[05:05] <pitti> Good morning
[05:05] <pitti> Trevinho: yes, with hardwired key actions there are no userspace notifications, so we can't create notification bubbles in userspace
[05:06] <pitti> but not a biggie for a kbd backlight -- I mean, the notification shold be that the brightness changes :)
[07:22] <willcooke> morning all
[07:22] <willcooke> seb128, need to leave early this evening, just fyi
[07:22] <hikiko> morning willcooke
[07:22] <willcooke> once the meeting is done
[07:22] <willcooke> hi hikiko
[07:38] <seb128> hey willcooke & desktopers
[07:38] <seb128> willcooke, k, no problem ... do you want me to handle the meeting?
[07:46] <willcooke> seb128, nah, should be wrapped up by 5 my time I think
[07:46] <seb128> likely yes
[07:49] <happyaron> hey seb128
[07:50] <seb128> hey happyaron, how are you?
[07:50] <happyaron> great, you?
[07:50] <seb128> happyaron, I'm going to look at your nm 1.2.2 today, sorry didn't manage to get to it on friday and yesterday was an holiday in France
[07:50] <seb128> happyaron, I'm good thanks :-)
[07:50] <happyaron> np, the link is updated - https://launchpad.net/~happyaron/+archive/ubuntu/ppa/+sourcepub/6431454/+listing-archive-extra
[07:51] <happyaron> and will have a meeting with oem people for nm in a couple of minutes
[07:52] <Sweet5hark> goood morning desktoppers!
[07:52] <seb128> happyaron, any specific issue/topic from oem?
[07:52] <seb128> hey Sweet5hark! had a good w.e? (was yesterday off for you as well?)
[07:53] <seb128> happyaron, btw did you talk to anybody from kubuntu about the symbol issue in their bindings?
[07:53] <happyaron> seb128: there is a list, will send something out after the meeting
[07:53] <seb128> k, great
[07:53] <happyaron> seb128: yep we talked last week
[07:53] <happyaron> they are going to ask upstream for a proper solution
[07:53] <seb128> k
[07:53] <seb128> what component has the issue?
[07:53] <seb128> is https://launchpad.net/ubuntu/+source/networkmanager-qt/5.18.0-0ubuntu1.2 a fix for that?
[07:54] <seb128> or something else?
[07:54] <happyaron> it's not a fix for that
[07:54] <happyaron> but a recompile may work around it
[07:54] <seb128> k
[07:54] <Sweet5hark> seb128: yesterday was off too here. I wasted a lot of time on the weekend to #makespacegreatagain (aka playing Stellaris now that its out)
[07:54] <seb128> can  you ping them again? they are going to block the sru until that's sorted out
[07:55] <happyaron> will do today
[07:55] <Sweet5hark> stellaris is just slightly more addictive than crack. About on the same level as a new release of Civilizations just-one-more-turn-syndrome.
[07:58] <seb128> happyaron, thanks
[07:58] <seb128> Sweet5hark, lol, sounds like better to stay away from it ;-)
[07:59] <Sweet5hark> seb128: its lots of fun though ;)
[07:59] <seb128> I can imagine :-)
[07:59] <seb128> but those also the best way to cut your sleep hours :p
[08:00] <seb128> "I'm close from victory, should be done in a few more turns"
[08:00] <seb128> 1.5h later "ok, Í'm getting there, just a bit more effort and it's done"
[08:00] <seb128> then it's 3am
[08:00] <seb128> been there :p
[08:02] <Sweet5hark> seb128: yeah, the tendency of "wtf is the sun doing dawning outside, it was just setting ..." is strong in this one.
[08:02] <seb128> :-)
[08:03] <Laney> yo
[08:05] <Sweet5hark> Laney: I see the bears didnt want to eat you over the weekend?
[08:07] <Laney> just the slugs
[08:07] <Laney> but they are week
[08:07] <Laney> weak
[08:10] <seb128> hey Laney! how are you?
[08:11] <seb128> had fun camping?
[08:11] <seb128> and how was monday around? not too crazy?
[08:13] <Laney> hi seb128
[08:13] <Laney> camping was fun, nice area out there
[08:13] <Laney> didn't get much sleep though
[08:14] <Laney> so was a quiet weekend otherwise ;-)
[08:14] <Laney> monday was okay... just worked on the hire stuff a bit and then the theme for 3.20 mostly
[08:14] <Laney> how ws your long weekend?
[08:14] <seb128> oh, you are doing the theme updatE?
[08:14] <seb128> nice :-)
[08:15] <seb128> quite good! though the weather was not as nice as previous week
[08:16] <seb128> we had friends over on saturday to make fun of the eurovision singers while eating pizza ;-)
[08:16] <seb128> otherwise played some videogames/watched some tennis on TV/relaxed mostly
[08:17] <Laney> there's always tennis!
[08:22]  * Laney cries
[08:22] <Laney> email without filter rules
[08:22] <Laney> oh my dear lord
[08:23] <seb128> oh, you did that email migration?
[08:23] <Laney> I have autopkgtest failures in with debian-devel in with emails about cycling stuff in with launchpad bug mail
[08:23] <seb128> and yeah, tennis is good :p
[08:23] <Laney> "did"
[08:23] <Laney> I would say started
[08:23] <seb128> now is the fun part? ;-)
[08:24] <Laney> indeed
[08:24] <Laney> need to learn this sieve filtering language they use
[08:24] <Laney> dovecot's one
[08:29] <willcooke> hey seb128 - did you upload the new Calendar to X btw?
[08:29]  * willcooke goes looking for the link to the queue
[08:30] <seb128> willcooke, yeah, https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=gnome-calendar
[08:30] <seb128> the queue has 39 items though
[08:30] <willcooke> seb128, sweet.  thanks.  I can test in proposed though right>?
[08:31] <seb128> it's not in proposed yet
[08:31] <seb128> workflow is
[08:31] <seb128> upload -> queue
[08:31] <seb128> review/ack -> proposed
[08:31] <seb128> verified -> updates
[08:39] <willcooke> seb128, ahh, I see.  I saw "pocket: proposed" and thought it was already there.  nw
[08:39] <seb128> no, it's the target
[08:42] <willcooke> got it
[08:47] <willcooke> seb128, Laney - with the +1 from design and a comment from sabdfl, I (think I) have made this bug SRU compliant:
[08:47] <willcooke> https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/762349
[08:47] <willcooke> when you get a sec, could you read over it and see if it's ok?
[09:13] <seb128> Sweet5hark, seems like people mentioned your name on bug #1577316 / asking for debugging hint
[09:13]  * Sweet5hark looks
[09:19] <willcooke> happyaron, great work on OEM NM issues - thanks
[09:22] <Sweet5hark> seb128: commented on with some (hopefully helpful) hints
[09:22] <seb128> Sweet5hark, thanks
[09:59] <andyrock> morning
[10:00] <andyrock> seb128: https://bugs.launchpad.net/ubuntu/+source/gnome-menus/+bug/1506744/comments/42
[10:14] <willcooke> new wifi card is here
[10:14] <willcooke> going to attempt to fit it.
[10:14] <willcooke> wish me luck....
[10:15] <Laney> live strong
[10:15] <willcooke> oh man, there are about a mllion screws to remote
[10:15] <willcooke> remove
[10:16] <willcooke> I predict pain
[10:16] <Laney> is this in a laptop?
[10:16] <willcooke> yeah, x220
[10:16] <Laney> fun
[10:16] <Laney> keep track of where they all came from
[10:16] <willcooke> I found a video on the Lenovo website
[10:17] <willcooke> right, here goes nothing... powering off....  START THE CLOCK
[10:19] <Laney> a suspicious single beep just sounded from somewhere in this room
[10:20]  * Laney panics
[10:30] <Laney> http://people.canonical.com/~laney/weird-things/gtk320.png
[10:30] <Laney> don't know about you but that looks pixel perfect to me
[10:30] <Laney> going to upload now
[10:33] <ricotz> hey desktopers
[10:33] <ricotz> Laney, hi, please make sure to add https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-20&id=e006f3ca98990f6e3c8da58b49d7feba8403bb47
[10:34] <Laney> did you look at the screenshot?
[10:34] <ricotz> Laney, not really
[10:34] <Laney> pretty sure there will be a point release before this is good
[10:35] <ricotz> I didnt expect this so land any other than in a PPA though
[10:37] <Laney> check it yo
[10:39] <willcooke> Done!
[10:41] <Laney> congrats
[10:41] <willcooke> wifi is connected at a massive 1Mb
[10:42] <willcooke> so... hmmmmmmmmmm
[10:42] <Laney> 5mb/s \m/
[10:43] <willcooke> Thankfully my wired ethernet connection is connected at 1000 Mb :)
[10:45] <willcooke> suppose I should test it actually works then...
[10:45] <willcooke> undocking........
[10:47] <willcooke_> yay
[10:47] <willcooke_> now connected at 65 Mb
[10:47]  * willcooke_ goes for a walk around the house
[10:47] <willcooke_> Kitchen!
[10:48] <willcooke_> End of the garden!
[10:48] <willcooke_> 58Mbps
[10:49] <willcooke_> In reality I'm getting 3Mb, but thats ok
[10:50] <willcooke_> redocked
[10:51] <willcooke> good.
[11:22] <willcooke> hello aquarius_
[11:22] <aquarius_> yo :)
[11:23] <aquarius_> hey, desktop peeps. How should a Python Gtk3 program play a system sound? GSound doesn't seem to be present in gi.repository on 14.04 or 16.04. (Perhaps a Trevinho question?)
[11:24] <pitti> aquarius_: gir1.2-gsound-1.0 should provide libcanberra bindings
[11:24] <pitti> or rather, GSound wraps libcanberra, and that's the GI binding
[11:24] <aquarius_> pitti, that doesn't seem to exist on 14.04?
[11:24] <pitti> but on 16.04
[11:24] <aquarius_> ya, it's in 16.04
[11:25] <pitti> and you said "14.04 or 16.04" :)
[11:25] <aquarius_> heh :) Apologies. It's not present in 14.04 and it's not installed by default in 16.04, I should have said :)
[11:25] <pitti> no idea for 14.04 I'm afraid, perhaps subprocess.call(['paplay', 'stuff.wav']) ? :-)
[11:25] <pitti> (honestly, no idea)
[11:25] <aquarius_> on 14.04, am I best to use the old static canberra bindings? I could just shell out to canberra-gtk-play...
[11:26] <aquarius_> haha! great minds, etc :)
[11:28] <aquarius_> actually, shelling out is probably not a terrible idea; sounds are fire-and-forget anyway, it's not critical if they don't work, and process startup is fast.
[11:32] <seb128> hey pitti, wie gehts? had a good w.e?
[11:32] <pitti> hey seb128! wonderful indeed, thanks! We went to Dresden to visit family again
[11:32] <seb128> ah, nice!
[11:33] <pitti> seb128: on Sunday we did a rafting tour on a wildwater channel, that was a lot of fun (and splash and water :) )
[11:33] <pitti> pics coming soon
[11:33] <pitti> seb128: and we had a long w.e. here due to Pentecost
[11:33] <pitti> seb128: et toi, as-tu passé un bon weekend?
[11:34] <seb128> oui, aussi merci
[11:34] <seb128> had a 3 days w.e as well
[11:34] <seb128> was mostly relaxing
[11:34] <seb128> we had friends over on saturday to eat pizza and made fun of eurovision singers ;-)
[11:35] <seb128> otherwise watching tennis on tv, played some video game, had some walks outside
[11:38] <Trevinho> aquarius_: mh yeah.... I guess for 14.04 you've to fallback to canberra or some scripts
[11:38] <aquarius_> yeah. I shall shell out. :)
[11:38] <aquarius_> thank you pitti and Trevinho!
[11:38] <pitti> aquarius_: not shell, just subprocess.call()
[11:39] <aquarius_> os.system is probably as good here, I think? I'm not passing untrusted data to it (it's only called from within my app with hardcoded sound names), and it needs to be a background process so we don't block on it
[11:40] <pitti> os.system is almost never a good idea
[11:40] <aquarius_> agreed, because you have to escape things properly, you can't get its response, etc. In this particular case, I'm not worried about any of that, though?
[11:41] <pitti> aquarius_: subprocess.Popen(['canberra-gtk-play', 'yoursound.wav']) and clean it up later on
[11:41] <pitti> (or don't, if you aren't interested in the exit code)
[11:44] <aquarius_> I agree it's not hard, I'm just wondering why the change in this particular case matters? I normally avoid os.system because it's bad for security, as mentioned.
[11:45] <aquarius_> (reads documentation on how to run it in the background)
[11:48] <seb128> happyaron, do you have a packaging vcs for network-manager?
[11:49] <aquarius_> pitti, hrm, running the process in the background seems quite a bit harder this way...
[11:49] <pitti> aquarius_: how do you mean? Popen() always starts it in the background
[11:50] <pitti> (unlike .call() or .check_call())
[11:50] <pitti> to the contrary, os.system() is syncronous
[11:50] <aquarius_> Yes. Yes, it does. subprocess.call doesn't, though, because I am stupid :)
[11:50] <aquarius_> fixed now :)
[11:51] <happyaron> seb128: https://code.launchpad.net/~happyaron/network-manager/+git/ubuntu
[11:56] <seb128> happyaron, thanks, it means I can't just cowboy hack the upload :p
[11:56] <seb128> happyaron, I was pondering adding https://git.gnome.org/browse/network-manager-applet/commit/?id=c3255ed740592a2f23a7ebc47f1acd2dd2d768b3 to the applet update
[11:56] <happyaron> seb128: I'm thinking about pushing 1.2.2 directly
[11:57] <happyaron> as the OEM guys would need that for most of their problems
[11:57] <happyaron> what do you think?
[11:59] <seb128> happyaron, that commit is after 1.2.2
[11:59] <seb128> you mean in xenial?
[11:59] <seb128> we just need the current SRU copied over first
[11:59] <seb128> it has the important fix for oem
[11:59] <seb128> or do they have other issues?
[12:00] <happyaron> they have several other issues
[12:00] <seb128> happyaron, do they have a list/bugs?
[12:01] <happyaron> seb128: check email
[12:01] <seb128> happyaron, thanks
[12:03] <seb128> happyaron, but yeah, let's keep rolling and prepare 1.2.2 for xenial
[12:03] <happyaron> yep, will prepare 1.2.2 for yakkety for the moment
[12:06] <seb128> happyaron, I though you had that ready?
[12:06] <seb128> next steps would be to get it in a ppa that oem&co can use for testing and that is going to turn into the next SRU
[12:06] <seb128> xenial ppa that is
[12:26] <Trevinho> seb128: hey, on the snap world... I've did some tests and at the end I think we can run most of gtk apps generating caches at runtime... here's an example: https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858 but I can apply the same to the calc snap we were hacking in Prague
[12:27] <Trevinho> pitti: I can't find the channel now, but I read somewhere a ping from you about the fact that hardwired events can't be notifier by udev/upower, or something like that, right?
[12:28] <pitti> Trevinho: yes, some laptop models are like that -- the brightness keys (screen or kbd) don't send any software event, they just directly change the brightness
[12:28] <seb128> Trevinho, shrugh, hacks on hacks :-/
[12:29] <Trevinho> seb128: yeah, I know.. that's how things work, though :/
[12:29] <seb128> Trevinho, so we would regenerate the caches at every application run?
[12:29] <Trevinho> seb128:  at least now things are generated on first run, which means later startup times are reduced a lot
[12:29] <seb128> ah, right
[12:29] <Trevinho> seb128: no, just first time
[12:29] <seb128> the user dir is persistent
[12:29] <seb128> right
[12:29] <Trevinho> yes, I made it snap version-dependent though
[12:30] <seb128> that makes sense
[12:30] <Trevinho> so if new packages, or new gsettings are added, they get regenrated
[12:30] <seb128> the content might change between versions
[12:30] <Trevinho> exactly
[12:30] <seb128> what do you build from?
[12:30] <seb128> source?
[12:30] <seb128> for the quilt thing to work
[12:30] <seb128> because the ones we played with was using the deb
[12:30] <seb128> so no compilation
[12:32] <Trevinho> pitti: yes... That's almost true... Almost since... in my thinkpads for example, the event is not triggered by default. However, by tuning the proc ibm hotkeys sysnode, I can get a KEY_KBDTOGGLEILLUM (or whatherver iscalled). But that break things, since laptop-side is just a notification that brightness has changed, not a request of changing it from
[12:32] <Trevinho> userland level
[12:32] <Trevinho> pitti: so... I was wondering if there's a way to use that event, and instead of triggering it to the userpsace, handling it a the kernel module level, to send an udev event that the led status has changed
[12:33] <Trevinho> pitti: then... upower could monitor that, maybe...
[12:33] <pitti> Trevinho: that's a lot of custom code in userspace then (new uevents etc.)
[12:33] <pitti> presumably sending a new type of key via evdev is simpler, but we don't have a definition for such new "indicate only" keys
[12:34] <seb128> pitti, is there any chance you get slot for the upower issue this week? can I help in some way to move it forward (I'm going to have a quick look to the upower code but if it's not trivial and I'm probably not going to be able to block enough days to learn the code&co)
[12:34] <pitti> Trevinho: I don't know whether this can be tweaked in the kernel/BIOS
[12:34] <Trevinho> pitti: mh.. I see... Well in some cases it seems that kernel events are fired when kbd illumination changes (only when zero'ed though)
[12:35]  * pitti frankly doesn't see the point -- isn't the best (and only) notification that you should see that the bridghtness of the keyboard actually changes?
[12:35] <Trevinho> pitti: so... making upower to actually read the value instead of relying on a cached one is something better for you?
[12:35] <pitti> Trevinho: upower reads the actual values from sysfs
[12:35] <Trevinho> pitti: yeah, I don't mind of the notification...
[12:35] <pitti> it doesn't "cache" anything, it just proxies sysfs as dbus properties
[12:35] <Trevinho> pitti: the thing is that u-s-d needs to know the actual state before idling the laptop
[12:35] <Trevinho> or it will resume things to the old value
[12:36] <pitti> seb128: ugh, is it that complicated? I guess most of that code is autogenerated indeed
[12:36] <pitti> seb128: anyway, I'll have a look now
[12:36] <Trevinho> pitti: mhmh... https://cgit.freedesktop.org/upower/tree/src/up-kbd-backlight.c#n106
[12:36] <pitti> seb128: this "one dbus per user" is highly annoying, I'll postpone that
[12:36] <Trevinho> seb128: are we spakeing of the same thing?
[12:37] <Trevinho> seb128: of the same issue, I mean, or something else?
[12:38] <Trevinho> pitti: priv->brightness is only updated  when user sets it, and that's what is returned when you call the getter
[12:38] <pitti> Trevinho: oh, this; ok, so you're saying this never gets written correctly from sysfs?
[12:39] <pitti> Trevinho: no, seb128 means freedesktop bug 95350
[12:40] <Trevinho> pitti: currently thinkpad and dell systems have this scenario: you change brightness from keyboard, the laptop goes idle, ups turn down the brightnes... Saving the previous level around. However the previous level is got from a cached value since if you call getbrightness from upower, it will always return the cached value, not the last one you changed. Now,
[12:40] <Trevinho> when you get back to the laptop, you won't get the proper backlight.
[12:41] <Trevinho> this is done this way, because there are laptops (like asus ones), which just reports a kernel request to change brightness., then userspace changes it.. calling SetBrightness in Upower... And so all this works. But in the other cases it doesn't
[12:42] <Trevinho> marco@tricky:~$ cat /sys/class/leds/tpacpi\:\:kbd_backlight/brightness
[12:42] <Trevinho> 1
[12:42] <Trevinho> marco@tricky:~$ gdbus call --system --dest org.freedesktop.UPower --object-path /org/freedesktop/UPower/KbdBacklight --method org.freedesktop.UPower.KbdBacklight.GetBrightness
[12:42] <Trevinho> (2,)
[12:42] <pitti> Trevinho: so this could be changed to drop the brightness iternal property and always read it
[12:42] <Trevinho> this is what I'm getting now
[12:42] <Trevinho> exactly... that's what I wanted to do in fact
[12:42] <Trevinho> I just was wondering if upstream is fine with that
[12:43] <pitti> ok from my side; best to file an upstream bug report, then we can ask hughsie
[12:45] <Trevinho> ok
[12:47] <seb128> pitti, I don't know if it's complicated but I'm not familiar with the codebase, I can start pocking a bit around in case it's easy but I've some meetings in the afternoon and I'm probably not going to be able to do much in between
[12:47] <pitti> seb128: looking at it now
[12:47] <seb128> danke
[12:47] <seb128> sorry to be nagging but it seems to hit quite some LTS users
[12:48] <pitti> seb128: does u-s-d check for up_client_new() returning NULL?
[12:48] <pitti> i. e. will that actually help fixing a crash, or just make it crash differently on a NULL ptr?
[12:51] <seb128> pitti, it's up_client_get_lid_is_closed() which segfaults, has that function in upower-glib has "g_return_val_if_fail (UP_IS_CLIENT (client), FALSE);"
[12:51] <seb128> has->and
[12:51] <seb128> pitti, also the usd side didn't change since trusty and that was not an issue
[12:52] <seb128> so I expect that fixing the bug is going to make usd happy again
[12:58] <pitti> seb128: hm, same upower behaviour in trusty and wily
[12:59] <pitti> seb128: so I guess the fact that upowerd doesn't start is the thing that actually changed and triggered this?
[13:00] <pitti> (or takes long to start)
[13:01] <seb128> could be I guess :-/
[13:06] <seb128> pitti, sorry otp ... but yeah, the root of the issue is probably a kernel bug delaying upower start on usb enumeration
[13:06] <seb128> unsure how we could workaround from usd is upower returns a valid object
[13:06] <seb128> is->if
[13:07] <seb128> which then trigger an upower segfault in an libupower-glib function when used on the said object
[13:07] <seb128> -upower
[13:07] <pitti> seb128: I am looking into that now, but as I said this won't really help to fix the issue
[13:07] <pitti> seb128: unless usd repeatedly tries to connect, it will be stuck with a NULL object forever, and thus not work
[13:08] <seb128> hum, right...
[13:09] <pitti> seb128: sorry, it's been too long: g_object_new (UP_TYPE_CLIENT, NULL);
[13:10] <pitti> that calls some type specific constructor, something like up_client_alloc() or so?
[13:10] <pitti> which we could change to return NULL on failure?
[13:10] <seb128> (otp,going to look in a bit)
[13:10] <pitti> but I'm really not sure that this is the correct fix
[13:10] <a1fa> andrea, you here?
[13:11] <pitti> because of the above (once upower does finish starting, the object should become useful
[13:13] <pitti> oh, _init()
[13:13] <seb128> pitti, shouldn't the upower call just block until upower gets ready rather than timing out then?
[13:13] <pitti> seb128: no, would potentially block forever then
[13:14] <pitti> and I can't change the object pointer in _init()
[13:14] <seb128> that would be the right thing to do in that case, the upower plugin is useless without upower
[13:14]  * Sweet5hark is out for a bit (shopping for an office chair that doesnt suck)
[13:15] <seb128> Sweet5hark, good luck finding one!
[13:15] <pitti> seb128: ah, I think I could unref the object in up_client_new() and return NULL; that would at least provide a more defined behaviour
[13:16] <pitti> but I'm not sure whether it's actually the more desirable behaviour
[13:16] <pitti> desrt: halp
[13:16] <seb128> pitti, he's in a call talking I guess we can discuss that more after that meeting
[13:16] <seb128> she*
[13:18] <pitti> bah, up_client_get() doesn't have such an UP_IS_CLIENT() assertion, but instead
[13:19] <pitti> ……………………if (client->priv->proxy == NULL)
[13:19] <pitti>                 return;
[13:19] <pitti> *throws hands into air* horribly inconsistent
[13:24] <seb128> pitti, but yeah, maybe we need to just get the kernel bug fixed...
[13:40] <seb128> happyaron, do you know why bug #1547826 was not closed? is that still an issue?
[13:54] <dandre> Hello,
[13:54] <dandre> I am looking for a widget I could place in my desktop toobar to create more or less a custom menu like th main menu but not included as a sub menu of it. I am using gnome flashbak desktop
[13:57] <dandre> I have found a simple python script sshmenu but the launch button goes into the notification area and I want a separate button. Is there any possibility?
[14:00] <dandre> it's not sshmenu but sshplus
[14:01] <seb128> desrt, hey
[14:01] <desrt> hey
[14:02] <seb128> desrt, in the call you mentioned discussions about mimetype/url handlers/help
[14:02] <seb128> who discussed that/where
[14:02] <desrt> attente and i were discussing it yesterday
[14:02] <desrt> he's writing a dbus service to allow confined apps to open uris "on the outside"
[14:02] <seb128> ah ok, I've that on my list of things I meant to look at
[14:02] <desrt> right now we're doing it really simple, as mentioned: allow http, https, mailto... everything else is a no-no
[14:03] <seb128> desrt, attente, I opened https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576296 about that btw
[14:03] <willcooke> I think those urli's will probably cover 99% of cases
[14:04] <willcooke> uri
[14:04] <seb128> well, "help" is usually help: uris
[14:04] <seb128> which yelp is the handler for
[14:11] <seb128> desrt, also I didn't understand the bits about what is flatpack currently doing for gsettings? do they have something to let app change its own keys?
[14:11] <desrt> not yet
[14:11] <desrt> that's what we're discussing on the call
[14:12] <desrt> *flatpak btw
[14:12] <seb128> thanks
[14:12] <seb128> and yeah, I followed the discussion
[14:12] <desrt> because, you know, dropping letters is cool
[14:12] <seb128> I just didn't hear alex at the start, audio was cutting
[14:12] <desrt> basically, they will do the same thing as we do
[14:13] <seb128> I though he said that they had a simple solution which restricted the schemas to current app
[14:13] <desrt> this was a theoretical imagined solution.  it doesn't exist yet.
[14:13] <seb128> k, that's the bit I missed
[14:13] <seb128> thanks
[14:13] <desrt> he was talking more about how he supposed it would work
[14:13] <seb128> do they currently give access to the system db?
[14:13] <desrt> there is not usually a system db
[14:14] <seb128> sorry, I meant the user one
[14:14] <seb128> but full db
[14:14] <desrt> it depends on the settings
[14:14] <desrt> it's possible to specify a package that gets full user homedir access
[14:14] <desrt> just like we can
[14:14] <desrt> in that case, it would work
[14:14] <seb128> right
[14:14] <desrt> otherwise, not
[14:14] <seb128> it's all or something
[14:14] <seb128> shrug
[14:14] <seb128> it's all or *nothing*
[14:15] <seb128> they also have the userdir under the normal location when they do that, right?
[14:15] <seb128> where snaps has it under some /snap path
[14:17] <desrt> in general, flatpaks are much more flexible in terms of file locations because they use a new mount namespace instead of apparmor-based filtering
[14:17] <desrt> so they don't run into the same path-relocation problems that we do
[14:18]  * jdstrand notes that the apparmor-based filtering has nothing to do with that
[14:18] <jdstrand> it is the choice of paths that is the problem
[14:19] <jdstrand> but that is a technicality
[14:19] <seb128> well, if we had a mount namespace doing the restriction we wouldn't need to apparmor filter behind?
[14:20] <jdstrand> yes
[14:20] <jdstrand> you want the MAC
[14:20] <jdstrand> but don't get hung up on that
[14:21] <jdstrand> I think you mean file namespace
[14:21] <seb128> yeah
[14:21] <jdstrand> well, NEWNS
[14:22] <jdstrand> anyhoo
[14:22] <seb128> but right, what is creating issues from our side is not what is used to restrict the locations
[14:22] <seb128> just that things are available at a non standard path
[14:22] <jdstrand> correct
[14:22] <seb128> which confuses existing code
[14:23] <jdstrand> but there are problems on either side
[14:24] <jdstrand> as soon as you use a mount namespace, things get really complicated with sharing
[14:25] <seb128> sharing?
[14:25] <jdstrand> yes
[14:25] <tyhicks> sharing data between two or more snaps
[14:25] <jdstrand> imagine a snap ships two commands
[14:26] <jdstrand> if they are supposed to share the same mount namespace, you need to make sure you do that right
[14:26] <tyhicks> oh, I wasn't thinking about sharing between two commands but that's true...
[14:26] <jdstrand> that isn't insurmountable
[14:26] <jdstrand> but then, like tyhicks said, if you have two snaps sharing data, things get complicated. 3, 4, more, etc
[14:26] <seb128> I didn't even know that snaps could share datas
[14:27] <seb128> I though they each had their own private dir
[14:27] <seb128> with maybe access to some "normal" system locations
[14:27] <jdstrand> by default, a snap gets private dirs that the commands use
[14:27] <tyhicks> jdstrand: they'd need to share the same mount namespace or the launcher would need to set up a bind mount for a shared area between the two commands
[14:28] <jdstrand> but interfaces will soon allow a snap from the same publisher to share data
[14:28] <jdstrand> and other interfaces might share data as well
[14:28] <jdstrand> tyhicks: yes
[14:28] <seb128> I see
[14:29] <jdstrand> tyhicks: let's explore this here for a moment (I know you and I have a meeting, but perhaps we can push it a moment)
[14:30] <seb128> jdstrand, tyhicks, do you know if there is any plan to try make some things available at their standard location (by bind mount, or whatever else)?
[14:30] <tyhicks> jdstrand: that's fine - I've been wanting to look into the possibility of a new mount ns some more anyways
[14:31] <jdstrand> seb128: yes-- that is what opengl does, there is already some bind mount stuff happening in the launcher
[14:31] <tyhicks> seb128: zyga and I will be working on adding the ability for interfaces to convey an fstab-like file so that the launcher will set up a series of bind mounts
[14:31] <seb128> oh, nice
[14:32] <seb128> tyhicks, is there a bug/blueprint/google doc about that?
[14:32] <tyhicks> seb128: not that I know of - we just discovered the need for it late last week at the snappy sprint
[14:32] <seb128> tyhicks, k, just curious on what cases did you find the need?
[14:33] <seb128> tyhicks, I can see that being useful for things like locales definitions, mimetypes, fonts, etc
[14:33] <jdstrand> tyhicks: I would think that planned work would fix these sorts of things in the same manner. I mean, in a way, we are effecting a new file namespace since we force commands to run within core's fs, then bind mount into it
[14:33] <tyhicks> seb128: opengl support requires it - AFAIK, the kernel snap needs to ship some libs that need to be bind mounted in known locations for app snaps to use
[14:34] <jdstrand> with newns, you create a blank one then bind mount into it
[14:34] <tyhicks> seb128: yes, fonts are another identified usage
[14:34] <seb128> great
[14:35] <tyhicks> jdstrand: yes, there's a lot of overlap here
[14:36] <jdstrand> tyhicks: ok, so, if we were going to implement newns now, what would it look like? then we can see what it would buy us and if it is appreciably different from the planned work
[14:37] <tyhicks> jdstrand: they're setting up a mount namespace where / is a private tmpfs
[14:38] <tyhicks> jdstrand: "/ is a private tmpfs not visible anywhere else. This is pivot_root:ed into so it is the new / and all other mounts from the host are unmounted from the namespace."
[14:39] <tyhicks> so they're setting up *everything* in the new mount namespace
[14:39] <jdstrand> right
[14:39] <jdstrand> that is flatpak
[14:39] <tyhicks> yes
[14:39] <jdstrand> that's fine
[14:40] <jdstrand> I'm trying to think if we were going to use newns, what would it look like so we can compare that to what we have and the planned bind mount work
[14:41] <tyhicks> if we're going to use a new mount namespace, we'd have to do something similar
[14:41] <jdstrand> sure
[14:41] <jdstrand> what would we mount into it?
[14:41] <jdstrand> I guess the core os snap
[14:41] <tyhicks> yes
[14:41] <tyhicks> possibly things from the kernel snap
[14:42] <tyhicks> (like opengl libs)
[14:42] <jdstrand> right
[14:42] <tyhicks> on classic, we'd mount in certain things that we'd want to use from the system, such as fonts
[14:42] <jdstrand> sure
[14:42] <jdstrand> what about HOME?
[14:43] <jdstrand> would one mount ~/snap/<name>/<version> as HOME?
[14:43] <tyhicks> yes, if the home interface was plugged in
[14:43] <jdstrand> ok, so not that
[14:43] <tyhicks> I'd think we'd use ~/snap/<name>/<version> by default or $HOME depending on the home interface being plugged in
[14:44] <willcooke> probably a stupid question, but.... could this be used to avoid shipping a whole Gtk in each Gtk app?  Like we could make the version shipping with classic available for use by snaps, and if you want something else (newer) then you ship it, or ship a snap with it in and then re-use that?
[14:44] <jdstrand> that could be weird since home isn't autoconnected-- you can imagine a snap starts unconnected, then writes files, then is connected, etc
[14:44] <jdstrand> willcooke: it could, but so could the planned work
[14:45] <willcooke> even better :)
[14:45] <jdstrand> willcooke: I think that is a different question. snaps are the way they are because they are supposed to be independent of the os
[14:45] <tyhicks> jdstrand: true - the operation of connecting the home interface would need to migrate data or warn that data will be lost
[14:45] <jdstrand> tyhicks: but let's assume that is fixed
[14:45]  * tyhicks nods
[14:46] <willcooke> jdstrand, sure, understood.  Just seeing if there is a potential work around to massive snaps for tiny apps.
[14:46] <jdstrand> tyhicks: so, my feeling is that we aren't really gaining anything-- we identified everything we are already doing or planning to do
[14:46] <jdstrand> the problem today is we aren't doing these other bind mounts
[14:46] <tyhicks> that may be true
[14:47] <jdstrand> let's for a moment assume that is true
[14:47] <jdstrand> what do we gain if we do newns? what do we lose?
[14:48]  * jdstrand is struggling to see what we gain since we are mounting large chunks of things into the newns so we still need fine-grained MAC
[14:48] <jdstrand> but we are possibly adding more complexity
[14:48] <tyhicks> the main difference is that we could prevent access to certain files/directories by simply not mounting them inside the new mount namespace instead of using AppArmor to mediate the access
[14:48] <jdstrand> tyhicks: so I was assuming that we would still wrap this in MAC
[14:49] <tyhicks> yes, we definitely would
[14:49] <jdstrand> right
[14:49] <jdstrand> so, what would we not mount?
[14:49] <jdstrand> in other words, what is a specific example of what we might gain?
[14:49] <tyhicks> well, since we said that we'd bind mount all of the os snap, everything would be mounted
[14:50] <jdstrand> so we could slice that up
[14:50] <tyhicks> we could
[14:50] <tyhicks> don't know if it gains us anything
[14:50] <jdstrand> or we could use what we already have
[14:51] <tyhicks> I'm in agreement that, at this time, there are no tangible benefits to using a new mount ns versus bind mount support in interfaces
[14:52] <jdstrand> ok, cool
[14:52] <jdstrand> I think I am at the same place
[14:52] <tyhicks> maybe we'll see something that we're missing when we do the bind mount work
[14:53] <tyhicks> I'll keep an eye out for anything like that
[14:54] <jdstrand> seb128, willcooke, desrt: so, the ease of the flatpak approach wrt to relocation compared to ours isn't a technical issue (ie, newns vs apparmor). currently what we are doing is similar to newns in a lot of ways, it is just that the planned bind mount/fstab work is not done yet
[14:55] <seb128> jdstrand, I didn't know we had such work planned, so that's good news
[14:56] <jdstrand> we could redo the fs setup and use the newns approach (wrapped with apparmor) and build up the bind mounts, but we can also just continue with the current fs setup and build up the bind mounts as planned
[14:56] <seb128> jdstrand, tyhicks, did that work start? is there a place where to follow the work/discussions?
[14:56]  * jdstrand defers to tyhicks 
[14:57] <jdstrand> I can say it came up last week at the sprint
[14:57] <tyhicks> seb128: I think zyga has started on his changes for snapd but I haven't started on my changes to ubuntu-core-launcher
[14:57] <seb128> k
[14:57] <seb128> well, in any case I guess we better wait on that then
[14:57] <tyhicks> seb128: it is on both of our lists for this week
[14:58] <seb128> rather than trying to patch glibc to make it loads locales from other custom dirs
[14:58] <tyhicks> seb128: if there's not a bug, I'll get one filed soon and point you to it
[14:58] <seb128> and other similar hacks we were considering
[14:58] <seb128> tyhicks, thanks
[14:58] <seb128> willcooke, ^ fyi
[14:58] <willcooke> yeah, sounds like good news all round
[15:00] <jdstrand> seb128: it sounds to me that the flatpak approach is sorta trying to also solve willcooke's question. you have a thick os that has your gtk libs, etc in it, and bind mount into the newns. snaps have a philosophical difference though in that snaps are supposed to be independent of the os. if we bind mount /usr/blah into the snap, then that snap is very much tied to a specific version of the os
[15:01] <jdstrand> so there is probably some discussions that need to happen with the snappy architects on these fronts
[15:01] <jdstrand> things I've heard about sdoc seem to be at odds with the 'snaps are independent' approach
[15:01] <seb128> jdstrand, willcooke, right, bundling gtk or not ... that's a different approach and I can see pro&con in each
[15:02] <seb128> I'm more concerned about things like having to bundle the glibc locales definitions
[15:02] <seb128> or fonts
[15:02] <jdstrand> I think there is probably a line that needs to be defined
[15:02] <seb128> but that should be fixed with the bind mount&interfaces
[15:02] <seb128> right
[15:03] <jdstrand> it seems that locales and fonts are fairly straightforward in the 'I need to use what is available on the system' line, but other things are less clear
[15:03] <jdstrand> like gschemas
[15:03] <jdstrand> anyhoo
[15:03] <jdstrand> interesting times
[15:05] <seb128> indeed
[15:05] <jdstrand> seb128, desrt, willcooke: hopefully this dispels any misconceptions that flatpaks are better in terms of relocation. I mean, they might be *today*, but the planned work is to not have as much reloaction pain
[15:05] <seb128> well, we at least have wrapper hacks for image loaders & schemas
[15:05] <seb128> jdstrand, it does, thanks
[15:05] <desrt> jdstrand: so if we move over to mount namespaces does that mean we can stop using apparmor for enforcement?
[15:06] <desrt> because that's sort of putting a cramp in our style in terms of advocating snaps as _the_ portable format for apps (since apparmor is not universal)
[15:06] <jdstrand> desrt: that is a funny takeaway, but I'll answer your question in the way you asked-- no, we will want to wrap in MAC
[15:06]  * jdstrand notes flatpak wants to use MAC as well
[15:06] <desrt> no.  it doesn't.
[15:07] <jdstrand> yes they do-- I just read about it
[15:07] <desrt> just had a call with them and they made it quite clear
[15:07] <jdstrand> then their docs are out of date
[15:08] <desrt> if they do use it it will only be in the way that apparmor/selinux are typically used today
[15:08] <desrt> ie: second line of defence against security breaches in apps
[15:08] <desrt> it will not in any way be used as a front-line confinement mechanism
[15:08] <jdstrand> snappy is more ambitious than flatpak as I read the current documentation. ie, they are using system namespaces to constrain apps. snaps may run root daemons and you can't constrain a root daemon with user namespaces
[15:08] <desrt> that's going to be entirely namespaces, seccomp, etc.
[15:08] <jdstrand> err
[15:08] <jdstrand> system namespaces
[15:09] <jdstrand> and user namespaces need a MAC as well considering all the security issues
[15:09] <Trevinho> xnox: hey, for that upstart / dbus work... It seems it really fixes stuff :-), so can you backport to xenial?
[15:09] <happyaron> seb128: need double check tomorrow
[15:09] <Trevinho> I think you told me the steps, but I forgot what to do :-)
[15:10] <desrt> jdstrand: i feel like we've been having this conversation for about 5 years...
[15:10] <Trevinho> pitti: so, this does the trick for me: http://pastebin.ubuntu.com/16475829/
[15:11] <desrt> i think neither of us have changed position at all during that time
[15:11] <jdstrand> the other thing a MAC does is provide very convenient fine-grained mediation which can be used in combination with a file namespace
[15:11] <Trevinho> together with an "hacked" usd that always check the last value before caching it
[15:13] <jdstrand> I don't really appreciate that comment-- the security team has given a lot of thought to namespaces and we are actually using them in snappy. the fact system namespaces (which flatpak uses) cannot be used to constrain root processes. that isn't just me-- there are plenty of selinux and docker guys who say the same thing
[15:13] <jdstrand> we must be able to constrain root, so we must have a MAC
[15:14] <jdstrand> but we want to use namespace technologies in combination with a MAC
[15:14] <jdstrand> that gives the best of both worlds in terms of security
[15:14] <jdstrand> and sets us up for user namespaces (which in the last 5 years have literally had scores of CVEs attributed to them)
[15:16]  * jdstrand notes that docker, lxc and lxd *also* use MAC in combination with namespaces. they work great together and offer a lot of flexibility
[15:20] <pitti> seb128: if you are in a position to test (sorry, I'm not right now), I attached two patches to the upstream bug; the first one is the important one
[15:21] <seb128> pitti, did you need/want desrt's input on the topic?
[15:21] <pitti> seb128: it's now much clearer, but one question remains indeed
[15:22] <pitti> desrt: is it a common or at least acceptable pattern that my_gobject_new() returns NULL on failure?
[15:22] <desrt> only if the object in question is a subclass of GInitable
[15:22] <pitti> desrt: in particular, should libupower-glib's up_client_new() return NULL if it can't connect to upowerd via dbus?
[15:22] <desrt> er.  implements.
[15:23] <pitti> otherwise, how would a client know that the returned object is useless/broken?
[15:23] <desrt> pitti: the normal pattern here is to make this thing GInitable and GAsyncInitable and use those interfaces to implement a sync and async version of the constructor... both with cancellables, and both failable
[15:23] <pitti> UpClient does not implement GIinitable
[15:23] <desrt> then instead of using g_object_new() inside of your _new() you use g_initable_new()
[15:23] <desrt> ditto for the _new_async()
[15:24] <desrt> if the constructor can fail, then it ought to
[15:24] <desrt> this is practically a "by definition" sort of thing
[15:24] <pitti> yeah, it's more ore less a gdbus wrapper around upower's d-bus API
[15:25] <desrt> sounds perfect, then
[15:25] <desrt> GDBusProxy, itself, is async-initable
[15:25] <desrt> if you did g_dbus_proxy_new_for_bus() then it would be a one-step operation for you
[15:26] <desrt> (you could even do subclassing, but imho that would be pretty gross)
[15:26] <pitti> desrt: so the patch on freedesktop bug 95350 is bad because UpClient doesn't implement GInitable?
[15:26] <pitti> well, it *has* a GDbusProxy thing in its private class members, but it is not by itself a GInitable
[15:27] <desrt> that's how you should be doing it, indeed
[15:27] <pitti> the _init() does priv->proxy = up_exported_daemon_proxy_new_for_bus_sync(...)
[15:28] <desrt> this is definitely evil.
[15:28] <desrt> _init() should not block
[15:28] <pitti> and that function is autogenerated code from that gdbus-binding-tool
[15:28] <desrt> !!
[15:28] <desrt> seriously?
[15:29] <desrt> the tool codegens code that does blocking IO in an init function?
[15:29] <pitti> _init() isn't autogenerated
[15:29] <pitti> up_exported_daemon_proxy_new_for_bus_sync() is
[15:29] <desrt> ah.  ya.  that makes sense.
[15:30] <willcooke> zut alors!  It's team meeting time...  I have to leave in 30 mins, so desrt pitti ok to interupt you?
[15:30] <pitti> what should block then? _new()?
[15:30] <pitti> willcooke: sure, sorry
[15:30] <willcooke> pitti, no no, sorry to jump in
[15:30] <willcooke> oki
[15:30] <seb128> just move them to #ubuntu-devel
[15:30] <seb128> ;-)
[15:31] <willcooke> #startmeeting Desktop Team Weekly Meeting - 2016-05-17
[15:31] <meetingology> Meeting started Tue May 17 15:31:05 2016 UTC.  The chair is willcooke. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:31] <meetingology> Available commands: action commands idea info link nick
[15:31] <willcooke> Roll call: andyrock, attente, desrt,  dgadomski, fjkong(out), happyaron, hikiko, laney, qengho, seb128, sweet5hark, themuso (out), tkamppeter(out), trevinho, robert_ancell (out)
[15:31] <desrt> pitti: do you want me to try to do a patch for this?
[15:31] <desrt> willcooke: o/
[15:31] <andyrock> o/
[15:32] <seb128> hey
[15:32] <Trevinho> \o
[15:32] <Sweet5hark> heya
[15:32] <dgadomski> o/
[15:32] <willcooke> that'll do to get started
[15:32] <willcooke> #topic andyrock
[15:33] <andyrock> # proposed a fix for the bug about the newly installed application not appearing on the dash
[15:33] <andyrock> # started working on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1582433 just because I've aleady everthing setup to work on it
[15:33] <seb128> andyrock, I saw your ping, just didn't have slots to go back to that yet, let me know if you need sponsoring (need to see if libunity and gnome-menus needs to land in locked steps)
[15:34] <andyrock> # bug traging
[15:34] <andyrock> *triaging
[15:34] <andyrock> # reviews
[15:34] <andyrock> # eof
[15:34] <willcooke> thanks andyrock
[15:34] <willcooke> #topic attente
[15:34] <andyrock> seb128: yeah i may need sponsoring
[15:34] <seb128> let's discuss that after the meeting
[15:34] <attente> hi, was at the snappy sprint last week
[15:34] <attente> looked into how to add featured snaps to the overview shell of gnome-software
[15:34] <attente> debugging some theming issues and menus in snaps for qt applications
[15:35] <attente> looked into https://bugs.launchpad.net/snappy/+bug/1580740, did a proof of concept fix with didrocks
[15:35] <attente> uploaded gnome-software rebased to 3.20.2 to a ppa, could use a lot of testing: https://launchpad.net/~attente/+archive/ubuntu/gnome-software
[15:35] <attente> (eof)
[15:35] <willcooke> thanks attente
[15:35] <willcooke> welcome back home :)
[15:35] <attente> thanks :)
[15:35] <willcooke> #topic desrt
[15:35] <seb128> attente, hey, wb! hope it was a good week, glad you made it back ;-)
[15:35] <desrt> o hai!
[15:35] <attente> seb128: lol
[15:36] <desrt> having a pretty interesting week.  got caught up on some glib reviewing last week, and this week i'm being pulled into a couple of new and interesting directions
[15:36] <desrt> going to look at the possibility of using jhbuild to get more up-to-date versions of apps into snaps, while at the same time resolving all of the hardcoded-path issues that we keep running in to based on using .debs
[15:37] <desrt> also had a really interesting conversation with alex just now about dconf in confined apps... have a clearer sense of direction now
[15:37] <desrt> and for the rest of today i'm probably helping pitti make a much more complicated patch than he needs to for upower
[15:37] <desrt> eof.
[15:37] <willcooke> thanks desrt
[15:37] <willcooke> did you ever make headway with that bug btw?
[15:38] <willcooke> #topic dgadomski
[15:38] <dgadomski> hey
[15:38] <dgadomski> * more Samba debugging - turned out that 2 more users hit bug 1576109 - fortunately there already was a fix to that in a ppa
[15:38] <dgadomski> * still waiting for input to examine the kerberos auth samba bug I mentioned last week, so I'm stuck with this
[15:38] <dgadomski> * researching possible fixes for bug 1578398 - prepared debdiffs with a temporary workaround for concerned users
[15:38] <dgadomski> eof
[15:38] <willcooke> thanks dgadomski
[15:38] <dgadomski> thanks
[15:39] <willcooke> #topic FJKong
[15:39] <willcooke> 1 do research on how to display candidate word window vertically,
[15:39] <willcooke> 2 continue on animated skin work of sogou im.
[15:39] <willcooke> 3 tracking bug : wrong position of candidate words window on firefox
[15:39] <willcooke> eof
[15:39] <willcooke> #topic happyaron
[15:39] <happyaron> hey
[15:39] <happyaron> 1. Update NM (and some friends) 1.2.2 for yakkety and 1.2.0 for xenial
[15:39] <happyaron> 2. Work with OEM people for NM related issues
[15:39] <happyaron> eof
[15:39] <willcooke> thanks happyaron
[15:39] <willcooke> #topic hikiko
[15:39] <hikiko> hello
[15:39] <hikiko> - working on this nasty bug in multimonitor: if we have two outputs o1 and o2, when the rendering is done in o2 and the components of o2 are scaled, some parts of the o1 appear in both outputs (eg o1's panel appears without artifacts in o1 but a part of it reappears scaled in o2). This indicates that there's either a problem in our 2D clipping (parts of o1 that should be clipped still appear and follow the o2 transformations) or that for some
[15:39] <hikiko> reason we render in all outputs when we should only render in one. (what happens at the end is that compiz renders things per output but nux renders things in the whole screen).
[15:39] <hikiko> - fixes in ezoom damage, +added signals to damage components only when there's a change in zoom transform
[15:39] <hikiko> - a fix in expo, scale branch (merged by marco)
[15:39] <hikiko> - a brief look at the vm issues - tasks
[15:39] <hikiko> EOF
[15:40] <willcooke> thanks hikiko
[15:40] <willcooke> #topic Laney
[15:40] <Laney> hi
[15:40] <Laney> • Got PagerDuty working for appstream monitoring, now I get called, texted and emailed when it stops updating!
[15:40] <Laney> • Send upstream fixes to move the 'show-weekdate' setting to a new key in gsettings-desktop-schemas
[15:40] <Laney> • A few updates/SRUs: glib, glib-networking gvfs
[15:40] <Laney> • Fix to gnome-calendar goa activation
[15:40] <Laney> • Start working on gtk 3.20 theme changes, going to be a few days worth of work there at least
[15:40] <Laney> • Help with reviewing/tweaking job description for new hires
[15:40] <Laney> 𝇛
[15:40] <willcooke> thanks Laney
[15:41] <willcooke> #topic qengho
[15:41] <qengho> * Finished with chromium 50.0.2661.102. Yes. Version 50. Gave to #security for upload.
[15:41] <qengho> * Didn't get appstream included in Chromium yet. Sorry, Laney. Maybe later.
[15:41] <qengho> * To-do: Figure out most recent SIGILL on snap of Google Chrome/Chromium. Could be some hidden SECCOMP fiddling.
[15:41] <qengho> EOF
[15:41] <willcooke> thanks qengho
[15:41] <willcooke> #topic seb128
[15:41] <qengho> And Laney, I made a kind of dead-man's-switch for notifications when a machine stops working.
[15:41] <seb128> • had monday off
[15:41] <seb128> • debugged usd/upower segfault, reduced to a simple upower example, filed upstream bug
[15:41] <seb128> • looked at the versions page not updating and restored the service
[15:41] <seb128> • joined discussion about using systemd user sessions in y
[15:41] <seb128> • SRUed a brasero update to fix translations and libdvdcss loading
[15:41] <seb128> • helped willcooke to debug missing speaker icon issue
[15:41] <seb128> • removed non working "browse files..." buttons from bluetooth settings/indicator
[15:41] <seb128> • webkitgtk 2.4.11 bugfix update+SRU
[15:41] <seb128> • backported u-s-d fix for keyboard backlight status on login
[15:41] <seb128> • some snappy discussions
[15:41] <seb128> • triaging of incoming launchpad/errors reports

[15:42] <willcooke> thanks seb128
[15:42] <willcooke> #topic Sweet5hark
[15:42] <Sweet5hark> - short week (monday was holiday here)
[15:42] <Sweet5hark> - some upstream mentoring/codereview for GSoC work on my hometurf
[15:42] <Sweet5hark> - work on snapcrafting 5.2 alpha
[15:42] <Sweet5hark> - still/again seeing weird linking/header foo with building NSS => investigating
[15:42] <Sweet5hark> EOF
[15:43] <willcooke> thanks Sweet5hark
[15:43] <willcooke> #topic TheMuso
[15:43] <willcooke> please let me have your update TheMuso, unless I've deleted by accident
[15:43] <willcooke> #topic tkamppeter
[15:43] <willcooke> - Google Summer of Code 2016: Guide students to get started with their projects
[15:43] <willcooke> - lsb package: Re-introduced the LSB compatibility binary packages Ubuntu-only to fix incompatibility of Ubuntu 16.04 with Epson's printer drivers (bug 1536353).
[15:43] <willcooke> - cups-browsed: Adding debug log file generation to more easily investigate bugs, especially problems during system boot and shutdown, like bug 1579905.
[15:43] <willcooke> - Bugs.
[15:43] <willcooke> #topic Trevinho
[15:44] <Trevinho> · New landing for bamf, compiz, unity, unity settins daemon
[15:44] <Trevinho> · Created xenial branches for bamf, compiz, unity, u-s-d
[15:44] <Trevinho> · Fixed build failures for unity in yakkety
[15:44] <Trevinho> · Reviews for lots of compiz community contributions (yay!) and unity
[15:44] <Trevinho> · New unity upstream release 7.4.0 is out (compiz will follow soon)
[15:44] <Trevinho> · u-s-d improvements for keyboard backlight support
[15:44] <Trevinho> · UPower patch for getting proper keyboard brightness, instead of the cached one
[15:44] <Trevinho> · Built a small snapcraft build plugin to make possible to patch upstream code
[15:44] <Trevinho> · Made hello-unity snap working, making building of gtk/gdk/minecaches dynamic on first start
[15:44] <Trevinho> · Snapcrafted a simple electron app (working only unconfined, for now)
[15:44] <Trevinho> · Fixed two crashes in unity7
[15:44] <Trevinho> · Preapared PPAs for gnome-terminal and emacs windows restoration fix.
[15:44] <Trevinho>  /EOF
[15:44] <willcooke> BOOM!
[15:44] <willcooke> thanks Trevinho
[15:44] <willcooke> #topic robert_ancell
[15:44] <willcooke> - GNOME package updates / filing bugs with excuses
[15:44] <willcooke> - Fix up versions page [1] to track correct versions
[15:44] <willcooke> - Paid snap work
[15:44] <willcooke> #topic willcooke
[15:44] <willcooke> Unprepared...
[15:45] <willcooke> Make tabs bug SRU compliant
[15:45] <willcooke> Helped fix missing speaker icon
[15:45] <willcooke> #Politics
[15:45] <seb128> willcooke, was the [1] from robert_ancell pointing to some url?
[15:45] <willcooke> http://people.canonical.com/~platform/desktop/versions.html
[15:45] <willcooke> seb128, sorry
[15:46] <willcooke> erm, can't remember what else, sorry, have to leave in a second
[15:46] <willcooke> oh, worked with recruitment to get them up to speed on the hires
[15:46] <willcooke> Laney helped with the JD so we will start getting CVs soon
[15:46] <willcooke> \o/
[15:46] <seb128> sorry, I didn't managed to reply to that today, got caught up with backlog and meetings
[15:46] <seb128> on my list for tomorrow
[15:46] <willcooke> seb128, no worries
[15:47] <willcooke> #topic Any Other Business
[15:47] <seb128> I'm trusting Laney for giving good feedback though ;-)
[15:47] <willcooke> :)
[15:47] <willcooke> anyone got bidnezz?
[15:47] <willcooke> going
[15:48] <willcooke> going
[15:48] <willcooke> gone
[15:48] <willcooke> #endmeeting
[15:48] <meetingology> Meeting ended Tue May 17 15:48:19 2016 UTC.
[15:48] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2016/ubuntu-desktop.2016-05-17-15.31.moin.txt
[15:48] <willcooke> thanks everyone
[15:48] <seb128> thanks!
[15:48] <willcooke> Got to go out now, but telegram if I can help with anything
[15:48] <seb128> have fun!
[15:49] <Laney> you can help me get a 99 flake
[15:49] <willcooke> Laney, from the ice cream man, or a fake one from the supermarket
[15:49] <willcooke> http://www.tesco.com/groceries/Product/Details/?id=251821479
[15:50] <Laney> hah
[15:50] <Laney> my browser won't even load tesco's css
[15:50]  * Laney high fives firefox
[15:51] <Laney> waitrose.com works though :) :) :) :)
[15:51] <willcooke> :D
[15:52] <Sweet5hark> willcooke: are JDs online? if so, do you have a link?
[15:56] <willcooke> Sweet5hark, not online yet, probably tomorrow
[15:56] <willcooke> will send you a link
[15:56] <Sweet5hark> willcooke: awesome, thanks!
[16:01] <Laney> ah the fun of an initial offlineimap sync
[16:02] <seb128> happyaron, hum, was https://launchpad.net/~happyaron/+archive/ubuntu/network-manager were you had the 1.2.2 update ready? did you superseed it with another update? also did you do the other sources, gnome/vpn/...?
[16:07] <seb128> happyaron, also why did you rename patches? need to undo that for the SRU or the diff is going to be harder to review
[16:08] <happyaron> seb128: will maintain a seperate branch for xential SRU, in yakkety I switched to use gbp-pq to manage the patch queue
[16:09] <happyaron> seb128: https://launchpad.net/~happyaron/+archive/ubuntu/ppa/+sourcepub/6431454/+listing-archive-extra
[16:09] <seb128> happyaron, is debian using that?
[16:09] <seb128> or is that increasing diff?
[16:10] <seb128> I never use gbp so I can't comment on how much of a win that is
[16:11] <mitya57> The -gnome part of the new NM is the most interesting because upstream integrated our indicator stuff
[16:12] <happyaron> seb128: plan to sell that, there are quite a lot of projects using gbp-pq in debian though
[16:12] <seb128> mitya57, that's already true in 1.2.0 no?
[16:13] <seb128> happyaron, ok, you are maintaining it so your call ... do you have updates for -gnome/vpn/etc? ;-) I guess nm 1.2.2 works fine with the others still being on 1.2.0/you are testing that?
[16:13] <happyaron> seb128: it's basically the same diffs, but managed by git patch queues
[16:13] <mitya57> Oh yes, I missed that we already have 1.2.0 :)
[16:13] <happyaron> seb128: will update most of them by this weekend
[16:14] <seb128> mitya57, :-)
[16:15] <seb128> happyaron, thanks, just to confirm you tested n-m 1.2.2 with applet 1.2.0 and it works right? good to upload? ;-)
[16:17] <happyaron> yes that works
[16:17] <seb128> happyaron, good, I'm sponsoring it, thanks for the work! when you update -gnome please backport the commit I pointed earlier ;-)
[16:17] <happyaron> no problem
[16:19] <happyaron> time to bed, cy
[16:19] <seb128> happyaron, night!
[16:25] <Trevinho> pitti: https://bugs.freedesktop.org/show_bug.cgi?id=95457 I've pinged also hughsie about that
[17:15] <Laney> nn!
[17:16] <seb128> Laney, have a good evening!
[17:16] <seb128> other desktopers as well ;-)
[17:16] <seb128> time for dinner and sport here
[19:29] <cinch> where can i find a kernel for 16.04 with the BFQ scheduler?
[19:30] <cinch> the "ck" patchset
[19:32] <sarnold> cinch: I don't think I've seen any ppas for it; I think if you want it you have to build it yourself
[19:34] <cinch> hmm ok
[19:35] <cinch> i think ill try other things first
[19:35] <cinch> im concerned with latency on the desktop, alt+tab takes awhile compared to windows 10
[19:35] <cinch> using ubuntu mate with the default software compositor
[19:36] <cinch> and in general its not as "snappy"
[19:38] <sarnold> I would seriously hope alt-tab doesn't need to hit the disk :)
[19:38] <cinch>  :-D
[19:38] <sarnold> if it does there are problems elsewhere that need addressing rather than whatever IO scheduler is in use :)
[19:38] <cinch> yeah
[19:38] <cinch> firefox has screen tearing when i scroll..
[19:39] <cinch> using the non_gnu Nvidia driver
[19:39] <cinch> oh well, linux woes as usual ;)
[19:40] <cinch> interestingly, on my old thinkpad x200s it's super snappy
[19:40] <cinch> with intel on board graphics, core 2 duo
[19:41] <cinch> but this monster core i5 2500k with a nvidia gtx 760 has issues :P
[19:43] <cinch> i solved it: -> in "Mate Tweak" -> change the window manager to compiz
[19:43] <cinch> easy :-)
[19:43] <sarnold> yeah, my intel onboard on my ~3.5 year old laptop is super-snappy doing virtual desktop changes, no tearing with firefox scrolling, etc., but I understand newer intel drivers don't have the quality of the old intel drivers :( and what with their recent "lay off ALL the employees" binge, it's hard to imagine their driver quality improving :(
[19:43] <sarnold> hah, nice
[19:44] <cinch> oh i didnt know that about newer intel drivers
[19:44] <cinch> they layed off alot of workers
[19:45] <cinch> now i just need to get reliable suspend/resume
[19:45] <cinch> when i suspend, the monitor doesnt go into standby
[20:24] <cinch> d'oh compiz crashed :)
[20:35] <cinch> let's say i want to log each process that was started (with its command line parameters), how would i go about it
[21:42] <sarnold> cinch: you've got a few choices here :) auditctl should be able to log executions, but it may not get arguments; old-school unix process accounting should also be able to get e.g. summaries of executions _after_ the processes have exited; the execsnoop program from https://github.com/iovisor/bcc can give you exactly what you wanted, but it's not in the archive so it requires a bit more work to install it and use it
[22:02] <cinch> sarnold, tyvm