[04:32] <jamesh> amurray: out of interest, was there some project in particular you wanted debug symbols for?
[04:33] <amurray> jamesh: I have a couple reports of crashes of my emacs snap and I am stumped how to easily enable users to get good backtraces
[04:37] <jamesh> we definitely want debug symbols for the snaps seeded on the desktop
[04:39] <jamesh> but there's not much to be done when they want a full design for snapcraft+store+snapd before considering any changes
[04:52] <amurray> jamesh: understood this is a "hard problem" ... but if folks want snaps to be first-class on the desktop there needs to be more focus on this IMO from all parties - it's not enough to have just you pushing on it (but I am glad you were)
[04:55] <jamesh> amurray: sure.  We've discussed it multiple times at previous dev summits, but when I've got more work to do than time available it is hard to prioritise something that gets ignored.
[04:56] <amurray> jamesh: i hear you
[04:56] <jamesh> I have gone back to update the first PR (https://github.com/snapcore/snapcraft/pull/2229) a few times to save it from bitrot, but that's about it
[04:56] <mup> PR snapcraft#2229: elf: extract build ID and presence of debug info <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/2229>
[05:13] <mborzecki> morning
[05:13] <mborzecki> wow, +11C outside :/
[05:39] <zyga> Good morning
[05:40] <zyga> Wow, I have a few more so not that drastic yet
[05:40] <zyga> Brrrrrr
[05:43] <mborzecki> zyga: hey
[05:48] <zyga> Doing school walk, be in the office soon
[06:03] <Mirv> do apps like signal-desktop, spotify, discord work for you on Ubuntu under Wayland? none of them start for me on SUSE under Wayland, and I'm wondering whether there's some low hanging fruit to grap.
[06:04] <Mirv> FYI https://pastebin.ubuntu.com/p/bSjqrJDhtf/
[06:05] <Mirv> I tried to search for LP bug reports at one point but it didn't sound they'd be broken for everyone
[06:05] <Mirv> Ubuntu defaults to X.org still so that makes it a bit different of course
[06:06] <jamesh> Mirv: is Xwayland listening on the abstract namespace socket?
[06:07] <Mirv> let me parse that for some time (or tell me how to check). it's running as /usr/bin/Xwayland :0 -rootless -terminate -accessx -core -auth /run/user/1000/mutter/Xauthority -listen 4 -listen 5 -displayfd 6
[06:07] <jamesh> i.e. @/tmp/.X11-unix/X0 in addition to /tmp/.X11-unix/X0
[06:07] <jamesh> I think you can check with ss.  Let me work out the invocation
[06:08] <jamesh> "ss -xl | grep X11" might be the best way to check
[06:09] <jamesh> I see two listening sockets locally
[06:09] <mborzecki> zyga: ^^ opensuse & wayland
[06:10] <Mirv> there's @ too: https://pastebin.ubuntu.com/p/QVKJpjP26R/
[06:11] <jamesh> I'm not sure then. The non-abstract socket is definitely blocked by snap confinement though
[06:11] <Mirv> ok, let's wait for zyga then. I'm in no hurry, just starting my work day, happy to help debugging.
[06:23] <zyga> back in the office now
[06:24] <zyga> aha, I see the chatter about wayland and suse
[06:24] <zyga> I _guess_ I'm running tumbleweed under X11, let me recheck
[06:26] <zyga> logged back under wayland
[06:27] <zyga> it fails on
[06:28] <zyga> (and now no copy-paste, fun)
[06:28] <zyga> on /run/user/1000/mutter/Xauthority
[06:28] <zyga> I recall seeing this in a PR recently
[06:28] <zyga> hold on
[06:31] <zyga> Mirv: confirmed, adding an extra rule for that makes it work
[06:31] <zyga> Mirv: is there a bug report? I'll handle the rest
[06:43]  * zyga needs to work on reviews today
[06:44] <zyga> good morning mvo
[06:44] <mvo> hey zyga
[06:44] <mvo> zyga: good morning! I also need to do reviews
[06:45] <mborzecki> mvo: hey
[06:46] <mvo> hey mborzecki
[06:48] <abeato> morning! question about the content interface, is it possible to share only a file, or it must be a full folder?
[06:48] <zyga> abeato: currently it must be a file but I have a patch to share single files stashed
[06:49] <zyga> er
[06:49] <zyga> must be a directory
[06:49] <abeato> :D
[06:49] <abeato> zyga, great, nice that we will have one file sharing soon, that will be useful if you want to share just a socker
[06:49] <abeato> shocket
[06:50] <zyga> sockets are more tricky
[06:50] <zyga> not sure it'd work for sockets
[06:50] <zyga> I have not tried
[06:51] <abeato> hm, right, well, but in the end it is a file, right? mount bind should work too?
[06:51] <zyga> ish,
[06:52] <zyga> sockets have a tricky apparmor side
[06:52] <zyga> anyway, it's a matter of checking
[06:52] <abeato> right
[06:59] <mup> PR snapd#7403 opened: cmd: use libtool for the internal library <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
[07:02] <pstolowski> morning
[07:02] <Mirv> zyga: there was not, I now filed bug #1842615
[07:02] <mup> Bug #1842615 opened: Wayland apps not starting under openSUSE Tumbleweed <Snappy:New> <https://launchpad.net/bugs/1842615>
[07:03] <mup> Bug #1842615: Wayland apps not starting under openSUSE Tumbleweed <Snappy:New> <https://launchpad.net/bugs/1842615>
[07:03] <mborzecki> pstolowski:  hey
[07:04] <Mirv> zyga: awesome :) meanwhile I checked the problem does not affect openSUSE Leap 15.0, so just Tumbleweed
[07:04] <mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/7387 ?
[07:04] <mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
[07:17] <zyga> Mirv: thank you
[07:17] <zyga> mborzecki: yeah but I'll start with older PRs first
[07:17] <zyga> or I'll starve them again :)
[07:19] <ackk> zyga, hi, so I just ran into that issue again, and it doesn't have to do with snapcraft rewriting the prime dir: https://paste.ubuntu.com/p/BVDHmmCn48/
[07:20] <zyga> ackk: that's interesting, can you mkdir /root/snap/maas/x1 yourself?
[07:20] <zyga> ackk: or will you get a EROFS error?
[07:20] <zyga> Mirv: I've updated the bug report and I'll be sending a PR to fix it later today
[07:20] <ackk> zyga, the dir already exists
[07:20] <zyga> ackk: is it a mount point?
[07:20] <zyga> ackk: can you write through it?
[07:21] <ackk> $ sudo ls -ld /root/snap/maas/x1
[07:21] <ackk> drwxr-xr-x 1 root root 12 Sep  4 06:59 /root/snap/maas/x1
[07:21] <mup> Bug #1842615 changed: Wayland apps not starting under openSUSE Tumbleweed <snapd:In Progress by zyga> <https://launchpad.net/bugs/1842615>
[07:21] <ackk> zyga, yeah I can write it as root
[07:21] <ackk> I mean, write a file in it
[07:21] <ackk> it's not a mountpoint
[07:21] <zyga> let me look again
[07:21] <zyga> that's odd
[07:22] <zyga> ackk: can you please try this:
[07:23] <zyga> sudo strace -o /tmp/strace.log SNAP_INSTANCE_NAME=maas
[07:23] <zyga> /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
[07:24] <zyga> not sure if free of typos
[07:24] <zyga> but give it a try
[07:24] <zyga> I'd like to see strace run of snap-confine
[07:24] <zyga> to see what was the error it failed on
[07:25] <ackk> zyga, that's all a single command right?
[07:25] <zyga> correct
[07:25] <ackk> strace: Can't stat 'SNAP_INSTANCE_NAME=maas': No such file or directory
[07:25] <ackk> that can't go there, it seems
[07:26] <ackk> I guess before the strace?
[07:26] <zyga> sorry, my bad
[07:26] <zyga> yes
[07:26] <zyga> :)
[07:26] <ackk> $ sudo SNAP_INSTANCE_NAME=maas strace -o /tmp/strace.log /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
[07:26] <ackk> strace: exec: Permission denied
[07:26] <Mirv> thank you zy_ga!
[07:27] <ackk> zyga, ^
[07:27] <zyga> ackk: _hmm_
[07:27] <zyga> did I get strace wrong somehow
[07:28] <zyga> ackk: and it didn't leave any log, did it?
[07:29] <ackk> zyga, just http://paste.ubuntu.com/p/5VW47nhgv9/
[07:29] <zyga> why would it do that?
[07:29] <zyga> is that under lxd?
[07:29] <zyga> perhaps thats why :/
[07:30] <zyga> can you check on your host, if you got a denial in dmesg?
[07:30] <Jonno_FTW> hello
[07:30] <zyga> ackk: one more idea
[07:31] <Jonno_FTW> I get this error: error: cannot add authorization: open /users/jonm/.snap/auth.json: permission denied
[07:31] <Jonno_FTW> when my $HOME is on NFS
[07:31] <zyga> ackk: can you install an older snapd and check if this happens?
[07:31] <zyga> Jonno_FTW: hey, can you tell us the command you ran?
[07:31] <zyga> Jonno_FTW: and snap version, please
[07:31] <ackk> zyga, like, stable?
[07:32] <zyga> yes
[07:32] <Jonno_FTW> sudo snap install redis-desktop-manager, snap version 2.39.2-1.fc30
[07:32] <mvo> ondra: hey, do you want to push your "lk-next" changes to "lk"? it seems you adrdress issues found in the review from chipaca?
[07:32] <zyga> aha, fedora
[07:32] <Jonno_FTW> yep
[07:32] <zyga> mborzecki: ^ can you render ideas on how to check denials for selinux + nfs?
[07:33] <ondra> mvo I will, once I test them :)
[07:33] <ondra> I'm just flashing test image
[07:33] <mborzecki> zyga: ackk: snap run --strace='--raw -o foo.log' maas if you can hit ^C in time
[07:33] <zyga> mborzecki: that likely wont help if lxd is in control on top and denies it already
[07:33] <zyga> mborzecki: I meant the case above from Jonno_FTW
[07:34] <mborzecki> Jonno_FTW: can you try ausearch -m AVC and look for anything with recent time stamp
[07:34] <ondra> mvo it is booting, so image prepare is working, I just want to run few core refresh tests
[07:34] <ondra> mvo I already tested snapd snap update and that worked as well
[07:35] <Jonno_FTW> mborzecki: there's nothing recent
[07:35] <Jonno_FTW> certainly nothing from around the time I started using snap (like 30m ago)
[07:37] <ackk> zyga, I can't switch to stable snapd as maas uses the system-usernames
[07:38] <zyga> ackk: well, just for a test, it doesn't really have to work all the way
[07:38] <zyga> just to see if this is something in 2.41
[07:38] <mborzecki> Jonno_FTW: for the record, the error when you do snap login right?
[07:38] <mborzecki> s/error when/error pops up when/
[07:38] <ackk> zyga, mborzecki https://paste.ubuntu.com/p/D7Ddt4rZ6X/
[07:39] <ackk> zyga, well it doesn't work at all as I get https://paste.ubuntu.com/p/rJ4pWKvQkC/ from snapd
[07:39] <zyga> what's /snap/snap/bin/maas/current?!
[07:39] <zyga> ackk: try without /snap/bin/maas, just maas
[07:39] <zyga> I think that's snap run getting confused
[07:39] <ackk> zyga, that's the first try there
[07:40] <zyga> right, I just mean that /snap/snap is clearly wrong
[07:41] <ackk> $ snap run --strace='--raw -o foo.log' maas upgrade
[07:41] <ackk> /usr/bin/strace: exec: Permission denied
[07:41] <ackk> error: exit status 1
[07:41] <zyga> ackk: on lxd host, can you run dmesg | grep DENIED
[07:41] <zyga> I'm sure it's lxd
[07:45] <ackk> zyga, https://paste.ubuntu.com/p/NPTRVQJtqQ/
[07:45] <zyga> ackk: that's excellent
[07:45] <zyga> so that is confirmed
[07:45] <zyga> ackk: to move forward we should figure out how to switch lxd's own profile on your host into permissive mode
[07:46] <zyga> then we can debug forther
[07:46] <zyga> *further
[07:46] <zyga> ackk: do you think we can postpone until lxd developers are online?
[07:46] <ackk> zyga, sure
[07:46] <ackk> zyga, I don't have a real xenial host to test with unfortunately
[07:47] <zyga> ackk: that's fine
[07:49] <ackk> zyga, also when I tried installing maas snap from edge I didn't hit the issue, so i'm not sure what triggers it. I can run "maas init" and maas works fine, then something gets messed up
[07:49] <ackk> but it might only happen in "try" mode, IDK
[07:49] <zyga> the code where it fails should fail regardless of try mode
[07:49] <zyga> I'd like to get to the bottom of this later today
[07:49] <ackk> zyga, btw is there any chance that the snapfuse issue (taking 100%cpu in containers) could get fixed? that makes it impossible to install maas in a container
[07:50] <ackk> (install from a snap and not from "try')
[07:50] <mborzecki> zyga: pff the libtool patch fails on this https://paste.ubuntu.com/p/mGVnXnF5j6/ :/
[07:50] <zyga> ackk: nobody on our team can fix that
[07:50] <ackk> zyga, is it a kernel or lxd thing?
[07:50] <zyga> ackk: please escalate that to get help
[07:50] <zyga> ackk: perhaps both
[07:50] <zyga> it's a fuse filesystem
[07:50] <zyga> maybe the bottleneck is kernel side
[07:51] <zyga> maybe userspace
[07:51] <ackk> zyga, you're saying it's a bug in squashfuse?
[07:51] <zyga> I don't think any of us really read that code
[07:51] <zyga> ackk: it's certainly not a bug in snapd, we just mount a filesystem
[07:51] <zyga> mborzecki: yeah I ran into that a number of times
[07:51] <zyga> mborzecki: load of garbage :/
[08:00] <mborzecki> duh, obviously there's no way to have misspell skip files :/
[08:01] <zyga> mborzecki: sed it
[08:18] <mup> PR snapd#7398 closed: boot, etc: simplify BootParticipant (etc) usage <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7398>
[08:19] <zyga> mvo: I think we should all review from oldest to youngest
[08:19] <zyga> it seems that the last two pages are like attic
[08:24] <zyga> brb, tea
[08:27] <mborzecki> zyga: added a workaround to #7403, other than that, all tests passed
[08:27] <mup> PR #7403: cmd: use libtool for the internal library <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
[08:30] <mvo> a review for 7125 would be great, small, self-contained and open since jul
[08:31] <mborzecki> mvo: looking
[08:45] <zyga> back with tea
[09:09] <mvo> Chipaca: good morning! if you could have a look at 7383 that would be great (should be simple, just a msg tweak)
[09:11]  * Chipaca looks
[09:11] <Chipaca> mvo: good morning! I've been working for the last hour but having to restart x a few times to sort out some things
[09:11] <Chipaca> fun with nvidia :-/
[09:11] <mvo> Chipaca: no worries
[09:11] <zyga> Chipaca: drivers?
[09:11] <mvo> Chipaca: and good luck with X, I kinda given up on nvidia for this reason :(
[09:11] <zyga> mvo: my ubuntu experience with 1030 was very good FWIW
[09:12] <zyga> mvo: not so much with 2080, LTS doesn't have the drivers for it yet,
[09:13] <mvo> zyga: to be fair my experience is ~1-2y old so I may be totally off
[09:14] <zyga> mvo: I think it depends on how recent the OS is, there have been some great strides lately
[09:14] <zyga> mvo: not sure if you remember this but a few weeks ago nvidia has opened a large number of specs for their hardware to aid nouveau
[09:14] <zyga> mvo: it looks like early days of amd shift, when the tactic was to open up, but it was still a long road towards benefits
[09:14] <Chipaca> mvo: zyga: i broke things by trying to update the drivers from a ppa, to get some games running … undoing it was less than fun
[09:15] <Chipaca> i'd forgotten how bad the quality of ppa debs was
[09:15] <zyga> Chipaca: does your system work with 19.10?
[09:15] <zyga> Chipaca: it's a good idea to just try that from a spare partition if it does
[09:15] <Chipaca> zyga: I'm still waiting for confirmation it works with 18.04 :-/
[09:15] <zyga> Chipaca: weekend evening project to check? :-)
[09:16] <Chipaca> nu uh
[09:16] <Chipaca> zyga: i've got way more fun weekend projects than updating a machine that works :-)
[09:16] <zyga> that's fair :-)
[09:16] <zyga> Chipaca: I played one game recently, control, strongly recommend it if you have the 3 evenings to finish it
[09:17] <zyga> anyway, back to reviews :)
[09:18] <mup> PR snapd#7396 closed: tests: don't guess in is_classic_confinement_supported <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7396>
[09:18] <mborzecki> zyga: w8, 3 evenings? is that how long the game is?
[09:19] <zyga> mborzecki: I think I played 6 hours each time
[09:19] <zyga> well into past 3AM :D
[09:19] <zyga> mborzecki: I just finished the main plot, there's more to do but that's enough for me
[09:20] <zyga> mborzecki: or I'm just pretty good at aiming
[09:20] <zyga> ;-)
[09:20] <mborzecki> hahaha
[09:20] <mborzecki> mad quake skillz? :)
[09:20] <zyga> mouse sensitivity set to maximum, field of view 120, those things ;)
[09:21] <zyga> just kidding though
[09:21] <zyga> the game is story driven
[09:21] <zyga> the combat is challenging but doesn't feel like grind
[09:21] <zyga> and unlike most shooters I can remember, it is very rewarding to use the very first revolver you get all the game
[09:21] <zyga> anyway
[09:22] <zyga> something for evening :)
[09:23] <mborzecki> zyga: fwiw, double barrel works in through all of doom too :P
[09:24] <zyga> mborzecki: indeed, but that's an exception, here the game gives you one gun, sharing ammo across all forms, and as you play you unlock more forms that are more suited for specific type of combat; what it doesn't do is to give you a much better gun that obsoletes the first one
[09:24] <Saviq> Chipaca: hey, you seem to know about snapshots, is it expected that `snap restore` does not restart the snap? is there something that can be done about that?
[09:25] <Chipaca> Saviq: yes, it's expected; stop all services / apps before restore, start them after
[09:27] <Saviq> kk
[09:27] <Chipaca> Saviq: that is, if you need to
[09:27] <Chipaca> Saviq: you don't always need to -- same as you don't always need to stop for a 'save'
[09:28] <Saviq> Chipaca: yeah, which is why  it feels like there should be hooks for this :)
[09:29] <Chipaca> Saviq: would a hook be able to know whether an app in the snap is running?
[09:29] <Chipaca> (in general the answer is 'no')
[09:30] <Saviq> Chipaca: an app, no, but a service, yeah
[09:30] <Chipaca> (zyga's work wrt deferring refreshes while apps are running might let us fix that)
[09:31] <Saviq> there's also https://forum.snapcraft.io/t/automatic-snapshot-opt-out/12131 - a `save` hook could reduce the size of the snapshot, but maybe it'd be better to have a whitelist for this particular usecase
[09:33] <mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/7387 ?
[09:33] <mup> PR #7387: packaging/fedora, tests/lib/prepare-restore: helper tool for packing sources for RPM <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7387>
[09:34] <pstolowski> mborzecki: sure
[09:34] <mborzecki> thanks!
[10:03] <zyga> jamesh: I finally reviewed https://github.com/snapcore/snapd/pull/6767#pullrequestreview-283483314
[10:03] <mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
[10:03] <jamesh> zyga: thanks.  Looking
[10:04] <zyga> jamesh: I think my only comment that would warrant blocking are related to validation
[10:04] <zyga> jamesh: on non-compliant files in meta/gui/icons
[10:04] <zyga> jamesh: as well as on file sizes in that place
[10:04] <zyga> jamesh: everything else is something that is good for followup
[10:05] <zyga> jamesh: I'm moving on to the next review, please ping me with your opinion
[10:05] <zyga> jamesh: as I said, you have +2 and you can merge as is
[10:05] <zyga> jamesh: but I'm worried about opening a hole
[10:05] <Chipaca> zyga: FWIW we already don't do that sort of validation on icons
[10:05] <Chipaca> zyga: so it's independent from that work
[10:05] <zyga> Chipaca: yes but now we read them into memory
[10:05] <zyga> Chipaca: in this PR
[10:05] <Chipaca> we do?
[10:05] <Chipaca> where?
[10:05] <zyga> ReadFile
[10:06] <Chipaca> why do we ReadFile them?
[10:06]  * Chipaca goes to look
[10:06] <pedronis> because Ensure* does that internally
[10:06] <pedronis> but I made a proposal in one of my comments
[10:06] <zyga> https://github.com/snapcore/snapd/pull/6767/files#diff-1a7d1cbe7825f23c89fbefcac29f347aR82
[10:06] <zyga> here
[10:06] <zyga> perhaps one way to solve this
[10:06] <mup> PR #6767: wrappers: allow snaps to install icon theme icons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6767>
[10:06] <zyga> is to extend ensure
[10:06] <zyga> to give it a handle that knows what the content is
[10:06] <zyga> and the size
[10:06] <zyga> so they can be stream like
[10:06] <ogra> oh ! gpio-control ? who breeded that ? (thats beautiful ! )
[10:07] <zyga> that's a good idea separately but I would not like to just let this silently merge without pointing it out
[10:07] <zyga> ogra: thank ondra
[10:07]  * ogra thanks ondra
[10:07] <zyga> I'll keep doing reviews to unblock people, I said my thing
[10:07] <ogra> ondra, beer for you in barcelona !
[10:11] <zyga> pedronis: should I review https://github.com/snapcore/snapd/pull/6705 ?
[10:11] <mup> PR #6705: bootloader: little kernel support <Needs Samuele review> <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>
[10:19] <pedronis> zyga: I'm looking at it right now, going a bit slowly
[10:19] <pedronis> also lunch
[10:19] <zyga> ok, I'll pick up the next one
[10:22] <zyga> mvo: hey, is https://github.com/snapcore/snapd/pull/6839 something that's ready for review?
[10:22] <mup> PR #6839: devicestate: allow remodel to different kernels  <Remodel :train:> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6839>
[10:24] <zyga> jamesh: this needs some comment feedback https://github.com/snapcore/snapd/pull/7073
[10:25] <mup> PR #7073: interfaces: OpenGL/Vulkan drivers provided by a base should be usable <⛔ Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7073>
[10:26] <jamesh> zyga: I think the way forward for that PR was to relax the AppArmor rules for snaps using a base other than core/core18
[10:26] <zyga> jamesh: indeed, can you please comment on it so that it's clear where we stand?
[10:26] <jamesh> on the assumption that non bootable bases should only contain files that are intended for use by apps
[10:27] <zyga> yeah, I recall the conversation about that in Toronto
[10:28] <mup> PR snapd#7404 opened: cmd/snap: don't append / to snap name just because a dir exists <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7404>
[10:29] <Chipaca> zyga: #7159 is an easy one
[10:30] <mup> PR #7159: tests: add functions to make an abstraction for the snaps <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7159>
[10:30] <zyga> looking quickly
[10:32] <pstolowski> pedronis: #7005 got 2 +1s and i adressed your earlier high-level feedback re having 'snap debug state..', would you like to take another look or can it land?
[10:33] <mup> PR #7005: debug: state-inspect debugging utility <Created by stolowski> <https://github.com/snapcore/snapd/pull/7005>
[10:50] <pedronis> pstolowski: it might be easier to land it and I play with it a bit once is in edge
[10:50] <pstolowski> pedronis: ok, ty
[11:04] <pstolowski> pedronis: i'm thinking of adding some kind of high-level simplified potential-conflict-checking command for it in the future, something rudimentary that doesn't try to replicate existing logic (because that could simply hide an existing problem), but rather list candidates for closer inspection. not sure if/how this will work in practice and how valuable it will be, but sometimes just filtering out irrelevant data
[11:04] <pstolowski> from the state and setting initial focus is helpful
[11:06] <zyga> jamesh: hey, question about https://github.com/snapcore/snapd/pull/7129#pullrequestreview-283531582
[11:06] <mup> PR #7129: userd: allow setting default-url-scheme-handler <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
[11:06] <zyga> I know it's not your PR but do you know why we need to add a "get set sub-property API"?
[11:06] <mvo> hm, tests are very red, shall we disable 19.10 for now?
[11:06] <zyga> mvo: what is failing if I may ask?
[11:07] <mvo> zyga: let me look again but pretty much everything is red
[11:07] <zyga> like all tests are failing?
[11:08] <zyga> I mean, there must be something that actually fails :)
[11:09] <mvo> zyga: the samples I looked at this morning were 19.10 but let me re-look to see if this is actually still happening
[11:09] <zyga> do you remember if a specific test was at fault?
[11:10] <mvo> zyga: iirc desktop-portal but let me look again
[11:10] <zyga> that fails uniformly though
[11:10] <zyga> it fails on me every day, or close
[11:10]  * mvo nods
[11:10] <zyga> I'd be happier if we can disable the test instead
[11:11] <zyga> and look at it really hard until we really understand why
[11:11] <mvo> https://travis-ci.org/snapcore/snapd/pull_requests <- looks sad
[11:16] <pstolowski> degville: hey! i'm looking for the best place to add documentation for snap unset and snapctl unset (and equivalents with 'set' subcommands followed by exclamation mark). seems like they need to go to https://forum.snapcraft.io/t/configuration-in-snaps/510 and https://forum.snapcraft.io/t/supported-snap-hooks/3795 ; do you know any better spot?
[11:19] <mup> PR snapd#7405 opened: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7405>
[11:23] <jwheare> zyga: re: 7129 my changes are almost entirely just repurposed existing code and style. i don't write go usually so feel free to make any stylistic changes you want
[11:24] <jwheare> the reason i added GetSub was because i couldn't see a way in go to have multiple function heads with different numbers of arguments
[11:24] <jwheare> (unlike say erlang)
[11:25] <jwheare> without eliminating types and then doing dynamic type checks
[11:28] <zyga> jwheare: hey, thank you for explaining that.
[11:29] <zyga> I will look at this with new information after lunch
[11:34] <degville> pstolowski: hello - thanks for looking! I think you're absolutely right about those locations - especially Configuration in snaps. We can always shuffle things around if the words fit somewhere better, but I think they're the best place for now.
[11:35] <pstolowski> degville: great, ty! ok if if i just edit it there (new paragraphs/subsections) and you take a look afterwards?
[11:35] <degville> pstolowski: yep - sounds good!
[11:36] <pstolowski> ok
[11:36] <ondra> ogra always ready for beer :P
[11:38] <ondra> mvo sorry I was at dentist, back now and doing more testing
[11:38] <ondra> mvo so far looks good
[11:38] <ondra> mvo I will push changes from lk-next to PR branch
[11:38] <mvo> ondra: sounds great, thank you
[11:39] <ondra> mvo one more question, there is essential c header file, which should be implemented by corresponding bootloader, I was wondering where to host that header file
[11:40] <ondra> mvo one option is to have it in bootloader/lkenv/snappy-boot.h
[11:40] <Chipaca> hmm, is it always the same two 19.10 tests that are failing?
[11:40] <ondra> mvo do you have any better idea where to host it?
[11:42] <ondra> mvo OK there is problem with seeding with my test snap
[11:43] <ondra> mvo I will debug, but it could be kernel seeding, when it tries to install bootimg
[11:44] <Chipaca> a pox on google:ubuntu-19.10-64:tests/main/interfaces-timeserver-control
[11:55] <ondra> mvo interesting is that it seems to panic when applying core18 security profiles though
[11:57] <ondra> mvo I will need to create image with cloud init to log in though, first boot crash is a bit pain to debug as there is no good way to log in. So I will try update path now
[11:58] <ondra> mvo ignore me, i think it's kernel seeding, it just happens right after core
[12:23] <pstolowski> degville: i updated the snap get/set document, but the one about hooks & snapctl needs some more work i think, it's a little bare when it comes to snapctl
[12:25] <degville> pstolowski: thank you! I'll take a look at set/get.
[12:39] <mup> PR snapd#7406 opened: cmd/snap-confine: keep track of snap instance name and the snap name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7406>
[12:39] <zyga> thanks!
[12:42] <mborzecki> + '[' no = yes ']'
[12:42] <zyga> test failed
[12:42] <zyga> that's that ;)
[12:42] <zyga> what printed that?
[12:43] <mborzecki> zyga: google:ubuntu-19.10-64:tests/main/interfaces-timeserver-control
[12:43] <zyga> our favourite test
[12:44] <ijohnson> mborzecki: I saw the same thing on one of Chipaca's PR's last night
[12:44] <ijohnson> I think it's a bug with eoan
[12:44] <mborzecki> mhm, mvo has a PR disabling it
[12:44] <mborzecki> for 19.10 at least
[12:44] <ijohnson> mborzecki: also thanks for the review, I responded
[12:45] <mborzecki> ijohnson: many dragons in snapstate handlers :) remember when i first dug into that
[12:46] <ijohnson> yeah indeed!
[12:46] <ijohnson> and yeah also not really sure about the `saveSnapDisabledServices` name either, it feels awkward, but I also need to do the same thing multiple places so I wanted to eliminate code duplication
[12:46] <pedronis> mvo: ondra: commented on the lk PR
[12:47] <ondra> pedronis thank you :)
[12:47] <ondra> mvo found issue, we do not determeng run time mode correctly on device
[12:47] <ondra> determine
[12:48] <mup> PR snapd#7405 closed: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7405>
[12:53]  * ijohnson will miss SU again today, need to go with someone taking the citizenship oath :-)
[12:56] <mvo> pedronis: thank you!
[12:57] <zyga> mvo: https://github.com/snapcore/snapd/pull/7405/files#r320742967 ;-)
[12:57] <mup> PR #7405: tests: disable interfaces-timeserver-control on 19.10 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7405>
[12:58] <zyga> geee I wish I made coffee before the call
[13:12] <zyga> jwheare: so, a quick question on Get/Set DBus API
[13:12] <zyga> jwheare: can the "setting" attribute  be like a obj.attr?
[13:13] <zyga> that would allow us to have one get and handle everything with it
[13:13] <zyga> jwheare: or perhaps / as I see the code already uses it
[13:15] <mup> PR snapcraft#2698 opened: dirs: check for existence of required data directories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2698>
[13:20] <ondra> pedronis I asked already mvo, but since you commented on it. I'd like to add c header file into lkenv dir for reference, otherwise I'm struggling to think about better place for it
[13:22] <jwheare> zyga: i tried not to change existing apis
[13:22] <mup> PR snapd#7403 closed: cmd: use libtool for the internal library <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/7403>
[13:30] <Chipaca> degville, pedronis: https://twitter.com/jonworth/status/1169185705823735809
[13:33] <jwheare> zyga: the / is used mainly just for logging strings tbh
[13:33] <zyga> jwheare: I'm getting familiar with this area
[13:33] <degville> Chipaca: ugh, thanks... if I squint, it looks like the sphinx. Riddle? Relic of lost civilisation?
[13:33] <zyga> my idea was to drop the Sub methods
[13:33] <zyga> and just allow more to be expressed by the property being interacted with
[13:37] <mvo> zyga: re timeserver-control test - fun: https://paste.ubuntu.com/p/skNwxPPGGn/ - it looks like a version mismatch of the tools with the systemd version running
[13:38] <jwheare> if you'd rather the api just be e.g. Check("default-url-scheme-handler/irc", "ircclient.desktop") or Check("default-web-browser", "browser.desktop") that's your call
[13:38] <pedronis> mvo: fun not
[13:38] <mvo> pedronis: yeah, so the timdatectl from the snap is 229 and does not (apparently) understand what 241 tells it
[13:39] <pedronis> big mess actually, we'll need to think
[13:39] <jwheare> i felt the more explicit separation of property/subproperty was a cleaner api, less magic, but i don't know the project
[13:39] <Chipaca> degville: right click, view image, zoom in -- or look for the post where jon links to the svg :)
[13:40] <jwheare> personally, i don't see more functions as a bad thing, in general
[13:40] <pstolowski> Chipaca: yay, that's very helpful, ty ;)
[13:41] <jwheare> but i have no strong feelings. if you think encoding the subproperty within the property string makes sense go for it :)
[13:45] <sergiusens> pedronis: mvo sorry for insisting, but I wanted confirmation that the snapd snap builds fine with snapcraft from edge to fix  anything before another half complete release (I will start the release process with your green light)
[13:47] <mvo> pstolowski: do you think you could double check if snapcraft from edge is fine with the snapd snap type?
[13:47] <mvo> pstolowski: see the question from sergiusens
[13:49] <sergiusens> ah, right, I did build pstolowski branch, if that is all you need, then we should be good to go (but ssome form of sanity test that could be run would be ideal)
[13:50] <pstolowski> mvo, sergiusens i will
[13:51] <pstolowski> mvo, sergiusens is it critical to check all build methods (lxd, multipass, destructive)?
[13:54] <sergiusens> pstolowski: in general no, unless you use hardcoded paths (I fixed on in a PR last week)... if you do try either multipass (or lxd) and --destructive-mode
[13:56] <zyga> mvo: because of change in formatting?
[13:56] <zyga> I think I saw that
[13:58] <mvo> zyga: yeah, I'm looking at it now
[13:58] <mvo> zyga: hopefully not too hard to fix
[14:00] <pstolowski> sergiusens: ok, thanks, i'm going to check this in a moment (with my branch)
[14:11] <zyga> re
[14:15] <zyga> mvo: any findings?
[14:17] <mvo> zyga: in a meeting, but I see  [  503.301852] audit: type=1400 audit(1567605570.552:74): apparmor="DENIED" operation="capable" profile="snap.test-snapd-timedate-control-consumer.timedatectl-timeserver" pid=31856 comm="timedatectl.rea" capability=12  capname="net_admin"
[14:17] <zyga> missing permissions, it seems
[14:19] <mvo> zyga: yeah, I look some more after the meeting
[14:19] <zyga> thank you
[14:23] <cachio> mborzecki, Chipaca hey, could you please take a look to #7401
[14:23] <mup> PR #7401: tests: add unstable stage for travis execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
[14:23] <Chipaca> cachio: yep
[14:23] <cachio> zyga, hey, yesterday I saw you were taking a look to a problem related to the snapd snap right?
[14:24] <Chipaca> cachio: nice
[14:24] <cachio> zyga, it is the only concern I have before promoting this to candidate
[14:25] <zyga> cachio: which specific problem, sorry - there were too many topics lately
[14:26] <cachio> zyga, the one related to maas
[14:26] <zyga> ah
[14:26] <zyga> sorry, yes
[14:26] <zyga> it's not a regression IMO
[14:26] <cachio> zyga, the issue which you were discussing with ackk
[14:26] <zyga> and it's specific to specific development flow
[14:26] <zyga> I'd not block on it
[14:26] <zyga> it's a UX issue, not a behavior change
[14:26] <cachio> zyga, perfect, thanks for the info
[14:28] <zyga> ackk: ^ FYI
[14:29] <mup> PR snapd#7401 closed: tests: add unstable stage for travis execution <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7401>
[14:31] <mup> PR snapcraft#2699 opened: python plugin: add option to process-pipfile-lock for pipenv users <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2699>
[14:33] <mup> PR snapd#7407 opened: tests: run failing tests on ubuntu eoan due to is now set as unestable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7407>
[14:42] <jwheare> zyga: do i interpret your latest comment to mean you're happy with Get and GetSub etc being separate?
[14:42] <zyga> yes, that's right
[14:42] <jwheare> cool
[14:42] <zyga> I'm reviewing technical details now
[14:42] <zyga> it's close I think
[14:53] <mup> PR snapd#7397 closed: tests: add --quiet switch to retry-tool <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7397>
[14:55] <ackk> zyga, so you know what's causing that issue?
[14:56] <zyga> ackk: no, but if you are around we can work on exploring more
[14:56] <zyga> ackk: we need to switch the host's lxd profile to permissive mode
[14:56] <zyga> ackk: and try strace again
[14:56] <cachio> jamesh, hey, could you please take a look to the comment I left in #7351
[14:56] <ackk> zyga, how do I do (and then revert) that?
[14:56] <mup> PR #7351: tests: retry checking until the written file on desktop-portal-filechooser <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7351>
[14:56] <zyga> ackk: I think you can do that in-memory
[14:56] <zyga> using ...
[14:57] <pstolowski> sergiusens: snapd from my PR built fine with multipass (i took a gooooood while to download all deps). i'm going to check destructive now
[14:57] <zyga> ackk: there's aa-complain
[14:57] <zyga> ackk: but really we want to find the profile on disk
[14:57] <sergiusens> pstolowski: if what it built works,, then we are solid for moving forward :-)
[14:57] <zyga> stgraber: where does lxd keep its apparmor profiles on disk?
[14:57] <zyga> ackk: we need to edit one profile and add one word to make it advisory, not enforced
[14:58] <ackk> zyga, how do I find it? I'm not very familiar with aa
[14:58] <pstolowski> sergiusens: yeah i don't expect problem with destructive since that's already coverted by spread test in my PR.. but i can check manually for piece of mind
[14:58] <zyga> ackk: unfortunately the kernel does not know so we just need to look around, hold on
[14:59] <stgraber> zyga: /var/snap/lxd/common/lxd/security/apparmor/
[14:59] <zyga> stgraber: thank you so much!
[14:59] <zyga> ackk: let's look at that path please
[14:59] <zyga> ackk: we want to change the profile that was denied
[14:59] <zyga> stgraber: perhaps there's an easier way to allow strace inside a container?
[15:00] <zyga> ackk: can you please remind me the DENIED line that you found then?
[15:00] <stgraber> zyga: strace is allowed inside containers
[15:00] <ackk> zyga, https://paste.ubuntu.com/p/NPTRVQJtqQ/
[15:00] <zyga> stgraber: we had a ptrace deny, perhaps it's more complex and two things together make it fail
[15:00] <ackk> stgraber, ^
[15:00] <ackk> stgraber, also, hi :)
[15:00] <zyga> peer="unconfined"
[15:01] <zyga> ackk: when you ran snap-confine manually,that was inside the container, right?
[15:01] <zyga> ackk: along with sudo and strace
[15:01] <zyga> all inside?
[15:01] <ackk> yes
[15:01] <zyga> ok
[15:02] <zyga> do I read that right, that snap-confine itself is denying the trace?
[15:04] <zyga> ackk: can you show me how to get to this stage? I can explore this locally somewhat faster perhaps
[15:04] <ackk> zyga, well I'm not sure if you can get to that stage easily with the snap from the store
[15:05] <stgraber> so we do have a ptrace restriction which prevents cross-profile ptracing to avoid cross-container security issues, I wonder if this is somehow triggering there
[15:05] <zyga> ackk: I'm happy to get some fresh stuff from git and play
[15:05] <zyga> stgraber: perhaps, I can just disable everything quickly locally to get to the bottom of the error that is masked behind this
[15:06] <stgraber> ackk: "lxc config set NAME raw.apparmor ptrace," should allow everything
[15:06] <ackk> zyga, so. you'd have to git clone lp:maas; build the snap and snap try it
[15:06] <ackk> stgraber, I assume I need to reboot?
[15:06] <ackk> (the container)
[15:06] <stgraber> yeah
[15:07]  * ackk tries
[15:07] <ackk> thanks
[15:07] <zyga> ackk: cloning
[15:09] <zyga> ackk: so having maas cloned
[15:09] <zyga> snapcraft?
[15:09] <ackk> zyga, of course, after rebooting the container the issue went away :/
[15:09] <zyga> ackk: oh?
[15:09] <zyga> that's interesting
[15:09] <ackk> zyga, yeah, I use --destructive-mode in the container
[15:09] <zyga> can you rebuild maas
[15:09] <zyga> and see if that breaks it again
[15:09] <ackk> sure
[15:09] <zyga> and then, re-run the sudo snap-confine strace line
[15:10]  * Chipaca needs caffeine
[15:10]  * Chipaca looks for something intravenous
[15:13] <mvo> xnox: did timedatectl change in 19.10? when I run "timedatectl  set-ntp no" (or yes) the "timedatectl status" output does not change regardless of yes/no
[15:22] <mvo> xnox: this is GCE so maybe this is relevant
[15:30] <mvo> xnox: aha! so it looks like we have chronyc on GCE
[15:30] <zyga> ooo
[15:30] <zyga> mvo: so ntp is always on?
[15:31] <zyga> ackk: any luck?
[15:32] <mvo> zyga: sort of, yes
[15:32] <mvo> zyga: anyway, I think I know what to do
[15:32] <ackk> zyga, no, I rebuilt and installed the snap (via snap try), but it seems to work so far
[15:32] <ackk> zyga, will try the strace if it happens again
[15:33] <zyga> ackk: thank you
[15:33] <ackk> zyga, still, that snap-confine line fails with permission denied
[15:34] <ackk> although "sudo maas" currently works
[15:34] <zyga> ackk: not with permission denied
[15:34] <zyga> it's confusing
[15:34] <ackk> $ sudo SNAP_INSTANCE_NAME=maas strace -o /tmp/strace.log /snap/snapd/4605/usr/lib/snapd/snap-confine snap.maas.maas /bin/true
[15:34] <zyga> if you look at the source
[15:34] <ackk> strace: exec: Permission denied
[15:34] <zyga> it has failed already
[15:34] <zyga> ah, sorry
[15:34] <zyga> that line does fail on strace and lxd
[15:35] <Chipaca> hmm, i'm seeing repeated failures for google:ubuntu-{16,18}.04-64:tests/main/proxy-no-core
[15:35] <zyga> that's strace being unable to execute snap-confine
[15:35] <ackk> $ snap run --strace='--raw -o foo.log' maas upgrade
[15:35] <ackk> /usr/bin/strace: exec: Permission denied
[15:35] <ackk> error: exit status 1
[15:35] <ackk> zyga, ^ this one too
[15:35] <zyga> yes, it's the same thing really
[15:35] <xnox> mvo:  that.
[15:35] <zyga> (snap run call strace)
[15:35] <xnox> mvo:  they asked and we changed default to chrony
[15:35] <xnox> mvo:  on gce
[15:35] <ackk> zyga, ok
[15:35] <JonelethIrenicus> can i change the default folder for snap configuration files?
[15:35] <zyga> what does chrony do?
[15:36] <zyga> JonelethIrenicus: which files?
[15:36] <zyga> but most likely no, it's not very easy to do
[15:36] <JonelethIrenicus> in ubuntu 19.04 it has a snap folder in the home directory
[15:36] <JonelethIrenicus> it isn't a dot file
[15:36] <zyga> there's a bug report for that
[15:36] <JonelethIrenicus> ahh ok
[15:36] <zyga> it's extremely hard to change
[15:36] <zyga> I'm sorry
[15:37] <JonelethIrenicus> all good
[15:37] <JonelethIrenicus> just was curious why it was in my home directory like that
[15:38] <zyga> JonelethIrenicus: this is bug https://bugs.launchpad.net/snapd/?orderby=-heat&start=0
[15:38] <zyga> and I do intend to fix it
[15:38] <zyga> b
[15:38] <zyga> but to fix it properly I need to build enough infra to be able to move it first
[15:38] <JonelethIrenicus> awesome thanks
[15:38] <zyga> without breaking people
[15:38] <zyga> so it's a bit slow
[15:38] <JonelethIrenicus> right
[15:39] <mvo> xnox: thanks, I will fix our test then
[15:39] <zyga> I'm burned out with reviews today
[15:39] <zyga> I'll switch to coding
[15:40]  * Chipaca hugs zyga
[15:40] <zyga> thanks Chipaca
[15:40] <zyga> writing is easier than reading
[15:40] <zyga> you know what you meant up front :)
[15:42] <ondra> pedronis are you OK for me to resolve comments which I already addressed? like change of error messages? Or are you gonna resolve those yourself?
[15:42] <pedronis> ondra: I can do it
[15:43] <pedronis> Chipaca: mborzecki: I proposed something in #7402 inspired by maciej ideas
[15:43] <ondra> pedronis thanks, just want to clean it a bit, so I can see which comments still need work
[15:43] <mup> PR #7402: daemon, client, cmd/snap: include architecture in 'snap version' <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7402>
[15:44] <Chipaca> pedronis: we could think of (someday) adding cloud info there also
[15:48] <Chipaca> not sure if there's a uniform way of finding out what cloud you're on (maybe via cloud-init or sth)
[15:49] <ondra> mborzecki do you have good example of gadget yaml to update to update assets
[15:49] <ondra> mborzecki forum post seems to be missing good example
[15:50] <mup> PR snapd#7408 opened: tests: fix interfaces-timeserver-control on 19.10 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7408>
[15:53] <pedronis> ondra: done
[15:53] <pedronis> Chipaca: we do get that info
[15:53] <tomwardill> hi! I'm trying to install snaps inside a xenial lxd, but getting "system does not fully support snapd: apparmor detected but insufficient permissions to use it". Is there a fix?
[15:53] <ondra> pedronis thanks
[15:53] <pedronis> Chipaca: it's a bit too much info tough, people might want not to tell us
[15:54] <ondra> pedronis what do you think about option to add header file to snapd repo?
[15:55] <ondra> pedronis or what is best place to have that reference header file?
[15:59] <zyga> ondra: would that header file ship with snapd binary
[15:59] <zyga> ondra: or just in the source repo
[15:59] <ondra> zyga just in source
[15:59] <ondra> zyga it is reference which should be used by bootloader
[15:59] <zyga> I see
[15:59] <Chipaca> pedronis: fair
[15:59] <Chipaca> i'm off to the gym, will bbl
[15:59] <ondra> zyga so data structure used by snapd and bootloader is in sync
[16:00] <zyga> ondra: put it in a manual page
[16:00] <zyga> ondra: on the forum :)
[16:00] <ondra> zyga I want it somewhere from where it's easy wget
[16:00] <zyga> ondra: why?
[16:00] <pstolowski> sergiusens, mvo: both multipass and destructive-mode builds worked with type:snapd + build-base:core 👌
[16:00] <zyga> would you expect people to wget it constantly?
[16:00] <zyga> because it changes all the time
[16:01] <ondra> zyga as this is also needed at gadget build time, when device pre-populated env should be generated
[16:01] <zyga> ondra: no, it's not
[16:01] <zyga> ondra: what is needed is the structure or other type it defines
[16:01] <zyga> ondra: hence my question
[16:01] <zyga> ondra: is it expected to change often?
[16:01] <zyga> ondra: what happens when it changes
[16:01] <ondra> zyga no it does not change, but file is used by around, and I want it to be in sync
[16:01] <zyga> ondra: keeping it in easy-wgettable place doesn't seem to solve any issues
[16:01] <zyga> ondra: you cannot have both :)
[16:02] <zyga> ondra: I think that's more important than where it is
[16:02] <zyga> ondra: what happens when, eventually, it must change
[16:02] <ondra> zyga if it changes, it will likely be new file, as it will have new version
[16:02] <zyga> ondra: then you don't need to wget it
[16:02] <zyga> it's fine to document as if it was a manual page
[16:02] <zyga> because it's fixed forever in stone
[16:02] <zyga> just make sure to name it, v1
[16:02] <ondra> zyga so new version will be new file, this file is essentially set in stone once snapd adopts it
[16:03] <ondra> zyga that's why I want single place to get it from
[16:03] <zyga> I think that's the essential information
[16:03] <zyga> thank you
[16:03] <ondra> zyga OK where can I have it, so I can wget it?
[16:03] <zyga> ondra: anywhere, because it's a constant now
[16:04] <zyga> ondra: just make sure not to accidentally make go build it
[16:04] <ondra> zyga so can I add it to snapd repo? :P
[16:04] <zyga> ondra: go is tricky for that
[16:04] <zyga> ondra: include/ perhaps (we don't have it yet)
[16:04] <ondra> zyga if I only add it there, how do I make sure it's not go build?
[16:04] <zyga> ondra: don't add any go files there
[16:04] <ondra> zyga I though to have it right next to go version, so bootloader/lkenv/
[16:05] <zyga> that's not godo
[16:05] <zyga> *good
[16:05] <zyga> it might get pulled for cgo build
[16:05] <ondra> zyga hmm
[16:05] <ondra> zyga so creating include directory?
[16:08] <zyga> ondra: yeah, it seems like that to me
[16:08] <ondra> zyga OK I will add it there
[16:08] <ondra> zyga goog idea
[16:09] <zyga> not a guarantee it will pass
[16:09] <zyga> but let's see
[16:09] <ijohnson> you could be tricky and add it to testdata
[16:09] <zyga> I hope my comments were not snarky in reception
[16:09] <zyga> I really did mean to point the light on the key issue of evolution
[16:10] <zyga> because that's the hard part of this problem
[16:10] <ijohnson> go ignores files in testdata, but it's not really test data so _shrugs_
[16:10] <zyga> sharing an agreed structure is easy
[16:11] <zyga> I'm near EOD
[16:12] <zyga> looking at apparmor bits
[16:14] <zyga> spread is spreading
[16:16]  * ijohnson lunches
[16:43] <mup> PR snapd#7409 opened: Allow a confined Wayland server running in a user session to work with Qt, GTK3 & SDL2 clients <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7409>
[16:45] <diddledan> so you can now run the gimp snap in Windows: https://usercontent.irccloud-cdn.com/file/SXwtQQGd/image.png
[16:58] <zyga> diddledan: is it stable? I had issues with the x server
[16:58] <diddledan> I'm using the x server in mobaxterm
[17:00] <mvo> thanks pstolowski|afk
[17:10] <ondra> Chipaca please re-review my changes, I believe I have address those I commented on
[17:51] <Saviq> sergiusens: is this error expected on a Pi? https://forum.snapcraft.io/t/building-for-core18-multipass-issue/8958/35
[18:19] <Chipaca> ondra: will do (not right now tho)
[18:19] <ondra> Chipaca thanks :)
[18:21] <sergiusens> Saviq: I think ijohnson got the gist of it. This is why the meeting this Friday is important :-)
[18:21] <sergiusens> Saviq: I am leaning to having that same image that is produced for multipass to be used for lxd on all architectures
[18:21]  * ijohnson hopes the meeting on friday ends in snapcraft being able to make me a sandwich
[18:23] <ogra> Saviq, sergiusens, these images from friendlyarm are an awful hackish mess (and legal should really go after them for claiming this crap is based on UbuntuCore ... ) it is some self-debootstrapped rootfs with configs manually hacked up etc and somce home-brewed BSP kernel binary
[18:24] <Chipaca> ijohnson: it can already make you a sandwich! the yaml is tricky though
[18:24] <sergiusens> ogra: ah, interesting, but I will not go into any legal topic on a public forum :-)
[18:24] <ogra> i wouldnt judge that an "error is expected on a pi" just because it fails on these hacked up vendor images
[18:24] <ijohnson> I bet it uses those silly yaml anchors
[18:25] <ogra> sergiusens, yeah, i shouldnt either it is just the third person on the forum in a month that has issues due to this "based on core" claim ... starts to really annoy me :)
[18:30] <Chipaca> ijohnson: b̥̦̪̞ͅa̞̙̫ͅs̜e̫̬̱̠͈̬̬:̡̣̦ ̙͚̤͓̜̦̫{̷̟̥̱̺ ̝̣͉̦̞̥<҉̙̣̣̰<̪̟̪̘͡:̖̖̼ ͈̘̥̮*̛͈̜̙ͅs͎̺a̦n̙͔̫͓͡d̯w̧̪͖͍͈i̝͈̗̬̣c̷̤͔̻h̹̟͚ ͕̘̗̜̕}̷̳
[18:31] <Chipaca> or something like that
[18:31]  * Chipaca is preparing dinner and might've gotten the zalgo wrong
[18:32] <ijohnson> perfect
[19:17] <zyga> jdstrand: hey, around?
[19:17] <zyga> jdstrand: https://bugs.launchpad.net/snapd/+bug/1842615 came up today, the fix is one liner policy change
[19:17] <mup> Bug #1842615: Wayland apps not starting under openSUSE Tumbleweed <snapd:In Progress by zyga> <https://launchpad.net/bugs/1842615>
[19:17] <zyga> owner /run/user/*/mutter/Xauthority r,
[19:18] <zyga> I was meaning to add it but wanted to run it by you for a quick look
[19:19] <mup> PR snapcraft#2700 opened: schema: build-base support for the kernel type <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2700>
[20:21] <mup> PR snapd#7410 opened: tests: support fastly-global.cdn.snapcraft.io url on proxy-no-core test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7410>
[20:23] <cachio> zyga, if you are there could tu please take a look to #7410
[20:23] <mup> PR #7410: tests: support fastly-global.cdn.snapcraft.io url on proxy-no-core test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7410>
[20:23] <cachio> it is blocking all the tests on travis
[20:24] <zyga> done
[20:24] <cachio> zyga, thanks!!!
[21:52] <mup> PR snapcraft#2687 closed: colcon plugin: add ability to ignore packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2687>
[21:52] <mup> PR snapcraft#2694 closed: multipass: fix setup exception when multipass is not found in PATH  <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2694>
[21:55] <mup> PR snapcraft#2698 closed: dirs: check for existence of required data directories <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2698>
[22:05]  * Chipaca hugs cachio


 I would have chosen a different beat... or maybe a different snare sound
[03:54] <FloatingGoat> thats what holstien said sorta
[03:54] <len-dt> The drums sound "busy", but I think if the snare was another drum like a bongo or bodran 9not sure of the spelling.
[03:54] <len-dt> What the celts use anyway.
[03:54] <FloatingGoat> what does busy mean
[03:55] <FloatingGoat> too fast for everything else?
[03:55] <len-dt> Like there are too many beats to a bar. But I am thinking it is because of the drum sound
[03:55] <len-dt> It isn't fast, it is in time.
[03:56] <FloatingGoat> if there where too less beats for the bar
[03:56] <FloatingGoat> is it called lazy or something
[03:56] <len-dt> The name is just what ever they call it. It helps you to remember it for next time :)
[03:57] <len-dt> The only beats that normally have names are latin beats
[03:57] <len-dt> My drumming is pretty rusty, but that is where I started.... 40 years ago.
[03:58] <FloatingGoat> my drumming is nonexistant
[03:58] <FloatingGoat> lol percussion is where i think i have the most trouble in my songs
[03:58] <len-dt> I haven't had a set since the early 80s now.
[03:59] <FloatingGoat> its the same beat the whole way through and usually consists of only a kick and a snare
[03:59] <len-dt> Ja, I think a rounder sound would be good. something with a bit more ring.
[04:00] <len-dt> The snare is a very short, sharp staccato, sound.
[04:01] <len-dt> Probably what they call a jazz snare.
[04:02] <len-dt> The average drummer would call it a piccolo snare, I think. Its been a long time and things have changed a bit.
[04:02] <FloatingGoat> dragon ball z fans?
[04:03] <len-dt> The other possibility would be to use a brushed sound.
[04:06] <FloatingGoat> insted of the snare?
[04:08] <len-dt> Ya
[04:14] <FloatingGoat> len-dt: want to hear one of my older ones before I started collabing with female bandmate girl
[04:17] <len-dt> ok
[04:19] <FloatingGoat> http://ubuntuone.com/09HdB6UmRLnpGzyl4rQ5re
[04:21] <FloatingGoat> len-dt: im trying to find my other one
[04:26] <len-dt> Vocals could be louder on that
[04:27] <FloatingGoat> yeah idk that ones down the drain in that deparment as far as I know
[04:27] <FloatingGoat> I dont know hwere the source file is so
[04:27] <FloatingGoat> heres another one though http://ubuntuone.com/5onDvCtuOS4Gtf9nTi5CxS
[04:27] <len-dt> What Soft ware did you use for that
[04:28] <FloatingGoat> which one?
[04:28] <len-dt> your early ones
[04:28] <FloatingGoat> both?
[04:28] <FloatingGoat> I use LMMS stock for the the last one i linked
[04:29] <FloatingGoat> used*
[04:29] <FloatingGoat> and I used LMMS with a proprietary VST enabled, on windows for the one up there
[04:30] <len-dt> I would go lighter on the piano... The lower octave should not be chords it sounds a bit muddy
[04:30] <FloatingGoat> good pount
[04:31] <FloatingGoat> point
[04:31] <len-dt> I have to put kids to bed for a bit...
[04:31] <FloatingGoat> okay
[04:31] <FloatingGoat> later alegator
[09:38] <jeff86> hello
[09:38] <jeff86> need some help please
[09:42] <jeff86> hardware context : ATI RADEON 7000 VE, CMEDIA AUDIO AC97, LOGITECH COMMUNICATE STX, SIS748CHIPSET (Int. LAN), WIFI TPLINK300Mbps, 1024 MoDDR400, ATHLON XP2200+, HD80GoIDE. Distro : UBSTUDIO 12.0.4 LTS
[09:43] <ailo> jeff86: What kind of problem are you having?
[09:44] <ailo> I'll be back later, but just ask a question, and me or someone else will answer when they see it and have time
[09:45] <jeff86> ailo: installation process is ok, but a few moments after loggedin, starting to work, doing synaptic, or Firefox, or any applications, PC is frozen, hard reboot necessary, so can't work... i think perhaps the graphic card, i saw perhaps a problem with the driver, so i will test but if you have other ideas... thanks in advance
[09:51] <jeff86> running under french, but i don't think my problems come from that.... but perhaps an allergy :)
[09:51] <jeff86> lol
[09:52] <jeff86> nobody?
[09:54] <jeff86> i was hoping... too bad, i'll try to find a solution. thank you.
[11:25] <FloatingGoat> how do I use unity with ubuntu studio
[11:26] <FloatingGoat> figured it out
[11:30] <smartboyhw> FloatingGoat, Good:D
[12:16] <FloatingGoat_> I caved and installed ubuntu-desktop
[12:47] <FloatingGoat> idk unity seems to fit me better
[23:45] <FloatingGoat> hey
[23:46] <franck_> bonsoir
[23:47] <franck_> hi
[23:48] <FloatingGoat> whats up?
[23:52] <franck_> first time using ubuntustudio, look great
[23:59] <franck_> and first little issue that i don't know fixed


[06:16] <pitti> Good morning
[07:01] <didrocks> good morning
[07:57] <seb128> good morning desktopers!
[07:58] <happyaron> morning seb128
[07:58] <seb128> hey happyaron, how are you?
[07:58] <happyaron> great, :)
[07:59] <didrocks> hey seb128, happyaron
[08:00] <seb128> lut didrocks :-)
[08:01] <happyaron> didrocks hey, :)
[08:03]  * didrocks now waits for ubuntu-make to build everywhere before blogging
[08:09] <pitti> bonjour seb128 et didrocks
[08:09] <pitti> hey happyaron
[08:09] <didrocks> morning pitti
[08:10] <seb128> hey pitti, wie gehts?
[08:15] <pitti> seb128: gut, danke!
[08:15] <pitti> played basketball again after 4 weeks last night; it was great
[08:15] <seb128> nice
[08:16] <seb128> I played tennis yesterday, was great as well ;-)
[08:17] <pitti> seb128: oh, dehors ? Il fait très froid ..
[08:18] <seb128> pitti, oui, dehors, il fait froid mais il n'y avait pas de vent et quand tu bouges ça va
[08:19] <happyaron> hey pitti, :)
[08:19] <pitti> vrai ; j'ai joué un peu lundi; seul, ... just to practice my throws
[08:19] <pitti> (outside in the park, too)
[08:23] <TheMuso> Hey willcooke.
[08:23] <TheMuso> And hello to everyone else. :)
[08:24] <willcooke> hey TheMuso
[08:24] <seb128> hey TheMuso willcooke
[08:24] <willcooke> TheMuso, just getting ready for school, be with you in 5 mins
[08:24] <TheMuso> willcooke: No worries.
[08:27] <didrocks> hey TheMuso, willcooke
[08:28] <mlankhorst> morning
[08:29] <willcooke> morning seb128 didrocks mlankhorst
[08:29] <willcooke> TheMuso, 2 more mins...
[08:30] <TheMuso> willcooke: No problem.
[09:03] <Guest54456> hey hey
[09:04] <Guest54456> GOD
[09:04] <Guest54456> WHY
[09:04] <Guest54456> might keep this nickname all day in protest
[09:04] <seb128> hey Laney
[09:04] <seb128> lol
[09:04] <seb128> what happened there?
[09:04] <Guest54456> must have been disconnected overnight
[09:05] <Guest54456> ah
[09:05] <Guest54456> 22/01 09:05:17 -NickServ(NickServ@services.)- You are already logged in as Laney.
[09:05] <Guest54456> I accidentally quit irssi, must have been changed before I logged back in
[09:05] <Laney> so, hello!
[09:07] <willcooke> QUOTE:
[09:07] <willcooke> Blackberry CEO John Chen thinks that companies should be forced to develop apps for his platform (TechCrunch). He accused Netflix, amongst others, of discriminating against Blackberry and called on lawmakers in the US to enforce "application neutrality".
[09:07] <mlankhorst> hahahahah
[09:07] <mlankhorst> I'm surprised a certain other os that's also not succesfull whines about it yet :P
[09:08] <Laney> Canonical developer Maarten Lankhorst was quoted as saying "What a great idea"
[09:08] <didrocks> hey Laney, mlankhorst
[09:09] <Laney> hey didrocks, how are you?
[09:09] <didrocks> Laney: headache and starting to catch a cold, so not at my maximum mind velocity TBH :p (which isn't great already)
[09:09] <didrocks> and you?
[09:09] <Laney> oh gosh, get some rest!
[09:10] <Laney> I'm alright yeah
[09:10] <didrocks> Laney: yeah, I plan to do mind-free tasks now that the intellij breakage is under control :)
[09:10] <didrocks> like patch piloting, a little bit of man pages writings…
[09:12] <Laney> some nice looking LCA summaries on LWN this week. ;)
[09:12]  * didrocks does LWN catchup on Friday
[09:24] <seb128> didrocks, Laney, can you sanity check http://paste.ubuntu.com/9816735/ for me?
[09:26]  * didrocks looks
[09:26] <seb128> "not configure"*
[09:27] <seb128> (removing the second "to")
[09:27] <seb128> in the comment
[09:27] <seb128> hum, or not?
[09:28] <didrocks> seb128: sounds good to me, idemnpotent and you source the needed resources IMHO
[09:29] <didrocks> seb128: have you tried it already?
[09:29] <seb128> didrocks, no, downloading the current daily atm
[09:29] <didrocks> (of course, think about chmod +x ;))
[09:29] <Laney> I don't understand the point of the prereq function
[09:30] <seb128> Laney, I'm not sure, but all the other scripts in that dir have that snippet so I just copied/based on that
[09:30] <seb128> oh, it fact they don't all have it
[09:30] <seb128> but most do
[09:36] <Laney> looks okay to me otherwise
[09:36] <Laney> I guess it's some facility to have scripts be able to have pre requisites
[09:37] <Laney> but in this case it does nothing since PREREQS is empty
[09:37] <Laney> might be better to have it be there for future use
[09:37] <seb128> k, I keep it
[09:37] <seb128> didrocks, Laney, thanks
[09:37] <didrocks> yw!
[09:37] <seb128> Laney, english question, the second "to" should be there or not? /me is unsure
[09:38] <seb128> "# Users want to try unity8, not to configure their system"
[09:38] <willcooke> correct
[09:38] <seb128> thanks
[09:40] <Laney> I think it works both ways
[09:40] <Laney> so what evs
[09:51] <seb128> nice to update the phone and see the daily improvements
[09:52] <seb128> with today updates the camera app has options to choose the image quality now, and to display a grid
[10:20] <willcooke> hey Saviq
[10:21] <willcooke> Saviq, you know how you and I are best buddies, and how I always tell people what a great guy you are?
[10:21] <willcooke> well, now it's time for *you* to do *me* a favour.
[10:22] <willcooke> Does this need your blessing?  https://code.launchpad.net/~gerboland/qtmir/fix-GTK-rendering/+merge/246201
[11:59] <mlankhorst> willcooke: for xmir you don't need anything right now?
[12:10] <willcooke> mlankhorst, I think we're good thanks
[12:27] <Laney> didrocks: want to try the ido in silo 028 to see if it fixes indicator-sound for you?
[12:28] <didrocks> Laney: sure, will do (in ~30 minutes, need some rest due to headache aggravating)
[12:34] <Laney> :(
[12:34] <Laney> feel better :(
[13:08] <mlankhorst> meh, my patch to make glamor work broke other stuff
[13:14] <willcooke> folks, who can help me with this:
[13:14] <willcooke> https://bugs.launchpad.net/oem-priority/+bug/1382291
[14:25] <Sweet5hark> Laney: thanks for that drive-by no-change rebuild of libreoffice for poppler!
[14:31] <Laney> np
[14:42] <Sweet5hark> mterry: ... and thanks for the MIR reviews.
[14:42] <Sweet5hark> seb128: around?
[14:42] <seb128> Sweet5hark, yes
[14:43] <mterry> Sweet5hark, :)
[14:44] <mterry> Sweet5hark, those were relatively easy oones
[14:44] <Sweet5hark> seb128: so, I merged from debian, tested/tweaked the autopkgtests, added the MIR deps and am currently upload for a armhf test
[14:44] <Sweet5hark> mterry: because of standard autotools foo for a plain lib?
[14:45] <mterry> Sweet5hark, modern packaging and didn't have to worry about code itself because it was in main already
[14:46] <Sweet5hark> seb128: if that arm build succeeds, I like to land that in vivid (as rc2), so as not to have a mir and mayor upstream release and FOSDEM and $stuff all at the same time.
[14:47] <Sweet5hark> mterry: I will try to make things as easy as possible in the future too ;)
[14:48] <Sweet5hark> seb128: currently there are only some ~25 additional commits upstream on top of rc2, so we should be okish to release a rc ...
[14:48] <didrocks> Laney: ido fix works well in my guest session
[14:50] <larsu> \o/
[14:51] <didrocks> nice work ;)
[14:56] <seb128> Sweet5hark, sounds good, let me know when it's ready and I can upload for you
[14:59] <Sweet5hark> seb128: k, will do.
[15:23] <mlankhorst> bleh glamor's stupid
[15:24] <mlankhorst> red and blue are inverted in metacity with Xmir, nothing I can do about it right now. I need to understand what's going on more first..
[15:24] <seb128> mlankhorst, hey, do you have documentation on xmir/what it is exactly/how it works technically? for those who want to understand it better :-)
[15:25] <seb128> mlankhorst, also is that something separate from other components, or do we need patches to xorg or mir to get it to run?
[15:25] <mlankhorst> seb128: it's a dumb wrapper for glamor with some support for dri2 that's currently broken
[15:25] <mlankhorst> it's a separate standalone xserver in the xorg-server source
[15:26] <mlankhorst> but the egl acceleration needs some patching to work on es2, it mostly assumes es3
[15:26] <Laney> didrocks: thanks (was larsu who did it), releasing
[15:27] <mlankhorst> seb128: no patches to mir are needed, but input and cursors don't work right because mir doesn't support enough yet..
[15:27] <seb128> k
[15:27] <mlankhorst> rotation works, is there anything you want to know specifically?
[15:35] <didrocks> larsu: https://code.launchpad.net/~larsu/gtk/images-in-menubars/+merge/246307 seems that its merged upstream, right?
[15:40] <larsu> didrocks: yes, I pushed it
[15:41] <larsu> only to master though
[15:41] <didrocks> larsu: do you think it worthes that we merge as a distro-patch to the gtk branch?
[15:41] <didrocks> or should we wait for next release?
[15:42] <larsu> didrocks: I think we should (thus I made the MR) - somebody from xfce asked for it
[15:42] <didrocks> larsu: ok
[15:42] <didrocks> Laney: do you have anything else in the pipe for gtk? (meaning: do I just stack the fix for a later upload?)
[15:43] <Laney> no, please upload, but scan the queue to make sure there's nothing else if you don't mind
[15:43] <didrocks> Laney: sure, just doing that
[15:43] <larsu> didrocks: thanks!
[15:44] <didrocks> thanks to you :)
[15:44] <larsu> Laney: btw, I found that gedit encoding combo box issue
[15:45] <larsu> Laney: also found out that it's fixed in 3-12 :/
[15:46] <Laney> heh
[15:47] <willcooke> mlankhorst, seb128 - we should write a wiki page.  I'll put it on my list of things to do
[15:47] <seb128> willcooke, thanks
[15:47]  * didrocks does a sanity build
[15:47] <Laney> let's work on getting to 3.14 then
[15:48] <larsu> that's what I'm doing right now
[15:48] <larsu> just letting you know ;)
[15:48] <Laney> sure, thanks for the heads up!
[15:49]  * Laney digs out the touch laptop to look at GtkGesture stuff
[15:51] <desrt> Laney: enjoying the netbsd stickers? :)
[15:56] <Laney> they make me feel like a fraud :p
[15:58] <mlankhorst> willcooke: where?
[15:59] <willcooke> mlankhorst, for the wiki page?  Dunno, I'll chuck it up on the Ubuntu wiki somewhere
[15:59] <mlankhorst> should probably be part of the u8 stuff
[16:03] <Sweet5hark> seb128: hmmm, what happened with the libcmis-0.5.0 sync from experimental? cant find it in main/-proposed or the vivid-queue?
[16:05] <seb128> Sweet5hark, sorry, I guess I forgot, doing that now
[16:07] <Sweet5hark> seb128: np, thanks!
[16:09] <willcooke> mlankhorst, good call
[16:16] <mlankhorst> Xmir *can* run as replacement for the standalone Xserver, but it's not nearly feature complete to be an enjoyable experience :P
[16:22] <didrocks> Laney: some gtk tests are known to be racy, right? (just confirming as I'm getting some tests randomly failing in my sbuild)
[16:22]  * didrocks hasn't uploaded gtk for a long time in distro
[16:23] <Laney> erm
[16:23] <Laney> they are quite reliable for me
[16:23] <Laney> and on the builders too
[16:23] <Laney> push it and I'll try
[16:23] <didrocks> Laney: done
[16:24] <Laney> ty
[16:24] <didrocks> thanks for trying :)
[16:24] <Cimi> kenvandine, I tested like 200k times and it always switch to continue :)
[16:24] <Cimi> both mako and krillin
[16:24] <Cimi> I will try again...
[16:24] <kenvandine> Cimi, sorry... didn't for me ... i tried twice
[16:25] <kenvandine> it was checked when it connected
[16:25] <kenvandine> but still said skip
[16:25] <Cimi> kenvandine, did you wait like 2-3 sec?
[16:25] <Cimi> kenvandine, the check turns green but it is not connected yet
[16:25] <kenvandine> yeah... much longer
[16:26] <Cimi> ah ok
[16:26] <kenvandine> i waited a good 30s
[16:26] <Cimi> here turns continue after 2 sec
[16:26] <Cimi> kenvandine, do you have a sim card in?
[16:26] <kenvandine> Cimi, oh.. and ifconfig confirmed it had an IP
[16:26] <kenvandine> no sim
[16:26] <Cimi> same condition
[16:26] <Cimi> weird
[16:26] <Cimi> have no idea then
[16:26] <kenvandine> so i know it connected and had an IP
[16:26] <Cimi> will try rtm on mako
[16:26] <kenvandine> thx
[16:27] <kenvandine> sorry... i was hopeful :)
[16:27] <Cimi> I tried rtm only on krillin
[16:31] <kenvandine> i can't imagine that would matter...
[16:31] <kenvandine> unless it's qml-module-qtsysteminfo
[16:31] <kenvandine> i guess that could be blowing up on mako
[16:34] <Laney> didrocks: (lt-gtk-reftest:3195): Gtk-WARNING **: Invalid icon size 0
[16:34] <Laney> /build/gtk+3.0-78JpNx/gtk+3.0-3.14.7/testsuite/reftests/gtk-icontheme-sizing.ui: FAIL
[16:34] <Laney> That sounds like it's a legit failure from this change
[16:35] <Laney> orrrrrr ...
[16:37] <didrocks> yeah, seem that the change can impact it, larsu? ^
[16:38] <Laney> no wait
[16:38] <didrocks> hum?
[16:38]  * didrocks is too head-broken to have a clear thinking, will probably go off soon…
[16:42] <larsu> Laney: are you sure? The patch was in GtkImageMenuItem, which isn't in that reftest at all
[16:42] <Laney> I said "no wait"
[16:42]  * larsu waits
[16:43] <larsu> maybe we're still missing pan-down-symbolic?
[16:54] <Laney> didrocks: try that
[16:56] <willcooke> didrocks, get well
[16:58] <didrocks> willcooke: thanks
[16:58] <GunnarHj> pitti: ping?
[16:59] <didrocks> Laney: ah, makes sense
[16:59] <didrocks> Laney: I'll go to get some rest now, either upload it or I will do it tomorrow morning
[17:01]  * didrocks waves good evening and good night
[17:06] <Cimi> kenvandine, mako rtm doesn't work with it
[17:06] <Cimi> kenvandine, I will try debugging
[17:06] <Cimi> kenvandine, can you try krillin too with rtm to see if works for you?
[17:06] <Cimi> kenvandine, could be a qt bug in the rtm version
[17:07] <kenvandine> Cimi, my krillin is vivid atm, i'd rather not switch it right now
[17:07] <kenvandine> it's my daily driver :)
[17:07] <Cimi> kenvandine, ok, you can try vivid too
[17:08] <kenvandine> then it would be in unity8
[17:08] <kenvandine> let me find someone else to test it
[17:08] <Cimi> kenvandine, when CI will finish to build https://code.launchpad.net/~cimi/unity8/fix-1363400/+merge/247129
[17:09] <Cimi> kenvandine, anyway mako rtm is a confirmed failure for me
[17:09] <Cimi> kenvandine, vivid rtm mako was fine
[17:09] <Cimi> vivid mako
[17:10] <Cimi> I will try again rtm tomorrow
[17:24] <Laney> GtkGestures seem to work well
[17:24]  * Laney gets out the BFG
[18:44]  * willcooke EOD
[19:02] <Sweet5hark> seb128: thx for libcmis! ;)
[19:14] <seb128> Sweet5hark, yw!
[19:17] <Sweet5hark> libreoffice build now running on amd64,ppc,i386,armhf -- thus calling it EOD
[19:20] <seb128> Sweet5hark, have fun!