[01:49] <mup> PR core#48 closed: add support for `snap set core proxy.{http,https,ftp,all}` <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/core/pull/48>
[03:50] <mup> PR snapd#3680 opened: tests: fix failover test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3680>
[04:18] <mup> Bug #1693016 changed: snap install conjure-up fails if juju snap installed <Snappy:Expired> <https://launchpad.net/bugs/1693016>
[04:56] <mup> PR snapd#3624 closed: interfaces/builtin: rework for avahi interface <Created by kubiko> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3624>
[06:35] <zyga-suse> good morning
[06:41] <mvo> hey zyga-suse!
[06:42] <mup> PR snapd#3678 closed: Merge pull request #3525 from jdstrand/password-manager-service <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3678>
[06:42] <zyga-suse> hey, how are you feeling? I finally feel like I had a good nights sleep
[06:43] <zyga-suse> (woke up at 6 and started cleaning the house and reading about taxes)
[06:43] <mup> PR snapd#3676 closed: interfaces/many, cmd/snap-confine: miscellaneous policy updates (#3634) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3676>
[06:44] <mvo> zyga-suse: I had a good night as well, feeling good. some interessting results from the debian issue, I updated the forum topic
[06:44] <zyga-suse> oh, let me look
[06:44] <mvo> zyga-suse: no idea yet how to fix things but I think the understanding is much higher now
[06:44] <mvo> (and its a bi*** to debug) :(
[06:45] <mvo> e.g. strace -f does not follow all forked, even if I give all the LWP pids
[06:45] <mvo> zyga-suse: I still have no idea *what* syscall is delivering the sigsys, I suspect its bind but its hard to say
[06:46] <mvo> (for certain)
[06:46] <zyga-suse> strace doens't work with golang
[06:47] <zyga-suse> the signal delivered is not SIGSYS, it is SIGKILL IMO
[06:47] <mvo> zyga-suse: check "man 2 seccomp" and search for SECCOMP_RET_KILL :)
[06:48] <mvo> zyga-suse: anyway, details, I think it comes down to that our generated seccomp profiles does not have the "bindSyscallWorkaround" for unknown reasons
[06:53] <zyga-suse> oh
[06:53] <mvo> zyga-suse: do you remember if/where we did "devmode: true" on devmode distros in 2.21 in snap-setup?
[06:53] <zyga-suse> interesting
[06:53] <mvo> zyga-suse: I remember us fixing things around this but I forgot the details :/
[06:53] <zyga-suse> we had a bug where devmode distro vs devmode snap were confused
[06:53] <zyga-suse> and then we changed core to not be devmode (flag of the snap)
[06:54] <zyga-suse> but this should *not* override the devmode distro fact
[06:57] <mvo> zyga-suse: I updated the post and made it a wiki, hopefully it now explain what is going on
[06:57] <zyga-suse> mvo: question: do you think we can fix this by not at all running configure hook in such a scenario?
[06:58] <zyga-suse> aha
[06:58] <zyga-suse> very interesting
[06:58] <zyga-suse> fantastic forensics mvo :)
[06:58] <mvo> zyga-suse: I would prefer to not use seccomp on devmode distros ;) but we had this argument before and I will shut up :)
[07:03] <mvo> zyga-suse: anyway, I keep digging, thanks for your reviews of the security work from jamie! I hope this won't be a conflicts nightmare once I merge back
[07:03] <zyga-suse> I'm sure it will be fine
[07:03] <zyga-suse> I think there are two more
[07:03] <zyga-suse> I'm doing reviews now
[07:03] <mup> PR snapd#3680 closed: tests: fix failover test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3680>
[07:04] <mvo> zyga-suse: great, thank you!
[07:04] <zyga-suse> ah, no, that's all I think
[07:04] <zyga-suse> I will propose a lot of interface PRs this week
[07:04] <zyga-suse> mvo: and one more sleeping/happiness observation
[07:05] <zyga-suse> I need to wake up at 4-5AM, this is when the sun raises and this is when I should start my day, I suspect my insistince of waking up at a fixed time after moving so far east is why I felt so tired all the time
[07:07] <mvo> zyga-suse: woah, 4-5am is pretty early
[07:09] <zyga-suse> I often wake up at 5 and then force myself to go to sleep just because I'm so tired after staying up past 2AM
[07:09] <zyga-suse> and I wake up simply because it's 100% bright already :)
[07:09] <gary-wzl> zyga-suse: :)
[07:09] <gary-wzl> zyga-suse: Hey, I saw you finished converting broadcom-asic-control to commonInterface.
[07:09] <gary-wzl> Thanks!
[07:10] <gary-wzl> not sure if you started working on others interfaces.
[07:10] <zyga-suse> gary-wzl: yes, I also merged that back into your branch (or at least locally, not sure if I pushed ^_^)
[07:10] <gary-wzl> I have something done in udev_tagging branch so I know there're still a bunch of interfaces need to be converted though.
[07:10] <zyga-suse> yes, I'm working on two more
[07:10] <gary-wzl> Okay,
[07:10] <zyga-suse> gary-wzl: I think I must have pushed it because your diff shrank by ~50 lines
[07:10] <gary-wzl> Yes
[07:11] <zyga-suse> gary-wzl: you can iterate on the branch I think
[07:11] <gary-wzl> I was thinking I might as well take a look at the rest and create a feature branch interface by interface
[07:11] <gary-wzl> Just like you did
[07:11] <zyga-suse> aha
[07:11] <zyga-suse> yes, please do!
[07:11] <gary-wzl> Then you can help on code review. And I'll merge it back into my PR.
[07:11] <zyga-suse> just two notes
[07:11] <gary-wzl> yes?
[07:11] <zyga-suse> I'm starting from A and go twards Z
[07:11] <zyga-suse> you can start from the other end
[07:11] <zyga-suse> so we don't conflict
[07:12] <zyga-suse> and I think we want to expand common interface more
[07:12] <gary-wzl> no problem:)
[07:12] <zyga-suse> as I noticed a lot of interfaces use permanent slot snippets
[07:12] <zyga-suse> I started that already, I'll have a PR after my batch of morning reviews
[07:12] <gary-wzl> puselaudio, modem_manager... I guess
[07:12] <zyga-suse> with that we can attack the next set of interfaces and convert them to common
[07:12] <gary-wzl> yep
[07:14] <mvo> zyga-suse: ok, I think its now all understood, the problem is that 2.26 (which is stable) has no bindSyscallWorkaround yet :) but 2.27 has, so the next stable release will fix it
[07:15] <zyga-suse> WHAT?!
[07:15] <zyga-suse> man
[07:15] <zyga-suse> so all the good stuff that I associate with "fixed in the next release"
[07:15] <zyga-suse> all of that is in 2.27?
[07:16] <zyga-suse> mvo: I think we need to recognize important bugfixes and tag them to backport
[07:37] <mup> PR snapd#3681 opened: interfaces: convert time-control to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3681>
[07:38] <zyga-suse> gary-wzl: +!
[07:38] <zyga-suse> +1 :)
[07:42] <pstolowski> mvo, hey, re yesterday's issue with upgrade/basic test failure - should we consider any +git... version to be newer than whatever is in the core? in this case we re-exec from 2.26.9+git1194.g7d0e792 into 2.26.14; version number is higher, but that version doesn't understand install hook tasks
[07:45] <mvo> pstolowski: I think we "just" need to make sure our versioning is not messed up, let me check what is going on
[07:46] <mvo> pstolowski: I think things slipped a bit because of the various vacations
[07:46]  * mvo looks
[07:50] <mvo> pstolowski: do you have the url with the failure log at hand?
[07:50] <mup> PR snapd#3682 opened: interfaces: convert ppp to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3682>
[07:51] <pstolowski> mvo, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170804_173931_89d2f@/log.gz
[07:53] <mvo> ta
[07:57] <mup> PR snapd#3683 opened: interfaces: convert physical_memory_control to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3683>
[08:05] <zyga-suse> gary-wzl: all +1
[08:06] <mup> PR snapd#3684 opened: interfaces: convert physical_memory_observe to common iface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3684>
[08:08] <zyga-suse> more +1s :-)
[08:15] <mup> PR snapd#3685 opened: interfaces: add missing test for optical_drive interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3685>
[08:17] <zyga-suse> gary-wzl: nice work! you're going through them like warm knife through butter :)
[08:17] <gary-wzl> zyga-suse: :PPPP
[08:18] <mup> PR snapd#3681 closed: interfaces: convert time-control to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3681>
[08:18] <zyga-suse> gary-wzl: quick request on that last one
[08:18] <zyga-suse> well
[08:18] <zyga-suse> pre last one, I'm looking at the optical-interface Pr
[08:18] <zyga-suse> can you look at what I did to test suites lately
[08:18] <zyga-suse> especially look at things in avahi-*
[08:18] <gary-wzl> zyga-suse: any interface I can refer to
[08:18] <gary-wzl> Okay, looking
[08:18] <zyga-suse> those two have all the most recently added improvements
[08:18] <zyga-suse> there are minor differences
[08:18] <zyga-suse> I test backend by backend
[08:19] <zyga-suse> TestXXXSpec
[08:19] <zyga-suse> I use a few new helpers
[08:19] <zyga-suse> MockPlug/MockSlot
[08:19] <zyga-suse> little things but it is shorter and, I think, nicer than what most older test did
[08:20] <gary-wzl> zyga-suse: yeah, it makes sense.
[08:21] <zyga-suse> gary-wzl: the naming is also relevant, consumer/producer/ app vs app1, other or other things that (I myself) wrote earlier, this makes it easier to reason about tests
[08:21] <zyga-suse> as hopefully all the interfaces will have similar behaving tests and features
[08:22] <gary-wzl> zyga-suse: exactly.
[08:50] <mup> PR snapd#3682 closed: interfaces: convert ppp to common iface <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3682>
[09:02] <zyga-suse> mvo: do we need to backport store URL changes?
[09:03] <mvo> zyga-suse: I think not
[09:03] <om26er> I am not able to setup a RPi3 using wifi, works fine with ethernet. Something broken ?
[09:06] <pedronis> zyga-suse: for obvious reasons the old urls still work
[09:06] <pedronis> (it woulb be bad (tm) if they didn't )
[09:06] <ogra_> om26er, works fibne here (with the edge images)
[09:06] <ogra_> stable wont work, but you know that (we talked about it before)
[09:07] <zyga-suse> is chipaca around today?
[09:07] <om26er> ogra_: that would be someone else ;) today is my first day with a RPi3 :)
[09:08] <pedronis> mvo: hi, what's the vague plan for when to cut 2.28 atm ?
[09:09] <om26er> oh, I have a 5" screen as well, now need to get mir working on it.
[09:10] <om26er> ogra_: when will UbuntuCore migrate to later versions of Ubuntu ?
[09:11] <ogra_> om26er, well, the edge images work, once the next stable release happens, stable will have the fix too
[09:12] <zyga-suse> om26er: ubuntu core won't need to as we are working on base snaps that will elimitate the "flag day" transitions mostly
[09:12] <zyga-suse> om26er: so soon you will be able to use, say 18.04 base alongside 16.04 base
[09:12] <zyga-suse> om26er: at the same time, at runtime, on one device
[09:12] <ogra_> if yuo want to config stable ruight now, use wired, reboot, ssh into the board via wired, run sudo console-config, deconfigure eth0 and configure wlan ...
[09:12] <om26er> zyga-suse: one distro to rule them all, eh ?
[09:13] <zyga-suse> om26er: well, one nice way of running software for sure
[09:13] <ogra_> om26er, no, exactly the opposite :)
[09:13] <ogra_> in fact you can have gentoo-base, fedora-base, slackware-base if you want to
[09:14] <ogra_> (and use that with your snaps)
[09:15] <ogra_> we're actually getting rid of the tie to ubuntu with snaps :)
[09:16] <zyga-suse> cachio: another fedora failure on 3684 -- perhaps it is a random ordering factor
[09:16] <zyga-suse> cachio: and interestingly same failure in 3685
[09:17] <ogra_> because they are siblings ?
[09:17] <ogra_> :)
[09:20]  * zyga-suse goes for a small break 
[09:21] <zyga-suse> will resume userd review
[09:21] <zyga-suse> and then go to address review feedback
[09:22] <mup> PR snapd#3686 opened: many: merge release/2.27 branch back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3686>
[09:28] <zyga-suse> holly molly
[09:29] <zyga-suse> 804 lines added in 2.27?!
[09:29] <mup> PR snapd#3683 closed: interfaces: convert physical_memory_control to common iface <Created by adglkh> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3683>
[09:30] <zyga-suse> mvo: small change on 3686
[09:41] <om26er> alan_g: Do you know if these instructions[1] are working on the Pi3 ? I just gave it a try and nothing came up on screen. [1] http://voices.canonical.com/alan.griffiths/2017/01/31/mircade-snap/
[09:43] <alan_g> om26er: I don't have a Pi3, but they were working around that time (see the first comment).
[09:44] <mvo> ogra_: prepare for reboots
[09:44] <alan_g> Saviq: ^ could this be the problem you were looking into yesterday?
[09:44] <ogra_> mvo, yay !
[09:45] <ogra_> mvo, btw, keep an eye on the store uploads, the publishing fails every now and then (probably more important for a release than for the dailies)
[09:45] <Saviq> alan_g: om26er, current edge (no --devmode) mir-libs, mir-kiosk and mir-kiosk-apps (r16) work fine, we didn't try mircade, but the problem we did have was Qt-related, so I doubt mircade would be affected
[09:45] <mvo> ogra_: aha, good to know, thank you
[09:46] <mvo> ogra_: the store was a bit unhappy in general in the last few days, some 504 and timeouts during the tests for example
[09:48] <Saviq> alan_g: so in your instructions, you shouldn't need --devmode or the explicit connect for mir-kiosk any more
[09:48] <om26er> Saviq: so I should just install those three snaps ?
[09:49] <alan_g> Saviq: ack, I'll update
[09:49] <Saviq> om26er: on the Pi, yes, just install mir-libs, mir-kiosk and mir-kiosk-apps and you should get the photoviewer app
[09:49] <mup> PR snapd#3687 opened: Remove redundant apparmor rule for opengl interface and improve the test <Created by adglkh> <https://github.com/snapcore/snapd/pull/3687>
[09:49] <om26er> Saviq: do I need to connect any interfaces after installing ?
[09:49] <Saviq> om26er: they should all autoconnect
[09:49] <Saviq> verify with `snap interfaces` of course
[09:51] <zyga-suse> gary-wzl: reviewed
[09:55] <alan_g> Saviq: updated the blogpost.
[09:56] <Saviq> ack
[09:56] <gary-wzl> zyga-suse: Thanks!
[10:02] <Saviq> alan_g: FWIW, confirmed this works on amd64
[10:02] <alan_g> Saviq: thanks
[10:05] <Chipaca> zyga-suse: the os->core rename pr i had up i closed because it broke spread tests in ways i didn't have a head for at the time
[10:05] <zyga-suse> aha, thank you
[10:05] <zyga-suse> I was just curious and this is a very clear and honest response :)
[10:06] <om26er> Saviq: all interfaces are connected but I still don't get a UI.
[10:07] <om26er> http://paste.ubuntu.com/25269094/
[10:07] <ogra_> om26er, you mean you dont get a black screen with mouse cursor ?
[10:08] <om26er> ogra_: I get that last screen after setup: "Personalize your account at https://login.ubuntu.com"
[10:08] <ogra_> om26er, and thats on an edge/daily image ?
[10:09] <ogra_> stable does not have a gadget that enables graphics
[10:09] <ogra_> (and we can not update gadgets on the pi yet)
[10:09] <om26er> oh
[10:09] <ogra_> same issue as on the pi2
[10:10] <om26er> ogra_: will flash image from edge.
[10:10] <om26er> will that image also contain the RPi GPIO interfaces ?
[10:10] <ogra_> i'd recommend installing from either http://people.canonical.com/~ogra/snappy/all-snaps/daily/ or from http://cdimage.ubuntu.com/ubuntu-core/16/edge/ ... then doing: "snap refresh core --stable" and "snap refresh pi2-kernel --beta"
[10:10] <ogra_> that will give you the latest gadget, a stable kernel and a stable core
[10:11] <om26er> downloading from http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/
[10:11] <ogra_> (the kernel is in lockstep with the gadget, so we can not upgrade it either atm, beta has the latest and most stable here)
[10:13]  * ogra_ takes a break
[10:19] <Chipaca> zyga-suse: in my review of snapd#3636 was it clear that the needsfixing was because of the int vs uint issue?
[10:19] <mup> PR snapd#3636: snap: add support for parsing snap layout section <Created by zyga> <https://github.com/snapcore/snapd/pull/3636>
[10:24] <zyga-suse> Chipaca: yes
[10:24] <zyga-suse> Chipaca: I haven't touched my tree since yesterday
[10:24] <zyga-suse> I'm all in review mode
[10:24] <Chipaca> 'k
[10:41] <zyga-suse> morphis: re-reviewed 3260
[10:41] <zyga-suse> morphis: have a look
[10:41] <zyga-suse> morphis: there are a few tiny things
[10:41] <zyga-suse> morphis: there's nothing major I'd change
[10:41] <zyga-suse> morphis: *except* an improvement for gio-open that we need to do for artful
[10:47]  * zyga-suse is somewhat hungry now
[10:47] <zyga-suse> I'll take a break
[10:47] <zyga-suse> and start updating my PRs
[10:48] <zyga-suse> I still have one review open for pedronis and I will finish it before switching (3616)
[10:48] <zyga-suse> if you need a review and I missed it, please ping me
[11:16] <morphis> zyga-suse: awesome! thanks
[11:33] <ondra> zyga-suse now when it's merged, when can I expect change in snapd to land in edge channel?
[11:34] <ogra_> next edge build usually
[11:34] <ogra_> though the release might be in your way atm
[11:34] <zyga-suse> yep, it needs to auto-build in the ppa
[11:34] <zyga-suse> and then it needs to auto-build in the core snap
[11:34] <ogra_> but we dont have the 2.27 release out yet, do we ?
[11:35] <ogra_> that usually blocks master for a bit
[11:35] <zyga-suse> ondra: thank you for caring about that, if there are any tweaks you want to make before 2.28 is out, please say
[11:35] <zyga-suse> ogra_: I think 2.27 is unlikely
[11:35] <zyga-suse> it won't have this change
[11:35] <ogra_> (since we land the release deb over the master-built deb)
[11:35] <ogra_> zyga-suse, thats not what i meant :)
[11:35] <zyga-suse> aha
[11:35] <ogra_> i mean that we dont do builds from master while releasing
[11:36] <ogra_> (i,e, edge core snaps will have 2.27 until it is released)
[11:36] <ogra_> (and only then 2.xxxgitxxx again)
[11:37] <zyga-suse> oh, I wasn't aware of that
[11:37] <ondra> zyga-suse no I don't need changes, unless something is broken, but just wanted to run more tests once it lands in edge
[11:39] <ogra_> zyga-suse, you pushed snapd to the image ppa yourself in the past (which overrides the edge ppa that builds the deb from master) ... so you should know ;)
[11:40] <zyga-suse> yeah I just don't do releases *that* often to remember this
[11:41] <ogra_> :)
[11:58] <popey> Chipaca: we have a developer who has registered and uploaded snap-foo in the store, and we'd like them to be using foo, is it possible to just rename, or should we get them to re-register foo, and forget snap-foo?
[11:59] <popey> Chipaca: note, nobody has yet downloaded snap-foo, we're just trying to make this smooth for a new person
[11:59] <Chipaca> popey: that's a question for people with their mits in the store backend, which isn't me
[11:59] <Chipaca> popey: maybe noise][ or nessita
[11:59] <popey> oh, okay. my bad. sorry.
[12:00] <popey> I'll wait for them to reply, thanks.
[12:01] <popey> zyga-suse: pinged you a question on telegram, is it better in pm here? (it's a private matte)
[12:01] <popey> *matter
[12:02] <zyga-suse> one sec
[12:02] <zyga-suse> popey: can you please ping zyga_es
[12:03] <zyga-suse> ahhh
[12:03] <zyga-suse> wait
[12:03] <zyga-suse> zyga_pl
[12:03] <ogra_> es ? ... is he home ?
[12:03] <zyga-suse> darn 2 accounts
[12:03] <ogra_> :P
[12:03] <zyga-suse> or just here
[12:03] <popey> ok
[12:03] <cachio> mvo, hey
[12:04] <popey> zyga-suse: sent pm
[12:04] <mvo> cachio: good morning!
[12:04] <cachio> mvo, new rc8?
[12:05] <mvo> cachio: yes, sorry for that, hopefully the last one, so far my tests in VMs look promising, updating the sheet as I go
[12:05] <mvo> cachio: scenario refresh core from stable is currently running on amd64
[12:05] <cachio> mvo, ok, the failover one is fixed too
[12:05] <cachio> mvo, it is a test error
[12:06] <mvo> cachio: yeah, thanks for chasing this!
[12:06] <cachio> mvo, I am going to buy new sd cards
[12:06] <cachio> now
[12:06] <cachio> mvo, the one that I was using for pi3 is not working properly
[12:06] <mvo> cachio: \o/
[12:06] <mvo> cachio: I had hoped it might be a flakky sd card
[12:07] <cachio> mvo, yes
[12:08] <ogra_> ah, i was about to ask how that worked out :)
[12:09] <cachio> ogra_, I discarded the one that we talked the other day
[12:09] <ogra_> yeah
[12:10] <cachio> ogra_, the problem is that another one is also with problems
[12:10] <ogra_> sigh ...
[12:10] <ogra_> i only have one like that ...
[12:10] <cachio> ogra_, and those are pretty new
[12:10] <ogra_> (but that fails reliable)
[12:10] <cachio> always on the reboots
[12:10] <cachio> the same problem
[12:11] <ogra_> well, resize and the uboot resetting of the sdhc controller
[12:11] <nessita> popey, hi! renames are not supported at this time (it needs work on backend and client)
[12:11] <ogra_> thats the two issues i see with the broken card ... once one of them shows up, once the other
[12:11] <ogra_> but i never reproduced it with a second card (and never heard from federico that he hits such an issue)
[12:12] <popey> nessita: ah, okay. that nails that. thank you!
[12:12] <cachio> ogra_,  yes, really bad luck
[12:12] <ogra_> yeah
[12:13] <popey> nessita: I'm asking if you can do it, not if the user can
[12:16] <popey> nessita: specifically I have a snap - snap-ruby, which we'd like renamed to ruby
[12:16] <ogra_> popey, if it has never been downloaded the user can delete the old one himself and just re-upload under the new name
[12:17] <popey> sure, they can. we're just trying to make it easier for them.
[12:17] <ogra_> (but i know that wasnt what you asked :) )
[12:22] <nessita> popey, no, sorry, I can't do it either, the name is inside the yaml and we can't edit and rebuild that
[12:23] <nessita> popey, until we work on renames, we have some restrictions where the snap name has to match the yaml name
[12:26] <popey> nessita: i have a PR to update the upstream snap to change the name, so the goal was that you guys change the name in the store, he changes the name in his yaml, rebuilds, and gets the new snap
[12:27] <nessita> popey, he will need a new snap-id, so he needs to re-register and do all the dance
[12:28] <nessita> popey, I can't edit assertions and re sign them (to edit the name in the existing declaration)
[12:31] <zyga-suse> Pharaoh_Atem: hey
[12:31] <zyga-suse> Pharaoh_Atem: I have two questions
[12:31] <zyga-suse> Pharaoh_Atem: could we consider updating snapd to 2.26.14 please?
[12:32] <zyga-suse> Pharaoh_Atem: and related to that, can we consider getting rid of the separate snap-confine package
[12:36] <om26er> ogra_: is NanoPi Neo going to be a supported platform ? Need to know before I order a bunch of them.
[12:37] <ogra_> om26er, i dont think so ... beyond me supporting it in my spare time ...
[12:37] <ogra_> if you can live with that level of support, go for it :)
[12:37] <ogra_> else, you caan indeed make a contract with canonical to have it fully supported ;)
[12:38] <ogra_> or hope that the manufacturer does it at some point
[12:38] <om26er> haha!
[12:38] <om26er> seems the manufacturer actually advertises UbuntuCore support
[12:39] <ogra_> no, they advertise some broken self hacked tarball release they call ubuntu core
[12:39] <ogra_> it is actually a classic install manually buit using debootstrap as i understand
[12:39] <ogra_> at least the images they offter
[12:39] <ogra_> *offer
[12:39] <ogra_> ... on their site ... for download
[12:41] <ogra_> i doubt they would even be able to run snapd
[12:41] <om26er> RPi is fine but goes a little out of budget if you have to create a mesh of 5-10 of them.
[12:41] <ogra_> did you consider the orangepi ?
[12:42] <ogra_> that has actually a chance to eventually get full ubuntu-core from the manufacturer
[12:42] <om26er> ogra_: there is a wifi variant of the board, did you play with that as well ? NanoPi Neo Air
[12:42]  * om26er looks into orangepi
[12:42] <ogra_> om26er, no, i have a remote controlled popey doing that for me :)
[12:42] <popey> Bleep Bloop!
[12:42] <popey> nessita: thanks!
[12:42] <ogra_> (i'll need to fix up the device tree for him before he csn use wifi)
[12:43] <ogra_> (just building these allwinner kernels is so hard (got to use snapcraft in a chroot that has gcc6 available and such)
[12:43] <ogra_> which is why it is going slow
[12:46]  * om26er wishes RPi Zero was ARMv7 -- a fine board, wrong arch.
[12:56] <om26er> fyi, `snap list` says "No snaps are installed yet...." on UbuntuCore image from edge channel. Device: RPi3
[12:58] <mvo> om26er: that is unexpected, what does "snap changes" tell you?
[12:59] <om26er> mvo: that command hanged for link 20 seconds, still isn't returning.
[12:59] <zyga-suse> om26er: snap version?
[13:00] <niemeyer> o/
[13:00] <niemeyer> I'll be a minute or two late..
[13:00] <om26er> mvo: now `snap changes` worked, says:
[13:00] <om26er> ID   Status  Spawn                 Ready  Summary
[13:01] <om26er> 1    Doing   2017-08-08T13:00:11Z  -      Initialize system state
[13:01] <om26er> zyga-suse: http://paste.ubuntu.com/25269849/
[13:01] <om26er> aah, now `snap list` showed up as well :)
[13:09] <zyga-ubuntu> om26er: is the machine very very busy?
[13:10] <zyga-ubuntu> can you run top?
[13:10] <zyga-ubuntu> and ps aux
[13:15] <om26er> zyga-ubuntu: the machine had just finished the first boot setup
[13:15] <om26er> ran nothing else. It is reproducible as I had that issue in my last flashing a few hours ago as well.
[13:16] <zyga-suse> om26er: that doesn't mean it wasn't busy
[13:16] <zyga-suse> maybe something ran in a loop
[13:26] <mup> PR snapd#3686 closed: many: merge release/2.27 branch back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3686>
[13:26] <mup> PR snapd#3687 closed: Remove redundant apparmor rule for opengl interface and improve the test <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3687>
[13:30] <jdstrand> ondra: hey, I see in the forum mention of a pending avahi snap stuck in review, but I don't see it in the store...
[13:57] <mvo> niemeyer: 3569 is ready for a second review from you, probably/hopefully quck and painless as pstolowski addressed all the points AFAICS
[13:59] <zyga-ubuntu> niemeyer: hey, how often is the review sprint thread updated?
[13:59] <niemeyer> zyga-ubuntu: It's not updated for quite a while now.. need to get back to it
[14:05] <zyga-ubuntu> mvo: what do you want to do about https://github.com/snapcore/snapd/pull/3639 ?
[14:05] <mup> PR snapd#3639: update to version of golang.org/x/crypto currently in Debian unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3639>
[14:07]  * zyga-ubuntu focuses on https://github.com/snapcore/snapd/pull/3499
[14:07] <mup> PR snapd#3499: interfaces/builtin: add the spi interface <Created by tokurz> <https://github.com/snapcore/snapd/pull/3499>
[14:15] <mvo> zyga-ubuntu: I need to read up on 3639, the update was 1.7 only or something?
[14:19] <ondra> jdstrand it might have failed review completely
[14:20] <ondra> jdstrand yeah it was rejected, as "interface 'avahi-control' not found in base declaration"
[14:22] <ondra> jdstrand I guess we need to wait till interface gets updated to stable? or does it check against edge?
[14:29] <jdstrand> ondra: thre review tools need to be updated. I am updating them now
[14:31] <mup> PR snapd#3688 opened: Improve the test for ppp interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3688>
[14:33] <Pharaoh_Atem> zyga-ubuntu: well, the reason I haven't updated snapd was because mvo indicated snapd 2.27 was coming asap
[14:33] <Pharaoh_Atem> zyga-ubuntu: as for getting rid of the snap-confine subpackage, I'm considering it
[14:33] <Pharaoh_Atem> though it has certainly helped in making rebasing less dumb
[14:35] <Pharaoh_Atem> but I have been thinking about merging snap-confine into snapd package
[14:37] <zyga-suse> Pharaoh_Atem: aha, thank you!
[14:38] <Pharaoh_Atem> zyga-suse: the thing is, no one ever gives feedback for snapd, so it's basically a week of sitting in bodhi
[14:39] <Pharaoh_Atem> so I don't particularly want to have snapd sitting in bodhi for a week on 2.26.14 if 2.27 is arriving
[14:39] <zyga-suse> I see
[14:39] <zyga-suse> that makes sense, thanks
[14:40] <Pharaoh_Atem> if people actually bothered to test snapd while it was in updates-testing and give positive feedback, then I'd be more willing to do rapid updates
[14:40] <Pharaoh_Atem> of course, I can see why no one really wants to use snapd, as it's hamstrung in Fedora right now due to desktop integration features being broken
[14:41] <cachio> niemeyer, where I can see the configuration for each spread cron?
[14:42] <niemeyer> cachio: In the spread-cron repository
[14:42] <niemeyer> cachio: Each branch should have its own setup.. or at least that's my understanding
[14:42] <cachio> niemeyer, nice
[14:44] <Neeraj> Hi Facu
[14:47] <Neeraj> Do we have any resolutions on
[14:47] <Neeraj> " ERROR received an unexpected http response code (404) when trying to download
[14:56] <Facu> Neeraj, hello! it should be deployed to production today
[14:59] <niemeyer> zyga-ubuntu: updated the board, btw
[15:05] <zyga-ubuntu> thank you
[15:14] <mup> PR snapd#3689 opened: Improve the test for physical memory control and observe interface <Created by adglkh> <https://github.com/snapcore/snapd/pull/3689>
[15:15]  * Chipaca shakes his fist at hardware in general and bootloaders in particular
[15:15] <Neeraj> Hi Facu : Thanks
[15:16] <Neeraj> Facu : so snap refresh will work as it is correct, or we need to perform any other operation
[15:16] <Facu> Neeraj, it should work ok, but as soon it's in production, I'll ping you and will supervise
[15:18] <Neeraj> Hi Facu thanks
[15:37] <jdstrand> roadmr: hi! would you mind pulling r895? not urgent
[15:37] <jdstrand> ondra: that has your avahi fixes ^
[15:37] <roadmr> jdstrand: sure
[15:40] <ondra> jdstrand perfect
[15:40] <ondra> jdstrand I will wait when new snapd lands and will resubmit avahi to the store then
[15:40] <ondra> jdstrand thanks
[15:41] <jdstrand> ondra: np. if it would help you, you can request a manual review and I could approve it in anticipation of the above
[15:48] <ondra> jdstrand sure might do that, so it all just starts working once core lands
[16:25] <cachio> mvo, quick question
[16:25] <cachio> https://github.com/snapcore/snapd/blob/master/tests/main/snap-interface/task.yaml
[16:29] <cachio> mvo, sorry, this is the link https://paste.ubuntu.com/25270863/
[16:29] <cachio> it is on pi2
[16:29] <cachio> does it sound familiar to you?
[16:35] <ogra_> cachio, https://github.com/snapcore/classic-snap/blob/master/bin/create
[16:35] <ogra_> (line 23)
[16:36] <cachio> ogra_, tx
[16:37] <ogra_> for whatever reason /snap/core/current doesnt exist (or isnt found)
[16:38] <cachio> ogra_, I bought 2 kingstone micro sd cards today
[16:38] <cachio> ogra_, I flash both
[16:38] <ogra_> do they behave any better ?
[16:39] <cachio> I insert in the pi3, and everything loads normally but then the "press to configure" does not appears
[16:39] <cachio> the last I see is
[16:39] <cachio> random: nonblocking pool is initialized
[16:39] <cachio> ogra_, any idea?
[16:40] <ogra_> it might take a while, did youwait long enough ?
[16:40] <ogra_> also is that on monitor or serial console ?
[16:40] <cachio> is it on serial console
[16:40] <cachio> I waited more than 1 hour
[16:40] <ogra_> heh, yeah, i meant more like 1-2min :)
[16:41] <ogra_> there is something odd with the startup of console-conf
[16:41] <ogra_> (on a monitor the screen actually flashes a few times before it comes up)
[16:43] <cachio> ogra_, any idea how to make it appear?
[16:44] <ogra_> gimme a sec ...
[16:44] <ogra_> i have to dig up the ancient stable gadget (havent looked at that in a while)
[16:44] <ogra_> check cmdline.txt in the system-boot partition of the SD
[16:45] <ogra_> what ate the console= settings in there ?
[16:45] <ogra_> ogra@pi3:~/oldgadget/squashfs-root$ cat /boot/uboot/cmdline.txt
[16:45] <ogra_> dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty0 elevator=deadline rng_core.default_quality=700
[16:45] <ogra_> ogra@pi3:~/oldgadget/squashfs-root$ cat boot-assets/cmdline.txt
[16:45] <ogra_> dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline
[16:45] <ogra_> here we go
[16:46] <ogra_> try changing ttyAMA0 to ttyS0
[16:46] <ogra_> (iirc back then we only made it work for hdmi consoles, that got fixed later in the gadget (which we can not upgrade :P ) )
[16:48] <ogra_> at least you can easily edit it on the PC on the Sd card ...
[16:49] <cachio> ogra_, dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty0 elevator=deadline
[16:49] <ogra_> yeah, change AMA0 to S0
[16:50] <cachio> ok
[16:50] <ogra_> sad that we cant update that :/
[16:51] <ogra_> (yet)
[16:51] <cachio> ogra_, loading...
[16:54] <cachio> ogra_, should I update to console=ttyS1 in case I am using the tty1?
[16:54] <ogra_> no, S0 is the serial port ... thats fine
[16:54] <cachio> ogra_, I have in the tty0 the pi2
[16:55] <cachio> but then I see console=ttyS0
[16:55] <ogra_> this is from the POV of the board, not from the POV of your PC :)
[16:55] <cachio> is it ok?
[16:55] <cachio> ogra_, ahh
[16:55] <cachio> ok
[16:55] <ogra_> S0 just means first serial device
[16:56] <mvo> cachio: checking
[16:56] <mvo> cachio: that error does not ring a bell
[16:57] <ogra_> mvo, well, classic bin/create cant find /snap/core/current it seems
[16:58] <ogra_> for whatever reason
[16:58] <mvo> cachio, ogra_: right, would be nice to get a debug shell on this machine, I wonder why current is missing. is that reprocible?
[16:59] <ogra_> no idea
[16:59] <cachio> mvo, I'll try once the full run has finished
[16:59] <ogra_> only judging by the pastebin :)
[16:59] <ogra_> i never see such issues here in real usage :)
[16:59] <ogra_> but then, i also never use stable
[17:01] <ogra_> cachio, so any change regarding the config UI ?
[17:01] <ogra_> (does it show up on serial now?)
[17:02] <mvo> cachio: thank you, I suspect its a test issue, i.e. that somehow during restore of the tests the current symlink points to the wrong place or somethin
[17:02]  * mvo needs to step out to get some dinner
[17:03] <ogra_> well,  it does [ -e ....] ... that shouldnt care about the target of the link as long as the file node exists
[17:09] <cachio> ogra_, https://paste.ubuntu.com/25271070/
[17:09] <cachio> ogra_, should I reflash?
[17:10] <ogra_> [    7.370791] FAT-fs (mmcblk0p1): IO charset ascii not found
[17:10] <ogra_> woah
[17:11] <ogra_> cachio, well, it should surely not break ... i dont get why you have all these disk errors
[17:12] <cachio> with both cards I see the same
[17:12] <ogra_> you mean the inode errors (the last two lines) ?
[17:14] <cachio> ogra_, no, I just saw that in this card
[17:14] <cachio> I'll try with the other one
[17:15] <ogra_> the charset issue is likely a missing config option in that ancient stable kernel
[17:15] <ogra_> (nothing we can fix until gadget update work)
[17:15] <ogra_> *updates
[17:21] <cachio> ogra, the same error with the other sd card :(
[17:21] <ogra_> which one ?
[17:22] <ogra_> the asccii charset one is fine ... just ignore that one
[17:22] <cachio> the last one
[17:22] <ogra_> (just odd that the module is missing, thogh that kernel  is awful and outdated anyway)
[17:22] <ogra_> hmm
[17:23] <ogra_> well, i doubt it is fatal
[17:23] <ogra_> (the last one that is)
[17:23] <ogra_> (and the next reboot/fsck should fix it i guess)
[17:23] <cachio> ogra_, EXT4-fs (mmcblk0p2): error count since last fsck: 2
[17:23] <ogra_> right
[17:24] <cachio> ogra_, I see this also in the other card
[17:24] <cachio> ogra_, should I reflash and make the change in the tty before insert it in the device=
[17:25] <ogra_> yeah, try that ... though i see we are still using AMA0 on todays pi2 images ...
[17:25] <ogra_> so theoretically it should work
[17:25] <cachio> ok
[17:25] <ogra_> do you have a mmonitor so you could cross check that the UI comes up on a screen at least ?
[17:26] <ogra_> else i'd blame console-conf (or something systemic) instead of the tty's
[17:36] <cachio> ogra_, yes, I'll try that too
[18:08] <niemeyer> mvo: Can we change the contact information in the core snap to point to the forum?
[18:09] <niemeyer> It currently has a pretty long email address
[18:09] <mvo> niemeyer: sure
[18:09] <niemeyer> mvo: Thanks!
[18:17] <mup> PR snapcraft#1407 closed:  recording: record the original snapcraft.yaml <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1407>
[18:17] <mup> PR snapcraft#1432 closed: kbuild plugin: support Makefile without install target <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1432>
[18:32] <cachio> niemeyer, there?
[18:33] <niemeyer> cachio: Always!
[18:33] <cachio> niemeyer, good
[18:33] <niemeyer> Sometimes there is not here, but always there, for certain
[18:34] <cachio> niemeyer, hehe, I am checking the spread cron branches and I see that
[18:34] <cachio> for most of the branches that are doing sru validation
[18:34] <cachio> niemeyer, those are using the snapd from apt and the test code from master
[18:35] <cachio> so, there are tests that are failing against that snapd but passing on master
[18:35] <cachio> i.e. snapd-interface
[18:35] <niemeyer> Hmm
[18:36] <cachio> https://travis-ci.org/snapcore/spread-cron/builds/262177661
[18:36] <cachio> look this example
[18:36] <niemeyer> cachio: That doesn't make a lot of sense
[18:36] <niemeyer> cachio: This will be pretty much always broken
[18:36] <cachio> https://travis-ci.org/snapcore/spread-cron/builds/262177661#L1534
[18:36] <niemeyer> Since we test features that we implement, and we're always implementing features
[18:37] <cachio> niemeyer, this is the script that it is running https://github.com/snapcore/spread-cron/blob/snapd-from-trusty-updates-edge/run-checks
[18:38] <niemeyer> cachio: Can you please check with Federico what was the thinking around these tests, and then let's catch up on that again?
[18:38] <niemeyer> cachio: Wait, that doesn't look like SRU validation
[18:38] <cachio> niemeyer, it is using SPREAD_SRU_VALIDATION=1
[18:38] <niemeyer> cachio: Sure, but the *intention* of this test is not SRU validation
[18:39] <niemeyer> cachio: Just from its name, my guess is that the point there is making sure that the package we have on trust can continue to update to whatever is in edge
[18:39] <niemeyer> This makes sense to be in spread-cron
[18:40] <cachio> niemeyer, ok, so perhaps it should not used SPREAD_SRU_VALIDATION=1
[18:40] <cachio> use+
[18:41] <niemeyer> cachio: It really depends on what this flag does
[18:41] <niemeyer> cachio: But as long as the intent is preserved, we can change the test at will
[18:41] <niemeyer> cachio: Obviously, it needs to use the package from Trusty
[18:41] <niemeyer> cachio: and it needs to update to the content in edge
[18:42] <cachio> niemeyer, in the code, if "$SRU_VALIDATION" = "1", then it installs snapd using apt, otherwise it installs snapd that was built
[18:43] <cachio> in sru validation it also updates snapd after install it
[18:46] <om26er> Hi! If a device has support in the mainline kernel, is there still an enablement effort needed ?
[18:55] <niemeyer> cachio: If that's all it does then it makes sense to have it set, as we want to test the package and then update it to edge, right?
[18:55] <niemeyer> It's also a hint that the variable name may be wrong
[18:56] <niemeyer> om26er: If everything works, then there's no need to make anything else work :)
[18:56] <niemeyer> om26er: Being in the mainline kernel is often not the same as "everything works", though
[18:56] <niemeyer> om26er: So, YMMV
[18:57] <om26er> niemeyer: hmm, so is there a armhf UbuntuCore image with stock kernel ?
[19:00]  * om26er wonders when will UbuntuCore get 4.11
[19:26] <niemeyer> om26er: The Ubuntu Core images published by Canonical target specific ARM devices..
[19:27] <niemeyer> ogra_ has all the details
[19:27] <niemeyer> I'd recommend sending your questions to the forum so others can participate and benefit from the discussion
[19:35] <mup> PR snapd#3593 closed: interfaces/wayland: add access to wayland compositors <Blocked> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/3593>
[20:17] <mup> Issue snapcraft#100 opened: Issues are tracked on launchpad <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/100>
[20:17] <mup> Issue snapcraft#1437 opened: cross-compile i386 kernel <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1437>
[20:20] <mup> Issue snapcraft#1438 opened: cross-compile python <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1438>
[20:23] <mup> Issue snapcraft#1439 opened: target arch default for containers <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1439>
[20:35] <mup> Issue # opened: snapcraft#1440, snapcraft#1441, snapcraft#1442, snapcraft#1443, snapcraft#1444, snapcraft#1445, snapcraft#1446
[20:49] <mup> PR snapd#3690 opened: interfaces/wayland: add wayland interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3690>
[21:31] <PhoenixMage> Hey guys, I have created a snap but it seems that it cant find the libraries that I have included with it, how can I fix that?
[21:33] <kyrofa> PhoenixMage, can you shared your snapcraft.yaml?
[21:36] <PhoenixMage> https://git.launchpad.net/samba-dc-snap/tree/snapcraft.yaml
[21:37] <kyrofa> PhoenixMage, the libs that end up not being found, where do they end up?
[21:37] <kyrofa> lib/private ?
[21:38] <PhoenixMage> kyrofa: Thats where the samba compile put them
[21:39] <kyrofa> PhoenixMage, yeah that's fine, I'm just asking: are those the libs you're not finding?
[21:39] <kyrofa> I assume so, just want to make sure
[21:40] <PhoenixMage>         libsamba-hostconfig.so.0 => not found
[21:40] <PhoenixMage>         libdbwrap-samba4.so => not found
[21:40] <PhoenixMage>         libtalloc.so.2 => not found
[21:41] <PhoenixMage> Actualy
[21:41] <PhoenixMage> Sorry my bad
[21:41] <PhoenixMage>  /snap/samba-dc/x1/sbin/samba: error while loading shared libraries: libcluster-samba4.so: cannot open shared object file: No such file or directory
[21:42] <PhoenixMage> Its early and I am hung over
[21:44] <kyrofa> Yep, private indeed
[21:45] <kyrofa> PhoenixMage, so you have two options
[21:45] <kyrofa> Three, maybe. Perhaps samba has a build option for putting those libs in a nicer place
[21:45] <kyrofa> 2) You can use snapcraft's `organize` keyword to move all the private libs into `lib`
[21:46] <kyrofa> 3) Add lib/private to the LD_LIBRARY_PATH of the app
[21:46] <kyrofa> (3 would use the `environment` keyword in the yaml)
[21:46] <PhoenixMage> kyrofa: ok thanks for your help, I thought LD_LIBRARY_PATH was recursive
[21:47] <kyrofa> PhoenixMage, nope, it's just like PATH
[21:48] <PhoenixMage> cool, will make the change and recompile
[21:48] <PhoenixMage> Thanks again
[21:49] <PhoenixMage> --with-privatelibdir should do the trick
[21:55] <kyrofa> Yeah, nice
[21:55] <kyrofa> PhoenixMage, and no problem :)
[22:17] <mup> PR snapd#3691 opened: tests: installing snapd for nested test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3691>
[23:17] <superjonotron> attempting to use the netplan yaml structure and even though I have figured out the correct syntax for what I want, during boot I get "A start job is running for raise network interfaces (5 mins 6 sec)".
[23:18] <superjonotron> based on testing, my best guess is this is with dns resolving but once the system is up, everything is resolved
[23:18] <superjonotron> if I leave the default yaml in /etc/netplan as the only one, and everything is dhcp with nothing defined essentially, this does not happen
[23:18] <superjonotron> anybody got any thoughts on this?
[23:19] <superjonotron> yaml config for reference http://paste.ubuntu.com/25273156/