[09:02] <Laney> hey ho
[09:02] <RAOF> Lay low
[09:02] <Laney> happy tuesday ;-)
[09:02] <diwic> Hi, I'm having a problem with the new what-did-you-plug-in dialog: it sometimes shows up *behind* windows instead of at the top.
[09:02] <diwic> I wonder if this is actually a feature of unity to refuse to do so?
[09:02] <diwic> I tried adding a gtk_window_present() call but it didn't help.
[09:03] <seb128> good morning desktopers!
[09:03] <diwic> seb128, good morning
[09:03] <seb128> hey Laney RAOF diwic
[09:04] <seb128> diwic, that's focus stealing preventing, it's so if you are typing some email when the thing happen it doesn't "divert"/"stop" your typing
[09:06] <diwic> seb128, okay...so, you think in this case it's okay to just show the dialog behind e g sound settings ?
[09:06] <seb128> diwic, larsu/Trevinho might be able to help you there, for the wm to do the right thing you usually need to have a timestamp for the event so the wm can compare that to the most recent user action
[09:07] <diwic> seb128, aha, so if I use gtk_window_present_with_time() and time == now it would always show up above?
[09:07] <seb128> right
[09:08] <seb128> well, if nothing happens between "time" and the moment you get on the wm
[09:08] <larsu> diwic: I think it _should_ pop up in the background
[09:08] <seb128> but if the user is typing and happen to time a char in between and you don't get the focus as a result, it's the right thing, you didn't disrupt the workflow
[09:08] <larsu> actually, you do have a time: the time the device was plugged in
[09:09] <larsu> seb128: right, you don't want to break f-s-p
[09:10] <seb128> using that function with the timestamp of the device plug event seems about right
[09:10] <seb128> the plugging of a device is an user interaction
[09:10] <diwic> so I don't think I have a "source" timestamp, only the timestamp from when u-s-d received the notification
[09:12] <diwic> however, the first time the dialog pops up, it always pops up above sound settings, so there's an inconsistency
[09:14] <larsu> hm? Why does it pop up above sound settings?
[09:14] <seb128> diwic, I don't know about that, the wm is not defined without a timestamp, so it's a bit random
[09:17] <diwic> gtk_window_present just calls gtk_window_present_with_time(GDK_CURRENT_TIME).
[09:20] <diwic> which translates to get_user_time, which is the last keypress / mouse pointer interaction
[09:20] <diwic> aha
[09:21]  * diwic tries gtk_window_present_with_time(now)
[10:02] <Laney> mlankhorst: you think this new deinterlacer is worth having?
[10:03] <mlankhorst> well I tested it, it makes interlaced video a whole lot less crappy :-)
[10:03] <Laney> is it go-back-if-it-sucks-able?
[10:03] <Laney> I guess just revert those patches
[10:03] <mlankhorst> yeah
[10:04] <Laney> ok, do it
[10:04] <mlankhorst> but you explicitly have to opt in to use the deinterlacer, it's not enabled by default :-)
[10:04] <Laney> oh it doesn't say that
[10:05] <mlankhorst> well the application has to request deinterlacing, else it falls back to 'weave'
[10:08] <Laney> so 'you' is the application
[10:08] <Laney> do you request the deinterlacing method too?
[10:09] <mlankhorst> there are 2, but the other method is not implemented, and before none were
[10:10] <mlankhorst> motion adaptive temporal deinterlacing with edge-guided spatial interpolation.  Needs fast video hardware.
[10:11] <mlankhorst> the one implemented is 'motion adaptive temporal deinterlacing.  May lead to A/V desync with slow video hardware and/or high resolution.'
[10:13] <Sweetshark> https://www.gitorious.org/gnutls/gnutls/commit/6aa26f78150ccbdf0aec1878a41c17c41d358a3b?diffmode=sidebyside <- scary. just scary what these guys are doing there.
[10:15] <mlankhorst> Laney: oh for reference https://mblankhorst.nl/etc/interlaced.png and with patch and deinterlacing enabled https://mblankhorst.nl/etc/deinterlaced.png
[10:16] <ali1234> it's somewhat less important these days, but weave deinterlacing is never the right choice
[10:16] <ali1234> even if you have an interlaced display, literally anything else is a better choice
[10:16] <mlankhorst> ali1234: that was from a raw video taken from a hd cam on sunday ;-)
[10:17] <ali1234> well it's only relevant for moving images anyway
[10:17] <ali1234> the problem is that weave has a 50% chance of drawing the fields in the wrong order
[10:17] <mlankhorst> also shows a nouveau decoding error in the bottom left
[10:18] <ali1234> double weave is the only reliable method for displaying interlaced video on an interlaced display
[10:24] <ali1234> actually i'd be interested to know if wayland or mir solve this problem
[10:25] <mlankhorst> probably not
[10:43] <seb128> jibel, the new compiz in trusty should fix your vm unity segfault issue, please let us know if it works for you
[11:03] <seb128> diwic, https://code.launchpad.net/~diwic/unity-settings-daemon/lp1287584/+merge/209213 ... can't you get the real timestamp of the device plugged event?
[11:04] <larsu> also, there's an unrelated fix in there (removing launch_sound_settingS)
[11:04] <diwic> seb128, if I understand correctly, it needs to be an X server timestamp. There is nothing X related earlier on. Plugging a jack in is not an X input event.
[11:05] <diwic> larsu, yeah, figured it could slip in :-)
[11:06] <larsu> diwic: we have two options: either fake an x timestamp (it's always monotonic time in practice iirc) or always open the dialog in the background
[11:07] <seb128> the "always in background" sucks, in practice it's easy to miss it if you don't notice your launcher changing
[11:08] <seb128> (I know we do that for e.g update-manager, but I noticed that the non-technical people around me who use Ubuntu never notice it opening)
[11:08] <larsu> good point. And probably in practice people type seldom right after plugging something in
[11:09] <diwic> seb128, agreed, for both.
[11:12] <seb128> diwic, can you have a look at what larsu suggested? faking the timestamp by using the monotonic time?
[11:13] <diwic> larsu, is there a reason getting monotonic time would be better than asking the X server?
[11:14] <larsu> diwic: yes, you can get that time at the time the device is plugged in
[11:14] <larsu> but looking at u-s-d, it looks like you don't even get that time..
[11:14] <larsu> unless it's in some weird proplist ?!
[11:14] <diwic> larsu, nope, pulseaudio does not provide that type of timestamping
[11:15] <larsu> in that case we'll have to do what you did now
[11:15] <diwic> larsu, and neither does alsa-lib IIRC so it would take quite a bit of plumbing to fix
[11:16]  * larsu goes on the record saying he doesn't like it, though
[11:16] <larsu> diwic: yeah, too much effort for focus stealing prevention
[11:16] <larsu> like I said, it might not even be that big of an issue in practice
[11:16] <larsu> and if it is, we can fix it later
[11:17] <diwic> larsu, ok, sounds good to me. Thanks larsu and seb128 for the quick review :-)
[11:18] <larsu> diwic: please explain in the comment above get_server_time() that we want to force the window to appear in the foreground
[11:18] <larsu> otherwise I wouldn't know why you don't just use gtk_window_present
[11:18] <diwic> ok, will do
[11:19] <larsu> thank you
[11:25] <seb128> larsu, diwic: wfm, thanks (I don't like hijacking the focus-stealing-prevention either, but I think in practice it's not likely users switch from plugging hardware to type on keyboard before the dialog is displayed)
[11:25] <diwic> yep, I think we all three agree on that conclusion
[11:27] <jibel> seb128, great, and it's on latest image. I'll try it.
[11:28] <seb128> jibel, thanks
[11:28] <diwic> seb128, btw, should I fight with bzr to try to remove that unrelated commit or are you ok with slipping it in?
[11:29]  * diwic never learnt the advanced bzr stuff.
[11:29] <seb128> diwic, I'm fine having it in, the commit message includes both
[11:29] <diwic> seb128, ok, thanks
[11:30] <seb128> diwic, the way I would "split it" is to bzr uncommit, push that somewhere, then bzr commit the second change again, push that to a second location and make the first one a pre-require
[11:30] <seb128> or just "branch, apply diff, push" for each
[11:30] <seb128> but let's not bother
[11:30] <diwic> seb128, ok, thanks. I'll try to memorise "uncommit" to next time
[11:32] <diwic> larsu, seb128 a little more explanation in comment pushed now
[11:32] <seb128> diwic, saw that, I just switched to approved, I'm going to land it in the next days, thanks
[11:32] <diwic> seb128, ok, thanks!
[11:32] <seb128> yw, thanks for the work!
[11:33] <larsu> diwic: thanks!
[12:06] <jibel> seb128, Trevinho I confirm, no more compiz crash during installer tests. Thanks for the fix!
[12:11] <seb128> jibel, thanks for confirming!
[12:11] <seb128> Trevinho, well done! ;-)
[12:12] <Laney> my phone is going to vibrate itself off the desk while autopiloting
[12:12] <Laney> funny
[12:22] <mlankhorst> ;D
[12:25] <seb128> hum
[12:25] <seb128> is phablet-screenshot supposed to work?
[12:25] <seb128> it hangs on "I: Capturing screenshot with screencap ..." here
[12:25] <Laney> I think it might be broken with mir
[12:28] <seb128> list suggest we need mir 0.1.6
[12:30] <jibel> seb128, it was a hack and doesn't work anymore with android 4.4. screencast/screencap should arrive in mir soon-ish
[12:30] <seb128> jibel, I was just reading that on the phone list, thanks ;-)
[12:31] <Laney> You can go back to sf and get them somehow afaik
[12:33] <seb128> thanks, I'm just going to take a photo of the phone :p
[12:41] <seb128> shrug, wifi timeout (doesn't disconnect but stop transfering datas)
[12:41] <seb128> if somebody said something for me and I did reply to it, please repeat
[12:43] <Laney> nope
[12:45] <seb128> good
[13:01] <Sweetsha1k> o.O "Make openssl verify return errors" in the openssl changelog for 1.0.2. sounds interesting. is this the third 'goto fail' after Apple and gnutls?
[13:03] <ochosi> hey Laney
[13:07] <Trevinho> jibel: thanks for the feedback )
[13:07] <mlankhorst> Sweetshark: I guess, but when checking with 'openssl verify'
[13:22] <xnox> seb128: do we have an expert in QGSettings ? Is it our code?
[13:22] <xnox> seb128: i'm trying to poke bug #1287674
[13:22] <ubot2`> Launchpad bug 1287674 in content-hub (Ubuntu) "content-hub click hook takes forever" [Undecided,New] https://launchpad.net/bugs/1287674
[13:22] <seb128> xnox, larsu wrote it
[13:23] <xnox> seb128: and i think that api is maybe used wrong as it seems to spend most of it's time doing g_settings_new_with_path() https://launchpadlibrarian.net/168322652/content-hub-hook-call-graph.png
[13:25] <seb128> xnox, that seems pretty weird
[13:25] <larsu> interesting. Does it call new_with_path() that often or is the function itself spending time?
[13:25] <larsu> if the latter, I'd gladly pass the ball to desrt
[13:26] <seb128> not sure how to read that graph but it has a "2x", so I guess it's 2 calls?
[13:26] <desrt> new_with_path ought to be relatively fast
[13:26] <seb128> nice graph btw
[13:26] <desrt> it is still opening a file on the disk, though...
[13:26] <seb128> desrt, good morning!
[13:26] <desrt> possibly several, in fact
[13:26] <desrt> (since it could result in a dynamic module -- dconf -- being loaded)
[13:26] <desrt> seb128: hi :)
[13:27] <desrt> congrats on your not-war, europe
[13:27] <desrt> i knew you guys could do it
[13:27]  * desrt woke up to good news this morning :)
[13:27] <xnox> larsu: i don't believe it calls new_with_path at all, only initialises two QGsettings objects, and that's all...
[13:28] <seb128> xnox, that image from you has a "new_with_path" rectangle though?
[13:29] <xnox> seb128: which probably comes from QGsettings implementation? as in the content-hub it doesn't call any g_* functions directly.
[13:29] <seb128> xnox, but what desrt said, that function call might lead to files being read and dconf being loaded
[13:29] <seb128> xnox, right, that's the gsettings api it's using
[13:29] <seb128> that's not a bug though
[13:29] <xnox> right, so i'm chasing wild goose here.
[13:30] <seb128> well, maybe it's the dconf loading which takes time?
[13:30] <desrt> it depends what we mean by 'time' here
[13:30] <seb128> is the content-hub the first user of gsettings in that boot?
[13:30] <xnox> seb128: probably.
[13:30] <larsu> why is it using a path at all?!
[13:30] <desrt> unless you have a spinning disk and you're taking time to pull files off of that, we should be looking at well less than a millisecond
[13:31] <xnox> seb128: the point is that content-hub looks at json content-hub hooks and when it doesn't find any, it bails.
[13:31] <xnox> seb128: larsu: desrt: that run shows, that there was nothing to do. So maybe it shouldn't have initialised dconf at all...
[13:32] <xnox> but things are not slow, if i disable that hook.
[13:32] <seb128> what is that hook doing?
[13:33] <desrt> hmm... some testing shows that _new_path() might actually take as much as 20 milliseconds
[13:33] <desrt> i'll look into that.  thanks for the pointer!
[13:33] <larsu> desrt: new_with_path() is illegal when the schema contains a path, no?
[13:34]  * xnox goes to profile actual first boot
[13:34] <seb128> desrt, that still seems reasonable
[13:34] <desrt> larsu: it lets it succeed if the path you give is the same as the one in the schema
[13:34] <larsu> ah okay
[13:34] <desrt> seb128: it's more than i'd expect...
[13:34] <xnox> seb128: desrt: larsu: here is the "whole meat of the hook" http://bazaar.launchpad.net/~phablet-team/content-hub/trunk/view/head:/src/com/ubuntu/content/service/hook.cpp
[13:34] <seb128> xnox, desrt: larsu: http://bazaar.launchpad.net/~phablet-team/content-hub/trunk/view/head:/src/com/ubuntu/content/service/registry.cpp
[13:34] <desrt> xnox: is that a russian expression? :)
[13:34] <seb128>  m_defaultPeers(new QGSettings("com.ubuntu.content.hub.default",
[13:34] <seb128>                                   "/com/ubuntu/content/hub/peers/")),
[13:35] <larsu> yes, those get created when registry is created
[13:35] <desrt> oh.  hook.cpp.  nvm.
[13:35] <larsu> which happens in the constructor of the hook
[13:35] <xnox> desrt: yes, probably in english "the raw guts" would make slightly more sense, i guess the "essence of the hook" is in that url.
[13:37] <xnox> we were all attributing click hooks slowliness to click written in python, but that seems not the case for this one.
[13:39] <xnox> also can anyone explain, why it has a main loop and a timer?
[13:39] <desrt> what is a click hook, exactly?
[13:41] <xnox> desrt: https://click.readthedocs.org/en/latest/hooks.html
[13:41] <xnox> desrt: something that executes after a click is installed for a user, or on first boot against default user / for all pre-installed clicks.
[13:42] <desrt> so we're talking about something that happens when the user installs a package?
[13:43] <desrt> and you're worried about < 20ms?
[13:43] <seb128> well, in this case it's the first boot that runs the hooks for the installed clicks
[13:43] <desrt> ah... so you do the run on a whole lot of them... and if there is 1000 then that's like 20 seconds, suddenly
[13:43] <xnox> desrt: on armhf, 700MHz emulator, it's like 15 minutes.
[13:43] <seb128> desrt, I don't think the slowness he's seeing under the emulator is in ms magnitude, first boot under the emulator takes like 10mib
[13:43] <seb128> 10min
[13:44] <desrt> so you need to fix your architecture
[13:44] <desrt> if you plan to do mass-updates then you need to run the trigger program only once
[13:44] <seb128> well, I think it's hitting a bug somewhere, it's not clear it's in gsettings/glib though
[13:44] <xnox> desrt: also a single click installation has <<3s total budget
[13:44] <desrt> because all of the thrashing of bringing processes up and down that many times will cost you
[13:45] <seb128> xnox, is any IO taking ages under the emulator?
[13:45] <larsu> you could also not look at settings schmemas in the hook if you don't need them...
[13:46] <desrt> a bit more info: it is indeed loading dconf that's taking the bulk of the time... but the total time is closer to ~8ms than 20 (on my speedy laptop)... the 20 was due to latencies introduced by using a ptrace-based tool for measurements
[13:46] <desrt> still something to look into, but i doubt that this is the source of your trouble...
[13:47] <seb128> right
[13:48] <xnox> desrt: seb128: ok, so i think the source of my trouble is that not a single one click provides Pattern: ${home}/.local/share/content-hub/${id}, yet the hook is executed.
[13:48] <desrt> in general though, starting up and stopping a process is not _that_ cheap
[13:48] <desrt> particularly if you're using a whole raft worth of shared libraries
[13:48] <seb128> right, and everything under the emulator seems to take a magnitude longer than on real hardware
[13:49] <desrt> you should really try to make it so that the hook system can run each binary once for all of the new packages instead of once per package
[13:49] <seb128> xnox, you should talke to kenvandine when he gets online, he wrote content-hub
[13:49] <desrt> this will see a massive improvement in performance
[13:50] <seb128> right
[13:50] <desrt> just one example: creating your second gsettings instance is very fast... since we don't need to dynamically link the dconf module and open the db... we already have it.
[13:55] <xnox> is kenvandine east / australian timezones?!
[13:57] <seb128> xnox, he's in north caroline in the U.S, should be up soon
[13:57] <xnox> seb128: ah, good =)
[14:04] <Laney> hey desrt
[14:04] <Laney> I got a present for you
[14:04] <Laney> the gift of evidence
[14:05] <seb128> Laney, did you do another glib update without test building it first? ;-)
[14:05] <Laney> how dare you
[14:05] <Laney> https://launchpadlibrarian.net/168323664/buildlog_ubuntu-trusty-i386.glib2.0_2.39.91-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:05] <Laney> it was all very deliberate
[14:06] <seb128> you keep uploading stuff that don't build!
[14:06] <mlankhorst> haha
[14:06] <Laney> desrt was suspicious that the failure could happen
[14:06] <Laney> so here is the proof :-)
[14:06]  * mlankhorst had stuff fail in a ppa depending on whether virt or phys was used
[14:10] <desrt> Laney: i386!!!
[14:10] <desrt> wtf
[14:10] <desrt> is this a VM or real metal?
[14:11] <Laney> real
[14:11] <desrt> GLib:ERROR:/build/buildd/glib2.0-2.39.91/./glib/tests/timer.c:57:test_timer_stop: assertion failed (elapsed == elapsed2): (1e-06 == 1e-06)
[14:11] <desrt> my mind is blown.
[14:12] <desrt> i should have added a print to show the exact binary contents of those two things :)
[14:13] <desrt> if i give you a patch to do that, will you resubmit the build?
[14:13] <Laney> can do, but I'll probably not use the primary archive any more...
[14:13] <desrt> :)
[14:13] <desrt> let me check one thing first...
[14:14]  * desrt starts to wonder if g_assert_cmpfloat is to blame
[14:14] <desrt> hmm.  it's shoving the values into long doubles in order to do the compare...
[14:15] <desrt> which means that it's doing software emulation of FP, at least up to a point
[14:15] <desrt> since i guess 32bit systems don't have support for 128bit floats
[14:15] <desrt> Laney: thanks for the info that this is i386..... that really surprises me.
[14:16] <Laney> I believe that we saw this on powerpc, i386 and armhf
[14:16] <Laney> i.e. not amd64 or ppc64el
[14:17] <desrt> all 32bit systems...
[14:17] <desrt> curious :)
[14:19] <ritz> cyphermox, hi, any remote chance for wpasupplicant 2.x in trusty ?
[14:21]  * desrt ponders installing a 32bit ubuntu vm
[14:21] <desrt> Laney: i guess you only try local-building 64bit?
[14:22] <Laney> yeah
[14:22] <Laney> I just started a 32 bit vm running it in a loop
[14:22] <desrt> okay... i'm going to try to install a 32bit vm then
[14:22] <Laney> no bad so far
[14:22] <desrt> oh.. weird
[14:22] <desrt> so not reliable... except on builders :)
[14:22] <Laney> same shit different day
[14:22] <desrt> http://paste.fedoraproject.org/82192/93942955
[14:23] <Laney> maybe try it on a real 32bit system
[14:23] <Laney> a certain seb128 has it
[14:23] <Laney> s/it/one of those/
[14:23] <desrt> seb128: hi seb :)
[14:23] <seb128> desrt, hey
[14:24] <seb128> let me start a build, see if I can get the error
[14:24] <desrt> seb128: can you take this patch i just fpasted, toss it on top of glib, and run the timer test on your 32bit hardware?
[14:24] <seb128> I need to do a full tree build right?
[14:24] <desrt> no...
[14:24] <desrt> only glib/
[14:24] <seb128> ok, let me try
[14:24] <desrt> with default options, the tests are not built
[14:25] <seb128> I'm going to copy the configure line from debuild
[14:25] <desrt> so you will need to manually go into the tests directory and type 'make timer && ./timer'
[14:25] <seb128> k
[14:25] <desrt> or just 'make check' if you don't mind waiting for all the others as well
[14:27] <seb128> why is glib build insulting my locale?
[14:27] <desrt> huh?
[14:27] <desrt> oh... you found the frenchman check we added?
[14:27] <desrt> (no... but seriously... huh?)
[14:27] <seb128> perl: warning: Falling back to the standard locale ("C").
[14:27] <seb128> don't worry, it's not glib itself
[14:28] <desrt> seb128: some of the tests try to run stuff in german
[14:28] <seb128> just the deb tools/packaging
[14:28] <mlankhorst> don't have the language pack installed ? :p
[14:28] <seb128> I've the locale available, I'm using it :p
[14:28] <desrt> but ya... nothing with perl :)
[14:29] <xnox> seb128: Laney: desrt: larsu: I came up with the following patch - which short-circuits any resource allocations, if there is nothing to do... https://code.launchpad.net/~xnox/content-hub/speed-up-no-op/+merge/209273
[14:30] <seb128> xnox, talk to kenvandine ;-)
[14:30] <xnox> and thus main() execution is only 2% of the total run, on default installation and very quick.
[14:30] <desrt> xnox: far better not to run the program at all :)
[14:31] <desrt> pulling up a process with lots of shared libraries is time consuming (and in particular, qt is quite bad here)
[14:31] <kenvandine> xnox, awesome... thanks!
[14:31] <xnox> kenvandine: by design, hooks play catch up.
[14:31] <xnox> kenvandine: sorry, desrt ^
[14:31] <seb128> desrt, should I get the test to fail or just give you the output on an OK run?
[14:31] <Laney> dude
[14:31] <Laney> https://qt-project.org/doc/qt-5.0/qtcore/qdir.html#filePath
[14:32] <xnox> kenvandine: see merge proposal, and the related analysis on the bug report.
[14:32] <xnox> kenvandine: not sure how/what the hook is suppose to do, maybe i'm overlooking something.
[14:32] <kenvandine> i thought the hook only ran on packages that specified content-hub in the hooks
[14:33] <kenvandine> it registers source/dest apps with the hub
[14:33] <desrt> seb128: there should be no output if it was OK
[14:34] <desrt> seb128: i'd like to see the result of a failure
[14:34] <seb128> desrt, no way to get it to fail
[14:34] <desrt> wtf
[14:34] <desrt> why must things only fail on builders?
[14:34] <seb128> desrt, http://paste.ubuntu.com/7033292/
[14:34] <desrt> uhhh
[14:34] <desrt> wait...
[14:35] <seb128> desrt, I'm running it in"while ./timer; do echo "ok"; done" loop
[14:35] <desrt> seb128: did you modify the patch?
[14:35] <seb128> no
[14:35] <desrt> so what the hell
[14:35] <seb128> I quilt pushed it
[14:35] <desrt> what the honest fuck is going on here
[14:36] <desrt> that print statement is inside of +  if (elapsed != elapsed2)
[14:36] <desrt> so it MUST be the case that these two are unequal
[14:36] <desrt> but then later:
[14:36] <desrt>    g_assert_cmpfloat (elapsed, ==, elapsed2);
[14:36] <desrt> and no failed assert
[14:36] <desrt> and looking at the binary output, we see that they are not unequal.... they are bitwise exactly the same
[14:37] <desrt> seb128: what happens if you run without my patch?  does the assert hit in that case?
[14:37] <desrt> also: does disabling optimisation help?
[14:37]  * desrt starts to suspect compiler bugs
[14:37] <seb128> Abandon (core dumped)
[14:37] <seb128> glib/tests/timer.c:57:test_timer_stop: assertion failed (elapsed == elapsed2): (1e-06 == 1e-06)
[14:38] <desrt> neat!!
[14:38] <Laney> yay
[14:38] <desrt> so this looks like a gcc bug...
[14:38] <seb128> every time
[14:38] <seb128> test_timer_stop: assertion failed (elapsed == elapsed2): (2e-06 == 2e-06)
[14:38] <desrt> i bet it has to do with the fact that the float is a return value
[14:38] <seb128> number changed on that run, but it fails reliably
[14:38] <desrt> so it's probably in some register...
[14:38] <desrt> and if we use it directly after it returns, we get it from the register
[14:39] <xnox> kenvandine: no, user-hook is executed at the end of easy user-level click installation finish.
[14:39] <desrt> else, we get it from memory again, which forces the bug to go away
[14:39]  * Laney tries on i386 porter machine
[14:39] <desrt> oh.... wait a minute......
[14:39] <desrt> i think i know about this
[14:39] <xnox> kenvandine: reading the code more, it looks like registry is initialised and enumerated, regardless of the sanity check that contentDir.exists() in the Hook::run()
[14:39] <desrt> iirc there is some implementation-defined 'extra precision' in fp registers
[14:39] <desrt> so a double may not be a double...
[14:39] <desrt> it might be a double plus some extra
[14:40] <kenvandine> xnox, yeah, your patch is a good idea
[14:40] <desrt> i bet the compiler is not being careful about this
[14:40] <ochosi> Laney: hey there, i don't wanna break your concentration here, just a quick question, how do things from https://launchpad.net/ubuntu/trusty/+queue proceed? just asking you cause you uploaded light-locker-settings and i was wondering whether there was anything i could do to help get this in trusty asap (as it's a new app it'd be good to get wider testing than those testers that manually add a PPA for it)
[14:40] <xnox> kenvandine: ideally, we'd do the contentDir calculation and check early at Hook initialisation.
[14:40] <Laney> ochosi: you need an archive admin, best to ask in #ubuntu-release
[14:40] <xnox> kenvandine: such that it bails to even allocate, not sure that is possible. Or like move registry allocation past check.
[14:40] <ochosi> Laney: ah i see, thanks!
[14:41] <xnox> kenvandine: right, well if you think my patch is a good idea, i'm happy with that. I'm not a C++/Qt developer at all though =)
[14:41]  * desrt imagines a coming argument with the gcc guys over what can be expected or not from floating point operations
[14:41] <xnox> hence hammering this down with a valgrind =) and monkey patching it.
[14:41] <kenvandine> i think it is, i'll look a bit closer in a bit
[14:42] <kenvandine> it's clearly a good idea to bail earlier if possible
[14:42] <seb128> desrt, have fun ;-)
[14:42] <seb128> desrt, let me know if you need more debug info from me
[14:43] <desrt> seb128: one more thing for you to check, please
[14:43] <seb128> sure
[14:43] <desrt>   gdouble elapsed, elapsed2;
[14:44] <desrt> add 'volatile' in front there
[14:45] <seb128> desrt, that fixes it
[14:45] <desrt> of course it does
[14:45]  * desrt beats gcc
[14:45] <desrt> okay... pretty sure i fully understand the issue now... only question is if i'm right or not.
[14:45] <desrt> wrt. what the "proper behaviour" is according to the C spec
[14:45] <seb128> either way you have a solution ;-)
[14:46] <desrt> seb128, Laney: thanks
[14:46] <seb128> yw!
[14:46] <desrt> hmm.  spec says
[14:46] <desrt>     Except for assignment and cast (which remove all extra range and
[14:46] <desrt>     precision), the values of operations with floating operands and
[14:47] <desrt> ie: assignment (as we do) should lose the extra precision
[14:56] <mpt> Ha, Nautilus’s Properties window describes the filetype of a PNG as “png (The PNG image format)”
[14:56] <mpt> No, Nautilus, that’s not what png stands for
[14:58] <ali1234> what do you want? "PNG (Not GIF)"
[15:00] <seb128> mpt, my nautilus  states "PNG Image"
[15:01] <mpt> ali1234, heh. If it’s going to use that many words at all, I’d expect those words to be Portable Network Graphics.
[15:03] <seb128> mpt, oh, in the "Image" tag
[15:03] <desrt> seb128, Laney: behold http://ur1.ca/gr0p6
[15:03] <desrt> fails for me when i build with -m32 -O2
[15:04] <seb128> desrt, take that gcc? ;-)
[15:04] <desrt> seb128: filing the bug as we speak :)
[15:05] <Laney> oh yes, O2 is what I was missing
[15:05] <desrt> seb128: can you tell me your gcc version?
[15:05] <seb128> gcc version 4.8.2 (Ubuntu 4.8.2-16ubuntu4)
[15:12] <desrt> oh jesus christ
[15:12] <desrt> using -std=c99 "fixes" the problem
[15:15] <Laney> doesn't for me (with the timer test)
[15:15]  * desrt leaves out mention of that part in the bug report
[15:16] <desrt> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60413 let the games begin
[15:16] <ubot2`> gcc.gnu.org bug 60413 in c "extra precision not properly removed on assignment of return value" [Normal,Unconfirmed]
[15:20] <desrt> Laney: thanks again for putting up with these problems... there is a patch on the bug that should fix it 'once and for all'
[15:20] <desrt> hopefully we also get a gcc fix out of it... but somehow i'm doubtful
[15:21] <desrt> i expect to get told that if i want a C compiler that complies with standards then it is my responsibility to supply -std=c99 and/or be told that i'm an idiot for doing a comparison on floats without an epsilon
[15:27] <desrt> oh.. interesting
[15:28] <desrt> -fexcess-precision
[15:28] <desrt> default value is 'fast'
[15:28] <desrt> and documented as "this causes the compiler to violate the spec"
[15:28] <desrt> fun.
[15:29] <desrt> seems that the gcc developers consider 32bit intel machines to be broken in that they have no instruction to truncate the precision without forcing it through memory
[15:29] <desrt> so they elect to violate the spec in the name of performance
[15:29] <desrt> since there is no 'fast' way to do this on i686
[15:29] <ogra_> Laney, larsu, is anyone working actively on the evo "black  frame" bug btw ? it got so silent around this recently :)
[15:30] <Laney> https://code.launchpad.net/~larsu/ubuntu-themes/dont-clear-toolbar-bg/+merge/209269
[15:30] <seb128> oh, it's meeting time!
[15:30] <seb128> qengho, Sweetshark, mlankhorst, Laney, tkamppeter, desrt, attente, larsu, kenvandine: hey ;-)
[15:31] <Sweetshark> o/
[15:31] <ogra_> Laney, thanks !
[15:31] <larsu> ogra_: I fixed it today. Sorry for the delay
[15:31] <larsu> turned out to be a one-liner, too
[15:31] <larsu> but really, evo is doing evil things
[15:31] <larsu> seb128: meeting \o/
[15:32]  * kenvandine waves
[15:32] <mlankhorst> hey
[15:32] <ogra_> larsu, NP, i get along, just wanted to knwo whats happening with it
[15:32] <ogra_> yeah
[15:32] <ogra_> definitely
[15:32] <seb128> ogra_, it's .css, you can just edit locally until it lands (should be this week)
[15:32] <seb128> I hope everyone is doing well
[15:32] <seb128> let's start the meeting
[15:33] <seb128> qengho, hey
[15:33] <ogra_> seb128, already got it open in vi ;)
[15:33] <qengho> Hey!
[15:33] <qengho> Okay, typing in real time.  Sorry.
[15:33] <qengho> - high-DPI mostly licked. In PPA.
[15:33] <desrt> \o/
[15:33] <qengho> - Cr touch support in progres.
[15:34] <qengho> - Trying to release new 33.0.1750.146 today.
[15:34] <qengho> EOF
[15:34] <seb128> can you share the ppa url? ;-)
[15:34] <qengho> https://launchpad.net/~cmiller/+archive/chromium-browser-dev-daily
[15:35] <qengho> It's ahead of stable, and so sets home to a temp dir, to keep your profile intact.
[15:35] <seb128> great
[15:35] <seb128> qengho, thanks
[15:35] <seb128> Sweetshark, hey
[15:35] <Sweetshark> - Build and bumped LibreOffice 4.2.2 rc1
[15:35] <Sweetshark> - adjusted and backportes fix for bug 1200277 on LibreOffice 3.5/precise and 4.2/trusty and pushed bothto ppa
[15:35] <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
[15:35] <Sweetshark> - MIRs: bug 1285424, bug 1276252
[15:35] <ubot2`> Launchpad bug 1285424 in hunspell-fr (Ubuntu) "[MIR] hunspell-fr" [Undecided,New] https://launchpad.net/bugs/1285424
[15:36] <ubot2`> Launchpad bug 1276252 in fonts-crosextra-carlito (Ubuntu) "[MIR] Caladea and Carlito fonts, essential fallback fonts" [Undecided,New] https://launchpad.net/bugs/1276252
[15:36] <Sweetshark> - FFEs: bug 1286216
[15:36] <ubot2`> Launchpad bug 1286216 in Ubuntu "[needs-packaging] [FFE] new package libreoffice-dictionaries" [Wishlist,Confirmed] https://launchpad.net/bugs/1286216
[15:36] <Sweetshark> - some upstream/bibisect triage
[15:36] <Sweetshark> - coordination on various comments to UK Cabinet Office proposal to move to ODF only for government use
[15:36] <Sweetshark> - upstream director work: distributing resposibilities, coord. hackfests/conferences etc.
[15:36] <Sweetshark> EOF
[15:36] <seb128> Sweetshark, you got the ffe approved for the dicts it seems, let me know if/when you need sponsoring
[15:36] <Sweetshark> seb128: aye
[15:37] <Laney> soon would be good
[15:37] <seb128> right
[15:37] <seb128> Sweetshark, thanks
[15:37] <seb128> mlankhorst, hey
[15:37] <mlankhorst> debugging winepulse issue that popped up today, turned out to be a issue in pulseaudio 5.0. preparing mesa 10.1 rc3 + vdpau fixes + running tests, testing nouveau on maxwell, testing synaptics 1.8 branch, maybe ffe it after it releases a rc. Trying to lower bug count, many dupes. :(
[15:37] <mlankhorst> ^D
[15:38] <seb128> thanks
[15:39] <seb128> good to see bug work, seems about the right focus for after ff ;-)
[15:39] <seb128> mlankhorst, thanks
[15:39] <seb128> Laney, hey
[15:39] <Laney> • Test & release phone update fixes. A problem with ubuntu-download-manager got through, but was quickly fixed afterwards.
[15:39] <Laney> • Finish up the 'reset API' for system-settings, which took too much time but now works.
[15:39] <Laney> • Upload the gstreamer split for phone guys, still need to alter seeds
[15:40] <Laney> • Work on landing the 'ringtone in AS' stuff for the phone, testing appreciated
[15:40] <Laney> • Review many FFes
[15:40] <Laney> • Help mardy with a new version of syncevolution sporting UOA support, waiting for testing feedback
[15:40] <Laney> • gnome update: glib2.0 (ftbfs, ubuntu2 coming in a minute)
[15:40] <Laney> • to do: webkitgtk
[15:40] <Laney> ⚖
[15:40] <desrt> glib2.0 ftbfs :(
[15:40] <Laney> NO MORE!
[15:40] <desrt> Laney: did you upload with the patch from the bug?
[15:40]  * seb128 sends tea and milk in Laney's direction to see if that helps with the ffe to add a "hide/show indicator-sound" to u-c-c
[15:40] <desrt> the 'volatile' thing?
[15:40] <Laney> will be doing
[15:41] <desrt> Laney: you're a doll :)
[15:41]  * desrt tries to have that in next release, in any case
[15:41] <Laney> seb128: i don't see it
[15:41] <seb128> Laney, https://bugs.launchpad.net/indicator-sound/+bug/829648
[15:41] <ubot2`> Launchpad bug 829648 in The Sound Menu "[ffe] No easy way to turn the sound menu on/off" [High,In progress]
[15:41] <seb128> shrug, status should be New?
[15:42] <seb128> (that rule is annoying, especially when turning a bug being worked in a ffe)
[15:42] <Laney> I looked for 'indicator'
[15:42] <Laney> nm
[15:42] <seb128> thanks ;-)
[15:42] <seb128> Laney, is there anything else that should potential trouble on the ffe list otherwise?
[15:42] <seb128> we got unity hi-dpi in
[15:43] <seb128> still the lockscreen change to land if we can
[15:43] <seb128> gnome-desktop transition maybe, I know the GNOME guys want it but it seems to have potential for issues :/
[15:43] <Laney> cyphermox just asked for some large wpa_supplicant update
[15:43] <cyphermox> hehehe
[15:44] <ritz> cyphermox, is this wpa 2.x ?
[15:44] <Laney> dunno about the lock screen
[15:44] <cyphermox> ritz: yes
[15:44] <Laney> is it likely to be ready without issues?
[15:44] <ritz> sweet, thank you :)
[15:44] <cyphermox> Laney: yes.
[15:45] <seb128> Laney, https://bugs.launchpad.net/unity/+bug/1282798
[15:45] <ubot2`> Launchpad bug 1282798 in Unity "[FFe] Provide a lock screen and unlock dialogs in Unity" [Medium,In progress]
[15:45] <seb128> Laney, it's a bit late, but a good improvement and robert_ancell reviewed it and seems to think it's worth trying to land
[15:46] <seb128> would spare us having to maintain gnome-screensaver and be more robust/integrated
[15:46] <mhr3_> seb128, uuh
[15:46] <mhr3_>   ubuntu-settings:amd64 conflicts with ubuntu-session:amd64
[15:46] <mhr3_>     ubuntu-session:amd64 conflicts with ubuntu-settings:amd64
[15:46] <Laney> 'more robust'?
[15:47] <seb128> the locking would be part of the compositor
[15:47] <seb128> not a separate process
[15:47] <seb128> no hack to get focus, etc
[15:47] <seb128> mhr3_, we are in a meeting, try #ubuntu-devel please
[15:47] <seb128> Laney, anyway, we can discuss it off meeting
[15:47] <seb128> Laney, thanks
[15:47] <seb128> tkamppeter, hey
[15:48] <tkamppeter> - Google Summer of Code 2014: Put up additional project ideas: IPP-over-USB support, PPD-less printing/IPP Everywhere support in GTK print dialog, and PPD generator for IPP Everywhere.
[15:48] <tkamppeter> - Discussion of how IPP-over-USB could be implemented under Linux (on OpenPrinting mailing list).
[15:48] <tkamppeter> - OpenPrinting Summit 2014: Moved to August 12-15, 2014 in Toronto, Canada due to my US visa problem. Made appropriate announcements on OpenPrinting web site and OpenPrinting mailing list.
[15:48] <tkamppeter> - Fixed search facility on the OpenPrinting web site, search for the Brother DCP-330C returned the entry for the Canon CP-330.
[15:48] <tkamppeter> - Bugs.
[15:48] <seb128> desrt, you won openprinting summit!
[15:48] <mlankhorst> they're the same aren't they? :P
[15:48] <desrt> yay.
[15:48] <seb128> ;-)
[15:48] <desrt> what do i get?
[15:49] <tkamppeter> desrt, are you living in Toronto?
[15:49] <larsu> desrt: a printing summit in TO
[15:49] <desrt> oh
[15:49] <desrt> nice :)
[15:49] <seb128> desrt, the opportunity to be proud of Toronto ;-)
[15:49] <Laney> PC load letter
[15:49] <seb128> tkamppeter, he is
[15:49] <desrt> seb128: canada is phasing out government cheques right now
[15:49] <desrt> toronto is not a good city to be in for paper use :)
[15:49] <cyphermox> lp1 is on fire
[15:49] <seb128> haha
[15:50] <seb128> tkamppeter, thanks
[15:50] <seb128> desrt, your turn ;-)
[15:50] <desrt> not much to report...
[15:50] <desrt> did two releases and fixed a lot of bugs
[15:50] <tkamppeter> cyphermox, therefore we need IPP-over-USB.
[15:50] <desrt> also helped some people tracking down tricky issues, etc.
[15:51] <desrt> the glib blocker list for 2.40 is now either all-fixed, or with-patches-waiting-for-testing
[15:51] <desrt> (eof)
[15:51] <seb128> desrt, what's the status of the one gsettings bug?
[15:52] <desrt> seb128: in progress still... it's slowing turning into me having to reinvent gsignal
[15:52] <seb128> please no crazy solution for this cycle ;-)
[15:52] <desrt> which is pushing me toward thinking that we may want to (soon) add support for cross-thread dispatching to gsignal
[15:52] <desrt> ya...
[15:52] <desrt> i'll keep it self-contained.... for now :)
[15:52] <seb128> ;-)
[15:53] <seb128> desrt, thanks
[15:53] <seb128> attente, hey
[15:53] <desrt> every time desrt writes an observer pattern to workaround insufficient functionality/performance in gsignal, god kills a kitten
[15:53] <attente> seb128, hey
[15:53] <larsu> desrt: god?
[15:53] <attente> indicator-keyboard and unity-gtk-module bugs, with help from desrt
[15:53] <desrt> larsu: ya... don't worry.... the kittens are safe.
[15:53] <larsu> ;)
[15:53] <attente> trying to fix the gnomecompat compiz plugin under unity
[15:53] <attente> EOF
[15:54] <seb128> hum, gnomecompat
[15:54] <tkamppeter> desrt, I forgot something, you are naturally invited to the OP Summit (and Canonical saves a lot of money as this time you do not need to travel).
[15:55] <seb128> I hope that's not too much work, I don't think we care much about that one
[15:55] <attente> seb128, it causes some problems when trying to rebind the terminal keys too
[15:56] <seb128> oh ok, that's what Trevinho was having issue with the other day I think
[15:56] <desrt> tkamppeter: i'm not sure if i would be able to make a valuable contribution
[15:56] <desrt> tkamppeter: and there is a good chance i will be away from canada at the time anyway
[15:56] <seb128> attente, desrt: what's the status of https://code.launchpad.net/~attente/unity-gtk-module/gtk-enable-mnemonics/+merge/207752
[15:57] <desrt> i gave it my "i'm not totally happy, but i won't block it further"
[15:57] <seb128> seems like desrt has some comments and attente addressed them, need another look from desrt?
[15:57] <seb128> desrt, attente did some tweaks since
[15:57] <desrt> ahh
[15:57] <Trevinho> attente: nice :)
[15:57] <desrt> i didn't realise that
[15:57] <desrt> i'll look over it again
[15:57] <seb128> thanks
[15:57] <desrt> attente must hate me by now :)
[15:57] <seb128> lol
[15:57] <seb128> attente, thanks
 review?
 rewrite your code!
 review?
 rewrite your code again!
 review?
[15:58] <attente> desrt, grar!
[15:58] <qengho> Hah
[15:59] <seb128> ;-)
[15:59] <seb128> thanks attente
[15:59] <seb128> larsu, your turn
[15:59] <larsu> whee
[15:59] <larsu> added menubars to rhythmbox and nautilus
[15:59] <larsu> made sound indicator hideable from the control center
[16:00] <larsu> and a ton of bugfixes: evince's presentation mode showed a menu bar and its popup menus were incomplete
[16:00] <larsu> and I fixed all of my theme-issue backlog
[16:01] <larsu> except for the o-s ones :-/
[16:01] <larsu> I think that's it. eof
[16:01] <seb128> \o/ (:-- for o-s)
[16:01] <seb128> nice work on the menubars, quite some nice user feedback on forums, g+, etc about getting those back
[16:01] <seb128> larsu, thanks
[16:02] <seb128> kenvandine, hey
[16:02] <kenvandine> Preparing content-hub branches to land
[16:02] <kenvandine>  * includes getting branches for all the apps that use the hub
[16:02] <kenvandine>  * I have a branch for ubuntu-system-settings ready as well, but we need to coordinate landing
[16:02] <kenvandine>  
[16:02] <kenvandine> Preparing for an app dev week session on content exchange
[16:02] <kenvandine>  /EOF
[16:03] <seb128> kenvandine, feel free to submit your branch for review if you want, so we can already start looking at the changes
[16:03] <seb128> do you have a ppa or something with those changes?
[16:04] <kenvandine> seb128, not really yet... sorry just started another meeting :)
[16:04] <seb128> kenvandine, thanks
[16:04] <seb128> no worry!
[16:04] <seb128> so my turn
[16:04] <seb128> • desktop bug fixes (gtk, gnome-bluetooth, gnome-control-center, yelp, nautilus, file-roller, shared-mime-info)
[16:04] <seb128> • investigated some build issues/trusty-proposed->trusty migration problems, helped to fixes some of those
[16:04] <seb128> • sponsoring/patch pilot
[16:05] <seb128> • review ubuntu-system-settings changes (main ones being click support, which needs more work, and first start wizard start
[16:05] <seb128> • test bug fixes from others (unity hidpi, traditional menubars for nautilus and rhythmbox, evince bugfixes)
[16:05] <seb128> • backported some extra fixes for unity-control-center
[16:05] <seb128> • organized CI train landing for some indicators fixes
[16:05] <seb128> • quite some bug triage to build a "to fix for the LTS" list

[16:06] <desrt> seb128: good job.
[16:06] <desrt> another fine meeting completed
[16:06] <seb128> desrt, thanks ;-)
[16:06] <seb128> it's not complete yet!
[16:06] <seb128> questions/comments?
[16:06] <desrt> oh.  right.
[16:06] <seb128> ;-)
[16:06] <desrt> i have a comment
[16:06] <desrt> which is: another fine meeting in progress
[16:07] <seb128> good comment ;-)
[16:07] <seb128> on that note let's call it a wrap
[16:07] <seb128> thanks everyone!
[16:07] <Laney> cheers!
[16:10] <Trevinho> seb128: do you have any idea why the nautilus desktop often gets closed? I mean, nautilus itself work, but the desktop window is not available anymore after some time...
[16:11] <Trevinho> seb128: so I need to nautilus -q, and again reaload it...
[16:11] <seb128> Trevinho, no, is something getting on top of it?
[16:12] <Trevinho> seb128: no it's not mapped at all
[16:12] <seb128> weird
[16:12] <seb128> is the gsettings key changing?
[16:12]  * Trevinho has just done the wrong thing of reloading nautilus
[16:12] <Trevinho> seb128: but it will happen again soon
[16:12] <seb128> I never saw that issue and we got no bug report about it
[16:12] <Trevinho> I don't know if this has some deal with the fact that I reload compiz pretty often
[16:13] <Trevinho> but in our team I guess we get that everyday
[16:13] <Trevinho> so, mhmh, might be some compiz reloading that makes it go away
[16:13] <seb128> yeah, maybe
[16:13] <seb128> as said I saw 0 report about it
[16:13] <Trevinho> it's a developers case :D
[16:13] <Trevinho> I'm getting that since years I think...
[16:14] <Trevinho> just never bothered about that :D
[16:19] <desrt> tell me i didn't call that
[16:19] <desrt> <gcc devs> use -std=c99 if you want standards-compliant behaviour
[16:19] <desrt> head, meet desk
[16:22] <czajkowski> aloha anyone done an update today on trust and lost their keyboard settings? my "@ are all skewed again but shows I'm on UK keyboard
[16:31] <desrt> Laney: so it seems like maybe we should reevaluate our compiler flag defaults...
[16:31] <desrt> the reason that this is not a problem on amd64 is because on amd64 we know that we have sse2 available... we don't know that on 32bit, even with -march=i686 because sse2 was only added at pentium 4
[16:32] <desrt> so the only options available to the compiler are to play fast and loose with the math or to be __REALLY__ slow by using the i387 FPU
[16:32] <Trevinho> didrocks, popey: are your window buttons corruptions fixed now?
[16:33] <desrt> do we really still need to be back-compatible to pentium pro?
[16:33] <didrocks> Trevinho: the issue was that the decor plugin was still loaded
[16:33] <Trevinho> didrocks: ah, weird ( I mean I've added migration scripts around)
[16:33] <Trevinho> same for popey ^ ?
[16:33] <didrocks> Trevinho: yeah, didn't work for my case though
[16:33] <didrocks> not sure
[16:33] <popey> Trevinho: i need to restart unity to find out, will find out when I go home ☻
[16:34] <Trevinho> ok :)
[16:34] <Trevinho> anyway, the way we load the textures now is the same we do for the decorations themselves, so... it should work
[16:37] <seb128> desrt, I don't think we care about pentium pro much, but that would be something for ubuntu-devel list discussion I guess, the foundation team probably has more of an opinion on that
[16:38] <Laney> desrt: no comment, I guess we get to accept GCC's argument here and work around broken things when we find them
[16:39] <desrt> i'm not done with gcc :)
[16:44] <desrt> so it seems that if we changed our default flag to -march=pentium3 then this would go away
[16:45] <desrt> it means we lose support for pentium2 and pentium pro (pentium+mmx is already dead since it is i586, not i686)
[16:45]  * desrt just asked gcc to make people suffer for having too old -march... we'll see how that goes...
[16:45] <seb128> didrocks, was https://code.launchpad.net/~didrocks/ubuntu-themes/bump-standards-version/+merge/207926 for testing or something you want to land?
[16:46] <didrocks> seb128: we need to have the theme ready first
[16:46] <didrocks> but no time until we get a promotable image :/
[16:46] <seb128> didrocks, to bump the standards version?
[16:47] <didrocks> seb128: this was stack on the other change
[16:47] <seb128> k
[16:47] <seb128> we are landing desktop fixes today
[16:47] <seb128> I guess I can let you that for when you are going to do the touch landing then
[16:47] <didrocks> yeah
[16:47] <didrocks> no hurry on that one I guess
[16:54] <Laney> desrt: hmm, test_monitor_directory has hung in my current test build because inotify_add_watch is ENOSPCing
[16:54] <Laney> I don't get why it didn't error out
[16:58] <Laney> it's looping poll → timeout → inotify_add_watch → enospc
[17:04] <Sweetshark> seb128: http://people.canonical.com/~bjoern/trusty/libreoffice-dictionaries_4.2.1-0ubuntu1_source.changes
[17:04] <seb128> Sweetshark, you tested it in a ppa right? ;-)
[17:06] <Sweetshark> seb128: that has been deployed to some ~5000 users in the ppa, yeah. (modulo bumping the version from 4.2.1-0ubuntu1~trusty1 to 4.2.1-0ubuntu1)
[17:06] <seb128> Sweetshark, great
[17:15] <desrt> Laney: file that as a bug please.
[17:15] <Laney> am doing
[17:15] <desrt> so.... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[17:15] <ubot2`> gcc.gnu.org bug 323 in middle-end "optimized code gives strange floating point results" [Normal,Suspended]
[17:16] <desrt> 3 digit bug number with 50+ dups, bug status "SUSPENDED" (i've never even seen that before....)
[17:16] <desrt> looks like i'm not the only one upset about this :)
[17:17]  * desrt wonders why it is too much to ask to have correct code be output when he types "cc -c src.c"
[17:17] <desrt> ...and not need to detect and use some weird compiler-specific flags in order to get it to DTRT
[17:51] <seb128> Sweetshark, still there?
[17:51] <seb128> Sweetshark, http://people.canonical.com/~bjoern/trusty/libreoffice-dictionaries_4.2.1-0ubuntu1_source.changes has distribution UNRELEASED
[17:51] <seb128> Sweetshark, can you fix that?
[17:51] <tkamppeter> jasoncwarner is talking about a systemd Blueprint, will systemd replace Upstart
[17:52] <tkamppeter> ?
[17:52] <jodh> tkamppeter, jasoncwarner: https://blueprints.launchpad.net/ubuntu/+spec/core-1403-systemd-transition
[17:52] <seb128> tkamppeter, http://www.markshuttleworth.com/archives/1316
[17:53] <jasoncwarner> wow, you guys are fast. I didn't have to link to anything ;)
[17:53]  * Laney smells a jodh highlight
[17:53] <jodh> Laney: ;)
[18:00] <popey> Trevinho: yes, controls fixed! Thank you
[18:00] <Trevinho> popey: cool
[18:00] <Trevinho> popey: can you also check if you've decor in the list of the enabled plugins?
[18:00] <tkamppeter> jodh, seb128, jasoncwarner, that is great news! Upstart is buggy in terms of socket activation of daemons and on Debian OdyX has finished to patch CUPS for socket activation via systemd!
[18:00] <Trevinho> popey: gsettings get org.compiz.core:/org/compiz/profiles/unity/ active-plugins
[18:01] <tkamppeter> +inf for systemd as PID1!
[18:01] <seb128> tkamppeter, that change is not going to happen before several cycles most likely, it needs lot of planning and work, so it's not a workaround for upstart issues we have atm or for that LTS
[18:02] <tkamppeter> xnox, are you around? We still need your Upstart fix for Trusty.
[18:09] <seb128> Sweetshark, seems you are not around, I'm rebuilding the sources/fixing it here, don't worry
[18:30] <seb128> hum
[18:30] <seb128> https://launchpadlibrarian.net/168346937/buildlog_ubuntu-trusty-amd64.gnome-control-center_1%3A3.6.3-0ubuntu53_FAILEDTOBUILD.txt.gz
[18:30] <seb128> "/usr/bin/ld.bfd.real: cannot find -lwayland-egl"
[18:30] <ogra_> lovely
[18:31] <seb128> tjaalton, mlankhorst: could you have a look?
[18:31] <seb128> g-c-c didn't change so I guess that's on the xorg stack side
[18:31] <attente> ChrisTownsend, hi, could use some advice re: https://code.launchpad.net/~attente/compiz/1284532/+merge/208908
[18:38] <ChrisTownsend> attente: Sure, what's up?
[18:38] <attente> ChrisTownsend, i'm not really sure how to do this in a way that will only affect unity under ubuntu
[18:39] <attente> we want to disable those options, but those options are generated at compile time
[18:39] <ChrisTownsend> attente: I'm not sure why a distro patch can't work.  It will get applied before building.
[18:40] <attente> because we want to make sure that it's still included for the same of other desktops like gnome-fallback
[18:40] <attente> *for the sake of
[18:41] <ChrisTownsend> attente: Ahhhhh, I see the dilemma.
[18:41] <attente> yeah...
[18:41] <ChrisTownsend> The problem being that someone uses Ubuntu and then installs a different DE.  Yeah, a distro patch won't work.
[18:42] <ChrisTownsend> Paging Mr. Trevinho
[18:42] <ChrisTownsend> Any ideas? ^^^^
[18:43] <attente> hmm.. i just had an idea actually
[18:44] <Trevinho> mh, I see you've changed some default settings, can't we just ignore these from the xml?
[18:44] <ChrisTownsend> attente: Ok.  I was thinking we'd need something runtime.
[18:44] <Trevinho> BTW, best solution imho would be making a compiz-unity package at this point
[18:44] <Trevinho> or... attente, can't we just not load that gnome plugin in unity profile?
[18:45] <ChrisTownsend> Trevinho: I think there are still some settings that are needed in gnome plugin for Unity.
[18:45] <attente> Trevinho, it's a selective thing, there are still a couple of options in that plugin we still need
[18:45] <Trevinho> mh, i see
[18:46] <attente> although i suppose we can just move those into unity
[18:48] <Trevinho> having the most in unity helps always :)
[18:48] <Trevinho> I see it now...
[18:57] <mdeslaur> Trevinho: hi, I opened bug 1287854...probably a regression in compiz
[18:57] <ubot2`> Launchpad bug 1287854 in unity (Ubuntu) "newly created windows get progressively smaller" [Undecided,New] https://launchpad.net/bugs/1287854
[18:58] <Trevinho> mdeslaur: mh
[18:59] <mdeslaur> Trevinho: sorry for the compiz whack-a-mole :)
[18:59] <Trevinho> mdeslaur: there are sooooo many races and cases to handle in two lines of code -_-
[18:59] <Trevinho> mdeslaur: so, well that's quite similar to ....
[18:59]  * Trevinho looking for the bug
[19:01] <Trevinho> mdeslaur: I think it's a dublicate for https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1287472
[19:01] <ubot2`> Launchpad bug 1287472 in Compiz "compiz unnecessarily shrinks new windows" [Medium,Triaged]
[19:02] <Trevinho> mdeslaur: but you gave me a nice way to test it :)
[19:02] <mdeslaur> Trevinho: yep, looks quite similar
[19:03] <mdeslaur> actually, it's probably an exact dupe, the new window gets smaller by the decoration size, firefox then remembers the new window size, etc.
[19:03] <Trevinho> yeah, I'm trying to find a proper solution to all these... otherwise I go back to the old state... THe change was needed for the "nedit" editor find dialog... but it's really a minor thing
[19:03] <Trevinho> yaeh, exactly
[19:04] <mdeslaur> Trevinho: thanks
[19:35] <popey> Trevinho: i do have decor in the list, yes (sorry for delay, commuting)
[20:13] <bschaefer> Trevinho, there was this fun issue/hack in the window code, that each time it resized it removed 5 from its w/h. Though I though Sam fixed that bit...
[20:13]  * bschaefer checks
[20:17] <bschaefer> Trevinho, yeah look like that bit of code i was talking about was removed a while ago when Sam worked on fixing some nvidia decor issues...
[21:24] <Trevinho> bschaefer: what code were you referring to?
[21:25] <bschaefer> Trevinho, ill have to dig the rev up again, it was when i was working on Semi max windows
[21:25] <bschaefer> soo a bit ago :)
[21:25] <Trevinho> Mh, ok
[21:25] <bschaefer> Trevinho, and Sam pushed a branch shortly after that to and removed those bits
[21:25] <bschaefer> but let me get you a bug #
[21:38] <bschaefer> Trevinho, https://bugs.launchpad.net/compiz/+bug/1195522
[21:38] <ubot2`> Launchpad bug 1195522 in Compiz "Fix disabled acceptance tests for the decor plugin and run them by default" [Medium,Fix released]
[21:38] <bschaefer> in the diff
[21:38] <bschaefer> around line 1370
[21:39] <bschaefer> it was to make sure the event windowResizeNotify went off
[21:41] <Trevinho> bschaefer: ok, thanks
[21:42] <bschaefer> Trevinho, np, i highly doubt it relates to your issues. Just remember it was decor oriented (even though we have nice new shiny ones :)
[21:42] <bschaefer> just remembered*
[21:42] <Trevinho> bschaefer: yeah, but that code is inside window itself
[21:42] <Trevinho> so it might matter
[21:42] <bschaefer> yeah
[21:42] <bschaefer> Trevinho, theres some scary things in that file, tread carefully!