[05:16] <mborzecki> morning
[05:53] <zyga> good morning
[06:12] <zyga> o/ mvo
[06:12] <zyga> how are you feeling?
[06:13] <mvo> zyga: good morning! much better, thank you
[06:16] <mborzecki> zyga: mvo: hey
[06:19] <zyga> hmm
[06:19] <zyga> on cosmic snaps seem to be broken?
[06:19] <zyga> zyga@fyke:~$ canonical-livepatch
[06:19] <zyga> 2018/09/25 08:19:08 error executing : open /var/snap/canonical-livepatch/42/livepatchd.err: permission denied
[06:20] <mvo> mborzecki: hey
[06:20] <mvo> zyga: all snaps?
[06:20] <zyga> ah, no it's just. a bug in canonical-livepatch
[06:20] <mvo> zyga: this sounds like its time for 18.10 in CI now that we are in beta freeze
[06:20] <mvo> zyga: aha, just c-l ok
[06:20] <zyga> canonical-livepatch uses wrong permission for status file https://www.irccloud.com/pastebin/asnxhatD/
[06:23]  * zyga wonders where to report bug on canonical-livepatch
[06:26] <zyga> ok, bug reported
[06:27] <mup> PR snapd#5858 opened: Skip unsupported architectures for fedora-base-smoke test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5858>
[06:35] <zyga> mvo: review on https://github.com/snapcore/snapd/pull/5845
[06:35] <mup> PR #5845: interface: add new dotfiles interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845>
[06:37] <zyga> brb, too cold, need more clothing
[06:44] <zyga> re
[06:51] <mvo> zyga: cool, thank you, I have a look
[07:03] <pstolowski> mornings
[07:07] <mborzecki> pstolowski: heya
[07:08] <mup> PR snapd#5832 closed: [RFC] overlord/{snapstate,assertstate}: parallel instances and refresh validation <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5832>
[07:11] <zyga> hey pawel
[07:20] <kyrofa> zyga, those chilly mornings are the best
[07:20] <zyga> kyrofa: best to get ill? :-)
[07:20] <zyga> or are you serious
[07:20] <zyga> my hands are freezing
[07:20] <kyrofa> Hahaha, I'm serious, I love it when it's cold and I need to bundle up all cozy
[07:20] <zyga> kyrofa: do you type with your gloves on or do you just have warm hands anyway?
[07:21] <zyga> kyrofa: it's not freezing yet
[07:21] <zyga> it just feels like proper autumn already
[07:21] <kyrofa> zyga, yeah not gonna lie, it's probably 60-something here and I'm working outside
[07:21] <kyrofa> So not the same situation :P
[07:21] <pstolowski> kyrofa: hey! how is the place?
[07:21] <zyga> 6C in the morning (42F)
[07:22] <zyga> kyrofa: tonight we will have 3C
[07:22] <pstolowski> kyrofa: also, unusual to see you online that early ;)
[07:22] <kyrofa> pstolowski, man, I couldn't ask for better. It's so quiet, and I have this courtyard to myself
[07:22] <kyrofa> pstolowski, haha, yeah I'm not used to you guys being around either!
[07:22] <zyga> kyrofa: beware of the squirrels ;)
[07:22] <zyga> mborzecki: partial review on 5857
[07:23] <zyga> I'll make warm tea and be back for more
[07:23] <kyrofa> zyga, there are some massive bees here, that's about all I've noticed so far
[07:23] <zyga> kyrofa: bees or wasps?
[07:23] <mborzecki> zyga: thanks
[07:23] <zyga> kyrofa: as in, do you get genuinely larger bees?
[07:23] <zyga> kyrofa: or is "bee" a word for anything bee-like
[07:23]  * zyga loves bees
[07:24] <kyrofa> I'd say they are bees, but they may completely different. They're like half the size of my fist, and black
[07:24] <kyrofa> But they're fat like a bee
[07:24] <zyga> kyrofa: did I tell you I want to have bee hives?
[07:24] <zyga> !!!!
[07:24] <zyga> that's some bee :D
[07:24] <kyrofa> I'm too busy flailing them away from me to look very closely
[07:24] <mborzecki> bumblebees?
[07:24] <zyga> if you can snatch a photo I would love to see those
[07:24] <kyrofa> mborzecki, it's a little bigger than that, and black
[07:25] <kyrofa> zyga, haha, I'll try, they tend to come out when it gets warmer
[07:25] <kyrofa> zyga, actually I've always been curious about bee hives as well. Do you have room for them?
[07:26] <pstolowski> kyrofa: i envy you!
[07:26] <zyga> kyrofa: no, but I would like to buy some land
[07:26] <zyga> kyrofa: and get properly trained to handle bees
[07:26] <zyga> kyrofa: my dad and granddad had honeybees :)
[07:27] <zyga> kyrofa: supposedly the best moment to start learning about them is early summer, the season ends in august and then pretty much nothing happens
[07:28] <zyga> kyrofa: I subscribed to a periodical about bees; so far I know very little though
[07:34] <mup> PR snapd#5858 closed: Skip unsupported architectures for fedora-base-smoke test <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5858>
[07:36] <mvo> zyga: thanks for your review on the dotfiles interface  - the missing check for "." is intentional -  I was thinking we could use this for non dotfiles as well at least potentially. if something neeeds access to a specific non-dotfile in home we could use the interfaces to give it without giving the full home away
[07:37] <zyga> hmmm, I would give the interface a different name then
[07:37] <zyga> like file-access or folder-access?
[07:37] <zyga> or user-data-access
[07:39] <zyga> actually
[07:39] <zyga> eyah
[07:40] <zyga> user data access feels like the right name
[07:40] <zyga> but I'll defer to the naming overlords ;-)
[07:52] <mvo> zyga: my thinking exactly :)
[08:14]  * mborzecki wonders what happens if one has networkd and NM managing different interfaces and competing for the default route
[08:17] <mvo> mborzecki: good question, when NM is in charge it will setup the default routes just with different metrics
[08:19] <mborzecki> mvo: yeah, would you need to manually tweak those or are the deafults non conflicting? i see the default route is using 600 here, but no clue whether that's dhcpclient's or nm's doing
[08:20] <mvo> mborzecki: I have 100 for eth and 600 for wlan but my two interfaces are both managed via NM :/
[08:20] <mborzecki> iirc a default 1000 if you add it by hand right?
[08:21] <mvo> mborzecki: just tried with "route" and got metric:0
[08:21] <mborzecki> hmm
[08:22] <mborzecki> well, i guess if one has a device which uses both netword and NM you craft the setup carefully enough so that it does what your requirements say
[08:27] <Chipaca> mvo: mborzecki: should I mention classic devices?
[08:56] <mvo> zyga: quick brainstorm: should the dotfiles interface infere if its a file or dir from the trailing "/" ? i.e. .foo is a file and .foo/ is a dir? or too magic?
[08:57] <mvo> zyga: this way I can get rid of the files/dirs attr and just use paths or something
[09:03] <zyga> mvo: I strongly think this is too magic
[09:03] <mvo> zyga: ok
[09:03] <zyga> So either allow both or make it explicit
[09:03] <mvo> zyga: in this case the validation needs to reject "foo/" for files
[09:03] <mvo> zyga: but allow "foo/" for dirs
[09:03] <zyga> Yes
[09:03] <zyga> Well
[09:03] <zyga> You kind of do clean on it already
[09:04] <zyga> So either allow trailing / on dirs
[09:04] <mvo> zyga: I do but you pointed out it might be confusing to disallow "foo/" on a dir
[09:04] <zyga> Or always reject it and add it internally like you do now
[09:04] <zyga> Right
[09:05] <zyga> Because the reason for that is unclear IMO
[09:05] <mvo> zyga: I will look into it but my gut feeling is to reject it because the alternative is more code
[09:05] <zyga> We routinely refer to directories with /
[09:05] <zyga> Ok
[09:05] <zyga> As long as it is documented
[09:05] <zyga> Files and directories explicitly have
[09:05] <zyga> one more advantage
[09:06] <zyga> If somebody uses a symlink it is not going to work
[09:06] <zyga> But perhaps rightfully so
[09:06] <mvo> zyga: yeah, I think thats ok, symlinks & apparmor are tricky
[09:18] <mup> PR snapcraft#2291 opened: meta: put environment into runner instead of app wrapper <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2291>
[10:22] <mup> PR snapcraft#2292 opened: sources: properly handle pull failures <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2292>
[10:41] <mup> PR snapd#5825 closed: tests: add snap install hook with base: core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5825>
[10:42] <mvo> niemeyer: when you have a moment, a high level review of 5717 would be great. I reworked it based on your input and it will auto-retry to get out of degraded mode now
[10:42] <mvo> niemeyer: this will unblock two more PRs :)
[10:43] <niemeyer> mvo: Heya, looking
[10:43] <mvo> niemeyer: also 5583 (without snaps stop and wait for socket) would be great but that might be more work :/
[10:43] <mvo> niemeyer: (but I also addressed your input there)
[10:43] <mvo> niemeyer: thanks!
[11:00] <zyga> brb
[11:00] <niemeyer> mvo: Sent a couple of notes on the first one
[11:14] <niemeyer> mvo: Second one reviewed
[11:17] <niemeyer> mvo, zyga, everyone: I'm taking the afternoon off today to recharge batteries a bit
[11:19] <Chipaca> niemeyer: I was just thinking of doing the same
[11:20] <Chipaca> finding it hard(er) to concentrate
[11:20] <zyga> niemeyer: yeah, I needed that yesterday
[11:20] <zyga> niemeyer: enjoy the remains of autumn :)
[11:27] <mup> PR snapd#5859 opened: many: introduce facts, export experimental features as facts <Created by zyga> <https://github.com/snapcore/snapd/pull/5859>
[11:46] <ogra> ppisati, poke ...
[11:46] <Chipaca> mborzecki: yesterday I saw code of yours where you took a string like "a:b::c:d" and return []string{"a", "b", "c", "d"}; where was that?
[11:47] <ppisati> ogra: poke back
[11:47] <ogra> ppisati, would you be able to include the bvc4 libs in the pi2-kernel initrd ?
[11:47] <ogra> *vc4
[11:47] <mborzecki> Chipaca: #5857?
[11:47] <mup> PR #5857: userd: extend the list of supported XDG Desktop properties when autostarting user applications <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5857>
[11:47] <ogra> ppisati, https://paste.ubuntu.com/p/v4qCGjTNrz/ would be the list
[11:49] <ogra> ppisati, that makes psplash work even with the vc4-kms-v3d overlay (else it only work with vc4-fkms-v3d, but that is completely unaccelerated)
[11:50] <ogra> when using vc4-kms-v3d /dev/fb0 is only created by the vc4 module ... while vc4-fkms-v3d gives you a kernel /dev/fb0 but without any acceleration
[11:51] <ogra> so to have fb0 in the initrd i'd need the modules available there (and i doubt we should compile vc4 into the kernel since many headless use casess wont want it)
[11:51] <ppisati> ogra: xenial or bionic? i guess both
[11:52] <ogra> ppisati, yeah., likely both, i have only worked with xeinal yet though
[11:52] <ppisati> ogra: if you open me an LP with the list of modules to include, i'll start working on it
[11:52] <ogra> \o/
[11:52]  * ogra hugs ppisati 
[11:53] <ogra> ppisati, hmm, LP just against linux-raspi2 ? (since i want it in the snap)#
[11:53] <ppisati> ogra: yep
[11:53] <ogra> on it
[11:58] <mborzecki> Chipaca: thanks for the tip
[11:59] <ogra> ppisati, Bug #1794279
[11:59] <mup> Bug #1794279: please include vc4 modules in pi2-kernel snap initrd <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1794279>
[12:01] <Chipaca> mborzecki: note you  can get megabytes into the environment before it starts to fall apart
[12:01] <Chipaca> I seem to recall that 8MB in an env block was enough for execve to fail, but that might be old (32 bits?), i haven't tested the limits in this way in ages
[12:02] <Chipaca> you can easily creae an env var that'll make bash crawl: FOO=$(yes)
[12:02] <zyga> some of those used to be limited to ~~~ 32KB but that was long ago
[12:02] <Chipaca> (killall yes when you get bored; then 'echo "$FOO"' to be more bored
[12:02] <zyga> AFAIK there's no limit now
[12:03] <Chipaca> zyga: xargs --show-limits thinks still thinks there is a limit
[12:03] <Chipaca> ~2MB?
[12:03] <Chipaca> but that's mostly for execve (which applies in this case, but the other is fun)
[12:07] <ppisati> ogra: ack
[12:08] <mborzecki> zyga: i wonder, when doing mount mappings for parallel installs under /var/snap/<snap>, would people expect this to have shared propagation
[12:09] <Chipaca> mborzecki: note also there's bytes.FieldsFunc which would save you the conversion (but then you want a []string, so ¯\_(ツ)_/¯
[12:09] <Chipaca> )
[12:09]  * Chipaca ~> lunch, and then probably nothing but probably guitar playing and maybe minecraft with the boys and dog walking and some more guitar and early bed
[12:09] <zyga> mborzecki: shared propagation is actually established as a default by snapd, we only get slave propagation though, right (because snap-confine)
[12:09] <Chipaca> but, hey, maybe some irc too. ttfn.
[12:09] <zyga> mborzecki: btw, I found a bug in propagation setting, something I need to investigate and fix ASAP
[12:09] <zyga> mborzecki: I have a test that shows htis
[12:09] <zyga> *this
[12:10] <zyga> mborzecki: we can sync after standup
[12:11] <mborzecki> zyga: i've extended fuse-support spread test a bit and obviously the mount point is only under the mapped hierarchy, now we've said (have we?) that _foo will be mapped under snap name, but i guess we did not promise anything about propagating mounts
[12:11] <zyga> yeah
[12:11] <zyga> I think that is the same bug
[12:12] <mborzecki> ok, let's talk after standup
[12:19] <zyga> mborzecki: https://github.com/zyga/broken-layout-migration
[12:20] <zyga> mborzecki: that shows this and one more issue found last week
[12:37] <mup> PR snapd#5860 opened: interfaces/houtplug: helpers and struct updates <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5860>
[12:55] <sil2100> mvo: hey! Today I quickly sat down to finally see what's up with my raspi3 when running core18 on it, since I wasn't able to reproduce your original problem (the one with the invalid netplan config)
[12:55] <sil2100> mvo: I wasn't able to reproduce it as console-conf was segfaulting
[12:55] <sil2100> mvo: I did some debugging and ugh, it's segfaulting on probert when trying to probe for wifi
[12:55] <sil2100> With the wifi module unloaded console-conf and probert all work fine
[12:55] <sil2100> mvo: so apparently my raspi3 is suffering from probably the same (or very similar) issue as the dragonboard
[12:57] <sil2100> mvo: so generally I'll poke mwhudson that probert seems to segfault on two different boards, I guess on two different architectures as well
[12:57] <mvo> sil2100: yeah, that sounds a lot like the segfault we had on the dragon
[12:58] <mvo> sil2100: did you push a debug build of probert into the image ppa?
[13:01] <mborzecki> zyga: pstolowski: standup?
[13:11] <joelkraehemann> hi all
[13:11] <joelkraehemann> https://snapcraft.io/nongnu-gsequencer/listing
[13:11] <joelkraehemann> ^^ please, do the review.
[13:14] <ogra> mvo, sil2100, note that we had the same issue with core16, caused by netplan (not probert) forcefully un/reloading the wlan drivers when probing
[13:15] <ogra> mvo, sil2100 there was a blacklist in netplan to avoid unloading most sdio based wlan drivers due to exactly that reason ... perhaps thats gone in 18.04 ?
[13:21] <mborzecki> zyga: snappy-devel?
[13:22] <zyga> mborzecki: actually, can we postpone for a sec, I need to see the stuff that my daughter asked about
[13:22] <mborzecki> zyga: ok
[13:29] <sil2100> ogra: oh! Good to know! I'll investigate that after lunch
[13:30] <ogra> sil2100, here is an example bug (there were three or four like this) https://bugs.launchpad.net/netplan/+bug/1741910
[13:30] <mup> Bug #1741910: ath6kl_sdio does not support unbinding <verification-done-xenial> <netplan:Fix Released by cyphermox> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1741910>
[13:31] <ogra> that black/whitelist was extremely ugly, i can imagine that cyphermox tried to replace it with some more intelligent code (which has perhaps bugs)
[14:05] <zyga> mvo: no c18 meeting?
[14:07] <mvo> zyga: we can have one if you want
[14:07] <mvo> zyga: but I think its fine to skip given that gustavo and samuele are not around
[14:07] <zyga> yeah
[14:07] <zyga> let's skip
[14:13] <mborzecki> 2018-09-25 13:32:01 Cannot allocate google:arch-linux-64: cannot allocate new Google server google:arch-linux-64 (sep251328-278432): cannot find ready marker in console output for google:arch-linux-64 (sep251328-278432)
[14:13] <mborzecki> cachio: have you seen something like this ^^
[14:15] <cachio> mborzecki, when did you get that?
[14:15] <cachio> 45 minutes ago?
[14:15] <mborzecki> cachio: yes
[14:15] <cachio> could you please try again?
[14:15] <mborzecki> ok
[14:15] <cachio> otherwise I'll revert last image which I manually updated today
[14:32] <cachio> mborzecki, seems to be failling in many branches
[14:32] <cachio> I'll revert it
[14:36] <mborzecki> ok
[14:37] <mborzecki> cachio: can you debug what's wrong with the image?
[14:37] <cachio> mborzecki, yes
[14:37] <cachio> I'm on that
[14:38] <cachio> this is already deprecated
[14:38] <cachio> so arch should be up again
[14:44] <cachio> mborzecki, https://paste.ubuntu.com/p/XD87JBKzxs/
[14:44] <cachio> have you seen that?
[14:45] <cachio> zyga, ~
[14:45] <zyga> nope
[14:56] <sil2100> ogra: I doubt that's it as it's segfaulting earlier, but who knows - thanks for the context o/
[15:01] <ogra> sil2100, good luck anyway :)
[15:11] <diddledan> random thought for the day: make snaps able to tell APT/DPKG that they "supply" the same as a debian package - the specific example I came across that would benefit me personally, a deb package depends on docker-ce deb package but I had the docker snap installed so it refused to install this other package because it thought I didn't already have docker-ce
[15:12] <diddledan> obviously that only benefits debian-based distributions so we'd need an abstraction to allow the same function on rpm or other distros
[15:13] <mup> PR snapd#5811 closed: tests: add test that runs snapctl with a core18 snap <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5811>
[16:18]  * zyga returns for evening work
[16:32] <halfbit> hi, so it seems like all of the snappy desktop applications on my system tend to hang/crash
[16:32] <halfbit> like I get a window for libreoffice, but nothing is drawn in it, I can't close it, and I can't start a new one
[16:32] <halfbit> same thing with the spotify snap
[16:33] <zyga> halfbit: hello, that's unfortunate, sorry about that - can you tell me more about your system (output of "snap version" helps)
[16:33] <halfbit> this is on a fresh install of ubuntu 18.04
[16:33] <halfbit>  tburdick@jupiter  ~  snap version                      ✔  8627  11:31:33
[16:33] <halfbit> snap    2.35
[16:33] <halfbit> snapd   2.35
[16:33] <halfbit> series  16
[16:33] <halfbit> ubuntu  18.04
[16:33] <halfbit> kernel  4.15.0-34-generic
[16:34] <zyga> what does snap changes say?
[16:35] <zyga> "snap changes"
[16:37] <halfbit> error: no changes found
[16:37] <zyga> hmm, ok
[16:37] <zyga> what happens when you run "snap run spotify" from command line?
[16:38] <halfbit> I re-installed spotify with the deb which works perfectly, let me try with libreoffice
[16:38] <zyga> ok
[16:40] <halfbit> ok now I'm confused
[16:41] <halfbit> yeah its just working now
[16:41] <halfbit> of course
[16:41] <halfbit> infuriating
[16:41] <zyga> perhaps it was the one-time setup that some apps are doing?
[16:41] <halfbit> I have no idea
[16:42] <halfbit> but its beyond frustrating to go from a working system to something where I'm mucking around with this :(
[16:42] <zyga> if you want you can "snap install spotify" and see if that starts
[16:43] <halfbit> yeah it started spotify and its working
[16:43] <mup> PR snapcraft#2292 closed: sources: properly handle pull failures <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2292>
[16:44] <halfbit> well I guess its good for now
[16:44] <halfbit> I'll be back if it stops working again
[16:44] <zyga> good luck
[17:46] <mup> PR snapd#5717 closed: snapd: go into degraded mode when the selftest fails <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5717>
[19:16] <diddledan> https://github.com/auchenberg/volkswagen
[19:32]  * ogra hopes thats not a diesel
[19:33] <diddledan> :-) that repo is full of win
[20:23] <mup> PR snapcraft#2293 opened: build providers: use the new snapcraft: remote for multipass <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2293>
[20:38] <mup> PR snapcraft#2294 opened: snap: workaround the dirty tree <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2294>
[20:40] <mup> PR snapd#5861 opened: cmd/libsnap: add functions for handling facts <Created by zyga> <https://github.com/snapcore/snapd/pull/5861>
[20:40] <mup> PR snapd#5862 opened: cmd: fix C formatting <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5862>
[21:50] <mup> PR snapcraft#2295 opened: tests: use SNAPCRAFT_PACKAGE_TYPE everywhere <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2295>