[07:48] <pitti> Good morning
[07:49] <didrocks> hey pitti!
[07:52] <pitti> bonjour didrocks, ça va ?
[07:53] <pitti> uff, I slept looong today
[07:53] <didrocks> on fait aller, et toi? :)
[07:53] <pitti> waking up at 3 one day, at 9 at the other
[07:54] <pitti> didrocks: otherwise, quite okay
[07:54] <didrocks> urgh, indeed, not even time…
[08:46] <Sweetshark> moin
[08:52] <Mirv> Trevinho: impressive stuff with hidpi btw! I'm glad it could be achieved to some extent, it's better than tell "well we'll have this Unity 8 in 16.04 LTS"
[08:53] <hikiko> seb128, good morning
[08:53] <Trevinho> Mirv: indeed... I know it was feasible, and well... it's a reality now... unfortunately not all the apps scale as they should but the shell will be  at least
[08:53] <hikiko> https://code.launchpad.net/~hikiko/unity-control-center/unity-control-center.bug-warning-fixes/+merge/208162 that's ready
[08:57] <Mirv> Trevinho: yep, better something than nothing. I guess it becomes more hacky the further one tries to solve it though, like installing an extension to Firefox and making it listen to the scale factor :)
[08:58] <Mirv> anyhow, nice
[09:00] <seb128> good morning desktopers
[09:00] <seb128> hey hikiko, Trevinho, Mirv, Sweetshark
[09:01] <hikiko> hahaha we were all waiting for you seb128 !!!
[09:01] <seb128> lol
[09:01] <seb128> hikiko, thanks for the branches, adding that to my list for the day
[09:02] <hikiko> seb128, I will submit another with the builder but since it's not urgent (it's just a coding style fix) I will do it a bit later
[09:02] <Sweetshark> seb128: ;) -- do you have the libreoffice-dicts still on the map?
[09:02] <Laney> morning
[09:03] <seb128> Sweetshark, yeah, sorry yesterday was busy (and we are beta frozen), going to do that today
[09:03] <seb128> Laney, hey, how are you?
[09:04] <seb128> hikiko, ok
[09:04] <Sweetshark> seb128: np
[09:05] <Mirv> hey seb128
[09:06] <Laney> seb128: good thank you!
[09:06] <Laney> you?
[09:07] <seb128> I'm good, thanks
[09:10] <Laney> you got a hidpi laptop right?
[09:10] <seb128> no
[09:10] <Laney> oh ok
[09:10] <seb128> those were too expensive, we got a bunch of cheap touch ones
[09:11] <seb128> why?
[09:11] <Laney> https://bugs.launchpad.net/unity/+bug/1282804/comments/2
[09:11] <ubot2> Launchpad bug 1282804 in Unity "[FFe] Move DPI settings over to use u-c-c settings." [Medium,In progress]
[09:11] <Laney>  Even GTK-based applications become pretty much unusable if it is set to anything but 1
[09:11] <Laney> seems curious to me
[09:11] <seb128> you can "fake" hidpi with xrandr --output <output> -- scale <n>x<n>
[09:12] <seb128> hum
[09:12] <seb128> let's talk with bregma when he gets online
[09:13] <seb128> or maybe hikiko or Trevinho knows what he means there
[09:13] <Laney> I just acked that ffe anyway
[09:13] <Laney> can do other work there later on if needed
[09:14] <seb128> right
[09:14] <seb128> thanks for that
[09:14] <hikiko> oh yes
[09:14] <hikiko> seb128, and Laney
[09:14] <hikiko> I had a string gsetting in unity
[09:14] <hikiko> before the requirements changed
[09:14] <hikiko> in unityshell gschema
[09:14] <Trevinho> Laney: that setting for now only controls unity, but I plan to add scale gtk apps also... based on our settings
[09:15] <hikiko> and then I replaced that with the GVariant dict we had in control center
[09:15] <hikiko> and didnt remove the old one
[09:15] <hikiko> it's fixed now
[09:15] <Laney> Trevinho: that comment basically says that the gtk scaling is bad though?
[09:15] <seb128> hikiko, I think the topic discussed there is different, it's basically making the slider writes the GTK setting as well
[09:15] <hikiko> oh sorry new bug
[09:16] <seb128> Laney, I think Trevinho wants to "teach GTK about their non-int-based scaled"
[09:16] <seb128> -d
[09:16] <seb128> Trevinho, still set on trying to do that? ;-)
[09:16] <Laney> good luck convincing upstream
[09:16] <seb128> well, I don't think upstream needs "convincing", it's more a technical issue there
[09:17] <Trevinho> Laney: well, it's not bad, but to get best results we need to mix the scaling value with text scaling...
[09:17] <seb128> the int-based scale is suboptimal but there are probably non-trivial technical reasons to it
[09:18] <Trevinho> yeah, there are, but still we can get a scaling by using both ui scale and text scale... So basically we use our integer scaling part for the GTK scaling, and then we set the text-scaling so that multiplied for the integer scaling equals our float scaling..
[09:19] <Laney> http://lwn.net/Articles/562287/ is what I read
[09:19] <hikiko> well, what I was thinking was to just use a float scale (slider) and when the value is selected, just save 1 float gsetting for unity 7 as it was before and 1 int (rounded and x8) for unity8
[09:19] <seb128> seems a reasonable approach to me
[09:19] <hikiko> and each app can use the more convenient
[09:23] <seb128> Laney, btw unity with hidpi on is in https://launchpad.net/~ci-train-ppa-service/+archive/landing-012/ if you want to test
[09:23]  * seb128 going to test that in a bit
[09:23] <Laney> can do, to check everything stays the same
[09:26] <seb128> Trevinho, btw did you see https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1055166/comments/6 ?
[09:26] <ubot2> Launchpad bug 1055166 in unity (Ubuntu) "compiz crashed with SIGSEGV in memmove() from drisw_update_tex_buffer() from dri_set_tex_buffer2() from operator() from compiz::opengl::bindTexImageGLX() from ... from unity::UnityWindow::DrawWindowDecoration" [High,Triaged]
[09:27] <seb128> Trevinho, seems like the unity decorations make llvmpipe unhappy, that has a pointer where a similar bug that was fixed in compiz decorations before
[09:27] <Trevinho> seb128: mhhm
[09:28] <seb128> Trevinho, https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1284536 is the same issue reported by jibel, seems to be hit often by the QA tests
[09:28] <ubot2> Launchpad bug 1284536 in compiz (Ubuntu) "compiz crashed with SIGSEGV in two_way_long_needle()" [High,Confirmed]
[09:30] <seb128> Trevinho, mlankhorst started having a look to drisw yesterday and said there is a bug there, but the code his an error when doing a XGetGeometry call or something like
[09:31] <seb128> mlankhorst, still looking at that issue btw?
[09:31] <Trevinho> seb128: mhmh... I see... I could try to use the same way was used before...
[09:31] <seb128> one way or another we need to fix it
[09:31] <seb128> if mlankhorst can fix the bug in drisw, great
[09:32] <seb128> otherwise doing the same workaround than compiz had would be nice
[09:32] <mlankhorst> seb128: yeah but I got a maxwell card now, playing with it a little on nouveau :P
[09:32] <seb128> mlankhorst, important bug fixes first, playing then, please ;-)
[09:33] <mlankhorst> hwe is an important bug ;D
[09:33] <seb128> hehe
[09:33] <seb128> well, I'm sure the QA guys would appreciate if you could fix the compiz/drisw issue
[09:40] <Laney> yay
[09:41] <Laney> with the latest fixes u-s-s updating works
[09:41] <seb128> nice!
[09:44] <Laney> just one small bug
[09:54] <hikiko> well finally that gvariantbuilder was a really small change so I pushed the fix
[09:54] <seb128> hikiko, great!
[09:58] <seb128> pitti, hey, have you seen https://code.launchpad.net/~psusi/ubuntu/trusty/udisks2/fix-standby/+merge/206951 (just checking if you did, it's in the sponsoring queue and looks like something for you)
[09:59] <pitti> seb128: I did, it's sitting in my mailbox; it's just utterly big, so certainly not something which we want to carry as a patch
[10:00] <pitti> ah no, that's just the .pc madness, go UDD
[10:00] <seb128> pitti, I was going to say
[10:00] <seb128> it's a few liners
[10:01] <pitti> seb128: either way, it's on my TODO list; I'll verify and apply it upstream, and sponsor
[10:01] <seb128> pitti, danke!
[10:23] <pitti> seb128: replied on the ML and in the MP/bug
[10:23] <seb128> pitti, danke
[10:32] <mlankhorst> ugh that error doesn't make sense..
[10:32] <mlankhorst> why would I get BadRequest on XGetGeometry
[10:41] <xnox> unity8-desktop-session-X starts in phone resolution, instead of full screen.
[10:41] <xnox> unity8-desktop-session-mir doesn't start at all for me at the moment, investigating.
[10:45] <seb128> happyaron, hey, what happened to the ibus-pinyin update?
[10:45] <seb128> happyaron, also https://bugs.launchpad.net/ubuntu/+source/ibus-anthy/+bug/1279845
[10:45] <ubot2> Launchpad bug 1279845 in ibus-anthy (Ubuntu) "ibus-anthy sets to jp keyboard layout forcibly." [Undecided,New]
[11:20] <mlankhorst> ugh
[11:20] <mlankhorst> any idea why XGetGeometry could fail with BadRequest?
[11:21] <seb128> no idea sorry, maybe try asking on some xorg channel?
[11:22] <mlankhorst> shrug, that seems to be the real issue here
[11:24] <mlankhorst> oops nm :P
[11:48] <bregma> xnox, if you're trying to run unity8-desktop-session-mir you'll need the patched mir and qtubuntu packages from ppa:unity8-desktop-session-team/custom until the respective maintainers decide to land the required bugfixes
[11:50] <bregma> unity8-desktop-session-X runs in the phone form factor because that's it's default size without a desktop shell to run under on X11
[11:55] <mlankhorst> compiz (core) - Debug: stacks are out of sync
[11:55] <mlankhorst> what's this?
[11:58] <xnox> bregma: can you please get all of those into qt5.2 ppa ? as i'm testing qt5.2.
[11:59] <xnox> bregma: also for a -DESKTOP- session, on the desktop, full screen / tablet makes more sense as a default. Note that for 14.04 we will not ship both phone/touch/tablet and desktop modes together, thus the two should be able to have different defaults.
[11:59] <xnox> bregma: and even when it starts in phone shell by default, there is no window manager to resize it into full screen.
[12:00] <xnox> (and or provide a config file or something)
[12:04] <bregma> xnox, there is no way to tell it to resize to fullscreen without it getting the size of the screen from the desktop shell it's running on -- blame the QPA maintainers I guess, they're trying to run a phone emulator or something
[12:05] <xnox> bregma: what does QPA stand for again?
[12:05] <bregma> xnox, somthing about Qt platform abstraction
[12:07] <xnox> bregma: so at the moment we have 3 hacks that I know of, with respect to screen size, in autopilot there is hard-coded list of screen resolutions, or "$ fbset -s" is queried to get the resolution.
[12:07] <xnox> bregma: there is also mirout tool to get the screen resolution.
[12:07] <xnox> bregma: i presume both of these are low level API.
[12:10] <bregma> xnox, they could also use xrandr, since it's running on X, but there's going to be a lot of code to write to get something we're not really planning to support long-term
[12:11] <bregma> we only plan to support unity8 on Mir long-term
[12:12] <xnox> bregma: right, but i don't think it would be a lot of code. Does unity8 at all supports command line args?
[12:13] <xnox> bregma: and how does unity8 on the phone ends up with correct resolution? (e.g. mako vs nexus 10)
[12:13] <mlankhorst> seb128: heh, not sure if it's a mesa problem any more, adding a xsync(dpy, true) before the failing call fixes it..
[12:13] <seb128> mlankhorst, so unity bug you think?
[12:14] <seb128> Trevinho said he can add the same workaround that was in the old decorator I think
[12:14] <seb128> Trevinho, ^ right?
[12:15] <mlankhorst> seb128: I don't know where the bug is, but I don't think it's in mesa
[12:16] <seb128> k
[12:16] <seb128> thanks for work you did investigating
[12:19] <Sweetshark> hmm, when I try to select a gnome-fallback guest session, I still get a unity guest session. known issue?
[12:19] <seb128> yes
[12:20] <xnox> bregma: also, it doesn't appear to be upstart managed desktop session, which is odd.
[12:20] <seb128> Sweetshark, though I don't find a bug report, so if you want to open one, feel free
[12:21] <seb128> Sweetshark, I mentioned it to robert_ancell in London, but a bug would be better for tracking
[12:21] <Sweetshark> ... and curiously the patch I applied on trusty/LO 4.2 packaging doesnt work. But it when I backported it to precise/LO 3.5 it works. :/
[12:21] <Sweetshark> seb128: what target package? lightdm?
[12:22] <seb128> Sweetshark, yeah, https://launchpad.net/ubuntu/+source/lightdm/+filebug
[12:22] <xnox> bregma: if i login into normal unity session, and do "unity8 -fullscreen" it looks nice and big.
[12:22] <bregma> xnox, if you log in to Unity7 and run Unity8, you have a desktop shell to tell it the screensize
[12:23] <bregma> probably the best solution is to remove the unity8-desktop-session-x11 package, reduce confusion
[12:23] <xnox> bregma: right. I guess i don't understand the concept of "shell" then.
[12:23] <xnox> bregma: well -x11 one at least works at the moment for me, where as -mir one fails to start.
[12:23] <xnox> bregma: is "shell" ~= window manager?
[12:26] <Sweetshark> seb128: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1285132 <- done
[12:26] <ubot2> Launchpad bug 1285132 in lightdm (Ubuntu) "guest session ignores session type selection" [Undecided,New]
[12:26] <bregma> xnox, yeah, window manager
[12:26] <seb128> Sweetshark, thanks
[12:30] <bregma> xnox, where's the qt5.2 PPA?  I can try uploading the patched qtubuntu and mir packages you need (or you could grab the code from https://code.launchpad.net/~unity8-desktop-session-team)
[12:31] <xnox> bregma: and in -mir session window manager / shell is mir. Hence in the -x11 something like compiz needs to be started as well. Which would be trivial to do if the whole -x11 is upstart managed (we have compiz user-session upstart job to start things)
[12:32] <xnox> bregma: https://lists.launchpad.net/ubuntu-phone/msg05681.html https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+packages
[12:32] <xnox> bregma: that also has qtubuntu patches for qt 5.2
[12:33] <xnox> bregma: not sure if timo idles here or not, cause coordinating the two would be good.
[12:33] <bregma> xnox, Mir is the display server: when Unity8 is running on the mirserver QPA, it is the desktop shell
[12:34] <xnox> bregma: oh, i see. ok.
[12:45] <seb128> Sweetshark, hum
[12:45] <seb128> Sweetshark, http://ftp.rezopole.net/tdf/libreoffice/src/4.2.1/libreoffice-dictionaries-4.2.1.1.tar.xz gives me an error
[12:45] <seb128> Sweetshark, well, http://download.documentfoundation.org/libreoffice/src/4.2.1/libreoffice-dictionaries-4.2.1.1.tar.xz
[12:45] <seb128> that redirects to that url that doesn't work
[12:47] <Sweetshark> seb128: hmm, using that link from the webpage seems to work. maybe just retry to get another mirror?
[12:47] <seb128> Sweetshark, I tried 15 times in wget and firefox
[12:47] <seb128> I always get the same mirror
[12:47] <seb128> Sweetshark, can you give an url for another mirror? ;-)
[12:47] <Sweetshark> seb128: I get http://ftp.rz.tu-bs.de/pub/mirror/tdf/tdf-pub/libreoffice/src/4.2.1/libreoffice-dictionaries-4.2.1.1.tar.xz which works
[12:48] <seb128> that indeed works
[12:48] <Sweetshark> seb128: Ill forward that to upstream infra ...
[12:48] <seb128> thanks
[12:50] <Sweetshark> done
[12:50] <seb128> danke
[12:52] <ogra> seb128, Laney, the HUD in system-settings has a quit option now ... but thats only available in the top level, if i have any of the pages open it isnt there, is that wanted (very confusing imho)
[12:52] <ogra> mpt, ^^^
[12:53] <seb128> ogra, talk to pete, we nothing to do with the HUD, system-settings doesn't do anything there
[12:53] <seb128> that's coming from the toolkit or from unity8
[12:53] <ogra> ah, i thought it has to implement the quit option
[12:53] <seb128> we have nothing*
[12:53] <Laney> nope
[12:53] <seb128> no
[12:53] <ogra> k
[13:25] <seb128> larsu, desrt: can g_settings_get_value() return NULL?
[13:25] <desrt> no.  never.
[13:25] <desrt> i was just about to mention this fact in a review :)
[13:26] <larsu>  /* this code will never be reached because desrt made it crash */
[13:27] <desrt> damn straight
[13:27]  * desrt has been taking the blame for 5+ years so that people don't have to check for NULL :)
[13:27] <seb128> trying to make sense of https://launchpadlibrarian.net/167529008/Stacktrace.txt
[13:27] <seb128>         sources = 0x0
[13:27] <seb128> that code is
[13:27] <seb128>                 sources = g_settings_get_value (settings, KEY_INPUT_SOURCES);
[13:27] <seb128>                 g_variant_builder_init (&builder, G_VARIANT_TYPE ("aa{ss}"));
[13:27] <seb128>                 g_variant_iter_init (&iter, sources);
[13:28] <seb128> larsu, "that bug is not possible", right?
[13:28] <desrt> so when you say NEVER...
[13:28] <desrt> it might violate its interface if you violate preconditions
[13:28] <desrt> in particular:
[13:28] <desrt>   g_return_val_if_fail (G_IS_SETTINGS (settings), NULL);
[13:28] <desrt>   g_return_val_if_fail (key != NULL, NULL);
[13:28] <larsu> desrt: I guess I should acknowledge that in between giving you shit for it: thanks! ;)
[13:28] <larsu> lol
[13:29] <desrt> so it's possible that 'settings' was invalid going into this
[13:29] <desrt> since i'm pretty sure KEY_INPUT_SOURCES is just a constant... so that's sure to have been OK
[13:29] <seb128> right
[13:29] <seb128>         settings = 0x9c7c530
[13:30] <seb128> we should get some warning if that's not a valie settings though?
[13:30] <desrt> non-NULL but maybe (a) pointing to something else; or (b) already freed
[13:30] <desrt> seb128: ya.. you'd see critical output about that.
[13:31] <seb128> shrug
[13:32] <seb128> pitti, did we ever update apport to collect warnings/errors in upstart log in addition to ~/.xsession-errors?
[13:32] <seb128> since that's where the logs are nowadays
[13:44] <Sweetshark> ritz: I did build with 4.2 on trusty and 3.5 on precise for the drag'n drop issue. I started off with the patch that you added to the bug.
[13:44] <ritz> Sweetshark, hi
[13:45] <pitti> seb128: yes, I thought I added that in saucy already, hang on
[13:45] <Sweetshark> ritz: Funny thing is: For me it doesnt work on trusty yet, but the backport to precise seems to be fine.
[13:45]  * ritz checking for new builds 
[13:45] <Sweetshark> ritz: builds are currently still here: https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-staging
[13:45] <pitti> seb128: data/general-hooks/ubuntu.py calls apport.hookutils.attach_upstart_logs(), so in theory it ought to work
[13:46] <seb128> pitti, https://launchpad.net/ubuntu/+source/apport/2.11-0ubuntu1
[13:47] <pitti> seb128: apport-bug update-notifier includes the log for me
[13:49] <seb128> pitti, hum, dunno why there is no log on https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1284521 then
[13:49] <ubot2> Launchpad bug 1284521 in unity-settings-daemon (Ubuntu) "unity-settings-daemon crashed with SIGSEGV in g_bit_lock()" [Medium,Confirmed]
[13:51] <ritz> Sweetshark, downloading lo on trusty, will check and post an update
[13:51] <seb128> pitti, is the codepath for segfaults different?
[13:52] <pitti> seb128: no, it could just be that ubunty.py crashes before it gets there
[13:52]  * pitti tries to kill unity-settings-daemon and see what apport does
[13:53] <pitti> hm, I still get the log in apport
[13:53] <pitti> seb128: could it be that the file was simply empty for the reporter?
[13:53] <pitti> process:21802): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed
[13:53] <pitti> I have a few instances of this ^ in the log, but nothing else
[13:53] <pitti> perhaps that's specific to my system and it doesn't log anything else?
[13:53] <pitti> we don't run it with G_DEBUG or anything
[13:54] <seb128> those warnings are firefox I think
[13:54] <pitti> seb128: oh, so perhaps a chromium user?
[13:54] <seb128> yeah, mine is mostly empty (some color profile warnings)
[13:54] <pitti> but why do firefox warnings appear in the u-s-d log?
[13:54] <seb128> pitti, well, the segfault shouldn't be possible without having glib warnings
[13:54] <pitti> I don't have color profile warnings
[13:55] <pitti> seb128: why wouldn't it?
[13:55] <pitti> glib would usually yell on assertions (and then abort), but that's a NULL pointer deref
[13:56] <seb128> pitti, because g_settings_get_value() can't return NULL
[13:56] <pitti> it's not quite 0, it's 10
 so when you say NEVER...
[13:56] <seb128>  it might violate its interface if you violate preconditions
[13:56] <seb128>  in particular:
[13:56] <seb128>    g_return_val_if_fail (G_IS_SETTINGS (settings), NULL);
[13:56] <seb128>    g_return_val_if_fail (key != NULL, NULL);
[13:56] <pitti> looks like something passes an 0x10 int as a pointer value or so
[13:56] <seb128> pitti, we should hit one of those g_return_val_if_fail to get a sources=NULL
[13:57] <desrt> seb128: if we had fatal criticals, we wouldn't have to play this guessing game right now ;)
[13:57] <pitti> well, segfault != critical
[13:57] <seb128> lol
[13:57] <seb128> let's not have that conversation today ;-)
[13:57] <pitti> in particular, segfaults are distinct from assertions (SIGABRT)
[13:57] <desrt> pitti: just lodging my usual complaint about how annoying it is to have to trace issues backwards to the original cause
[13:58] <desrt> instead of aborting as soon as we detect any issue at all
[13:58] <seb128> pitti, I think desrt is saying that if we had an sigabrt we would have a bt and not have to parse logs for warnings
[13:58] <seb128> but as said, we are not going to do that, so let's not discuss it ;-)
[13:59] <seb128> pitti, anyway, thanks for checking the apport side, I'm going to keep an eye on reports, it's weird that we don't have one in this case
[13:59] <pitti> yes, but we don't have an assertion failure here
[13:59] <pitti> so this is moot :)
[13:59] <pitti> something derefs the value 0x00000010
[14:00] <desrt> pitti: i'm just saying that we could have had a nice assert failure with the backtrace showing the exact cause of the problem, but instead we get a segfault some time later...
[14:00] <desrt> pitti: the deref of 0x10 is pretty simple: someone gives a NULL pointer for a struct and we try to read something at offset 0x10 inside that struct
[14:00] <pitti> desrt: ah, now I understand what you mean
[14:00] <seb128> pitti, the issue on frame 4 "        sources = 0x0"
[14:01] <seb128> pitti, that's a 'sources = g_settings_get_value (settings, KEY_INPUT_SOURCES);'
[14:01] <desrt> pitti: pretty sure seb is right about the cause being that the 'settings' object is wrong, earlier
[14:01] <seb128> pitti, that can't return 0x0
[14:01] <seb128> except if the settings object is invalid
[14:01] <seb128> which should trigger a warning in the log
[14:01] <pitti> *nod*
[14:01] <seb128> but I found a condition where it can be buggy
[14:01] <seb128> so I'm just going to patch that
[14:02] <seb128> the init code does
[14:02] <seb128> 	xkb_init (manager);
[14:02] <seb128> 	set_devicepresence_handler (manager);
[14:02] <seb128>         manager->priv->input_sources_settings = g_settings_new (GNOME_DESKTOP_INPUT_SOURCES_DIR);
[14:02] <seb128>  
[14:02] <seb128> or set_devicepresence_handler() connect a signal with a callback that uses input_sources_settings
[14:02] <seb128> just going to put the g_settings_new before the handler
[14:03] <seb128> desrt, pitti: thanks
[14:03] <pitti> I wonder if the log gets flushed properly after each line
[14:03] <desrt> seb128: i'm suspicious.
[14:03] <pitti> i. e. could it be that it forgets to write the pending buffers after a crash?
[14:03] <desrt> unless ->priv was allocated in some strange way, it should be NULL from the start
[14:03] <desrt> and the bt shows a non-NULL value in 'settings'
[14:04] <desrt> so unless the settings are being created/destroyed/created/destroyed during the life of the object, ...
[14:05] <larsu> clearly we need fatal criticals
[14:05] <larsu> oh wait, you already seem to have discussed that...
[14:07] <seb128> desrt, https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/keyboard/gsd-keyboard-manager.c#n1765
[14:07] <pitti> hm, how do I get back my settings after killing and rstarting unity-settings-daemon..
[14:07] <seb128> pitti, which ones?
[14:08] <pitti> seb128: theme mostly; this dark theme hurts my eye :)
[14:08] <pitti> well, I'll just restart my session
[14:08] <seb128> yeah, I don't know why theme update don't pick up :/
[14:08] <seb128> that's annoying
[14:10] <desrt> seb128: ya... indeed the settings is being created/destroyed
[14:11] <desrt> seb128: it's a bit weird, though -- they seem to be managing the reference quite properly -- g_clear_object() is really a good thing to be using here
[14:11] <desrt> so i have no idea :)
[14:12] <attente> how is that possible though, it only seems to be created once?
[14:12] <seb128> desrt, is something supposed to do init to NULL when the object is created there?
[14:13] <desrt> seb128: the private structure gets zero-filled by g_type_create_instance
[14:13] <seb128> k, so that's not the order in the init function I guess
[14:14] <seb128> we would have null there otherwise
[14:14] <attente> is it a problem that it's created in an idle?
[14:14]  * seb128 gives up, that bug is not important enough to justify spending hours on it
[14:14] <attente> maybe that callback comes before the idle is run
[14:14] <seb128> what callback?
[14:15] <attente> user_notify_is_loaded_cb
[14:15] <seb128> I don't think it's possible
[14:16] <larsu> also, the settings object would be NULL in that case, no?
[14:16] <seb128> none of the callers should be triggerable before the start_keyboard_idle_cb() is called
[14:16] <seb128> e.g 	set_devicepresence_handler (manager); is called in start_keyboard_idle_cb()
[14:22] <desrt> seb128: btw: i hate you for that gsettings bug yesterday
[14:22] <seb128> heh, don't blame the messenger!
[14:22] <desrt> just thought i'd mention that ;)
[14:22] <seb128> ;-)
[14:23] <seb128> shrug
[14:23] <seb128> ricotz's ppa is creating issues for unity-settings-daemon
[14:24] <seb128> desrt, is https://errors.ubuntu.com/problem/4272a581c30b062869c18b356abcf37fa51adc65 the same gsettings bug?
[14:24] <seb128> that's the most reported u-s-d issue in a week with 25 reports :/
[14:25] <desrt> same backtrace, same bug
[14:25] <desrt> i should have a fix today
[14:25] <seb128> \o/
[14:25] <desrt> it's one of those things that i could fix in about 50 possible ways
[14:25] <desrt> and i'm really not sure which is the best
[14:26] <desrt> but i think it's going to involve lots of hashtables
[14:26] <seb128> well as long as you are happy with the fix
[14:26] <desrt> hashtables make me happy... so it will prevent me from being too depressed while i write the patch
[14:28] <seb128> ;-)
[14:28] <seb128> attente, how do you bind keybindings to actions with the compiz/u-s-d key grabber?
[14:29] <seb128> attente, https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1284532 is a bit weird
[14:29] <ubot2> Launchpad bug 1284532 in unity-settings-daemon (Ubuntu) "print screen button appears hard-wired to screenshot" [Low,Confirmed]
[14:29] <seb128> attente, the defaults settings are, "print" = screen capture, "ctrl+print" = capture to clipboard
[14:30] <seb128> attente, if you unset "print" from screen capture, pressing the print key triggers a capture to clipboard
[14:30] <seb128> which is supposed to be ctrl-print
[14:30] <seb128> attente, do you have any idea what's going on?
[14:30] <attente> seb128, not really, but i'll look at it
[14:31] <seb128> attente, don't worry much about it, it's a corner case (who reassign the print screen to something else?!)
[14:31] <attente> lol
[14:32] <hikiko> desrt, hi
[14:32] <desrt> hikiko: good morning/afternoon
[14:32] <hikiko> good morning :)
[14:32] <Laney> ooh
[14:32] <Laney> if you unset print and then reset it then it doesn't print screen any more
[14:32] <Laney> for me anyway
[14:32] <hikiko> I'm looking at the g_settings_get_value/set_value
[14:32] <hikiko> but there's no param for the type
[14:33] <desrt> hikiko: you don't need it.  the type is in the schema.
[14:33] <seb128> Laney, "re-set" you mean?
[14:33] <desrt> you're always guaranteed to get the correct type of value
[14:33] <Laney> put it back to print
[14:33] <seb128> right
[14:33] <seb128> wfm
[14:33] <Laney> nfm
[14:33] <hikiko> cool that was my question :)
[14:33] <seb128> did you restart u-s-d in between?
[14:33] <Laney> no but doing that does restore it
[14:33] <seb128> I think things go weird with the grabbing if you restart it
[14:33] <seb128> hum, k
[14:33] <seb128> weird
[14:34] <Laney> and now the grabbing is broke after another restart
[14:34] <seb128> I had one issue of that earlier but couldn't reproduce
[14:34] <Laney> woe!
[14:34] <seb128> isn't the issue with restart the state thing desrt, attente and larsu discussed during the meeting yesterday?
[14:35] <larsu> yes, I noticed that while hacking on the media-keys plugin
[14:35] <larsu> in fact, I'm seeing the same issue again today after unity decided to crash
[14:35] <larsu> (I shouldn't have used Alt-Tab!)
[14:35] <attente> :(
[14:35] <attente> might have to do the xdg runtime dir thing after all
[14:36] <Laney> ya, probably
[14:36] <seb128> attente, it's another "would be nice to have, but don't worry too much about it, restarting u-s-d is what we do for testing, not something most users are going to do"
[14:36] <larsu> attente: I still don't understand why that is necessary...
[14:37] <larsu> but I guess you and desrt talked about it in detail, so it'll be fine
[14:38] <attente> well.. it doesn't just happen for testing unity/u-s-d, it happens if either crashes hard
[14:38] <seb128> right
[14:38] <seb128> which isn't the norm
[14:38] <larsu> attente: as opposed to crashing softly?
[14:38]  * larsu wonders what that would look like
[14:39] <larsu> a backtrace with lots of pillows?!
[14:41] <Sweetshark> maybe put an memory eating forkbomb in the exception handling? that would softy put the machine to a halt ...
[14:41] <seb128> when that happens you get other issues
[14:41] <seb128> like g-s-d/u-s-d restarting screws your theme
[14:41] <Sweetshark> ... until the OOM puts an end to it, spoils the party and wakes you up.
[14:44] <Sweetshark> ritz: I think I know what the issue is on trusty ...
[14:44] <ritz> Sweetshark, this I would love to know
[14:45] <ritz> still downloading the source
[14:53] <Sweetshark> ritz: https://gist.github.com/bjoernmichaelsen/9230792/revisions <- I think I tried to cp the file before it was moved in place ...
[14:54] <ritz> aah
[14:54] <ritz> k, so the rules files is hosted on git
[14:55] <Sweetshark> ritz: nah, gist is just a glorified pastebin ...
[14:57] <Sweetshark> ritz: the packages are hosted at http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=summary but I usually only push there, when I also do a 'real' upload to the archive.
[14:57] <ritz> hmm, this would also be need to be pushed into debian
[14:59] <ritz> Sweetshark, thanks. pastebin with git support . very interesting concept
[14:59] <Sweetshark> ritz: well, there are two scenarios: 1/ rene likes the patch -- then he will cherry-pick it to debian anyway, when I push on the ubuntu branch 2/ rene doesnt like the patch -- then no matter what you do, the patch is unlikely to land in debian.
[15:01] <ritz> Sweetshark, so, I would need to write my reasons as why this should be used
[15:03] <ritz> and file a debian bug report
[15:04] <Laney> pitti: did you miss my latest dbusmock PR? ;-)
[15:04] <Laney> I have a feeling gitorious isn't the best when it comes to notifications
[15:04] <pitti> Laney: indeed, I didn't get any notification at all
[15:04]  * pitti checks whether there's an option for that
[15:05] <Laney> fail
[15:05] <pitti> Laney: sorry, will do ASAP
[15:05] <Laney> no worries, I forgot myself
[15:06] <xnox> Laney: not sure if github is any better, one needs to login and check facebook style notifications and the "wall of events"
[15:06] <Laney> xnox: no emails there either?
[15:06] <pitti> "By default notify me of updates in what I am watching"
[15:06]  * pitti enables that
[15:06] <Laney> nod
[15:06] <pitti> xnox: I do get RAOF's pull requests on github
[15:06] <pitti> by mail, I mean
[15:07] <xnox> Laney: not that i've seen, maybe i've disabled them?!
[15:07]  * xnox goes to check
[15:07] <xnox> Launchpad for one has most sane emails of them all...
[15:07] <seb128> Sweetshark, the libreoffice dicts packaging seems fine to me, what sort of feedback were you after for it?
[15:11] <pitti> xnox: +1
[15:11] <pitti> X-Launchpad-Rationale: for filtering → gold
[15:18] <smb> Sarvatt, Not sure you are the one to contact but you may know who. I have the feeling that there is a regression in recent Trusty desktop that maybe is related to llvm-pipe.
[15:34] <seb128> desrt, do you know why GNOME has robot.txt that stops google to give a description of the developer.gnome.org apis?
[15:34] <seb128> "developer.gnome.org/glib/2.30/glib-GDateTime.html
[15:34] <seb128> La description de ce résultat n'est pas accessible à cause du fichier robots.txt de ce site. En savoir plus"
[15:34] <seb128> I get that when I google glib apis
[15:35] <desrt> seb128: i think we do that to try to make sure the newest version of the doc is the one that google finds
[15:35] <desrt> not helping, apparently :)
[15:35] <seb128> right
[15:37] <seb128> desrt, http://people.canonical.com/~seb128/glib.png
[15:37] <desrt> pretty lame
[15:37] <desrt> seb128: tell fredp about this?
[15:37] <seb128> ok
[15:37] <desrt> he speaks french too, so maybe he can even help you understand what the error message means :)
[15:37] <fredp> he's even on #ubuntu-desktop :)
[15:38] <Laney> c'est impossible!
[15:38] <seb128> fredp, hey
[15:39] <fredp> it's because we only allow google to index the latest versions, to avoid the results being cluttered by the same api from different versions.
[15:40] <fredp> seb128: https://bugzilla.gnome.org/show_bug.cgi?id=509424
[15:40] <ubot2> Gnome bug 509424 in help.gnome.org "Only let search engined index stable, unstable versions" [Normal,Resolved: fixed]
[15:41] <seb128> fredp, well, google fails to rank/return results from newer versions though
[15:41] <fredp> seb128: a bug that was recently found, but I'm not sure it got reported, is that we do not exclude old odd version numbers.
[15:42] <seb128> fredp, did you see http://people.canonical.com/~seb128/glib.png ?
[15:42] <fredp> seb128: missed it, sorry
[15:44] <seb128> fredp, let's continue on the gnome channel only, no need to duplicate the conversation (sorry, pinged you there because I didn't though you were on #ubuntu-desktop ;-)
[15:44] <Sweetshark> seb128: Exactly that kind of feedback. ;)
[15:44] <seb128> Sweetshark, if you want to go with the update you are going to need a ffe though
[15:44] <seb128> Sweetshark, I don't know how much data changed since our outdated openoffice version
[15:45] <Sweetshark> seb128: Can we push that to trusty and get rid of openoffice.org-dicts? ffe needed, sure, do we need a MIR too again?
[15:45] <seb128> Sweetshark, it's the same set of datas right?
[15:46] <Sweetshark> yes, just some 3 years of improvement on top of it ...
[15:50] <seb128> I don't think you need a MIR for that
[15:50] <seb128> but check with mterry or didrocks
[15:53] <seb128> right, so it's like a new version of a source in main imho
[15:53] <seb128> just need a ffe
[15:54] <seb128> Laney, easy review on https://code.launchpad.net/~seb128/unity-control-center/dont-duplicate-icon/+merge/208350 (just dropping 3 lines), I would appreciate if you could ack it, I want to do a u-c-c landing today
[15:54] <seb128> that's not the main change, but I want to include it while I'm doing a landing
[15:55] <Laney> oh yeah
[15:55] <Laney> I saw that issue
[15:58] <Laney> grr
[15:59] <Laney> I'm going to have to fix bzr-builddeb at some point
[15:59] <seb128> what is it doing?
[15:59] <Laney> it really annoys me how bzr bd -S puts the source package in .. and ../build-area
[15:59] <seb128> oh, right
[16:04]  * seb128 has the feeling Laney want to test build/run that change before +1 it :p
[16:05] <Laney> always
[16:05] <Laney> it does indeed work though
[16:05] <seb128> ;-)
[16:05] <seb128> it's a .ui diff, you could have patched the file on disk to avoid a build ;-)
[16:06] <seb128> Laney, thanks
[16:06] <Laney> hah
[16:06] <seb128> oh, hikiko just resubmited the gvariant refactoring
[16:06] <seb128> let's see if desrt is happy with that version, maybe we can batch it in the same landing
[16:06]  * desrt is checking now :)
[16:06] <hikiko> :D
[16:06] <desrt> this looks much better, indeed
[16:07] <desrt> hikiko: i assume you tested it?
[16:07] <hikiko> I've run it and it looked ok
[16:07] <desrt> approved, then
[16:07] <desrt> thanks for all the fixing
[16:07] <hikiko> but the previous one looked fine too so...
[16:08] <hikiko> I think it's fine though
[16:08] <desrt> hikiko: that's the trouble with leaks... they look fine :)
[16:08] <hikiko> so true!
[16:09]  * desrt likes all of the red lines in this patch
[16:09] <hikiko> hahahaha
[16:10] <hikiko> it was a nice trick that GVariantBuilder finally :)
[16:10] <hikiko> 3 lines of code
[16:11] <hikiko> replaced like 20 :)
[16:11] <desrt> yup.  much nicer this way.
[16:12] <desrt> it could have been even nicer if you moved the GSettings code into the add_dict_entry() func -- but this is not necessary :)
[16:12] <hikiko> well I have to go (my day is over) I hope I haven't introduced any new bugs accidentally
[16:12] <hikiko> mmm
[16:13] <desrt> (and i think it's better to have it separate -- it makes more sense logically this way)
[16:13] <hikiko> I could do
[16:13] <desrt> hikiko: i hope so too.  i'm always afraid that i'll do a review on code and get someone to replace their working code with my broken suggestions :)
[16:13] <desrt> hikiko: have a good evening
[16:14] <hikiko> well, it seems to not leak anything now :) thanks for the review
[16:14] <hikiko> +good evening :)
[16:25] <attente> anyone having trouble running unity from trunk?
[16:25] <attente> seems to halt as soon as the session is started...
[16:26] <seb128> trunk should be what is in trusty-proposed
[16:26] <seb128> did you self build?
[16:26] <seb128> the packages are working fine for me
[16:26] <attente> i did
[16:26] <seb128> does it exit? or segfault? or?
[16:26] <attente> it literally halts...
[16:26] <seb128> so freezes?
[16:26] <attente> the machine shuts off...
[16:26] <seb128> shrug
[16:27] <seb128> wth?
[16:27] <Laney> O_O
[16:27] <seb128> does it do the same if you start another session and run unity by hand there?
[16:27] <attente> yeah..
[16:27] <attente> seb128, haven't tried it
[16:29] <seb128> but is the box doing a proper shutdown?
[16:29] <seb128> I wonder if there is some upstart condition going on there...
[16:30] <attente> on the one hand, i saw a broadcast that said the system was going down, but on the other hand, the next boot was checking the file system
[16:33] <seb128> hum
[16:34] <seb128> is that reproducable?
[16:35] <attente> seb128, never mind, running it manually from a working session seems to work
[16:35] <seb128> weird still
[16:35] <attente> yeah...
[16:36] <seb128> attente, did you hit the power button by mistake? ;-)
[16:36] <attente> i was installing it locally
[16:36] <attente> lol
[16:36] <attente> could be, seb128
[16:38] <seb128> ;-)
[16:38] <xclaesse> seb128, hey, sound setting now have an "allow louder than 100%" checkbox
[16:38] <seb128> xclaesse, hey, indeed
[16:38] <xclaesse> seb128, but volume keys still does not go over 100%
[16:39] <seb128> xclaesse, install the deb from https://launchpad.net/ubuntu/+source/unity-settings-daemon/14.04.0+14.04.20140225-0ubuntu1
[16:39] <seb128> xclaesse, that got blocked by the beta freeze, should go in trusty proper tomorrow
[16:39] <xclaesse> seb128, awesome
[16:40] <xclaesse> seb128, you made that change since our converstation last time ?
[16:40] <seb128> xclaesse, yes
[16:40] <xclaesse> seb128, thanks! I owe you a beer :D
[16:40] <seb128> yw! ;-)
[16:41] <seb128> thanks to mpt and larsu mostly (for the design and the implementation), I've just been pushing a bit to see if they though it would be a good change to have
[16:42] <seb128> bregma, did you see https://launchpadlibrarian.net/167642928/buildlog_ubuntu-trusty-ppc64el.unity_7.1.2%2B14.04.20140225-0ubuntu1_FAILEDTOBUILD.txt.gz ?
[16:43] <bregma> seb128, yep, we're looking into it
[16:43] <seb128> ok, good
[16:43] <seb128> I didn't know if you would get any notification since that's not a manual upload
[16:43] <seb128> I noticed it while looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[16:45] <bregma> seb128, I check the builds before hitting Merge and Clean
[16:45] <seb128> bregma, good idea ;-)
[16:46] <seb128> tedg, did you see https://launchpadlibrarian.net/166581289/buildlog_ubuntu-trusty-ppc64el.dbus-test-runner_14.04.0%2B14.04.20140217.1-0ubuntu1_FAILEDTOBUILD.txt.gz ?
[16:47] <tedg> Hmm, no.
[16:48] <seb128> tedg, that's blocking the update in trusty-proposed
[16:48] <seb128> we really need to output the tests logs by default :/
[16:48] <tedg> Yeah, curious what's happening.
[16:48] <tedg> Do we have a ppc64el porter?
[16:48] <seb128> should I retry it in case that was transient ?
[16:49] <seb128> I don't think so
[16:49] <tedg> Building locally just to make sure it works :-)
[16:50] <tedg> Yeah, builds locally.
[16:50] <tedg> seb128, Hmm, I guess.  Seems unlikely, as those are pretty fast, right? (timeouts are usually transient issues)
[17:02] <mterry> seb128, could you give https://code.launchpad.net/~laney/ubuntu-system-settings/as-ringtone/+merge/200862 a re-look when you get a chance?
[17:03] <seb128> mterry, is that the one you approved some days ago?
[17:03] <mterry> seb128, yeah
[17:03] <mterry> seb128, you had looked at it previously too
[17:03] <seb128> why is CI failing, did it ever work since they enabled it for u-s-s?
[17:03] <mterry> seb128, just figured it probably shouldn't land without a final once-over by someone actually working on that component
[17:03] <seb128> om26er, ^
[17:04] <seb128> mterry, Laney is working on u-s-s, but I can have a look
[17:04] <mterry> seb128, yeah, but it's laney's branch.  CI was working for that branch before Laney merged from trunk.  Not sure if bad merge or just flakiness
[17:04] <seb128> mterry, I was trying to stay away from it because I'm still unsure I agree with replacing gsettings by accountsservice :p (for the reasons listed previously)
[17:04] <Laney> it's the new stuff
[17:04] <mterry> seb128, ah
[17:06] <om26er> seb128, sorry about that there is that one test that is failing on otto due to a crash while mocking upower, i'll disable that one
[17:06] <seb128> Laney, the world was simpler before, I liked that, I don't want the new stuff: p
[17:06] <seb128> om26er, thanks
[17:06] <Laney> yeah, multi-user sucks man
[17:06] <Laney> but "new stuff" I was referring to CI :P
[17:07]  * Laney almost has u-s-s reset api working
[17:09] <seb128> oh
[17:11] <seb128> Laney, mterry: approved
[17:12] <seb128> Laney, do you want to handle the landing/put it in a silo for testing?
[17:12] <Laney> ty
[17:12] <Laney> can't, u-s-s already has one
[17:12] <seb128> (or wait, we have other upgrade work ongoing right?)
[17:12] <seb128> k
[17:12] <seb128> well, once that one is landed
[17:12] <Laney> sure
[17:12] <Laney> or mterry can lead on doing that if he wants
[17:12] <mterry> sigh... silos
[17:12] <Laney> & can
[17:13] <mterry> it can be squeezed in with other u-s-s changes you guys have, no rush for its own silo
[17:14] <seb128> well, having a silo gives you a ppa with a nice debs you can run tests on, to really make sure the change is ok :p
[17:14] <Laney> I'd rather not, the current one has been quite hard fought
[17:15]  * seb128 still nervous about that one, doesn't want to be the guy who made the phone not ring on calls ;-)
[17:15] <Laney> get some 'avengers' to test the ppa :P
[17:15] <mterry> Laney, no not that it needs to go in this immediate next silo.  Just that it can go in a future silo without pressure
[17:15] <Laney> ah
[17:15] <mterry> Laney, i.e. it's not time sensitive for me yet
[17:16] <Laney> shouldn't be too hard to do next anyway
[17:16] <Laney> if the service side can still go
[17:16] <seb128> Laney, btw I plan to let the oobe (wizard) merge in soon as well (mentioning it in case you wanted to look at it before it's accepted)
[17:16] <mterry> ooh
[17:16] <mterry> still unusable, but that helps future merges be tiny
[17:17] <seb128> right, that's why I want to get it in
[17:17] <seb128> so we can start reviewing reasonable diffs
[17:17] <Laney> ok, I'll see but don't wait for me
[17:18] <seb128> k
[17:22] <seb128> tjaalton, I guess you noticed https://launchpadlibrarian.net/167123837/buildlog_ubuntu-trusty-i386.gstreamer-vaapi_0.5.7-0ubuntu2_FAILEDTOBUILD.txt.gz ?
[17:25] <tjaalton> yes
[17:25] <tjaalton> no idea why it fails
[17:25] <tjaalton> just on i386
[17:26] <tjaalton> haven't had time to fix it yet, the guy who made all the packaging changes vanished
[17:26] <seb128> tjaalton, because it's the only arch building the documentation which is arch all?
[17:26] <tjaalton> huh
[17:26] <tjaalton> ok
[17:26] <seb128> ;-)
[17:26] <tjaalton> well, there's something else wrong to
[17:26] <tjaalton> +o
[17:27] <tjaalton> or not, but this is essentially the same what is on debian NEW
[17:27] <tjaalton> since a few weeks
[17:27] <tjaalton> I'll look into it tomorrow..
[17:28] <tjaalton> btw, how's the wacom config backend doing?
[17:28] <seb128> tjaalton, did you test it?
[17:28] <tjaalton> forgot the status.. something got added?
[17:28] <seb128> tjaalton, I forgot that we already had g-s-d 3.8
[17:29] <seb128> we updated the control center side to 3.8
[17:29] <tjaalton> the good stuff is not in 3.8, but 3.10
[17:29] <tjaalton> I think
[17:29] <seb128> seems like 3.10 has some "worth trying to backport" changes though
[17:29] <seb128> but I don't have a wacom so I can't really test
[17:29] <seb128> right
[17:29] <tjaalton> it's all in the archive now?
[17:29] <seb128> 3.8 is
[17:30] <seb128> https://bugs.launchpad.net/ubuntu/+source/unity-control-center/+bug/1277733
[17:30] <ubot2> Launchpad bug 1277733 in unity-control-center (Ubuntu) "Backport newer Wacom tablet support" [Wishlist,Triaged]
[17:30] <tjaalton> cool, subscribed
[17:30] <tjaalton> yeah the OSD looks cool
[17:30] <tjaalton> *would look cool :)
[17:31] <seb128> hehe
[17:31] <seb128> tjaalton, gstreamer-vaapi ... it just seems like that upstream tarball is not shipping the generated documentation and the package is not using enable-gtk-doc
[17:31] <seb128> so you end up with no documentation to install
[17:32] <tjaalton> it builds fine on sbuild
[17:34] <seb128> tjaalton, with arch all?
[17:35] <seb128> hum, the tarball has the html files
[17:36] <tjaalton> seb128: yes, -0u1 too
[17:36] <tjaalton> -0u2 was a panic change, didn't have time to worry what the real fix would've been. and it wasn't enough anyway..
[17:38] <seb128> tjaalton, "checking whether to build gtk-doc documentation... no"
[17:38] <tjaalton> so the current u-c-c/u-s-d versions map to g-c-c/g-s-d 3.8?
[17:38] <seb128> yes
[17:40] <tjaalton> I'll try to build -vaapi on a ppa instead of sbuild
[17:45] <Laney> http://paste.ubuntu.com/7000960/
[17:45] <Laney> woot
[17:45] <seb128> Laney, nice!
[17:45] <Laney> that do some resetting comes from a js function inside of the phone plugin
[17:45] <Laney> called from c++
[17:46] <seb128> that's slightly scary ;-)
[17:46] <Laney> kind of
[17:47] <Laney> it means you can define a "function reset() { undo_my_stuff() }" in each plugin
[17:48] <seb128> that's nice
[17:48] <Laney> online accounts is annoying
[17:48] <Laney> it opens its page component automatically
[17:57] <dobey> anyone know how to disable this new live-resize feature? does one have to install ccsm to do so?
[18:05] <seb128> dobey, you can probably tweak the option through dconf or gsettings but ccsm is easier
[18:06] <seb128> dobey, is it buggy for you? (would be useful to get feedback on that to know if we need to turn if off again before release)
[18:07] <dobey> seb128: it's pretty cpu-intensive, and it works very poorly with emacs
[18:08] <dobey> i don't know if that's cause to turn it off before release though
[18:08] <dobey> i didn't see an option when i was poking through dconf, but maybe i was looking in the wrong places
[18:10] <seb128> well, compiz settings are stored in dconf nowadays
[18:10] <seb128> but they are relocatable paths, so it's a bit tricker to find them iirc
[18:10] <seb128> use ccsm it's easier
[18:10] <dobey> well i didn't see anything under org.compiz in dconf-editor
[18:18] <seb128> dobey, $ gsettings set org.compiz.resize:/org/compiz/profiles/unity/plugins/resize/ mode 2
[18:23] <dobey> whee. and compiz crashed
[18:23] <dobey> or at least, the window decorator did
[20:29] <robert_ancell> desrt, does a feature in gsettings where a key is marked as deprecated and that would cause an application that accesses that key to have a GWarning sound useful?
[20:30] <robert_ancell> so schema writers are encouraged to never remove keys but just mark them as deprecated
[20:30] <desrt> robert_ancell: it sounds interesting... not sure it's super-userful
[20:31] <desrt> i don't like the runtime nature of it... i'd prefer if it were compile/install time, but i guess that's not really possible
[20:31] <robert_ancell> desrt, has to be run-time because there's no way of knowing who's consuming your schema
[20:31] <robert_ancell> desrt, this is due to keys being removed from g-s-d and that means old apps crash
[20:32] <robert_ancell> you want to strongly encourage those apps to update to new keys, but be able to test newer versions of schemas without everything falling apart
[20:32] <desrt> robert_ancell: might help also if we had a different notation in the schema file for deprecated keys..
[20:33] <desrt> so that they didn't use as much space
[20:33] <robert_ancell> desrt, yes
[20:33] <desrt> like, a one-liner with a type maybe... default values unsupported...
[20:33] <robert_ancell> by marking them as such we can optimise them for a slow path
[20:33] <desrt> and it always returns the wrong value
[20:33] <desrt> something like that....
[20:33] <desrt> ie: this is no longer useful at all to you... but at least you don't crash
[20:34] <robert_ancell> yes
[20:34] <desrt> robert_ancell: it might be nicer than the current situation
[20:34] <robert_ancell> it would probably have to return an appropriate value, as apps might be relying on the schema limits
[20:34] <desrt> although honestly, i think your beef is with the people removing keys from their schemas *shrug*
[20:34] <desrt> robert_ancell: ya... range would indeed have to be respected
[20:35] <desrt> which argues towards just having the full entry there, but with a deprecated='yes' tag
[20:35] <desrt> and perhaps a summary form for the simple cases
[20:35] <robert_ancell> desrt, yes, but I appreciate why they'd want to remove them. If there was a better process to deprecate I think people would do that more happily
[20:35] <desrt> it won't help you if people don't use it, though
[20:35] <desrt> and i suspect that people won't use it
[20:51] <attente> bschaefer, hi, what's the purpose of the ScaleImageIcons function in panel/PanelIndicatorEntryView.cpp?
[20:56] <bschaefer> attente, for HiDPI support in unity
[20:56] <bschaefer> attente, we need to scale all the icons based on the per monitor DPI scale setting
[20:57] <bschaefer> attente, do you see that function in trunk?
[20:57]  * bschaefer doesn't seem to see it
[20:57] <attente> bschaefer, is there a reason why the x and y positions are hard coded?
[20:57] <bschaefer> attente, let me poke Trevinho
[20:57] <bschaefer> Trevinho, ^
[20:58] <attente> bschaefer, yes, it's in trunk
[20:58] <bschaefer> attente, i think Trevinho might have removed that code :) in this branch
[20:59] <bschaefer> attente, https://code.launchpad.net/~3v1n0/unity/hidpi-better-scaling/+merge/208238
[20:59] <bschaefer> attente, yeah, that was a work around, now we use the nice cairo scaling :)
[20:59] <bschaefer> so that function is removed
[21:00] <attente> ah, ok, thanks!
[21:00] <bschaefer> attente, np! Lots of new fixes for dpi :)
[21:02] <bschaefer> Trevinho, ignore the poking!
[21:40] <seb128> bregma, did you noticed that the unity8-desktop-session publish is waiting for a packaging ack click
[21:41] <bregma> seb128, yes, I just got back from running an errand
[21:42] <seb128> K
[21:42] <seb128> bregma, I was pondering clicking it for you but I decided to ping first in case you didn't ack it for a reason :-)
[21:43] <bregma> no good reason