[09:48] <jml> compiz is chewing up a lot of CPU
[09:48] <jml> should I file a bug about this? (precise)
[10:38] <dbarth> jml: yes please
[10:39] <dbarth> jml: it's weird because i don't think there was a new version released
[10:39] <dbarth> jml: so that must be external causes
[10:40] <jml> dbarth: ok. will do.
[10:41] <dbarth> jml: just let me know of the bug number or subscribe me
[10:46] <jml> dbarth: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/906816
[10:46] <ubot2> Launchpad bug 906816 in compiz "compiz always using significant chunk of CPU" [Undecided,New]
[12:09] <dbarth> jml: thanks
[13:19]  * rodrigo_ lunch
[13:49] <Riddell> is there a meeting today?
[13:52] <pitti> Riddell: don't think so; half of the team or more is on vac already
[14:02] <dobey> pitti: uh, firefox/etc are really reporting bytes transfered as base 10 rather than base 8?
[14:02] <pitti> dobey: nautilus/gvfs etc. is; I'm not entirely sure of firefox
[14:03] <dobey> that is not very nice
[14:04] <pitti> I think firefox still gets it wrong, too
[14:04] <dobey> base 10 is wrong :)
[14:04] <pitti> no, it's not
[14:05] <dobey> it is when you are transferring in blocks of base 8
[14:05] <pitti> unless you only have two fingers
[14:05] <pitti> but we don't
[14:05] <pitti> or if we do, it's absolutely uninteresting for a human-readable size
[14:06] <pitti> but anyway, we've been through this, and https://wiki.ubuntu.com/UnitsPolicy is the result now
[14:06]  * ogra_ grumbles about ubuntu-docs taking over 30min to unpack in precise ... that was only 15min in oneiric, did it really grow so much or are we using some insane compression mechanism now ?
[14:07] <pitti> dobey: anyway, even if you want base-2, then format_size_for_display is still wrong
[14:07]  * ogra_ expects the same issue for gnome-user-docs ...
[14:07] <pitti> dobey: as it doesn't use the correct units then, like MiB/GiB
[14:08] <dobey> pitti: i didn't say format_size_for_dispay was right
[14:08] <dobey> but it's all there is in glib < 2.30
[14:08] <pitti> dobey: but as format_size_for_dispay was essentially unfixable, they deprecated it
[14:08] <pitti> dobey: right, for older releases we just have to live with it
[14:09] <pitti> dobey: but I sent an updated MP which now gets along with both
[14:09] <pitti> it gives the correct output for >= 2.30, and remains unchanged for < 2.30
[14:09] <pitti> which is pretty much what we want for SRUs, etc.
[14:09] <dobey> what i'm saying, is the policy seems to be broken
[14:10] <dobey> pretty much *everything* reads/writes data in 4096 byte blocks, not 1000 bit blocks
[14:10] <pitti> how is that relevant?
[14:11] <pitti> it doesn't matter if your read/write block size is 1024 or 1234567
[14:11] <pitti> what you display are either file sizes or transfer rates
[14:11] <dobey> because it's readying bytes, not bits
[14:11] <dobey> reading, not readying
[14:11] <pitti> ok, I'm afraid I don't follow
[14:11] <pitti> which part of the policy do you think is broken?
[14:12] <pitti> (or the g_format_size() implementation for that matter?)
[14:13] <dobey> the g_format_size implementation is fine; it just calls g_format_size_full () with the default of using 1000 instead of 1024, and _full lets you use 1024. i think defaulting to 1000 is a bad idea, vs requiring developer to make a conscious choice, but whatever, i don't care to argue that
[14:14] <pitti> well, that was made because in all except rare circumstances 1000 is the right default now
[14:15] <dobey> and i fundamentally disagree with perpetuating the lies of an entire industry, but whatever. ex post facto standards are complete bollocks, if you ask me. :)
[14:15] <kenvandine> oh interesting, i didn't know about the UnitsPolicy page... i've wondered about that a couple times in the past
[14:15] <dobey> i think the network bandwidth thing is wrong, though
[14:17] <pitti> well, it's not ex post fact
[14:17] <pitti> humans have counted in base-10 (well, some in base-60) for centuries
[14:18] <pitti> just some nerds a couple of decades ago thought it was a good idea to confuse people with a Mega-something which is not actually what Mega- means
[14:18] <kenvandine> it makes sense, normal humans prefer easy number
[14:18] <kenvandine> +s
[14:18] <pitti> someone just abused the SI prefixes to mean something different
[14:18] <pitti> _that_ was the confusion, not switching back to real base-10 prefixes
[14:18] <dobey> pitti: computers have never counted in base 10
[14:19] <pitti> why should users care?
[14:19] <kenvandine> dobey, computers != humans
[14:19] <dobey> the IEC standard didn't exist until 1998
[14:19] <dobey> and hard disk manufacturers had been cheating since way before then
[14:19] <kenvandine> we're talking about representing the information to humans not computers
[14:20]  * kenvandine stops feeding the dobey :)
[14:20] <pitti> dobey: why cheating?
[14:20] <pitti> dobey: 100 MB == 100.0000.000 Bytes
[14:20] <dobey> humans don't care. they just want the computer to match what the box says.
[14:20] <dobey> when they see certain things
[14:20] <pitti> (scratch that extra 0, YKWIM)
[14:20] <dobey> there is no box label for how many bytes your computer transferred across the network
[14:21] <pitti> what I do agree to is that using the base-2 prefixes is confusing
[14:21] <pitti> like, 100 MiB for file sizes, etc.
[14:21] <pitti> since users do not know what these really are either
[14:21] <pitti> we still need them for total mem size
[14:22] <dobey> the XiB crap is annoying because of the i
[14:22] <pitti> that's why we shouldn't use it for most things :)
[14:23] <dobey> people making stupid naming choices in a standard is no excuse for avoiding base 2
[14:23] <dobey> "we'll just make stupid names for things, so nobody will use them!"
[14:23]  * pitti stops any hope of getting dobey out of his geek unit world, and just STFU :)
[14:24] <kenvandine> pitti, it is hard not to feed the dobey :)
[14:24] <pitti> dobey: if you had written the standard, which prefixes would you have chosen, OOI?
[14:25] <dobey> drwxr-xr-x   2 dobey dobey      4096 2011-05-06 16:19 我的光碟/
[14:25] <dobey> drwxr-xr-x   2 dobey dobey 4.0K 2011-05-06 16:19 我的光碟/
[14:25] <dobey> :)
[14:25] <dobey> pitti: i wouldn't pick names that sounded like they came from care bears, at least
[14:25] <pitti> but that's a lie :)
[14:26] <pitti> it's 4.096 K
[14:26] <dobey> pitti: so do you have a patch for ls?
[14:26] <pitti> https://wiki.ubuntu.com/UnitsPolicy#Exception
[14:26] <pitti> dobey: --si
[14:33] <pitti> dobey: http://xkcd.com/394/ is an even clearer standard :)
[16:09] <ricotz> jbicha, hi
[16:11] <ricotz> jbicha, good catch and interesting patch in gnome-themes-standard for nautilus, but i think something like this would be better http://paste.debian.net/plain/149749
[16:12] <jbicha> ricotz: oh, would that work too?
[16:12] <jbicha> I don't actually understand theming
[16:13] <ricotz> jbicha, this is hard to notice, but it only draws this dark line?
[16:13] <ricotz> and this smaller change does the same, and wouldnt break nautilus 3.3
[16:15] <jbicha> ricotz: yeah, it would be better to work with both nautilus 3.2 and 3.3
[16:15] <ricotz> as long nautilus 3.2 doesnt use GtkGrid it doesnt interfere with the newer style definitions
[16:16] <ricotz> jbicha, please change it then
[16:16] <jbicha> ricotz: yes, doing it now :)
[16:16] <ricotz> thanks
[16:35] <ricotz> jbicha, you messed the patch up :(
[16:35] <ricotz> jbicha, please look at the paste again
[16:35] <ricotz> do it exactly that way
[16:46] <jbicha> ricotz: sorry, I'll just copy and paste then
[17:23] <ricotz> jbicha, me again ;), the break against fglrx in g-s arent compatible with ubuntu
[17:24] <ricotz> i think it should be something like "fglrx (<< 2:8.910)"
[17:33] <jbicha> ricotz: maybe we could just leave that line out since I hear that the latest fglrx still doesn't work right for everyone w/ gshell
[17:37] <jbicha> ricotz: also you should join the desktop team
[17:39] <ricotz> jbicha, yes, dropping the line would be the best
[17:42] <jbicha> actually, fglrx-driver isn't in Ubuntu at all, so I don't think the breaks hurts anything to be left in
[17:43] <ricotz> indeed ;)
[17:48] <ricotz> jbicha, on the other hand i was thinking fglrx 2:8.911 fixed some things
[18:00] <pitti> cyphermox: did you sync libnl3?
[18:00] <pitti> ah, there's a MIR already for xmlstarlet, nevermind
[18:08] <jbicha> ricotz: I was thinking of 8.881 which still had problems but I don't run ATI so I don't know if the problems are fixed now or not
[18:08] <cyphermox> pitti: yeah
[18:08] <cyphermox> I just did the MIR too, I had forgotten all about hte new xmlstarlet requirement
[18:17] <ricotz> jbicha, ok, i thought i read some good news about the newer driver
[18:36] <pitti> happy holidays everyone! I'll stop IRC now, please mail me if you need me to do something over the holidays (no response time guarantee, though)
[18:42] <broder> where's the best place to send feedback on dx's multi-display spec? ayatana@lists.lp?
[19:21] <mterry> chrisccoulson, hey, congrats!
[21:47] <alex_mayorga> Hello! Can someone here help me get rid of bug 907012
[21:47] <ubot2> Launchpad bug 907012 in indicator-datetime "indicator-datetime uses 80% of RAM or 3.1g" [Undecided,Confirmed] https://launchpad.net/bugs/907012