[00:56] <mup> PR snapcraft#1006 closed: schema: replace `snap` filter with `prime` filter <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1006>
[00:59] <mup> PR snapcraft#1014 closed: tests: reorganize plugin tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1014>
[02:00] <liuxg> elopio, have you checked the reported "classic confinement requires the core_dynamic_linker to be set"? I just installed a container, and I found the same issue
[02:04] <mup> Bug #1653851 opened: no way to avoid CDN for assertions.ubuntu.com within launchpad builds <Snappy:New> <https://launchpad.net/bugs/1653851>
[02:10] <mup> Bug #1653852 opened: Cannot activate Chinese input method for Qt app even in the devmode <Snappy:New> <https://launchpad.net/bugs/1653852>
[04:20] <liuxg> elopio, I have tried to build it in yaketty container, and I have the same issue. What is your finding? thanks
[07:55] <mup> PR snapd#2492 closed: cmd/snap: remove currency switch following UX review <Created by pete-woods> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2492>
[09:27] <mup> PR snapd#2549 closed: cmd/snap-confine: add shutdown helper <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2549>
[09:27] <davidcalle> Morning and happy new year! Is it expected that on 2.20.1+17.04ubuntu2 , network-bind doesn't auto-connect?
[09:28] <davidcalle> mvo ^
[09:29] <davidcalle> (or zyga ? ^)
[09:55] <liuxg> davidcalle, network-bind needs to have mannual connect? according to the spec, http://snapcraft.io/docs/reference/interfaces, it should be.
[09:56] <davidcalle> liuxg: I know, that's why I'm asking why it's not auto-connecting anymore
[10:06] <topi`> I'm trying to build os/kernel/gadget snaps for an unsupported device (Hummingboard), any idea how to "cache" the always-recurring download of ubuntu-core when running "snapcraft"?
[10:07] <topi`> no matter how little I change, it always re-downloads it
[10:27] <davidcalle> sergiusens: ^
[10:37] <jamespage> jdstrand, ok so I've had some good success with the new network-namespace support in network-control with the nova-hypervisor snap
[10:38] <jamespage> jdstrand, the nova-hypervisor snap almost works in strict mode now
[10:39] <jamespage> jdstrand, looking at the remaining syslog DENIED messages, the remaining issues look related to processes wanting to drop privs for things like dnsmasq
[10:41]  * jamespage is frustratingly close to having this working...
[10:58] <mup> PR snapd#2551 opened: refactore store.Snap to take a spec struct <Created by chipaca> <https://github.com/snapcore/snapd/pull/2551>
[11:24] <kalikiana_> topi`: Does the core snap show as being installed? Does "snap changes" say anything dubious?
[11:26]  * kalikiana_ has no idea about that device, but checking those should be a good start
[11:32] <mup> PR snapcraft#1015 closed: tests: reorganize command tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1015>
[12:04] <mcphail> kyrofa: are you still maintaining the nextcloud snap? If I install it, in preference to a manual nextcloud install, what restrictions would I be likely to face? Can I, for example, use Let's Encrypt etc?
[12:11] <mup> Issue snapd#2552 opened: snapd is not tested with against Arch Linux <Created by zyga> <https://github.com/snapcore/snapd/issue/2552>
[12:21] <kalikiana_> Hrm. Getting "...changes in progress..." error and nothing in 'snap changes'. I hate it when that happens.
[12:38] <mup> Bug #1653955 opened: Access to /dev/shm/sem.snap.@{SNAP_NAME}.* should be allowed for semaphores to work <Snappy:New> <https://launchpad.net/bugs/1653955>
[12:41] <mup> Issue snapd#2553 opened: snapd is not tested against Debian <Created by zyga> <https://github.com/snapcore/snapd/issue/2553>
[12:56] <popey> mcphail: http://flexion.org/posts/2016-12-raspberry-pi-3-powered-nextcloud-box-on-ubuntu-core - i used that guide to add letsencrypt
[13:24] <mcphail> popey: thanks. That looks clever. Didn't realise there were helper scripts in the snap. Do you know if you can dd extra apps like the calendar app etc? Not sure how the snap would handle that...
[13:24] <mcphail> *add
[13:28] <popey> mcphail: i think so, yes. I added an app as part of that guide
[13:28] <didrocks> pedronis: hey! I was wondering if when providing required-snaps, I could make one installed in devmode?
[13:30] <pedronis> didrocks: you can say --devmode for everything but it's probably going to change again
[13:30] <pedronis> didrocks: anyway is something you pass/would pass to ubuntu-image, not something that goes into the model assertion
[13:31] <pedronis> didrocks: we have a open task about clarifying/fixing this
[13:31] <pedronis> didrocks: mvo started to look into that
[13:32] <didrocks> pedronis: hum, so, in the model assertion, I should put the snap name
[13:32] <didrocks> pedronis: and in ubuntu-image, there is a devmode option?
[13:32] <pedronis> didrocks: yes, just the snap name
[13:32] <pedronis> didrocks: there should be but might not work atm
[13:32] <mcphail> popey: excellent. Ta
[13:32] <pedronis> as I said bit of wip atm
[13:33] <didrocks> pedronis: ok, I think this isn't going to work for our workshop deadline thus
[13:33] <didrocks> pedronis: I'll keep on "this does not work thus"
[13:33] <didrocks> :)
[13:45] <mup> PR snapcraft#1019 closed: tests: reorganize state tests into subdirectory <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1019>
[13:48] <mup> PR snapcraft#973 closed: ci: check the license agreement on Travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/973>
[13:52] <mup> PR snapd#2551 closed: refactor store.Snap to take a spec struct <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2551>
[13:59] <mup> PR snapd#2554 opened: tests: add end-to-end store test for classic confinement <Created by mvo5> <https://github.com/snapcore/snapd/pull/2554>
[14:13] <liuxg> sergiusens, ping
[14:15] <sergiusens> liuxg hey
[14:15] <jacekn> hello. What's the best way to create new directory in my snap package using snapcraft.yaml? I need to ship it with empty directory but can't find a way to do it, thought dump plugin woudl do it but does not look like it
[14:16] <liuxg> sergiusens, regarding the bug https://bugs.launchpad.net/snapcraft/+bug/1650946, I tried to compile my sample project using LXD, and I had the same issue. What could be reason for it? thanks
[14:16] <mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Incomplete> <https://launchpad.net/bugs/1650946>
[14:16] <liuxg> sergiusens, I checked it with my colleague and it worked under 17.04.
[14:17] <sergiusens> liuxg oh, does snap list show `core` in there? if not, `snap install core`
[14:17] <sergiusens> and tell me if that works
[14:18] <liuxg> sergiusens, http://paste.ubuntu.com/23739129/, this is the list
[14:18] <liuxg> sergiusens, I think ubuntu-core is there already
[14:18] <sergiusens> liuxg I didn't need the list ;-) And no it is not, `ubuntu-core` != core
[14:19] <sergiusens> so `snap install core`
[14:22] <liuxg> sergiusens, oh, I see your point. However, I got an error http://paste.ubuntu.com/23739153/. Should I remove ubuntu-core first?
[14:23] <liuxg> sergiusens, I am wondering what is the difference between "core" and "ubuntu-core". Are they the same thing? Sorry, this is the first time I tried to install core.
[14:23] <sergiusens> liuxg I don't know about that, I have both at the same time. But you need that for classic snaps to be buildable
[14:23] <sergiusens> core replaces ubuntu-core
[14:24] <sergiusens> liuxg you will need to ask someone in the snapd (core team) about this
[14:24] <liuxg> sergiusens, so, I should remove the "ubuntu-core" first in order to install "core".
[14:25] <liuxg> sergiusens, by the way, who is from the snapd team?
[14:26] <sergiusens> mvo zyga ^
[14:26] <sergiusens> liuxg you can get by this by `snap install core` in a clean lxd container and build there
[14:27] <liuxg> sergiusens, OK. I will try it. thanks
[14:27] <mvo> liuxg: ubuntu-core and core are currently mostly identical except the name, we will transition ubuntu-core to core at some point but thats not done yet
[14:28] <sergiusens> mvo right, classic confined snaps require having core installed to build and eventually run
[14:28] <liuxg> mvo, the thing is that classic needs to have "core" instead of "ubuntu-core", right? I cannot remove the "ubuntu-core" for now in my 16.04 system. Can I get them both co-exist in order to test classic?
[14:28] <sergiusens> seems an addition to not allowing both installed was added recently
[14:30] <liuxg> sergiusens, mvo, the problem is that how can I test it on 16.04 OS. By default, "ubuntu-core" is installed on my machine. when i tried to remove "ubuntu-core", it complains "error: cannot remove "ubuntu-core": snap "ubuntu-core" is not removable"
[14:34] <mvo> liuxg: thats a bug then in classic mode, it should work with either ubuntu-core and core, let me have a look
[14:35] <mvo> liuxg: plus it should be possible to exachange the two, thats another bug :/
[14:35] <sergiusens> mvo it actually isn't possible, we designed it that way with zyga
[14:35] <liuxg> mvo, thanks! I never got it working. could you please see the bug report at https://bugs.launchpad.net/snapcraft/+bug/1650946?
[14:35] <mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Incomplete> <https://launchpad.net/bugs/1650946>
[14:36] <sergiusens> mvo the linker used is hard coded in the elf headers
[14:36] <mvo> sergiusens: oh, ok. so then we need to make it possible to remove ubuntu-core
[14:36] <mvo> sergiusens: I have a look
[14:38] <pedronis> mvo: that is a bit problematic in other ways, I think we wanted to allow that but only if there are no other snaps installed (on classic)
[14:38] <pedronis> I mean to remove core/ubuntu-core
[14:42] <mup> Bug #1653988 opened: no soundcore in linux-raspi2  <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1653988>
[14:44] <mvo> pedronis: aha, I see, to avoid that people break their system? I guess "snap install core and remove ubuntu-core" would be nice :)
[14:48] <pedronis> mvo: yes, to avoid people breaking stuff without thinking
[15:29] <pmcgowan> mvo, is there a workaround to the issue discussed above? can I just rm the /snap/ubuntu-core folder?
[15:31] <mvo> pmcgowan: cleanest workaround is to purge snapd (the deb) and then snap install core as the first operation
[15:32] <pmcgowan> OK
[15:41] <popey> mvo: that requires removal of all snaps?
[15:46] <mvo> popey: unfortunately, we work on something better but its not there yet
[15:47] <popey> ok
[15:52] <jdstrand> niemeyer: hi! I'm not up on everything for 'aliases'. I need to add support to the review tools and was wondering if declaring aliases should prompt for manual review. My understading is 'no' since the aliases are applied by the user unless there is an auto-alias in the store
[16:05] <niemeyer> jdstrand: Heya
[16:05] <niemeyer> jdstrand: Happy new year (to all!)
[16:06] <niemeyer> jdstrand: Yeah, it shouldn't prompt for manual review.. the idea is that people can experiment with aliases without the burden of involving reviews
[16:06] <niemeyer> jdstrand: We then need a way for people to ask for aliases
[16:06] <niemeyer> ask for auto-aliases, that is
[16:06] <niemeyer> Which is just an explicit whitelist of a particular alias that may (and may not!) be in the snap
[16:09] <jdstrand> niemeyer: ok, thanks. fyi, cprov showed me today that the store already has support to grant auto-aliases. I don't know the status/plans for how to request them
[16:09] <jdstrand> I mean, putting them in the yaml is a form of request, but I don't think that is what you were talking about
[16:21] <niemeyer> jdstrand: Yeah, that's no tit
[16:22] <niemeyer> jdstrand: As long as you can edit them, we can take bugs as requests for the time being
[16:23] <jdstrand> niemeyer: sounds good
[16:23] <ogra_> sudo apt install fakeroot
[16:23] <ogra_> bah !
[16:26] <longsleep> ogra_: hey any idea how and whom to contact so https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1652262 can be resolved rather sooner than later? For me right now its pretty unclear how extra dependencies for stuff added to ubuntu-core are handled. I remember there was some ppa which got pulled in during rootfs build in the past.
[16:26] <mup> Bug #1652262: subiquitycore exception in controller.run <snappy> <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1652262>
[16:27] <ogra_> heh, i just saw someone comment on it
[16:27] <longsleep> ogra_: yeah me too, thats why i rememberd to ask you :)
[16:27] <ogra_> longsleep, usually subiquity is mwhudson's baby
[16:27] <ogra_> might be that he is still on EOY vacation though
[16:27] <longsleep> ogra_: yes but the fix is in a dependency of subiquity - i wonder how these get pulled in
[16:28] <ogra_> oh ?
[16:28]  * ogra_ checks the bug 
[16:28] <longsleep> ogra_: fix is in https://github.com/CanonicalLtd/probert/commit/09c449104c15f7c4518eff77055d70af08bcc42a
[16:28] <longsleep> ogra_: so in the probert python module
[16:29] <ogra_> longsleep, ah, well, that might be a cyphermox package (though mwhudson tends to touch it too)
[16:29] <ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[16:30] <ogra_> last probert upload for xenial is from nov. 10th though
[16:30] <longsleep> ogra_: ah yeah that was the repo - good to know that this is still used
[16:30] <longsleep> ogra_: yeah so what needs to happen to get probert updated eventually is the question
[16:30] <ogra_> yeah, sadly it is ... i'll work my way throuhg SRUs the next weeks
[16:31] <ogra_> technically all these packages need SRUing
[16:31] <ogra_> longsleep, you either catch mwhudson or cyphermox to upload a new version to that PPA
[16:32] <longsleep> ogra_: ok - great  thanks!
[16:33] <ogra_> longsleep, if you dont get any answers before EOW, ping me again and we can see what to do (i would just upload a fixed package but i dont want to break any processes the guys have in place)
[16:34] <longsleep> ogra_: yeah no hurry - i can wait until they have time
[16:38] <mup> PR snapd#2555 opened: many: implement 'snap aliases' <Created by pedronis> <https://github.com/snapcore/snapd/pull/2555>
[17:04] <mup> PR snapd#2556 opened: interface/builtin: drop the obsolete checks in udisks2 SanitizeSlot <Created by pedronis> <https://github.com/snapcore/snapd/pull/2556>
[17:06] <mup> PR snapcraft#989 closed: pluginhandler: add support for disabling system library migration <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/989>
[17:23] <elopio> ev_: I heard you can help me with my rocket chat account. I can't log in.
[17:23] <ev_> elopio: hey! sorry for not getting back to you on Telegram
[17:23] <ev_> I’m not actually an admin on RocketChat
[17:23] <elopio> ev_: Also, I'll have a meeting with shadow tomorrow at 14:30 UTC. What to join us?
[17:24] <ev_> no idea who keeps pointing people in my direction
[17:24] <elopio> ev_: ^_^
[17:24] <ev_> shadow> yes please!
[17:24] <elopio> sabdfl: do you know who is admin in rocket chat?
[17:34]  * ogra_ gives up for the day ... this extrausers group stuff makes my brain hurt ... 
[17:35] <ogra_> (but we'll eventually have lxd working on core images at least ... )
[17:51] <kyrofa> elopio, in our snaps tests, are we using the ubuntu-core snap or the core snap?
[17:51] <kyrofa> (i.e. is it a clean install)?
[17:53] <mup> Issue snapd#2557 opened: Serial Port Plug/Interface issue with Ubuntu-core 16.04 <Created by mrsinghgit> <https://github.com/snapcore/snapd/issue/2557>
[17:55] <ogra_> hopefully the latter
[18:01] <elopio> kyrofa: it is a clean install. But sergiusens forced one test to install core if it wasn't installed before.
[18:01] <kyrofa> elopio, ah! Excellent
[18:06] <Cust0sLimen> hi
[18:06] <Cust0sLimen> how poorly will snappy work with firewalld ?
[18:08] <kyrofa> Cust0sLimen, I expect it just needs to be properly packaged with the right interfaces
[18:08] <Cust0sLimen> kyrofa, well ... let me put it like this rather ... if I use firewalld on ubuntu ... will snappy stop working ?
[18:09] <kyrofa> Cust0sLimen, ah, indeed I misunderstood the question
[18:09] <kyrofa> Cust0sLimen, I don't see why that would interfere with snappy. What makes you suspect that it will?
[18:10] <Cust0sLimen> so there is this: http://snapcraft.io/docs/reference/interfaces - "firewall-control - Can configure network firewalling giving privileged access to networking."
[18:11] <kyrofa> Yeah, if you have a snap installed that utilizes that interface you might run into issues
[18:11] <Cust0sLimen> kyrofa, :/
[18:11] <kyrofa> Cust0sLimen, run `snap interfaces` to check that
[18:11] <kyrofa> Cust0sLimen, it would be like having both ufw and firewalld installed
[18:11] <Cust0sLimen> why could ubuntu not just be fedora without stupid rules that result in not having ffmpeg ;(
[18:12] <Cust0sLimen> kyrofa, I have no snaps at the moment
[18:12] <Cust0sLimen> just pessimistic
[18:12] <kyrofa> Cust0sLimen, then you should have no issues
[18:12] <Cust0sLimen> kyrofa, I might have some installed later though
[18:12] <kyrofa> Cust0sLimen, just don't install a firewall snap then, and you should be fine
[18:30] <jdstrand> Cust0sLimen: the firewall-control interface you referenced in the documentation is something that a snap may request, not what snappy necessarily controls. in other words, if your system uses firewalld, you'll have no problems with snappy. if you install the ufw or some other firewall snap and use it, they might conflict with each
[18:30] <jdstrand> other
[18:30] <jdstrand> Cust0sLimen: this is no different than trying to install two different firewall applications via rpm and eb and using them at the same time
[18:30] <jdstrand> s/and eb/or deb/
[18:31] <jdstrand> Cust0sLimen: so, basically, what kyrofa said: if you don't install a firewall snap, you should have no issues
[18:32] <jdstrand> roadmr: hi! can you pull r814? it adds 'aliases' support to the review tools among other things
[19:03] <roadmr> jdstrand: sure thing
[19:03] <roadmr> jdstrand: (happy new year :)
[19:04] <jdstrand> roadmr: thanks! and happy new year to you too :)
[19:45] <wswartz> Hello.  I was wondering if anyone knew what the various flavors (Gnome, KDE, etc) were planning to also be Snap-based?
[19:58] <mup> PR snapd#2556 closed: interface/builtin: drop the obsolete checks in udisks2 SanitizeSlot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2556>
[20:11] <mwhudson> longsleep: hi
[20:11] <longsleep> mwhudson: hey
[20:12] <mwhudson> longsleep: you want a probert upload?
[20:13] <longsleep> mwhudson: yeah would be awesome to have probert with the wifi stuff try/except change in edge asap
[20:13] <mwhudson> alright
[20:13] <longsleep> mwhudson: i still do not know why it fails with my kernel though as my test code works just fine in classic ubuntu
[20:14] <longsleep> mwhudson: but the try/except fix would unblock me to hopefully get a working edge image for further testing
[20:14] <mwhudson> longsleep: with the same kernel?
[20:14] <mwhudson> that is pretty odd
[20:14] <mwhudson> longsleep: does your board actually have wifi?
[20:14] <longsleep> mwhudson: yes, different builds though
[20:14] <longsleep> mwhudson: yes board has wifi / iw works just fine as well
[20:15] <mwhudson> longsleep: how odd
[20:15] <mwhudson> anyway, i'll get the fix uploaded
[20:15] <longsleep> mwhudson: did you see my test program - maybe you can spot a difference - or probert runs in some confinment when started on snappy boot
[20:17] <longsleep> mwhudson: awesome - most appreciated thanks
[20:18] <longsleep> mwhudson: btw if i might suggest an improvement to https://github.com/CanonicalLtd/probert/commit/09c449104c15f7c4518eff77055d70af08bcc42a#commitcomment-20335990 - it should say that it cannot start the nl80211 listener instead of just the listener imho
[20:19] <mwhudson> it says wlan_listener?>
[20:20] <longsleep> ah right, wouldnt be nl80211 wlan_listener better? After all there is also the rtnetlink wlan listener?
[20:20] <mwhudson> there's nothing wlan about the rt listener
[20:20] <longsleep> oh
[20:20] <mwhudson> i agree it's a bit obscure
[20:20] <longsleep> right - then i guess its just my misunderstanding
[20:24] <mup> PR snapcraft#1025 opened: project loader: better error message for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1025>
[20:28] <mwhudson> longsleep: uploaded, should be in the next edge build
[20:28] <longsleep> mwhudson: very nice thank you!
[20:28] <longsleep> mwhudson: i just rebuilt probert from source on classic ubuntu on that kernel to see if i can reproduce the original issue there
[20:29] <mwhudson> longsleep: that would be interesting
[20:30] <mwhudson> longsleep: you can just run python3 probert/network.py
[20:30] <mwhudson> (after python3 setup.py build_ext -i)
[20:30] <longsleep> mwhudson: yeah on it, need some extra python modules installed first
[20:33] <longsleep> mwhudson: what do you make of this http://paste.ubuntu.com/23741215/ ?
[20:33] <mwhudson> longsleep: well that's interesting
[20:34] <longsleep> mwhudson: thats not the same error as when run through subiquity though
[20:34] <mwhudson> yeah
[20:34] <mwhudson> pretty odd though, is the device actually up already?
[20:35] <longsleep> mwhudson: ifconfig shows wlan0 and wlan1 it as up yes
[20:36] <mwhudson> longsleep: can you hack network.py:435 to print link.flags?
[20:36] <longsleep> mwhudson: sure hold on
[20:36] <mwhudson> it shouldn't be trying to up the device if it's already UP
[20:37] <mwhudson> um i guess printing ifindex would be useful too
[20:37] <longsleep> mwhudson: mhm magic print makes it work - no error this time
[20:38] <longsleep> let me down it again
[20:38] <mwhudson> hah uh maybe some kind of race maybe
[20:38] <mwhudson> longsleep: wait, you have two wifi devices? i haven't tried it in that situation, maybe there is some confusion
[20:38] <longsleep> ah yeah if its down before
[20:38] <mwhudson> shouldn't be but who knows
[20:38] <longsleep> yeah two
[20:38] <longsleep> that driver creates two interfaces for a single card
[20:38] <mwhudson> oh right
[20:39] <longsleep> mwhudson: xxx (5, 1)
[20:39] <mwhudson> so i bet when you up one, the other gets implicitly upped too
[20:39] <longsleep> 5 is the index and 1 is the flags
[20:39] <longsleep> mwhudson: ah yeah thats true
[20:39] <longsleep> mwhudson: i usually disable the second device in interfaces
[20:39] <mwhudson> and probert tries to up both and something complains
[20:39]  * mwhudson waves hands
[20:40] <mwhudson> longsleep: wait what, the flags are 1 for the call that crashes?
[20:41] <longsleep> mwhudson:  yes - full output at http://paste.ubuntu.com/23741260/
[20:41] <longsleep> mwhudson: if i run it again without downing the interfaces first, no error
[20:42]  * mwhudson tries to remember how to find out what -16 means
[20:43] <mwhudson> longsleep: can you pastebin git diff, to be sure?
[20:43] <mwhudson> oh
[20:43] <mwhudson> #define NLE_SEQ_MISMATCH	16
[20:43] <longsleep> +                print("xxx", (ifindex, IFF_UP))
[20:43] <mwhudson> longsleep: oh
[20:43] <mwhudson> longsleep: link.flags, not IFF_UP :)
[20:43] <longsleep> err sorry
[20:45] <longsleep> mwhudson: link.flags is 4098 for both errors
[20:45] <mwhudson> longsleep: thanks
[20:45] <longsleep> mwhudson: http://paste.ubuntu.com/23741285/
[20:46] <mwhudson> longsleep: but anyway, the wlan_listener is starting ok?
[20:47] <mwhudson> eh it must be
[20:47] <longsleep> mwhudson: well no other error and it shows a bunch of networkinfo objects
[20:47] <mwhudson> longsleep: and the interfaces are up after you run probert?
[20:47] <longsleep> mwhudson: yes
[20:47] <mwhudson> then i don't know what is going on but it seems harmless
[20:48] <longsleep> mwhudson: xxx wlan_listener started (<_nl80211.listener object at 0x7fa91f3b88>,)
[20:48] <mwhudson> longsleep: cool
[20:49] <mwhudson> if still mysterious why it doesn't work with snappy
[20:49] <longsleep> mwhudson: ok, but it confirms that wlan listener starts fine on classic ubuntu, same kernel except that one is manual build and the other is built by snapcraft
[20:51] <longsleep> mwhudson: fyi - kernel snap is built with this https://github.com/longsleep/build-pine64-image/blob/master/snappy/kernel/snapcraft.yaml
[20:51] <longsleep> mwhudson: and the classic kernel is also built only with sun50iw1p1smp_linux_defconfig config
[20:55] <mwhudson> longsleep: can you do this: http://paste.ubuntu.com/23741362/ re-down the interfaces and run network.py again?
[20:55] <mwhudson> uh after running build_ext -i
[20:55] <mwhudson> pastebin the output, there will be a lot of it
[20:55] <longsleep> mwhudson: sure hold on
[20:56] <longsleep> oh wow thats a lot of output
[20:58]  * longsleep installs pastebinit
[20:59] <longsleep> mwhudson: http://paste.ubuntu.com/23741380/
[21:09] <mup> PR snapcraft#1010 closed: meta: add 'desktop' entry for apps <Created by oSoMoN> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1010>
[21:31] <cliftonts> Evening everybody
[21:34] <cliftonts> I'm having an issue packaging up a python script, is there anybody here who might be able to point out where I'm going wrong?
[21:34] <kyrofa> cliftonts, sure! What's up?
[21:35] <cliftonts> Initially it was building but the installed snap was saying it couldn't find python
[21:35] <kyrofa> cliftonts, which plugin were you using?
[21:35] <cliftonts> Mark Shuttleworth suggested I change the python location stated in the script, now it just loads the python interpreter.
[21:36] <cliftonts> my snapcraft.yaml is here: http://paste.ubuntu.com/23741430/
[21:36] <kyrofa> cliftonts, the python plugin pulls in python2-- is that the one you want?
[21:37] <cliftonts> My script will work with either 2 or 3
[21:37] <kyrofa> cliftonts, ah, but you have no setup.py or anything
[21:37] <cliftonts> for what purpose?
[21:38] <kyrofa> cliftonts, to tell snapcraft (or users, for that matter) about your project's dependencies and where it should be installed
[21:38] <kyrofa> cliftonts, I'm referring to the RokuTerm project itself
[21:38] <kyrofa> We still might be able to get this to work, hold on a sec
[21:39] <cliftonts> I am not the most experienced at this. I've never been able to package an app. Tried with deb for 2 years and gave up!
[21:39] <cliftonts> So please forgive me if I'm doing things in an odd way.
[21:39] <kyrofa> cliftonts, that's alright, you're just about there :)
[21:40] <cliftonts> It's one of those things that's impossible until you've done it once I think.
[21:42] <kyrofa> cliftonts, I'm playing with it for a minute, hold on
[21:42] <cliftonts> kyrofa - rokuterm is a sort of prototype program, mostly not finished, mostly patched together and just there to iron out some kinks in the design which will be transferred to a new project later. It seemed appropriate to experiment with packaging on an experiment.
[21:43] <cliftonts> I would be keen to learn how one of these setup.pys would work though.
[21:45] <kyrofa> cliftonts, it's a python packaging thing. This might prove a good starting point: https://stackoverflow.com/questions/1471994/what-is-setup-py
[21:45] <cliftonts> Ok, thanks
[21:45] <kyrofa> cliftonts, but you probably don't need it for this
[21:45] <cliftonts> I was about to say, the snap handles all of that anyway, right?
[21:46] <kyrofa> I'll explain in a second
[21:46] <kyrofa> cliftonts, well, you still have to tell snapcraft what to put in the snap
[21:46] <kyrofa> cliftonts, the `dump` plugin just puts EVERYTHING in its `source` into the snap (unless files are filtered out)
[21:46] <cliftonts> Yes, but once I've got it actually loading the script I can then worry about dependancies and permissions.
[21:47] <kyrofa> cliftonts, the make plugin doesn't-- it runs `make` and `make install`
[21:47] <kyrofa> cliftonts, i.e. if you didn't have a Makefile, the `make` plugin wouldn't know what to install. Does that make sense?
[21:47] <kyrofa> The python plugins are the same way
[21:48] <kyrofa> cliftonts, but we can get around that by telling it exactly what to do
[21:48] <cliftonts> kyrofa - I see, I have simply been following the demo for the python3 snap, trying to change as little as possible. But to be honest that didn't seem to work for me either.
[21:48] <kyrofa> cliftonts, the python3 demo pulls in https://github.com/markokr/spongeshaker, which has a setup.py
[21:49] <cliftonts> kyrofa - I will browse further. The problem with coming in with zero knowledge is you can so easily overlook the obvious.
[21:50] <kyrofa> cliftonts, alright, quick question:
[21:51] <kyrofa> cliftonts, rokuterm.py is supplied by two things, it seems: the github project and alongside the snapcraft.yaml
[21:51] <kyrofa> cliftonts, can you explain that? Do you actually want both of them?
[21:52] <cliftonts> kyrofa - No, as I previously stated that is pretty much a carbon copy of the spongeshaker yaml. Make it go, then figure out why it goes. I had no idea what was removable, yet.
[21:52] <kyrofa> cliftonts, ah, I see. So that github project should work standalone?
[21:52] <cliftonts> Download it to your desktop and run the py, it'll just work.
[21:53] <kyrofa> No dependencies other than python2 or 3?
[21:53] <kyrofa> (Note that the py is not executable)
[21:54] <cliftonts> kyrofa - Only a number of python modules. I debated with myself whether it would be frowned upon to have it set as executable as standard.
[21:55] <kyrofa> cliftonts, default python modules, or pypi?
[21:56] <cliftonts> requests, urllib, sys, time, os, urllib2
[21:56] <kyrofa> Alright, sounds standard. Does this work better? http://pastebin.ubuntu.com/23741636/
[21:57] <kyrofa> I made a few changes. First of all, got rid of the extra dump usage
[21:57] <kyrofa> Second, I noticed the script uses `env python` so I used python2 instead of python3
[21:57] <kyrofa> Third, I had to tell snapcraft how to install the script, due to the lack of a setup.py that tells that to snapcraft for you
[21:58] <kyrofa> It's just a simple "make a bin folder, copy it into the bin folder, make it executable"
[21:59] <kyrofa> cliftonts, does that make sense?
[21:59] <cliftonts> Sounds good
[22:01] <cliftonts> kyrofa - Trying now
[22:02] <kyrofa> cliftonts, looks like you use requests
[22:02] <kyrofa> Oh, you said so. Not standard, missed that
[22:02] <cliftonts> kyrofa - I will work on creating the setup.py next then. Easier now I have a starting point
[22:02] <cliftonts> Requests if python 3
[22:03] <cliftonts> Oh no sorry, I use th requests module yes.
[22:04] <kyrofa> cliftonts, alright, this works: http://pastebin.ubuntu.com/23741673/
[22:04] <cliftonts> kyrofa - Excellent! I now get an error stating no module named requests so that's one problem fixed, one created. Progress!!
[22:05] <kyrofa> cliftonts, it doesn't work though-- it's trying the wrong subnet for me. But that should get you closer :)
[22:05] <kyrofa> At least it builds correctly now
[22:05] <cliftonts> kyrofa - As I said it is experimental, one of the next stages is to get network scanning working correctly. But you can specify the IP manually anyway.#
[22:06] <kyrofa> How? I have a roku
[22:06] <cliftonts> kyrofa - rokuterm 192.168.blah, blah
[22:07] <gb__> kyrofa ive been searching for a solution to my snap/nextcloud question.  I have I installed the ownbackup plugin but it doesnt seem to run.  What would you recommend as a backup solution?  I found on reddit that your the goto guy and worked on the snap package.
[22:08] <cliftonts> kyrofa - Brilliant. It works but of course it is contained so can't access the network. I haven't read up on that yet.
[22:09] <kyrofa> cliftonts, excellent, a little homework then!
[22:10] <kyrofa> gb__, we've been talking about that actually
[22:10] <cliftonts> kyrofa - Feel free to download and play with it. The aim is to re-create it using a graphivcal interface once all the features work.
[22:10] <kyrofa> gb__, can you explain what you're trying to backup and why?
[22:10] <kyrofa> cliftonts, already done ;)
[22:11] <kyrofa> cliftonts, nice job by the way
[22:11] <kyrofa> cliftonts, it would probably be helpful if you brought your mailing list thread to a close, by the way
[22:11] <kyrofa> To others, I mean
[22:11] <cliftonts> kyrofa - It's not that impressive, I've simply reverse engineered the code for uroku for ubuntu touch.
[22:12] <gb__> kyrofa all i wanted to do was backup the data so if i loose the boot disk on my server i can restore everything
[22:12] <kyrofa> gb__, so you want _everything_, including the data?
[22:12] <kyrofa> gb__, how often do you want to capture such a backup?
[22:12] <gb__> kyrofa thats what i was thinking of yes
[22:13] <gb__> kyrofa, just once a week its only a home server
[22:14] <cliftonts> kyrofa - Thanks for your help. More progress in 24 hours than the last 2 years!
[22:15] <kyrofa> gb__, that's all I have to, but that's still a few hundred GBs per backup if you include the data. Where do you intend on putting them? (not trying to attack by the way, it's just helpful having a use-case to poke at)
[22:15] <kyrofa> cliftonts, any time!
[22:15] <mup> PR snapcraft#1025 closed: project loader: better error message for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1025>
[22:15] <kyrofa> gb__, and how many do you intend on keeping?
[22:15] <cliftonts> I'm off to try and find something to watch on the bottomless pit that is roku. Night!
[22:16] <gb__> kyrofa i have a zfs array on the server to backup too
[22:18] <mup> PR snapcraft#984 closed: parser: improve output <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/984>
[22:18] <kyrofa> gb__, okay. So currently, you can totally just slurp the entire /var/snap/nextcloud/current directory
[22:18] <kyrofa> As well as the /var/snap/nextcloud/common directory (which holds the raw data)
[22:19] <kyrofa> To restore, just install the snap and copy stuff over the top
[22:19] <kyrofa> gb__, but we're working on making a nicer export/import
[22:20] <kyrofa> gb__, but unlike just Nextcloud, we have other things to think about. SSL keys, etc
[22:21] <kyrofa> gb__, so: do you find yourself caring about the raw data, the database, the nextcloud config, the extra stuff like SSL keys, or everything in one big dump?
[22:23] <kyrofa> gb__, note that the discussion to which I refer is happening here: https://github.com/nextcloud/nextcloud-snap/issues/126
[22:24] <gb__> kyrofa thinking about it if i backup just the data i could always copy it back
[22:26] <kyrofa> gb__, yeah just backup /var/snap/nextcloud/common, then. If you need to restore, just put the files back in there and Nextcloud will pick them up
[22:26] <kyrofa> gb__, but we can make that better
[22:26] <kyrofa> It's on the list :)
[22:27] <gb__> kyrofa thanks for your help Ill do that then.  I have a long list of todo's too.  Thanks for your help :)
[22:28] <kyrofa> gb__, any time!
[22:28] <kyrofa> gb__, thanks for letting me pick your brain. Feel free to join in that conversation on the bug
[22:29] <gb__> kyrofa will do!
[23:04] <mwhudson> longsleep: sorry for the delay, that doesn't really make much sense to me though :(