[07:22] <hurricanehrndz> anyone know how to enable IPForward using netplan and networkd as the renderer
[08:05] <oSoMoN> good morning desktoppers
[08:37] <jibel> salut oSoMoN
[08:38] <oSoMoN> salut jibel, ça va?
[08:41] <jibel> oSoMoN, ça va bien, et toi?
[08:47] <oSoMoN> on fait aller :)
[08:47] <seb128> good morning desktopers
[08:47] <seb128> lut oSoMoN
[08:47] <jibel> salut seb128
[08:48] <seb128> lut jibel
[08:54] <willcooke> morning all
[08:55] <seb128> hey willcooke, how are you today?
[08:56] <willcooke> hey seb128.  Long story ;)
[08:57] <oSoMoN> hey willcooke, seb128
[09:02] <Laney> morning!
[09:05] <willcooke> hi Laney
[09:08] <Laney> hey willcooke
[09:09] <oSoMoN> hey Laney
[09:18] <seb128> hey Laney, how are you?
[09:27] <Laney> hey oSoMoN, hey seb128!
[09:28] <Laney> seb128: good, getting back into it!
[09:28] <Laney> being spammed on lots of gnome irc channels
[09:28] <Laney> good week / good day off?
[09:29] <seb128> not a week, just a longer w.e :) and yes, spent some days in France that was nice and relaxing
[09:29] <seb128> what about you, good week off?
[09:31] <Laney> yeah, lots of pub / walk / hanging out
[09:31] <Laney> opened email 0 times which was fun yesterday ;-)
[09:31] <Laney> cold though
[09:33] <seb128> :)
[09:33] <seb128> snow?
[09:34] <seb128> we had a bit over the w.e, that was nice
[09:35] <Laney> little bit on the hilltops
[09:35] <Laney> but not much :(
[09:35] <Laney> it was icy on some days though and the place is very hilly
[09:35] <Laney> so sliding around
[09:35] <Laney> funscary
[11:06] <ricotz> jbicha, hi, I am going to pick up your proposed firefox packaging changes for the next trunk build, and forward-port from there
[11:29] <oSoMoN> kenvandine, you had a machine with nvidia hw, iirc?
[11:36] <popey> oSoMoN: he does. but he uses nouveau AIUI
[11:38] <oSoMoN> right, I remember now
[11:38] <oSoMoN> kenvandine, any chance you can switch temporarily to the proprietary driver to help me debug the chromium snap issue?
[11:38]  * Laney is using nvidia
[11:39] <Laney> but if you need any actual snap help I might not be the best person :-)
[11:40] <oSoMoN> Laney, you’re using the proprietary drivers?
[11:41] <Laney> yeah
[11:41] <Laney> don't tell rms
[11:43] <oSoMoN> Laney, I won't, if you can confirm that the chromium snap doesn't work ;)
[11:44] <Laney> oSoMoN: stable?
[11:45] <oSoMoN> yes, stable
[11:46] <oSoMoN> as a bonus if you can try beta and edge that'd be nice, but I expect the result will be identical
[11:47] <Laney> yeah it's just a black window
[11:48] <Laney> and apparmor isn't happy
[11:48] <oSoMoN> ok, that's consistent with what popey and others are seeing
[11:48] <oSoMoN> Laney, what are the denials?
[11:49] <Laney> https://paste.ubuntu.com/26118048/
[11:52] <oSoMoN> Laney, any seccomp denial?
[11:53] <Laney> https://paste.ubuntu.com/26118073/ saw those on beta/edge
[11:53] <Laney> all black too
[11:54] <Laney> hmm, seccomp, where's that?
[11:56] <oSoMoN> on my machine I get them in /var/log/audit/audit.log
[11:56] <ogra_> they should be in syslog/journal
[11:56]  * Laney doesn't have that
[11:56] <Laney> what does it look like?
[11:57] <Laney> I mean I have entries from audit in journal but they look the same as those denials to me
[11:57] <Laney> just with AVC at the start
[11:58] <oSoMoN> that syscall=133 entry is mknod, looks like the same issue that mvo looked into
[11:59] <oSoMoN> Laney, would you mind stracing it to confirm the node it fails to create? see https://forum.snapcraft.io/t/stracing-snap-commands/1433
[12:02] <Laney> oSoMoN: yeah, the only mknod it shows is for /dev/nvidiactl
[12:05] <mvo> oSoMoN: I still see this syscall=133 issue, iirc when we talked last you looked into the chromium source to see if its needed, we should have that in the core snap but I guess chromium is building its own sandbox or something(?)
[12:07] <oSoMoN> yeah, I *think* the relevant code is here: https://cs.chromium.org/chromium/src/content/gpu/gpu_sandbox_hook_linux.cc?sq=package:chromium&l=195
[12:09] <mvo> oSoMoN: did you talk to jdstrand about the mknod issue on nvidia with chromium yet? maybe we can just add it
[12:11] <oSoMoN> mvo, I did a while ago, but I don't remember the outcome of the conversation
[12:13] <mvo> oSoMoN: thanks, I wonder if we could simply allow mknod in the confinement with argument filtering on nvidiactl
[12:14] <mvo> oSoMoN: but something for jdstrand to decide :)
[12:15] <oSoMoN> yeah
[12:15] <jdstrand> I don't recall otoh what you are referring to
[12:16] <oSoMoN> jdstrand, see https://forum.snapcraft.io/t/call-for-testing-chromium-62-0-3202-62/2569/42
[12:16] <jdstrand> (but we can't arg filter in the manner described because we can't arg filter on the path)
[12:16] <oSoMoN> the chromium snap fails to render when run on nvidia hardware with the proprietary drivers
[12:17] <oSoMoN> and this appears to be down to something chromium tries to do with /dev/nvidiactl
[12:21] <jdstrand> oSoMoN: this seems related to chromium's own seccomp sandbox
[12:22] <jdstrand> I mean, based on the incompleete strace
[12:23] <jdstrand> there is something very wrong there. it successfully stats, later gets ENOENT from seccomp, it tries to stat, gets eperm, then tries to mknod
[12:23] <jdstrand> I mean, none of that seems like it should go together
[12:24] <jdstrand> why would you stat a file that you got ENOENT on? why would you mknod a file you got EPERM on?
[12:25] <oSoMoN> yeah, that doesn't look right
[12:26] <jdstrand> the seccomp denial is for open. we allow that so that should be chromium's seccomp sandbox
[12:26] <oSoMoN> in fact I think the relevant code is https://cs.chromium.org/chromium/src/gpu/ipc/service/gpu_init.cc?type=cs&q=nvidiactl&sq=package:chromium&l=83
[12:26] <jdstrand> I suspect there may be an interaction between chromium's namespace setup and the per-snap mount namespace
[12:28]  * oSoMoN is lost in (sandbox) translation
[12:28] <jdstrand> I don't have nvidia hardware
[12:29] <jdstrand> I wonder if you passed --no-sandbox (is that the right option) to chromium if it would make it work
[12:29] <jdstrand> that might give a clue if it is sandbox interactions
[12:30] <popey> yes, if you pass --no-sandbox, you get a window
[12:31] <popey> https://usercontent.irccloud-cdn.com/file/Zs63UnQq/chromium_snap_on_nvidia_with_no_sandbox
[12:35] <jdstrand> oSoMoN: that may be a clue ^
[12:36] <oSoMoN> ah, that's a good clue indeed
[12:36] <oSoMoN> popey, do you get hw-accelerated rendering? see the output of chrome://gpu
[12:37] <popey> https://usercontent.irccloud-cdn.com/file/3lhImbzG/I%20think%20so
[12:37] <popey> https://usercontent.irccloud-cdn.com/file/HDGGxDgW/unsnapped%20chrome%20on%20same%20machine
[12:38] <popey> so not quite the same, no
[12:39] <jdstrand> oSoMoN: CanAccessNvidiaDeviceFile() should return true with just apparmor (access() isn't mediated by apparmor). if the chromium sandbox sets up a mount namespace, its possible it isn't accounting for snap-confine's mount namespace
[12:43] <jdstrand> oSoMoN: also the fact that it is trying to mknod should indicate that this is happening in the privileged code since the process would need CAP_MKNOD to have any chance of success with that call
[12:45] <jdstrand> the forum post is a bit light on details. I don't see any reference to logged denial (or lack thereof)
[12:46] <jdstrand> oSoMoN: it might also be interesting to add 'capability mknod,' to the chromium apparmor profile and running without --no-sandbox. capability denials are rate limited and may not always show up
[12:47] <oSoMoN> jdstrand, see https://forum.snapcraft.io/t/call-for-testing-chromium-62-0-3202-62/2569/25
[12:48] <jdstrand> oSoMoN: that's with an old snapd though. the udev_enumerate error should be fixed
[12:49] <jdstrand> oSoMoN: what was happening there is that nvidiactl wasn't udev tagged since nvidia is a proprietary driver and not allowed to use sysfs
[12:49] <jdstrand> oSoMoN: because eit wasn't udev tagged, it wasn't added to the per-snap device cgroup
[12:51] <oSoMoN> ok
[12:53] <jdstrand> oSoMoN: you could try this: add 'capability mknod,' to the apparmor profile, then add 'mknod' to /var/lib/snapd/seccomp/bpf/snap.chromium...src, then do 'sudo /snap/core/current/usr/lib/snapd/snap-seccomp compile /var/lib/snapd/seccomp/bpf/snap.chromium....src /var/lib/snapd/seccomp/bpf/snap.chromium....bin
[12:53] <jdstrand> (also reload the apparmor profile)
[12:54] <oSoMoN> jdstrand, I don't have nvidia hw myself, Laney/popey can you try that?
[12:54] <jdstrand> oSoMoN: if that works, then do an strace of the working version
[12:55] <jdstrand> to reload the apparmor profile, do 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.chromium.chromium
[12:55] <jdstrand> so those ...src and ...bin files would by snap.chromium.chromium.src and snap.chromium.chromium.bin, respectively
[12:55] <jdstrand> be*
[12:56] <jdstrand> and the strace should use https://forum.snapcraft.io/t/stracing-snap-commands/1433
[12:57] <popey> oSoMoN: ok
[12:58] <popey> jbicha: stuck at first step - "add 'capability mknod,' to the apparmor profile... wat?
[12:59] <popey> sorry jbicha , i meant jdstrand :)
[12:59] <jdstrand> popey: add 'capability mknod,' to /var/lib/snapd/apparmor/profiles/snap.chromium.chromium, then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.chromium.chromium
[12:59] <jdstrand> '
[13:00] <jdstrand> popey: you have r3604 of the core snap?
[13:00] <jdstrand> (ie, 16-2.29.4.2)
[13:00] <popey> yes
[13:00] <jdstrand> k
[13:02] <jdstrand> popey: after you load the apparmor profile, then modify /var/lib/snapd/seccomp/bpf/snap.chromium.chromium to have mknod. then do: sudo /snap/core/current/usr/lib/snapd/snap-seccomp compile /var/lib/snapd/seccomp/bpf/snap.chromium.chromium.src /var/lib/snapd/seccomp/bpf/snap.chromium.chromium.bin
[13:02] <popey> done that
[13:02] <popey> now need to reload apparmor profile..?
[13:03] <jdstrand> popey: then do: sudo strace -u <your username> -e '!select,pselect6,_newselect,clock_gettime' -f -D -vv -o ./chromium.trace /snap/bin/chromium
[13:03] <jdstrand> popey: yes, see above
[13:03] <popey> ok
[13:03] <popey> all done, now to trace
[13:04] <popey> ok, chromium launched
[13:04] <popey> and giant trace file made
[13:04] <jdstrand> popey: did it not launch before?
[13:05] <popey> previously it launched but blank window
[13:05] <popey> it only launched successfully with --no-sandbox
[13:05] <jdstrand> popey: and you launched without using --no-sandbox?
[13:05] <popey> on this trace session, yes
[13:05] <jdstrand> ok, can you make that trace available somewhere?
[13:05] <popey> on it
[13:06] <popey> jdstrand: http://people.canonical.com/~alan/chromium.trace.gz
[13:06] <jdstrand> popey: also, can you paste the output of cat /sys/fs/cgroup/devices/snap.chromium.chromium/devices.list?
[13:07] <popey> jdstrand: http://paste.ubuntu.com/26118453/
[13:08] <jdstrand> popey: when ready, can you undo your apparmor and seccomp changes (reloading the apparmor profile and recompiling the seccomp profile) and run the strace again, reporting if it broke again?
[13:08] <popey> is removing / reinstalling the snap sufficient to undo that?
[13:09] <jdstrand> yes
[13:09] <jdstrand> and then again after a reboot
[13:10] <jdstrand> (to make sure the cgroup is cleared)
[13:10] <popey> ugh
[13:10] <popey> I _really_ don't want to reboot
[13:10] <jdstrand> the reboot is less important at this moment
[13:11] <jdstrand> popey: I need to run an errand, but will checkc back
[13:12] <popey> jdstrand: http://people.canonical.com/~alan/chromium.trace2.gz
[13:12] <popey> kk
[13:13] <jdstrand> popey: did the second trace fail again?
[13:13] <popey> yes
[13:14] <jdstrand> popey: let me rephrase. after reinstalling, did it fail in the same way as before you made the apparmor/seccomp changes?
[13:14] <popey> yes
[13:14] <popey> blank window
[13:14] <jdstrand> ok
[13:14] <popey> first trace is what I would call a "successful" launch of chromium - a browser window appeared. Second trace is what I'd call a "fail" - an empty window containing a grab of what was under the window when launched
[13:16] <jdstrand> I think the first stat is snap-confine
[13:21] <jdstrand> so the successful trace.gz shows it is trying to mknod /dev/nvidiactl for no good reason, it is getting EPERM, ignoring it and moving on and trying to open() it
[13:21] <jdstrand> this doesn't seemed to be coded correctly
[13:22] <jdstrand> oSoMoN: ^ (feel free to look at trace.gz (the successful run with apparmor/seccomp changes) and trace2.gz (the unsuccessful one without)
[13:22] <jdstrand> )
[13:22] <oSoMoN> jdstrand, popey : ack, thanks
[13:22] <oSoMoN> going for a quick lunch and I'll take a close look
[13:23] <jdstrand> oSoMoN: if you could figure out where it is mknod()ing that, comment it out, I suspect it would work. an upstream patch for the needless mknod() would obviously do more than that
[13:24] <jdstrand> oSoMoN: soon, with tyhicks' seccomp won't kill PR, this would also go away
[13:24] <jdstrand> oSoMoN: (I suspect)
[13:24] <jdstrand> ok, I really need to go
[13:24] <jdstrand> bbl
[13:31] <popey> oSoMoN: jdstrand looks like this is where they do it? https://cs.chromium.org/chromium/src/content/gpu/gpu_sandbox_hook_linux.cc?q=kNvidiaCtlPath&l=195
[13:31] <jdstrand> oSoMoN: actually, you technically wouldn't need to send up an upstream patch. you distro patch to remove the mknod until tyhicks PR lands, then can remove. granted, upstream is wrong and burning syscalls
[13:31] <jdstrand> ok, really leaving
[14:09] <jbicha> ricotz: thanks! 😀
[14:30] <seb128> ok, it's meeting time
[14:31] <seb128> #startmeeting Desktop Team Weekly Meeting - 2017-12-05
[14:31] <meetingology> Meeting started Tue Dec  5 14:31:15 2017 UTC.  The chair is seb128. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:31] <meetingology> Available commands: action commands idea info link nick
[14:31] <oSoMoN> o/
[14:31] <andyrock> o/
[14:31] <seb128> Roll call: andyrock, dgadomski, didrocks (out), duflu (out), jbicha, jamesh (out), jibel/heber, kenvandine, laney, oSoMoN, seb128, tkamppeter, trevinho, robert_ancell (out)
[14:31] <jibel> hi
[14:31] <jbicha> o/
[14:32] <seb128> ok, let's get started
[14:32] <seb128> #topic andyrock
[14:32] <kenvandine> o/
[14:32] <seb128> andyrock, hey
[14:33] <seb128> hum, he just waved 3 minutes ago?
[14:33] <andyrock> 1. Updated merge request for udisks2 after review (this is required to hide snap squashfs in gnome-disks)
[14:33] <andyrock> 2. Opened bug https://bugs.launchpad.net/xenial-backports/+bug/1735160 to backport python3-macaroonbakery in xenial
[14:33] <andyrock> 3. Proposed debdiff for protobuf 2.6.1 to build python3 deb too
[14:33] <andyrock> 4. Proposed debdiff for https://bugs.launchpad.net/ubuntu/+source/google-apputils-python/+bug/1735162
[14:33] <andyrock> 5. Proposed debdiff to backport python3-macaroonbakery in xenial with some workarounds (like using proto2 instead of proto3)
[14:33] <andyrock> 6. Built a ppa to test the backport https://launchpad.net/~azzar1/+archive/ubuntu/bug-1735160
[14:33] <andyrock> 7. eow
[14:33] <andyrock> sorry I didn't get the ping
[14:33] <andyrock> :D
[14:33] <seb128> no worry
[14:33] <seb128> thanks andyrock
[14:33] <seb128> #topic dgadomski
[14:34] <seb128> dgadomski, hey
[14:34] <dgadomski> hey
[14:34] <dgadomski> * refreshing debdiffs for bug #1699179
[14:34] <dgadomski> * testing -proposed fix for bug #1638695
[14:34] <dgadomski> eof
[14:34] <seb128> thanks dgadomski
[14:34] <seb128> #topic jbicha
[14:34] <seb128> jbicha, hey
[14:34] <jbicha> • A fresh Ubuntu 18.04 install now only installs 3 gtk2 rdepends: Firefox, Thunderbird and libgtk2-perl (for debconf). (Some input methods still require gtk2 or Qt). LP: #1585903
[14:34] <jbicha> • Filed MIR for mod-dnssd (needed for gnome-user-share) LP: #1731065
[14:35] <jbicha> • Demoted mono and cvs to universe
[14:35] <jbicha> • Cherry-picked gtk3 commit to enable the Insert Emoji right-click menu item in places like gedit
[14:35] <jbicha> • spice-vdagent MIR was approved but someone needs to package a security fix before it can be promoted to main LP: #1200296
[14:35] <jbicha> I'll probably drop the usb seed after this meeting since there hasn't been any objections so far
[14:36] <jbicha> eof
[14:36] <Laney> yeah, good idea
[14:36] <seb128> sounds good indeed
[14:36] <seb128> thanks jbicha
[14:36] <seb128> #topic jamesh
[14:36] <seb128> snapcraft-desktop-helpers:
[14:36] <seb128> * my two PRs got merged, improving performance for snaps using the
[14:36] <seb128> GNOME platform snap.
[14:36] <seb128> * unfortunately there were reports of problems from people not using
[14:36] <seb128> the platform snap.  This was down to the older GLib in 16.04 not
[14:36] <seb128> looking for scheams in $XDG_DATA_HOME.  A fix for this has been pushed
[14:37] <seb128> out, and no further problems have been reported.
[14:37] <seb128> * I'd like to bring the speed ups to the non-platform versions of the
[14:37] <seb128> part, but it doesn't look like snapcraft currently has the required
[14:37] <seb128> hooks at the moment.  I started a thread on the forum to see if there
[14:37] <seb128> is interest in adding them.
[14:37] <seb128> snapd:
[14:37] <seb128> * user-mounts branch is still waiting to land.  I need to follow up on
[14:37] <seb128> what else needs doing.
[14:37] <seb128> * gnome-online-accounts-service branch works
[14:37] <seb128> #topic jibel/heber
[14:37] <seb128> jibel, heber, hey
[14:37] <jibel> - Finished SRU verification of gnome-software in artful, waiting for publication to -updates.
[14:37] <jibel> - Investigated how to run gtk apps with dtrace enabled for glib to measure application performance.
[14:37] <jibel> - Defined a basic set of tests to smoke test releases of Firefox.
[14:37] <jibel> - Ported selenium autopkgtest of Chromium to Firefox.
[14:37] <jibel> - Investigated specific cases of upgrade failures for customers.
[14:37] <jibel> - Submitted merge proposal for snapd tests.
[14:37] <jibel> - Testing of Bluez 5.47 snap on desktop.
[14:37] <jibel> - Snap autopilot-gtk in progress but the introspection of GTK apps is still not working…
[14:37] <jibel> ...
[14:37] <seb128> thanks jibel
[14:38] <seb128> #topic kenvandine
[14:38] <seb128> kenvandine, hey
[14:38] <kenvandine> * Reviewed, tested and merged the desktop helpers PRs from jamesh.
[14:38] <kenvandine> * Debugged issues found with the desktop helpers improvements related to gsettings schemas and the gtk3 launcher
[14:38] <kenvandine> * Rebuilt all of the GNOME snaps with the improved desktop helpers
[14:38] <kenvandine> * Two more GNOME projects accepted the snap packaging upstream
[14:38] <kenvandine> * Working on test snaps for desktop helper testing
[14:38] <kenvandine> EOF
[14:39] <seb128> thanks kenvandine
[14:39] <seb128> #topic Laney
[14:39] <seb128> Laney, hey
[14:39] <Laney> sup
[14:39] <Laney> • short week due to hols
[14:39] <Laney> • autopkgtest:
[14:39] <Laney> ∘ kernel bug that takes down the machines is still happening, whinged at apw about that and now sforshee is assigned
[14:39] <Laney> ‣ trained him on how to get into the environment and operate nova enough to work on a fix
[14:39] <Laney> ∘ some more skill sharing with Steve
[14:39] <Laney> • systemd-session
[14:39] <Laney> ∘ started working on this, kicked some upstream bugs a bit
[14:39] <Laney> ∘ been working on some units to push upstream
[14:40] <Laney> ∘ trying to understand what upstream changes are going to be needed (gnome-session stuff)
[14:40] <Laney> ∘ now I can log in to a black screen!
[14:40] <Laney> ∘ going to be an ongoing project
[14:40] <Laney> • snap seeding
[14:40] <Laney> ∘ got review from Colin, fixed based on that feedback
[14:40] <Laney> ∘ he raised the issue of classic snaps, apparently they need to be seeded differently so we'll have to be able to specify that in the seed I think
[14:40] <Laney> 🎄
[14:40] <seb128> thanks Laney, quite some work for a post-week-off couple of days :)
[14:41] <seb128> #topic oSoMoN
[14:41] <seb128> oSoMoN, hey
[14:41] <oSoMoN> hey
[14:41] <oSoMoN> • chromium
[14:41] <oSoMoN>   ∘ updated chromium dev to 64.0.3278.0, and updated snap in edge channel
[14:41] <oSoMoN>   ∘ updated chromium beta to 63.0.3239.70, and update snap in beta channel
[14:41] <oSoMoN>   ∘ rebased hardware-accelerated video decoding PPA on latest dev branch: https://launchpad.net/~osomon/+archive/ubuntu/cr-vaapi-test/+packages, need to test again and find out what upstream is up to
[14:41] <oSoMoN>   ∘ tested a11y in latest dev branch, good improvements to exposing the accessibility tree but OSK still not functional, with a simple (and incomplete) patch I enabled it and submitted to upstream authors interested in a11y, they are working on it already
[14:41] <oSoMoN>   ∘ expecting beta branch to be promoted to stable this week
[14:41] <oSoMoN>   ∘ currently investigating snap issues with nvidia proprietary drivers with jd_strand and po_pey's invaluable help
[14:41] <oSoMoN> • libreoffice
[14:41] <oSoMoN>   ∘ 5.4.3 migrated from bionic-proposed to the release pocket (i386 autopkgtest failures were ignored)
[14:41] <oSoMoN>   ∘ 5.4.2 SRU migrated to artful-updates after a possible regression (bug #1733849) was discarded
[14:41] <oSoMoN>   ∘ 5.4.3 snap has been in candidate channel for a few days (rebuilt against updated desktop helpers, now with logic for mime, icon and schema cache generation at build time rather than at run time) and no negative feedback so far, will promote to stable channel today
[14:41] <oSoMoN> that's it from me
[14:41] <seb128> quite a busy week it seems :)
[14:42] <seb128> thanks oSoMoN
[14:42] <seb128> #topic seb128
[14:42] <seb128> • had two day off work
[14:42] <seb128> • some sponsoring (pulseaudio, totem-pl-parser)
[14:42] <seb128> • usual rounds of bugs triaging
[14:42] <seb128> • continued reviewing the plans for the cycle and discussed details of some of the work with people

[14:42] <seb128> #topic tkamppeter
[14:42] <seb128> tkamppeter, hey
[14:42] <tkamppeter> - cpdb-libs: Released version 1.1.0 upstream, to solve problems with Debian packaging.
[14:42] <tkamppeter> - avahi: Received the patch for advertising services on localhost. It is actually a one-liner! One of the GSoC 2017 students did it for me. I have reviewed it and now I am preparing for testing it. Now 18.04 will ship the complete driverless printing fun, including USB.
[14:42] <tkamppeter> - Google Summer of Code 2018: Sahil (who did the PCLm support in cups-filters, for Mopria and WiFi Direct) got his first job starting in July 2018 (congrats), but wants to do (and we want, too) the GSoC 2018, too. He has the next two months free, so he will do his GSoC 2018 in Dec 2017, Jan 2018, and May 2018. Similar will probably happen with Nilanjana. I will probably mentor these students. If all works out 18.04 will already have some GSoC 201
[14:42] <tkamppeter> 8 code, shipping one month before start of official GSoC 2018 coding.
[14:43] <tkamppeter> - Google Summer of Code 2018: Continued planning.
[14:43] <tkamppeter> - CUPS snap: Some exchange of ideas.
[14:43] <tkamppeter> - Bugs.
[14:43] <seb128> thanks tkamppeter
[14:43] <seb128> #topic Trevinho
[14:44] <seb128> Trevinho, hey, around or should I copy your summary from the email you sent?
[14:44] <seb128> copy it is
[14:44] <seb128>  · Various fixes at the gjs PR to avoid acccess to deleted objects
[14:44] <seb128>    methods / properties, added tests and got merged:
[14:44] <seb128>    https://gitlab.gnome.org/GNOME/gjs/merge_requests/22
[14:44] <seb128>  · Fixed some gnome-shell issues (potential crashes) caused
[14:44] <seb128>    by access to deleted objects:
[14:44] <seb128>    https://bugzilla.gnome.org/show_bug.cgi?id=791233
[14:44] <seb128>  · Finished the SRU for the unity stack in xenial, did some fixes
[14:44] <seb128>    to it, and wrote a call-for testing post to get people verify
[14:44] <seb128>    the fixed bugs
[14:44] <seb128> https://community.ubuntu.com/t/unity-stack-sru-for-ubuntu-16-04-help-verify/2420/5
[14:44] <seb128>  · Got in touch with Ambiance-RW author and did some triaging
[14:45] <seb128>    to get him propose upstream his changes.
[14:45] <seb128>  · Fractional scaling work:
[14:45] <seb128>    - Fixed some issues with the a11y zoom
[14:45] <seb128>    - Some refactoring to fix some blurry effects that were
[14:45] <seb128>      happening when using fractional scale.
[14:45] <seb128>    - Fixed loading of some kinds of textures using TextureCache
[14:45] <seb128>      when having resource-scale.
[14:45] <seb128>    - A refactoring of TextureCache to fix potential crashes
[14:45] <seb128>      on loading sliced images.
[14:45] <seb128> #topic robert_ancell
[14:45] <seb128> - Got first iteration of guest support branch for AccountsService
[14:45] <seb128> - Working on guest support in GDM
[14:45] <seb128> - Code clean-ups in GDM
[14:45] <seb128> - Analysing gnome-software crashers in errors.ubuntu.com
[14:45] <seb128> #topic aob
[14:45] <seb128> did I forget anyone? any other topic?
[14:46] <seb128> k, seems not
[14:46] <seb128> efficient meeting today, let's wrap then
[14:47] <seb128> thanks everyone
[14:47] <seb128> #endmeeting
[14:47] <meetingology> Meeting ended Tue Dec  5 14:47:02 2017 UTC.
[14:47] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2017/ubuntu-desktop.2017-12-05-14.31.moin.txt
[14:47] <oSoMoN> sweet and short, thanks seb128
[14:47] <kenvandine> thanks seb128!
[14:47] <jbicha> seb128: btw, I filed the MIR needed for latest udisks LP: #1735499 but it needs libblockdev to get autopkgtests and 2 more MIRs
[14:49] <seb128> jbicha, thanks, those are for the recommends? what features are missing without those extra plugins?
[14:49] <Trevinho> seb128: sorry I arrived few minutes later, thanks for pasting :)
[14:50] <seb128> Trevinho, no worry, good morning, how are you today?
[14:50] <jbicha> seb128: libblockdev-crypto2 is for LUKS so I think we really want that, but I haven't looked very closely at all of it
[14:52] <Trevinho> seb128: I'm good, thanks... what about you?
[14:54] <seb128> Trevinho, I'm good thanks
[14:54] <Trevinho> great to hear :)
[14:59] <mdeslaur> What component in 17.10 creates the .local and .config directories?
[15:03] <Trevinho> mdeslaur: I guess the first app that is launched and that might need them? :o
[15:04] <mdeslaur> hrm, I'm looking at bug 1735929 and trying to figure out what that might be
[15:06] <seb128> mdeslaur, I would guess gnome-settings-daemon but it might be that other components who need those dirs create them if they don't exist as well
[15:08] <seb128> mdeslaur, https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/housekeeping/gsd-housekeeping-manager.c#n391
[15:08] <Trevinho> mdeslaur: so I think, one thing we can do is having a component creating them earlier with proper rights...
[15:08] <jdstrand> popey: mind doing another test for me?
[15:08] <Trevinho> might be even a migration script, no?
[15:08] <seb128> Trevinho, ^ that code is supposed to be that no
[15:08] <Trevinho> seb128: yeah, but it might run after other things in session I guess
[15:09] <mgedmin> hmm, I don't see mkdirsnoop in https://github.com/iovisor/bcc
[15:09] <mgedmin> but it would be the perfect tool to discover who creates the directory, if it existed
[15:10] <mdeslaur> maybe fatrace
[15:11] <Trevinho> mdeslaur: not sure if adding just an inotify monitor would help in saying the process who creates things
[15:11] <mdeslaur> I mean the package called fatrace
[15:12] <tedg> Isn't it xdg-user-dirs-update?
[15:12] <seb128> hey tedg
[15:12] <kenvandine> hey tedg
[15:12] <Trevinho> oh hey tedg
[15:12] <jbicha> mdeslaur: what about having something ship those directories in /etc/skel/ ?
[15:12] <mdeslaur> hi tedg
[15:13] <seb128> tedg, that handles images/videos/templates/etc not the private dirs
[15:13] <tedg> Howdy folks, ah, I thought it did all of them.
[15:13] <seb128> jbicha, what about stack unreliable workarounds rather than fixing the bug? :)
[15:13] <seb128> stacking*
[15:13] <Laney> it does make ~/.config but only because that's where user-dirs own config lives
[15:13] <Laney> IIRC
[15:14] <seb128> that component didn't change for years though, so if we are looking at a bug it's not likely there
[15:14] <tedg> Perhaps it should make .local and that would fix mdeslaur's bug ;-)
[15:15] <jdstrand> popey: when you have a moment: http://paste.ubuntu.com/26119147/
[15:15] <jdstrand> hey tedg! :)
[15:16]  * tedg blushes from all the hellos :-)
[15:18] <jdstrand> popey: actually, make that http://paste.ubuntu.com/26119164/ (the first should be enough so if you started with that, that's fine)
[15:20] <seb128> mdeslaur, well, I guess another way would be to look at the binaries active and do remove the dirs/restart the binaries one by one and see if they create it and with which mode
[15:20] <popey> jdstrand: i will have time to look at that in an hour or so
[15:20] <mdeslaur> seb128: let me see how far back this issue goes, and then I'll install fatrace and will figure it out
[15:21] <seb128> mdeslaur, I can find it tomorrow if you want
[15:21] <mdeslaur> seb128: I'll let you know how far I get, thanks
[15:21] <jdstrand> popey: ok, I think I can come up with workaround policy for browser-support. just need you to confirm it works
[15:21] <popey> ok
[15:22] <seb128> mdeslaur, k, thanks
[15:45] <jdstrand> popey: please report back here either way so I can help troubleshoot if needed. if it succeeds, then please respond to https://forum.snapcraft.io/t/call-for-testing-chromium-62-0-3202-62/2569/46
[15:49] <oSoMoN> jdstrand, that'd be awesome!
[15:52] <jdstrand> oSoMoN: it would certainly save you some time :)
[15:53] <jdstrand> it's really weird that chromium is doing that
[15:53] <jdstrand> "I'm not root, the file exists, but I'm going to mknod it anyway"
[16:07] <oSoMoN> yeah, that really doesn't sound right
[16:09] <popey> jdstrand: http://people.canonical.com/~alan/chromium.trace3.gz
[16:09] <popey> jdstrand: chromium launched fine with those changes
[16:12] <jdstrand> popey: great, thanks. can you comment in the forum?
[16:13] <popey> done
[16:24] <oSoMoN> kenvandine, that's a very similar issue you were seeing with chromium, isn't it? https://forum.snapcraft.io/t/call-for-testing-libreoffice-5-4-3/2935/6?u=osomon
[16:25] <kenvandine> oSoMoN, yes, same issue
[16:25] <kenvandine> Trevinho, ^^ do you have any ideas about that?
[16:25] <kenvandine> Trevinho, apps that register as a gapplication doesn't have the issue
[16:26]  * Trevinho reads
[16:26] <kenvandine> it happens when the snap refreshes while the app is running
[16:26] <kenvandine> chromium and libreoffice snaps
[16:27] <Trevinho> kenvandine: mh, it looks like it happens when the .desktop file is deleted
[16:27] <Trevinho> I'm not much familiar with all that but i can give a look
[16:28] <kenvandine> Trevinho, thx
[16:28] <Trevinho> kenvandine: is this happening also when a .deb is updated?
[16:28] <kenvandine> not that i'm aware of
[16:28] <Trevinho> it would be nice to test
[16:28] <kenvandine> so the running process might be like /snap/chromium/54/bin/chromium
[16:28] <Trevinho> as it might be the way the .desktop file sobstitution is done
[16:28] <kenvandine> and after updating it might be /snap/chromium/62/bin/chromium
[16:28] <kenvandine> something like that
[16:29] <kenvandine> doesn't happen for the gnome snaps
[16:29] <Trevinho> I remember we had an issue when they were just replaced, while it was fine when removed first then replaced or the other way around... :o
[16:29] <Trevinho> mh, yeah, they are tracked using the desktop id too, so I guess it's simpler
[16:29] <kenvandine> right
[16:29] <Trevinho> anything smaller I can try with? :)
[16:29] <kenvandine> lol
[16:29] <kenvandine> no... sorry :)
[16:30] <kenvandine> those are the only two i know of
[16:30] <oSoMoN> kenvandine, do we have a bug report to track the issue? or should I file one? (if so, against which project Trevinho?)
[16:31] <kenvandine> oSoMoN, no bug report i know of
[16:58] <kenvandine> using the gnome platform snap, checkout the time it takes to run the first time
[16:58] <kenvandine> real	0m0.289s
[16:59] <kenvandine> using the gtk3 launcher though... much worse still
[16:59] <kenvandine> real	0m31.995s
[17:10] <oSoMoN> kenvandine, Trevinho: bug #1736525
[17:11] <kenvandine> oSoMoN, Trevinho: thx
[18:03] <Laney> night night
[19:06] <oSoMoN> night all
[22:02] <jbicha> robert_ancell: howdy, I poked at LP: #1271358 today, maybe we'll be able to close that 4-year old bug this cycle :)
[22:02] <robert_ancell> jbicha, that would be nice :)
[22:12] <kennyloggins> robert_ancell: forgive my misunderstanding but does this affect 2D or 3D in bionic beaver ?
[22:30] <kennyloggins> robert_ancell: is that a canonical issue ?
[22:47] <robert_ancell> kennyloggins, 2D or 3D what?
[22:48] <robert_ancell> kennyloggins, the vino package had just been held back forever, so it would be nice to run the latest upstream.
[22:49] <robert_ancell> There's not a major improvement for users, but it means we'd be able to get any future enhancements more easily
[22:49] <kennyloggins> what is the sub-user for this - is it a debian issue aswell ?
[22:50] <robert_ancell> kennyloggins, debian is already running a newer version
[22:51] <jbicha> kennyloggins: see https://community.ubuntu.com/t/update-vino-to-current-version-affects-unity/2537
[22:51] <kennyloggins> but buster is not completed in terms of compatability, is that right - unsure kinda of getting the whole vino-issue. What is vino ?
[22:52] <robert_ancell> kennyloggins, vino is the GNOME VNC server
[22:54] <kennyloggins> jbicha: I have just realised this is a hyacinth-issue then. Does it affect zinc aswell ?
[22:54] <robert_ancell> Upstream is 3.22 (https://download.gnome.org/sources/vino), Debian has this version (https://packages.debian.org/search?keywords=vino), Ubuntu has 3.8 (https://launchpad.net/ubuntu/+source/vino)
[22:54] <jbicha> kennyloggins: I have no idea what you're talking about
[22:57] <kennyloggins> jbicha: sorry, Its my blueberry tea, apologies. shall not ping you anymore.
[22:58] <kennyloggins> robert_ancell:  I just think that someone in packaging that uses something like yakkety yak zinc would help, well maybe if I knew someone there ?
[23:01] <kennyloggins> robet_ancell : would this guy help ? https://launchpad.net/~pitti
[23:05] <kennyloggins> robert_ancell: anytime soon, pal - or am I distracting you ?