[00:36] PR snapcraft#2381 closed: tools: copy in spread-shellcheck from snapd [05:40] seems to a docker issue. [05:40] https://askubuntu.com/questions/1088170/docker-volume-error-over-snaps === cpaelzer_ is now known as cpaelzer [06:06] morning === chihchun_afk is now known as chihchun [06:58] Hello [06:59] zyga: hey [06:59] zyga: seen the news/ [07:36] Yes, interesting times [07:36] Some small errands in the morning [07:36] But I will be around shortly [07:36] hey zyga ! [07:37] zyga: good morning [07:37] zyga: interessting times indeed [07:37] Hey mvo [07:37] How are you feeling? [07:37] We have one page of reviews :-) [07:38] mvo: hey, nice to have you back :) [07:41] mvo: welcome back! ;) [07:42] mborzecki, sil2100 thank you! [07:42] zyga: \o/ one page of reviews - awesome [07:42] zyga: I feel very tired :) [07:42] but beside that very happy to be back and being able to code again [07:43] mvo: i've took the liberty and pushed some changes to #6039, hope you don't mind [07:43] PR #6039: snapstate: do not allow classic mode for strict snaps [07:44] mborzecki: thank you! [07:44] mborzecki: I have a look [07:45] I tried to as well but I could not make it pass so I aborted [07:46] 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] I hope you had a good time? [07:46] anything I should know and missed? [07:47] sil2100: how are the stable images looking? I just promoted snapd 2.36 to stable (after a quick smoke test) [07:59] re [08:00] mvo: no worries man, you did great [08:00] mvo: I meant that I failed to make it better [08:00] it was late that night [08:00] mvo: we need to cherry pick one patch into stable [08:00] mvo: please ensure this is in the next release https://github.com/snapcore/snapd/pull/6044 [08:00] PR #6044: cmd/snap-confine: remove stale mount profile along stale namespace <⚠ Critical> [08:00] (of any kind) === pstolowski|afk is now known as pstolowski [08:01] morning guys, hey mvo, welcome back! [08:01] hey pawel! [08:02] pstolowski: did you read the news? [08:02] today is going to be interesting [08:02] and hey, [08:02] fedora 29 ships tomorrow [08:02] I wonder if people will notice that :) [08:02] (timing is a bit unfortunate) [08:02] mvo: not sure if good morning material [08:02] https://github.com/snapcore/snapd/pull/5170 [08:02] this is ready and green [08:02] and only missing an ack from gustavo [08:02] PR #5170: interfaces/builtin: add adb-support interface [08:02] but it implements exactly what he asked for [08:03] so maybe we can land it? [08:03] hey pstolowski ! [08:04] zyga: nice, I have a look over the open PRs next [08:04] woot, thank you :) [08:04] I will work on user mounts, so many little things have landed already [08:04] I need to run an errand around 11-13 [08:04] but otherwise I will be here [08:05] zyga: anything else we need in 2.36? [08:05] mvo: perhaps but not from me [08:05] mvo: I think there are some things though [08:05] but my mind is very rusty still [08:05] we need to check the regression [08:05] zyga: ibm&redhat, or something else? [08:05] but I believe there was something else as well [08:05] pstolowski: yep [08:05] zyga: no worries, I will check if anything is marked [08:05] pstolowski: anything from you for 2.36? [08:05] right [08:06] https://github.com/kubeflow/kubeflow/issues/1854 [08:07] mvo: perhaps cherry pick https://github.com/snapcore/snapd/pull/5739 if feasible [08:07] PR #5739: interfaces/default: don't scrub with change_profile with classic [08:08] zyga: nothing new from me for 2.36, the 2 criticals i had are there already [08:09] pstolowski: great [08:09] pstolowski: in 2.36 or in edge? [08:09] (master) [08:15] zyga: in release/2.36 [08:23] mborzecki: anything for 2.36 you want in badly? [08:24] zyga: not really [08:24] we're doing .1 already? [08:26] mborzecki: yeah, I think we need a .1 anyway [08:27] mborzecki: iirc zyga mentioned something critical, need to log at the branch to remember what it was exactly [08:27] 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] mvo: didn't see any news since Friday [08:28] mvo: there's this as well: https://github.com/snapcore/snapd/pull/6026 [08:28] PR #6026: cmd/snap: try not to panic on error from "snap try" <⚠ Critical> [08:28] sil2100: thank you [08:28] sil2100: fwiw, the pi3 b+ works for me now with 4.15 [08:28] mvo: should we re-spin for the new snapd? Is there anything critical in the 2.36 for core18 GA? [08:28] 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] mvo: \o/ ;) [08:28] PR #6027: overlord/ifacestate: don't conflict on own discard-snap tasks when refreshing & doing garbage collection <⚠ Critical> [08:29] PR snapd#6053 closed: cmd/snap, daemon, strutil: use CommaSeparatedList to split a CSL [08:30] 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] PR #6030: cmd/snap: tweak `snap services` output when there is no services [08:30] PR #6049: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection [08:32] PR snapd#6054 opened: strutil: add extra test to CommaSeparatedList as suggested by mborzecki [08:41] mvo: you can also perhaps consider https://github.com/snapcore/snapd/pull/6048 for 2.36 - it is a low risk bugfix [08:41] PR #6048: cmd/snap-exec: don't fail on some try mode snaps [08:46] zyga: thanks, I check that (and the ones from mborzecki) out now [09:01] PR snapd#6055 opened: tests/main: fixes for the new shellcheck [09:09] Hey Chipaca [09:30] zyga: oi music turtle [09:32] Nice, each? [09:32] Eh :-) [09:33] yeah [09:33] i think this just nerd-sniped my brother :-) [09:33] I’m waking up, slow day ahead [09:33] I love things like that, [09:33] Exactly the software that shapes imagination [09:34] 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] 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] zyga: ^ is anything we're doing using the last entry in /etc/passwd when it doesn't find something? [09:35] or is that libssh? [09:35] Hmmmmm [09:35] That would be weird, let me think and look [09:35] chesty: did you add a line to /etc/passwd to check it was the last line and not some even weirder fluke? [09:36] 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] ^ smart idea! [09:36] maybe it was there all the time and i missed it =) [09:37] 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] Chipaca: hey, good morning (have nothing for you, just want to friendly say hello :) [09:40] mvo: hey! good morning =) aren't you going to take a day off or seven? [09:41] Chipaca: yes! wed->fri I will be off [09:42] Chipaca: but today and tomorrow I work or I will fall asleep the entire day, i.e. fighting jetlag this way :) [09:42] Chipaca: and it works great so far (together with copious amounts of tea) [09:42] 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] mvo: ok [09:42] Chipaca: *but* please bear with me if I'm a bit slow today [09:42] (mentally) [09:42] mvo: we managed to get the PRs down to one page! despite my efforts [09:43] Chipaca: I notied, I was super impressed. I think this means that gustavo/samuelle/mvo should be away more often ;) [09:44] mvo: some of the ones not closed are waiting for your (plural) reviews [09:45] Chipaca: ok - I have a look and see what I can do to fix that :) [09:46] mvo: #6054 is gtg fwiw [09:46] PR #6054: strutil: add extra test to CommaSeparatedList as suggested by mborzecki [09:46] 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] PR snapd#6054 closed: strutil: add extra test to CommaSeparatedList as suggested by mborzecki [09:47] Chipaca: looks like it got merged already :) [09:52] chesty: are you running this on amd64, and is the snap you're trying to use based on 'core'? [09:54] yes and idk, it's ubuntu 18.04 using the 16.04 base for the snap built in a docker [09:54] PR snapd#6055 closed: tests/main: fixes for the new shellcheck [09:55] chesty: right [09:55] so [09:55] that ssh_get_user_home_dir is buggy [09:55] and I believe this might explain why things like spotify and skype snaps didn't work for me [09:55] chesty: I did this: https://pastebin.ubuntu.com/p/nwTc45hDft/ [09:56] chesty: then I build and run it like this: gcc -Wall -o q q.c && sudo -u \#12345 ./q [09:56] Bug #12345: isdn does not work, fritz avm (pnp?) [09:56] chesty: and that returns the last entry in /etc/passwd [09:57] wow, you're a machine. I can't even open my editor that quick [09:57] and indeed, the manpage for getpwuid_r says [09:57] If no matching password record was found, these functions return 0 and [09:57] store NULL in *result. In case of error, an error number is returned, and NULL is st [09:58] it's checking for error, but not for nothing-found [09:58] sounds like you get to submit a pull request to libssh and earn another notch on your belt [09:58] that check hsould be if (rc != 0 || pwdbuf == NULL) { [09:59] yeah, i'm on it [09:59] I wonder if actual ssh has the same issue [09:59] how do i send a pull request to libssh though [09:59] * Chipaca looks [10:01] Chipaca: hopefully not another cve for libssh :) [10:05] PR snapd#6056 opened: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection (2.36) [10:14] #6039 is green :) [10:14] PR #6039: snapstate: do not allow classic mode for strict snaps [10:18] mborzecki: approve it :) [10:19] zyga: heh pushed too many patches there [10:19] indeed, [10:19] * zyga did 2nd coffee [10:19] today I feel so sleepy I can barely keep my eyes open [10:19] what's wrong :/ [10:22] mvo: are there any agreements on 5845 (dot-files) [10:25] zyga: unfortunately not, I will try to come up with a better name today [10:25] zyga: and propose that and see what happens [10:25] no worries, thank you for letting me know [10:25] mborzecki: \o/ for 6039 [10:25] with 23 PRs left we can easily go after what's left :) [10:27] zyga: yeah [10:28] chesty: https://bugs.libssh.org/T118 [10:29] chesty: and if you want you can apply that patch locally to build your snap [10:40] 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] '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] PR snapd#6057 opened: snap-exec: add comment about usage of ReadInfoExceptSize() [10:45] Chipaca: OpenSSH does not have the same problem, as far as I can see [10:46] I don't think they have much if any code in common [10:46] cjwatson: tks [10:46] PR snapd#6058 opened: cmd/snap-exec: don't fail on some try mode snaps (2.36) [10:50] hm postgresql* snap does not have ny services declared [10:54] mborzecki: I think that's because they need to run as non-root [10:54] PR snapd#6056 closed: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection (2.36) [10:57] 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] 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] tomwardill: that does not sound like something that needs fixing [11:07] tomwardill: use post-refresh hook [11:07] it runs in the new snap [11:07] pstolowski: can a post-refresh hook reject the refresh? [11:08] contextL I [11:08] 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] tomwardill: who ships the database4? [11:10] tomwardill: perhaps epochs could be used to solve that? [11:11] zyga: not us, we configure it, but using a connection that is provided by the machine admin [11:11] 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] yeah, it's starting to look like an epochs use case [11:11] aha [11:11] tomwardill: given what you said I don't think epochs can do that [11:11] except we don't have superuser control, so there's not a lot we can do about it either way [11:11] should libraries in usr/lib/x86_64-linux-gnu/ in the snap be found? [11:12] zyga: ah, right. [11:12] pstolowski: aha, I didn't realise post-refresh could do that, that sounds more like what I'm after then. [11:12] chesty: if snapcraft arranges for it yes [11:12] they are not added to LD_LIBRARY_PATH automatically [11:12] oh, well there's my problem [11:13] 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] tomwardill: sure, yw. simply make it exit with !=0 to make entire change fail [11:16] chesty: that's usually done by a wrapper script [11:17] tomwardill: pstolowski: zyga: note epochs aren't there yet [11:17] Chipaca, will this work too? https://stackoverflow.com/questions/42991501/snapcraft-custom-ld-library-path [11:17] ah yeah, that is also a problem for that approach :) [11:18] 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] chesty: although you two are mutually antipodean [11:19] so good luck [11:19] (well, not exactly, kyrofa might be -8 or something) [11:25] cachio: hey! [11:25] cachio: fyi, i've found the way for passing custom serial number to serial port adapters created with qemu [11:28] has anyone seen: [11:28] FAIL: :1: ctxSuite.TestWriter [11:28] context_test.go:50: [11:28] // but we copied things until the deadline hit [11:28] c.Check(n, check.Not(check.Equals), int64(0)) [11:28] ... obtained int64 = 0 [11:28] ... expected int64 = 0 [11:28] yet? [11:28] waaaht? [11:28] looks like a racy test, just happend in the snpad autobuild [11:28] nope [11:29] what's the what about? [11:29] we could use the new int checker btw but that's unrelated [11:29] that's Not() output [11:29] it can be confusing [11:29] it obtained int64(0), and it expected _not_ to obtain the "expected int64(0)" [11:29] yeah, I read this now [11:30] ah ok [11:30] maybe we can patch Not to prepend NOT to the 'expected' line =) [11:30] or append "... NOT!" [11:30] pstolowski, nice [11:30] do yo have an example? [11:31] ... obtained int64 = 0 [11:31] ... expected int64 = 0 ... NOT! [11:31] I was playing with confiugration failes [11:31] Chipaca: that's a nice idea [11:31] NOT :D [11:31] (it's a nice idea) [11:31] pstolowski, to configure any kind of device [11:31] Chipaca, zyga btw, did we find out more about the kernel permission issue that cachio found in 2.36 testing? [11:31] no [11:31] mvo: that's not on my radar at all [11:31] https://www.irccloud.com/pastebin/fDLL0JuA/ [11:31] cachio: ^ [11:33] cachio: and it seems undocumented.. they depcreated -serial=... option but didn't document that new one [11:34] Chipaca: ok, no worries, lets talk about it during the standup. I may have (sleepy) cycles for this :) [11:35] PR snapd#6058 closed: cmd/snap-exec: don't fail on some try mode snaps (2.36) [11:35] Chipaca: https://api.travis-ci.org/v3/job/447722772/log.txt [11:35] https://www.irccloud.com/pastebin/PyCaVZMe/ [11:35] Chipaca: sorry for bothering you so much today, but have you seen http://paste.ubuntu.com/p/P2zHPvrFMJ/ before? [11:35] I think the test should have failed when "snap save. .." failed [11:36] missing error check? [11:36] Chipaca: ^ FYI that's exactly the same problem :} [11:36] heh [11:38] mvo: no worries [11:38] mvo: I have seen that error, but not in that test since I added the "run something from the snap" step [11:39] mvo: zyga: I'll push a PR so we get more logs if it happens again [11:39] Chipaca: ta [11:43] pstolowski, nice [11:44] pstolowski, is it iportant ofor you to have other information such as vendor? [11:47] mvo: zyga: there was also one that happened sporadically on amazon linux, where the uid was -2 [11:47] oh [11:47] right [11:47] last night [11:47] 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] well, apart from the weekend that is [11:48] 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] * not that much thought [11:51] 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] hmmm [11:51] how would stat make it better? [11:51] lstat that is you silly spellchecker [11:51] zyga: the problem is that the symlink is dangling, right? [11:51] you would stat the symbolic link itself, and? [11:52] zyga: so it doesn't error out [11:52] no, the problem is that symlink is controlled by the user [11:52] and we are in a mount namespace [11:52] so the user can point it a nearly arbitrary things [11:52] we cannot traverse it, period [11:52] zyga: how is the symlink controlled by the user? [11:52] Chipaca: because whoever "snap try"ies controls it [11:52] zyga: how? [11:53] zyga: the symlink is created by snapd, not by the user [11:53] the symlink is created by snapd to point to the directory picked by the user [11:53] look at the test case in that branch [11:53] ok, hold on [11:53] before we go there [11:53] pstolowski, ok [11:53] vendor is fixed [11:53] you can come up with creative use of "snap try /proc/..." [11:53] zyga: the stat is done to get the size of the snap [11:53] mhm [11:53] pstolowski, so it should not be a problem [11:53] zyga: that won't work for trys [11:54] but under the assumption that it points to a file [11:54] which is not the case in try mode snaps [11:54] zyga: hold on let me finish [11:54] ok [11:54] cachio: most likely not, i'll now for sure when i've the test passing [11:54] 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] aha, I see the reasoning now [11:54] so just lstat all the time [11:55] zyga: in both cases, using lstat fixes the issue [11:55] and if it was a symlink, don't do more [11:55] yep [11:55] I agree [11:55] zyga: the right thing would be to do lstat, check the filename, and fill in size if it's a regular file [11:55] keeps the api simpler [11:55] 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] hmmmm [11:56] no [11:56] not really [11:56] well, snapd does a validation before enabling it [11:56] what kind of validation? [11:56] that it looks like a snap [11:56] maybe it's a toctou [11:56] yeh [11:56] do we check that there are no symlinks along the way? [11:56] do we check afterwards? [11:56] can we then rm -rf /old/path [11:56] what happens if we tell it to snap try a symlink? does it normalize? [11:56]