| mup | PR snapcraft#2369 closed: Hide progress bar for dumb terminals <Created by eberkund> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2369> | 00:03 |
|---|---|---|
| koala_man | cjwatson: I've looked into alternative routes. The stack build fails because it's linked against an old version of Cabal, and the docker build fails because multistage builds weren't introduced before 17.05 (xenial has 17.03) | 01:21 |
| mup | PR snapd#6038 closed: release: 2.36 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6038> | 04:23 |
| mborzecki | morning | 05:43 |
| mborzecki | how can i put an apparmor profile of a snap into complain mode? | 05:47 |
| === chihchun_afk is now known as chihchun | ||
| dot-tobias | good morning everyone | 06:25 |
| mborzecki | dot-tobias: morning | 06:27 |
| zyga | Good morning | 06:39 |
| zyga | mborzecki: you can use apparmor tools | 06:40 |
| zyga | But I never remember which | 06:40 |
| zyga | Just edit the profile | 06:40 |
| mborzecki | zyga: something i wanted to avoid :) | 06:40 |
| zyga | Change the part that reads (attach_disconnected,....) | 06:40 |
| zyga | And insert “complain” there AFAIR | 06:41 |
| zyga | Then parse and load into the kernel | 06:41 |
| mborzecki | zyga: tried aa-complain, but expects a path to the binary, which is sligtly funny as you can have a profile just with a label like we do for snaps | 06:42 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | heyas | 07:04 |
| zyga | Hey | 07:05 |
| mborzecki | looks like this test is slightly incorrect: https://github.com/snapcore/snapd/blob/master/cmd/snapd/main_test.go#L57-L94 the daemon is started, but we never wait for it to finish | 07:06 |
| mborzecki | added some synchronization and now it's clear that Run() does not exit with nil, but raises value *errors.errorString = &errors.errorString{s:"cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s"} ("cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s") | 07:08 |
| mborzecki | that's probably because http connections from the client are kept alive | 07:09 |
| mborzecki | there are 2 intersting failures in unit tests i've seen today, first one https://paste.ubuntu.com/p/kTHywvD39V/ i can reproduce it locally if i change the sleep to something really small, hence i started adding extra synchronization around snapd.Run() | 07:31 |
| mborzecki | and the 2nd one: https://paste.ubuntu.com/p/SwXy77XJ6H/ where userd got SIGQUIT ? | 07:32 |
| mborzecki | this one is appearing quite often in 2.36 branch | 07:32 |
| sil2100 | eh, I fucked up | 07:39 |
| sil2100 | Can anyone check if the right pc i386 and amd64 gadget snaps are in stable and candidate now? | 07:39 |
| sil2100 | I never use the snapcraft dashboard UI for promoting snaps ever again... | 07:40 |
| zyga | mborzecki: thank you | 07:46 |
| zyga | sil2100: define correct | 07:46 |
| sil2100 | The last one that was supposed to be there, but I found it in the stable images | 07:48 |
| sil2100 | Damn I'm pissed off | 07:48 |
| zyga | I'm still sleepy, not sure how to check | 07:49 |
| zyga | I can tell you the revisions I see | 07:49 |
| zyga | but not sure if that helps | 07:49 |
| sil2100 | Wanted to promote 18 gadget snaps, thought the dashboard UI is smart and will promote to the right 18/stable etc. | 07:49 |
| zyga | sil2100: 18/stable is empty | 07:50 |
| zyga | so perhaps not correct | 07:50 |
| zyga | there are some revisions in 18/beta and edve | 07:51 |
| sil2100 | zyga: I was talking about 16 | 07:52 |
| sil2100 | I now just promoted the 18 ones | 07:52 |
| zyga | stable: 16.04-0.8 (9) 856kB - | 07:53 |
| zyga | candidate: 16.04-0.8 (9) 856kB - | 07:53 |
| zyga | beta: 16.04-0.9 (24) 872kB - | 07:53 |
| zyga | edge: 16.04-0.9 (24) 872kB - | 07:53 |
| sil2100 | zyga: want to make sure the 16 ones are as correct as they were | 07:53 |
| zyga | it looks rather unchanged | 07:53 |
| sil2100 | phew | 07:53 |
| zyga | but I don't know what they were before | 07:53 |
| zyga | so hard to say | 07:53 |
| mborzecki | heh, looking into problem 1, we're doing a graceful shutdown and daemon is stuck calling net.Conn.Close() | 08:19 |
| zyga | pstolowski: could you please look at 6010, landing this would unblock me | 08:22 |
| pstolowski | zyga: sure | 08:22 |
| mborzecki | this doesn't make any sense, it's like close(fd) which should not block | 08:22 |
| zyga | mmm | 08:22 |
| zyga | mborzecki: is it really just that? | 08:23 |
| mborzecki | zyga: https://golang.org/src/net/net.go#L197 | 08:23 |
| zyga | mborzecki: sorry, I don't feel very well today and I'm slow at thinking, can you walk me through the problem statement | 08:23 |
| mborzecki | zyga: take a look here: https://github.com/snapcore/snapd/blob/master/cmd/snapd/main_test.go#L57-L94, there's a gorouting which runs `err := snapd.Run()` | 08:24 |
| mborzecki | zyga: but in the test we do not wait for the goroutine to finish | 08:24 |
| mborzecki | zyga: now if we wait, it's either stuck or exits with error `cannot gracefully finish, still active connections on /tmp/check-8792093359864697921/0/run/snapd.socket after 5s` | 08:25 |
| zyga | aha | 08:25 |
| zyga | and where is the graceful shutdown code? | 08:26 |
| mborzecki | zyga: that's because the test is poking the API via http, but net/http does not close the connection right away after the request is finished, so it's still 'seen' at the server side and we try to go through graceful shutdown calling Close() nicely on each connection | 08:26 |
| mborzecki | zyga: it's here https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L462-L490 | 08:27 |
| mborzecki | zyga: specifically i see it stuck on https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L471 now | 08:28 |
| === chihchun is now known as chihchun_afk | ||
| zyga | mborzecki: and the net.Conn that we re interacting with | 08:38 |
| zyga | what is it in reality? | 08:38 |
| zyga | that is, what Close are we really calling | 08:38 |
| mborzecki | zyga: this one https://golang.org/src/net/net.go#L197 | 08:39 |
| zyga | and netFD? | 08:39 |
| mborzecki | heh added DisableKeepAlives to the transport config and now it's closing right away | 08:40 |
| mborzecki | zyga: https://golang.org/src/net/fd_unix.go#L182 and then it goes into some internal/poll https://golang.org/src/internal/poll/fd_unix.go#L86 there's a comment that Close() may block | 08:45 |
| dot-tobias | greyback: Regarding i3 WM in chromium-mir-kiosk not picking up rotation: I dug into the configuration and it seems that i3 does indeed not pick up the mir-kiosk vertical rotation. However, when I enable kiosk mode in the snap, chromium is forced to fullscreen, and resizing commands are discarded by i3. Do you have a hint on where I can disable the fullscreen? Maybe in xwayland-kiosk-helper? | 08:46 |
| === chihchun_afk is now known as chihchun | ||
| greyback | dot-tobias: the helper auto-generates a config file to make a surface fullscreen, see https://github.com/MirServer/xwayland-kiosk-helper/blob/master/xwayland-preload/xwayland-kiosk-launch#L121 | 08:48 |
| greyback | dot-tobias: however chromium-mir-kiosk provides it's own i3 config file | 08:49 |
| greyback | I don't think enabling/disabling kiosk mode impacts the use of that config file at all | 08:49 |
| zyga | mborzecki: a bit of internals for the morning | 08:50 |
| zyga | are we holding it wrong? | 08:50 |
| dot-tobias | greyback: Yeah, just found that variable 😊 I'm uncertain how the two i3 configs interact, but what I can observe is that commands in the chromium-mir-kiosk i3 config are ignored when kiosk mode is enabled for chromium-mir-kiosk. which “just” loads the kiosk Chrome app AFAIR | 08:51 |
| mborzecki | zyga: i think it's outside of our control, let me check the unixDialer we use | 08:51 |
| greyback | dot-tobias: that's not what I intended anyway. The goal was: if snap provides its own i3 config, use that. If not, fallback to an auto-generated one | 08:51 |
| zyga | mborzecki: given that we don't do real http we could disable keepalive | 08:57 |
| zyga | mborzecki: and perhaps leave a clear note that dragons lurk beyond | 08:57 |
| zyga | pstolowski: one for you https://forum.snapcraft.io/t/hook-run-script-when-an-interface-is-connected/8155 | 09:03 |
| pstolowski | zyga: thanks, i'll answer | 09:05 |
| pstolowski | zyga: i've just hit the issue popey reported recently, with gnome-calculator. i installed its snap yesterday, it's connected to gnome platform snap yet it doesn't see it. i'm on 2.36 | 09:11 |
| pstolowski | zyga: my laptop has been running for only a few days (since monday) | 09:13 |
| zyga | can you nester | 09:13 |
| zyga | nsenter | 09:13 |
| zyga | and then see if that place $SNAP/gnome-platform looks sane please | 09:13 |
| popey | yay! | 09:13 |
| pstolowski | zyga: will do | 09:14 |
| zyga | pstolowski: any files inside? | 09:25 |
| zyga | and any changes recently? | 09:25 |
| pstolowski | zyga: sorry, tryng to finish the review of your PR, will check that issue next. the only changes are | 09:26 |
| pstolowski | 195 Done yesterday at 17:39 CEST yesterday at 17:39 CEST Auto-refresh snap "lxd" | 09:26 |
| pstolowski | 196 Done today at 09:04 CEST today at 09:05 CEST Auto-refresh snaps "core", "lxd" | 09:26 |
| zyga | thanks | 09:26 |
| pstolowski | so, unrelated | 09:26 |
| zyga | aha, core refreshed | 09:26 |
| zyga | core change is related (perhaps) | 09:26 |
| * zyga tries locally | 09:26 | |
| pstolowski | hmm | 09:26 |
| zyga | h | 09:28 |
| zyga | HA | 09:28 |
| zyga | reproduced :) | 09:28 |
| zyga | popey: I got this now | 09:28 |
| zyga | I switched core from edge to beta | 09:29 |
| * zyga investigates | 09:29 | |
| popey | \o/ | 09:29 |
| zyga | and I got the sudo nsenter + ctrl-d bug :/ | 09:30 |
| popey | also yay :) | 09:34 |
| mup | PR snapd#6041 opened: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6041> | 09:35 |
| pstolowski | zyga: a few comments | 09:52 |
| pstolowski | zyga: wow, you reproduced, yay x2 | 09:53 |
| pstolowski | nonetheless, looking into my namespace | 09:53 |
| zyga | pstolowski: you can discard the namespace, I will fix that issue | 10:06 |
| zyga | thank you for the review, looking at the response | 10:07 |
| mborzecki | can someone take a look at this: https://github.com/snapcore/snapd/blob/master/overlord/standby/standby.go#L80-L105 if i'm reading this right, when Stop() is called at the bad moment and m.stopCh is nil, the goroutine will go into sleep waiting for timeout even though it's supposed to exit | 10:08 |
| pstolowski | zyga: great you found the problem! thanks | 10:11 |
| pstolowski | degville: hey, https://forum.snapcraft.io/t/hook-run-script-when-an-interface-is-connected/8155/3 reminded me of the missing doc for interface hooks | 10:18 |
| pstolowski | degville: shall i describe all that in an email and send to you? | 10:19 |
| mup | PR snapd#6042 opened: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042> | 10:21 |
| degville | pstolowski: hello - yes, that would be great - thanks! | 10:21 |
| pstolowski | degville: ok, will do | 10:24 |
| * zyga breaks | 10:32 | |
| zyga | sorry guys, I feel sick | 10:32 |
| Chipaca | why am i getting shellcheck errors for something that's already on master :-( | 10:42 |
| Chipaca | and why is shellcheck now saying "unable to decommit memory" | 10:44 |
| mborzecki | Chipaca: whcih file? | 10:44 |
| mborzecki | Chipaca: btw. 6042 might be interesting for you | 10:45 |
| zyga | Chipaca: uname? | 10:46 |
| Chipaca | oh. new shellcheck. | 10:46 |
| Chipaca | mborzecki: https://pastebin.ubuntu.com/p/KSJXRVXFVz/ | 10:47 |
| Chipaca | zyga: GO AWAY YOU'RE SICK FFS | 10:47 |
| Chipaca | zyga: we'll get IRC cooties | 10:47 |
| Chipaca | mborzecki: fixing | 10:48 |
| mborzecki | Chipaca: which PR is that? shellcheck version should be printed in the log | 10:48 |
| Chipaca | mborzecki: this is the spread-run shellcheck, so it's the snap | 10:49 |
| Chipaca | mborzecki: the snap was created 2018-10-25T05:05:12.188830+00:00 | 10:50 |
| Chipaca | I think that means koala_man found out that haskell-stack does not have the "cabal does not do good http" bug | 10:51 |
| mborzecki | heh | 10:51 |
| Chipaca | mborzecki: anyway, to answer your question, https://api.travis-ci.org/v3/job/445913480/log.txt | 10:51 |
| Chipaca | mborzecki: and AFAIK the spread run does not print the shellcheck version | 10:52 |
| zyga | Chipaca: https://ghc.haskell.org/trac/ghc/ticket/12865 | 10:53 |
| mup | PR snapd#6028 closed: testutil, cmd/snap: introduce and use testutil.EqualsWrapped and fly <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6028> | 10:53 |
| Chipaca | “This is a stylistic issue that does not affect correctness. If you prefer the original expression, you can't not Ignore it with a directive or flag.” | 10:59 |
| Chipaca | ^ shellcheck being snarky about the double-negative implied by ! -z / ! -n | 10:59 |
| mup | PR snapd#6043 opened: tests/main: fixes for the new shellcheck <Created by chipaca> <https://github.com/snapcore/snapd/pull/6043> | 11:01 |
| Chipaca | mborzecki: ^ | 11:01 |
| mborzecki | Chipaca: yeah, looks good | 11:03 |
| mborzecki | nice that it's picky about such small things too | 11:03 |
| Chipaca | mborzecki: also nice that it catches [ ! -z ] and ! [ -z ] the same | 11:05 |
| mborzecki | yeah, one of these days it'd be nice to look at the implementation, my money is on having those actually encoded as pattern matching directly in the code | 11:06 |
| Chipaca | haskell doing pattern matching? sounds about right :-) | 11:08 |
| zyga | pstolowski: updated https://github.com/snapcore/snapd/pull/6010 | 11:09 |
| mup | PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010> | 11:09 |
| pstolowski | ok | 11:09 |
| pstolowski | zyga: +1 | 11:16 |
| mborzecki | any ideas about https://paste.ubuntu.com/p/SwXy77XJ6H/ ? i've looked in go and check, does not look like any of those would send SIGQUIT | 11:16 |
| mborzecki | the test sends SIGUSR1 to itself, but that's handed properly already | 11:17 |
| zyga | mborzecki: nope, nothing remotely SIGQUITS this | 11:21 |
| zyga | maybe it is spread itself? | 11:21 |
| zyga | but I don't know | 11:21 |
| mborzecki | zyga: grepped through spread, came up empty | 11:22 |
| zyga | actually, I grepped in spread as well | 11:22 |
| zyga | :/ | 11:22 |
| mborzecki | pushing an update to arch pacakge in a bit | 11:27 |
| cjwatson | Chipaca: They installed an even more terrifying hack than that | 11:43 |
| Chipaca | cjwatson: … emacs? | 11:43 |
| cjwatson | https://bugs.launchpad.net/launchpad-buildd/+bug/1797809/comments/3 | 11:43 |
| mup | Bug #1797809: Build fails on snapcraft.io, works locally (during `cabal update`) <launchpad-buildd:Triaged> <https://launchpad.net/bugs/1797809> | 11:43 |
| Chipaca | hah | 11:44 |
| Chipaca | proxies all the way down | 11:44 |
| cjwatson | I also discovered that the reason newer cabal "works" even without curl is that it now supports multiple mirrors and just falls back to the next one in the list when its connection gets terminally confused by the first one | 11:45 |
| cjwatson | So I'm trying to hack persistent connection support into launchpad-buildd's internal proxy | 11:46 |
| mup | PR snapd#6043 closed: tests/main: fixes for the new shellcheck <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6043> | 11:50 |
| dot-tobias | greyback: re: fullscreen chromium-mir-Kiosk in rotate => https://git.launchpad.net/~gerboland/+git/chromium-kiosk-app-snap/tree/manifest.json#n35 | 12:00 |
| zyga | mborzecki, Chipaca, pstolowski: would you mind stating your opinions on https://github.com/snapcore/snapd/pull/6010/commits/0ecf1448668b726021ff94408981599d335576d0 | 12:01 |
| mup | PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010> | 12:01 |
| dot-tobias | greyback: I suspect this launches chromium in fullscreen, and i3 does not seem to pick up the rotation coming from mir-kiosk / xwayland. Resizing commands in i3 do not work for fullscreen windows (which is logical, but impractical for my use-case) | 12:02 |
| dot-tobias | greyback: I‘ll add this to the forum topic (http://discourse.ubuntu.com/t/snaps-to-develop-a-web-kiosk-on-ubuntu-core-using-wayland/6424?page=5) once I‘m back at work. Would be very glad if you have suggestions how I can force i3 to respect the rotated layout. Thank you for your work on all the kiosk snaps 😊 | 12:05 |
| greyback | dot-tobias: hmm interesting, I forgot about that policy setting | 12:05 |
| greyback | dot-tobias: yes please do update the forum. I'll try to find time to look into the problem | 12:06 |
| dot-tobias | greyback: I’ll do that and ping you here once done. Thank you for your time in advance 😊I’ll try to find a way to hide chromium UI when not in fullscreen mode. | 12:08 |
| cachio | zyga, hey, I need to take my son to make an audition study | 12:15 |
| cachio | zyga, I'll try to be back for the stand up but not sure | 12:15 |
| zyga | cachio: noted | 12:17 |
| zyga | thanks, good luck :) | 12:17 |
| cachio | zyga, tx | 12:18 |
| pstolowski | zyga: will do in a moment | 12:22 |
| mborzecki | snapd updated in AUR, i've also updated the wiki with some extra info | 12:30 |
| mborzecki | funny cause someone else edited the wiki while i was editing it and added a note about apparmor, which was like 10-15 minutes after i pushed the change to aur | 12:30 |
| ijohnson | mborzecki: so is snapd on Arch now fully confined? | 12:31 |
| mborzecki | ijohnson: not everything is supported yet, jdstrand left some details here: https://forum.snapcraft.io/t/arch-linux-and-apparmor/7036 | 12:32 |
| Chipaca | zyga: I have close to 0 opinions on C formatting style | 12:35 |
| zyga | Chipaca: mainly if you are -1 on moving to clang-format | 12:35 |
| Chipaca | zyga: I am not | 12:35 |
| Chipaca | zyga: the only C formatting style I think is bad is the one that pushes the {}s and the ;s to column 80 | 12:36 |
| Chipaca | degville: you around? | 12:38 |
| degville | Chipaca: yep | 12:39 |
| Chipaca | degville: could you give the long help strings in https://github.com/snapcore/snapd/blob/dfef243c027b84ae8331a36dddbf61b6bf847813/cmd/snap/cmd_snapshot.go a once over? | 12:39 |
| Chipaca | degville: (search for "var long") | 12:39 |
| pstolowski | zyga: the clang-format lgtm, nothing out of ordinary,+1 | 12:39 |
| degville | Chipaca: will do - looking now. | 12:40 |
| zyga | thanks! | 12:40 |
| Chipaca | sborovkov: hi | 12:43 |
| sborovkov | Chipaca, hello | 12:43 |
| Chipaca | sborovkov: remind me, if I'm not being rude, what was it you worked on? | 12:43 |
| sborovkov | screenly, digital signage :) | 12:43 |
| Chipaca | sborovkov: are you, or is your team, sensitive to snapd api changes? | 12:44 |
| Chipaca | I think it wasn't you, fwiw | 12:44 |
| sborovkov | hmm, not to a big extent, We currently only use it to set config.txt options | 12:45 |
| Chipaca | a shame, I'm going to have to talk to field engineering to get them to talk with the team in question, more roundabout than i would've preferred | 12:45 |
| sborovkov | so you might be thinking about someone else | 12:45 |
| Chipaca | sborovkov: yep yep :-) | 12:45 |
| Chipaca | sborovkov: this is about a screenshots -> media transition | 12:45 |
| Chipaca | happening in the 2.36 … 2.39 timeline | 12:46 |
| sborovkov | definitely not us then :) | 12:46 |
| Chipaca | sborovkov: thank you for confirming :-) I'll go pester field eng | 12:46 |
| zyga | mborzecki: do you know why the set of panics we see in unit tests surfaced now? | 12:51 |
| zyga | mborzecki: is it something that changed on our side recently? | 12:51 |
| Chipaca | mborzecki: which panics? | 12:54 |
| Chipaca | um | 12:54 |
| Chipaca | zyga: ^ | 12:54 |
| zyga | Chipaca: unit tests time out and panic | 12:54 |
| zyga | just look at recent test failure | 12:54 |
| Chipaca | zyga: in cmd/snap? | 12:55 |
| zyga | yes | 12:55 |
| Chipaca | hmm | 12:55 |
| Chipaca | yes I did see that, thought it was a one-off | 12:55 |
| Chipaca | machine taking a sleep or sth | 12:55 |
| Chipaca | i'll dig | 12:55 |
| mborzecki | Chipaca: w8, whci one? there's a PR addressing one of the issues i saw | 12:57 |
| Chipaca | mborzecki: ah! which pr is that? | 12:57 |
| mborzecki | Chipaca: there's one here https://github.com/snapcore/snapd/pull/6041 | 12:57 |
| mup | PR #6041: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6041> | 12:57 |
| mborzecki | Chipaca: another one https://github.com/snapcore/snapd/pull/6042 this was not caught by unit tests but race detector suggested and issue and IMO there is one | 12:58 |
| mup | PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042> | 12:58 |
| Chipaca | mborzecki: the one I saw (and I thought zyga was asking about) was one where you get the test killed by go because it times out | 12:58 |
| mborzecki | intersting, what PR is that? | 12:59 |
| zyga | mborzecki: I mean your PRs are good but I wonder what happened that this started to happen | 12:59 |
| Chipaca | zyga: do you have one of these failures handy? | 12:59 |
| zyga | guys, I feel sick and could need to... break, at any time | 12:59 |
| zyga | can one of you run the standup please | 12:59 |
| zyga | my update: working on user mounts but interrupted by reproducing the issue popey discovered | 13:00 |
| zyga | fixing it with top priority | 13:00 |
| zyga | Chipaca: let me look | 13:00 |
| zyga | Chipaca: here is one https://api.travis-ci.org/v3/job/445642309/log.txt | 13:01 |
| Chipaca | whoops standup | 13:02 |
| mborzecki | cachio: standup | 13:03 |
| zyga | mborzecki: he said he would probably not make it | 13:04 |
| mborzecki | ah ok | 13:04 |
| zyga | sorry, I should have mentioned that above | 13:04 |
| Chipaca | zyga: you coming? | 13:04 |
| zyga | no, sorry | 13:04 |
| Chipaca | ah ok | 13:04 |
| Chipaca | the cmd/snap unit tests really need the new WrappedEquals checkers -- otherwise you can't run them from the 'go test -c' binary unless your terminal is 80 columns (or you redirect stdin) | 13:15 |
| Chipaca | mborzecki: do you see what i mean about StandbyOpinions not being goroutine-safe? | 13:16 |
| Chipaca | mborzecki: OTOH, why is timerCh an attribute, instead of a variable? | 13:18 |
| mborzecki | Chipaca: heh, probably went through a couple of review changes | 13:18 |
| mborzecki | Chipaca: using tomb we'd drop stopCh, then timerCh could be variable and we're left with AddOpinion() which could use some locking but not necessarily, slapping a comment that it needs to be called before Start() should be sufficient | 13:20 |
| Chipaca | mborzecki: also setting closeCh to nil doesn't make sense; you want it closed, not nil, so the receive works (as opposed to blocking on nil) | 13:20 |
| mborzecki | Chipaca: oh and daemon should probably wait for standby to finish | 13:21 |
| mborzecki | Chipaca: right now it does not | 13:21 |
| Chipaca | mborzecki: are either of your PRs fixing the ... value *errors.errorString = &errors.errorString{s:"dbus: connection closed by user"} ("dbus: connection closed by user") failure? | 13:24 |
| mborzecki | Chipaca: nope, where did you get that one? | 13:25 |
| Chipaca | mborzecki: /snap/bin/go test -count=100 -failfast ./cmd/snap | 13:26 |
| Chipaca | mborzecki: fails with that rather quickly | 13:27 |
| Chipaca | mborzecki: /snap/bin/go becaue 1.10 has -failfast | 13:27 |
| mborzecki | Chipaca: hmm is godbus reusing the connection? | 13:28 |
| Chipaca | mborzecki: dunno :-) i'm skipping the test to go on and find the hanging one | 13:29 |
| tomwardill | more pre-refresh hook questions! Is it possible to manually run a hook? Otherwise testing this is a bit tricky. | 13:34 |
| ogra | perhaps via "snap run --shell <snap app>" | 13:34 |
| ogra | that gives you a shell inside the snap env ... | 13:35 |
| tomwardill | ooh, that might do it, thanks ogra | 13:36 |
| mborzecki | Chipaca: it is reusing the connection | 13:36 |
| mup | PR snapd#6040 closed: data/apt: close stderr when calling snap in the apt install hook <Simple 😃> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6040> | 13:48 |
| Chipaca | zyga: ping | 13:56 |
| zyga | yes? | 13:56 |
| Chipaca | zyga: problem with the ptrace thing in other arches | 14:00 |
| Chipaca | zyga: PTRACE_GETFPREGS i mean | 14:00 |
| Chipaca | zyga: syscall.PTRACE_GETFPREGS is not always there | 14:00 |
| Chipaca | i'm adding a test for this, hopefully | 14:00 |
| Chipaca | xnox: are you around? question about gcc-arm-linux-gnueabihf vs gcc-multilib | 14:01 |
| zyga | yes | 14:02 |
| zyga | I think that's an arch specific thing but let me look | 14:02 |
| Chipaca | zyga: do you know about gcc-arm-linux-gnueabihf vs gcc-multilib? | 14:03 |
| zyga | probably not | 14:03 |
| Chipaca | ok | 14:03 |
| zyga | http://man7.org/linux/man-pages/man2/ptrace.2.html | 14:04 |
| zyga | Chipaca: floating point regs, not on all arches | 14:04 |
| xnox | Chipaca, sup? two are different; and also different depending on the host's arch. | 14:05 |
| xnox | Chipaca, so which host arch are you on, what are you using, and why / what do you want to achieve? | 14:05 |
| Chipaca | xnox: I was once again trying to cross-build go to armhf, and your blog post is my only reliable reference :-) but every time I come to it I have to install one and remove the other, and then time passes and I have to reverse it, and it seems broken | 14:06 |
| Chipaca | xnox: so I was wondering if that was The Way, or if it was outdated and I was missing a trick | 14:06 |
| xnox | ha | 14:06 |
| xnox | Chipaca, which blog is that? | 14:06 |
| Chipaca | http://blog.surgut.co.uk/2014/06/cross-compile-go-code-including-cgo.html | 14:06 |
| Chipaca | I use this vintage tech called a "bookmark" | 14:06 |
| xnox | Chipaca, no idea what that is? is like a star? | 14:07 |
| Chipaca | :) | 14:07 |
| xnox | Chipaca, also well, click chroots, don't exist anymore.... so do you use $ mk-sbuild --arch armhf bionic ; schroot -u root -c bionic-armhf ? | 14:07 |
| ogra | xnox, nah, starts are for favourites ... | 14:08 |
| Chipaca | xnox: CGO_ENABLED=1 GOOS=linux GOARCH=arm CC=arm-linux-gnueabihf-gcc GOPATH=~/canonical/snappy/ go build -v -o /dev/null ./cmd/snap-seccomp/ | 14:08 |
| Chipaca | (the GOOS is spurious and you can ignore it) | 14:08 |
| xnox | Chipaca, gcc-multilib is usually to allow building "co-pairs" of things - e.g. armel/armhf/arm64 on arm platforms; i386/amd64 on x86 platforms and so on. | 14:08 |
| xnox | gcc-arm-linux-gnueabihf is a generic cross-compiler which should be available on all arches; and as a bonus point it is the native compiler on armhf. | 14:09 |
| xnox | this way wherever one is, one should always be able to install and use gcc-arm-linux-gnueabihf | 14:09 |
| xnox | Chipaca, i'm not sure how/why/where that would conflict with gcc-multilib | 14:09 |
| xnox | cause it shouldn't..... | 14:09 |
| xnox | and if you are doing all that, you shouldn't need to ever install gcc-multilib, on any host. | 14:10 |
| Chipaca | xnox: ah, ok. Then don't look because you'll get lost down the warren. | 14:10 |
| xnox | Chipaca, i see that gcc-multilib declares conflicts on everything.... so like stop using gcc-multilib i guess? | 14:10 |
| Chipaca | xnox: ok, I'll stay like this, and the next time I need to revert it I'll flag you down again | 14:11 |
| Chipaca | maybe the other flow is broken :-) | 14:11 |
| Chipaca | xnox: thank you | 14:11 |
| xnox | Chipaca, on the surface, i see that gcc-multilib potentially overdeclares conflicts..... | 14:11 |
| oSoMoN | jdstrand, I could use your help with bug #1738164 (see my last two comments). I now have a yubikey 4 so I can easily test things | 14:26 |
| mup | Bug #1738164: [snap] U2F doesn't work with yubikey <snap> <chromium-browser (Ubuntu):Confirmed for osomon> <https://launchpad.net/bugs/1738164> | 14:26 |
| mborzecki | Chipaca: so -count=n with dbus test does not work because the connection is shared, there is one reference in used and another one in dbustest, i'm working on some changes to use private connection instead | 14:29 |
| Chipaca | mborzecki: ok | 14:33 |
| Chipaca | mborzecki: I've forked to writing a mutliarch spread test | 14:33 |
| ppisati | ogra: can you still reproduce those rpi wifi issues you were mentioning me some time ago? | 14:47 |
| zyga | is master fixed now? | 14:49 |
| ogra | ppisati, it seems to have been gotten a bit more stable lately but i still see it reboot at times (i have a acrit that pings the GW and force-reboots the board if it cant reach it) see https://paste.ubuntu.com/p/B7kDjxjKbt/ | 15:00 |
| ogra | *a script | 15:01 |
| === chihchun is now known as chihchun_afk | ||
| zyga | popey: I know what the bug is | 15:03 |
| zyga | it's very simple to fix | 15:03 |
| zyga | man | 15:03 |
| zyga | THANK YOU | 15:03 |
| zyga | it's super important!!! | 15:03 |
| popey | zyga: oh!? | 15:07 |
| zyga | I will land a quick one liner | 15:07 |
| zyga | but then proceed with better fix | 15:07 |
| popey | I love a one-liner | 15:07 |
| zyga | I also added a logging subsystem to show what is going on | 15:07 |
| ppisati | ogra: are you using a raspberrypi official power supply? | 15:13 |
| ogra | ppisati, nope, a 2A phone charger | 15:14 |
| zyga | Chipaca: hey | 15:16 |
| zyga | do you have a sec? | 15:16 |
| ppisati | ogra: ok, if you could get one and try that, it will surely help - with my rpi3b+ i encountered a lot of instabilities, in particular duing the boot phase, and they all went away when i switched to an official raspberry power supply | 15:16 |
| ppisati | ogra: other than that, a tentative fix landed in the rpi tree so i might have a kernel to test, if you could give it a spin | 15:17 |
| mup | PR snapd#6044 opened: cmd/snap-confine: remove stale mount profile along stale namespace <Created by zyga> <https://github.com/snapcore/snapd/pull/6044> | 15:18 |
| ogra | ppisati, well, i can surely try but thats a normal pi3 ... i doubt it is underpowered ... there is a USB wbcam attached that permanently streams though ... my guess would rather go towards USB saturation than to missing power | 15:18 |
| ogra | sure, i'll happily test | 15:18 |
| Chipaca | zyga: more or less, why? | 15:19 |
| zyga | Chipaca: can you please look at https://github.com/snapcore/snapd/pull/6044 | 15:19 |
| mup | PR #6044: cmd/snap-confine: remove stale mount profile along stale namespace <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6044> | 15:19 |
| zyga | it's pretty critical | 15:19 |
| zyga | I wanted to do a staged patch, a quick fix that is provided here | 15:19 |
| ogra | (needs a bit though, this image is not running a sideloaded kernel, i'll need to build a new one) | 15:19 |
| zyga | a more lengthy fix that uses snap-discard-ns instead of reimplementing it locally | 15:19 |
| Chipaca | zyga: is this the one for --classic not going away? | 15:19 |
| zyga | and perhaps a spread test if I can come up with a way to write one | 15:19 |
| zyga | no, for mount profiles going away on base refreshes | 15:19 |
| zyga | or breaking all desktop apps | 15:20 |
| zyga | :/ | 15:20 |
| zyga | popey: ^ | 15:20 |
| zyga | that's the fix | 15:20 |
| zyga | it won't fix any affected systems but for those snap-discard-ns can be ued | 15:20 |
| zyga | subsequently it will be OK | 15:21 |
| Chipaca | ah | 15:21 |
| ppisati | ogra: bionic or xenial kernel? | 15:21 |
| ogra | ppisati, core 16 stable | 15:21 |
| ogra | so xenial | 15:21 |
| popey | I don't fully understand, but don't worry :) | 15:25 |
| pstolowski | zyga: \o/ | 15:26 |
| zyga | popey: it will get fixed, I will work with mvo on making this patch released | 15:26 |
| zyga | and on tests so that it doesn't regress | 15:27 |
| popey | ok, thanks | 15:27 |
| zyga | thank *you* | 15:27 |
| Chipaca | zyga: did you look further into the syscall.PTRACE_SHENANIGAN thing? | 15:39 |
| zyga | not more that it is only available on some arches | 15:40 |
| zyga | what is the problem? | 15:40 |
| zyga | we should just have this logic in the interface | 15:40 |
| zyga | we can start with easy | 15:40 |
| zyga | if on i386 or amd64 == add that part | 15:40 |
| zyga | otherwise not | 15:40 |
| zyga | and that should be enough | 15:40 |
| Chipaca | zyga: master is currently broken on arm64 armhf powerpc ppc64el s390x | 15:41 |
| zyga | because of that? | 15:41 |
| Chipaca | zyga: apparently? | 15:41 |
| Chipaca | zyga: report comes from mvo | 15:41 |
| zyga | well, master is broken in general, unit tests keep exploding | 15:41 |
| zyga | aha | 15:41 |
| zyga | let's do this | 15:41 |
| zyga | let's maker that conditional | 15:42 |
| zyga | but I need to get some stuff for my stomach first | 15:42 |
| zyga | so ~~ one hour | 15:42 |
| zyga | the patch should be mininal | 15:42 |
| Chipaca | i'm working on a spread test that cross-compiles everything just in case | 15:42 |
| zyga | iff it can land | 15:42 |
| zyga | nice, thank you! | 15:42 |
| Chipaca | so we don't break like this again | 15:42 |
| Chipaca | but it's taking me a bit :-) | 15:42 |
| zyga | Chipaca: it would be great to unbreak master | 15:42 |
| Chipaca | zyga: can you? i'll review :-D | 15:42 |
| zyga | I mean | 15:43 |
| zyga | the current one that explodes on travis | 15:43 |
| Chipaca | ah | 15:43 |
| Chipaca | zyga: with this timeout thing? | 15:43 |
| zyga | I can fix the trace issue | 15:43 |
| Chipaca | zyga: but it's not every time is it? | 15:43 |
| zyga | yeah | 15:43 |
| Chipaca | i was looking at that but then this cross-thing came up | 15:43 |
| Chipaca | which seemed more important :-) | 15:43 |
| zyga | ok, I'll break now | 15:45 |
| zyga | ttyl | 15:45 |
| zyga | (in one hour) | 15:46 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| Chipaca | xnox: what's the way to get i686-linux-gnu-gcc (or i386 or w/e) on amd64? | 16:51 |
| zyga | Chipaca: you can just use -mtune 32 or something | 16:53 |
| zyga | I used to do that often | 16:53 |
| zyga | hold on | 16:53 |
| Chipaca | zyga: yes, but | 16:53 |
| xnox | Chipaca, that's multilib, he doesn't want that. | 16:54 |
| Chipaca | was wondering if amd64/i386 were the same | 16:54 |
| Chipaca | as all the others :-) | 16:54 |
| Chipaca | if not it's fine | 16:54 |
| zyga | xnox: is there a difference in the resulting binary? | 16:54 |
| Chipaca | zyga: are you back, looking at the ptrace thing? | 16:54 |
| xnox | Chipaca, you want gcc-i686-linux-gnu i believe | 16:54 |
| zyga | (or: is it worth testing with gcc on i386 vm) | 16:54 |
| xnox | zyga, no, but there is a difference in # of compilers you can co-install. | 16:55 |
| zyga | aha | 16:55 |
| zyga | I see, thanks | 16:55 |
| zyga | so some compilers conflict with each other? | 16:55 |
| Chipaca | zyga: oh yes | 16:55 |
| Chipaca | zyga: I started taking a stab at the ptrace thing, and it's strange | 16:55 |
| Chipaca | zyga: i'm getting errors in more places than i'd expect | 16:55 |
| xnox | Chipaca, zyga - and i strongly recommend you to use a chroot, such that you can safely install libfoo-dev:i386 libfoo-dev:amd64 etc if your native code requires C libraries/headers for a given cross-arch. | 16:56 |
| xnox | e.g. mk-sbuild --arch armhf|arm64|i386 bionic, and schroot into that. | 16:56 |
| xnox | it will have all the right compilers pre-installed, accessible by the right name gcc-${arch} | 16:56 |
| Chipaca | xnox: I'll give that a try if my current approach fails even a teeny bit more | 16:57 |
| Chipaca | xnox: (I don't see too much value in the chroot approach as these are for running in throwaway vms already) | 16:58 |
| zyga | xnox: curious about armhf, would that work on amd64 as well? I mean, is that a chroot with a native cross compiler or a chroot with a non-native native compiler | 16:58 |
| Chipaca | zyga: is it right that there's no PTRACE_GETFPREGS on 386? | 16:59 |
| xnox | Chipaca, yeah, if you are already isolated from your host, it's fine to run as is. | 16:59 |
| xnox | zyga, re-read again what you are saying =) | 16:59 |
| zyga | xnox: well, I know what I said :) | 17:00 |
| zyga | is that a chroot for native execution on the host | 17:00 |
| zyga | or would it require qemu static | 17:00 |
| xnox | of course not | 17:00 |
| xnox | =) | 17:00 |
| xnox | mk-sbuild can setup native chroots, and chroots for cross-compiling | 17:00 |
| xnox | see manpage. | 17:00 |
| xnox | but the neat thing is that our cross-compilers for $foo, on all arches, and the native compiler for $foo on $foo have the same binary name. | 17:01 |
| zyga | Chipaca: looking at the kernel | 17:01 |
| popey | jdstrand: you about for an apparmor problem? | 17:01 |
| Chipaca | zyga: ignore that bit about PTRACE_GETFPREGS on 386, i'm dumb | 17:01 |
| Chipaca | zyga: ignore ignore | 17:01 |
| zyga | xnox: that _is_ neat :) | 17:01 |
| xnox | thus one can always use the same CC= name | 17:01 |
| zyga | haha, ok Chipaca :) | 17:01 |
| zyga | xnox: yeah, I'm a bit of a fan of running my pet projects on weird stuff | 17:01 |
| zyga | and I use the assorted set of cross compilers we provide | 17:02 |
| zyga | I value that a lot | 17:02 |
| zyga | I often mix those with qemu static | 17:02 |
| zyga | and for some I have the hardware | 17:02 |
| zyga | (still waiting for that low-cost power board that is low cost) | 17:02 |
| mup | PR snapd#6044 closed: cmd/snap-confine: remove stale mount profile along stale namespace <⚠ Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6044> | 17:11 |
| Chipaca | zyga: it's surprising to me that neither amd64 nor s390x have PTRACE_GETFPREGS | 17:20 |
| Chipaca | zyga: running tests on a branch to fix this whole thing | 17:24 |
| Chipaca | includes the cross-build spread test for arches supported by go itself | 17:24 |
| Chipaca | bah for the intersection | 17:24 |
| Chipaca | { arches supported by snapd } ∩ { arches supported by go } - { arches already covered by regular tests } | 17:26 |
| Chipaca | { arm64 arm s390x } | 17:26 |
| Chipaca | an alarmingly short list :-) | 17:26 |
| Chipaca | still, should be enough to catch some bugs | 17:26 |
| Chipaca | ooh ooh ppc64le also | 17:28 |
| * Chipaca tries to add that | 17:28 | |
| kyrofa | zyga, you asked me to remind you about https://bugs.launchpad.net/snapd/+bug/1800004 | 17:33 |
| mup | Bug #1800004: snap try doesn't work: "cannot find installed snap" <snapd:New> <https://launchpad.net/bugs/1800004> | 17:33 |
| zyga | thanks! | 17:33 |
| kyrofa | It's kinda killing me if you can find some cycles | 17:33 |
| zyga | kyrofa: I'll look today | 17:35 |
| zyga | just updating a PR from mvo | 17:35 |
| Chipaca | is ports.ubuntu.com the right place for -security on armhf? | 17:35 |
| kyrofa | zyga, thank you. Please let me know if you need data from me | 17:36 |
| Chipaca | zyga: https://github.com/snapcore/snapd/pull/6045 | 18:01 |
| mup | PR #6045: cmd/snap-seccomp: only look for PTRACE_GETFPX?REGS where available <Created by chipaca> <https://github.com/snapcore/snapd/pull/6045> | 18:01 |
| mup | PR snapd#6045 opened: cmd/snap-seccomp: only look for PTRACE_GETFPX?REGS where available <Created by chipaca> <https://github.com/snapcore/snapd/pull/6045> | 18:01 |
| mup | PR snapd#6010 closed: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6010> | 18:27 |
| zyga | Chipaca: can we land https://github.com/snapcore/snapd/pull/6042#pullrequestreview-168525464 | 18:30 |
| mup | PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042> | 18:30 |
| zyga | Chipaca: https://github.com/snapcore/snapd/pull/6046 if you want to +1 something simple | 18:37 |
| mup | PR #6046: cmd/snap-confine: remove SC_NS_FAIL_GRACEFULLY <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6046> | 18:37 |
| mup | PR snapd#6046 opened: cmd/snap-confine: remove SC_NS_FAIL_GRACEFULLY <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6046> | 18:37 |
| zyga | kyrofa: ok looking now | 18:43 |
| mup | PR snapd#6047 opened: cmd: remove remnants of sc_should_populate_mount_ns <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6047> | 18:44 |
| kyrofa | zyga, wonderful! | 18:44 |
| zyga | kyrofa: I cannot reproduce it, tried on ... | 18:47 |
| zyga | https://www.irccloud.com/pastebin/HtAv4AnW/ | 18:47 |
| zyga | can you share a snap you have that triggers this | 18:47 |
| zyga | I tried ... | 18:47 |
| zyga | go/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-sh$ sudo snap try | 18:48 |
| zyga | and subsequently ran some commands, all worked | 18:48 |
| zyga | ahhh | 18:49 |
| zyga | the snap is in /tmp/? | 18:49 |
| zyga | perhaps that's why :) | 18:49 |
| * zyga checks | 18:49 | |
| zyga | kyrofa: reproduced! | 18:49 |
| kyrofa | zyga, ah, indeed, if I put it in my homedir it works | 18:50 |
| kyrofa | Why would that be? | 18:51 |
| kyrofa | I thought the private tmp didn't come into play until we were talking about the snap's namespace | 18:51 |
| zyga | I'll reply in the bug | 18:51 |
| kyrofa | Very good | 18:51 |
| zyga | it's silly | 18:51 |
| zyga | (very silly) | 18:52 |
| zyga | replied, looking if I can fix it | 18:53 |
| zyga | kyrofa: ok, I see why this happens | 18:56 |
| zyga | it's silly, api reused around and perhaps in a bad way | 18:56 |
| zyga | kyrofa: the tl;dr; answer is because the code for running a snap wants to know how big the snap is | 18:58 |
| zyga | which is silly | 18:58 |
| zyga | because that is a hot path | 18:58 |
| zyga | and should not reuse random parts of snapd | 18:58 |
| zyga | and hence it is a dangling symlink from the namespace POV | 18:58 |
| zyga | it doesn't work | 18:58 |
| zyga | which is double plus silly for symlinks | 18:58 |
| zyga | it would be useless anyway, no size | 18:58 |
| * cachio afk | 19:03 | |
| kyrofa | zyga, ah, interesting | 19:19 |
| zyga | fixed locally | 19:19 |
| zyga | just crafting a quick test | 19:19 |
| kyrofa | Awesome! | 19:20 |
| zyga | just running spread | 19:24 |
| zyga | and I should EOD, it's almost 10pm | 19:24 |
| zyga | kyrofa: https://github.com/snapcore/snapd/pull/6048 | 19:38 |
| mup | PR #6048: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <https://github.com/snapcore/snapd/pull/6048> | 19:39 |
| zyga | enjoy :) | 19:39 |
| kyrofa | Thanks zyga! | 19:39 |
| mup | PR snapd#6048 opened: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <https://github.com/snapcore/snapd/pull/6048> | 19:39 |
| Chipaca | zyga: wrt 6042, no :-) | 20:32 |
| Chipaca | zyga: wrt 6046, looking | 20:33 |
| Chipaca | I'm this >< close to losing packets today | 20:51 |
| * Chipaca goes for tea | 20:51 | |
| * Chipaca wishes there were biscuits | 20:51 | |
| Chipaca | brb, reboot | 21:55 |
| mup | PR snapd#6031 closed: snap/pack, cmd/snap: allow specifying the filename of 'snap pack' <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6031> | 22:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!