[02:13] Hello Can someon tell me what the snap is called for this snap ? https://uappexplorer.com/snap/ubuntu/tor [02:13] Or how I get on tor on Solus OS ? [02:16] And why is sabdfl on this channel tonite? Is he usually here ? [02:18] robert_ancell ping [02:18] AuroraAvenue, hello [02:19] Hiya - hows the far-east these days ? Anyway I waned to ask how to gt this on my Solus OS i.e. what is the snap called ? https://uappexplorer.com/snap/ubuntu/tor [02:19] AuroraAvenue, I think it's just called 'tor' (https://snapcraft.io/tor) [02:20] is that the client or what ? [02:20] I don't know any more than what it says in the description [02:20] because it says 'client' on that wesite. [02:21] robert_ancell, I need help - who do I ask here ? Who knows snaps thats in the US ? [02:21] Not sure who's online now [02:21] Well hows NZ anyways ? [02:21] Nice any sunny today [02:22] and [02:22] cool stuff - sorry to bother you. [02:22] np [02:23] elopio, ping (maybe) [02:28] oh wait - it is that one. https://paste.ubuntu.com/p/8xCc8SDYmV/ [02:31] Wit x2 there is no client [02:31] **Wait [02:31] damn it. [02:31] http://pasteall.org/pic/aa8ff4298c2c6315886afe1e236c8662 [02:32] there is no client. [02:32] no Tor client anyway - no GUI ! [02:32] feel lied to by Ubuntu again. [02:32] grumbles. [06:05] morning [07:28] morning === pstolowski|afk is now known as pstolowski [08:04] mornings [08:05] pstolowski: mvo: Chipaca: morning guys [08:10] hey pstolowski and mborzecki and zyga [08:10] Chipaca: and good morning to you as well [08:12] morning everyone [08:15] anyone objects to moving sanity check mount point to /run/snapd instead of /tmp? [08:15] eg. /run/snapd/sanity- [08:17] mborzecki: that sounds fine [08:17] mvo: from selinux perspective it'd probably be cleaner if we had a helper to check the mounts :/ [08:18] otherwise we're handing out permissions to snapd, and they don't feel enough fine grained [08:23] hey mvo [08:23] sorry for starting late, I needed to catch up sleep after the night before [08:23] but all set [08:24] mvo: I had a call with pedronis yesterday, we discussed all that's needed to get feature's exported [08:24] I'll attack that now :) [08:24] zyga: awesome [08:25] zyga: I'm ready for reviews for those [08:25] mvo: I summarized that on the PR - though in abbreviated form [08:25] let me know if you want to know more [08:25] but I think this is a very good design and we will be able to learn from that [08:25] in case we need to export more stuff like I wanted with facts originally [08:25] (facts will have the same properties) [08:27] cool [09:22] I think I found the cause of the bug I saw last night [09:22] tl;dr; broken cleanup [09:31] zyga: on fedora https://paste.ubuntu.com/p/8nYxtc2nHh/ [09:31] mmm, mount unit with selinux context? [09:32] yes [09:35] zyga: it gets more interesting https://paste.ubuntu.com/p/bRk8qdcrpM/ [09:53] mborzecki: https://github.com/snapcore/snapd/pull/6201 [09:53] PR snapd#6201 opened: tests: remove test-snapd-with-configure on restore [09:53] PR #6201: tests: remove test-snapd-with-configure on restore [09:54] I need a 2nd review on https://github.com/snapcore/snapd/pull/6159 [09:54] zyga: discarding ns in snap-mgmt would fix that too i think [09:55] PR #6159: cmd/snap-confine: handle mounted shared /run/snapd/ns [09:55] we do that but the test breaks the assumptions [09:55] it removes the snap "by hand" [09:55] I really think we should go over all tests [09:55] and over the prep/restore logic for all system [09:55] and get rid of hacks [09:56] time saved in one test is lost by time wasted debugging lots of random failures [09:57] zyga: could we discard all namespaces in restore? [09:59] mvo: do you know my position on prepare/restore? [09:59] it's all broken and backwards [09:59] pre restore in prepare [09:59] and do nothing in restore [10:00] we don't discard namespaces on core, looking at the maze that our restore logic is [10:00] s/pre restore/we restore/ [10:00] restore_suite_each is { true } [10:01] prepare_suite_each is calling reset.sh with a --reuse-core [10:01] mvo: if you are asking if we could do this better then the answer is yes [10:02] zyga: #6201 should probably go to 2.36 [10:02] PR #6201: tests: remove test-snapd-with-configure on restore [10:03] mborzecki: as in for stable update? won't hurt I suppose [10:04] zyga: can you take a look at the build log in https://github.com/snapcore/snapd/pull/6189 ? [10:04] PR #6189: daemon, vendor: bump github.com/coreos/go-systemd/activation, handle API changes (2.36) [10:04] mvo: I'm happy to make parepare/restore measureably better at some point [10:04] mborzecki: sure [10:04] build log or task failures? [10:04] zyga: ok [10:04] task failure [10:05] mborzecki: I saw that myself once [10:05] mborzecki: not 100% sure but I suspect it's a bug in how we prepare against the snapd in edge [10:05] is this branch based on older master? [10:05] mborzecki: after we removed quirks [10:05] it's 2.36 + a backport of some commits unrelated to what's failing [10:05] this bug started to show up on branches [10:05] that were using old master (before quirk removal) [10:06] mborzecki: it looks like we are taking snap-confine apparmor profile [10:06] from edge [10:06] where it has fewer permissions [10:06] I didn't debug it further though [10:06] perhaps after the repackaging magic [10:06] after snapd has ran and loaded the per-core-rev snap-confine profile [10:06] it doesn't do that again [10:07] and we run with profile from edge with code from master [10:07] er [10:07] not from master, from the branch being tested [10:07] and the branch being tested needs more permissions [10:07] I suspect if you run this with debug [10:07] and inspect the on disk per-revision profile [10:07] zyga: funny thing is, there's nothing in dmesg about denials, idk if it's surpressed or sth [10:07] you will not see the quirks permissions anymore [10:08] but that branch surely needs them since it is 2.36 [10:08] mborzecki: yes, they are supressed [10:08] they easily get rate limited-lost [10:08] maybe we should use audit instead [10:08] configure auditd with a reasoanble buffer [10:08] dunno [10:08] I use audit on suse because dmesg doesn't have denial messages [10:08] (actually have a change like this for fedora/centos) [10:09] yeah, afaik once auditd is urnning denials go there [10:09] mborzecki: if you debug this I'd love to know where the mistake is [10:09] is it in snapd [10:09] or is it in the repackaging magic [10:16] mvo: I double checked, we remove each snap in prepare [10:16] mvo: except bases [10:17] mvo: which we collect and remove at the end [10:38] mborzecki: https://botland.com.pl/pl/raspberry-pi-hat-komunikacja/10602-pi-top-laptop-modulowy-raspberry-pi-3-model-b-v2.html [10:38] :D [10:38] pi3 laptop for 446zł net [10:38] maybe ;D [10:38] would be nice for debugging pi issues without having to worry about screen/keyboard as always? [10:38] heh :) [10:39] zyga: i'm more into this https://botland.com.pl/pl/microbit-zestawy-edukacyjne/8574-microbit-go-bbc-modul-edukacyjny-cortex-m0-akcelerometr-bluetooth-led-5x5-akcesoria.html [10:39] 95zł! [10:39] not sure [10:39] what for, for kids? [10:39] yeah [10:40] have various stm32f{0,1,3} boards around but too complicated to give those to the kids [10:41] yeah [10:41] well [10:42] either your kids speak englisb [10:42] or the bbc micro has nice localized material to follow [10:42] not sure if worth the money TBH [10:44] ic Chipaca off today? [10:47] not sure [10:47] haven't seen him though [10:48] pstolowski: ^ what do you think about pi-top deal above? [10:50] zyga: oh wow, interesting! but i'd rather pick regular rpi3 [10:51] pstolowski: pi is inside :) [10:51] it's just a hat on top a regular pi [10:51] (you can also upgrade the pi eventually though given what the foundation has said I think pi3 is the end of the current line) [10:51] zyga: i know i know, but pi3 will be 3x cheaper (although, the price for this thing is very good - if that's what you want) [10:52] yeah :-) [10:52] convenience for having pi with screen/keyboard/power and less cables and fuss to worry about [10:59] pstolowski: not away, but not 100% here yet [11:07] PR snapd#6202 opened: tests: restore in restore, not in prepare [11:08] brb, cold, making hot tea [11:35] PR snapd#6201 closed: tests: remove test-snapd-with-configure on restore [11:35] snap run test-snapd-xdg-autostart.foo [11:35] cannot create temporary directory for /var/lib/snapd mount point: Permission denied [11:35] zyga: ^ is that interesting to you? [11:35] nah, why would it be :) [11:35] Chipaca: this is the same as mborzecki noticed earlier today [11:35] mborzecki: didn't you look at https://bugs.launchpad.net/snapd/+bug/1775340 ? [11:35] let me find that [11:35] Bug #1775340: Make snapd zsh aware [11:36] Chipaca: https://pastebin.ubuntu.com/p/rmcTXPjYfx/ [11:36] Chipaca: it's a bug in our prepare restore as far as I know [11:36] Chipaca: but not 100% sure as I didn't debug further [11:36] Chipaca: did https://bugs.launchpad.net/snapd/+bug/1801955 land in 2.36.1 already? [11:37] Bug #1801955: snapshot fails if unknown user in /home [11:37] Chipaca: is this also on 2.36 -based branch? [11:37] * Chipaca hugs pstolowski for doing this bug thing [11:37] zyga: yes [11:37] Chipaca: so very likely the same issue [11:37] Chipaca: you will hate me by eod ;) [11:38] Chipaca: if you cannot fix it in 30 mintues I can look, just trying to wrap up this thing that spawned into a chain of other things [11:38] pstolowski: nope [11:38] * Chipaca EODs [11:38] Chipaca: (pawel will assign all open bugs to you ;) [11:38] ha [11:38] hahaha [11:38] :D [11:38] lol [11:39] Chipaca: also, any conclusion re that macaroon thing? [11:39] pstolowski: $ git tag --contains d062f3f2d2a529b0d329df7f0f2c2713d0927af9 [11:39] pstolowski: nothing [11:39] pstolowski: so, no, not in 2.36.1 [11:39] Chipaca: k, thanks [11:40] pstolowski: re that macaroon, IIRC (but it was long ago so), we couldn't reproduce it back then either [11:40] have I mentioned that shell sucks today? [11:40] message of the day: shell sucks [11:40] there [11:40] now I feel better [11:41] for n in *.dupa; do echo $n; done [11:41] zyga: echo "shell sucks." > ~/.motd [11:41] why the hell did people did this [11:41] why why why [11:41] it's so insane [11:41] zyga: ? [11:41] Chipaca: ok, interesting :). closing then [11:41] Chipaca: run that [11:41] did you expect *.dupa [11:41] (sorry about the name) [11:41] yes [11:41] * zyga hugs chipaca [11:42] ¯\_(ツ)_/¯ [11:42] I know this happens but every time I write some more code and hit this I hate myself [11:42] zyga: stop writing that sort of code then [11:42] zyga: find -name \*.dupa ftw [11:42] that's not the same meaning :) [11:42] but yeah [11:42] zyga: -maxdepth 1 [11:42] shell is suuuucky [11:42] see [11:43] zyga: -also-i-don't-want-dotfiles [11:43] zyga: -dwim [11:43] zyga: -dwimnwis [11:43] zyga: -just-work-already [11:43] * Chipaca stops [11:46] Chipaca: git grep -E 'for [[:alpha:]]+ in .+[*].*' [11:46] Chipaca: heh [11:46] we are all guilty of that :) [11:46] * mvo hugs zyga and Chipaca [11:46] * zyga goes to fix it [11:46] eh [11:47] Chipaca: I remember a long time ago when I was teaching people unix and find - oh boy [11:47] find is really not that easy to explain at least to beginners [11:47] find: warning: you have specified the -maxdepth option after a non-option argument -name, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it). Please specify options before other arguments. [11:47] that's the point where you duck, as your students hurl their computers at you [11:50] Chipaca: this is like python range(0) returning ["range(0)"] because FU that's why [11:50] and people coding around it with isinstance(int) [11:50] eh :) [11:51] * zyga feels better by removing this from the tree [11:51] well [11:51] what [11:51] no it doesn't [11:51] Chipaca: haha - yes [11:51] right? [11:51] because it's sane [11:51] and shell is insane [11:51] zyga: no really range(0) does not return ["range(0)"] [11:52] and, in python, range objects have len, so if you need to know before looping you can [11:52] Chipaca: I know, I meant that this is equally crazy to a hypothetical python behavior where range(0) returning ["range(0)"] [11:52] ah [11:52] oh [11:52] wait i have a gif for this [11:52] http://i.imgur.com/NU3KE.gif [11:59] that is a good gif [12:03] Chipaca: I suppose this is fixed in snapd? https://bugs.launchpad.net/snapd/+bug/1751447 [12:03] Bug #1751447: snapstore and review-tools use the wrong regexp for snap names

Released by jdstrand> [12:04] Chipaca: shellcheck doesn't like loops over for [12:04] recommends while read loop [12:04] *sigh* [12:06] https://github.com/koalaman/shellcheck/wiki/SC2044 [12:06] and the solution doesn't works in sh [12:06] heh [12:07] * zyga just stops [12:07] zyga: what [12:07] pstolowski: yes, that's fixed [12:07] fix-released even [12:08] Chipaca yep, thanks [12:08] zyga: which is the for loop it doesn't like? [12:08] zyga: can you quickly assess https://bugs.launchpad.net/snapd/+bug/1803210 ? [12:08] Bug #1803210: snap's device cgroup is not discarded upon uninstall [12:08] pstolowski: true [12:08] pstolowski: ancient [12:08] Chipaca: I converted one for loop to find and ran shellcheck [12:09] zyga: hm, it's from 2 weeks ago? [12:09] pstolowski: the behavior is true since snapd v1 [12:09] we never ever did anything about those [12:09] zyga: ah, in that sense [12:10] zyga: confirm+low? [12:10] no idea what the priority is [12:10] but confirmed [12:10] fair enough [12:10] thx [12:11] if it's since forever and nothing exploded, it looks low/medium to me [12:11] yeah [12:12] zyga: can you show me? [12:12] https://www.irccloud.com/pastebin/YtRQUGYI/ [12:12] Chipaca: patch in https://github.com/snapcore/snapd/pull/6203 [12:12] PR #6203: tests: discard mount namespaces in reset.sh [12:13] Chipaca: at this rate I'm closer to saying that perl is better [12:13] zyga: that 'cannot create temporary directory for /var/lib/snapd mount' thing, is it expected to just go away or do i need to do something? [12:13] getting it repeatedly [12:13] PR snapd#6203 opened: tests: discard mount namespaces in reset.sh [12:13] Chipaca: you need to do something [12:13] it's a bug in our test code or in snapd [12:13] snap-confine profile in edge is more restrictive [12:13] zyga: so it isn't that it doesn't like for loops, it doesn't like for loops over find [12:14] i agree with it on this :-) [12:14] zyga: what's the body of the loop? [12:14] repackaging for tests and all the other jazz we do should make the profile from the branch (more permissive) active [12:14] but it seems we missed something and it's not working for real [12:14] snap-confine profile changes that remove permissions are rare so we didn't observe this before [12:14] Chipaca: loop is https://github.com/snapcore/snapd/pull/6203/commits/0e13a3077f4318091e05f90005c8f970461087c3 [12:14] PR #6203: tests: discard mount namespaces in reset.sh [12:15] I know about -exec and stuff [12:15] just feels like I shouldn't have to [12:15] zyga: try find .... | while read [12:15] see what shellcheck thinks of that [12:15] the wiki has a comprehensive list of solutions [12:15] look at that please [12:16] they all turn a one liner into a body of code [12:21] PR snapd#6204 opened: daemon: remove enableInternalInterfaceActions [12:26] pstolowski: ^ [12:27] zyga: wow, interesting, i've never stumbled on it [12:33] zyga: wrt while, the read solution is correct, but while read < <( find ) is a bashism; find | while read would work everywhere [12:33] zyga: wrt enableInternalInterestingInsects, maybe it's time to run 'unused' again [12:34] Chipaca: mmm [12:34] +1 [12:34] it says makeHttpClient is unused [12:34] etc etc [12:34] burn with fire [12:34] Chipaca: also, would you be ok with splitting api.go [12:34] api_debug.go api_interfaces.go [12:35] zyga: i already have [12:35] ... [12:35] oh, perfect [12:35] zyga: api_snapshots [12:35] so can be done on a drive-throuh basis? [12:35] cool, didn't notice [12:35] api.go makes vim unhappy :) [12:35] i don't agree with vim a lot, but i'm with it on this [12:36] or as it would put it, beep beep angry flash beep delete half the text [12:36] * zyga loves the look of https://github.com/pkg/errors [12:36] mvo: ^ [12:36] back to crufty stuff [12:36] eh [12:36] obviously [12:36] I ran a test that failed in https://github.com/snapcore/snapd/pull/6202 and it passed [12:36] PR #6202: tests: restore in restore, not in prepare [12:36] because some other test broke the state [12:37] gosh I hate this test suite today [12:37] * pstolowski lunches [12:57] whoa, ineffective break statement [13:04] zyga: interessting, I read that after lunch [13:22] PR snapd#6205 opened: many: staticcheck fixes [13:23] ^ a couple of serious ones in there [13:23] (most are arguably innocuous) [13:44] Chipaca: in similar vein https://github.com/snapcore/snapd/pull/6206 [13:44] PR #6206: many: fix composite literals with unkeyed fields [13:44] Chipaca: many vet fixes [13:44] Chipaca: oh, I see you fixed the same bug :) [13:44] zyga: https://github.com/dominikh/go-tools/tree/master/cmd/keyify [13:44] PR snapd#6206 opened: many: fix composite literals with unkeyed fields [13:45] PR snapd#6207 opened: mkversion: use "test -n" rather than "! test -z" [13:47] PR snapd#6208 opened: run-checks: assorted fixes [13:48] mmm [13:48] nice [13:48] I wish I'd known :) [13:48] PR snapd#6209 opened: run-checks: discard test good/bad banner [13:50] sorry for the noise [13:50]