[03:50] <plars> duflu: any idea when we'll see the new compiz package in images? I was hoping it would show up today but it doesn't seem to have built yet?
[03:50] <duflu> plars: raring?
[03:51] <duflu> plars: All raring images built after today will contain compiz 0.9.9. The proof is here: https://launchpad.net/ubuntu/+source/compiz
[03:52] <duflu> If you want daily updates for the bleeding edge then there is also ppa:ubuntu-unity/daily-build
[03:52] <plars> duflu: that's showing that the current for raring is the  1:0.9.9~daily12.12.05-0ubuntu1
[03:53] <sarnold> are they blocked by the flavor-distro-alpha1?
[03:53] <duflu> plars: Yeah I was assuming the new inline packaging plan would mean daily changes to raring-proposed, but to get daily updates you need the PPA still
[03:54] <plars> duflu: so you (or someone) needs to manually push that to get it in the images?
[03:55] <plars> duflu: I'm out tomorrow, but I have others on my team that'll be looking for it I know
[03:56] <duflu> plars: To update the official raring release version, that is decided and pushed by distro. It's out of my hands
[03:56] <duflu> BTW, "tomorrow" is Saturday for me :)
[03:56] <micahg> duflu: no, once stuff's reverse dependencies are fine and autopkgtests pass, stuff migrates automatically from -proposed to -release
[03:56] <plars> duflu: tomorrow for me is always "next daily image built" :)
[03:57] <duflu> micahg: Yeah but there is no "proposed", which I find unexpected: https://launchpad.net/ubuntu/+source/compiz
[03:57] <micahg> duflu: it migrated already
[03:57] <micahg> oh, maybe not
[03:57] <micahg> hrm, nothing to upload for today?
[03:58] <duflu> micahg: Yes, there have been revisions that should have triggered daily builds. But looks like the daily builds are blocked or frozen
[03:58] <micahg> didrocks can probably explain when he comes online in ~2hrs or so
[03:59] <duflu> This is the first time people have been able to run the bleeding edge compiz and get a new one every day. Should make some people happy, despite the risk
=== m_conley_away is now known as m_conley
=== m_conley is now known as m_conley_away
[05:38] <didrocks> good morning
[05:41] <RAOF> Aloha didrocks!
[05:41] <didrocks> hey RAOF!
[05:41] <RAOF> This must mean it's soon to be Zoë bath time :)
[05:41] <didrocks> RAOF: heh, that's what I understood! :) I'm a little bit in advance today though ;)
[05:42] <didrocks> RAOF: did you plan anything for the week-end?
[05:43] <RAOF> Got some board games lined up on Sunday; I hope to continue my romping Eclipse form.
[05:43] <didrocks> oh sounds interesting :)
[05:44] <didrocks> I never played but I heard good things about "battlestar gallactica" as a board game
[05:44] <didrocks> (well, especially when you are a fan of the serie)
[05:45] <RAOF> That'd probably be an interesting game.
[05:47] <RAOF> I've not played it, but it seems likely to have a “traitor” dynamic, which is generally interesting.
[05:48] <didrocks> yeah, like in the TV show
[05:48] <didrocks> in the TV show, the best is that traitors don't know that they are traitos
[05:48] <didrocks> traitors*
[05:48] <didrocks> (basically they can be dormant agent)
[05:49] <didrocks> not sure if that's reflected inside the game
[05:51] <RAOF> That show wrote checks the writers couldn't cash.
[05:52] <RAOF> Also lost its way somewhere - S3 or S4, if I recall.
[05:52] <RAOF> But ended up finding it again.
[05:53]  * duflu votes BSG for best sci fi series in a long tim
[05:53] <duflu> +e
[05:53]  * didrocks agrees with duflu
[05:54] <RAOF> Yeah, I'll go with that.
[05:54] <didrocks> RAOF: I globally liked this one from start to end :)
[05:54] <didrocks> caprica was also great
[05:54] <didrocks> but the last 5 minutes are:
[05:55] <didrocks> "well, we didn't get the credit for doing more, here is what we wanted to explain…"
[05:55] <RAOF> Didn't watch all of that; still got some of it lying around somewhere.
=== Ursinha is now known as Ursinha-afk
[05:56] <didrocks> "lying around" ;)
[05:56] <didrocks> a file on a server, lost in a big HD :p
[05:57] <RAOF> Something like that, yeah :)
[05:57] <didrocks> that's a sad story!
[05:57] <didrocks> :)
=== Ursinha-afk is now known as Ursinha
[07:17] <tjaalton> RAOF: so you got your copy of eclipse then?-) met with the designer the other week, he was sorry about the delay in getting the new edition in stores
[07:17] <RAOF> tjaalton: I got mine some time ago, yeah.
[07:19] <tjaalton> looks like the local reseller has it in stock, need to get one for the holidays :)
[07:19] <RAOF> It's pretty good.
[07:19] <RAOF> There seems to be a *9* player expansion, which I suggest is a tiny bit excessive :)
[07:20] <tjaalton> yeah, rise of the ancients
[07:29]  * duflu feels like a non-geek in this environment
[08:32] <smspillaz> duflu: so I've got something that gets us from "grinding to a complete halt when dragging opengl windows around on nvidia" to "stays at a steady 12fps"
[08:32] <smspillaz> its the safest version I can come up with so far, shall I propose it ?
[08:32] <smspillaz> or shall I try and go for potentially more unsafe, but more framez
[08:33] <duflu> smspillaz: You've got time to improve it. I need to go lay down soon. This sinus infection won't go away
[08:33] <smspillaz> ok, the other changes could be unrelated then
[08:33] <smspillaz> I might separate them out
[08:33] <smspillaz> duflu: I'll get MCR1 to throw it at the wall and see if there are any bugs. Get better soon :)
[08:34] <smspillaz> RAOF: care to offer any possible explanation as to why the nvidia driver might be completely choking when you post it a ConfigureWindow request at the same time some redirected window is rendering ?
[08:35] <duflu> smspillaz: Did you work on improving the XShape usage?
[08:36] <duflu> Whenever I snapshotted compiz during a resize freeze that was a big issue, after the XSync
[08:36] <smspillaz> duflu: the xshape usage shouldn't really be a problem except for resizing
[08:36] <smspillaz> duflu: I'm only working on movement at the moment
[08:36] <duflu> smspillaz: OK, one at a time
[08:36] <smspillaz> duflu: to be honest its tricky - we really have to be careful when resizing a window with a custom shape, as we also need to reflect the changes in the frame window too
[08:36] <smspillaz> thats not something that can exactly be done asynchronously
[08:37] <smspillaz> duflu: the biggest thing so far is just the nvidia driver choking on ConfigureWindow. That's where our massive slowdown is
[08:37] <duflu> smspillaz: Frustrating. How often do apps really need or use non-rectangular shape?...
[08:37] <smspillaz> duflu: not often
[08:37] <smspillaz> duflu: the most common one would be chromium if its using CSD
[08:38] <duflu> Sheet. Chromium counts as common...
[08:38] <smspillaz> duflu: I don't know if people use CSD with it that much though
[08:38] <duflu> CSD?
[08:38] <smspillaz> client side decorations
[08:39] <smspillaz> The other shape related slowdown would be in the decor plugin, because I'm pretty sure those decorations have custom input shapes (pretty sure, you'll have to double check)
[08:39] <RAOF> smspillaz: What are you doing with the ConfigureWindow? There are a bunch of different codepaths depending on what you're actually configuring.
[08:39] <smspillaz> but the decor plugin is its own nightmare in terms of resize performance
[08:39] <smspillaz> RAOF: CWX | CWY
[08:39] <smspillaz> maybe three times a frame so far
[08:40] <smspillaz> I'm trying to get it down to one
[08:40] <duflu> smspillaz: Yeah I noticed decor is a big problem
[08:40] <smspillaz> duflu: the best fix for that one will be to rewrite it from scratch really, unless you want to reinvent the protocol
[08:40] <smspillaz> which will also count as rewriting it from scratch
[08:40]  * duflu decides to use annotate instead
[08:41] <smspillaz> "i have decorations too!"
[08:41] <duflu> And there's a house and a sun with smiley face
[08:41] <smspillaz> decorations - you mean christmas decorations on windows right?
[08:42] <smspillaz> duflu: all I can think of now is that solver paint commercial from years ago with the little kid at the end saying "I help too!"
[08:42] <duflu> Yes, libfestive.so
[08:42] <smspillaz> except that he has paint all over his face
[08:42] <RAOF> smspillaz: There's basically only two things the driver could be wrapping there - ChangeBorderWidth or MoveWindow.
[08:43] <smspillaz> RAOF: yeah, the's probably some sycnhronization thing the driver has to do when it gets MoveWindow
[08:43] <smspillaz> RAOF: this only happens when sync to vblank is on in the driver
[08:43] <smspillaz> it just completley freaks out when you change a window position mid-frame
[08:43] <RAOF> A redirected window shouldn't incur such synchronisation!
[08:44] <smspillaz> thats what I was thinking
[08:44] <smspillaz> but nope
[08:44] <RAOF> It's not like it's drawing to the screen at all. It's entirely divorced from vblank!
[08:44] <smspillaz> RAOF: I know
[08:44] <smspillaz> RAOF: so at the moment, if you drag a redirected gl window around, two things happen
[08:44] <pitti> Good morning
[08:44] <smspillaz> 1. the driver starts choking like crazy
[08:44] <smspillaz> 2. we get even more time to send it even more ConfigureWindow requests
[08:45] <smspillaz> which make it choke even more
[08:45] <RAOF> Yay!
[08:45] <duflu> if (vblank) for (i=0; i < 100; i++) XSync(d, False);
[08:45] <smspillaz> RAOF: you can basically DoS the thing by wagging your mouse cursor around for a few seconds
[08:45] <smspillaz> it will hang for about 30 seconds here
[08:46] <RAOF> That's suboptimal.
[08:46] <RAOF> So, have you (a) filed a bug, and (b) asked tselliot to raise it at the next nvidia meeting?
[08:46] <smspillaz> RAOF: nope, although the other WM's don't seem to cause it to choke too much
[08:47] <smspillaz> so right now I'm just optimizing how much we send ConfigureWindow requests
[08:47] <smspillaz> then I'll file the bug
[08:47] <smspillaz> the thing is that I'm not sure if we have "conclusive proof" that this is the case, or if compiz in doing something else in combination with the ConfigureWindow requests is just causing this behaviour
[08:47] <smspillaz> if I comment them out it goes back to fast again
[08:47] <smspillaz> *shrug*
[08:53] <smspillaz> RAOF: all I can think of right now though is this: http://www.quickmeme.com/meme/3s31jd/
[08:53] <RAOF> Heh
[08:54] <duflu> smspillaz: Before I forget... If you can tell the difference between "shaped" and unshaped rectangular windows, it would be a good idea to skip XShape where possible
[08:54] <smspillaz> do we not skip it ?
[08:54] <duflu> smspillaz: No it's "always on"
[08:54] <smspillaz> hm
[08:54]  * smspillaz thought the code already did that
[08:54] <duflu> At least in updateRegion
[09:14] <Sweetshark> good Mooorrring, all!
[09:14] <pitti> A wonderrrrrrful good morrrrning to you, Sweetsharrrrrk!
[09:15] <Sweetshark> pitti: arrr!
[09:15] <Sweetshark> .oO(every day is talk like a pirate day!)
[09:16] <didrocks> hey Sweetshark!
[09:17] <Sweetshark> seb128: I got my raring baseline ready and had a nice little build finished on it. I would love to have in in raring even though its only a beta. I should be okish already, and it will help ironing out the rest early on.
[09:17] <Sweetshark> didrocks: morning!
[09:18] <Sweetshark> seb128: I dont wanna do that on a friday though, so I will just give you some more deps/sync-requests today, and keep the big one for monday.
=== tkamppeter_ is now known as tkamppeter
[09:31] <seb128> hey Sweetshark pitti, happy friday!
[09:31] <pitti> seb128: bon vendredi!
[09:32] <seb128> pitti, merci, à toi aussi
[09:32] <seb128> pitti, tu rentres quand ?
[09:32] <pitti> seb128: I'll leave the office in about an hour
[09:32] <seb128> Sweetshark, ok, works for me
[09:32] <seb128> pitti, when do you land? munich?
[09:33] <pitti> seb128: about 5 pm in Munich, yes
[09:33] <seb128> when->where
[09:33] <pitti> I'll meet with my wife and a friend, and we;
[09:33] <pitti> 'll walk over the Christmas market
[09:33] <seb128> pitti, good luck, I hope it's not snowing that much there
[09:34] <seb128> pitti, they forecasted 15cm of snow for us today and it's getting close from 10cm already this morning
[09:34] <pitti> merci; il pleut à Londres, mais je ne sais pas que il neige à Munich
[09:34] <pitti> "à München"?
[09:34] <pitti> seb128: actually, is that "que-t-il"?
[09:35] <Sweetshark> seb128: just to confirm I got the debian policy right: if one file moves from one package to another, the right thing to do it to make the packge it moved to claim it conflicts/replaces the one the file was moved from in the old version?
[09:35] <seb128> pitti, "je ne sais pas si il neige"
[09:35] <pitti> seb128: oh, en effet
[09:36] <seb128> Sweetshark, correct
[09:36] <seb128> pitti, bonne chance en tout cas !
[09:38] <pitti> seb128: ba.com says the flight is operating, right now
=== vrruiz_ is now known as rvr_
[09:40] <seb128> pitti, good
[09:40] <seb128> pitti, how was the sprint otherwise ?
[09:41] <pitti> seb128: very intense, but we got a lot done; ev will write a summary today or on Monday
[09:41] <seb128> cool
[09:42] <pitti> we got the daisy deployment really simplified (two commands really), started on some test infrastructure for this, have armhf retracing well underway, designed various improvements such as per-problem hooks or better comparison between distros, etc.
[09:45] <xnox> Sweetshark: yes.
[09:50] <Sweetshark> fun facts: creating the tarballs for a libreoffice release takes 54 minutes on a decent machine (i7-2720QM) -- and that is with a local git mirror.
[09:56] <seb128> pitti, great ;-)
[10:05] <smspillaz> MCR1: wanna do some testing ?
[10:10] <MCR1> sure
[10:10] <MCR1> smspillaz: ^^
[10:15] <smspillaz> MCR1: https://code.launchpad.net/~compiz-team/compiz/compiz.performance_1027211.2/+merge/138682 try it with both lazy positioning in the move plugin "off" and "on"
[10:15] <smspillaz> its off by default as its technically not compliant, but with it "on" its about 5x faster with the nvidia driver
[10:16] <MCR1> smspillaz: Sam, unfortunately we seem to have a new problem with windows getting unresponsive to mouseclicks if they were fully hidden behind other windows - still trying to find a reliable way to reproduce... seems to be a very new problem...
[10:31] <pitti> good bye everyone, time to catch a flight
[10:33] <smspillaz> MCR1: is this with that branch ?
[10:33] <MCR1> smspillaz: no, with trunk
[10:34] <smspillaz> hmm ok, that's good. because I got that once today and wondered if it was a problem with the configure buffer locks not getting released
[10:34] <smspillaz> MCR1: the xshape code was touched recently
[10:34] <smspillaz> MCR1: how long ago did you start getting this ?
[10:35] <MCR1> smspillaz: not long ago, experienced first time today or yesterday
[10:36] <MCR1> smspillaz: also my individual mousepointer is not loading when I start the system
[10:36] <smspillaz> that's separate, the mouse cursor is set by the application
[10:36] <smspillaz> (as strange as that sounds)
[10:37] <MCR1> smspillaz: yeah, but there was a change regarding to mousepointers and now I get this...
[10:37] <MCR1> smspillaz: http://bazaar.launchpad.net/~compiz-team/compiz/0.9.9/revision/3513
[10:40] <MCR1> smspillaz: I am starting your branch now...
[10:40] <smspillaz> MCR1: that branch is correct, however we should probably stop changing the input shape of the frame and wrapper windows
[10:41] <smspillaz> especially where the client has no defined input shape
[10:41] <smspillaz> it doesn't make a whole lot of sense to do it that way ...
[10:41] <MCR1> to be honest: I do not know ;)
[10:41] <smspillaz> MCR1: btw, have you ever used callgrind ?
[10:42] <MCR1> no, but gdb
[10:42] <smspillaz> MCR1: callgrind is what duflu and I use to figure out performance bottlenecks
[10:42] <MCR1> yeah
[10:42] <GunnarHj> seb128: Good morning, Seb! Aron approved the l-s MP at bug 1076975, so now both the l-s and im-config MPs should be ready to go.
[10:42] <ubot2> Launchpad bug 1076975 in language-selector (Ubuntu) "Please port input method function to use im-config" [Undecided,In progress] https://launchpad.net/bugs/1076975
[10:42] <MCR1> should learn to use it I guess
[10:43] <smspillaz> its best to run compiz through that, and then look at how those particular functions can be optimized
[10:43] <smspillaz> MCR1: its pretty simple - valgrind --tool=callgrind compiz --replace ccp & ... kcachegrind callgrind.out.(process id)
[10:44] <MCR1> ok - will try
[10:44] <smspillaz> MCR1: static analysis tools like cppcheck are somewhat helpful, but often tell you to make lots of "optimizations" that don't really do anything
[10:44] <MCR1> yeah
[10:44]  * Sweetshark primes his 4.0 ccache for raring.
[10:44] <MCR1> sure
[10:45] <seb128> GunnarHj, hey, great!
[10:45] <smspillaz> MCR1: also there is gDebugger, but that is a bit of a pain to use. You have to patch compiz to remove server grabs and the like
[10:47] <MCR1> smspillaz: I noticed that turning off framebuffers improves performance a lot (at least on AMD, both with fglrx and gallium)
[10:49] <MCR1> smspillaz: I get a assertion failed error with your branch
[10:49] <MCR1> smspillaz: in configurerequestbuffer.cpp
[10:50] <MCR1> smspillaz: line 151
[10:51] <MCR1> smspillaz: priv->lockcount < priv->locksize() failed
[10:52] <smspillaz> MCR1: it will be like that until DRI3 lands really
[10:52] <smspillaz> there's not a whole lot we can do about it - its a hole in the way opengl works
[10:53] <MCR1> when will that happen ?
[10:53] <smspillaz> *shrug*
[10:54] <smspillaz> it might be worth looking into using copySubBuffer and waitVideoSync but duflu is opposed to that for good reasons
[10:54] <smspillaz> either method is bad really
[10:54] <smspillaz> I have some ideas to improve the performance of framebuffer objects though
[10:54] <smspillaz> but only be 5%
[10:56] <smspillaz> MCR1: ok, I've fixed the assert
[10:56] <MCR1> I do not know why, but framebuffer object on/off is like day/night here - the difference in speed is huge
[10:56] <smspillaz> MCR1: probably beacuse you're running at a massive resolution
[10:56] <smspillaz> there are two areas where performance is impacted there
[10:57] <smspillaz> the first is the synchronization cost associated with glBindFramebuffer (which we do twice per-render)
[10:57] <smspillaz> (that's a fixed cost)
[10:57] <smspillaz> the second is what happens when your GPU fillrate can't keep up with drawing an entire texture to the backbuffer
[10:57] <smspillaz> generally speaking, the second performance hit becomes worse as your resolution increases
[10:58] <smspillaz> It really boils down to:
[10:58] <smspillaz> 1. opengl sucks at this
[10:58] <smspillaz> 2. gpu's suck at this
[10:59] <MCR1> I will make some tests with other hardware (intel/nvidia) and different resolutions and write a comprehensive report then, because the default should really be chosen wisely
[11:00] <MCR1> currently default is on, which sucks at least for ATI hardware...
[11:00] <smspillaz> (well, sorry, gpu's rock at this, but not so much at 3840x1200)
[11:00] <MCR1> and my VRAM is fast - 256bit DDR5
[11:01] <smspillaz> MCR1: if your driver implements substantially faster blit operations than texturing operations then some other work I'm doing might speed that up
[11:01] <smspillaz> however as far as I've seen most drivers implement blits as a texture operation
[11:01] <smspillaz> which means you get the fragment pipeline overhead
[11:01] <MCR1> all I am saying is, we probably should adjust the default on startup according to the hardware used...
[11:02] <smspillaz> MCR1: not really - it really depends on the usage
[11:02] <MCR1> to get the best performance from start for everyone
[11:02] <MCR1> sure, tests are needed for that
[11:02] <smspillaz> MCR1: for example, where you're updating small areas of the screen (and you don't hit the fillrate cap) glCopySubBufferMESA and glCopyPixels make more sense than drawing to a framebuffer and using glXSwapBuffers ()
[11:03] <smspillaz> where you're doing large areas of the screen and can't meet the vblank deadline  with glCopyPixels or glCopySubBufferMESA then using an fbo and glXSwapBuffers makes the most sense because it happens asynchronously
[11:04] <smspillaz> not meeting the vblank deadline happens more often than you might think - and its better to buffer up frames for it to process asynchronously rather than continually blocking the cpu on the gpu
[11:07] <MCR1> maybe this buffering up of frames makes it feel less smooth, I do not know...
[11:07] <smspillaz> well it should make it feel more smoth
[11:07] <smspillaz> in any case, there are other points in our rendering code where we do gpu synchronization
[11:07] <smspillaz> we can probably remove them
[11:07] <smspillaz> but it will take time
[11:08] <MCR1> all I know is that fbo is just essential for the water plugin, that it is less smooth here, when enabled and that it causes CCSM screenshots to be broken (blue overlay on shots)
[11:09] <smspillaz> MCR1: its also required to be able to use glXSwapBuffers
[11:09] <smspillaz> which is required for tear-free rendering
[11:10] <MCR1> well, that is another point
[11:10] <smspillaz> MCR1: its also required for the unity blurs too :)
[11:11] <MCR1> AMD has a option to enable "Tear-free desktop", forcing VSync, which works very good here without FBO
[11:11] <smspillaz> it will still tear sometimes
[11:11] <smspillaz> waitVideoSync () doesn't make any guaruntee that your entire frame is going to end up in the front buffer
[11:12] <smspillaz> all it does is give you a small window of time to ask opengl to ask the gpu to put it in the front buffer
[11:12] <smspillaz> if all three don't make it in time, you get tearing
[11:13] <smspillaz> SwapBuffers and SwapControl can guaruntee it because the operation to get from the backbuffer to the front buffer is atomic - it just changes a pointer
[11:13] <MCR1> probably - I know that tearing has been a big problem in the past, which is loads better now... but currently I have no tearing at all, even with the youtube vsync test video
[11:14] <smspillaz> however in order for that to work you have to redraw the whole backbuffer on every frame, because it gives the application an "undefined" area to draw in
[11:14] <smspillaz> .... speaking of which I wonder if we clear the backbuffer on each frame ... I don't think we do
[11:15] <smspillaz> nope, good
[11:17] <smspillaz> MCR1: anyways, let me know how that branch goes
[11:18] <smspillaz> it will only help with window movement, but it should help a lot
[11:19] <MCR1> ok
[11:23] <MCR1> smspillaz: got the same error again
[11:23] <MCR1> smspillaz: I did not make clean, but recompiled and reinstalled
[11:24] <MCR1> will reboot and retry
[11:26] <smspillaz> MCR1: oh, one known bug, you'll probably get some weird resizing behaviour
[11:26] <smspillaz> I'm just pushing the fix for that now
[11:26] <smspillaz> (forgot to hook the relevant part of the code up)
[11:27] <MCR1> I am still not sure how to force the staging Compiz to use Unity and my CCSM settings
[11:37] <bizhanMona> HI is this a right channel to ask about how to create preseed iso  for Ubuntu 12.4/10 ?thx
[12:28] <psivaa> didrocks: i tested the packages in http://people.canonical.com/~didrocks/compiz/ but i get dependency problems in installing them
[12:33] <didrocks> psivaa: hum, what dependency issue?
[12:33] <didrocks> they didn't change
[12:47] <psivaa> didrocks: compizconfig-settings-manager depends on  python-compizconfig, ( we are doing this in the live session btw)
[12:56] <jibel> psivaa, it's because python-compizconfig in not in didrocks's folder. Either don't install compizconfig-settings-manager or install it with apt instead of dpkg and universe enabled
[12:57] <psivaa> jibel: ok but even if i finish installing those packages, i have not figured out a way to restart lightdm after the package installations. could someone help on that
[12:58] <xnox> psivaa: switch to tty1; stop lightdm; Ctrl-C; stop lightdm; stop ubiquity; pkill -9 X; start lightdm; all as root.
[13:00] <psivaa> xnox: pkill -9 X will bring the desktop in live session even without these packages, so it actually will make the testing pointless. sudo stop lightdm just hangs
[13:01] <xnox> psivaa: for reasons I have not yet troubleshooted, "sudo stop lightdm ENTER Ctrl-C  sudo stop lightdm ENTER" works.
[13:02] <xnox> psivaa: sure desktop comes up without lightdm because of autologin.
[13:03] <psivaa> xnox: ok thanks v much. ill try that in a bit.
[13:03] <xnox> so lightdm is there if restarted after stopping the chain. But "it can be swift"
=== soren_ is now known as soren
[13:36] <Sweetshark> seb128: liborcus_0.3.0-2~ubuntu1.dsc is wait for review/sponsoring on chinstrap.
[13:36] <seb128> Sweetshark, ok
[13:36] <Sweetshark> seb128: and is testbuilding on https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-quantaltest-20120601
[13:36] <Sweetshark> (succeeded locally)
[13:38] <Sweetshark> seb128: btw whats the state of libreoffice_3.5.7-0ubuntu2.dsc? precise upload-queue on lp timeouts for me ...
[13:38] <seb128> Sweetshark, https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=libreoffice ... still there
[13:39] <seb128> Sweetshark, btw you should reply to dholbach's email about the upload rights
[13:39] <Sweetshark> seb128: meh
[13:40] <Sweetshark> seb128: true. kinda sick of it though. prefer to get stuff done, instead of talking about it </sarc>
[13:40] <seb128> Sweetshark, well, it shouldn't be that much talking and it would spare us both some time over the long run
[13:42] <seb128> Sweetshark, liborcus seems fine, the liborcus-dev.dirs docs and README.source don't seem like they are useful though, but that's a detail
[13:42] <seb128> will sponsor it
[13:47] <seb128> Sweetshark, dh_install: usr/bin/orcus-xml-dump exists in debian/tmp but is not installed to anywhere
[13:47] <seb128> Sweetshark, is that an issue?
=== Quintasan_ is now known as Quintasan
[13:58] <Sweetshark> seb128: certainly not for libreoffice, if there are other clients of orcus at some point we can reinvestigate. so: no, not an issue
[14:01] <GunnarHj> seb128: The accountsservice bazaar branch in LP hasn't been updated for several months, which is inconvenient.
[14:01] <GunnarHj> https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/accountsservice/raring
[14:01] <GunnarHj> What kind of issue is it? A LP bug, or something else?
[14:03] <seb128> GunnarHj, it's a launchpad bug, it happens ... can you report it against https://bugs.launchpad.net/udd/+filebug ?
[14:04] <GunnarHj> seb128: Will do.
[14:04] <seb128> GunnarHj, thanks
[14:14] <didrocks> mvo: hey, small question: is it possible from apt.cache.Cache() to get source package name? (it's only listing binary packages it seems)
[14:19] <mvo> didrocks: yes, indirectly: source_pkgs = set(); for pkg in apt.cache.Cache(): source_pkgs.add(pkg.source_package_name)
[14:20] <didrocks> mvo: ok, I wanted to know if there was a more direct way, but that works for me! :) Thanks a lot
[14:34] <cyphermox> morning!
[14:42] <didrocks> hey cyphermox!
[14:48] <cyphermox> didrocks: ca va?
[14:48] <didrocks> cyphermox: ça va bien, et toi? :)
[14:48] <cyphermox> ouais
[14:49] <cyphermox> so, yeah, these things I have no idea what to do with now, the tests are so totally broken, plus the crash in X... I'm going crazy
[14:52] <didrocks> cyphermox: do you think mterry can be some kind of help?
[14:53] <cyphermox> if he wants to tackle the failing tests, it can be of help, yes
[14:55] <didrocks> cyphermox: you can go over the rest (I commented on your MP btw ;))
[14:55] <cyphermox> I saw
[14:55] <didrocks> also, there is lp:gcovr IIRC
[14:56] <cyphermox> yup
=== m_conley_away is now known as m_conley
=== vrruiz_ is now known as rvr_
=== rickspencer3_ is now known as rickspencer3
[17:03] <Sweetshark>  dpkg-source --after-build libreoffice-4.0.0~beta1
[17:03] <Sweetshark> dpkg-buildpackage: full upload (original source is included)
[17:03] <Sweetshark> on raring ;)
[17:17] <Sweetshark> seb128: _rene_ just made the point that translations are likely still outdated/incomplete in the beta, so building them might cause spurious bug report. building libreoffice without that in main would obviously create update horrors.
[17:18] <Sweetshark> seb128: OTOH, getting this in early is critical to get early feedback, see component mismatches, pull in the new packages etc.
[17:18] <seb128> Sweetshark, well, you can see component mismatches and file MIRs etc before upload, you probably should
[17:21] <Sweetshark> seb128: yes, I do of course. but the real upload is always something different given the complexity of the package. in theory, theory and practice are the same. in practice, ... not so much.
[17:22] <seb128> Sweetshark, sure, but you can do the obvious one upfront
[17:22] <seb128> ones
[17:22] <Sweetshark> seb128: note that the first upload of a new libreoffice major will always be tricky. making it later wont make it better.
[17:22] <seb128> like the libs you asked me to upload this week
[17:23] <Sweetshark> seb128: sure.
[17:23] <seb128> not discussing that
[17:23] <seb128> let's upload on monday
[17:23] <seb128> but please start on the MIRs monday as well
[17:23] <Sweetshark> yes, will do.
[17:25] <seb128> Sweetshark, thanks
=== attente is now known as attente_zzz
[17:55] <Quintasan> Hi there, anyone knowledgeable about how input methods are handled in Ubuntu? I need some help in getting ibus to work correctly in Kubuntu
[18:18] <mdeslaur> seb128: ok, thanks
[18:18] <mdeslaur> seb128: whoops, wrong channel
[18:19] <seb128> mdeslaur, thank *you* ;-)
=== hggdh_ is now known as hggdh
[19:26] <qengho> kenvandine: Hi hi.  Is that "demo" chromium browser extension good for anything? It makes #security nervous.
[19:35] <kenvandine> qengho, i haven't seen it
[19:36] <qengho> kenvandine: Okay.  Thanks.
[19:36] <qengho> kenvandine: It's a new entry in the chromium-browser.install file.  I'll figure it out.
[19:40] <kenvandine> ok
[19:41] <GunnarHj> seb128: still there?
[19:41] <seb128> GunnarHj, sort of, why?
[19:42] <GunnarHj> seb128: it's the postinst thing on the l-s merge.
[19:42] <seb128> GunnarHj, yes?
[19:42] <GunnarHj> seb128: postinst is essential, I think.
[19:43] <GunnarHj> seb128: im-config and im-switch can't co-exist anyway.
[19:43] <seb128> GunnarHj, why? what are you trying to achieve?
[19:43] <seb128> GunnarHj, well, it's not right to clean files from some other packages
[19:44] <seb128> GunnarHj, the way you achieve that is to make im-config Conflicts: im-switch so it get uninstalled, and you made im-switch to clean behind it on uninstall
[19:44] <GunnarHj> seb128: but more important, if you only remove im-switch (which is what the package manager does), the config files are still there, and one of the "config" files is 80im-switch
[19:44] <seb128> GunnarHj, well, im-switch should clean those on uninstall
[19:44] <GunnarHj> seb128: it doesn't. only if you purge
[19:45] <seb128> GunnarHj, well, that's an im-switch bug and should be fixed there
[19:45] <seb128> GunnarHj, one way to fix it is to update 80im-switch to check if im-switch is installed (e.g by checking a file on disk) and return without doing anything if that's the case
[19:46] <seb128> GunnarHj, see e.g /etc/X11/Xsession.d/80appmenu
[19:48] <GunnarHj> seb128: Aha, now I see. Yes, I suppose that would be possible.
[19:48] <GunnarHj> seb128: But then I'll not be able to do the rest of the "cleaning". ;-)
[19:48] <seb128> GunnarHj, one way is to consider 80im-switch not a conffile (it's not really) and clean it on removal and not only on purge
[19:49] <seb128> same for the other files
[19:49] <GunnarHj> seb128: Sounds better to me.
[19:49] <seb128> that works
[19:49] <GunnarHj> seb128: I'll check the im-switch package, and see if I can find out how to do it.
[19:50] <seb128> GunnarHj, you can read man dpkg-maintscript-helper
[19:51] <GunnarHj> seb128: Ok, will do, thanks.
[19:51] <seb128> GunnarHj, yw
[19:51] <seb128> GunnarHj, basically it's changing the im-switch postinst to call dpkg-maintscript-helper rm_conffile on remove
[19:52] <GunnarHj> seb128: The last thing done by that postinst script was to remove ~/.xinput.d. Any idea about that as well?
[19:53] <seb128> GunnarHj, the packages can't change user files, the user directory could be an nfs one and not mounter at the time you upgrade
[19:54] <seb128> GunnarHj, you should teach language-selector (or whatever else is appropriate) to rename/delete that file on start if needed
[19:54] <GunnarHj> seb128: True, but with the -f option you can try without causing a failure.
[19:54] <seb128> GunnarHj, it's still wrong, packages are not supposed to touch user datas and it means upgrade is not reliable, what happens for the users where that snippet failed?
[19:54] <GunnarHj> seb128: It's not needed, really. Just me who want to clean up. :)
[19:55] <seb128> yeah, don't... ;-)
[19:55] <GunnarHj> seb128: Going to read that man page, now.
[19:56] <seb128> GunnarHj, good luck, I'm off for the night but feel free to ping me on monday if you have questions
[19:56] <kenvandine> good night seb128!
[19:56] <kenvandine> have a great weekend
[19:56] <seb128> kenvandine, thanks, you too!
[20:03] <GunnarHj> seb128: Btw, was it any problem with the im-config MP?
=== attente_zzz is now known as attente
[22:19] <infinity> So, anyone around who cares to explain the im-switch -> im-config change, and why no one filed an MIR either for im-config or for it's new deps?
[22:23] <cyphermox> infinity: there was a rather long discussion on the ubuntu-desktop mailing list about ibus and stuff, maybe the rationale is there
[22:23] <cyphermox> sorry, I don't know the answer
[22:25] <infinity> cyphermox: Right, well, I'm reverting it for now, so the desktop is actually installable.
[22:26] <cyphermox> ok
[22:26] <cyphermox> will you send an email about it on ubuntu-devel?
[22:26] <infinity> I might.  Gimme a second to fix it all first. :P
[22:36] <infinity> cyphermox: Though, honestly, I don't see any reason for public shaming here.  Is there a specific reason you think it needs a broader audience?
[22:36] <cyphermox> certainly not for public shaming
[22:36] <cyphermox> just so that people know it's been reverted, and that you want to know why it was changed, why there was no MIR, tec.
[22:37] <cyphermox> infinity: or just send it to whomever did the change
[22:38] <infinity> I'll just mail Gunnar (who did the upload) and Seb (who changed the seeds), since theirs are the only changes I had to revert.
[22:39] <cyphermox> sure