| mup | PR snapd#4725 closed: tests: avoid removing preinstalled snaps on core <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4725> | 01:06 |
|---|---|---|
| mup | PR snapcraft#1988 opened: RFC: elf: only set rpaths to libs of the same arch <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1988> | 01:48 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| jdstrand | zyga-ubuntu (cc mvo): ack, thanks. I was running stable core and local built from master deb | 06:32 |
| zyga-ubuntu | That explains it then | 06:32 |
| jdstrand | zyga-ubuntu: would you mind looking at https://travis-ci.org/snapcore/snapd/builds/350156100#L5241 ? | 06:36 |
| zyga-ubuntu | looking | 06:37 |
| jdstrand | zyga-ubuntu: I'm puzzled by the failure cause it only fails on 16.04 i386 and debian-9. it is failing in a file I edited, but not a test case I edited. I don't see how PR 3998 would cause this to fail, and if it did, why it would be specific to i386 Ubuntu and debian-9 | 06:37 |
| mup | PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998> | 06:37 |
| jdstrand | zyga-ubuntu: but I've done 3 retries and it always fails, for just those two | 06:37 |
| zyga-ubuntu | hmmm debian 9 and i386 xenial | 06:38 |
| zyga-ubuntu | I'll look into it after breakfast | 06:38 |
| zyga-ubuntu | I should get going :) | 06:38 |
| jdstrand | zyga-ubuntu: ok. thanks! I've looked at my changes in that pr, but you might want to double check | 06:39 |
| jdstrand | zyga-ubuntu: the only thing I was thinking is maybe there restore() or the snap removes were leaving artifacts, but again, why just those two? | 06:40 |
| jdstrand | zyga-ubuntu: have a nice breakfast :) | 06:40 |
| mup | PR snapcraft#1987 closed: pluginhandler: add option to disable patchelf for a part <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1987> | 06:46 |
| === palasso is now known as palasso2 | ||
| === palasso2 is now known as palasso | ||
| mup | PR core#84 opened: xdg-open: switch to "snapctl user-open" based implementation <Created by jhenstridge> <https://github.com/snapcore/core/pull/84> | 07:43 |
| mup | PR snapcraft#1959 closed: elf: only patch elf files that aren't referenced by DT_NEEDED <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1959> | 08:02 |
| jamesh | zyga-ubuntu: https://forum.snapcraft.io/t/supporting-desktop-themes-via-the-content-interface/4122 | 08:23 |
| ackk | zyga-ubuntu, hi, so actually turns out that removing the ~/snap directory didn't fix my issue with snap-confine failing with permission denied | 08:41 |
| jdstrand | zyga-ubuntu: I know your busy, but curious if you found anything onthe PR 3998 spread test issue | 09:13 |
| mup | PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998> | 09:13 |
| jdstrand | zyga-ubuntu: I ask, in part, because popey and friends would love to see PR 3998 in 2.32, and I need to chat with mvo about that, but only once it lands | 09:14 |
| popey | +1 :) | 09:14 |
| popey | It blocks a bunch of electron apps which try to chown, and games which try to setpriority | 09:15 |
| jdstrand | I've enumerated what this fixes in the PR too | 09:16 |
| zyga-ubuntu | jdstrand: ish, I'm testing a fix now | 09:21 |
| zyga-ubuntu | jdstrand: it took me $FOREVER because I didn't have my linode key and I had to bring the i386 qemu image over | 09:21 |
| zyga-ubuntu | it's testing locally now | 09:21 |
| jdstrand | zyga-ubuntu: oh, if you have a moment, can you paste the diff? I'm curious what it was | 09:28 |
| zyga-ubuntu | jdstrand: sure, though not sure it works :) | 09:28 |
| zyga-ubuntu | in 3 min I will know | 09:28 |
| jdstrand | :) | 09:28 |
| ackk | zyga-ubuntu, is there a way to get more debug logs from snap-confine? I'm not sure what that failure is about | 09:28 |
| jdstrand | as mentioned, I was pretty puzzled by it | 09:29 |
| zyga-ubuntu | ackk: you can set SNAP_CONFINE_DEBUG=yes SNAPD_DEBUG=1 | 09:29 |
| zyga-ubuntu | ackk: that will show you way more things | 09:29 |
| ackk | zyga-ubuntu, thanks | 09:31 |
| ackk | zyga-ubuntu, that gives me this message: 2018/03/07 09:32:12.793577 cmd.go:102: DEBUG: core snap (at "/snap/core/current") is older ("2.31.1") than distribution package ("2.31.1+18.04") | 09:32 |
| zyga-ubuntu | ackk: that's okay, that's coming from parts other than snap-confine though | 09:33 |
| jdstrand | roadmr: fyi, I think this is another one like yesterday: https://dashboard.snapcraft.io/snaps/love-game/revisions/231/ | 09:35 |
| BjornT_ | sergiusens: this is what i currently have for bug 1752538: https://github.com/bjornt/snapcraft/commit/676457cfc4ad090387ea9d807ceca521bb936f01 | 09:36 |
| mup | Bug #1752538: Building snap using base-18 is broken with 2.39 <Snapcraft:Confirmed> <https://launchpad.net/bugs/1752538> | 09:36 |
| jdstrand | ralsina: and hi! :) | 09:36 |
| ackk | zyga-ubuntu, http://paste.ubuntu.com/p/vDQrQvj8JR/ is the full strace | 09:41 |
| mup | PR snapd#4796 opened: cmd/snap: "current"→"installed"; "refreshed"→"refresh-date" <Created by chipaca> <https://github.com/snapcore/snapd/pull/4796> | 09:47 |
| === __chip__ is now known as Chipaca | ||
| Chipaca | kyrofa: o/? | 09:50 |
| roadmr | hey jdstrand ! Let me check | 10:03 |
| Dianomic_Stefano | Hi, we have developed a service (FogLAMP) that uses avahi, it is visible using the command 'avahi-browse' when it runs in Ubuntu Server - but it is not visible when it runs in a snap in Ubuntu Core, any suggestions ? | 10:09 |
| roadmr | jdstrand: yes, sorry about that. I'll unwedge that one | 10:09 |
| Chipaca | Dianomic_Stefano: does your snap include an avahi daemon? | 10:15 |
| Dianomic_Stefano | yes : foglamp@foglamp-core:~$ snap list | 10:16 |
| Dianomic_Stefano | Name Version Rev Tracking Developer Notes | 10:16 |
| Dianomic_Stefano | avahi 0.7-26-g89573c2 87 edge ondra - | 10:16 |
| Dianomic_Stefano | avahi-client 0.6.32 38 stable ondra devmode | 10:16 |
| Dianomic_Stefano | classic 16.04 26 edge canonical devmode | 10:16 |
| Dianomic_Stefano | core 16-2.31.1+git606.68b2ef4 4176 edge canonical core | 10:16 |
| Dianomic_Stefano | pc 16.04-0.8 9 stable canonical gadget | 10:16 |
| Dianomic_Stefano | pc-kernel 4.4.0-116.140 104 stable canonical kernel | 10:16 |
| Dianomic_Stefano | foglamp@foglamp-core:~$ | 10:16 |
| Dianomic_Stefano | 10:16 | |
| Chipaca | Dianomic_Stefano: sorry, do you mean your _service_ is visible in avahi-browse, or your _server_? | 10:17 |
| Dianomic_Stefano | this is the snap list : | 10:19 |
| Dianomic_Stefano | foglamp@foglamp-core:~$ snap list | 10:19 |
| Dianomic_Stefano | Name Version Rev Tracking Developer Notes | 10:19 |
| Dianomic_Stefano | avahi 0.7-26-g89573c2 87 edge ondra - | 10:19 |
| Dianomic_Stefano | avahi-client 0.6.32 38 edge ondra - | 10:19 |
| Dianomic_Stefano | classic 16.04 26 edge canonical devmode | 10:19 |
| Dianomic_Stefano | core 16-2.31.1+git606.68b2ef4 4176 edge canonical core | 10:19 |
| Dianomic_Stefano | foglamp 1.2.0 x1 - - devmode | 10:19 |
| Dianomic_Stefano | pc 16.04-0.8 9 stable canonical gadget | 10:19 |
| Dianomic_Stefano | pc-kernel 4.4.0-116.140 104 stable canonical kernel | 10:19 |
| Dianomic_Stefano | foglamp@foglamp-core:~$ | 10:19 |
| Dianomic_Stefano | foglamp is our snap | 10:20 |
| Dianomic_Stefano | I installed avahi-client to being able to use 'avahi-client.browse' | 10:20 |
| Chipaca | Dianomic_Stefano: you said | 10:21 |
| Chipaca | Dianomic_Stefano: you " have developed a service […] that uses avahi, it is visible using the command 'avahi-browse' when it runs in Ubuntu Server" | 10:21 |
| Dianomic_Stefano | if I start foglamp in a Ubuntu server (in the same network) - I can see the service in the Ubuntu core using 'avahi-client.browse -a -t' | 10:21 |
| Chipaca | ah | 10:21 |
| Chipaca | Dianomic_Stefano: ok | 10:22 |
| Chipaca | Dianomic_Stefano: so, how does your snap talk to the avahi snap? | 10:22 |
| Dianomic_Stefano | if I start foglamp within the 'foglamp snap' I can't see the service running using 'avahi-client.browse -a -t' (and foglamp is running for sure) | 10:22 |
| Dianomic_Stefano | so, should I configure my snap 'foglamp' to talk with the avahi snap ? how ? | 10:23 |
| Chipaca | Dianomic_Stefano: the avahi snap exposes avahi-observe and avahi-control | 10:23 |
| Chipaca | Dianomic_Stefano: you probably need to connect your snap to avahi-control to add services, but I'm not sure | 10:24 |
| Chipaca | ondra: can you inform us? | 10:24 |
| Dianomic_Stefano | thanks for helping... | 10:25 |
| Chipaca | niemeyer: could you make spread look in ~/snap/google-cloud-sdk/current/.config/gcloud/ as well as ~/.config/gcloud for the google creds? | 10:54 |
| ondra | Chipaca Dianomic_Stefano hi, sorry in the meeting, will have a look after | 11:02 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#4797 opened: many: add the snapd-generator <Created by zyga> <https://github.com/snapcore/snapd/pull/4797> | 11:23 |
| === chihchun is now known as chihchun_afk | ||
| ondra | Dianomic_Stefano ping | 12:08 |
| ondra | Dianomic_Stefano you can use avahi-client as example how to implement and connect to avahi snap daemon service. | 12:10 |
| ondra | Dianomic_Stefano source for avahi client is here https://github.com/kubiko/avahi-client | 12:10 |
| ondra | Dianomic_Stefano depending how you want to expose your service, you can either use dbus, socket interface, or you can as well use content interface for service and simply place service file in there | 12:11 |
| Saviq | niemeyer: "Cannot allocate google:fedora-27: cannot allocate new Google server for fedora-27: required 'compute.images.useReadOnly' permission for 'projects/computeengine/global/images/fedora-cloud-base-27-1-6-x86-64'" when trying to use google with fedora images | 12:36 |
| Saviq | https://travis-ci.org/MirServer/mir/jobs/350005082 | 12:36 |
| === ikey|afk is now known as ikey | ||
| jdstrand | zyga-ubuntu: hi! :) | 12:58 |
| jdstrand | zyga-ubuntu: what happened with the test? | 12:58 |
| jdstrand | zyga-ubuntu: if you're busy, I understand, but I need to get it working so if you can't, can you tell me what you think it is? | 12:59 |
| zyga-ubuntu | jdstrand: re, so I tested it a little but then we found another bug that broke the test entirely | 13:00 |
| zyga-ubuntu | jdstrand: (squashfs) | 13:00 |
| zyga-ubuntu | jdstrand: we fixed that | 13:00 |
| zyga-ubuntu | jdstrand: and as soon as this lands I can merge master and see if my fix is ok | 13:00 |
| zyga-ubuntu | jdstrand: and while this happens I'm fixing the snap.mount unit for containers | 13:01 |
| zyga-ubuntu | and that's where we are | 13:01 |
| zyga-ubuntu | I wrote down the list of bugs we found this weeks so that we can keep track of things and not forget it | 13:01 |
| jdstrand | zyga-ubuntu: hey ok. yay for bug fixes! boo you are hitting them all at once. but yay people are here to interact with! but ... ;) | 13:04 |
| jdstrand | heh* | 13:04 |
| zyga-ubuntu | jdstrand: yeah, I hope to get to roughly the same bug count we had in the morning soon :D | 13:04 |
| jdstrand | zyga-ubuntu: thank you. not trying to be a pest (do I have to try?) | 13:04 |
| jdstrand | zyga-ubuntu: haha | 13:05 |
| Dianomic_Stefano | ondra: thanks, I'm going to take a look to it. | 13:06 |
| ondra | Dianomic_Stefano you are welcome :) | 13:06 |
| Chipaca | kyrofa: o/? | 13:37 |
| jamesh | popey: I've got a skeleton themes package. Where did you want me to upload it? | 13:48 |
| === palasso is now known as palasso2 | ||
| === palasso2 is now known as palasso | ||
| popey | jamesh: did we agree to put it under snapcrafters? | 14:07 |
| jamesh | popey: yeah. So I guess github.com/snapcrafters/gtk-common-themes? | 14:08 |
| popey | yes | 14:10 |
| popey | if you put it somewhere on github I can import it into snapcrafters jamesh | 14:10 |
| mup | PR snapcraft#1988 closed: elf: only set rpaths to libs of the same arch <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1988> | 14:12 |
| === palasso is now known as palasso2 | ||
| === palasso2 is now known as palasso | ||
| Dianomic_Stefano | ondra:hi, our service, foglamp, uses dbus so we have to expose that type of functionality. is it something related to changes in the snapcraft.yaml file only or is it something also in the code that we have to change/adapt ? | 14:21 |
| ondra | Dianomic_Stefano if you are using dbus, then all you need to defined in your snapcraft.yaml is avahi-control plug | 14:55 |
| ondra | Dianomic_Stefano then once you install your snap, snap connect <your snap>:avahi-control avahi | 14:55 |
| ondra | Dianomic_Stefano define plug like this https://github.com/kubiko/avahi-client/blob/master/snap/snapcraft.yaml#L32 | 14:56 |
| niemeyer | Saviq: Fixed the role so that everybody has access to that permission too | 15:01 |
| niemeyer | Saviq: Please let me know if you see anything else like this | 15:01 |
| Saviq | niemeyer: thanks! | 15:08 |
| * Saviq tries | 15:08 | |
| Saviq | niemeyer: we hit ENOSPC on the fedora images, should we grow the partition ourselves? I suppose cloud-init does it on ubuntu hosts? | 15:21 |
| Saviq | s/hosts/nodes/ | 15:21 |
| cachio__ | Saviq, are you running on google? | 15:25 |
| cachio__ | Saviq, how much space do you need? | 15:27 |
| kyrofa | Hey Chipaca, I'm here now! | 15:28 |
| kyrofa | Are you? | 15:28 |
| kyrofa | Our days almost completely miss each other while you folks are in budapest | 15:29 |
| Chipaca | kyrofa: i am | 15:35 |
| Chipaca | kyrofa: hello | 15:35 |
| Chipaca | kyrofa: let's talk about timestamps in our commands' output | 15:35 |
| kyrofa | Chipaca, hey there, sure! | 15:35 |
| Chipaca | kyrofa: so, we want to let people tinker with the output of stuff easily using grep/cut/etc | 15:36 |
| Chipaca | kyrofa: so for that it looks like RFC3339 is the way to go | 15:36 |
| Chipaca | that's the nassty YYYY-mm-ddTHH:MM:SSzzz format | 15:37 |
| Chipaca | but, because that's nasty for humans, we'd like to also offer friendlier timestamps | 15:37 |
| Chipaca | current proposal is for it to be "NN days ago, at HH:MM:SS ZZZ" | 15:37 |
| kyrofa | Chipaca, would supporting outputting json be better for such use-cases? | 15:37 |
| Chipaca | kyrofa: I think json would be a nice addition, but not replace things | 15:38 |
| kyrofa | Fair enough. Default to the human-friendly ones? | 15:38 |
| Chipaca | yeah | 15:38 |
| Chipaca | one nit with the human-friendly one is that if N is big, it's not that useful | 15:38 |
| kyrofa | Works for me. At some delta, does it make sense to switch from "days ago" to a date? | 15:38 |
| kyrofa | Exactly | 15:38 |
| Chipaca | say, "779 days ago, at 09:35 PST" | 15:39 |
| kyrofa | Yeah totally | 15:39 |
| Chipaca | yeah | 15:39 |
| kyrofa | I think more than a week it's not very useful | 15:39 |
| Chipaca | I think switching to just a YYYY-mm-dd after that would be alright | 15:39 |
| Chipaca | I don't have a good, locale-aware way of printing that unfortunately | 15:39 |
| Chipaca | (but everybody should understand that particular one ,right? i mean, it's iso :-p ) | 15:40 |
| kyrofa | I'm trying to think if times would still be useful to know for some things. Like when snaps were released | 15:40 |
| Chipaca | kyrofa: I think i'd set the cutoff a bit further out than a week | 15:40 |
| Chipaca | precisely because it drops time precision | 15:40 |
| Chipaca | but if you need to know the time of something further out than that i'm not too worried about you having to grok the rfc3339 nastiness (because aiui it'd be rare) | 15:41 |
| kyrofa | Good point, if we support that it covers everything | 15:41 |
| kyrofa | However, you raise a good point about locale. We need a way to do the same thing across both go and python | 15:41 |
| kyrofa | Would it be easier to forgo the "days ago" approach and just provide "YYYY-mm-dd, at HH:SS Z" ? | 15:42 |
| Chipaca | at my end, translating messages isn't an issue | 15:43 |
| Chipaca | translating times, is | 15:43 |
| kyrofa | Ah. Both are an issue for us :D | 15:43 |
| Chipaca | kyrofa: how so? | 15:43 |
| kyrofa | Mostly kidding-- we don't actually translate at all | 15:43 |
| Chipaca | kyrofa: if you do want to start doing it, you could piggyback on our catalogues | 15:44 |
| kyrofa | Yeah that's a larger discussion we need to have | 15:44 |
| kyrofa | Do you want to forgo translating the times for now, and push ahead with this? Or do some research? | 15:45 |
| kyrofa | I like the approach | 15:45 |
| kyrofa | Just need to decide the cutoff for days ago | 15:45 |
| kyrofa | Keep in mind that a lot of the timestamps coming from the store are without the zone, which means they're UTC if I remember correctly | 15:46 |
| kyrofa | Also, what option were you thinking of using for switching between them? --nasty? | 15:47 |
| kyrofa | Would be nice to have it be the same between tools | 15:47 |
| Chipaca | kyrofa: 'coming from the store', in the json? or elswhere | 15:48 |
| Chipaca | kyrofa: that reminds me, human-friendly times would be local, machine-friendly would be utc | 15:48 |
| kyrofa | Yeah, json. I think the acl timestamps are lacking zones | 15:48 |
| kyrofa | Chipaca, makes sense | 15:49 |
| Chipaca | kyrofa: we should double-check that's not a bug, and that they are indeed z | 15:49 |
| kyrofa | Chipaca, here I have a chat log | 15:50 |
| Chipaca | kyrofa: wrt flags, --absolute-times? | 15:50 |
| kyrofa | Hmm... doesn't seem obvious, but I don't really have a better suggestion either | 15:51 |
| Chipaca | kyrofa: sleep on it? | 15:53 |
| Chipaca | wrt cut off, 30 days? | 15:53 |
| kyrofa | Chipaca, https://pastebin.ubuntu.com/p/86bTpK98BW/ FYI | 15:54 |
| kyrofa | Sounds good | 15:54 |
| mup | PR snapd#4798 opened: snap: don't create empty Change with "Hold" state on disconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/4798> | 15:54 |
| Dianomic_Stefano | ondra:Hi, I changed the snapcraft.yaml of our snap in : | 15:56 |
| Dianomic_Stefano | apps: | 15:56 |
| Dianomic_Stefano | foglamp: | 15:56 |
| Dianomic_Stefano | command: usr/bin/wrapper-foglamp | 15:56 |
| Dianomic_Stefano | plugs: | 15:56 |
| Dianomic_Stefano | - avahi-control | 15:56 |
| Dianomic_Stefano | - network | 15:56 |
| kyrofa | Chipaca, thanks for the chat, that's been bothering me for a while | 15:57 |
| Dianomic_Stefano | at at the start of the service I have got : Mar 7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: Error parsing EntryGroup::AddService message Mar 7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: dbus-entry-group.c: interface=org.freedesktop.Avahi.EntryGroup, path=/Client46/EntryGroup1, member=AddService Mar 7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: Error parsing EntryGroup::AddService | 15:57 |
| Dianomic_Stefano | ---- | 15:57 |
| Dianomic_Stefano | Mar 7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: Error parsing EntryGroup::AddService message | 15:57 |
| Dianomic_Stefano | Mar 7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: dbus-entry-group.c: interface=org.freedesktop.Avahi.EntryGroup, path=/Client46/EntryGroup1, member=AddService | 15:57 |
| Dianomic_Stefano | Mar 7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: Error parsing EntryGroup::AddService message | 15:57 |
| Dianomic_Stefano | Mar 7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: dbus-entry-group.c: interface=org.freedesktop.Avahi.EntryGroup, path=/Client46/EntryGroup1, member=AddService | 15:57 |
| Dianomic_Stefano | -- | 15:57 |
| Chipaca | kyrofa: perfect thanks | 15:57 |
| Chipaca | Dianomic_Stefano: please use a pastebin for pasting long text | 15:58 |
| Chipaca | Dianomic_Stefano: pastebin.ubuntu.com | 15:58 |
| Dianomic_Stefano | ok | 16:01 |
| Dianomic_Stefano | ondra: https://pastebin.ubuntu.com/p/HQJqBdNTzK/ | 16:03 |
| mup | PR snapcraft#1989 opened: elf: don't parse elf more than we need to <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1989> | 16:07 |
| morphis_ | kyrofa, popey: do you guys have an example snap somewhere which is using Qt+QML? I don't get one working, things are crashing just badly for me so far | 16:15 |
| ondra | Dianomic_Stefano this looks like problem with your dbus message to the avahi service, is this working when you run it on classic system? | 16:28 |
| ondra | Dianomic_Stefano is it working when you run it in --devmode | 16:28 |
| Dianomic_Stefano | I installed using 'sudo snap install --devmode foglamp_1.3.3_amd64.snap' | 16:29 |
| Dianomic_Stefano | ad it produce the error messages in the syslog | 16:29 |
| ondra | Dianomic_Stefano first make sure that your client is working well with avahi daemon before you start snapping it. Debugging in snap confinement is just adding unnecessary burden to debugging | 16:30 |
| Dianomic_Stefano | it works fine in a standard Ubuntu Server and using for example 'avahi-browse -t -a -d local ' to check its existence | 16:30 |
| ondra | Dianomic_Stefano OK once I have time I will debug with my example client avahi-client.browse -t -a -d local | 16:33 |
| ondra | Dianomic_Stefano as that seems to be also failing now | 16:33 |
| ondra | Dianomic_Stefano so quick work around, avoid use of avahi-browse -a | 16:43 |
| ondra | Dianomic_Stefano avahi does not broadcast correctly PTR record, at least what I could so far find about this error | 16:44 |
| popey | morphis_: i do not | 16:47 |
| Dianomic_Stefano | ondra: the point seems different: I was able to start our service using the snap that was created having the snapcraft.yaml having only ' plugs: [network]' | 16:47 |
| ondra | Dianomic_Stefano I was testing with avahi-client.browse _http._tcp | 16:48 |
| Dianomic_Stefano | ondra: I was no more able to start our service when I created the snap having in snapcraft.yaml ' plugs: - avahi-control - network' | 16:48 |
| ondra | Dianomic_Stefano and that works, but when I call avahi-client.browse -t -a -d local | 16:48 |
| ondra | Dianomic_Stefano then I get error | 16:48 |
| ondra | Dianomic_Stefano that just means that your service was before not talking to avahi daemon at all | 16:48 |
| Dianomic_Stefano | but it worked fine in the standard Ubuntu server | 16:49 |
| ondra | Dianomic_Stefano yeah because there daemon is installed as deb package and is not confined | 16:51 |
| morphis_ | popey: hm | 16:51 |
| ondra | Dianomic_Stefano on core apparmor will fag any unauthorised communication to the daemon | 16:51 |
| ondra | Dianomic_Stefano so running client as --devmode does not guarantee you that you can talk to avahi snap daemon | 16:52 |
| ondra | Dianomic_Stefano communication is secured from both sides. On server it's only from one side if you are talking to something from classic side | 16:53 |
| Dianomic_Stefano | ondra: could I completely disable apparmor ? if this could help. | 16:54 |
| ondra | Dianomic_Stefano you can install also avahi in devmode | 16:54 |
| ondra | Dianomic_Stefano then both sides are unconfined | 16:54 |
| Dianomic_Stefano | ondra: I'm going to try | 16:55 |
| morphis_ | popey: I feel like the xenial Qt version was just too old and buggy for my use case | 17:00 |
| Dianomic_Stefano | ondra: same situation - https://pastebin.ubuntu.com/p/BKPH3qCNfM/ | 17:06 |
| Nafallo | hiya. can I overwrite ~/snap to ~/.snap somewhere? :-) | 17:07 |
| nacc | Nafallo: i think it's pretty well defined to be ~/snap | 17:14 |
| morphis_ | popey: so yes, that was the problem; using newer qt prebuilt from qt.io fixes the problems and make the snap working on various Ubuntu versions | 17:17 |
| mup | PR snapcraft#1990 opened: tests: build and install snapcraft on osx <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1990> | 17:19 |
| Nafallo | nacc: i.e. I can't change it? | 17:21 |
| nacc | Nafallo: I don't believe so, but I'm not 100% | 17:21 |
| nacc | Nafallo: i think you'd need to patch snapd to do so, but I'm not sure (SNAP_USER_DATA and SNAP_USER_COMMON depend on that path) | 17:22 |
| ondra | Dianomic_Stefano hmm, I'm not expert on avahi, so we might need to ask lathiat for help | 17:23 |
| ondra | Dianomic_Stefano are you calling avahi-browser directly? | 17:23 |
| Nafallo | nacc: thanks for the response. I'll guess we need IndexIgnore for the home dir next ;-) | 17:24 |
| nacc | Nafallo: :) | 17:24 |
| Dianomic_Stefano | ondra: no, I have used 'avahi-client.browse -a -t' | 17:24 |
| ondra | Dianomic_Stefano interestingly without changing anything vahi-client.browse -t -a -d local does work now | 17:25 |
| ondra | Dianomic_Stefano ok avahi-client.browse -a -t does work here | 17:25 |
| ondra | Dianomic_Stefano so what are you running this on? | 17:25 |
| ondra | zyga-ubuntu any idea what this means? https://paste.ubuntu.com/p/HH7NK5hPF5/ | 17:42 |
| zyga-ubuntu | ondra: It means that the snap has a content interface plug with a default provider that does not exist | 18:04 |
| zyga-ubuntu | CC mvo | 18:04 |
| ondra | zyga-ubuntu hmm, it is installed on that machine | 18:07 |
| ondra | zyga-ubuntu and shouldn't this be warning instead of error blocking installation | 18:07 |
| ondra | zyga-ubuntu OK my bad, I had wrong version of default provider, sorry for that | 18:09 |
| fireclawTheFox | Hey everyone. My snapcraft plugin doesn't work when run on launchpad, quiting with "no attribute '_python_major_version'". The plugin is derived from the python plugin and does work fine if run locally. Does anyone know what could cause this? | 20:26 |
| nacc | fireclawTheFox: how are you building locally? cleanbuild? | 20:28 |
| nacc | fireclawTheFox: in any case, i'd first check the version of snapcraft locally vs. the version on LP | 20:29 |
| fireclawTheFox | the snapcraft version I have is the stable 2.39.2 (1177) | 20:32 |
| nacc | fireclawTheFox: and how are you building locally? | 20:32 |
| nacc | fireclawTheFox: and on what release? | 20:32 |
| fireclawTheFox | usually snapcraft -d I did try cleanbuild but last time I tried it stopped almost instantly with some lxd problem. Will try that again. | 20:33 |
| fireclawTheFox | release of what? Do you mean the Ubuntu version? | 20:34 |
| nacc | fireclawTheFox: yeah | 20:34 |
| fireclawTheFox | 16.04 | 20:34 |
| nacc | fireclawTheFox: ok, that rules out one thought i had :) | 20:34 |
| nacc | fireclawTheFox: note that the snapcraft used by LP is from the debs (I believe) and is currently at 2.39.3+really2.35 | 20:34 |
| nacc | fireclawTheFox: so you should test using that one, probably | 20:35 |
| fireclawTheFox | using cleanbuild I get this: https://paste.ubuntu.com/p/z7yTYDzHJ9/ | 20:35 |
| nacc | fireclawTheFox: yeah, i believe that was fixed in snapcaft (it's aobut using a snap to call lxd | 20:36 |
| nacc | kyrofa: --^ do you know if that's fixed in snapcraft? i think you had commented on this in the github issue | 20:37 |
| fireclawTheFox | How do I get the 2.39.3 deb version? | 20:37 |
| nacc | fireclawTheFox: of snapcraft? i assume you need to uninstall the snapcraft snap and install the snapcraft deb (apt) | 20:38 |
| fireclawTheFox | ah ok, will try | 20:38 |
| nacc | although that does raise the question of why the snapcraft snap is behind the the snapcraft deb | 20:38 |
| kyrofa | nacc, I don't believe it's fixed, we didn't want to introduce a hack in snapcraft to work around a lxd bug | 20:38 |
| nacc | kyrofa: ack, is there a suggestion for fireclawTheFox to workaround it? | 20:39 |
| kyrofa | nacc, fireclawTheFox I personally fire up a clean lxd image with a custom profile that installs snapcraft, then build in there | 20:39 |
| kyrofa | Not as seamless, but works well enough for me | 20:39 |
| kyrofa | Could also use our docker container if you like, snapcore/snapcraft | 20:41 |
| kyrofa | :latest is the deb, :<channel> is each channel of the snap, edge, beta, candidate and stable | 20:41 |
| nacc | kyrofa: ah makes sense | 20:42 |
| fireclawTheFox | ok, installed the deb version which gives me the same version as launchpads and as expected results in the same error. | 20:43 |
| magicaltrout | stupid question multiple developers, if you want to grant access to push to the same snap. Can you? :) | 20:43 |
| kyrofa | fireclawTheFox, indeed, it's not a snapcraft bug, it's a lxd bug | 20:43 |
| kyrofa | As long as you have lxd installed from the deb, you'll have that issue | 20:43 |
| kyrofa | magicaltrout, indeed you can add collaborators in the web interface of the store, but it's kind of all or nothing-- they can administer the snap | 20:44 |
| kyrofa | (i.e. not just push) | 20:44 |
| fireclawTheFox | kyrofa: I meant the error that I get because of the not existing _python_major_version, not the lxd one. I do wonder though, if the deb version is a more recent version than the sources on git, as this specific variable I was using is still there in the git sources. | 20:46 |
| nacc | fireclawTheFox: *older* version than what is in git | 20:46 |
| nacc | fireclawTheFox: the issue is presumably that, since you were using a newer snapcraft (from the snap) than what is in xenial-updates | 20:47 |
| nacc | kyrofa: which brings up a good point about the snapcraft snap, hsouldn't it get reverted too? | 20:47 |
| nacc | kyrofa: given we know it's broken for certain (*cough*) classic snaps | 20:47 |
| fireclawTheFox | ah ok, so I'm ahead. | 20:47 |
| nacc | fireclawTheFox: well, you were (when on the snapped snapcraft) | 20:47 |
| kyrofa | nacc, it IS? Oh no, I should have spent every day this week on that! :D | 20:47 |
| magicaltrout | ah yeah got it | 20:48 |
| magicaltrout | thanks | 20:48 |
| nacc | kyrofa: heh :) | 20:48 |
| nacc | kyrofa: it was more a question of how the snapped snapcraft works relative to the deb :) | 20:48 |
| nacc | (version wise) | 20:48 |
| kyrofa | nacc, kidding aside, I'm not sure. It's actually been released for a lot longer than the deb, but things didn't explode until we released the deb since that's what all the infrastructure is based upon | 20:49 |
| nacc | kyrofa: yeah | 20:49 |
| kyrofa | nacc, the snap works a bit differently since it bundled the correct version of patchelf | 20:49 |
| kyrofa | With the deb, we didn't have that option | 20:49 |
| nacc | kyrofa: oh sure | 20:49 |
| fireclawTheFox | nacc, kyrofa, does it change anything, if I switch the series of the snap reciep on launchpad (e.g. to Artful or Bionic) or will it always use the same snapcraft version? | 20:49 |
| kyrofa | fireclawTheFox, if you're building a snap in LP, I suggest always using xenial | 20:50 |
| nacc | fireclawTheFox: you don't (generally) want to do that :) | 20:50 |
| nacc | for other reasons :) | 20:50 |
| fireclawTheFox | ok | 20:50 |
| fireclawTheFox | so for now, I either have to wait until LP will update the snapcraft version or fix my custom plugin, right? | 20:51 |
| nacc | fireclawTheFox: yes, I believe so. The latter is probably preferable, since it seems to be dependent on external python code (which you don't control the version of) | 20:52 |
| kyrofa | fireclawTheFox, I haven't actually seen the issue you've hit. I think I missed it above | 20:52 |
| kyrofa | All I saw was the lxd bit | 20:52 |
| fireclawTheFox | kyrofa, the error I posted above was before I changed to the deb version. The new one looks like the one I get on launchpad so that's fine. | 20:55 |
| kyrofa | fireclawTheFox, ohhh, you're using a local plugin written against git master, but the deb is much older | 20:56 |
| kyrofa | Okay, same page now | 20:56 |
| nacc | kyrofa: yeah, and that's why i was asking about the snap :) | 20:57 |
| fireclawTheFox | yeah, I have a local plugin which was based on the snap/git version of snapcraft | 20:57 |
| kyrofa | fireclawTheFox, normally that wouldn't be a problem except we haven't had a deb release for a while so it's pretty far behind. I suggest updating the local plugin referring to the 2.35 tag | 20:58 |
| fireclawTheFox | will do | 20:58 |
| fireclawTheFox | if the standard python plugin would be able to accept custom setup tool commands (e.g. replacing the install arg) I might not even needed to build a custom plugin. | 21:01 |
| bashfulrobot | hey guys... how does one remove a snap from a channel in the store? I tried doing `snapcraft release {name} {rev} {channel}` with an older revision. But `list-revisions` shows both in the original channels. Isthis something that you do with the `close` option? | 21:08 |
| bashfulrobot | sorry - "remove a snap revision" | 21:09 |
| kyrofa | bashfulrobot, check `snapcraft status` instead | 21:12 |
| kyrofa | Or `snap info` | 21:12 |
| kyrofa | bashfulrobot, or, in list-revisions, look for the asterisk | 21:13 |
| kyrofa | Basically, the store remembers that a given snap was released into a given channel, and list-revisions shows you that | 21:13 |
| kyrofa | But the only thing that really matters is which revision is currently ACTIVE in that channel | 21:13 |
| kyrofa | fireclawTheFox, can you be more specific about what the plugin is doing today and what you need it to do? | 21:15 |
| kyrofa | fireclawTheFox, we're always open to adding to it | 21:15 |
| bashfulrobot | kyrofa: Rockstar! Thanks. Misunderstood the output | 21:15 |
| kyrofa | bashfulrobot, there's a lot of info there, easy to misinterpret | 21:15 |
| fireclawTheFox | kyrofa, it's a plugin to utilize the deployment system of the Panda3D game engine. It doesn't do that much, just calling the setup.py script with -OO and build_apps instead of install and finally copy some libs into the root directory. | 21:20 |
| mup | Issue snapcraft#1991 opened: Distrubuted ROS system among multiple snaps <Created by Lingaprahasam> <https://github.com/snapcore/snapcraft/issue/1991> | 21:23 |
| fireclawTheFox | kyrofa: you can take a look at my actual plugin here: https://bazaar.launchpad.net/~fireclawthefox/thetravelingfox/snap/view/head:/snap/plugins/x_panda3d.py | 21:26 |
| kyrofa | fireclawTheFox, oh man, you're gonna be so sad making that work on 2.35 | 21:27 |
| kyrofa | Don't throw this away | 21:27 |
| kyrofa | fireclawTheFox, so panda3d won't work with pip? | 21:30 |
| fireclawTheFox | kyrofa I can install it with pip, but then I have the complete engine installed which isn't really desirable. Using the deploy tools of the engine will pack up everything nicely and will save a lot of space. | 21:32 |
| kyrofa | fireclawTheFox, interesting, okay. As you may have seen in the code, as call setup.py install directly as a workaround for a bug, not really as a thing we expect many people need | 21:33 |
| kyrofa | s/as/we/ | 21:33 |
| kyrofa | Perhaps that needs to change | 21:33 |
| fireclawTheFox | yeah, not sure if many people do write custom setup tools, but for those who are, having this configurable would be a welcome addition. | 21:34 |
| fireclawTheFox | btw, what bug are you talking about that calling setup.py install directly fixes? | 21:35 |
| mup | Issue snapcraft#1991 closed: Distrubuted ROS system among multiple snaps <Created by Lingaprahasam> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1991> | 21:41 |
| Lite5h4dow | Hi there | 22:15 |
| Lite5h4dow | Im having issues installing snapd | 22:15 |
| Lite5h4dow | from the AUR | 22:15 |
| Lite5h4dow | well, snapd and snapd-git both fail to build | 22:16 |
| Lite5h4dow | is any one here? | 22:18 |
| Lite5h4dow | guess not | 22:19 |
| Lite5h4dow | rest in pepperonies | 22:19 |
| bashfulrobot | kyrofa: It's actually not too bad. But it is one of those things as you work through it for the first time... 😃 | 22:19 |
| Lite5h4dow | hello palasso | 22:21 |
| palasso | hello | 22:21 |
| Lite5h4dow | do you know anything about building snapd on arch? | 22:22 |
| palasso | Yeah, it's on the AUR | 22:22 |
| Lite5h4dow | yeah | 22:22 |
| Lite5h4dow | problem with that | 22:22 |
| Lite5h4dow | it fails to build | 22:22 |
| Lite5h4dow | both snapd and snapd-git fail | 22:23 |
| palasso | could you pastebin the output? | 22:23 |
| Lite5h4dow | https://pastebin.com/HwTtu8eG | 22:24 |
| palasso | hmmmm it's not descriptive | 22:26 |
| palasso | snapd gives you same output? | 22:26 |
| Lite5h4dow | yup | 22:26 |
| Lite5h4dow | same error | 22:26 |
| palasso | Have you considered to build the package through makepkg? | 22:28 |
| Lite5h4dow | yup | 22:28 |
| Lite5h4dow | same error | 22:28 |
| Lite5h4dow | its an error in the pkgbuild | 22:28 |
| palasso | I'll try to build it now and see what will happen | 22:28 |
| Lite5h4dow | autoreconf isnt a recognised command | 22:28 |
| Lite5h4dow | any luck? | 22:32 |
| palasso | It's still building, I'll let you know once it's finished | 22:40 |
| Lite5h4dow | ok | 22:40 |
| palasso | and finished | 22:40 |
| Lite5h4dow | xD | 22:40 |
| palasso | It builds on my machine | 22:40 |
| Lite5h4dow | huh | 22:40 |
| Lite5h4dow | weird | 22:40 |
| Lite5h4dow | could you walk me through what you did? | 22:40 |
| Lite5h4dow | because i built it and it broke | 22:41 |
| palasso | just makepkg | 22:41 |
| Lite5h4dow | your on arch right? | 22:41 |
| palasso | yeah of course | 22:41 |
| Lite5h4dow | ok | 22:41 |
| Lite5h4dow | really weird | 22:41 |
| palasso | I could upload the built package for you to download if you want | 22:42 |
| Lite5h4dow | i think it was just my version of base-devel | 22:45 |
| Lite5h4dow | it was a little old | 22:45 |
| Lite5h4dow | yeah | 22:45 |
| Lite5h4dow | it installed | 22:45 |
| Lite5h4dow | my bad | 22:45 |
| palasso | Okay, nice | 22:45 |
| Lite5h4dow | im on a macbook, so not every package works | 22:46 |
| Lite5h4dow | so i had the core packages frozed | 22:46 |
| Lite5h4dow | frozen* | 22:46 |
| palasso | Ahh yeah this is a problem for arch. | 22:46 |
| palasso | If you freeze lost of core packages it's hard to install newer software | 22:47 |
| Lite5h4dow | yeah | 22:47 |
| Lite5h4dow | anyway | 22:48 |
| Lite5h4dow | ty for taking the time to help | 22:48 |
| palasso | yw | 22:48 |
| Lite5h4dow | now to see if i can get anbox installed | 22:49 |
| palasso | Lite5h4dow: if you wish to remain with many packages frozen consider using the Arch Linux Archive. You could point your repo to a specific date and get all software from that date (no security fixes). Otherwise perhaps you should look for some other distro that does fixed-point releases. Or maybe some strategy for rollbacks in case of regressions after updating | 22:50 |
| Lite5h4dow | oh ok | 22:51 |
| Lite5h4dow | ill definately do that | 22:55 |
| Lite5h4dow | but im looking into it and it seems all the current versions of the core packages support my macbook | 22:55 |
| Lite5h4dow | so im going to do a full upgrade tonigh | 22:55 |
| Thillai | hello team | 23:34 |
| Thillai | I have a Edge Gateway that runs ubuntu-core/15.04/stable.. | 23:37 |
| Thillai | I am trying to install Apache2 on this device.. Does anyone have idea on thi.. | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!