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