[00:00] <rickspencer3> kklimonda, can I fix that in my Python code?
[00:00] <kklimonda> rickspencer3: yes
[00:01] <rickspencer3> so if test() returns True, all is good?
[00:01] <rickspencer3> in your sample?
[00:01] <rickspencer3> sweet
[00:02] <kklimonda> rickspencer3: well, either True or False (see http://pygtk.org/docs/pygtk/class-gtkspinbutton.html#signal-gtkspinbutton--input for what should be returned in your case)
[00:02] <rickspencer3> let me try it
[00:06] <rickspencer3> hmm
[00:06] <rickspencer3> still crashing for me
[00:06] <kklimonda> hmm..
[00:06] <rickspencer3> before my signal handler is even called
[00:07] <rickspencer3> yeah, even without the handler connected it crashes
[00:08] <kklimonda> rickspencer3: that's weird - it didn't crash when callback wasn't connected before
[00:08] <kklimonda> rickspencer3: and adding return True to __changed in grid_filter.py fixed it for me.
[00:08] <rickspencer3> hmmm
[00:08] <rickspencer3> weird, not for me, I must be missing something really simple
[00:10] <kklimonda> rickspencer3: http://pastebin.com/1WyryErp - that's for grid_filter.py from the tarball you have uploaded to the bugreport
[00:11] <kklimonda> argh, not this - http://pastebin.com/bedubE7c
[00:12] <kklimonda> I was supposed to paste a patch, not whole script :)
[00:13] <rickspencer3> kklimonda, so, it's not working for me, but I'm suspecting I am doing something really silly
[00:15] <kklimonda> rickspencer3: hmm.. if you tested the patch and not script I've pasted before (which was unpatched) then I'm not sure..
[00:15] <kklimonda> rickspencer3: does spin.py work for you?
[00:16] <rickspencer3> kklimonda, it was me being stupid
[00:17] <kklimonda> well, it happens to all of us from time to time.
[00:18] <rickspencer3> it happens to me every day, so I'm used to it :/
[00:18] <rickspencer3> (hadn't set the PYTHONPATH properly when running the test script)
[00:21] <rickspencer3> kklimonda, sweet, so not the widget is working properly!
[00:21] <rickspencer3> thanks a million
[00:23] <kklimonda> no problem, glad to be of help
[00:29] <rickspencer3> kklimonda, so ...
[00:29] <rickspencer3> more to the point, you're not supposed to use the "input" signal handler in Python at all
[00:29] <rickspencer3> :(
[00:29] <rickspencer3> you're supposed to use "value-changed"
[00:29] <rickspencer3> if ever there was a face-palm moment, this is it
[00:30] <kklimonda> rickspencer3: :)
[00:30] <kklimonda> rickspencer3: good to know
[00:30] <rickspencer3> mortifie
[01:01] <RAOF> Morning all
[01:03] <RAOF> Argh!  I just spent 30 seconds wondering why my mouse pointer wouldn't go to this screen… which is driven by a different computer.  Bah!
[01:35] <rickspencer3> hey RAOF
[01:35] <RAOF> rickspencer3: Good evening!
[01:35] <rickspencer3> RAOF, back in Sydney?
[01:35] <RAOF> Hobart, yeah.
[01:35] <rickspencer3> Sid-knee
[01:35] <rickspencer3> Oh, right, Hobart
[01:35] <RAOF> Not Syd-en-ee :)
[01:35] <rickspencer3> how was the conference?
[01:36] <RAOF> Great!
[01:36] <RAOF> Toulouse is a pretty nice town and there were all sorts of interesting conversations.
[01:37] <rickspencer3> nice
[01:37] <RAOF> We cornered krh at one point and made him explain wayland in detail :)
[01:37] <rickspencer3> heh
[01:37] <rickspencer3> and?
[01:37] <RAOF> It's pretty interesting architecturally.
[01:38] <RAOF> And has its own special IPC mechanism, and object-based notification system.
[01:38] <RAOF> And is not an X server in any way :)
[01:39] <rickspencer3> heh
[01:39] <rickspencer3> RAOF, how is xorg-xserver looking for Maverick?
[01:39] <RAOF> Although he gave a neat demonstration of a couple of X servers + some flowers running under wayland with funky animation.
[01:40] <RAOF> xorg-server is looking pretty good.
[01:41] <RAOF> There are some edge-cases in mesa on strange hardware I need to look at, and to get kde to log out without crashing the server.
[01:41] <RAOF> That's on intel.
[01:41] <rickspencer3> right
[01:42] <rickspencer3> well, Kubuntu is in much better shape with the new mesa, right?
[01:42] <RAOF> I've got the kde thing half done; now it just needs to log _in_ succesfully the second time ;)
[01:42] <rickspencer3> heh
[01:42] <Amaranth> RAOF: Although Wayland is basically X the way modern applications really use X
[01:43] <Amaranth> RAOF: It gives you a pixmap to draw to and tell it when you're done
[01:43] <RAOF> Kubuntu is *much* better with the new mesa.  And the new mesa helped Chase's multi-touch in unity demonstration, too, because it made unity actually work on his ati laptop :)
[01:43] <Amaranth> And that's pretty much it on the client side of drawing, the toolkit or app has to handle subwindows and such by itself
[01:43] <Amaranth> Which they all do anyway
[01:43] <RAOF> Amaranth: Right.  It's not terribly difficult to port things to it.
[01:44] <Amaranth> Although it still needs libxkb and some major work in the input area in general
[01:44] <RAOF> That might need to wait until we actually figure out how to do input properly :)
[01:44] <Amaranth> And apparently it's still possible to write an application that hooks in to the wayland compositor to provide effects
[01:45] <rickspencer3> well, so long as you can draw flowers, I guess that's all that matters
[01:45] <RAOF> But libxkbcommon is getting split out and depended on by X, so Wayland will be able to have xkb working more easily.
[01:45] <Amaranth> It just gives you flicker free screen updates and transparency, compositing 101 stuff
[01:46] <RAOF> Yeah.  Actually, the goal appears to be to make your compositor link to libwayland and be a display server itself.
[01:47] <RAOF> So unity-wayland would be the display server and compositor and shell.
[01:47] <Amaranth> But the major problem with wayland is it lacks all the standard we have for how windows should work, EWMH and such
[01:47] <RAOF> By design!
[01:47] <Amaranth> Sure but you need to provide some of that, somewhere
[01:48] <RAOF> In the desktop shell, or so says krh.
[01:48] <Amaranth> So each compositor/display server should implement their own version of docks and always on top windows and such?
[01:48] <RAOF> Yes.
[01:48] <Amaranth> Oh boy, that's going to be a mess for a few years
[01:48] <RAOF> Or, alternatively, should provide a separate interface to make those writable.
[01:48] <Amaranth> Until someone reinvents half the X11 standards
[01:49] <RAOF> Over dbus!
[01:49] <RAOF> ;:)
[01:49] <Amaranth> Yeah, I imagine it'd all be over dbus
[01:49] <Amaranth> Setting properties on the root window is such a hack
[01:50] <Amaranth> I've been tempted to get wayland running on my computer, now that you don't have to build the entire stack to do it
[01:50] <RAOF> Yeah.  And something you can't do in Wayland, because clients can't communicate.
[01:50] <RAOF> (Over wayland, at least)
[01:51] <RAOF> You can expect a wayland PPA pretty soon.
[01:51] <Amaranth> We'll probably end up with a new org.freedesktop.WindowManager interface every shell/display server implements
[01:51] <RAOF> Yup.
[01:51] <Amaranth> Or even better, a library everyone uses
[01:51] <kklimonda> RAOF: if wayland a real [1] project that is aimed at replacing X at some point [1] as opposed to a tech demo of sort :)
[01:51] <RAOF> Oooh, I don't know about that!
[01:52] <RAOF> kklimonda: krh was talking about Meego(?) switching to wayland in the near future; it's not actually a tech demo.
[01:53] <kklimonda> RAOF: sweet
[01:53] <Amaranth> Although the nice thing about the xserver is if you don't have a driver you can still use it
[01:53] <kklimonda> RAOF: so when do we follow? :)
[01:53] <Amaranth> Yeah, apparently Nokia is looking in to using it for Meego
[01:53] <Sarvatt> kklimonda: meego as in the phone UI for meego :)
[01:53] <kklimonda> Sarvatt: I know, j/k ;)
[01:53] <RAOF> kklimonda: Right now!  Just as long as you don't want anything to run! :)
[01:54] <Amaranth> But if you had a seamless way of starting a rootless X server for legacy apps...
[01:54] <RAOF> But, more seriously, we might want to use wayland in the next couple of cycles as an intermediate compositor for switching between X servers.
[01:54] <kklimonda> RAOF: meh, as long as it runs terminal I'm all set ;)
[01:54] <kklimonda> RAOF: hmm, sounds interesting - what's the usecase?
[01:54] <Amaranth> The nice thing is you could implement that org.freedesktop.WindowManager interface for X11 too that would just set the appropriate properties and such so apps wouldn't have to care
[01:55] <Amaranth> RAOF: That sounds like the exact idea I was pushing at UDS Seville using Xgl :)
[01:55] <RAOF> kklimonda: Keith gets his way and X is entirely out of the trusted path so each user runs one (or more) X server(s) and you want to be able to log in smoothly.
[01:56] <RAOF> Amaranth: :)
[01:56] <Amaranth> Yeah, if wayland is running at root and managing input you could run xservers on top of it as the user running the session and expose much less code to root access
[01:57] <Amaranth> And have a spinning cube to switch user sessions or something :)
[01:57] <RAOF> Amaranth: That's what krh was suggesting.  Keith was going further; *no* display server manages input, and you push input arbitration into the kernel.
[01:57] <kklimonda> now that's something users would actually care about :)
[01:57] <RAOF> In what seemed like a very reasonable (and small) change to the input code.
[01:58] <Amaranth> RAOF: ha
[01:58] <Amaranth> That'd be a nice way to work around not having a revoke() syscall
[01:58] <RAOF> Right.
[01:59] <RAOF> The idea being, you don't need revoke if the input devices don't broadcast but instead go to only one fd (as serial devices do now?) + some way for consolekit to tell the kernel which fd should get it.
[01:59] <RAOF> It seemed very reasonable in a room full of 40-odd X hackers :)
[02:00] <RAOF> Woot!  A new fglrx which actually works on Maverick!
[02:01] <ajmitch> isn't that sort of an important thing to have before release? :)
[02:01] <RAOF> Yes.  And we've now got it.
[02:02] <Sarvatt> we do?!
[02:02]  * Sarvatt jumps for joy
[02:02] <RAOF> According to my bug mail, yes.  Looks like Alberto just uploaded it.
[02:03] <Sarvatt> oh ATI you never cease to confuse the heck out of me
[02:03] <Sarvatt> beta driver that works with xserver 1.9 doesn't have newer kernel support added in the public releases for the past 4 months :)
[02:05] <RAOF> Launchpad wishlist: The ability to add a regex to a bug, so when anyone enters a comment matching that you can pop up some text saying “We've repeatedly said that this applies to the E6410 and *not* to the E6510.  Do you *really* want to add a comment about how this fix doesn't work for the E6510?”
[02:06] <TheMuso> It will be nice once all ATI cards have open source support out of the box... If that is indeed the eventual aim...
[02:06] <RAOF> That's getting pretty close.
[02:09] <RAOF> I *think* we're even be supporting Radeon 5xxx series 3D out of the box on Maverick, although I don't have any hardware to determine how useful this is :)
[02:11] <Sarvatt> yup, no 2D acceleration though funny enough
[02:11] <Sarvatt> don't worry, 6xxx series will be out really soon and drivers will lag 6 months again :)
[02:12]  * ajmitch just wants fast, stable & complete 3D support :)
[02:14] <Sarvatt> RAOF: our friend eDP?
[02:14] <Amaranth> Hey, once all the gallium dreams happen having 3D support will get you 2D support for free
[02:14] <Amaranth> Neat, i just got root on my laptop. Without putting in my password
[02:15] <Sarvatt> the xorg state tracker seems to be on life support, I think only vmware cares about it
[02:15] <RAOF> Sarvatt: Indeed.  We talked of eDP in hushed tones at XDS, so as to not traumatise Jesse any further :)
[02:15] <Sarvatt> hah!
[02:15] <Amaranth> Sarvatt: That's why I said dreams :)
[02:16] <Amaranth> I suppose I'll get it the same time I get native Direct3D support
[02:16] <Amaranth> Oh, wait...
[02:17] <Sarvatt> yeah speaking of that, adding wine-dev to the mesa build-deps sure is fun! it's bad enough mesa depends on x which depends on mesa in xorg-edgers for vmwgfx
[05:20] <GrueMaster> crimsun: Need your help again with Marvell Dove audio in Maverick.  Seems the new board changed codecs.
[05:59] <TheMuso> GrueMaster: What has changed exactly? Mixer elemt names?
[06:41] <pitti> Good morning
[06:50] <RAOF> Heya pitti
[07:01] <GrueMaster> TheMuso: Hey.  No, the entire codec chip.
[07:01] <GrueMaster> It used to use an AD1980, now it uses an ALC655.
[07:07] <TheMuso> GrueMaster: oh ok
[07:07] <bratsche> Hey pitti, how's it going?
[07:07] <pitti> hey bratsche; pretty well, thanks!
[07:09] <GrueMaster> TheMuso: I have found in my research that there are several x86 motherboards that use the same codec.  I am trying to decipher the pci/ac97 code for similarities, but coming up short.  Alsa speaker-test works, but nothing through pulseaudio.
[07:13] <GrueMaster> TheMuso: If you get a chance, scan http://paste.ubuntu.com/499485.  The ASoC machine driver is exporting AC97 HiFi, AC97 LFE, and AC97 Surround.  Not sure what pulseaudio needs.
[07:16] <GrueMaster> If you have any insights, leave me a note, thanks.  I'm off to bed for now.
[08:38] <mvo> pitti: hey, good morning. do you think its ok to get http://paste.ubuntu.com/499517/ in? its both bugfix and feature (in order to fix the bug) - the problem is that brasero calls the packagekit session interface to find what provides the cdrdao binary and this is a nice and elegant way to fix the problem (and any other app that searches for binaries)
[08:39] <mvo> its currently broken (throws exception, so its going to be hard for the change to make it worse ;)
[08:43] <didrocks> good morning
[08:44] <pitti> good morning mvo, hey didrocks
[08:44] <didrocks> Guten Morgen pitti :)
[08:45] <pitti> mvo: oh, haven't seen try:/except:/else yet; so else is run when there's no exception?
[08:46] <pitti> mvo: it looks like an elegant solution indeed
[08:46] <pitti> fine for me
[08:47]  * didrocks like also try:/except:/finally: ;)
[08:47] <mvo> pitti: thanks! I think its a win too, I tested it with brasero and its really nice, you insert a audio cd and it will prompt to install cdrdao and continue just fine afterwards
[08:53] <pitti> mvo: I just thought that having wodim and growisofs would be enough
[08:53] <pitti> I don't remember that I installed cdrdao to burn an audio CD
[08:53] <pitti> this sounds like something which ought to "just work" in a default install?
[08:53] <pitti> mvo: so brasero doesn't use wodim any more?
[08:57] <mvo> pitti: not sure, I haven't looked into brasero myself. but I agree, it should just work
[08:57] <mvo> pitti: oddly with the current brasero it crashes :/ I worked on that branch a couple of days ago so I think its a regression
[08:58] <mvo> didrocks: do you know about this? what brasero is using for audio cd burning?
[08:58] <didrocks> mvo: hum, I haven't tracked brasero recently. Let me have a look
[08:59] <didrocks> in 2.31.3: Fix wrong report of speed with both cdrecord and wodim
[09:00] <didrocks> so, sounds like it's still works with wodim, let me look the changelog from that
[09:01] <didrocks> burn-wodim.c as a plugin
[09:03] <mvo> odd
[09:06] <didrocks> I don't see it in the plugin list, weird… will try to have a look when having some time
[09:06] <pitti> alternatively we could drop wodim and just install cdrdao?
[09:07] <pitti> well, I guess wodim is still needed for data CDs
[09:08] <mvo> eh, so I have a fresh install here
[09:08] <mvo> but no wodim
[09:08] <mvo> I guess that is the problem then :) ?
[09:08] <mvo> no installed wodim
[09:10] <mvo> I have a look
[09:11] <mvo> wodim seems to be prefered over cdrdao when I read the plugin order correctly
[09:11] <pitti> shouldn't brasero depend on either of those?
[09:11] <mvo> yeah
[09:11] <mvo> for some reason it got dropped
[09:11] <mvo> I check the bzr history
[09:11] <pitti> in wodim it did
[09:12] <pitti> Depends: [...] wodim, genisoimage, dvd+rw-tools,
[09:12] <pitti> all of those are gone
[09:12] <pitti> can we please put them back?
[09:12] <mvo> yeah, in lucid it was all there
[09:12] <mvo> sure, I can do that now
[09:12] <mvo> I just want to see who/why so that I can send my wrath ;)
[09:13] <pitti> *phear*
[09:13]  * pitti hugs mvo, cheers
[09:13]  * mvo makes his best grim face and hugs pitti back
[09:13] <pitti> your best grim face still isn't very scary, sorry :)
[09:14] <mvo> lol
[09:14] <pitti> but I'm sure whoever committed it won't ever have a successful dist-upgrade again
[09:14] <mvo> I need to practise more
[09:14]  * pitti thinks mvo's revenges are a little more subtle than mere grim faces
[09:15] <mvo> if uid=="name": raise ResolverGeneratedBreaks("The resolver generated breaks, %s" % random.choice(apt.Cache())
[09:16] <mvo> there is a new brasero-cdrkit
[09:16] <mvo> maybe its enough to seed that
[09:16] <pitti> aah
[09:16] <mvo> it seems to have all the dependencies
[09:16] <pitti> but that doesn't have dvd+rwtools?
[09:17] <pitti> mvo: I'd actually prefer this to be a recommends: of brasero
[09:17] <pitti> it sounds more correct to me
[09:17] <mvo> the dvd+rwtools? or wodim-cdrkit (or both)?
[09:17] <pitti> They are only needed for the
[09:17] <pitti>  following operations in Brasero:
[09:17] <pitti>   * Audio CD burning with CD-Text information
[09:17] <pitti>   * Video DVD creation
[09:17] <pitti> hmm
[09:18] <pitti> mvo: I meant that brasero-cdrkit doesn't depend on dvd+rwtools
[09:18] <pitti> but lucid's brasero did
[09:18] <mvo> odd that this was unoticed for so long, it seems like its missing since Jul (the first merge)
[09:18] <pitti> well, what's a CD?
[09:18] <pitti> USB sticks FTW :)
[09:18] <mvo> haha, true
[09:18] <mvo> shows how the world has changed
[09:18] <pitti> mvo: brasero-cdrkit promoted to main
[09:19] <mvo> pitti: nice, thanks
[09:19]  * pitti leaves this in mvo's capable hands and goes back to fixing OEM stuff
[09:19] <mvo> I add dvd+rwtools as a recommend sand upload
[09:19] <mvo> thanks for your help/time pitti
[09:19] <pitti> if dvd+rwtools is still being used, that sounds good
[09:19] <pitti> mvo: and you'll add brasero recommends: -cdrkit?
[09:20] <mvo> yeah
[09:20] <mvo> either that or seeding, I don't have a preference
[09:20] <mvo> recommends is fine
[09:20] <pitti> I think recommends: is better, for derivatives or people without the metapackage
[09:20] <pitti> or chroots, and whatnot
[09:20] <mvo> ok
[09:20] <mvo> makes sense
[09:20]  * mvo prepares the upload
[09:20] <pitti> and we need a brasero upload anyway
[09:21] <mvo> oh, what for?
[09:21] <pitti> mvo: I thought you wanted to add the dvd+rwtools dependency?
[09:22] <mvo> I just checked, it gets in via the libbrasero-media1 dependency
[09:22] <mvo> but stil, the derivates argument makes sense
[09:22] <pitti> ah
[09:52] <mvo> hey glatzor! thanks for your sessioninstaller merge \o/
[10:02] <glatzor> thanks for your patchm mvo!
[10:20] <didrocks> pitti: I'm interested in your opinion on bug #645561
[10:20] <ubot2> Launchpad bug 645561 in gnome-keyring (Ubuntu) "gnome-keyring prompts lack way to set default timeout (affects: 2) (heat: 14)" [Undecided,Triaged] https://launchpad.net/bugs/645561
[10:20] <didrocks> maybe reverting to seahorse-plugins for this release for GPG key is the solution
[10:20] <didrocks> (as mdeslaur suggested)
[10:21] <chrisccoulson> hi didrocks
[10:21] <didrocks> hey chrisccoulson, how are you?
[10:21] <chrisccoulson> did you have a chance to look at the gdk-pixbuf change yet?
[10:21] <chrisccoulson> i'm good btw thanks :)
[10:21] <chrisccoulson> how are you?
[10:21] <didrocks> chrisccoulson: not yet, just jumping on it in a few :)
[10:22] <didrocks> tired ;)
[10:23] <chrisccoulson> yeah, i feel a bit tired too ;)
[10:30] <chrisccoulson> urgh, the new hamster-applet is really broken
[10:37] <chrisccoulson> ok, it's pretty much not usable
[10:37] <didrocks> what? ;)
[10:37] <chrisccoulson> the new hamster-applet
[10:38] <didrocks> ah… (sorry, as just reconnected, no context) :)
[10:38] <didrocks> chrisccoulson: so, what should I do? at least I have a graphical GNOME interface, which means gdx-pixbuf should work :)
[10:38] <chrisccoulson> when i fill in the "Description" field for a particular task (or even leave it empty), it shows the wrong description in todays list of tasks, and the description seems to change depending on where i put my mouse
[10:39] <chrisccoulson> so i can't trust that any of the information it's displaying is actually correct ;)
[10:39] <didrocks> chrisccoulson: ahah, some kind of $random in it, sweet!
[10:39] <chrisccoulson> didrocks, oh, that's good gdk-pixbuf works :-)
[10:39] <chrisccoulson> could you run gdk-pixbuf-query-loaders through strace, and put the output somewhere for me to look at? :)
[10:41] <didrocks> chrisccoulson: here we go: http://paste.ubuntu.com/499564/
[10:41] <pitti> didrocks: yes, sounds good to me
[10:41] <pitti> didrocks: and filing a bug upstream about making the timeout configurable?
[10:41] <chrisccoulson> didrocks - oh, this commit looks suspicious - http://git.gnome.org/browse/hamster-applet/commit/?h=gnome-2-32&id=4b40e64c536a79329adbd0cae3d17c615f3904e0
[10:41] <chrisccoulson> i think i might test that and then backport it if it works
[10:42] <chrisccoulson> i really on the hamster applet ;)
[10:42] <didrocks> pitti: ok, so removing the conffile for gnome-keyring-gpg.desktop and filing the upstream bug :)
[10:42] <chrisccoulson> didrocks - ok, that output looks fine
[10:42] <chrisccoulson> i think it's good to go :)
[10:42] <didrocks> chrisccoulson: ok, great t;)
[10:42] <didrocks> chrisccoulson: needs sponsoring for that one?
[10:42] <chrisccoulson> didrocks, yes please
[10:43] <chrisccoulson> i can't upload that yet ;)
[10:43] <didrocks> chrisccoulson: ok, doing then :)
[10:43] <chrisccoulson> thanks. i'll get ia32-libs done then, once that's been approved
[10:44] <didrocks> chrisccoulson: great, setting it as fix commited
[10:44] <chrisccoulson> thanks
[10:44] <didrocks> thank to you :)
[10:54] <didrocks> chrisccoulson: so, there is nothing do to on ia32-libs?
[10:54] <chrisccoulson> didrocks - i need to refresh ia32-libs with the new gdk-pixbuf version, and also add a postinst hook to create the loaders.cache on install
[10:55] <didrocks> chrisccoulson: ok, keep me in touch ;)
[10:59] <chrisccoulson> ok, hamster-applet is fixed
[10:59] <chrisccoulson> will upload that too
[11:01] <didrocks> great ;)
[11:01] <didrocks> do you want to work on other bugs too?
[11:02] <chrisccoulson> didrocks - yeah, sure :)
[11:02] <didrocks> chrisccoulson: I think that one can be interesting to fix (bug #630753)
[11:02] <ubot2> Launchpad bug 630753 in gnome-screensaver (Ubuntu) "gnome-screensaver activates while watching a movie in totem (affects: 2) (heat: 206)" [Undecided,New] https://launchpad.net/bugs/630753
[11:03] <chrisccoulson> yeah, i can take that one
[11:03] <chrisccoulson> i saw that too
[11:03] <didrocks> thanks :)
[11:03] <didrocks> maybe totem issue as vlc isn't impacted
[11:03] <chrisccoulson> VLC uses a different mechanism to do this
[11:05] <didrocks> oh ok :)
[11:06] <chrisccoulson> right, i've got to pop out for a little bit to pick up my car :)
[11:17] <didrocks> see you!
[12:05] <didrocks> RAOF: can you have a look at your WI list and state on them, please?
[13:15] <dpm> didrocks, I'm not sure who I should best ask, but you and Robert seemed to do the latest changes for yelp, so here goes the question :)
[13:15] <dpm> could someone have a look at bug 605577 and remove the en.po translation?
[13:15] <ubot2> Launchpad bug 605577 in yelp (Ubuntu) (and 4 other projects) "Help contents title bar shows cubes with numbers instead of a proper title (affects: 127) (dups: 65) (heat: 830)" [Undecided,Invalid] https://launchpad.net/bugs/605577
[13:16] <dpm> I've explained in my last comment. This will still not fix the bug (we'll need a new full language pack for that), but at least will I think prevent the wrong en.po getting into LP with the next upload
[13:16] <didrocks> dpm: don't we refresh the full yelp on 2.32.0 upload normally?
[13:17] <dpm> didrocks, if that's planned, that's fine, that would take care of it
[13:17] <didrocks> dpm: I mean, take from launchpad, as create this patch
[13:17] <didrocks> dpm: yeah, next week, we will have 2.32.0
[13:17] <dpm> ok, cool
[13:17] <didrocks> I should just add a task to remind me about it :)
[13:17] <dpm> :)
[13:18] <didrocks> oh no
[13:18] <didrocks> sorry, we have 2.30.1
[13:18] <didrocks> I think it's the webkit transition
[13:18] <didrocks> so, we wont update
[13:18] <didrocks> dpm: the best fix it to take from launchpad and refresh the patch?
[13:18] <didrocks> rather than deleting en.po
[13:19] <dpm> didrocks, yeah, as it will fetch new translations in other languages people might have done
[13:19] <didrocks> dpm: think it worthes it, adding a task for me :)
[13:19] <didrocks> dpm: btw, bug #619816
[13:19] <ubot2> Launchpad bug 619816 in gnome-power-manager (Ubuntu) (and 1 other project) "Battery status line too long (affects: 2) (dups: 1) (heat: 20)" [Medium,New] https://launchpad.net/bugs/619816
[13:19] <dpm> awesone, thanks didrocks
[13:19] <dpm> ok, let me have a look
[13:19] <didrocks> dpm: not sure it will be accepted or not, still didn't ask, but maybe it worthes it
[13:32] <dpm> didrocks, ok, commented on it, thanks for the pointer
[13:33] <didrocks> thanks dpm :)
[13:51] <doko> who can tell me something about the libindicator uploads?
[13:51] <doko> is it correct to demote libindicator-tools  ?
[13:53] <didrocks> doko: I think you should ask tedg about it when he's around
[13:53] <doko> didrocks: could you remind me/ask him?
[13:53] <didrocks> doko: yeah, I will
[13:53] <doko> thanks
[13:53] <didrocks> yw
[14:16] <didrocks> dpm: can you join #ayatana?
[14:19] <dpm> yep!
[14:23] <didrocks> thanks :)
[14:33] <didrocks> tedg: hey
[14:33] <didrocks> 14:51:24          doko | is it correct to demote libindicator-tools  ?
[14:33] <didrocks> tedg: ^^
[14:34] <tedg> didrocks, What does "demote" mean in this context?
[14:34] <tedg> Oh, to universe?
[14:34] <tedg> I don't think there's any reason those need to be in main.  They're just debugging tools.
[14:35] <tedg> doko, ^
[14:35] <doko> tedg: ok, thanks!
[14:36] <didrocks> yeah, it's my feeling as well :)
[14:36] <kamstrup> dpm, we have a problem with https://bugs.edge.launchpad.net/ubuntu-translations/+bug/646653
[14:36] <didrocks> thanks tedg
[14:36] <ubot2> Ubuntu bug 646653 in unity (Ubuntu) (and 2 other projects) "The number of items message in the Unity trash does not load translations (affects: 1) (heat: 6)" [Critical,Triaged]
[14:36] <kamstrup> dpm, it's getting late and I can not for the life of me figure out why ngettext() isn't working
[14:36] <kamstrup> dpm, So my last resort is to change the string into something without nggettext()
[14:37] <dpm> hey kamstrup, does gettext() work there?
[14:37] <kamstrup> dpm, So either (if n_items == 1) _("1 Item in trash") else _("%d items in Trash") - and pretend plural forms don't exist
[14:37] <kamstrup> dpm, yes
[14:38] <kamstrup> dpm, or simply "Items in trash: %d" - which seems a bit awkward
[14:38] <kamstrup> dpm, what's your take on this?
[14:38] <dpm> kamstrup, I think it might be awkward, but at this point it might be the best solution as the if/else option would only work for some languages
[14:39] <kamstrup> dpm, ok will do that then - should I notify the mailing list?
[14:39] <dpm> kamstrup, yes, please, that would be great
[14:40] <dpm> kamstrup, and thanks a lot for the work on this
[14:47] <dpm> didrocks, the conversation on the g-p-m time string has reminded me about bug 579134 - I know it's too late, but it might be worth reassessing the importance, as per pitti's comment there, so that it stays on the radar for natty perhaps
[14:47] <ubot2> Launchpad bug 579134 in indicator-datetime (Ubuntu) (and 2 other projects) "The date and time indicator should respect the locale setting for time format (affects: 23) (dups: 2) (heat: 126)" [Undecided,New] https://launchpad.net/bugs/579134
[14:47] <pitti> dpm: ugh, does that thing still display 12 hours only? :-(
[14:48] <dpm> pitti, I think there was a workaround to use a translatable string to specify the format, but I haven't tried it yet, as we haven't finished translating it in our team
[14:49] <dpm> I might try with another locale
[14:49] <pitti> dpm: but that's rather broken -- that's already specified in the locale
[14:49] <dpm> pitti, I know, I know, I'm just mentioning it
[14:49] <geser> pitti: what do you expect from "A very, very simple clock"?
[14:50] <pitti> I understand that we don't want to use strftime(%c), but we can certainly ask the locale for whether it's 24 or 12 hours, and the AM/PM strings
[14:50] <didrocks> dpm: can you remind me that later? It's one of the blocker I set to not put indicator-datetime to the desktop this cycle
[14:50] <pitti> geser: to at least show the correct time? :-)
[14:50] <dpm> didrocks, sure
[14:50] <pitti> tedg: ^ WDYT about just asking the locale for the format?
[14:51] <geser> pitti: 50% of a day it's correct :)
[14:51] <tedg> pitti, I couldn't find a way to ask it that simple of a question.  But, what we do is make the default string translatable.
[14:51] <pitti> geser: only if you work from 6 to 18, which is not quite the most preferred part of the day for geeks..
[14:54] <tedg> pitti, There's also a gsettings key for those who don't like their locale's setting.
[15:03] <rickspencer3> good morning all
[15:03] <pitti> tedg: so from a shell this would be "locale -k am_pmÄ
[15:03] <pitti> hey rickspencer3
[15:04] <pitti> tedg: of course you'd use the libc function for that, but if it has a value, it shows the localized strings for AM and PM; if it's not set, it's 24 hours
[15:04] <pitti> tedg: with that we can use the info from the locales, instead of having to re-translate them all over agani (which is also quite error prone)
[15:07] <didrocks> hey rickspencer3
[15:07] <rickspencer3> hi didrocks
[15:07] <mterry> tedg, pitti, dpm: I remember looking at that bug.  I think one problem I had was that en_GB doesn't translate the string to say 24 hour time.  Also, stfrtime can give you the time in locale format, but it has seconds attached, and there's no clean way to strip that
[15:08] <pitti> mterry: right, that's why I suggested asking the locale instead of strftime()
[15:09] <pitti> mterry: but en_GB uses 12 hours?
[15:10] <mterry> pitti, no?  I thought not.  I've used it in the past to show 24h
[15:12] <mterry> pitti, this is complicated.  language-support says en_GB is 24h.  with LC_TIME="en_GB.UTF-8", date --date="8PM" gives 20:00:00.  But locale -k am_pm shows am_pm="AM;PM"
[15:12] <pitti> mterry: oh, indeed; seems I misremembered
[15:12] <mterry> pitti, I think locale -k is lying?
[15:12] <pitti> apparently so
[15:13] <pitti> mterry: I just checked the locale source, and it sets it to empty
[15:13] <mterry> pitti, so currently indicator-datetime is 12h for en_GB but should be 24h if someone would add that translation
[15:13] <mterry> pitti, sets am_pm to empty?
[15:13] <pitti> right, which means "24 hours"
[15:13] <pitti> so date can interpret it correctly, just locale -k shows it wrong
[15:14] <mterry> pitti, odd.  Is there another way of asking?
[15:14]  * pitti checks
[15:14] <mterry> pitti, is there a library that 'locale' and 'date' are using?  What's the lowest level way besides scraping the locale files?
[15:15] <pitti> glibc

[15:15] <mterry> pitti, so nl_langinfo ?
[15:15] <pitti> right; I used that in the past for something different
[15:17]  * mterry waits for giant glibc manual to load
[15:17]  * pitti writes a quick test program
[15:19] <mterry> pitti, actually, strftime %p seems like it gives the info we need.  Empty string means 24-hour, else it gives AM or PM
[15:20] <pitti> mterry: hm, nl_langinfo() gives me the same as locale -k
[15:20] <pitti> mterry: ah, good
[15:20] <mterry> pitti, hrm, it doesn't work for en_GB when I do date +%p
[15:20] <mterry> pitti, gives me AM
[15:21] <pitti> same nl_langinfo() presumably
[15:21]  * pitti RTFS in glibc
[15:21] <mterry> pitti, which argument to langinfo did you use?  I see three relevant ones: T_FMT_AMPM, AM_STR, and PM_STR
[15:22] <pitti>     printf ("T_FMT: '%s', T_FMT_AMPM: '%s', AM_STR: '%s', PM_STR: '%s'\n",
[15:22] <pitti>             nl_langinfo (T_FMT), nl_langinfo (T_FMT_AMPM),
[15:22] <pitti>             nl_langinfo (AM_STR), nl_langinfo (PM_STR));
[15:22] <pitti> mterry: it seems AM_STR and PM_STR aren't a good indicator
[15:22] <pitti> mterry: they are present in the locale so that you can alternatively use 12 hour format (GB probably had used it in the past)
[15:22] <mterry> pitti, but T_FMT_AMPM is?  that would work en?
[15:22] <pitti> mterry: but I think T_FMT_AMPM is better
[15:22] <pitti> $ LANG=en_GB.utf8 /tmp/timefmt
[15:22] <pitti> T_FMT: '%T', T_FMT_AMPM: '%l:%M:%S %P %Z', AM_STR: 'AM', PM_STR: 'PM'
[15:22] <pitti> $ LANG=en_US.utf8 /tmp/timefmt
[15:23] <pitti> T_FMT: '%r', T_FMT_AMPM: '%I:%M:%S %p', AM_STR: 'AM', PM_STR: 'PM'
[15:23] <mterry> pitti, (why is this so hard?  :))
[15:23] <mterry> pitti, oh, but T_FMT_AMPM forces seconds
[15:23] <pitti> %I is hour (1..12)
[15:23] <mterry> pitti, one could grep the returned string for %I
[15:23] <pitti> mterry: I think we should grep for %p or %P
[15:23] <mterry> pitti, to determine if it's 24h.  /me shudders
[15:24] <pitti> for de_DE.utf8:
[15:24] <pitti> T_FMT: '%T', T_FMT_AMPM: '', AM_STR: '', PM_STR: ''
[15:24] <pitti> (we don't use 12 hour format, ever)
[15:24] <pitti> i. e. it'll just be empty
[15:24] <pitti> so it seems T_FMT_AMPM =~ '%[pP]' is a good indicator
[15:25] <mterry> pitti, but en_GB has %p and should be 24h
[15:25] <mterry> pitti, wouldn't %I be better?
[15:26] <pitti> mterry: en_GB has %l there, which confusingly is described as "The  hour  (12-hour clock) as a decimal number (range 1 to 12)"
[15:26] <mterry> pitti, I think T_FMT_AMPM is also broken for en_GB...?
[15:27] <pitti> well, no; it looks correct for a time which you request in 12 hour form
[15:27] <pitti> phone, brb
[15:28] <mterry> pitti, oh right.  T_FMT_AMPM is inherently non-24h.  I don't get why you care about %p though.  The goal I thought was to find a way to detect that en_GB is 24h.  %p gives a false-negative for that
[15:29] <pitti> right
[15:29] <pitti> (phone, brb)
[15:29] <mterry> pitti, sure, no rush :)
[15:32]  * pitti chuckles about some h4cks in glibc
[15:32] <pitti> #  define ampm (L_("AMPM") + 2 * (tp->tm_hour > 11))
[15:34] <pitti> mterry: so it seems that date +%X gets it correct
[15:35] <pitti> ooh, of course
[15:35] <pitti> mterry: T_FMT == '%T' -> 24 hour; T_FMT == '%r' -> AM/PM
[15:36] <pitti> mterry: the alternative is to just use strftime('%X') and removing seconds
[15:36] <pitti> the format is predictable, after all
[15:37] <pitti> (i. e. HH:MM:SS (AM|PM)?
[15:37] <pitti> but I think using T_FMT is what we actually want
[15:37] <pitti> and that's what strftime uses for %X
[15:37] <pitti> #  define ampm (L_("AMPM") + 2 * (tp->tm_hour > 11))
[15:37] <pitti> oops
[15:37] <pitti> http://sourceware.org/git/?p=glibc.git;a=blob;f=time/strftime_l.c;h=08c2aeb32be6421cb8075dfae3579da4ee02644a;hb=HEAD#l1177
[15:38] <pitti> tedg: so, seems we have two alternatives
[15:40] <mterry> pitti, http://stackoverflow.com/questions/2507726/how-to-display-locale-sensitive-time-format-without-seconds-in-python tells how to remove seconds
[15:46] <rickspencer3> pitti, hey
[15:46] <rickspencer3> bug #605577
[15:46] <ubot2> Launchpad bug 605577 in yelp (Ubuntu Maverick) (and 6 other projects) "Help contents title bar shows cubes with numbers instead of a proper title (affects: 127) (dups: 65) (heat: 830)" [Undecided,Invalid] https://launchpad.net/bugs/605577
[15:46] <rickspencer3> seems lang pack related, and is really ugly
[15:47] <rickspencer3> pitti, do have a chance to check in and see how we can fix this asap?
[15:48] <pitti> rickspencer3: I'll have a look ASAP
[15:48] <rickspencer3> thanks pitti
[15:48] <chrisccoulson> yeah, it's a broken langpack. i came across the same issue when we updated the language packs in all the other releases for the firefox update
[15:48] <chrisccoulson> and it got fixed in those
[15:48] <rickspencer3> chrisccoulson, well, it's really really ugly
[15:48] <rickspencer3> and very salient
[15:49] <chrisccoulson> rickspencer3, yeah, it's fairly noticeable
[15:49] <pitti> mterry: that would bring it to the next level (locale dependent hour/minute separators), but it looks a bit ugly
[15:50] <chrisccoulson> remote debsign ftw :-)
[15:50] <chrisccoulson> thanks for the suggestion yesterday pitti ;)
[15:50] <didrocks> rickspencer3: pitti: will do it on Monday as dicussed on this channel :)
[15:50] <pitti> chrisccoulson: heh
[15:51] <chrisccoulson> i can do this whole update whilst only using a few bytes of my own bandwidth :-)
[15:51] <didrocks> it's just about taking the new LP translations which removes the en.mo
[15:51] <tedg> pitti, I looked at that, but my concern was whether the format was predictable... I hate the idea of parsing format strings :-/
[15:51] <pitti> tedg: right; I think checking T_FMT is more robust
[15:52] <rickspencer3> didrocks, the status on the bug is making robbiew worry
[15:52] <didrocks> rickspencer3: oh, I can change that
[15:52] <rickspencer3> perhaps you could update it there when you get a chance?
[15:52] <didrocks> sure
[15:52] <pitti> tedg: if it's %T or %r, we know what to do
[15:53] <didrocks> done
[15:53]  * robbiew has corrected the settings...so it shows up on our radar ;)
[15:54] <didrocks> good, should be fixed on Monday, just hadn't the time still :)
[15:54] <robbiew> no worries
[15:55] <pitti> dpm: do you already know whether bug 605577 is fixed in the translations?
[15:55] <ubot2> Launchpad bug 605577 in yelp (Ubuntu Maverick) (and 6 other projects) "Help contents title bar shows cubes with numbers instead of a proper title (affects: 128) (dups: 65) (heat: 842)" [Undecided,Triaged] https://launchpad.net/bugs/605577
[15:59] <mterry> didrocks, I swear the top pixel isn't working!
[15:59] <didrocks> mterry: go hunt and hit njpatel then ;)
[15:59] <didrocks> mterry: are you in the UNE session?
[15:59] <mterry> didrocks, yeah
[15:59] <didrocks> or trying to run it from desktop
[15:59] <mterry> didrocks, running unity from desktop?
[16:00] <didrocks> hum… really, I can't reproduce it, I was thinking first your were talking about the other bug :/
[16:00] <didrocks> mterry: with mutter --replace blablabla :)
[16:00] <njpatel> mterry, one sec, you need to hit jason
[16:00] <mterry> didrocks, ah.  I'll bug njpatel to see if that's the best debugging method
[16:00] <mterry> njpatel, or jason
[16:01] <DBO> wassup homies
[16:01] <njpatel> DBO, meet your picking patches biggest fan, mterry
[16:01] <njpatel> mterry, let him have it
[16:01] <njpatel> :)
[16:01] <mterry> DBO, you're jason?  :)
[16:01] <gord> Its a trap!
[16:01] <DBO> ITS A TRAP
[16:01] <DBO> we cannot repel bugs of this magnitude
[16:01] <DBO> mterry, no
[16:02] <mterry> DBO, OK, so my top pixel in UNE maverick still doesn't work.  (it works for GtkStatusIcon indicators like NM, but not indicators, window controls, or the logo button)
[16:02] <mterry> DBO, ok
[16:02] <DBO> yeah I got that bug report this morning
[16:02] <DBO> I am looking it over (again) now
[16:02] <mterry> DBO, any way I can provide debugging stuff?
[16:02] <DBO> not sure whats wrong since the math all makes sense in my head
[16:03]  * didrocks updates DBO for getting the missing case
[16:03] <didrocks> and update the symbol file as well
[16:03] <DBO> wat?
[16:03]  * DBO wonders if mterry really thinks he is not Jason
[16:04] <mterry> DBO, you lied to me?!  Man, I'm too trusting
[16:04] <DBO> /whois DBO wasn't a clue?
[16:04] <mterry> DBO, didn't need to, I had your gentleman's word
[16:05] <DBO> mterry, but you met me in real life
[16:05] <DBO> you *know* I am not a gentleman
[16:05] <mterry> DBO, :)
[16:05] <DBO> little more than a man-child truly
[16:10] <mterry> DBO, didrocks suggested trying to run mutter from desktop session (not netbook session).  Would that be a useful test?
[16:11] <didrocks> mterry: no, this was in case you've done that
[16:11] <DBO> mterry, if you can manage to click the "top pixel" of a window...
[16:11] <DBO> accurately
[16:11] <mterry> DBO, nope!
[16:11] <DBO> I actually wrote a utility for that
[16:11] <didrocks> sometime, mutter doesn't align very well, when started over compiz (the mouse was aready moved by some offset)
[16:11] <DBO> yay mouse warp
[16:12] <bratsche> dpkg-source: error: none of the filenames in ---/+++ are relative in diff `evince-2.31.92/debian/patches/03_gesture.patch' (line 3)
[16:12] <bratsche> Oops.
[16:12] <mterry> DBO, but I find it odd that the GtkStatusIcons get it right.  Or should I not be surprised since those are xembeds?
[16:12] <chrisccoulson> right, i am done with ia32-libs \o/
[16:13] <DBO> mterry, no surprise
[16:18] <dpm> pitti, sorry, I was on the phone. re: the yelp bug, I fixed it in LP, it's only that the delta export did not pick up the change (the corrected en.po file), but the full export should. I talked about it with didrocks earlier on, and we should also make sure that the patch with translations from LP in yelp does not contain en.po, otherwise we'd be reimporting it into LP I think
[16:19] <pitti> dpm: ah, thanks; so the problem is that yelp has some patch with LP-imported translations, and it messes up the encoding along the way?
[16:21] <dpm> pitti, not exactly. Somehow an en.po file with en@shaw translations was imported into LP. That en.po file was exported in langpacks wreaking havoc in yelp. In addition to that, when adding translations to yelp from LP we also put that en.po translation in the patch. So we should fix this in two places: language packs and yelp
[16:22] <pitti> dpm: I just don't understand why we manually patch in LP translations to yelp?
[16:22] <pitti> dpm: but thanks for the heads-up!
[16:24] <dpm> pitti, because we include some additional Ubuntu-specific strings to the documentation. I understand that that's the only way to use those translations. I think it's "Assistive Technologies" and something else perhaps (in the main index page shown when starting yelp)
[16:25] <pitti> dpm: ok; I'll probably talk to you on Monday about this
[16:26] <dpm> pitti, sure, but I'm away on Monday and back on Tuesday, but in the meantime seb128 should also be aware of the yelp-patching part (most probably better than me)
[16:26] <dpm> and didrocks too
[16:27] <didrocks> pitti: I've already done that for 2 or 3 release, not sure why yelp need manual translation, right
[16:27] <didrocks> pitti: new gnome-keyring to fix the gpg issue uploaded btw
[16:33] <chrisccoulson> thanks to whoever approved ia32-libs already :-)
[16:34] <didrocks> chrisccoulson: oh? it's done?
[16:34] <chrisccoulson> didrocks - yeah, it was approved a couple of minutes after uploading it
[16:34] <chrisccoulson> right, totem next
[16:35] <didrocks> chrisccoulson: thanks! ;)
[16:40] <cyphermox> didrocks, I'm able to fix 575160 by using the in-tree cairo, about to push a package to my PPA for testing, but I already have a merge request.
[16:42] <didrocks> cyphermox: oh nice!
[16:42] <didrocks> cyphermox: One more bug dead ;)
[16:43] <cyphermox> hopefully
[16:43] <cyphermox> didrocks, I'm not sure if it fixes things for lucid though, I'll look in a minute
[16:43] <didrocks> cyphermox: just keep us updated.
[16:43] <cyphermox> yep
[16:43] <didrocks> cyphermox: well, focus on maverick, no hurry for lucid I think
[16:43] <chrisccoulson> cyphermox, did any other distro's switch to in-tree cairo too?
[16:43] <cyphermox> rickspencer3, did you make that wallpaper? if so, nice work on the saturation
[16:44] <cyphermox> chrisccoulson, looks to me like it's exactly what opensuse did
[16:44] <didrocks> cyphermox: you bought it? :)
[16:44] <rickspencer3> cyphermox, no
[16:44] <rickspencer3> I had a wallpaper, it was a picture of my dog
[16:44] <cyphermox> didrocks, yeah I did
[16:44] <rickspencer3> but someone replaced it :/
[16:44] <cyphermox> aw
[16:44] <didrocks> urgh :/
[16:44] <cyphermox> rickspencer3, we have snails, why couldn't we have dogs?
[16:44] <rickspencer3> well
[16:44] <rickspencer3> there are dogs, and there is my dog
[16:45] <rickspencer3> I guess there was concern that the wallpaper would have been considered some kind of act of aggression
[16:45] <rickspencer3> international incidents ensue
[16:45] <rickspencer3> etc...
[16:47] <doko> chrisccoulson: looking at the firefox package, is there a reason that binary packages are still in the control file (the ones which are not built anymore)?
[16:48] <chrisccoulson> doko - which packages are those?
[16:48] <chrisccoulson> we cleaned all the transitional packages in maverick, so they should all be gone now
[16:49] <doko> chrisccoulson: sorry, was looking on the wrong machine
[16:52] <chrisccoulson> didrocks - a quick look at the error messages from bug 632594 suggests that dbus is not running
[16:52] <ubot2> Launchpad bug 632594 in xorg-server (Ubuntu) (and 1 other project) "xvfb 1.9 and/or metacity not working on the buildds (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/632594
[16:52] <chrisccoulson> which makes sense in the buildd ;)
[16:52] <chrisccoulson> i have similar issues with firefox unit tests too
[16:52] <didrocks> chrisccoulson: right, I really didn't give a look at it
[16:53] <chrisccoulson> yeah, me neither. that's just a guess from the error message
[16:53] <chrisccoulson> but you need dbus to talk to gconf
[16:53] <didrocks> isn't there this --direct option?
[16:53] <didrocks> ignore me
[16:54] <didrocks> I was thinking a testsuite using gconftool
[16:54] <didrocks> so, if it's only the testsuite which fails, deactivating this part will fix the issue
[16:55] <chrisccoulson> really, the test-suite needs to start metacity with dbus-launch
[16:55] <chrisccoulson> but that's pretty hacky
[16:55] <chrisccoulson> i'd just ignore those warnings tbh ;)
[16:55] <didrocks> yeah, sounds the safe option :)
[16:56] <didrocks> dbus + buildd aren't good mate :)
[16:59]  * cyphermox -> lunch
[17:08] <pitti> didrocks: upower fix uploaded FYI
[17:08] <pitti> (I think..)
[17:08] <didrocks> pitti: are we already Monday?
[17:08]  * didrocks should have get some rest :)
[17:08] <pitti> heh
[17:08] <pitti> didrocks: I'll deal with yelp on Monday
[17:08]  * didrocks hugs pitti thanks!
[17:09] <didrocks> pitti: oh, you want to work on it? thanks!
[17:09]  * pitti does some more queue review and then waves good bye
[17:09] <didrocks> oO(gnome-keyring, gnome-keyring…)
[17:09] <didrocks> thanks pitti, enjoy your week-end!
[17:10] <pitti> didrocks: right, those
[17:10] <didrocks> :)
[17:11] <pitti> didrocks: you tested the gnome-keyring update, I figure? i. e. seahorse still works well for gpg?
[17:11] <didrocks> pitti: running seahorse from yesterday
[17:11] <pitti> ooh, dpkg-maintscript-helper; nice, it's the first time I see that in production
[17:11] <didrocks> yeah, it's working well it seems
[17:11] <didrocks> I tried without changing the content
[17:12] <didrocks> -> removed
[17:12] <didrocks> with changing the content
[17:12] <didrocks> -> renamed :)
[17:12] <pitti> didrocks: nice, so 2.31.92 does make it configurable already?
[17:12] <didrocks> pitti: yeah, with gsettings, not sure there is an UI (didn't check yet)
[17:12] <pitti> ah, gsettings;
[17:12] <pitti> ok, let's keep seahorse for now
[17:12] <didrocks> it's desrt's fault :)
[17:25] <pitti> good night, have a nice weekend everyone!
[17:33] <didrocks> enjoy pitti
[18:28] <DBO> mterry, you here?
[18:28] <mterry> DBO, yup
[18:28] <DBO> I seriously have my doubts about you being on the right mutter
[18:28] <DBO> I just cant reproduce the bug
[18:28] <DBO> top pixel works
[18:28] <mterry> DBO, 2.31.5-0ubuntu7
[18:28] <mterry> DBO, did you see that sabdfl reproduced it too?
[18:29] <DBO> erm sorry latest clutter
[18:29] <mterry> DBO, libclutter-1.0-0 1.2.12-0ubuntu13
[18:29] <DBO> I can video it working on my system though I suspect you will take my word it works here
[18:30] <mterry> DBO, yeah, obvi otherwise there would be a million people complaining.  I'm suspecting it's not a 100% reproducable thing.  (though I can 100% reproduce it)
[18:30] <mterry> DBO, want video card info?
[18:30] <mterry> DBO, I'm on some sort of Intel
[18:31] <DBO> need more than that
[18:31] <mterry> DBO, :)
[18:31] <mterry> DBO, Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller
[18:31] <DBO> GM965 then
[18:31]  * mterry shrugs
[18:32] <DBO> wtf then
[18:32] <DBO> hey do me a favor
[18:32] <DBO> you are running unity now?
[18:33] <DBO> send me a screenshot of your desktop
[18:33] <mterry> DBO, ok
[18:33] <mterry> DBO, I think I can see the pixel sabdfl was talking about at the top
[18:34] <DBO> thats what I am worried about
[18:34] <DBO> I am going to use gimp to find out for sure
[18:35] <mterry> DBO, in the bug
[18:36] <DBO> well fuck me sideways
[18:36] <DBO> the whole thing is offset by a pixel
[18:36] <DBO> no wonder the top pixel isn't working
[18:36] <mterry> DBO, :)
[18:37] <DBO> join me in the dx chat room please
[19:12] <didrocks> enjoy your week-end :)
[20:47] <doko> chrisccoulson: ia32-libs: why are the packages not refreshed?
[20:47] <chrisccoulson> doko - they are refreshed aren't they?
[20:48] <chrisccoulson> it's picked up the new gdk-pixbuf anyway :/
[20:48] <doko> chrisccoulson: all?
[20:50] <chrisccoulson> doko - yeah, everything that was out-of-date has a new version now
[20:50] <doko> chrisccoulson: sorry, my mistake
[20:54] <Laney> just seen bug 619003
[20:54] <ubot2> Launchpad bug 619003 in gdk-pixbuf (Ubuntu) "multiple warnings during installation (affects: 4) (heat: 20)" [Undecided,Confirmed] https://launchpad.net/bugs/619003
[20:54] <Laney> might be worth a poke
[20:55]  * chrisccoulson wipes brow
[20:55] <chrisccoulson> i thought that was because of my upload today ;)
[20:56] <chrisccoulson> but that bug is quite old
[20:56] <chrisccoulson> i nearly died there ;)
[20:56] <Laney> haha
[20:56] <chrisccoulson> i wouldn't be popular if i broke gdk-pixbuf in time for the weekend
[21:01] <devildante> mvo: ping
[21:02] <mvo> hey devildante!
[21:02] <mvo> devildante: how is it going?
[21:03] <devildante> hi mvo :) all is fine :)
[21:03] <devildante> mvo: I just wondered if there are any bugs targeted for fixing in 10.10 in USC or update-manager
[21:05] <mvo> devildante: there is a nasty race 507836 in s-c
[21:05] <devildante> bug 507836?
[21:05] <ubot2> Launchpad bug 507836 in software-center (Ubuntu) "[master] software-center crashed with DatabaseModifiedError in _database_gen_postlist_iter() (affects: 89) (dups: 58) (heat: 527)" [High,Triaged] https://launchpad.net/bugs/507836
[21:05] <mvo> devildante: but a bit of triage would be cool, all the stuff with apport traceback is probably worth a look
[21:06] <devildante> pff, you just said in the comments you fixed it :p
[21:06] <mvo> no really :)
[21:06] <devildante> silly me, it's only the UI :p
[21:07] <mvo> just made the effects go away, the root is still there
[21:07] <mvo> the "fix" just recovery nicely
[21:07] <devildante> 'kay :)
[21:07] <mvo> well, "just" is already good, but fixing the root cause would rock
[21:07] <mvo> I have no good idea currently :/ but maybe a fresh brain is needed :)
[21:07] <devildante> so we need some triaging before determining the root?
[21:08] <mvo> for this bug I think the root is a race condition between the apt-cache-reopen and the xapian-db-rebuilding (or finish rebuilding). if both overlap, the problem appears
[21:08] <mvo> but a general triage of the bugs in NEW state would be great, I'm sure there are some low hanging ones
[21:08] <devildante> hmm...
[21:08] <mvo> (i.e. easy to fix ones, if we get good backtraces from apport)
[21:09] <devildante> Don't have time, I have to prepare a hugday :p
[21:10] <mvo> haha
[21:10] <mvo> excellent
[21:10] <mvo> on what package is it?
[21:10] <devildante> Not a specific package, it will be jaunty bugs
[21:11] <devildante> we "need" to treat these bugs before jaunty goes EOL
[21:11] <devildante> not really need, but it would be great :)
[21:21] <mvo> woah
[21:21] <mvo> cool :)
[21:21] <devildante> is it that great? :p
[21:21] <mvo> its cool to do this kind of gardening
[21:21] <devildante> heh :)
[21:42] <robbiew> mvo: up late?
[21:47] <mvo> robbiew: yes
[21:48] <mvo> robbiew: merging a python-apt fix that looked super-simple and turned out to be not quite-as-simple as anticipated
[21:48] <robbiew> ah...a common trap in coding ;)
[21:48] <mvo> lol
[21:48] <mvo> indeed