[00:16] <zyga> Caelum: Yeah, Good idea. I will mąkę that change unless already did
[00:16] <zyga> I’m back tomorrow
[00:16] <Caelum> awesome, thank you!
[03:59] <mwhudson> so is there any way to tell patchelf to leave certain files alone? https://launchpadlibrarian.net/363045593/buildlog_snap_ubuntu_xenial_ppc64el_go110_BUILDING.txt.gz
[03:59] <mwhudson> the hints in the log seem to be about how to exclude the file, which i don't really want to do
[05:01] <mborzecki> morning
[06:05] <mborzecki> mvo: morning
[06:15] <mvo> hey mborzecki ! good morning
[06:15] <mvo> mborzecki: how are things? any fires?
[06:15] <mborzecki> mvo: not that i'm aware of
[06:15] <mvo> mborzecki: excellent
[06:16] <mvo> mborzecki: I see the list of open PRs is also relatively tame
[06:16] <mborzecki> mvo: yes, zyga was doing the 'trimming'
[06:16] <mvo> mborzecki: nice!
[06:18] <mvo> 4967 needs a "review" :)
[06:18] <mvo> (just changelog updates so not really much of a review9
[06:18] <mvo> )
[06:24] <zyga> Hey
[06:24] <zyga> I’m trying to wake up
[06:25] <zyga> Sorry for being late
[06:25] <mvo> zyga: good morning!
[06:25] <zyga> Good morning
[06:27] <mvo> zyga: how are you? any issues that need attention?
[06:28] <zyga>  Sleepy :-)
[06:28] <zyga> I think one issue needs attention.  The release, I didn’t publish the build to beta that day.
[06:29] <mvo> zyga: ok, on it
[06:30] <mvo> zyga: done
[06:30] <zyga> Thank you
[06:32] <zyga> I noticed a new recurring test failure
[06:32] <zyga>     - google:debian-9-64:tests/main/interfaces-network fails very often, though not all the time
[06:33] <zyga> and the failure looks real
[06:33] <zyga> typical failure of the network test on debian https://www.irccloud.com/pastebin/KujuZdgP/
[06:46] <FeelAporl> License error in discord app showing Up! https://paste.ubuntu.com/p/yHcHWGH2z2/
[06:59] <kalikiana> good morning
[06:59] <zyga> hey kalikiana
[06:59] <zyga> mvo: I found an interesting bug
[07:00] <zyga> snaps cannot be refreshed concurrently with core when reexec is supported https://www.irccloud.com/pastebin/46PfLThC/
[07:00] <zyga> as snapd restarts and snapctl doesn't run
[07:01] <mvo> zyga: uh, indeed
[07:02] <zyga> we could sort the refresh list so that snapd-carrier is always first
[07:02] <zyga> and make it so that core refresh blocks all the other guys
[07:03] <zyga> but not sure how since they are in lanes
[07:03] <zyga> we could perhaps make concurrentl downloads but apply them one by one
[07:03] <zyga> (so lane some part but not all of it0
[07:03] <zyga> but it would be a bigger redesign
[07:04] <mvo> zyga: yeah, or we ensure core is done last
[07:04] <mvo> zyga: fwiw, the nvidia fix works for me (tm) on bionic - thanks mborzecki for this!
[07:04] <mborzecki> mvo: yay!
[07:04] <zyga> I chose core first because of assumes: snapdXY
[07:04] <zyga> mvo: can we have a "bug" tag on the forum?
[07:05] <mvo> zyga: sure, I think you can add tags yourself
[07:05] <zyga> oh, thanks, I didn't see that
[07:05] <mvo> zyga: just write them and I think they appear. I'm not fully sure though, I did not use them much in the past (only for releases)
[07:08] <zyga> mvo: I don't think I can do that actually
[07:08] <zyga> mvo: anywy, I tried to capture this so that we don't forget: https://forum.snapcraft.io/t/musnt-refresh-core-concurrently-with-other-snaps-when-reexec-is-supported/4841
[07:16] <pstolowski> morning
[07:17] <pstolowski> do we have a fire with a configure hook?
[07:28] <mvo> pstolowski: good morning! not really a fire more a bit of a wart: https://forum.snapcraft.io/t/musnt-refresh-core-concurrently-with-other-snaps-when-reexec-is-supported/4841 but we should fix it as it leaves ugly errors in the `snap changes`
[07:34] <zyga> hey hey pawel
[07:38] <mborzecki> pstolowski: hey
[07:38] <pstolowski> o/
[07:39] <zyga> pstolowski: I added some feedback to https://github.com/snapcore/snapd/pull/4917
[07:39] <mup> PR #4917: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <https://github.com/snapcore/snapd/pull/4917>
[07:39] <zyga> but I think it's close to landing otherwise
[07:39] <zyga> though I think it warrants a gustavo/pedronis review
[07:41] <pstolowski> zyga: thank you, i need to revisit this
[07:42] <zyga> sure
[07:42] <zyga> mvo: how do you feel about https://github.com/snapcore/snapd/pull/4911
[07:42] <mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
[07:43] <zyga> we can rebase it to make tests pass
[07:43] <zyga> but we could also close it
[07:43] <zyga> mborzecki: I have a question about https://github.com/snapcore/snapd/pull/4880
[07:43] <mup> PR #4880: [RFC] cmd, data: plain make  <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>
[07:43] <zyga> mborzecki: can we please close it, add a makefile and switch to it gradually
[07:44] <zyga> mborzecki: it'd be easier to review and I have some strong opinions about how to use plain make to its full extent
[07:45] <mborzecki> zyga: can you leave some comments on what you have in mind there?
[07:45] <zyga> mborzecki: well, it's a lot of little thing
[07:46] <zyga> *things
[07:46] <zyga> I'm mainly saying it's easier to discuss this in PRs when the scope is smaller
[07:49] <zyga> mborzecki: let me propose some skeletons to show what I mean
[07:49] <zyga> but I need to finish trespassing branch first
[07:49] <zyga> so in the afternoon
[07:50] <mborzecki> zyga: ok, i'll close it for now
[07:51] <mup> PR snapd#4880 closed: [RFC] cmd, data: plain make  <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4880>
[07:57]  * zyga is once again reaffirmed that terminus is the best font for low-dpi displays
[07:59] <mborzecki> morphis: can you take a look at https://github.com/morphis/meta-snappy/pull/17 ?
[07:59] <mup> PR morphis/meta-snappy#17: updates: snapd 2.32.2, libseccomp 2.3.3 <Created by bboozzoo> <https://github.com/morphis/meta-snappy/pull/17>
[07:59] <morphis> mborzecki: sure
[08:00] <mborzecki> morphis: thanks
[08:17] <zyga> brb
[08:25] <seb128> mvo, hey, how are you? had a good easter w.e?
[08:35] <mvo> seb128: hey, good morning! I had a really nice weekend, thank you. how are you?
[08:36] <seb128> mvo, I'm good, thanks! I had a long relaxing w.e :) but now back to bionic crazyness :/
[08:37] <seb128> mvo, did you see https://forum.snapcraft.io/t/translation-management/4798 ? is that something you could help with ? ;)
[08:37] <seb128> mvo, basically how is snapd setup for translations? do you import the translation work from launchpad to github?
[08:38] <mvo> seb128: I have seen it but not thought about it yet. we do not currently merge the translations back but we could easily do this of course
[08:38] <mvo> seb128: and I think we have to for the benefit of the other distros
[08:38] <seb128> mvo, do you have translators on github?
[08:38] <mvo> seb128: I mean, for ubuntu langpacks are probably ok
[08:38] <seb128> right
[08:38] <mvo> seb128: not really, LP seems to be the better choice here
[08:38] <seb128> but even on ubuntu, the template was outdated on launchpad
[08:38] <seb128> Gunnar updated it manuallys
[08:39] <seb128> -s
[08:39] <seb128> so at least translators can do their job now, but it made us wonder what was the expected workflow around snapd translations
[08:39] <mvo> seb128: uh, I though we had setup auto-sync :/ I need to look into this, we certainly want the auto-imported snapd LP tree for the translations
[08:39] <seb128> k
[08:40] <mvo> seb128: tbh we just had not put enough effort into the translations and to support them, but now is a good time to fix that I think
[08:40] <Chipaca> moin moin
[08:42] <seb128> mvo, k, well let me know if I can do anything to help. I think that with the template update from Gunnar translators can do their work, you might just want to do an export/import of those in github a bit later for other distros as you said
[08:42] <seb128> mvo, and I'm going to keep an eye on what's going on with the template import, the package build generated a correct one but somehow launchpad ended up not having all the strings until Gunnar workarounded it
[08:42] <Chipaca> is there an automated way to export it, so we can add it to the other distros build scrips?
[08:47] <mvo> seb128: I look into it once I finished my current task
[08:47] <seb128> mvo, thx
[08:48] <seb128> Chipaca, launchpad can auto export to a branch/vcs I think
[08:53] <zyga> Chipaca: hello
[08:53] <Chipaca> zyga: hiya
[08:53] <zyga> mvo: hey, do you think we could seed langpacks-all into the core as an experiment?
[08:53] <Chipaca> zyga: did you see #1760416?
[08:53] <zyga> Chipaca: how have you been? :)
[08:53] <mup> Bug #1760416: dropping privs did not work: Invalid argument <amd64> <apport-bug> <artful> <wayland-session> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1760416>
[08:53] <zyga> oh, nope
[08:53] <Chipaca> zyga: very lazy :D
[08:54] <zyga> bummer, that's something nasty
[08:54] <Chipaca> was tempted into looking at snapd things only twice in the last week \o/
[08:57] <mborzecki> zyga: can you do antoher pass of #4942
[08:57] <mup> PR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
[08:57] <zyga> mborzecki: queued, now looking into the bug chipaca referenced
[08:58] <mborzecki> zyga: thanks
[09:01] <zyga> I cannot reproduce that bug on bionic
[09:01] <zyga> trying artful
[09:15] <zyga> same
[09:16] <zyga> is anyone on artful that can reproduce that bug?
[09:16] <zyga> just running any snap should fail
[09:16] <zyga> that code is on an unconditional code path
[09:19] <mborzecki> zyga: any idea what's happening with fedora?
[09:19] <zyga> in which sense?
[09:19] <mborzecki> zyga: i mean the go build thing
[09:19] <zyga> ah
[09:19] <zyga> the one that was failing last week
[09:19] <zyga> yes
[09:20] <zyga> downstream package for gopkg.in/yaml.v2 was broken
[09:20] <zyga> I added some information about this here: https://github.com/snapcore/snapd/pull/4832#issuecomment-377539457
[09:20] <mup> PR #4832: tests: move fedora 27 to google backend <Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>
[09:20] <mborzecki> zyga: https://src.fedoraproject.org/rpms/golang-gopkg-yaml/pull-request/1 ??
[09:21] <zyga> maybe Pharaoh_Atem can help us speed up landing and releasing this
[09:21] <zyga> as it's a terribly broken package now
[09:21] <zyga> (out in stable)
[09:29] <kjackal> Hey snappy people! Is there a way to disable elf stripping?
[09:29] <zyga> kjackal: hey
[09:30] <kjackal> 2.40 is breaking at least one of our banaries and trying to see why
[09:30] <kjackal> binary is kubernetes-test
[09:31] <kjackal> hi zyga (!?)
[09:31] <zyga> kalikiana: ^ I think you know the answer
[09:34] <kjackal> Just to offer some context. Here is the build with snapcraft 2.40 with -d: https://pastebin.ubuntu.com/p/jTm7TBJH4B/
[09:35] <kjackal> and here is the segfault we are getting with builds from 2.39 vs 2.40 : https://pastebin.ubuntu.com/p/f4552kVxVK/
[09:39] <mvo> zyga: 4967 needs a "review" :)
[09:47] <zyga> OH
[09:47] <zyga> ah :)
[09:48]  * zyga mvo: #4938 needs a review as well
[09:48] <mup> PR #4938: release-tools: add repack-debian-tarball.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/4938>
[09:48] <mup> PR snapd#4967 closed: release: 2.32.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4967>
[09:51] <kalikiana> kjackal: yes, you can disable it. By adding build-attributes: [no-patchelf] to the part
[09:52] <zyga> mborzecki: there are some unanswered comments on your PR
[09:52] <zyga> well, one so far :)
[09:52] <kjackal> trying that kalikiana, thanks
[09:52] <zyga> thef first one down the line , aobut the error message
[09:52] <zyga> thank you kalikiana :)
[09:53] <kalikiana> sure
[09:55]  * zyga does the review and enjoys the sunny day today :)
[09:55] <zyga> finally less clouds and more sun
[09:57] <mvo> zyga: oh, ah :) will do in a little bit
[09:57] <mvo> zyga: thanks for the merge
[10:01] <kjackal> kalikiana: zyga: seems to be working now. But I was wondering, why would snapcraft touch the banaries packaged? Seems like a bug to me. I guess I would better open a forum thread
[10:07] <kalikiana> kjackal: Yeah, a forum post sounds sensible. If you think it's doing the wrong thing we can discuss it there.
[10:08] <kjackal> thanks
[10:09] <kjackal> You definetely have your reasons I just do not know them
[10:09] <Chipaca> any other reviews i should do before going to add stuff to the error report?
[10:15] <zyga> hmm hmm
[10:16] <ogra_> hmm?
[10:17] <zyga> wondering why tests on my branch failed
[10:17] <zyga> it was supposed to work, just a re-factor
[10:17] <zyga> but let me finish one review before jumping back into my branches
[10:17] <zyga> hey ogra_, how have you been btw?
[10:18] <ogra_> busy implementing workarounds for customers ;)
[10:18] <Chipaca> ogra_: hehe
[10:18] <Chipaca> ogra_: phrasing there makes it sound like you're working around customers =)
[10:19] <ogra_> heh, well ...
[10:20] <Chipaca> la la la la can't hear you
[10:21] <Chipaca> zyga: wasn't snap-confine always in core?
[10:23] <ogra_> not in the early days (IIRC it was also called differetly in the begining)
[10:23] <ogra_> *differently
[10:26] <zyga> Chipaca: yes, that's a good point
[10:26] <zyga> Chipaca: but the one in core is correct and I have no idea how this could happen there
[10:28] <Chipaca> zyga: ＭＡＧＩＣ
[10:30] <pedronis> Chipaca: hi, #4900 needs reviews
[10:30] <mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
[10:30] <Chipaca> pedronis: hi
[10:30] <Chipaca> pedronis: ack, on it in a bit
[10:30] <pedronis> it's big, the big parts are the test changes
[10:31] <zyga> hey pedronis, power is back?
[10:31] <pedronis> yes
[10:32] <pedronis> I noticed the problems with interfaces-network on debian
[10:32] <zyga> I haven't debugged that yet
[10:33] <zyga> it's certainly random but also worrysome (related to security) and pretty frequent now
[10:33] <zyga> I suspect it is related to system key somehow
[10:37] <mvo> zyga: oh? how?
[10:37] <zyga> mvo: nothing changed in that area for a while and we introduced system key recently, I don't know what else could cause this
[10:38] <zyga> mvo: but it's just a guess, it needs to be debugged
[10:40] <mup> PR snapd#4968 opened: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
[10:40] <pstolowski> zyga: hey, thoughts on https://github.com/snapcore/snapd/pull/4968 ? some tests will need updating but before that I'd like to get +1/-1 on the approach
[10:40] <mup> PR #4968: RFC: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
[10:40] <zyga> looking
[10:42] <mvo> zyga: isn't debian itself changing?
[10:42] <zyga> mvo: debian 9 is not changing much
[10:43] <zyga> this was on stretch, not sid
[10:43] <mvo> zyga: hm, hm, ok
[11:01] <pstolowski> zyga: thanks for the quick review; apart from that minor detail re logging, do you see any big no-no?
[11:04] <cjwatson> ~/wg 40
[11:04] <cjwatson> sorry
[11:19] <zyga> pstolowski: no, it's fine I think
[11:19] <zyga> pstolowski: sorry, I will be back with reviews in a moment
[11:19] <zyga> some interruptions IRL
[11:20] <pstolowski> np, ty!
[11:39] <diddledan> snapcraft isn't working :-( (paste follows)
[11:39] <diddledan> https://www.irccloud.com/pastebin/dOwZkaZC/
[11:39] <diddledan> was fine when I went to bed last night
[11:39] <zyga> 4327 is the core snap in candidate now
[11:40] <diddledan> maybe related:
[11:40] <diddledan> https://www.irccloud.com/pastebin/Us8ymABs/
[11:40] <zyga> hmm, no idea though
[11:40] <zyga> kalikiana: more fire ^
[11:44] <zyga> ah, I found a typo in my PR
[11:44] <zyga> fixed locally, should make it green now
[11:44] <zyga> but I need to make that more robust, one sec...
[11:47]  * Chipaca -> lunch
[11:48] <zyga> sigh
[11:48] <zyga> is there any gnome extension that makes alt-tab less moronic
[11:48] <zyga> I have two virtual screens,
[11:48] <zyga> two terminals open, one on each
[11:49] <zyga> each screen also has one other unrelated window (browser and editor)
[11:49] <zyga> (again, each)
[11:49] <zyga> alt-tab from unrelated window should not jump to the terminal on another virtual screen
[11:49] <zyga> man, I hate how gnome gets most things right and consistently breaks something very very commonly used
[11:51] <zyga> and https://extensions.gnome.org/ says there is no "native connector", whatever that means
[11:53] <tomwardill> zyga: I use https://extensions.gnome.org/extension/15/alternatetab/ and you’ll need to install the extension for your browser to install gnome-extensions from that site
[11:53] <zyga> I have that installed (apparently)
[11:54] <zyga> the extension for firefox that is
[11:54] <mborzecki> any idea for which snap we dump a dbus policy file in /etc/dbus-1/system.d?
[11:54] <zyga> mborzecki: mmm
[11:54] <zyga> let me look
[11:54] <mborzecki> i've tried some of the test-snapd-* ones but no luck so far
[11:55] <zyga> mborzecki: anything that uses dbus backend would
[11:55] <mborzecki> zyga: hmm test-snapd-dbus-{consumer,provider} did not (at least on arch)
[11:55] <zyga> mborzecki: oh, that's very weird
[11:55] <zyga> let me try quickly
[11:58] <zyga> hmm
[11:58] <zyga> `func (iface *dbusInterface) getAttribs(attribs interfaces.Attrer) (string, string, error) {`
[11:58] <zyga> need to name the return values
[11:58] <mborzecki> heh :)
[11:58] <mborzecki> probably, (ok, ok, not-so-ok)
[11:59] <zyga> mborzecki: so dbus services need a policy only if they are on the system bus
[12:00] <zyga> and the snaps you mentioned use the session bus
[12:00] <zyga> so you'd have to find one that uses bus: system
[12:04]  * zyga found one more bug the refactoring has introduced
[12:04] <mup> Bug #1760841 opened: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:New> <https://launchpad.net/bugs/1760841>
[12:04] <zyga> more interesting than just a bug
[12:04] <zyga> oh
[12:04] <zyga> interesting bugs galore
[12:10] <Chipaca> mhdwtfs?
[12:11] <ogra_> a new filesystem !
[12:12] <zyga> wtffs
[12:12] <zyga> oh
[12:12] <zyga> that's frelling interesting
[12:12] <zyga> https://romanrm.net/mhddfs
[12:12] <zyga> looks like another overlayfs?
[12:12] <diddledan> yaffs = yet another ferking file system?
[12:13] <diddledan> was yaffs invented by SuSE? :-p
[12:13] <zyga> mtfs: me too file system ;)
[12:13] <diddledan> lol
[12:13] <zyga> anyway, I need to fix this bug
[12:13] <ogra_> not overlay ... but union
[12:13] <diddledan> htfs - hashtag filesystem
[12:13] <zyga> yeah, overlay can do unions today
[12:13] <ogra_> indeed
[12:13] <zyga> everything-in-a-box filesystem
[12:14] <ogra_> but that just looks like another unionfs-fuse stepchild
[12:14] <diddledan> we missed April the 1st to launch our new bhfs - black hole file system. it's effectively >/dev/null
[12:14] <zyga> diddledan: lol, indeed
[12:14] <zyga> ogra_: wait for our own snapdfs
[12:14] <zyga> it's really coming
[12:14] <ogra_> oh my
[12:15] <zyga> (not april 1st)
[12:15] <ogra_> as if we had not more pressing issues to fix :P
[12:16] <zyga> it will help a lot
[12:17] <ogra_> well, not with the issues we're facig at customers :) but yeah
[12:17] <zyga> ogra_: hey, we released the fix for /dev/ttymcsN
[12:18] <ogra_> yeah, saw that
[12:18] <ogra_> is that already ib stable ?
[12:18] <ogra_> *in
[12:18] <zyga> ogra_: no, needs to go through testing
[12:19] <ogra_> yeah, thats what i thought
[12:19] <zyga> should be out soonish though
[12:19] <ogra_> yep
[12:20] <zyga> mvo: we need to fix https://bugs.launchpad.net/snappy/+bug/1760841 for .3
[12:20] <mup> Bug #1760841: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1760841>
[12:21] <zyga> mvo: this prevents snapd from starting :/
[12:21] <zyga> mvo: the bug here is that when we cannot parse fstab we cannot start up
[12:21] <zyga> I didn't expect that
[12:24] <zyga> ogra_: I'm sure some of the issues faced by our customers will be addressed with layouts and the snapdfs idea will make that easier to work with, we could essentially allow merging content in arbitrary ways (finally)
[12:24] <zyga> this would eliminate almost all reasons to patch or alter software with configuration
[12:25] <pedronis> Chipaca: thx for the review
[12:25] <ogra_> zyga, well, main issues atm are autoconnecting interfaces on first boot, and disabling of console-conf (which michael seems to be tackling atm)
[12:26] <ogra_> also an option to disable the assertion auto-importer ... gadget updates ...
[12:26] <zyga> ogra_: one of those, the auto-importer, why is that an issue
[12:26] <ogra_> zyga, some customers want a 100% locked down device
[12:27] <zyga> aha, I see
[12:27] <zyga> so not performance related
[12:27] <ogra_> with no way to insert anything, not even a valid assertion
[12:27] <zyga> well, only they can issue assertions :)
[12:27] <ogra_> well, also performance
[12:27] <mvo> zyga: looking at the bug now
[12:27] <zyga> thank you mvo
[12:28] <zyga> ogra_: how is that performance critical?
[12:28] <ogra_> zyga, thats not the highest prio though ... autoconnecting is most important (saves one of the build.sh script hacks) atm
[12:28] <zyga> ogra_: I think that was the missing bit that we didn't understand when that PR was closed
[12:29] <zyga> yeah, the auto-connect is something I totally agree iwth
[12:29] <zyga> *wtih
[12:29] <zyga> *with :)
[12:29] <mvo> zyga: do you think I could push my suggestion for 4930?
[12:29] <zyga> looking
[12:29] <mvo> ogra_: iirc auto-connect from the gadget is something that pedronis will work on next
[12:29] <zyga> yeah, go for it, great idea
[12:30] <mvo> zyga: cool, thank you. but 176... first, looks more important
[12:30] <ogra_> zyga, it mounts all attached devices on every boot (and also falsely mounts XrpmbX and XbootX partitions (and fails since they are not mountabe ... but that causes a systemd timeout counter)
[12:30] <ogra_> )
[12:30] <ogra_> zyga, but it isnt the super imortant thing anyway
[12:30] <zyga> ogra_: is this attached to the bug report? this is relevant
[12:31] <ogra_> as i said ... console-conf and auto-connect are high prio ... but seems they are properly on the TODO
[12:31] <zyga> mvo: it basically is this:
[12:31] <zyga>  Apr 03 13:43:33 asd snapd[4016802]: 2018/04/03 13:43:33.378103 helpers.go:115: error trying to compare the snap system key: cannot parse /etc/fstab: expected between 3 and 6 fields, found 1
[12:31] <zyga> when this happens we mustn't die
[12:31] <ogra_> zyga, i think i added it to the original description
[12:31] <zyga> thanks!
[12:31] <pedronis> mvo: yes,  need G-ustavo back to discuss syntax, but yes is next on my list after being done with 2.32.x stuff
[12:31] <ogra_> zyga, it is the "#" (your fstab issue)
[12:32] <zyga> oh?
[12:32] <zyga> hmmm but don't we ignore those?
[12:32]  * zyga looks
[12:32] <ogra_> how silly can you be to require a # sign in your fs line
[12:32] <zyga> ah
[12:32] <zyga> yes
[12:32] <zyga> man, is that how this operates
[12:32] <zyga> foo# /some/other/shit?\
[12:32] <ogra_> i think no space
[12:32] <zyga> thank you ogra, I totally missed that
[12:32] <ogra_> foo#/some/other/shit
[12:33] <mvo> zyga: hm, I think I know what is going on
[12:33] <mvo> zyga: with the statup issue
[12:33] <zyga> I see
[12:33] <zyga> mvo: thank you
[12:33] <zyga> mvo: if you focus on this I will fix the parser
[12:33] <zyga> ogra_: this is interesting (from man fstab):               mount(8) and umount(8) support filesystem subtypes.  The subtype
[12:33] <zyga>               is defined by '.subtype' suffix.  For example 'fuse.sshfs'. It's
[12:33] <zyga>               recommended  to  use subtype notation rather than add any prefix
[12:33] <zyga>               to the first fstab field  (for  example  'sshfs#example.com'  is
[12:33] <zyga>               deprecated).
[12:34] <ogra_> aha
[12:34] <ogra_> well, there you go .. deprecated
[12:34] <ogra_> (though i'm surprised this was ever valid)
[12:34] <zyga> especially since the suffix is ... empty
[12:34] <zyga> this is going to be fun for parsing
[12:34] <ogra_> ŷeah
[12:35] <zyga> ogra_: that field is out of spec but I guess reality trumps specs
[12:36] <zyga> and trump trumps reality
[12:36] <zyga> and reality will trump trump eventually
[12:36] <zyga> :-)
[12:36] <zyga> brb, tea time
[12:36] <ogra_> hopefully ...
[12:42] <mup> PR snapd#4969 opened: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
[12:46] <vidal72[m]> it would be nice to have snapd in debian stable backports https://backports.debian.org/ , I'm little afraid of using it from normal repos
[12:46] <vidal72[m]> flatpak is there already
[12:51] <zyga> vidal72[m]: on debian we benefit from reexec
[12:51] <ogra_> vidal72[m], snapd should re-exec itself to the binary from the core snap if this is newer so you should automatically always get the latest
[12:51] <zyga> vidal72[m]: but yeah, no disagreement
[12:51] <ogra_> vidal72[m], "snap version" will tell you
[12:51] <zyga> and some things cannot be fixed with reexec
[12:52] <ogra_> zyga, huh ? you mean it wont bring us world peas ?
[12:53] <cwayne> That's a lot of peas
[12:53] <ogra_> not *that* many https://imgur.com/gallery/MQWyj
[12:53] <vidal72[m]> zyga ,ogra_ : thx, I may try it
[12:56] <cwayne> ogra_: nice
[12:56] <ogra_> :)
[13:02] <kalikiana> diddledan: zyga: I just saw this before reading this. The `lxc push` seems to be failing consistently as if cleanbuild's source tarball didn't exist... I'm investigating what's going on there.
[13:03] <zyga> kalikiana: thank you
[13:03] <diddledan> \o/
[13:18] <mvo> cachio: (for later) is it possible to run the sru validation against https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+sourcepub/8895866/+listing-archive-extra ? (2.32.2 from the ppa:snappy-dev/image) ? it would be great to know if the issues we saw with the sru validateion for 2.31 is now fixed
[13:23] <zyga> mvo: the converstaion is spread among two PRs: https://github.com/snapcore/snapd/pull/4868 and https://github.com/snapcore/snapd/pull/4957
[13:23] <mup> PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
[13:23] <mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
[13:35] <zyga> mvo: the tofu-meat is in this comment: https://github.com/snapcore/snapd/pull/4957#pullrequestreview-108131063
[13:35] <mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
[13:53] <kalikiana> diddledan: zyga FYI reported it here after narrowing it down a bit https://github.com/lxc/lxd/issues/4394
[13:54] <mvo> zyga: thank you
[13:54] <mvo> cachio: let me know if it is possible to run the sru vadlidation (or even just the subset that failed in 2.31) against the 2.32.2 ppa deb, if that is possible and the results are green I will do the sru based on 2.32.2 today
[13:55]  * kalikiana now lunch
[13:57]  * zyga -> walk
[13:57] <zyga> kalikiana: thank you, will read soon
[14:02] <pedronis> mvo: #4900 is the new API switch PR
[14:02] <mup> PR #4900: many: use the new install/refresh API by switching snapstate to use store.SnapAction <Critical> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4900>
[14:26] <oSoMoN> jdstrand, hey, would you mind commenting on https://bugzilla.mozilla.org/show_bug.cgi?id=1449594#c9 ?
[14:33] <mvo> zyga: hey, whats the latest on user-mounts? I am asked in a HO about this right now
[14:36] <mup> PR snapd#4970 opened: Add SocketUser and SocketGroup options <Created by guilhem> <https://github.com/snapcore/snapd/pull/4970>
[14:42] <jdstrand> oSoMoN: there are no current plans to mount /tmp/.X11-unix into the snap's mount namespace since X is typically accessed via an abstract socket. I guess the request is "since we are special and use 'allow-sandbox: true' and can unshare() the network namespace, we break because now we don't have access to the abstract socket and .X11-unix isn't in /tmp either"
[14:43] <cachio> mvo, sure, I'll run that
[14:44] <jdstrand> oSoMoN: the simple answer is "don't do that and you get the abstract socket". I'm not sure what the network namesapce is giving them over apparmor mediation, but maybe they are concerned about devmode classic distro
[14:44] <jdstrand> oSoMoN: this requires a forum topic. it isn't a trivial request
[14:46] <mvo> cachio: great, please keep me updated!
[14:51] <oSoMoN> jdstrand, ack, that makes sense. it looks like they have a solution (not unsharing) even when /tmp/.X11-unix is not mounted in the snap's namespace, so that's alright. Can you just comment on the bug to state that there are no current plans to mount /tmp/.X11-unix, or shall I do it?
[14:52] <alexlarsson> Relying on abstract sockets is kinda ass
[14:52] <jdstrand> oSoMoN: well, just cause there aren't current plans doesn't mean there couldn't be
[14:52] <alexlarsson> I'm recommending everyone to stop listening to them, because they are not properly sandboxed
[14:53] <jdstrand> apparmor has mediation for abstract sockets with an out of tree patch (eg, Ubuntu, its derivatives and Solus have it). we are in the process of upstreaming that
[14:53] <alexlarsson> Sure, but not everyone uses apparmor
[14:54] <jdstrand> sure, hence the 'devmode classic distro'
[14:54] <alexlarsson> abstract namespaces predate /run and are really made deprecated by it
[14:54] <alexlarsson> since that is also auto-cleaned up, and additionally allows per socket access rights
[14:55] <alexlarsson> And is properly namespaceable
[14:58]  * zyga is back
[14:59] <zyga> hey alexlarsson, I'm very happy to see you here
[15:23]  * zyga is happy to see green tests on #4889 
[15:23] <mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
[15:24] <zyga> but it needs some more love before I'm happy with it
[15:24] <zyga> mvo: about https://github.com/snapcore/snapd/pull/4969/files
[15:24] <mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
[15:25] <zyga> I think we should return the error but log it at the caller
[15:25] <zyga> as otherwise we neuter the whole error value
[15:25] <zyga> ah, wait, actuall
[15:25] <zyga> actually, hmmm
[15:25]  * zyga thinks
[15:28] <diddledan> is there any way to use snapcraft until lxd 3.1 comes along without uninstalling the lxd snap to clear it's configuration??
[15:28] <diddledan> I can't rollback because: error: The database schema is more recent than LXD's schema.
[15:29] <zyga> diddledan: doesn't lxd use $SNAP_DATA for the database location?
[15:29] <diddledan> yes
[15:31] <diddledan> it looks like the 2.0/* channels don't have the 2.21 release which is what I was running previous to the refresh
[15:32] <diddledan> actually using `snap revert` to get to 2.21 now tells me: error: Error creating database: schema version '37' is more recent than expected '36'
[15:32] <diddledan> I think whoever is in charge of lxd has made a mess
[15:32] <nacc_> stgraber: --^ :)
[15:33] <diddledan> :-p
[15:35] <diddledan> shouldn't the database be backed-up by snapd so that reverts actually revert the database, too??
[15:35] <cachio> mvo, the errors we used to see on sru are not happening with
[15:35] <cachio> 2.32.2
[15:35] <diddledan> it looks to be being stored in $SNAP_COMMON
[15:36] <cachio> mvo, there are some problems to run on 17.10 which I have to fix
[15:40] <stgraber> diddledan: snapcraft will be fixed in the next hour or so
[15:41] <stgraber> diddledan: LXD can't be downgraded, we used to revert the database but then the rest of the data couldn't be read, so now we just don't allow it ever
[15:41] <diddledan> hmm
[15:41] <diddledan> ok
[15:41]  * diddledan twiddly diddly
[15:43] <mvo> cachio: yay, thats encouraging that most of the errors are fixed. can you pastebin the 17.10 errors?
[15:43] <cachio> mvo, cannot find the linux-image-extra-4.10.0-20-generic
[15:43] <mvo> cachio: i.e. I assume we need a 2.32.3 with the sru fixes?
[15:43] <mvo> cachio: oh, heh :)
[15:44] <mvo> cachio: thanks for finding this, do we hardcode this path?
[15:44] <mvo> cachio: eh, package name
[15:44] <cachio> yes
[15:44] <cachio> I'll push a fix
[15:45] <cachio> mvo,  but it is a test problem
[15:45] <cachio> so I can patch that locally and run the tests
[15:45] <mvo> cachio: thank you! once the fix is up I will prepare/sru 2.32.3
[15:46] <cachio> ok
[15:49] <zyga> mvo: what's the timeline for 2.32.3
[15:49] <zyga> I can prepare the 2nd part of the fix soon, just driving home now
[15:52] <vidal72[m]> jdstrand: I would prefer snap doesn't use abstract x socket https://forum.snapcraft.io/t/xorg-abstract-socket-is-mandatory-for-running-snaps/4580
[16:04] <jdstrand> oSoMoN (cc vidal72[m]): I didn't answer your question because it is a matter of priority as opposed to me saying 'yes' or 'no' (tbh, I wouldn't probably be the one to implement it, but I would review it). this is why I suggested a forum topic. perhaps add to vidal72[m]'s
[16:05] <oSoMoN> ack
[16:08] <mup> PR snapd#4971 opened: errtracker: add more fields to aid debugging <Created by chipaca> <https://github.com/snapcore/snapd/pull/4971>
[16:08] <jdstrand> oSoMoN: we aren't avoiding the named socket for security reasons. we just haven't needed it since the abstract is there
[16:08] <Chipaca> jibel: ^^ fwiw (but i assume you're getting pinged via github and the forum on this already =)
[16:08] <mvo> pstolowski: you have some feedback in 4940, looks reaonable to me, I wonder if we need gustavo for this or if we can just go ahead
[16:12] <pstolowski> mvo: thanks for you review! i'd like Gustavo's opinion on the overall approach, afaict he hasn't really evaluated the approach I described in the forum post
[16:12] <mvo> pstolowski: ok
[16:15] <mup> PR snapd#4911 closed: daemon,client: add build-id to /v2/system-info <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4911>
[16:15] <mvo> pedronis: I'm halfway through 4900, looks good so far and the non-test code is less than I expected it to be
[16:20] <zyga> mvo: you now have a review on https://github.com/snapcore/snapd/pull/4969
[16:20] <mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
[16:22] <zyga> jdstrand: hey,  have you seen https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1760416
[16:22] <mup> Bug #1760416: dropping privs did not work: Invalid argument <amd64> <apport-bug> <artful> <wayland-session> <snapd (Ubuntu):New for zyga> <https://launchpad.net/bugs/1760416>
[16:22] <zyga> I'm very puzzled why that could ever fail
[16:27] <cachio> mvo, are you pushing 2.32.3 to beta too?
[16:29] <zyga> mvo: is 2.32.3 already done?
[16:29] <mup> PR snapcraft#2046 opened: lxd: specify arch in lxc image list command <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2046>
[16:29] <zyga> I haven't fixed the fstab parser error (though your fix is sufficient, though not merged either)
[16:31]  * kalikiana wrapping up for today
[16:33] <kenvandine> alexlarsson, it was great to see the snap support PR for xdg-desktop-portals merged today
[16:33] <jdstrand> zyga: give me a minute, it seems I got the lxd 3.0 snap and things are broken
[16:35] <jdstrand> that's weird. 'snap interfaces lxd' shows nothing
[16:35] <zyga> Oh
[16:36] <zyga> Snap was not mounted or onterface was inwalidów?
[16:36] <zyga> Invalid
[16:36] <zyga> But sure, no rush
[16:36] <jdstrand> the snap doesn't show as broken this time
[16:37] <jdstrand> I have 16-2.32.2
[16:38] <jdstrand> I stopped and started snapd and it seems to be back
[16:39] <jdstrand> then I needed to disconnect/connect
[16:39] <jdstrand> weird
[16:51] <zyga> jdstrand: weird
[16:51] <zyga> jdstrand: are you on bionic?
[16:54] <jdstrand> zyga: the seteuid or setegid calls could fail for a number of reasons (see man seteuid)
[16:54] <jdstrand> zyga: I am
[16:55] <jdstrand> zyga: I responded to the bug
[16:58]  * zyga breaks because kids are getting crazy
[17:15] <mvo> zyga, cachio no 2.32.3 yet, we need the fstab fix and the sru fix in there at least
[17:15] <zyga> what's the sru fix, the golang 1.6 thing?
[17:15] <zyga> I'm almost home, I will resume work on the fstab fix shortly, i have most of it done but I need to add some tests and see if I broke anything by changing things
[17:15] <mvo> zyga: the sru validation fails on 17.10 because of a hardcoded linux-image package name (with an abi) apparently
[17:16] <zyga> ah
[17:16] <zyga> uch
[17:21] <cachio> ok, is the sru for 2.32.2 ready?
[17:21] <cachio> tests for sru worked
[17:21] <cachio> just some known issues
[17:23] <mvo> cachio: almost ready, I think we need 4969 and then its a go (fixes a regression in 2.32.2)
[17:23] <stgraber> diddledan: should be good now
[17:24] <diddledan> yey
[17:24] <diddledan> danke
[17:25]  * diddledan pushes the button
[17:25] <cwayne> mvo: so should we be expecting another beta?
[17:25] <diddledan> yup everything good
[17:26] <mvo> cwayne: yeah, we have one (corner case) regression we need to fix
[17:26] <cwayne> mvo: ack, will keep an eye out
[17:27] <mvo> cwayne: thank you
[17:28] <cwayne> no problemo
[17:36] <mup> PR snapcraft#1997 closed: lxd: merge existing image info contents <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1997>
[17:36] <mup> PR snapcraft#2038 closed: Add an option for setting npm flags option <Created by guilhem> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2038>
[18:15] <mvo> zyga: I updated 4969 based on your suggestion
[18:49]  * zyga looks
[18:52] <zyga> #4969 needs a 2nd review
[18:52] <mup> PR #4969: interfaces: make system-key more robust against invalid fstab entries <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4969>
[19:04]  * cachio afk
[21:29] <popey> When is 2.32 going to be in stable?
[21:31] <mup> PR snapcraft#2047 opened: pluginhandler: organize in build instead of stage <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2047>
[23:59] <mup> PR snapcraft#2043 closed: cli: support exporting login to stdout <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2043>