[05:01] <mborzecki> morning
[05:31] <zyga> Hey
[05:31] <zyga> mborzecki: mvo asked for release reviews today
[05:32] <mborzecki> zyga: hey, ok
[05:33] <mborzecki> zyga: do you know what's the status of https://github.com/snapcore/snapd/pull/5845 ? iirc it was waiting for a review from jdstrand mostly
[05:35] <zyga> It also needs a new name from Gustavo
[05:37] <zyga> I need to take Bit to the vet for surgery today but that should take a moment
[05:37] <zyga> I’ll be in the office shortly
[06:17] <mborzecki> zyga: https://paste.ubuntu.com/p/3ZwGpF6ZyT/ something i found on the laptop
[06:17] <mborzecki> zyga: lrwxrwxrwx 1 root root 13 10-23 08:15 /var/lib/lxd -> /mnt/data/lxd
[06:18] <mborzecki> since we test for access() removing the symlink makes it work
[06:48] <zyga> Hmmm
[06:57] <zyga> Yeah, the error message need improvements
[07:04] <pstolowski> mornings
[07:18] <mborzecki> zyga: can you take another look at https://github.com/snapcore/snapd/pull/6023 ?
[07:24] <mborzecki> pstolowski: pedronis left a suggestion in https://github.com/snapcore/snapd/pull/6027
[07:25] <pstolowski> yep, looking
[07:34] <zyga> Ok
[07:34] <zyga> Dog at vet
[07:34] <zyga> Two hours after surgery for pickup
[07:34] <zyga> Fingers crossed it goes well
[07:35] <zyga> mborzecki: two, in 2 minutes, just going home
[07:39] <jdrab> pani, VCERA SME PREMESKALI MEDZINARODNY DEN CAPS LOCKU!
[07:39] <zyga> re
[07:39] <zyga> uh?
[07:39] <zyga> mborzecki: looking now
[07:40] <mborzecki> yday was the national day of cap lock?
[07:41] <jdrab> oh sry, wrong channel :D
[07:42] <zyga> mborzecki: thank you for the link about Khan's Algorithm
[07:42] <zyga> I wasn't aware of it, cool
[07:42] <zyga> jdrab: nie szkodzi
[07:42] <zyga> :)
[07:42] <jdrab> ahaha :)
[07:46] <mborzecki> zyga: yeah, and it's surprisingly simple once you understand it
[07:49] <seb128> hey there
[07:49] <seb128> $ snap changes
[07:49] <seb128> ID    Status  Spawn                      Ready  Summary
[07:49] <seb128> 1462  Doing   4 days ago, at 09:21 CEST  -      Auto-refresh snaps "core", "core18", "gnome-logs"
[07:49] <seb128> is that "4 days ago" normal?
[07:49] <seb128> or is snapd stucked in some way?
[07:49] <mborzecki> pstolowski: ^^
[07:50] <pstolowski> seb128: snap version?
[07:50] <seb128> $ snap version
[07:50] <seb128> snap    2.36~pre2+git965.966c1d4~ubuntu16.04.1
[07:50] <seb128> snapd   2.36~pre2+git965.966c1d4~ubuntu16.04.1
[07:50] <seb128> series  16
[07:51] <seb128> pstolowski, ^
[07:51] <mborzecki> pstolowski: you think that could be auto-connect?
[07:51] <pstolowski> seb128: ok, and snap change 1462?
[07:52] <seb128> that takes a bit...
[07:53] <seb128> pstolowski, http://people.canonical.com/~seb128/log
[07:54] <zyga> about that
[07:54] <zyga> I think we could use RW locks on state
[07:54] <zyga> so snap changes is fast
[07:54] <zyga> unless I misunderstand and the delay is because of the volume of data
[07:55] <mborzecki> crazy thought, but should we try to detect that stuff is getting retried indefinitely and perhaps log && abort?
[07:55] <zyga> I think we do that in a way
[07:55] <pstolowski> seb128: thanks. so yes, it's a known bug we've right now in master/edge, fix is being reviewed
[07:55] <zyga> very old tasks get aborted
[07:55] <zyga> or perhaps we meant to
[07:56] <zyga> I'm not super familiar with that code
[07:57] <pstolowski> seb128: as a workaround you can snap abort the change, and then remove all unused revisons of gnome-logs (snap remove --revision=....) to only leave one. alternatively, switching core to stable (after aborting the change) might help
[07:58] <zyga> mborzecki: I will follow up with a validator for topological sorting in the mount backend
[07:58] <zyga> at least we must detect cycles
[07:58] <mborzecki> zyga: ping me for review
[07:58] <zyga> with pleasure :)
[07:58] <seb128> pstolowski, ok, thanks, I didn't even remember that I changed the core to a non stable channel on that box :)
[08:02] <ackk> kyrofa, WRT --destructive-mode, it seems it currently only works if you don't pass a comand to snapcraft? if I try to "snapcraft prime --destructive-mode" it tries to use multipass
[08:02] <ackk> is that expected?
[08:04] <mborzecki> zyga: pstolowski: if i'm reading that right, the task would be auto aborted after 7 days
[08:04] <zyga> that's about right
[08:04] <zyga> it's a lot of time but it was meant to be conservative
[08:04] <pstolowski> seb128: which is good, thanks to one other report about this we avoided releasing it (it happens under specific circumstances)
[08:05] <pstolowski> mborzecki: zyga, right, we will not eat cpu indifinately or anything... but the problematic change will keep re-appearing and will never succeed (auto-refresh in this case)
[08:06] <zyga> yeah
[08:06] <zyga> we may have a fallback mode
[08:06] <mborzecki> eat cpu and fill up the state
[08:06] <zyga> if we fail to refresh and abort after 7 days
[08:06] <zyga> we could do something special, like just refresh core - if installed, or snapd - if installed
[08:06] <zyga> and nothing else
[08:06] <mborzecki> iff we do healtchecks, this could be part of it
[08:09] <pstolowski> seb128: so, thanks for using of edge, please switch back to it if possible after the fix lands, you guys have more interesting use cases than anyone else, so better chances of finding potential problems
[08:09] <mborzecki> if nobody minds i can push the fixes to https://github.com/snapcore/snapd/pull/5727 that jdstrand requested
[08:10] <zyga> mborzecki: +1
[08:10] <seb128> pstolowski, np, thx for replying/getting me unstuck, your step worked
[08:14] <pstolowski> zyga: yes, this sounds like a good idea
[08:27] <zyga> mborzecki: can we land ? https://github.com/snapcore/snapd/pull/5346
[08:34] <mborzecki> zyga: let me finish with the changes for breakpad and i'll take another look at it
[08:34] <zyga> it's +2 and green
[08:34] <zyga> breakpad?
[08:34] <zyga> ah
[08:34] <zyga> mozilla
[08:34] <zyga> sure
[08:35] <mborzecki> damn, hate running tests in snap-seccomp
[08:35] <ogra> (assuming that GH behaves again i un-quietened mup again)
[08:43] <zyga> mborzecki: on your laptop?
[08:44] <mborzecki> zyga: anywhere, it's making the modules for all those crazy AF_* loaded
[08:44] <zyga> ah right
[08:50] <mborzecki> zyga: looking at the snap:// pr
[08:50] <zyga> I wonder if it's ok to just merge
[09:00] <zyga> morning Chipaca
[09:00] <Chipaca> morning zyga
[09:02] <mup> PR snapd#5985 closed: overlord/many: cleanup use of snapName vs. instanceName <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5985>
[09:15] <zyga> need to go to get the dog from the vet
[09:15] <zyga> surgery over
[09:15] <zyga> brb
[09:15] <pstolowski> zyga: hmm, interesting issue from popey on the forum, 'snap interfaces' and conns state has the connection, but gnome snaps complain about lack of it; i've vague memory of something similiar before, do you remember?
[09:16] <pstolowski> zyga: and it's 2.35.4
[09:17] <pstolowski> zyga: was there something about profile generation you were investigating some time ago?
[09:18] <pstolowski> it's https://forum.snapcraft.io/t/cant-connect-interfaces-so-cant-run-snaps/8123
[09:18] <mup> PR snapd#5346 closed: cmd/snap: gnome-software install via snap:// handler <Created by jhenstridge> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5346>
[09:24] <Chipaca> update sequencing makes my head hurt, still
[09:28] <Chipaca> mborzecki: the snapcraft static suite doesn't like spread-shellcheck :-(
[09:29] <Chipaca> mborzecki: I reformatted it with black, which passed the first hurdle, but now its flake8 is saying it's all too complicated
[09:30] <Chipaca> zyga: at what  point are cmd/snap-confine/spread-tests/ run?
[09:33] <zyga> Never, those are the old ones from split repo
[09:33] <zyga> Probably more stale than ever
[09:33] <zyga> pstolowski: still afk at vet, will be home in 10 min
[09:34] <mborzecki> Chipaca: heh, we can feed spread-shellcheck to snapcraft, have them fix it to be nice python, and merge it back
[09:34] <Chipaca> mborzecki: *cough* snapcraft#2381 *cough*
[09:34] <mup> PR snapcraft#2381: tools: copy in spread-shellcheck from snapd <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/2381>
[09:34] <zyga> pstolowski: can you please ask for mount profiles
[09:34] <zyga> Current and desired
[09:36] <mborzecki> btw. are we having any talks about ubuntu core & snaps at ELC?
[09:37] <mborzecki> Chipaca: heh, checkfile is too complex, it's the cyclic complexity check right?
[09:37] <Chipaca> mborzecki: "aaah this is too complicated i give up"
[09:37] <Chipaca> mborzecki: I imagined flake8 slamming the program printing down and going off in a huff
[09:37] <mborzecki> Chipaca: i have some expierience working around gocyclo :P
[09:38] <mborzecki> wonder if that applies to python too
[09:38] <mborzecki> Chipaca: probably dropping some ifs would help
[09:38] <Chipaca> mborzecki: I was going to just leave it there and see if snapcrafters would push a fix :-)
[09:39] <mborzecki> Chipaca: hm ther's if > for > for > if sequence
[09:40] <Chipaca> i'm going to have to figure out why flake8 locally complains about everything, making it pointless, aren't i
[09:40] <Chipaca> sigh
[09:40]  * Chipaca remembers the snapcraft venv, and tries that
[09:41] <Chipaca> mborzecki: got it
[09:41] <Chipaca> mborzecki: i'll fix
[09:42] <mborzecki> Chipaca: heh, it's fun when you apply an artificial metric and thresholds and then workaround to meet the them :)
[09:48] <pstolowski> popey: allright, i'll ask you to collect a bunch of other info in a moment
[09:49] <popey> pstolowski: ok
[09:50] <zyga> re
[09:50] <zyga> dog safely home, still numb. but alive :)
[09:51] <pstolowski> zyga: are the *fstab files from the host os useful, or only those from the mount namespace?
[09:52] <zyga> pstolowski: we want a pair of files: /var/lib/snapd/snap.$SNAP_NAME.fstab and /run/snapd/ns/snap.$SNAP_NAME.fstab
[09:53] <Chipaca> mborzecki: http://paste.ubuntu.com/p/6hmN9bKR6j/
[09:54] <pstolowski> zyga: k, thanks
[09:55] <zyga> thank you, let me know if you get more data
[10:00] <mborzecki> Chipaca: does that bring the complexity count down?
[10:03] <Chipaca> mborzecki: it brings it down to 9, apparently
[10:03] <Chipaca> no, 10
[10:03] <mborzecki> Chipaca: lgtm
[10:03] <Chipaca> mborzecki: from 12 or 14 that it was
[10:04] <Chipaca> 12
[10:04] <Chipaca> mborzecki: ok, i'll push it
[10:04] <Chipaca> of course now black doesn't like it
[10:04] <Chipaca> :-)
[10:08] <zyga> pstolowski: the .fstab files are available in all namespaces
[10:08] <zyga> you don't need to be in a specific spot to read them
[10:09] <pstolowski> zyga: yep, i figured by md5'suming them just to be sure ;)
[10:29] <pstolowski> popey: ty! zyga, all the info there
[10:30] <thresh> is there a way to make firefox in a snap to use the same mouse pointer as system-wide?
[10:32] <zyga> popey, pstolowski: responded
[10:32] <zyga> thresh: kenvandine would know I suspect
[10:33] <ogra> you can surely fake it if you ship the cursor theme and force theme defaults for your app
[10:33] <pstolowski> zyga: thanks, interesting (whether the script does the right thing)
[10:33] <ogra> but thats indeed only making it a look-alike and only works as long as the default of the system has not been changed
[10:35] <popey> pstolowski: fyi. I just did ctrld to exit that thing you had me enter. The second I did that something segfaulted and I lost  my entire desktop
[10:35] <zyga> popey: !!
[10:35] <pstolowski> woot
[10:35] <zyga> can you please collect some logs
[10:35] <zyga> I saw something similar on my machine once
[10:35] <zyga> I was inside a mount namespace entered via nsenter
[10:35] <thresh> well, me being on KDE and using breeze/dark will only make it more complex with firefox being a gtk app
[10:36] <zyga> I hit exit and my desktop blinked
[10:36] <zyga> I was surprised because as far as we're concerned that's just bash quitting
[10:36] <thresh> but at least having the mouse pointer scaled 2x would already help
[10:36] <pstolowski> popey: sorry! unintended and unexpected
[10:36] <zyga> popey: are you on Wayland?
[10:36] <ogra> thresh, well, my suggestion above would also not scale it ... just set a shipped default so you dont end up with the x11 pointer
[10:37] <popey> No. X11
[10:37] <zyga> hmmm
[10:37] <zyga> collect logs please, let's try to understand what crashed
[10:38] <popey> ogra: thresh mouse cursors are on kenvandine radar
[10:38] <ogra> (though you could probably write a complex wrapper, read the dpi, force the theme up in scale etc etc ... but thats super hackish and pretty overkill)
[10:38] <ogra> (pretty much what ken will eventually do in a clean way as popey says :) )
[10:39] <thresh> gotcha
[10:39] <thresh> thanks!
[10:39] <popey> We shouldn't work around this but fix it
[10:39] <ogra> popey, we should ... since 2 years :P
[10:39] <ogra> if only the day had more hours
[10:39] <popey> http://paste.ubuntu.com/p/sQtP7vmXPY/
[10:39] <ogra> :D
[10:39] <popey> Dmesg from my exploded session
[10:40] <zyga> some things crashed on X
[10:41] <zyga> but I suspect X disconnected
[10:41] <zyga> and those things died as a consequence
[10:41] <zyga> popey: can you look for logs of X
[10:41] <zyga> not sure how yet
[10:41] <popey> Yeah
[10:42] <cachio> pstolowski, hey,
[10:42] <zyga> TBH I'm not sure how X is started or managed nowadays
[10:42] <pstolowski> hey cachio !
[10:42] <cachio> pstolowski, did it work the change
[10:42] <cachio> could you try it?
[10:43] <pstolowski> cachio: I think it didn't, i'm just giving it another try
[10:43] <zyga> for instance it _seems_ that gdb runs everything
[10:43] <zyga> gdm then has gdm-session-worker as a child
[10:43] <cachio> pstolowski, do you have the command line you used to start the vm?
[10:44] <zyga> then gdm-x-session
[10:44] <zyga> perhaps X is hidden there
[10:44] <pstolowski> cachio: yes i've. let's talk in a private channel
[10:44] <zyga> but no idea really
[10:44] <zyga> popey: can you work with someone from the desktop team to help us understand this, if you can reproduce this the better
[10:44] <zyga> popey: do you have Nvidia drivers?
[10:44] <popey> I do
[10:45] <popey> http://paste.ubuntu.com/p/VxM3bjHq3K/
[10:45] <popey> Syslog
[10:45] <zyga> popey: I see
[10:45] <popey> Need to reboot to actually do some work
[10:46] <zyga> Oct 23 11:30:43 hal /usr/lib/gdm3/gdm-x-session[2062]: (**) Option "fd" "84"
[10:46] <zyga> Oct 23 11:30:43 hal /usr/lib/gdm3/gdm-x-session[2062]: (II) event3  - Power Button: device removed
[10:46] <zyga> I think this is udev input triggering
[10:46] <zyga> but no idea why it would happen
[10:47] <ogra> do interfaces still call udevadm tigger ?
[10:47] <ogra> iirc we had some doing that
[10:48] <zyga> Oct 23 11:30:39 hal org.gnome.Shell.desktop[2197]: Window manager warning: last_focus_time (773055215) is greater than comparison timestamp (773055214).  This most likely represents a buggy client sending inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to work around...
[10:48] <zyga> then all hell breaks loose it seems
[10:48] <zyga> ogra: regardless of what happens in udev - in this case we were not using interfaces
[10:48] <zyga> popey just closed bash
[10:48] <ogra> ouch, ok
[10:48] <popey> well, i closed the command I had opened in bash
[10:49] <zyga> popey: right
[10:49] <zyga> it should not have happened
[10:49] <zyga> btw, I have the same mouse :)
[10:49] <popey> :)
[10:49] <zyga> Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (EE) NVIDIA(GPU-0): Failed to acquire modesetting permission.
[10:49] <zyga> this is interesting
[10:50] <zyga> but TBH I think the X + Nvidia combo is something someone needs to look into
[10:50]  * zyga has no nvidia
[10:50] <zyga> popey: do you think it would help if I had a GPU at home?
[10:50] <zyga> I could stick it into my test desktop for cases like that :/
[10:50] <popey> 🤷‍♂️
[10:50] <mborzecki> what what nvidia?
[10:50] <zyga> popey: Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (EE) Please also check the log file at "/var/log/Xorg.1.log" for additional information.
[10:50] <zyga> do you still have that log files?
[10:50] <zyga> perhaps X log has more fun stuff
[10:51] <zyga> Oct 23 11:30:46 hal /usr/lib/gdm3/gdm-x-session[2062]: (WW) NVIDIA(0):  - Setting a mode on head 0 failed: Insufficient permissions
[10:51] <zyga> Oct 23 11:30:47 hal nautilus[13429]: nautilus: Fatal IO error 11 (Resource temporarily unavailable) on X server :1.
[10:51] <zyga> so my theory is as follows:
[10:51] <zyga> something is broken in the desktop session and your ctlr+d went to X
[10:51] <zyga> X got nuts and went belly up
[10:52] <zyga> apps died making lots of noise when X disconnected
[10:52] <zyga> I think a  test case is to:
[10:52] <zyga> open bash just like you had befor
[10:52] <zyga> (nsenter and such)
[10:52] <zyga> and ctrl+d
[10:52] <zyga> perhaps open the same apps
[10:52] <zyga> not sure if there's a catalyst that makes this happen
[10:52] <zyga> remember when ctrl-c was killing gdm?
[10:53] <zyga> because overzealous input somewhere
[10:53] <mborzecki> popey: what did you do?
[10:54] <popey> good question
[10:55] <mup> PR snapd#6030 opened: cmd/snap: tweak `snap services` output when there is no services <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6030>
[10:55] <mborzecki> popey: i mean, what command did you run? i don't see it in the log
[10:56] <popey> sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt
[10:56] <zyga> so you were root
[10:56] <popey> and now I have rebooted, the snaps that didn't work, now work
[10:56] <ogra> zyga, popey https://bugs.launchpad.net/ubuntu/+source/gdm3/+bug/1710637
[10:56] <zyga> (not that it would explode because you were root and wrote ctrl+d)
[10:56] <popey> i cant see that ogra
[10:57]  * zyga can
[10:57] <zyga> but that was fixed in 2017
[10:57] <ogra> that was the "ctrl+c (or +d) kills gdm" bug
[10:57] <zyga> that's the bug where Ctrl-c goes to the wrong place
[10:57] <zyga> but
[10:57] <zyga> popey: I'll add you there
[10:57] <zyga> can you read the last few comments
[10:58] <zyga> done
[10:58] <zyga> there's a command
[10:58] <zyga> wait
[10:58] <zyga> 503
[10:58] <zyga> :/
[10:58] <zyga> still 503
[10:58] <mborzecki> heh, pefect timing
[10:59] <mborzecki> zyga: btw. that PR ^^ hopefuly Chipaca and degville can help come up with a message that makes sense :)
[10:59] <zyga> popey: ok, as a quick reproduce test
[10:59] <popey> Note, I haven't restarted my system for 15 days before this happened
[10:59] <popey> I seem to see all these odd issues because I have "long" uptimes
[10:59] <popey> stuff seems to get itself well wedged as a result
[11:00] <zyga> popey: run as root: udevdm trigger; udevadm settle --timeout=10
[11:00] <zyga> this _may_ trigger bad stuff
[11:00] <zyga> so mind the abyss
[11:00] <zyga> then try the nsenter thing again
[11:01] <zyga> I have a feeling we should stop using udev rules for tagging
[11:01] <zyga> and use croups
[11:01] <zyga> cgroups
[11:01] <ogra> croups ?
[11:01] <zyga> moronic spellchecker
[11:01] <ogra> croutons ?
[11:01] <ogra> :)
[11:01] <zyga> cre^p du kernel ;)
[11:02] <ogra> :D
[11:02] <popey> Yes
[11:02] <popey> That did bad things
[11:02] <popey> Desktop exploded
[11:02] <zyga> perfect
[11:02] <zyga> package this in a bug report
[11:02] <popey> Thanks
[11:02] <zyga> along with system version, the driver you had (version) and perhaps the make of the card
[11:03] <zyga> we will take it from there
[11:03] <popey> Against gdm3?
[11:03] <zyga> and I'm very sorry for the inconvenience this is causing
[11:03] <popey> Or snapd
[11:03] <zyga> against snapd first
[11:03] <popey> Kk
[11:03] <zyga> so that we can alter the status
[11:03] <zyga> we can affect others as we discover
[11:03] <popey> Will do
[11:03] <zyga> woot!
[11:03] <popey> Nice one
[11:04]  * zyga inserts mental model of a plane falling on fire with two engineers watching from the ground, congratulating each other, one saying "woot, you were right, it was the fuel injection pump" 
[11:04] <popey> This is separate from the original issue though, right :)
[11:04] <zyga> "reproduced"
[11:04] <zyga> I think so
[11:05] <zyga> popey: I don't have recent enough hardware but I will see if this happens without nvidia
[11:05] <zyga> and then buy a card for testing
[11:05] <zyga> and upcoming chunk of Nvidia work anwy
[11:10] <zyga> wooot
[11:10] <zyga> reproduced like hell
[11:10] <zyga> popey: no nvidia neede
[11:10] <zyga> we need to get off of udev
[11:10] <zyga> touching udev is bad
[11:11] <zyga> here's my login screen
[11:11] <zyga> I think willcooke is on a sprint now, right?
[11:12] <popey> https://bugs.launchpad.net/snapd/+bug/1799433
[11:12] <mup> Bug #1799433: GNOME desktop on nvidia crashes when exiting nsenter <snapd:New> <https://launchpad.net/bugs/1799433>
[11:12] <zyga> popey: funny, in my case something crashed, desktop blinked but my programs were intact
[11:12] <zyga> I logged in and it was back
[11:12] <popey> hah
[11:12] <zyga> but it's clearly broken
[11:12] <popey> I am happy for you :)
[11:13] <diddledan> OT https://github.com/features/actions
[11:14] <pstolowski> zyga: see my comment re that problem
[11:16] <zyga> pstolowski: replied
[11:16] <pstolowski> zyga: ah, sorry, let me remove this not to bring confusion
[11:21] <mborzecki> zyga: it does not reproduce here, i mean udevadm trigger && settle and nsenter
[11:23] <mborzecki> zyga: popey: nope, maybe i'm doing something wrong
[11:28] <zyga> mborzecki: we're talking in the #ubuntu-desktop channel as well
[11:28] <zyga> same, I cannot reproduce it again
[11:28] <zyga> maybe I was just very lucky
[11:28] <zyga> (that one time)
[11:31] <mborzecki> zyga: popey: i'm looking through my irc logs, but i recall we discussed a similar case when udevadm trigger with nvidia would bring down the whole session
[11:31] <popey> yeah
[11:31] <zyga> mborzecki: note, I was not on nvidia
[11:31] <popey> this is familiar
[11:32] <mborzecki> popey: do you remember what that was?
[11:32] <popey> not without grepping logs
[11:33] <popey> https://forum.snapcraft.io/t/weird-udev-enumerate-error/2360/9
[11:33] <mborzecki> popey: heh, grepping is what i do, i really wish i had that indexed by xapian or sth
[11:50]  * zyga lunches
[11:52] <mborzecki> popey: zyga: i think last time we discussed this: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1760104
[11:52] <mup> Bug #1760104: Xorg crashed with SIGSEGV in InputReady() from ospoll_wait() from InputThreadDoWork() <amd64> <apport-crash> <bionic> <compiz-0.9> <single-occurrence>
 <snapd:Invalid> <nvidia-graphics-drivers (Ubuntu):Confirmed> <xorg-server (Ubuntu):Confirmed> <https://launchpad.net/bugs/1760104>
[11:53] <mborzecki> off to pick up the kids
[11:53] <zyga> indeed
[11:53] <zyga> interesting
[12:21]  * pstolowski lunch
[12:31] <dot-tobias> Hi greyback, may I ask if you found the time to identify the cause for the rotation issue in chromium-mir-kiosk (https://discourse.ubuntu.com/t/snaps-to-develop-a-web-kiosk-on-ubuntu-core-using-wayland/6424/87) when rotating mir-kiosk to portrait mode (https://community.ubuntu.com/t/display-configuration-for-mir-kiosk/7815/3)? I'm currently building the snap with an altered i3 config which sets default_orientation = vertical. Does not seem to help,
[12:31] <dot-tobias>  except I get a short i3 nagbar “you have an error in your configuration file”, but I cannot figure out what the error is.
[12:32] <ogra> dot-tobias, did you try shipping xrandr and use its rotation feature ?
[12:32] <greyback> dot-tobias: hey, my apologies but I've been focused elsewhere.
[12:32] <ogra> alternatively i think you would actually need a mir config to force the rotation
[12:33] <ogra> https://community.ubuntu.com/t/configuring-mir-kiosk-a-masterclass/8150
[12:33] <greyback> ogra's idea is worth a try, but I suspect it is i3 itself that isn't dealing with the X display rotation
[12:33] <greyback> alan_g looked into it and it did appear that Xwayland was being correctly told by mir that the display had rotated
[12:33] <dot-tobias> ogra: Not yet, was hoping I could achieve this through config files. Adding a layout for mir-kiosk rotates just fine, but chromium-mir-kiosk (which uses i3) does not pick up on it.
[12:33] <ogra> ouch
[12:34] <greyback> dot-tobias: as (lousy) workaround, could you make i3 size the chromium window in pixels at the size you desire?
[12:34] <ogra> i'll hit that myself soon, working on https://snapcraft.io/magicmirror to build a pre-configured appliance image :)
[12:35] <dot-tobias> greyback: Yeah, that workaround is building right now on my Pi 😊 But good to hear that would actually work.
[12:35] <ogra> uh, you build on your pi ?
[12:35] <ogra> use build.snapcraft.io ;)
[12:35] <ogra> (it might fail to release, but you can still directly download the bult snap from there)
[12:35] <ogra> *built
[12:36] <dot-tobias> I use launchpad in parallel, but we're hosting everything on Gitlab.com which is currently not supported by build.snapcraft?
[12:36] <greyback> dot-tobias: it shoud work, afaics i3 just isn't sizing the chromium surface by flipping the width/height
[12:36] <ogra> ah, right
[12:37] <ogra> launchpad offers git imports into local LP trees ... you might be able to use that with gitlab, not sure
[12:39] <dot-tobias> ogra: That's actually exactly what I used, but good to hear I went in the right direction 😊
[12:39] <ogra> heh
[12:44] <mup> PR snapd#6031 opened: snap/pack, cmd/snap: allow specifying the filename of 'snap pack' <Created by chipaca> <https://github.com/snapcore/snapd/pull/6031>
[13:18] <mup> PR # closed: snapd#5170, snapd#5644, snapd#5696, snapd#5712, snapd#5714, snapd#5727, snapd#5789, snapd#5792, snapd#5822, snapd#5845, snapd#5885, snapd#5887, snapd#5897, snapd#5915, snapd#5916, snapd#5946, snapd#5954, snapd#5955, snapd#5958, snapd#5962, snapd#5963, snapd#5972, snapd#5981,
[13:18] <mup> snapd#5982, snapd#5987, snapd#5996, snapd#6000, snapd#6008, snapd#6010, snapd#6016, snapd#6019, snapd#6023, snapd#6025, snapd#6027, snapd#6028, snapd#6030, snapd#6031
[13:19] <mup> PR # opened: snapd#5170, snapd#5644, snapd#5696, snapd#5712, snapd#5714, snapd#5727, snapd#5789, snapd#5792, snapd#5822, snapd#5845, snapd#5885, snapd#5887, snapd#5897, snapd#5915, snapd#5916, snapd#5946, snapd#5954, snapd#5955, snapd#5958, snapd#5962, snapd#5963, snapd#5972, snapd#5981,
[13:19] <mup> snapd#5982, snapd#5987, snapd#5996, snapd#6000, snapd#6008, snapd#6010, snapd#6016, snapd#6019, snapd#6023, snapd#6025, snapd#6027, snapd#6028, snapd#6030, snapd#6031
[13:24]  * Chipaca hugs mup
[13:29] <mup> Issue core18#86 opened: Ubuntu 18.10 <Created by kravietz> <https://github.com/snapcore/core18/issue/86>
[13:58] <diddledan> did mup just vomit?
[13:58] <diddledan> lots of "PR # closed"
[13:59] <ogra> it rather "released a constipation"
[13:59] <diddledan> aha. stinky mup!
[14:10] <dot-tobias> ogra: (late reply re: rotation & mirror applkiance after AFK) BTW using display_rotate and dtoverlay=vc4-fkms-v3d (https://github.com/michmich/magicmirror/wiki/configuring-the-raspberry-pi#enable-the-open-gl-driver-to-decrease-electrons-cpu-usage) works most of the time with mir-kiosk, but it produced some funny rendering issues and the Pi heats up considerably. Had two temp-induced reboots,
[14:26] <mup> PR snapd#5981 closed: interfaces/many: updates to support k8s worker nodes <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5981>
[14:27] <Chipaca> hmmm
[14:27] <Chipaca> i should probably have lunch
[14:27] <ogra> isnt that linner already ?
[14:28] <ogra> dot-tobias, fkms is 100% SW rendering, it completely turns off the GPU
[14:28] <ogra> your board will overheat if you run it for a while
[14:29] <dot-tobias> ogra: that's what I thought, and observed … I'll test the i3 resizing and/or xrandr route once I'm back at the office.
[14:29] <ogra> either use the kms driver and gallium or somehow get the closed source driver to work ... but i doubt thats possible without also patching the kernel
[14:32] <ogra> sadly using kms means no rotation before mir comes up (i.e. splash screen)
[14:33] <zyga> mborzecki: could you please review https://github.com/snapcore/snapd/pull/6010
[14:34] <mup> PR #6010: cmd/snap-discard-ns: add support for per-user mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/6010>
[14:34] <zyga> you did in the past but not fully (vote vote vote)
[14:38] <zyga> mborzecki: I'll review your ordering PR next, I stopped on Khan before and then it got lost in a tab swarm
[14:43] <dot-tobias> ogra: is that what you mentioned about the missing /dev/fb0 in your PR @ https://github.com/snapcore/pi3-gadget/pull/13 ? Or unrelated? I could live with an always-portrait splash for now 😊
[14:43] <mup> PR pi3-gadget#13: add splash support <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/13>
[14:44] <ogra> dot-tobias, the missing framebuffer is caused by the vc4 module not being in the initrd ...
[14:45] <ogra> dot-tobias, i have a workaround in my pi-kiosk gadget
[14:45] <ogra> https://github.com/ogra1/pi-kiosk-gadget
[14:46] <ogra> and the next kernel should actually even add the modules to the initrd by default so only the modprobe call might be needed (if at all) ... i'm not sure where we stand with that though ... ppisati is your man
[14:47] <tomwardill> hello! another question about pre-refresh hooks, which version of the hook do they execute? The installed version or the about-to-be-installed one?
[14:47] <tomwardill> the docs here https://docs.snapcraft.io/supported-snap-hooks/3795 aren't entirely clear
[14:47] <ogra> if you'd do the installed one, your fix to that hook would only apply in the next update ...
[14:48] <ogra> so i guess you can assume it is the about-to-be-installed one
[14:48] <dot-tobias> ogra: I have your pi-kiosk gadget on my todo/inspiration list for exactly that usecase 😊 Thank you for your work btw!
[14:48] <ogra> np :)
[14:51] <tomwardill> ogra: thanks :)
[14:51] <Gargoyle> Is there any way to accelerate the launch of snap apps?
[14:52] <ogra> buy a faster disk ? :)
[14:52] <zyga> Gargoyle: snaps launch very very quickly - what is slow are parts of the desktop stack, such as fontconfig, that is unique to each snap
[14:52] <zyga> Gargoyle: work on fontconfig should improve that situation to the point where perhaps a shared cache can be used?
[14:53] <ogra> specifically at the foirst start of a desktop snap you have a lot of stuff being copied around
[14:53] <zyga> Gargoyle: to see how fast snaps run install snapd-hacker-toolbelt and time it
[14:53] <ogra> (and generated etc)
[14:53] <Gargoyle> ahh so the 15 seconds it takes atom to launch it doing things like updating the fontconfig cache each time?
[14:54] <zyga> I don't think it is each time
[14:54] <diddledan> don't you love when builds are long: https://usercontent.irccloud-cdn.com/file/u3SMBRXX/image.png
[14:54] <mup> PR snapcraft#2382 opened: unit tests: missing full adapter in extension test <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2382>
[14:54] <zyga> but it should be per ... something
[14:54] <zyga> (per revision perhaps?)
[14:54] <zyga> but I really don't know
[14:54] <zyga> it needs per-snap analysis
[14:54] <zyga> though I believe the overhead from desktop helpers is commonly known
[14:55] <Gargoyle> OK. I think something might be screwy on my laptop then. It;s taking 15s every time. But it's also giving me the "first run" screen every time too
[14:56] <zyga> Gargoyle: perhaps something to debug with kenvandine
[14:56]  * zyga returns to reviews
[15:07]  * Chipaca drags himself off to have something to eat before he keels over
[15:14] <mup> PR snapd#6030 closed: 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>
[15:23] <Chipaca> zyga: notes := []string{"", ""}[:0]
[15:24] <zyga> haha
[15:24] <zyga> yeah
[15:24] <zyga> I don't know if golang does any static arrays but perhaps :)
[15:24] <Chipaca> zyga: OTOH i don't know why you care :-)
[15:24] <zyga> we seem to care about some trivial optimisations like that
[15:24] <zyga> like pre-computing array size
[15:25] <zyga> I heard that map resizing is slow
[15:25] <zyga> but nothing tangible I can recall
[15:25] <Chipaca> zyga: it's a little bit bad if it leaves the function, and can be big
[15:26] <Chipaca> zyga: and is in something long-lived
[15:26] <Chipaca> otherwise, eh
[15:53] <kyrofa> zyga, Chipaca is core edge not on snapd master at the moment?
[15:53] <kyrofa> Perhaps I should have phrased that the other way around
[15:54] <kyrofa> And in reality, perhaps that's a question for cachio
[15:54] <Chipaca> kyrofa: edge is 11 hours old
[15:54] <Chipaca> and  built from master
[15:54] <mup> PR snapd#6027 closed: 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>
[15:54] <Chipaca> afaik :-)
[15:55] <kyrofa> Chipaca, I can't find that commit hash though
[15:55] <Chipaca> I'd love to know why you even care,  but ok
[15:56] <kyrofa> Haha, Chipaca because it doesn't seem to contain what I WANT it to contain, so I'm trying to figure out what it DOES contain
[15:56] <Chipaca> kyrofa: what do you want it to contain?
[15:57] <kyrofa> Chipaca, https://github.com/snapcore/snapd/pull/6029
[15:57] <mup> PR #6029: snapstate: add command-chain to supported featureset <Created by kyrofa> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6029>
[16:00] <Chipaca> kyrofa: hmm
[16:00] <Chipaca> I wonder if we're mangling the tree before building the snap
[16:01] <kyrofa> Making some sort of temporary commit?
[16:01] <Chipaca> kyrofa: https://launchpadlibrarian.net/394484955/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
[16:09] <kyrofa> Chipaca, hmm. That doesn't tell me much. Edge doesn't seem to contain the functionality I added there, so I'm trying to figure out if it's broken or just not there. Are you pretty sure it's the former?
[16:10] <Chipaca> kyrofa: what time was that build started?
[16:11] <kyrofa> Chipaca, ah, looks like yesterday in my early morning
[16:11] <Chipaca> kyrofa: i thought it was today
[16:11] <Chipaca> but dunno where you are in the world
[16:11] <kyrofa> Chipaca, Mon Sep 24 13:14:43 UTC
[16:12] <Chipaca> .... wat
[16:12] <Chipaca> that's a month ago
[16:12] <kyrofa> Oh
[16:12] <kyrofa> Uh
[16:12] <Chipaca> where are you looking?
[16:12] <kyrofa> Whoops, ignore me
[16:12] <Chipaca> way ahead of you
[16:12] <Chipaca> :-þ
[16:15] <kyrofa> Chipaca, you're right, looks like it was today
[16:16] <Chipaca> 4am utc is pretty much exactly 12 hours ago
[16:16]  * zyga grabs dinner 
[16:17] <Chipaca> kyrofa: so now the question is did the git tree in launchpad get the commit you wanted in time
[16:17] <Chipaca> it's cutting it close :-)
[16:18] <kyrofa> Yeah it is. It doesn't look like it, but there's no way to be sure unless snapd happens to shove a changelog in there
[16:19] <kyrofa> It does!
[16:21] <kyrofa> Not sure how this works though. If this is to be believed it's just 2.36~pre2
[16:21] <Chipaca> kyrofa: i think the changelog has a manual step
[16:22]  * Chipaca grabs cachio before he runs off again
[16:24] <Chipaca> cachio: hi
[16:24] <Chipaca> cachio: how can kyrofa figure out what commits of snapd are on core edge?
[16:34] <zyga> re
[16:34] <zyga> back to reviews
[16:37] <cachio> Chipaca, kyrofa there is a launchpad repo
[16:37] <cachio> on sed
[16:37] <cachio> sec
[16:38] <cachio> kyrofa, this is the repo https://launchpad.net/snapd-vendor
[16:39] <cachio> it takes a time to create the snap
[16:39] <cachio> kyrofa, what do you need to do with it?
[16:40] <kyrofa> cachio, I was hoping folks could utilize a PR that landed yesterday
[16:40] <kyrofa> Chipaca, ah, the commit hash comes from that ^
[16:42] <kyrofa> cachio, so what, you just dump snapd master into that every few days?
[16:44] <cachio> kyrofa, we dump it always when master is in green
[16:44] <cachio> so, we run tests on master branch after each merge
[16:45] <cachio> if the tests pass, then we run a script to dump the master to this lp repo
[16:46] <cachio> then, based on that, we build the core snap on edge
[16:46] <cachio> it takes some time
[16:47] <kyrofa> Okay so based on this, the edge snap is based on snapd master as of Friday?
[16:48] <kyrofa> Am I deducing this all correctly?
[16:48] <Chipaca> kyrofa: BTW, you know assumes: is a last-ditch kind of thing, currently? it's not user friendly at all
[16:49] <cachio> kyrofa, let me check when was the last one
[16:49] <Chipaca> kyrofa: it's fine for exploratory work or for super-early-adopters kind of thing, but not for end users
[16:49] <Chipaca> kyrofa: it'll download the snap before even knowing about assumes
[16:49] <Chipaca> and throw a hissy fit at you
[16:49] <kyrofa> Chipaca, yeah. It's either that or magically not work
[16:50] <cachio> kyrofa, edge snap is based on snapd master
[16:50] <cachio> it si right
[16:51] <cachio> based on last master which has passed the tests
[16:52] <cachio> kyrofa, last one is from today
[16:54] <kyrofa> cachio, I'm confused. The edge snap has this version: "16-2.36~pre2+git967.54466bd"
[16:54] <mup> PR snapcraft#2383 opened: ci: use more travis primitives for osx tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2383>
[16:54] <kyrofa> cachio, that commit hash points to a commit you made on Friday: https://git.launchpad.net/snapd-vendor/commit/?id=54466bdcf1432fb7c2869a3abbf92751186aaa42
[16:55] <kyrofa> Although when I click on it it changes to Saturday... but I'll ignore that :P
[16:55] <kyrofa> Timezones I guess
[16:56] <kyrofa> And if I look at the file I'm interested in, it's definitely not from today-ish since it doesn't contain the commit that landed yesterday: https://git.launchpad.net/snapd-vendor/tree/overlord/snapstate/check_snap.go?id=54466bdcf1432fb7c2869a3abbf92751186aaa42
[17:01] <koala_man> mborzecki, Chipaca: I'm glad you're finding shellcheck useful! unfortunately the shellcheck snap build has been broken for a while due to https://bugs.launchpad.net/snapcraft/+bug/1797809 . Any suggestions?
[17:02] <mup> Bug #1797809: Build fails on snapcraft.io, works locally (during `cabal update`) <Snapcraft:New> <https://launchpad.net/bugs/1797809>
[17:04] <Chipaca> koala_man: I didn't know, no! and yes, we're using it all over the place including in static checks of snapd itself
[17:05] <Chipaca> koala_man: I've got to run now, but I'll take a look later
[17:05] <koala_man> I'd appreciate it ^^
[17:06] <Chipaca> kyrofa: sergiusens: if you have a bit of time, ^^^
[17:07] <kyrofa> koala_man, one of the better tools I've used
[17:07] <kyrofa> We're using it in snapcraft as well
[17:08] <kyrofa> koala_man, do you know if cabal obeys http_proxy?
[17:08] <koala_man> kyrofa: yes, it does
[17:09] <koala_man> If I run http_proxy='http://localhost:12345' cabal update  it fails with "cabal: Couldn't establish HTTP connection. Possible cause: HTTP proxy server is down."
[17:10] <kyrofa> cjwatson, are you around? Curious to get your thoughts on https://bugs.launchpad.net/snapcraft/+bug/1797809
[17:10] <mup> Bug #1797809: Build fails on snapcraft.io, works locally (during `cabal update`) <Snapcraft:New> <https://launchpad.net/bugs/1797809>
[17:13]  * zyga goes for last streak today
[17:15] <cachio> kyrofa, the commit summary has the commit in githb
[17:15] <cachio> kyrofa, the last commit on lp has a commit message which points to c712d09ac22ee65c48b520f462f8ddbaf1ee5efa commit on github
[17:15] <cachio> this it the traceability
[17:17] <kyrofa> cachio, right, but that one's not in edge
[17:17] <kyrofa> How often is it built?
[17:24] <mup> PR snapcraft#2384 opened: project: do not install base is already installed <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2384>
[17:27] <cachio> kyrofa, once a day aprox
[17:27] <cachio> during the night
[17:27] <cachio> kyrofa, 4 am was built the last one
[17:28] <kyrofa> cachio, then why is the version referring to 54466bd?
[17:29] <cachio> we have a sync job which takes the changes in snapd master and push it to launchpad
[17:30] <cachio> the 54466bd... is the commit on launchpad which has the same content than whe commit id added in the summary
[17:30] <cachio> Content updated (b5e852ba093baad2624a8ecc32e9715c72631752)
[17:31] <cachio> so yoy know the commit in lp 	54466bdcf1432fb7c2869a3abbf92751186aaa42 is the same then the commit in github b5e852ba093baad2624a8ecc32e9715c72631752
[17:31] <cachio> then every night another job is executed which creates and publishes the core on edge
[17:32] <cachio> it takes the last change in the lp repo and use that to create the core snap
[17:32] <cachio> it is a bit complicated :)
[17:33] <kyrofa> Ah, I'm just looking at the commit timestamps and thinking "13 hours ago was yesterday!" but I suppose not everywhere
[17:34] <kyrofa> Okay so the one that builds tomorrow will be what I want
[17:34] <kyrofa> Thanks cachio, that traceability is handy
[17:35] <cjwatson> kyrofa: should be reassigned over to launchpad-buildd - I guess either cabal ignores the proxy or they manage to confuse each other somehow
[17:36] <kyrofa> cjwatson, will do, thanks :)
[17:36] <cachio> kyrofa, yes, I think tomorrow will be includede
[17:36] <cjwatson> kyrofa: I think I saw another question about the same thing recently but it doesn't seem to have ended up as a launchpad-buildd bug, so ...
[17:36] <cachio> otherwise ping me
[17:38] <kyrofa> koala_man, cjwatson knows everything about build.snapcraft.io, he'll help get that working
[17:39] <koala_man> awesome! I'm happy to help in any way I can
[17:40] <koala_man> cjwatson: is there any way I can run the build locally with the same proxy?
[17:48] <cjwatson> koala_man: It's possible but complicated.  Requires setting up a xenial VM, installing launchpad-buildd in it from ppa:launchpad/ubuntu/ppa, and then sending some err not-very-well-documented XML-RPC commands to it to get it to do something ...
[17:49] <cjwatson> Oh and of course you need a proxy for it to talk to
[17:50] <cjwatson> I suspect the problem here is the localhost-only proxy that launchpad-buildd runs to avoid builds needing to be able to cope with authenticated proxies
[17:53] <koala_man> cabal apparently has a --http-transport=curl flag that can be switched to wget or plain-http. is there a nice way to test this that doesn't involve me pushing upstream test commits?
[17:53] <koala_man> by the way, this used to work, and I can probably find the date it started breaking if that's helpful
[17:54] <cjwatson> Testing it locally can be done by just dispatching a snap build, but I won't be able to get to it until later this week
[17:55] <cjwatson> It's quite likely that it started breaking in mid-June when we deployed the fix for bug 1690834 / bug 1753340
[17:55] <mup> Bug #1690834: snap builds in cleanbuild but fails on buildd <launchpad-buildd:Fix Released by cjwatson> <https://launchpad.net/bugs/1690834>
[17:55] <mup> Bug #1753340: build failing on download by ant build  <ant> <python> <snapcraft> <launchpad-buildd:Fix Released by cjwatson> <https://launchpad.net/bugs/1753340>
[17:55] <koala_man> I just looked it up and you're right
[17:55] <cjwatson> launchpad-buildd 162
[17:56] <cjwatson> I'd rather we not work around it in shellcheck TBH since you're probably not the only affected project
[17:56] <cjwatson> I'm slightly surprised I've only heard about this in relation to cabal
[17:57] <cjwatson> But there may be some subtle property of the HTTP connection that's confusing it
[17:57] <koala_man> of course, but it would be nice way to narrow down the problem
[17:57] <cjwatson> It would be possible to push test commits to a branch and create a test snap on LP that builds it
[17:57] <cjwatson> build.snapcraft.io can't do that, but it can be done directly using the API
[17:58] <cjwatson> https://launchpad.net/+apidoc/devel.html#snaps-new
[17:59] <cjwatson> Though TBH I suspect actually fixing the bug is going to require more direct debugging methods anyway - strace/tcpdump, that sort of thing
[17:59] <cjwatson> or a load of debugging prints sprinkled through the localhost-only proxy
[18:24] <mup> PR snapcraft#2383 closed: ci: use more travis primitives for osx tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2383>
[18:54] <zyga> jdstrand: hey, I know you are sprinting but if you have a moment please consider looking at https://github.com/snapcore/snapd/pull/5727
[18:54] <mup> PR #5727: interfaces/browser-support, cmd/snap-seccomp: Allow read-only ptrace, for the Breakpad crash reporter <Created by jld> <https://github.com/snapcore/snapd/pull/5727>
[18:55] <mup> PR snapd#6000 closed: snap,client: use a different exit code for retryable errors <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6000>
[18:59]  * cachio afk
[19:06] <koala_man> cjwatson: I would be willing to look into that if I had a simple way to reproduce it
[20:52] <mup> PR snapcraft#2382 closed: unit tests: missing full adapter in extension test <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2382>
[21:26] <AuroraAvenue> Hi N00b question. Is it possible to Snap the google Api ?
[21:26] <AuroraAvenue> https://developers.google.com/+/web/api/rest/
[21:27] <ijohnson> AuroraAvenue: if all you want to do is call the API via HTTP calls then yes you could have a snap which interfaces with the Google+ REST API
[21:39] <AuroraAvenue> cheers - I shall add it to the list.
[22:39] <mup> PR snapd#5727 closed: interfaces/browser-support, cmd/snap-seccomp: Allow read-only ptrace, for the Breakpad crash reporter <Created by jld> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5727>
[22:46] <mup> PR snapd#6023 closed: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6023>
[22:49] <mup> PR snapd#6032 opened: overlord/snapstate, snap, wrappers: start services in the right order during install <Created by mvo5> <https://github.com/snapcore/snapd/pull/6032>