[00:36] <mup> PR snapcraft#2381 closed: tools: copy in spread-shellcheck from snapd <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2381>
[05:40] <AuroraAvenue> seems to a docker issue.
[05:40] <AuroraAvenue> https://askubuntu.com/questions/1088170/docker-volume-error-over-snaps
[06:06] <mborzecki> morning
[06:58] <zyga> Hello
[06:59] <mborzecki> zyga: hey
[06:59] <mborzecki> zyga: seen the news/
[07:36] <zyga> Yes, interesting times
[07:36] <zyga> Some small errands in the morning
[07:36] <zyga> But I will be around shortly
[07:36] <mvo> hey zyga !
[07:37] <mvo> zyga: good morning
[07:37] <mvo> zyga: interessting times indeed
[07:37] <zyga> Hey mvo
[07:37] <zyga> How are you feeling?
[07:37] <zyga> We have one page of reviews :-)
[07:38] <mborzecki> mvo: hey, nice to have you back :)
[07:41] <sil2100> mvo: welcome back! ;)
[07:42] <mvo> mborzecki, sil2100 thank you!
[07:42] <mvo> zyga: \o/ one page of reviews - awesome
[07:42] <mvo> zyga: I feel very tired :)
[07:42] <mvo> but beside that very happy to be back and being able to code again
[07:43] <mborzecki> mvo: i've took the liberty and pushed some changes to #6039, hope you don't mind
[07:43] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[07:44] <mvo> mborzecki: thank you!
[07:44] <mvo> mborzecki: I have a look
[07:45] <zyga> I tried to as well but I could not make it pass so I aborted
[07:46] <mvo> mborzecki, zyga thank you guys! sorry that the tests were in a bad state, it was just hard to focus during the sprint but I get back to it today :)
[07:46] <mvo> I hope you had a good time?
[07:46] <mvo> anything I should know and missed?
[07:47] <mvo> sil2100: how are the stable images looking? I just promoted snapd 2.36 to stable (after a quick smoke test)
[07:59] <zyga> re
[08:00] <zyga> mvo: no worries man, you did great
[08:00] <zyga> mvo: I meant that I failed to make it better
[08:00] <zyga> it was late that night
[08:00] <zyga> mvo: we need to cherry pick one patch into stable
[08:00] <zyga> mvo: please ensure this is in the next release https://github.com/snapcore/snapd/pull/6044
[08:00] <mup> PR #6044: cmd/snap-confine: remove stale mount profile along stale namespace <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6044>
[08:00] <zyga> (of any kind)
[08:01] <pstolowski> morning guys, hey mvo, welcome back!
[08:01] <zyga> hey pawel!
[08:02] <zyga> pstolowski: did you read the news?
[08:02] <zyga> today is going to be interesting
[08:02] <zyga> and hey,
[08:02] <zyga> fedora 29 ships tomorrow
[08:02] <zyga> I wonder if people will notice that :)
[08:02] <zyga> (timing is a bit unfortunate)
[08:02] <zyga> mvo: not sure if good morning material
[08:02] <zyga> https://github.com/snapcore/snapd/pull/5170
[08:02] <zyga> this is ready and green
[08:02] <zyga> and only missing an ack from gustavo
[08:02] <mup> PR #5170: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
[08:02] <zyga> but it implements exactly what he asked for
[08:03] <zyga> so maybe we can land it?
[08:03] <mvo> hey pstolowski !
[08:04] <mvo> zyga: nice, I have a look over the open PRs next
[08:04] <zyga> woot, thank you :)
[08:04] <zyga> I will work on user mounts, so many little things have landed already
[08:04] <zyga> I need to run an errand around 11-13
[08:04] <zyga> but otherwise I will be here
[08:05] <mvo> zyga: anything else we need in 2.36?
[08:05] <zyga> mvo: perhaps but not from me
[08:05] <zyga> mvo: I think there are some things though
[08:05] <zyga> but my mind is very rusty still
[08:05] <zyga> we need to check the regression
[08:05] <pstolowski> zyga: ibm&redhat, or something else?
[08:05] <zyga> but I believe there was something else as well
[08:05] <zyga> pstolowski: yep
[08:05] <mvo> zyga: no worries, I will check if anything is marked
[08:05] <zyga> pstolowski: anything from you for 2.36?
[08:05] <pstolowski> right
[08:06] <kjackal> https://github.com/kubeflow/kubeflow/issues/1854
[08:07] <zyga> mvo: perhaps cherry pick https://github.com/snapcore/snapd/pull/5739 if feasible
[08:07] <mup> PR #5739: interfaces/default: don't scrub with change_profile with classic <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5739>
[08:08] <pstolowski> zyga: nothing new from me for 2.36, the 2 criticals i had are there already
[08:09] <zyga> pstolowski: great
[08:09] <zyga> pstolowski: in 2.36 or in edge?
[08:09] <zyga> (master)
[08:15] <pstolowski> zyga: in release/2.36
[08:23] <zyga> mborzecki: anything for 2.36 you want in badly?
[08:24] <mborzecki> zyga: not really
[08:24] <mborzecki> we're doing .1 already?
[08:26] <mvo> mborzecki: yeah, I think we need a .1 anyway
[08:27] <mvo> mborzecki: iirc zyga mentioned something critical, need to log at the branch to remember what it was exactly
[08:27] <sil2100> mvo: thanks! So far so good, they're still in testing by the cert team, I'm waiting for the US to wake up to get more info
[08:27] <sil2100> mvo: didn't see any news since Friday
[08:28] <zyga> mvo: there's this as well: https://github.com/snapcore/snapd/pull/6026
[08:28] <mup> PR #6026: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6026>
[08:28] <mvo> sil2100: thank you
[08:28] <mvo> sil2100: fwiw, the pi3 b+ works for me now with 4.15
[08:28] <sil2100> mvo: should we re-spin for the new snapd? Is there anything critical in the 2.36 for core18 GA?
[08:28] <zyga> and this but I presume this is in the release branch as well https://github.com/snapcore/snapd/pull/6027 (didn't check)
[08:28] <sil2100> mvo: \o/ ;)
[08:28] <mup> PR #6027: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <Squash-merge> <⚠ Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6027>
[08:29] <mup> PR snapd#6053 closed: cmd/snap, daemon, strutil: use CommaSeparatedList to split a CSL <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6053>
[08:30] <mborzecki> mvo: in that case https://github.com/snapcore/snapd/pull/6030 is a nice improvement and https://github.com/snapcore/snapd/pull/6049 may help resolve dbus issues we were seeing under spread
[08:30] <mup> PR #6030: cmd/snap: tweak `snap services` output when there is no services <Simple 😃> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6030>
[08:30] <mup> PR #6049: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6049>
[08:32] <mup> PR snapd#6054 opened: strutil: add extra test to CommaSeparatedList as suggested by mborzecki <Created by mvo5> <https://github.com/snapcore/snapd/pull/6054>
[08:41] <zyga> mvo: you can also perhaps consider https://github.com/snapcore/snapd/pull/6048 for 2.36 - it is a low risk bugfix
[08:41] <mup> PR #6048: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6048>
[08:46] <mvo> zyga: thanks, I check that (and the ones from mborzecki) out now
[09:01] <mup> PR snapd#6055 opened: tests/main: fixes for the new shellcheck <Created by mvo5> <https://github.com/snapcore/snapd/pull/6055>
[09:09] <zyga> Hey Chipaca
[09:30] <Chipaca> zyga: oi music turtle
[09:32] <zyga> Nice, each?
[09:32] <zyga> Eh :-)
[09:33] <Chipaca> yeah
[09:33] <Chipaca> i think this just nerd-sniped my brother :-)
[09:33] <zyga> I’m waking up, slow day ahead
[09:33] <zyga> I love things like that,
[09:33] <zyga> Exactly the software that shapes imagination
[09:34] <chesty> Hi, I was chatting to Chipaca earlier, he pin pointed the problem I'm having with an x2goclient snap I'm playing with. x2goclient is trying to open /var/lib/gdm3/.ssh/known_hosts when trying to open a connection (it uses libssh), my user isn't in /etc/passwd, it's on freeipa and the last entry in /etc/passwd is the gdm user with the home /var/lib/g
[09:34] <chesty> dm3. So it appears libssh is trying to find my users home dir, it isn't found in /etc/passwd so it uses the home dir of the last entry in /etc/passwd.
[09:35] <Chipaca> zyga: ^ is anything we're doing using the last entry in /etc/passwd when it doesn't find something?
[09:35] <Chipaca> or is that libssh?
[09:35] <zyga> Hmmmmm
[09:35] <zyga> That would be weird, let me think and look
[09:35] <Chipaca> chesty: did you add a line to /etc/passwd to check it was the last line and not some even weirder fluke?
[09:36] <Chipaca> chesty: when we talked last we were talking about the qt libs, where did libssh enter? is libssh qt?  (i wouldn't think so)
[09:36] <zyga> ^ smart idea!
[09:36] <Chipaca> maybe it was there all the time and i missed it =)
[09:37] <chesty> Chipaca, I'll do that now. btw before I was looking at x2goclients source code, it is using QDir::homePath, but I believe opening known_hosts would be done by libssh which x2goclient uses, it tunnels everything through ssh
[09:39] <mvo> Chipaca: hey, good morning (have nothing for you, just want to friendly say hello :)
[09:40] <Chipaca> mvo: hey! good morning =) aren't you going to take a day off or seven?
[09:41] <mvo> Chipaca: yes! wed->fri I will be off
[09:42] <mvo> Chipaca: but today and tomorrow I work or I will fall asleep the entire day, i.e. fighting jetlag this way :)
[09:42] <mvo> Chipaca: and it works great so far (together with copious amounts of tea)
[09:42] <Chipaca> chesty: https://git.libssh.org/projects/libssh.git/tree/src/misc.c#n223 says it should be falling back to HOME if getpwuid_r fails
[09:42] <Chipaca> mvo: ok
[09:42] <mvo> Chipaca: *but* please bear with me if I'm a bit slow today
[09:42] <mvo> (mentally)
[09:42] <Chipaca> mvo: we managed to get the PRs down to one page! despite my efforts
[09:43] <mvo> Chipaca: I notied, I was super impressed. I think this means that gustavo/samuelle/mvo should be away more often ;)
[09:44] <Chipaca> mvo: some of the ones not closed are waiting for your (plural) reviews
[09:45] <mvo> Chipaca: ok - I have a look and see what I can do to fix that :)
[09:46] <Chipaca> mvo: #6054 is gtg fwiw
[09:46] <mup> PR #6054: strutil: add extra test to CommaSeparatedList as suggested by mborzecki <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6054>
[09:46] <chesty> I added a new user to /etc/passwd which is now the last entry and x2goclient/libssh now tries to open known_hosts in that users home dir
[09:47] <mup> PR snapd#6054 closed: strutil: add extra test to CommaSeparatedList as suggested by mborzecki <Simple 😃> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6054>
[09:47] <mvo> Chipaca: looks like it got merged already :)
[09:52] <Chipaca> chesty: are you running this on amd64, and is the snap you're trying to use based on 'core'?
[09:54] <chesty> yes and idk, it's ubuntu 18.04 using the 16.04 base for the snap built in a docker
[09:54] <mup> PR snapd#6055 closed: tests/main: fixes for the new shellcheck <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6055>
[09:55] <Chipaca> chesty: right
[09:55] <Chipaca> so
[09:55] <Chipaca> that ssh_get_user_home_dir is buggy
[09:55] <chesty> and I believe this might  explain why things like spotify and skype snaps didn't work for me
[09:55] <Chipaca> chesty: I did this: https://pastebin.ubuntu.com/p/nwTc45hDft/
[09:56] <Chipaca> chesty: then I build and run it like this: gcc -Wall -o q q.c && sudo -u \#12345 ./q
[09:56] <mup> Bug #12345: isdn does not work, fritz avm (pnp?) <isdnutils (Ubuntu):Fix Released by doko> <https://launchpad.net/bugs/12345>
[09:56] <Chipaca> chesty: and that returns the last entry in /etc/passwd
[09:57] <chesty> wow, you're a machine. I can't even open my editor that quick
[09:57] <Chipaca> and indeed, the manpage for getpwuid_r says
[09:57] <Chipaca> If no matching password record was found,  these  functions  return  0  and
[09:57] <Chipaca>        store NULL in *result.  In case of error, an error number is returned, and NULL is st
[09:58] <Chipaca> it's checking for error, but not for nothing-found
[09:58] <chesty> sounds like you get to submit a pull request to libssh and earn another notch on your belt
[09:58] <Chipaca> that check hsould be   if (rc != 0 || pwdbuf == NULL) {
[09:59] <Chipaca> yeah, i'm on it
[09:59] <Chipaca> I wonder if actual ssh has the same issue
[09:59] <Chipaca> how do i send a pull request to libssh though
[09:59]  * Chipaca looks
[10:01] <mborzecki> Chipaca: hopefully not another cve for libssh :)
[10:05] <mup> PR snapd#6056 opened:  cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6056>
[10:14] <mborzecki> #6039 is green :)
[10:14] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[10:18] <zyga> mborzecki: approve it :)
[10:19] <mborzecki> zyga: heh pushed too many patches there
[10:19] <zyga> indeed,
[10:19]  * zyga did 2nd coffee
[10:19] <zyga> today I feel so sleepy I can barely keep my eyes open
[10:19] <zyga> what's wrong :/
[10:22] <zyga> mvo: are there any agreements on 5845 (dot-files)
[10:25] <mvo> zyga: unfortunately not, I will try to come up with a better name today
[10:25] <mvo> zyga: and propose that and see what happens
[10:25] <zyga> no worries, thank you for letting me know
[10:25] <mvo> mborzecki: \o/ for 6039
[10:25] <zyga> with 23 PRs left we can easily go after what's left :)
[10:27] <mvo> zyga: yeah
[10:28] <Chipaca> chesty: https://bugs.libssh.org/T118
[10:29] <Chipaca> chesty: and if you want you can apply that patch locally to build your snap
[10:40] <chesty> firstly, legen, wait for it,  dary.  Secondly, I might do that soon, I will need to learn how to build a package in a snap first.  In the meantime I'm going to work around it by modifying /etc/passwd. I still haven't got x2goclient to work, now it's complaining about a missing lib, /usr/lib/libXcomp.so.3, I added ilibxcomp3 to stage-packages but it
[10:40] <chesty> 's still complaining about it missing, ldding it it looks like libpng12.so.0 is missing. I wonder if that's a package dependency bug
[10:44] <mup> PR snapd#6057 opened: snap-exec: add comment about usage of ReadInfoExceptSize() <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6057>
[10:45] <cjwatson> Chipaca: OpenSSH does not have the same problem, as far as I can see
[10:46] <cjwatson> I don't think they have much if any code in common
[10:46] <Chipaca> cjwatson: tks
[10:46] <mup> PR snapd#6058 opened:  cmd/snap-exec: don't fail on some try mode snaps (2.36) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6058>
[10:50] <mborzecki> hm postgresql* snap does not have ny services declared
[10:54] <Chipaca> mborzecki: I think that's because they need to run as non-root
[10:54] <mup> PR snapd#6056 closed:  cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection (2.36) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6056>
[10:57] <chesty> I don't understand what's going on, I added libpng12-0 to stage-packages but it's not finding its way into the snap.
[11:04] <tomwardill> hi! pre-refresh hooks (again). I have a snap installed that does not have a pre-refresh hook. If i then install a new version that does, the hook does not run. It looks like the pre-refresh hook runs in the 'installed' context, not the 'to-be-installed' context. Anything I can do to fix that?
[11:07] <Chipaca> tomwardill: that does not sound like something that needs fixing
[11:07] <pstolowski> tomwardill: use post-refresh hook
[11:07] <pstolowski> it runs in the new snap
[11:07] <tomwardill> pstolowski: can a post-refresh hook reject the refresh?
[11:08] <tomwardill> contextL I
[11:08] <tomwardill> context: I'm trying to avoid upgrading to a version that requires database features that we don't have in the old version
[11:10] <zyga> tomwardill: who ships the database4?
[11:10] <zyga> tomwardill: perhaps epochs could be used to solve that?
[11:11] <tomwardill> zyga: not us, we configure it, but using a connection that is provided by the machine admin
[11:11] <pstolowski> tomwardill: yes it should, it's run as one of many tasks handling the transition to a new revision and if it fails, we undo everything and go back to the previous revisions
[11:11] <tomwardill> yeah, it's starting to look like an epochs use case
[11:11] <zyga> aha
[11:11] <zyga> tomwardill: given what you said I don't think epochs can do that
[11:11] <tomwardill> except we don't have superuser control, so there's not a lot we can do about it either way
[11:11] <chesty> should libraries in usr/lib/x86_64-linux-gnu/ in the snap be found?
[11:12] <tomwardill> zyga: ah, right.
[11:12] <tomwardill> pstolowski: aha, I didn't realise post-refresh could do that, that sounds more like what I'm after then.
[11:12] <zyga> chesty: if snapcraft arranges for it yes
[11:12] <zyga> they are not added to LD_LIBRARY_PATH automatically
[11:12] <chesty> oh, well there's my problem
[11:13] <tomwardill> pstolowski, zyga: I'll give post-refresh a poke and see if that will do what I'm after. Thanks for the help :)
[11:13] <pstolowski> tomwardill: sure, yw. simply make it exit with !=0 to make entire change fail
[11:16] <Chipaca> chesty: that's usually done by a wrapper script
[11:17] <Chipaca> tomwardill: pstolowski: zyga: note epochs aren't there yet
[11:17] <chesty> Chipaca, will this work too? https://stackoverflow.com/questions/42991501/snapcraft-custom-ld-library-path
[11:17] <tomwardill> ah yeah, that is also a problem for that approach :)
[11:18] <Chipaca> chesty: given that that kyle is this kyrofa, i'd say it'll either work or you can harass him (you win either way!)
[11:19] <Chipaca> chesty: although you two are mutually antipodean
[11:19] <Chipaca> so good luck
[11:19] <Chipaca> (well, not exactly, kyrofa might be -8 or something)
[11:25] <pstolowski> cachio: hey!
[11:25] <pstolowski> cachio: fyi, i've found the way for passing custom serial number to serial port adapters created with qemu
[11:28] <mvo> has anyone seen:
[11:28] <mvo> FAIL: <autogenerated>:1: ctxSuite.TestWriter
[11:28] <mvo> context_test.go:50:
[11:28] <mvo>     // but we copied things until the deadline hit
[11:28] <mvo>     c.Check(n, check.Not(check.Equals), int64(0))
[11:28] <mvo> ... obtained int64 = 0
[11:28] <mvo> ... expected int64 = 0
[11:28] <mvo> yet?
[11:28] <zyga> waaaht?
[11:28] <mvo> looks like a racy test, just happend in the snpad autobuild
[11:28] <zyga> nope
[11:29] <Chipaca> what's the what about?
[11:29] <zyga> we could use the new int checker btw but that's unrelated
[11:29] <Chipaca> that's Not() output
[11:29] <Chipaca> it can be confusing
[11:29] <Chipaca> it obtained int64(0), and it expected _not_ to obtain the "expected int64(0)"
[11:29] <zyga> yeah, I read this now
[11:30] <Chipaca> ah ok
[11:30] <Chipaca> maybe we can patch Not to prepend NOT to the 'expected' line =)
[11:30] <Chipaca> or append "... NOT!"
[11:30] <cachio> pstolowski, nice
[11:30] <cachio> do yo have an example?
[11:31] <Chipaca> ... obtained int64 = 0
[11:31] <Chipaca> ... expected int64 = 0 ... NOT!
[11:31] <cachio> I was playing with confiugration failes
[11:31] <zyga> Chipaca: that's a nice idea
[11:31] <zyga> NOT :D
[11:31] <zyga> (it's a nice idea)
[11:31] <cachio> pstolowski, to configure any kind of device
[11:31] <mvo> Chipaca, zyga btw, did we find out more about the kernel permission issue that cachio  found in 2.36 testing?
[11:31] <zyga> no
[11:31] <Chipaca> mvo: that's not on my radar at all
[11:31] <pstolowski> https://www.irccloud.com/pastebin/fDLL0JuA/
[11:31] <pstolowski> cachio: ^
[11:33] <pstolowski> cachio: and it seems undocumented.. they depcreated -serial=... option but didn't document that new one
[11:34] <mvo> Chipaca: ok, no worries, lets talk about it during the standup. I may have (sleepy) cycles for this :)
[11:35] <mup> PR snapd#6058 closed:  cmd/snap-exec: don't fail on some try mode snaps (2.36) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6058>
[11:35] <zyga> Chipaca: https://api.travis-ci.org/v3/job/447722772/log.txt
[11:35] <zyga> https://www.irccloud.com/pastebin/PyCaVZMe/
[11:35] <mvo> Chipaca: sorry for bothering you so much today, but have you seen http://paste.ubuntu.com/p/P2zHPvrFMJ/ before?
[11:35] <zyga> I think the test should have failed when "snap save. .." failed
[11:36] <zyga> missing error check?
[11:36] <zyga> Chipaca: ^ FYI that's exactly the same problem :}
[11:36] <mvo> heh
[11:38] <Chipaca> mvo: no worries
[11:38] <Chipaca> mvo: I have seen that error, but not in that test since I added the "run something from the snap" step
[11:39] <Chipaca> mvo: zyga: I'll push a PR so we get more logs if it happens again
[11:39] <mvo> Chipaca: ta
[11:43] <cachio> pstolowski, nice
[11:44] <cachio> pstolowski, is it iportant ofor you to have other information such as vendor?
[11:47] <Chipaca> mvo: zyga: there was also one that happened sporadically on amazon linux,  where the uid was -2
[11:47] <zyga> oh
[11:47] <zyga> right
[11:47] <zyga> last night
[11:47] <pstolowski> cachio: only important factor is that vendor is present and constant (doesn't get random values like serial by default), which seems to be the case
[11:47] <zyga> well, apart from the weekend that is
[11:48] <Chipaca> mvo: zyga: I maintain what I said on Friday about that: it's my considered opinion, after much and careful thought, that i can't even.
[11:48] <Chipaca> * not that much thought
[11:51] <Chipaca> zyga: question: given that the size from ReadInfo wouldn't be useful for trys even if it weren't dangling, why not use an Lstat instead of a Stat?
[11:51] <zyga> hmmm
[11:51] <zyga> how would stat make it better?
[11:51] <zyga> lstat that is you silly spellchecker
[11:51] <Chipaca> zyga: the problem is that the symlink is dangling, right?
[11:51] <zyga> you would stat the symbolic link itself, and?
[11:52] <Chipaca> zyga: so it doesn't error out
[11:52] <zyga> no, the problem is that symlink is controlled by the user
[11:52] <zyga> and we are in a mount namespace
[11:52] <zyga> so the user can point it a nearly arbitrary things
[11:52] <zyga> we cannot traverse it, period
[11:52] <Chipaca> zyga: how is the symlink controlled by the user?
[11:52] <zyga> Chipaca: because whoever "snap try"ies controls it
[11:52] <Chipaca> zyga: how?
[11:53] <Chipaca> zyga: the symlink is created by snapd, not by the user
[11:53] <zyga> the symlink is created by snapd to point to the directory picked by the user
[11:53] <zyga> look at the test case in that branch
[11:53] <Chipaca> ok, hold on
[11:53] <Chipaca> before we go there
[11:53] <cachio> pstolowski, ok
[11:53] <cachio> vendor is fixed
[11:53] <zyga> you can come up with creative use of "snap try /proc/..."
[11:53] <Chipaca> zyga: the stat is done to get the size of the snap
[11:53] <zyga> mhm
[11:53] <cachio> pstolowski, so it should not be  a problem
[11:53] <Chipaca> zyga: that won't work for trys
[11:54] <zyga> but under the assumption that it points to a file
[11:54] <zyga> which is not the case in try mode snaps
[11:54] <Chipaca> zyga: hold on let me finish
[11:54] <zyga> ok
[11:54] <pstolowski> cachio: most likely not, i'll now for sure when i've the test passing
[11:54] <Chipaca> zyga: if it's a symlink, we should not follow it for two reasons, it won't be what we need to get the size,  and the user  might have tricked snapd somehow
[11:54] <zyga> aha, I see the reasoning now
[11:54] <zyga> so just lstat all the time
[11:55] <Chipaca> zyga: in both cases, using lstat fixes the issue
[11:55] <zyga> and if it was a symlink, don't do more
[11:55] <zyga> yep
[11:55] <zyga> I agree
[11:55] <Chipaca> zyga: the right thing would be to do lstat, check the filename,  and fill in size if it's a regular file
[11:55] <Chipaca> keeps the api  simpler
[11:55] <Chipaca> zyga: now, about the other thing, how would you trick snapd into pointing the symlink to something it shouldn't? via a race?
[11:55] <Chipaca> hmmmm
[11:56] <zyga> no
[11:56] <zyga> not really
[11:56] <Chipaca> well, snapd does a validation before enabling it
[11:56] <zyga> what kind of validation?
[11:56] <zyga> that it looks like a snap
[11:56] <Chipaca> maybe it's a toctou
[11:56] <Chipaca> yeh
[11:56] <zyga> do we check that there are no symlinks along the way?
[11:56] <zyga> do we check afterwards?
[11:56] <zyga> can we then rm -rf /old/path
[11:56] <Chipaca> what happens if we tell it to snap try a symlink? does it normalize?
[11:56] <zyga> and then ln -s /proc/evil ?
[11:56] <Chipaca> yeah
[11:56] <zyga> yep
[11:56] <Chipaca> lots of questions
[11:57] <Chipaca> in any case the lstat is the right approach here i think
[11:57] <Chipaca> but i'd like to know the answers to these other things as well =)
[11:57] <Chipaca> zyga: should I push a pr?
[11:58] <zyga> or I can if you want me to
[11:58] <zyga> I feel sleepy and this is a good think to wake up with
[11:58] <Chipaca> zyga: +1, i'm in snapshot-ate-my-brunch land
[11:59]  * zyga hugs chipaca
[11:59] <zyga> and takes a snapshot
[11:59] <Chipaca> also need to get lunch going
[12:20] <zyga> Chipaca: https://github.com/snapcore/snapd/pull/6059
[12:20] <mup> PR #6059: snap: use Lstat to determine snap size, remove ReadSnapInfoExceptSize <Created by zyga> <https://github.com/snapcore/snapd/pull/6059>
[12:21] <mup> PR snapd#6059 opened: snap: use Lstat to determine snap size, remove ReadSnapInfoExceptSize <Created by zyga> <https://github.com/snapcore/snapd/pull/6059>
[12:21] <Chipaca> zyga: I had too much on my plate last week, but I _think_ pstolowski suggested lstat on the original pr
[12:22] <zyga> perhaps but I didn't get the idea then
[12:22] <Chipaca> i'm just now getting the bandwidth to think about it =)
[12:24] <Chipaca> zyga: it was kyrofa !
[12:24] <Chipaca> heh
[12:26] <zyga> brb
[12:32] <cachio> zyga, hey https://paste.ubuntu.com/p/9W39q9S2H4/
[12:32] <cachio> I am getting that denial on the cifs test
[12:33] <cachio> zyga, any idea if I should need to plug any other interface?
[12:36] <diddledan> cachio: https://forum.snapcraft.io/t/namespace-awareness-of-run-mount-utab-and-libmount/5987
[12:37] <mup> PR snapd#6057 closed: [RFC] snap-exec: add comment about usage of ReadInfoExceptSize() <Simple 😃> <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6057>
[12:38] <mborzecki> zyga: i'm runnig spread tests with centos branch rebased on current master and got a problem with parallel services, we do bind mounts from snap_foo to snap, seems like that whenerver the mount ns of a snap exists and we try to remove a location on the host that is bind mounted inside snap's ns we get device os resource busy
[12:38] <mborzecki> zyga: snap-discard-ns makes the problem go away
[12:39] <cachio> diddledan, nice, thanks
[12:46] <zyga> mborzecki: this is a kernel bug
[12:46] <zyga> It was fixed later
[12:46] <zyga> I doubt we can work around it
[12:46] <zyga> cachio: let me look
[12:47] <zyga> Ah, I see
[12:48] <zyga> cachio: let me know if we should do utab mount
[12:50] <cachio> zyga, I just have pushed the changes for the test
[12:50] <mborzecki> zyga: do you have a link to lp? something i could use to open a bug in rh bugzilla
[12:51] <Chipaca> standup is in ten minutes?
[12:51] <Chipaca> dang
[12:51] <Chipaca> need to re-get-used to it
[12:52] <mborzecki> w8, in 10 minutes now?
[12:53] <mborzecki> hmm, dst change
[12:53] <Dmitrii-Sh> mvo, Chipaca: tested on 2.36 https://bugs.launchpad.net/snapd/+bug/1791587/comments/7. Something is still wrong there
[12:53] <mup> Bug #1791587: snapd ignores proxy settings set via core snap <cpe-onsite> <snapd:New> <https://launchpad.net/bugs/1791587>
[12:53] <Chipaca> Dmitrii-Sh: did you (or somebody from your team) talk in SLC as we last discussed?
[12:54] <Dmitrii-Sh> Chipaca: yes, I talked to mvo about this
[12:54] <Dmitrii-Sh> he asked me to test on 2.36
[12:54] <Dmitrii-Sh> just following up
[12:54] <Chipaca> ah ok
[12:54] <Dmitrii-Sh> what we agreed on is that /etc/environment should not be touched on classic systems (it isn't now by the looks of it)
[12:55] <Dmitrii-Sh> and that this is a bug indeed \
[12:55] <Dmitrii-Sh> just needed to test on the latest to make sure as there are release notes suggesting that it was fixed
[12:56] <mvo> Dmitrii-Sh: thanks, I look into it then
[12:57] <mvo> Chipaca: context> we have the in-config proxy config now, this should work so I need to figure out where the gap is
[12:58] <Chipaca> mvo: AFAIK it fails when core isn't installed;  works ok after
[12:58] <Dmitrii-Sh> mvo: there's a simple test: install a squid proxy on a host system, launch a container with snapd and squashfuse, remove the default gateway in that container
[12:58] <Chipaca> mvo: at least that's what I got from Dmitrii-Sh week before last =)
[12:59] <Dmitrii-Sh> the container will have a route only to the local subnet for communication with the host and will be able to use a proxy
[12:59] <Dmitrii-Sh> Chipaca: I can try again
[13:00] <mvo> Chipaca: yeeah, sounds reasonable, still puzzling that it does not work without core but something to figure out :)
[13:00] <Chipaca> Dmitrii-Sh: when you built 2.36, how did you then run it?
[13:01] <mborzecki> standup?
[13:01] <Chipaca> omw
[13:01] <mborzecki> zyga: ^^
[13:02] <Chipaca> mvo: ^
[13:02] <Chipaca> cachio: ^?
[13:02] <mvo> Chipaca: need to restart pulseaduio first
[13:02] <Dmitrii-Sh> Chipaca, mvo: yes, enabling default gateway, installing core, disabling gateway and trying to download other snaps works. I can also see that snapd connects to the proxy via strace
[13:02] <mvo> JamieBennett: want to join the standup?
[13:02] <zyga> what, already?
[13:02] <zyga> sorry, joining
[13:02] <Chipaca> mvo: i thought jamie was on holiday
[13:02] <Chipaca> dunno about niemeyer
[13:03] <Dmitrii-Sh> Chipaca: ran snapcraft cleanbuild, then I copied the resulting snap to the target system, unsquashfs-ed it and rsynced the /usr/lib/snapd/* and /usr/bin/snap* to relevant system dirs
[13:03] <Dmitrii-Sh> Chipaca: snapcraft also builds a deb but it got deleted after cleanbuild
[13:04] <Chipaca> Dmitrii-Sh: this was with no snaps installed?
[13:04] <Dmitrii-Sh> Chipaca: yes, no snaps installed at first. Then I installed the core snap only and disabled the gateway
[13:04] <Dmitrii-Sh> it then started to respect the proxy settings
[13:11] <Chipaca> Dmitrii-Sh: the output of 'snap version' would be good, if you do over
[13:17] <Dmitrii-Sh> snap --version
[13:17] <Dmitrii-Sh> snap 2.36
[13:17] <Dmitrii-Sh> snapd 2.36
[13:17] <Dmitrii-Sh> series 16
[13:17] <Dmitrii-Sh> ubuntu 18.04
[13:17] <Dmitrii-Sh> kernel 4.15.0-34-generic
[13:17] <Dmitrii-Sh> Chipaca: it's in the comment here https://bugs.launchpad.net/snapd/+bug/1791587
[13:17] <mup> Bug #1791587: snapd ignores proxy settings set via core snap <cpe-onsite> <snapd:New> <https://launchpad.net/bugs/1791587>
[13:18] <Dmitrii-Sh> btw, might be worthwhile to triage this bug for tracking
[13:55] <mup> PR snapd#6060 opened: overlord/snapshotstate/backend: be more verbose when SNAPPY_TESTING=1 <Created by chipaca> <https://github.com/snapcore/snapd/pull/6060>
[14:15] <mborzecki> off to pick up the kids
[14:15] <zyga> mvo: can you look at https://github.com/snapcore/snapd/pull/5170 as a satiny check before we merge it please
[14:15] <mup> PR #5170: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
[14:16] <zyga> mvo: and if you consider it sane we could even add it to 2.36.1
[14:16] <zyga> since it is a new feature
[14:16] <niemeyer> Hey, I forgot to ask: how was the mic volume/quality?
[14:16] <mvo> zyga: I have a look, for 2.36.1 we need to squash merge it
[14:16] <zyga> that's ok
[14:16] <mvo> niemeyer: quality was good afaict
[14:17] <niemeyer> mvo: Thanks, it was an external USB mic, so wondering if it's good for htat kind of meeting too
[14:25]  * pstolowski lunch
[14:26]  * cachio lunch
[14:34]  * zyga -> lunch
[14:41] <mvo> zyga: 5170 looks fine, wonder if it makes sense to have a spread test that just double checks that the right files are created on connect etc?
[14:48] <mborzecki> mvo: thanks for pushing that patch to 6039, i missed that comment from zyga
[14:49] <mvo> mborzecki: my pleasure - thanks for all your help with this one, much more tricky than I anticipated
[15:02] <Chipaca> pstolowski: when do you want to talk about that pr?
[15:17] <zyga> mvo: I can look into that
[15:18] <mvo> zyga: thanks! something simple if fine
[15:18] <mvo> zyga: is fine
[15:21] <pstolowski> Chipaca: in 30?
[15:28] <zyga> re
[15:41] <zyga> Chipaca, pstolowski: do you want me to participate as well?
[15:45] <zyga> mvo: I wrote a test, if it passes I'll push it and merge when green
[15:46] <Chipaca> pstolowski: zyga: fine by me
[15:46] <zyga> just tell me when :)
[15:47] <Chipaca> in 12 minutes would be ok. In 2 hours would be better =) but probably too late
[15:52]  * zyga found a bug in snaps.sh make_snap
[15:52] <zyga> 12 minutes would be ok but if you want we can also do tomorrow
[15:52] <mvo> zyga: cool
[15:53] <pstolowski> it can be tomorrow morning if you prefere that Chipaca, zyga
[15:53] <Chipaca> pstolowski: zyga: tomorrow morning \o/
[15:53] <zyga> yeah, I prefer to do reviews in the morning
[15:54] <zyga> and coding in the evening
[15:54] <Chipaca> ye
[15:54] <pstolowski> sure
[16:09] <zyga> Chipaca: remember the lstat thing?
[16:09] <zyga> it regresses :D
[16:09] <zyga> https://www.irccloud.com/pastebin/xJJ4C4SL/
[16:09] <zyga> but I'd argue it doesn't regress because bind mounts are magic
[16:10] <sil2100> uugh
[16:11] <zyga> sil2100: ?
[16:15] <Chipaca> zyga: what the wha?
[16:15] <zyga> Chipaca: Lstat now shows a snap the _used_ to be broken as not broken
[16:15] <zyga> but not really because it's not really broken
[16:15] <zyga> because it works after the mv
[16:16] <zyga> so ... :)
[16:16] <Chipaca> heheh
[16:17] <Chipaca> zyga: and does it _actually_ work?
[16:17] <Chipaca> zyga: or is that snap now broken?
[16:17] <zyga> I suspect so, it's the next thing in my pipe
[16:17] <zyga> because the symlink is broke
[16:17] <zyga> but the bind mount is not
[16:17] <zyga> so why would it break?
[16:17] <zyga> just found it funny :)
[16:25] <mup> PR snapd#6061 opened: tests: fail if install_snap_local fails <Created by zyga> <https://github.com/snapcore/snapd/pull/6061>
[16:26] <zyga> Chipaca: one small for you https://github.com/snapcore/snapd/pull/6061 :)
[16:26] <mup> PR #6061: tests: fail if install_snap_local fails <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6061>
[16:35]  * Chipaca goes for a run
[16:35] <zyga> cachio: hey
[16:35] <zyga> cachio: the cifs test failed with
[16:35] <zyga> https://www.irccloud.com/pastebin/I87puih6/
[16:38] <zyga> Chipaca: it works,
[16:38] <zyga> https://www.irccloud.com/pastebin/UR39vPVm/
[16:41] <Chipaca> zyga: and with a non-trivial snap? =)
[16:41]  * Chipaca is picky
[16:44] <cachio> zyga, yes this is the error I mentioned before
[16:45] <cachio> zyga, let me re-xecute it here
[16:57] <cachio> zyga, I see this error
[16:57] <cachio> [  607.220089] audit: type=1400 audit(1540832191.979:52): apparmor="DENIED" operation="open" profile="snap.test-snapd-cifs-mount.sh" name="/run/mount/utab" pid=23728 comm="mount" requested_mask="wrc" denied_mask="wrc" fsuid=0 ouid=0
[16:57] <cachio> this denial appears with the error you displayed before
[17:04] <mup> PR snapd#6062 opened: tests: add test to ensure proxy is used even without core <Created by mvo5> <https://github.com/snapcore/snapd/pull/6062>
[17:09] <zyga> Chipaca: re
[17:09] <zyga> I think it would work with any snap because:
[17:09] <zyga> aww, I wanted to paste something but then spread session ended
[17:09] <zyga> because the mount point shows what was there originally
[17:09] <zyga> unless you start to rm file by file
[17:10] <zyga> cachio: that's an attempt to modify utab
[17:10] <zyga> cachio: we share utab with the host today so we should not modify it
[17:10] <zyga> cachio: we should probably change the interface and debug this more
[17:12] <cachio> zyga, you mean to allow access to this file as part of the interface?
[17:13] <zyga> cachio: not really, we would have to make sure that file is not really there
[17:13] <zyga> and allow the snap to read and write a fake copy
[17:17] <mup> PR snapd#6061 closed: tests: fail if install_snap_local fails <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6061>
[17:21] <cachio> zyga, ah, ok, I'll try that
[17:21] <zyga> cachio: I think this needs some changes to the interface
[17:21] <zyga> cachio: I can look at that tomorrow
[17:21] <zyga> Chipaca: so to respond to your question:
[17:21] <zyga> https://www.irccloud.com/pastebin/xgHWy2hn/
[17:21] <zyga> cachio: I was trying to say that I think the test shows that some things are probably wrong and we need to revisit the interface
[17:22] <zyga> Chipaca: as you can see the snap is not broken
[17:22] <zyga> Chipaca: not sure if I should change the test to instead rm the snap.yaml file
[17:22] <zyga> Chipaca: like this:
[17:22] <zyga> https://www.irccloud.com/pastebin/9fhnCc46/
[17:41] <zyga> we need a 2nd review on https://github.com/snapcore/snapd/pull/5982
[17:41] <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
[17:49]  * zyga EODs
[17:49] <zyga> ttyl!
[18:27] <Chipaca> zyga: change the test, but RFC it so we talk about what is going on when this happens
[18:28] <Chipaca> zyga: the question is: if this happens, and it happened by accident, what's the least surprising thing we can do so the user knows what's up
[18:29] <Chipaca> zyga: and if it happens on purpose, double-check we're not opening the door for something dumb
[18:42] <zyga> Chipaca: I pushed the change
[18:59] <Chipaca> zyga: ack
[18:59]  * Chipaca EODs, mostly
[19:02] <cachio> pstolowski, I think I have a good solution to speedup nested vm executions
[19:03] <cachio> pstolowski, I'll send you an email with the details after I can test the solution works properly
[19:13] <zyga> https://www.irccloud.com/pastebin/4tieerHP/
[19:13] <zyga> Chipaca: ^ is that the additional logs you were looking for?
[19:13] <Chipaca> zyga: they'll be in the snapd log
[19:13] <zyga> one sec
[19:15] <zyga> hmm
[19:15] <zyga> I cannot see that
[19:15] <zyga> perhaps this is the partial log from before the feature landed?
[19:15] <Chipaca> um
[19:15] <Chipaca> zyga: the feature isn't landed
[19:16] <Chipaca> it's got .99 of a review
[19:16] <zyga> aaah
[19:16] <zyga> right
[19:16] <zyga> so that's all I know :)
[19:16] <Chipaca> =)
[19:16] <zyga> I'll re-trigger it
[19:16] <Chipaca> yeah, need moar logs
[19:16] <zyga> and we should both EOD
[19:16] <Chipaca> yes
[19:16] <Chipaca> i need to make dinner
[19:16] <zyga> enjoy the evening :)
[19:16] <Chipaca> or i'll be eaten alive by feral teenagers
[19:16] <Chipaca> ttfn
[19:20] <cachio> kyrofa, hey
[20:22] <kyrofa> Hey cachio, what's up?
[20:27] <cachio> kyrofa, tomorrow I'll update images and the nested vm will change the name
[20:27] <cachio> on gce
[20:28] <cachio> it already exists and it is called ubuntu-1604-64-virt-enabled
[20:28] <cachio> and ubuntu-1804-64-virt-enabled
[20:28] <cachio> it is part of a reorg I am doing
[20:29] <cachio> both image names will be available the whole week
[20:30] <cachio> the idea is that this week we chagne the image names
[20:30] <cachio> does it work for you?
[21:27] <kyrofa> cachio, no problem at all, I'll propose the change now
[21:27] <mup> PR snapd#5170 closed: interfaces/builtin: add adb-support interface <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5170>
[21:28] <kyrofa> Thanks for the heads up!
[21:35] <mup> PR snapcraft#2387 opened: spread: change virt-enabled image name <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2387>
[21:35] <kyrofa> cachio, that ^ look okay?
[22:08] <cachio> kyrofa, the image is ready
[22:08] <cachio> so if you want to test the xenial one
[22:08] <cachio> you can so it, I'll create the bionic one now
[22:17] <cachio> kyrofa, image for bionic is ready
[22:39] <Chipaca> cachio: o/
[22:40] <Chipaca> cachio: could you send me steps for creating the image so I can repro https://forum.snapcraft.io/t/8176 ?
[22:46] <cachio> Chipaca, sure
[22:47] <cachio> Chipaca, https://github.com/sergiocazzolato/snappy-qa-jobs
[22:47] <cachio> git clone https://github.com/sergiocazzolato/validator.git
[22:47] <cachio> cd validator
[22:47] <cachio> sudo ./create.sh beta
[22:48] <cachio> Chipaca, sudo ./create.sh beta pc-amd64
[22:48] <cachio> that will create the image you need
[22:48] <Chipaca> nice
[22:48] <Chipaca> thanks
[22:48] <cachio> amd64: sudo kvm -snapshot -smp 2 -m 1500 -net nic,model=virtio -net user,hostfwd=tcp::8022-:22 -nographic -serial mon:stdio <PATH_TO_VM_IMAGE>
[22:48] <cachio> I use that command for the vm
[22:49] <cachio> Chipaca, np
[22:49] <Chipaca> cachio: this is uses ubuntu-image as in 16.04?
[22:52] <cachio> yes
[22:52] <cachio> it uses ubuntu image
[22:53] <cachio> the .deb one
[22:57] <Chipaca> cachio: how do i get the new kernel?
[22:59] <cachio> Chipaca, ahh
[22:59] <cachio> :)
[22:59] <cachio> the problem is that I created my images with the old kernel on beta
[22:59] <cachio> which was updated
[23:00] <cachio> now you can't reproduce that
[23:00] <Chipaca> cachio: well i can refresh to 18/stable or sth
[23:00] <cachio> I can share my image with you perhaps
[23:00] <cachio> yes
[23:00] <Chipaca> but that doesn't give me a delta
[23:00] <Chipaca> which might be the key difference
[23:01] <Chipaca> I'm looking at that
[23:01] <Chipaca> cachio: is it easy to build an image with beta snapd but stable kernel?
[23:01] <cachio> otherwise I can share the image I have
[23:01] <cachio> but it is gonna take some time
[23:02] <cachio> Chipaca, let me check
[23:04] <Chipaca> HAH
[23:04] <Chipaca> it's the deltas
[23:04] <Chipaca> cachio: no worrries
[23:05] <Chipaca> cachio: this is not a regression, but it is a bug
[23:05] <Chipaca> i shall fix
[23:05] <Chipaca> … somehow =)
[23:07] <cachio> Chipaca, as I see you can add which snaps you want to use
[23:07] <cachio> as a parameter
[23:08] <cachio> but I didn't test it with the kernel
[23:08] <cachio>         --channel "$CORE_CHANNEL" \
[23:08] <cachio>         --output "$WORK_DIR/ubuntu-core.img" "$EXTRA_SNAPS"
[23:08] <cachio> Chipaca, you can try that
[23:08] <Chipaca> cachio: no worries
[23:08] <Chipaca> cachio: I found the bug, as I said ^
[23:08] <cachio> Chipaca, ok
[23:08] <cachio> Chipaca, hehe
[23:08] <cachio> much better
[23:09] <cachio> Chipaca, thanks for chasing this
[23:09] <Chipaca> np
[23:09] <cachio> I'll go to the gym now :)
[23:09] <cachio> see you tomorrow
[23:10]  * cachio afk
[23:20] <mup> PR snapd#6063 opened: store: also make snaps downloaded via deltas 0600 <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6063>
[23:20] <Chipaca> cachio: ^ fwiw
[23:55] <mup> PR snapd#6064 opened: many: move regexp.(Must)Compile out of non-init functions into variables <Created by chipaca> <https://github.com/snapcore/snapd/pull/6064>