[00:04] <xnox> desrt: or like fix the tests to not assert, or allow error margins on floating point results, since there will be errors.
[00:35] <desrt> xnox: i mentioned before... this is not about having a testcase produce any particular result
[00:36] <desrt> i don't care what the result is
[00:36] <desrt> i only care that if i do the calculation twice, i get the same result both times
[00:36] <desrt> that doesn't seem like too much to ask :)
[00:41] <Fudgey> hi, wondering if anyone can suggest how to elaborate on this, think it is a Compiz problem, Bug #1272131
[00:41] <ubot2`> Launchpad bug 1272131 in compiz (Ubuntu) "Totem regains focus on a window when it is not supposed to." [Undecided,New] https://launchpad.net/bugs/1272131
[05:49] <pitti> Good morning
[08:28] <xnox> desrt: it is too much to ask, all floating point calculation are unstable and will not get same results. http://software.intel.com/sites/default/files/article/164389/fp-consistency-122712_1.pdf is a fun read.
[08:31] <RAOF> pitti: That's not technically true - there *is* a concept of equality for real numbers in mathematics. It's just uncomputable.
[08:32] <pitti> RAOF: well, that depends on which definition of real numbers you want
[08:33] <pitti> RAOF: some are merely uncomputable, some are not even defined
[08:33] <RAOF> Or, rather, a real number is generally defined as an equivalence class.
[08:33] <pitti> RAOF: but I guess  either way, uncomputable already rules out the possibility of using that in a programming language :)
[08:33] <RAOF> Indeed :)
[08:33] <RAOF> If you're talking about decimal expansions, then you've already lost :)
[08:33] <pitti> RAOF: you can't even write down an equivalence class, only some representatives (and then you again can't compare them)
[08:34] <RAOF> Oh, absolutely.
[08:34] <RAOF> There's a legitimate argument in mathematics as to whether real numbers are a well-formed concept.
[08:34] <pitti> I'm a computer scientist, so I refuse AC
[08:35] <RAOF> But if you accept the _existence_ of real numbers, then they've got a well-defined equality. It's just that you can never write down a real number.
[08:35] <pitti> any object which doesn't fit into our universe and requires infinite amounts of energy, information, decisions, and space to write down is not real to me :)
[08:35] <RAOF> Oooh, a hardcore finitist!
[08:36] <pitti> people have done fairly well with finite approximations so far :)
[08:36] <RAOF> Except you can't do any calculus with them.
[08:37] <RAOF> (This is really, really terrible)
[08:37] <pitti> why, we do, without ever having to write down a singlel real number
[08:37] <RAOF> Right, but calculus is defined only for real numbers.
[08:38] <RAOF> Otherwise you find rather awkward things, like the integral of all functions being 0.
[08:39] <RAOF> pitti: You know what's hilarious? My unit tests die with SIGHUP in umockdev_testbed_teardown() when built with gcc, but not with clang.
[08:39] <pitti> you can easily get derivatives of rational functions just purely algebraically
[08:40] <pitti> I don't know how to do the integration algebraically, but ISTR that I've once seen a clever way to do it
[08:40] <pitti> RAOF: oha, which one is that?
[08:40] <pitti> HUP??
[08:40] <pitti> what a strange signal to die with
[08:40] <RAOF> It's “someone's closed your pty”
[08:40] <pitti> ah
[08:41] <RAOF> Which is totally true, apart from the bit where I don't have any fds to the child end of the pty open.
[08:41] <RAOF> Also, it's rather hard to algebraically differentiate such unimportant trancendental functions as, say, sin(x) ☺
[08:43] <pitti> yes, of course, as they are not algebraic in the first place
[08:43] <pitti> but we can only approximately calculate them anyway, so any integration etc. is necessarily also approximate
[08:44] <pitti> except for the usual school book special cases of course
[08:44] <RAOF> Mathematicians are rather unhappy with the whole “just approximate it” schtick :)
[08:44] <RAOF> And you can't approximately derive those special cases.
[08:45] <seb128> good morning desktopers, happy friday!
[08:45] <RAOF> (It's not entirely clear how you'd do a non-infinitesimal integration, and how you'd show that it's the area under the curve. I guess there's always numerical integration, but that's not interesting to mathematicians :P)
[08:45] <RAOF> seb128: Yo!
[08:46] <seb128> RAOF, hey! how are you?
[08:46] <RAOF> I'm good.
[08:46] <pitti> hey seb128
[08:46] <RAOF> I'm wondering what precisely causes gcc to generate code that dies when clang doesn't :)
[08:47] <pitti> RAOF: some race condition perhaps?
[08:47] <RAOF> Ah.
[08:47] <pitti> RAOF: did you strace in both cases? do you actually see the sighup?
[08:47] <RAOF> No.
[08:47] <RAOF> (I added a sighup handler, and it is indeed called)
[08:47] <pitti> perhaps in one case the sighup arrives a tad later when the destructor is already done or so
[08:48] <RAOF> I think there might be a umockdev bugfix release in the near future. It seems that, rather than the difference being clang/gcc, the difference might be umockdev 0.6 vs 0.7.
[08:48] <seb128> pitti, hey, wie gehts?
[08:49] <RAOF>  !!!
[08:49] <RAOF> No, that's not it either?
[08:52] <pitti> seb128: gut, danke! und Dir?
[08:52] <seb128> pitti, auch gut, danke!
[08:54] <pitti> RAOF: you mean it's not related to 0.6 vs. 0.7?
[08:54] <pitti> RAOF: or do you perhaps still have some local clang-built umockdev around? could that be the difference?
[08:54] <RAOF> pitti: Yeah. I've just rebuilt the tests with clang again and... it receives SIGHUP
[08:55] <pitti> RAOF: so it's not clang and it's not the umockdev version?
[08:55] <pitti> just a nice classic nasty race condition?
[08:55] <RAOF> Indeed.
[08:55] <pitti> RAOF: it doesn't try to compare real numbers in the condition to send SIGHUP, does it? :-)
[08:55] <RAOF> For added giggles, it doesn't show up if you *only* run the tests that use umockdev.
[08:56] <RAOF> :P
[08:56] <pitti> RAOF: of course, as that would make debugging easier; can't be
[08:57] <RAOF> What this means is that it's time to fix all of the (many) fd leaks in the unit-tests and see which one unbreaks it.
[09:02] <pitti> RAOF: hm, you think you have some old PTY fds which perhaps time out, and the SIGHUP on those spills over to the next test?
[09:03] <RAOF> Possibly something like that.
[09:03] <pitti> RAOF: you can also try running just that one test in a loop and doing some load in the background (find / > /dev/null, cat /dev/urandom > /dev/null or similar)
[09:06] <Laney> hey
[09:06] <Laney> happy friday
[09:08] <seb128> Laney, hey, you too! how are you?
[09:08] <pitti> hey Laney
[09:12] <Laney> hey seb128, pitti
[09:12] <Laney> I'm doing good thanks!
[09:12] <Laney> and you?
[10:01] <tsdgeos> anyone knows how/where i file against the mesa drivers crashing?
[10:02] <tsdgeos> ah
[10:02] <tsdgeos> found it
[10:02] <tsdgeos> launchpad is such a confusing thing
[10:04] <seb128> tsdgeos, if you need somebody to have a look you can try pining mlankhorst
[10:06] <tsdgeos> mlankhorst: i've got crashes in i965_dri.so in trusty i was not having a few days, filed https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1289243 tell me if you need something else or want me to try anything
[10:06] <ubot2`> Launchpad bug 1289243 in mesa (Ubuntu) "Regression in trusty, i965_dri.so crashes" [Undecided,New]
[10:13] <mlankhorst> tsdgeos: can you try to downgrade mesa to rc1?
[10:15] <tsdgeos> mlankhorst: do you know the exact package name by heart? i mean is it 10.1.0~rc1-0ubuntu1 ?
[10:16] <mlankhorst> ought to be
[10:17] <mlankhorst> 10.1.0~rc1-1ubuntu3
[10:23] <tsdgeos> mlankhorst: hmmm, i guess i'll ahve to build the packages myself? trying to apt-get that version tells me it doesn't exist
[10:25] <mlankhorst> old versions are removed, but still available on launchpad
[10:25] <mlankhorst> https://launchpad.net/ubuntu/+source/mesa/10.1.0~rc1-1ubuntu3
[10:28] <tsdgeos> mlankhorst: ah, cool thanks
[11:14] <tsdgeos> mlankhorst: do i need to restart X?
[11:15] <tsdgeos> Trevinho: ping
[11:19] <mlankhorst> tsdgeos: probably not if the crash is in compiz, but might need to restart opengl applications
[11:20] <tsdgeos> mlankhorst: not in compiz, in a separate app
[11:20] <tsdgeos> mlankhorst: so just starting the app should be ok, no?
[11:31] <mlankhorst> yeah
[11:37] <tsdgeos> mlankhorst: then it still crashes :_
[11:37] <tsdgeos> :/
[11:38] <mlankhorst> can you try 10.0.1-1ubuntu2 ? :P
[11:43] <mlankhorst> afk, can you post the result if it occurs there on that bug, and then ask in #intel-gfx ?
[11:46] <tsdgeos> i guess i can try
[12:00] <tsdgeos> mlankhorst: same thing, that is weird, may it be a kernel regression or something?
[12:00] <tsdgeos> i'll try jumping into  #intel-gfx anyway
[12:01] <tsdgeos> but next week, need to get some work work done
[12:01] <seb128> pitti, so, another trusty regression is that if you have "do nothing on lid close when on power" selected and close the lid docked, the laptop suspends... do you have any debug hint?
[12:03] <pitti> seb128: hm, run gnome-settings-daemon with G_MESSAGES_DEBUG=power (not sure if that works, use "all" if not)?
[12:03] <seb128> pitti, is g-s-d supposed to put a logind inhibit? how do I list those?
[12:03] <pitti> seb128: it coudl either be that gsd doesn't properly evaluate that config option and suspends anyway, or doesn't configure the logind suspend inhibitor properly
[12:04] <pitti> seb128: yes, it is; if there's no g-s-d running (i. e. just text consoles), lid close will be handled by logind
[12:06] <pitti> seb128: hm, I don't quickly find a loginctl command to show inhibitors, but there's a d-bus call; hang on
[12:06] <seb128> pitti, I found that in my tomboy old notes
[12:06] <seb128> gdbus call --system -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.ListInhibitors
[12:07] <pitti> right, that very
[12:07] <seb128> pitti, http://paste.ubuntu.com/7049587/
[12:07] <pitti>  I get the same here
[12:08] <seb128> same issue on power cord without dock
[12:09] <seb128> so it's not dock specific
[12:09] <pitti> where 5105 ought to be your g-s-d pid
[12:09] <pitti> for me it's unity-settings-daemon, so that seems right
[12:10] <seb128> indeed, that's u-s-d
[12:14] <pitti> seb128: btw, I suggest creating a script which does exit 1 in /usr/lib/pm-utils/sleep.d/00break
[12:14] <pitti> so that it doesn't actually suspend (might ease debugging)
[12:14] <pitti> (needs to be executable)
[12:15] <seb128> pitti, thanks!
[12:23] <desrt> xnox: c99 disagrees with you :p
[12:23] <desrt> as does ieee754
[12:24] <seb128> desrt, good morning, happy friday!
[12:24] <desrt> hi.
[12:25] <xnox> desrt: i'm a human, not a walking set of standards =)
[12:26] <desrt> "damnit jim! ..."
[12:26] <seb128> mhr3_, hey, please fix https://bugs.launchpad.net/ubuntu/+source/libunity/+bug/1274669
[12:26] <ubot2`> Launchpad bug 1274669 in libunity (Ubuntu) "scope-runner-dbus.py crashed with signal 5 in g_variant_new_va()" [Medium,Confirmed]
[12:27] <seb128> mhr3_, I just got is with the same steps as the bug description (typed "disk" and ran gdu in dash)
[12:30] <mhr3_> seb128, sounds like a bug in manpages scope
[12:30] <seb128> mhr3_, who maintains that? ;-)
[12:30] <mhr3_> i wonder the same thing
[12:30] <mhr3_> seb128, plus it's python, just remove it :P
[12:31] <seb128> wfm
[12:31] <seb128> mhr3_, https://errors.ubuntu.com/?package=libunity&period=year ... man, your code is buggy!
[13:14] <Laney> pitti: Hm, php5-gearman-dbgsym in ddebs.u.c has no Description: which makes update-apt-xapian-index segfault here
[13:14] <Laney> do you know how that could have happened?
[13:18] <seb128> oh
[13:18] <Laney> bug #1220013
[13:18] <ubot2`> Launchpad bug 1220013 in apt-xapian-index (Ubuntu) "update-apt-xapian-index crashed with SIGSEGV in File()" [High,Confirmed] https://launchpad.net/bugs/1220013
[13:19] <seb128> Laney, thanks for debugging that ;-)
[13:19] <Laney> yeah I got lost in the code for ages
[13:19] <Laney> but it's too hard
[13:19] <Laney> I'm going to brain dump
[13:19] <seb128> I've moved /bin/true over apt-xapian-index earlier in the cycle
[13:19] <seb128> I was tired to get apport prompting me every morning
[13:19] <Laney> yeah me too
[13:19] <seb128> I though it was only me
[13:19] <Laney> so I decided to debug it :P
[13:19] <seb128> I tried to debug for a bit but failed
[13:19] <seb128> well, to be honest I went "ok, that's not trivial, I can't be bothered spending a morning on it"
[13:20] <Laney> yeah that's why I pinged about the origin of the problem
[13:20] <Laney> it violates policy to not have a description there
[13:20] <Laney> fixing that would make the problem go away for ddebs users anyway afaict
[13:21] <seb128> that might not be a code fix but that would already be a good step toward less annoyance for us ;-)
[13:22] <Laney> yeah
[13:22] <Laney> hopefully mvo or don will see the problem
[13:23] <pitti> Laney: not off-hand; it doesn't look any special to me
[13:24] <Laney> It seems correct in the main archive
[13:24]  * pitti builds php-gearman locally in sbuild with ddebs
[13:28] <pitti> Laney: indeed sbuild -d trusty php-gearman_1.1.2-1build1.dsc reproduces that
[13:28] <Laney> ah
[13:28] <Laney> it has some substvar magic
[13:53] <Laney> pitti: http://paste.ubuntu.com/7050008/ ?
[13:55] <Laney> lunch, will look to upload that when I get back if you think it's ok
[13:56] <pitti> Laney: could certainly do with a test case, but if that fixes it, fine for me
[13:56] <pitti> aah, Description: ${phppear:summary}
[14:42] <seb128> bregma, Trevinho: can you please fix the compiz reduce windows by their decoration height before we start on putting a landing ask for the lockscreen?
[14:42] <seb128> bregma, Trevinho:it's creating test issues, it's driving people crazy, it's annoying everyone, that should be an high priority to fix, before new features
[14:49] <pitti> oh, is that related to terminal windows and the keyring dialog now being too small?
[14:50] <mdeslaur_> yeah
[14:50] <Trevinho> seb128: ok, I move to that now
[14:51] <seb128> Trevinho, thanks
[14:51] <mdeslaur_> it's driving me crazy too
[14:51] <Trevinho> that's why at the beinning i accepted windows to go below bottom side :P
[14:51] <mdeslaur_> heh
[14:52] <seb128> Trevinho, well, you should have let it that way until you could fix it properly I guess ;-)
[14:53] <Trevinho> seb128: probably... but I didn't notice at the beginning :P
[14:53] <Sweetshark> seb128: so, I would like to do one more LO/LO-l10n upload for trusty: To get bumped to upstream 4.2.2, to fix bug 1200277 and bug 1288378. Im still collecting random bits and pieces. Can we do that even after next week?
[14:53] <ubot2`> Launchpad bug 1200277 in libreoffice (Ubuntu) "[LibreOffice] - libreoffice-writer.desktop when drag/drop to desktop, 100% broken. " [Medium,Fix committed] https://launchpad.net/bugs/1200277
[14:53] <ubot2`> Launchpad bug 1288378 in libreoffice-l10n (Ubuntu) "libreoffice-help-en-us no longer built" [Undecided,New] https://launchpad.net/bugs/1288378
[14:53] <Sweetshark> seb128: (random bits and pieces include: fixing the autopkgtests for example)
[14:53] <seb128> Sweetshark, https://wiki.ubuntu.com/TrustyTahr/ReleaseSchedule
[14:54] <seb128> Sweetshark, you have some weeks for bug fixes, etc
[14:54] <mdeslaur_> seb128: no! the bottom side bug was driving me insane too! :)
[14:54]  * mdeslaur_ 's sanity only typically hangs with a thread
[14:55] <Sweetshark> seb128: yep, looked at that already. Im aiming for UI freeze, so that Ill make it for ~DocString Freeze ;)
[14:56] <seb128> Sweetshark, sounds fine to me
[14:57] <seb128> mdeslaur_, we should get lightdm on the session bus, that would give enough things to think about and you would stop focussing on those compiz issues ;-)
[14:57] <mdeslaur_> AAAARRRRGH! :)
[14:57] <seb128> ;-)
[14:57]  * mdeslaur_ demotes seb128 to universe
[14:57] <seb128> :-(
[14:58] <seb128> mdeslaur_, be nice of we might claim chrisccoulson back!
[14:58] <seb128> of->or
[14:58] <mdeslaur_> hehehe
[15:08] <Sweetshark> mdeslaur_: dont be nice
[15:09] <Sweetshark> we want chrisccoulson back anyway.
[15:09] <mdeslaur_> hahahaha
[15:09] <mdeslaur_> Sweetshark: he's high maintenance, you should see the beer and steak bills
[15:10] <Sweetshark> mdeslaur_: yeah, he makes me stand out less.
[15:23] <Laney> pitti: I'll see what I can do about a test
[15:23] <Laney> is there a vcs or just the archive?
[15:24] <pitti> Laney: I just use the UDD branch
[15:24] <pitti> i. e. with actual committing, not just auto-importing
[15:24] <Laney> nod
[15:44] <seb128> pitti, hum, turned out my lid close/suspend issue was local screwup in the config (just as a status update)
[15:44] <pitti> seb128: in your gsettings you mean?
[15:45] <pitti> seb128: good to hear
[15:45] <seb128> yes
[15:45] <seb128> pitti, my ipod is still showing the wrong icon though :p
[15:45] <seb128> if you ever get some free slot to debug that
[15:45] <seb128> (I might in fact have a look to it now, good eow debugging I guess)
[15:46] <pitti> ah, I'm just doing some sponsoring now, so let's have a look
[15:49] <pitti> seb128: so it looks like a normal USB drive, right?
[15:50] <pitti> seb128: sorry, I'm afraid I forgot all context
[15:50] <seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=725390
[15:50] <ubot2`> Gnome bug 725390 in daemon "ipod displayed with an usb key icon" [Normal,Unconfirmed]
[15:50] <pitti> it's an old-style mass storage USB player
[15:50] <seb128> pitti, that has the gvfs-mount output
[15:50] <seb128> but yeah
[15:50] <seb128>   themed icons: [drive-removable-media-usb] [drive-removable-media]
[15:52] <seb128> pitti, http://launchpadlibrarian.net/118396495/gvfs_1.14.0-0ubuntu2_1.14.0-0ubuntu3.diff.gz was the fix you did by then
[15:52] <seb128> pitti, but I guess that "set x-content/audio-player" hack stopped working
[15:53] <pitti> seb128: does your device have ID_MEDIA_PLAYER?
[15:53] <seb128> iirc yes, let me check
[15:54] <pitti> that was supposed to be fixed in https://git.gnome.org/browse/gvfs/commit/?id=4d39b17547648a
[15:55] <seb128> pitti,
[15:55] <seb128> E: ID_MEDIA_PLAYER=apple_video-ipod
[15:55] <seb128> E: ID_MODEL=iPod
[15:55] <seb128> E: ID_MODEL_ENC=iPod
[15:57] <seb128> pitti, hum, https://git.gnome.org/browse/gvfs/log/monitor/udisks2/gvfsudisks2mount.c ... that file didn't change much since
[15:57] <pitti> yes, the code is still there
[15:57] <pitti> seb128: what's the gvfs-mount -i output while the device is mounted?
[15:58] <seb128> pitti, what's in the bugzilla I pointed you, or do you need more?
[15:58] <pitti> seb128: sorry, -li
[15:58] <pitti> seb128: ah right, sorry
[15:58] <pitti> seb128: hm, no, I want hte mount
[15:58] <pitti> or the volume, not the drive
[15:59] <seb128> pitti, http://paste.ubuntu.com/7050647/
[15:59] <pitti> symbolic themed icons:  [drive-removable-media-usb-symbolic]  [
[16:01] <pitti> ok, so no music player
[16:01] <pitti> actually, what's that "media"?
[16:01] <seb128> pitti, https://git.gnome.org/browse/gvfs/commit/monitor/udisks2?id=dff2d84d15b7a62a162031f2da3015e989c0eadc
[16:01] <pitti> as in "USB medium", or as in "music/video"?
[16:02] <seb128> well I guess that doesn't apply here
[16:02] <pitti> seb128: ah, so it gets the icon straight from udisks
[16:02] <pitti> ?
[16:02] <pitti> right, we have a drive
[16:02] <seb128> pitti, well, for symbolic icons, yes
[16:02] <seb128> https://git.gnome.org/browse/gvfs/commit/monitor/udisks2?id=d2273d404cb3e895ba67052dde4a3e85b1c084ba
[16:02] <seb128> that commit doesn't change the non-symbolic codepath though
[16:04] <pitti> seb128: do you have anything "Icon"ish in udisksctl dump?
[16:05] <pitti> (which could override the detection)
[16:05] <pitti> sorry, it's too long ago that I looked at all this stuff, I don't remember the details any more
[16:05] <pitti> so this needs some deeper debugging
[16:05] <seb128>     HintIconName:
[16:05] <seb128> no
[16:05] <seb128> pitti, no worry, I guess I can debug myself, I thouh maybe you would know offhand where to look
[16:52] <bregma> seb128, I have a couple of client-track BPs for UDS that need approval, would you like to do the honours?
[16:53] <seb128> bregma, sure
[16:53] <bregma> do you need a link or is there a magic queue somewhere?
[16:53] <seb128> urls please
[16:54] <bregma> https://blueprints.launchpad.net/ubuntu/+spec/client-1403-unity7-defaults-and-settings
[16:54] <bregma> https://blueprints.launchpad.net/ubuntu/+spec/client-1403-unity8-desktop-session
[16:54] <bregma> c'est ca
[16:57] <seb128> bregma, hum, I can add them, but the first one seems not so much content for a session (I'm also not sure a session is the right venue to decide on defaults, everybody is going to have an opinion but there is no way to determine who is right)
[16:57] <seb128> bregma, the second one, it seems a bit late in the cycle to discuss plans that still apply to this cycle?
[17:00] <bregma> seb128, the second one is more for discussing plans for what will land after release to trusty, since the Touch work does not follow Ubuntu release cycles per se
[17:00] <seb128> bregma, ok, unity8 one approved
[17:03] <bregma> seb128, as to the first one, I would think a public community discussion of the defaults and settings is entirely appropriate, although yes the content may be a bit thin ... it's up to you to approve or reject, I'm completely fine with either one
[17:04] <bregma> really.
[17:04] <seb128> bregma, I'm approving it, the schedule as space, but by experience that doesn't seem like an useful session ;-)
[17:04] <seb128> (it's like the "default apps" sessions we stopped to have)
[17:04] <seb128> you are going to have people who tell you why they hate the integrated menus
[17:04] <seb128> and some who tell you why they hate the local menus
[17:05] <seb128> and that's going to be an argument for the length of the session
[17:05] <seb128> with an akward "so, what do we do"
[17:05] <mitya57> seb128: Hi, can you please look again at my nautilus MP? That blocks moving Flashback to u-s-d, which blocks new g-s-d upload darkxst wants to do.
[17:05] <bregma> yes, I anticipate Fun
[17:06] <seb128> mitya57, hey, I can try have a look when I'm done with what I'm doing, though it's getting late so it might be on monday
[17:06] <seb128> mitya57, I still don't understand why we have that classic .desktop and why those sessions are different from unity in how they start nautilus
[17:08] <mitya57> darkxst: ^ Any idea?
[17:08] <ara_> seb128, I would like to see the unity7 one approved (and attend), as those are very important features for our customers, so it would be a good way to know what's there and what's not
[17:09] <ara_> (high dpi, not local menus)
[17:09] <mitya57> The AutostartCondition is "GSettings org.gnome.desktop.background show-desktop-icons", so that shouldn't be an issue.
[17:11] <seb128> ara_, I don't see what there is to discuss on hi-dpi, the factor should scale with the dpi value, the level is probably better determined by user testing than by a discussion
[17:11] <seb128> bregma, ara_: anyway, approved, let's see how useful that turns out to be
[17:13] <seb128> ara_, I would expect e.g oems to define their default scale value for a particular model and tweak that by model
[17:14] <ara_> seb128, yes, but I would like to know more what's going to happen with gtk apps, and with browsers. currently they don't scale with unity
[17:15] <seb128> ara_, yeah, that one is a good point to discuss, though the GTK factor is an int, so the best we can do is probably to round the value of our factor and apply the gtk value the closest
[17:20] <ara_> seb128, yes, I guess that's the best we can have, but yes, some open discussion during UDS seems like a good thing to have
[17:20] <seb128> ara_, yeah, let's see, doesn't hurt to have a session, even if it's a short one
[18:03] <Laney> ok, got to get a train
[18:03] <Laney> happy weekend!
[18:08] <didrocks> Laney: needing a silo? (kidding :p)
[18:08] <didrocks> happy weekend Laney!
[19:22] <attente> bschaefer: does ibus' candidate window pop up for you?
[19:23] <bschaefer> attente, i dont seem to have ibus running atm :)
[19:23]  * bschaefer stats it up
[19:23] <attente> heh
[19:24] <bschaefer> attente, nope, i also dont get the preedit window :(
[19:25] <bschaefer> let me update though, its been a few days
[19:49] <bschaefer> attente, soo preedit window back, but no candidate window
[19:49] <bschaefer> the candidate window is the little pop up box that show you possibly languages to switch to? (Somewhat like a language switcher?)
[19:52] <attente> bschaefer: candidate window shows the list of characters that match the current preedit text
[19:52] <attente> also called the lookup table in ibus' api
[19:52] <bschaefer> attente, sound like the preedit pop up window to me :), i might be mistaken
[19:52] <bschaefer> i have it though
[19:53] <attente> bschaefer: do you know what you did to get it back?
[19:53]  * bschaefer doesn't really know the correct names for things in ibus haha
[19:53] <attente> i'm fully updated
[19:53] <bschaefer> attente, i just updated
[19:53] <bschaefer> hmm
[19:53] <bschaefer> attente, and killed the daemon
[19:53] <bschaefer> and restarted it
[19:53] <bschaefer> killall ibus-daemon; ibus-setup (which restart it for you with a message)
[19:54] <attente> bschaefer: thanks, that worked
[19:54] <bschaefer> attente, yay!
[19:55] <attente> bschaefer: quite strange though...
[19:55] <bschaefer> attente, hopefully...thats not needed every login though
[19:56] <attente> bschaefer: could be an indicator-keyboard bug
[19:56] <bschaefer> attente, hopefully not...was your system fully updated on the last login?
[19:57]  * bschaefer hopes your daemon was just out of date :)
[19:57] <attente> bschaefer: yes, it was
[19:57] <bschaefer> shoot, it could also be one of the settings possibly attached to the daemon when started
[19:57] <attente> bschaefer: so it's working for you now, right
[19:58] <attente> bschaefer: can you do killall indicator-keyboard-service?
[19:58] <attente> then try again?
[19:59] <bschaefer> yeah
[19:59] <bschaefer> attente, back to preedit window broken :(
[19:59] <bschaefer> or candidate window broken :(
[20:00] <bschaefer> thats not goo
[20:00] <bschaefer> d
[20:01] <attente> bschaefer: ok, at least i know where the problem is thanks to you :)
[20:01] <bschaefer> attente, np! Good luck!