[00:26]  * rickspencer3 braces for $sudo apt-get dist-upgrade tonight
[00:27] <robert_ancell> rickspencer3, have you not gone lucid yet?
[00:28] <rickspencer3> robert_ancell, not yet
[00:28] <rickspencer3> but tonight
[00:29] <Amaranth> rickspencer3: Should be fun
[00:30] <Amaranth> I hope your computer doesn't have an accelerometer
[00:31] <Amaranth> Xorg decided my accelerometer was a joystick so when I'd bump my desk or press on the keyboard it'd cause it to move a little which would move my mouse to the center of the screen
[00:31] <Amaranth> was good times
[00:31] <rickspencer3> hehe
[00:31] <rickspencer3> I will be upgrading my desktop first, so should be ok
[00:32] <Amaranth> Once I figured it out it was pretty awesome, actually
[00:32] <Amaranth> I picked my laptop up and moved it around to open a terminal and turn it off :)
[00:33] <rickspencer3> hehe
[00:36] <Keybuk> Amaranth: what was the button click?
[00:36]  * Keybuk has images of Amaranth slamming his laptop onto the floor to click on things
[00:36] <Amaranth> Keybuk: Probably dropping the laptop but I just used the mouse for that :P
[00:36] <Keybuk> you know what this means?
[00:36] <Keybuk> X HAS HOT-PLUGGABLE ACCELEROMETERS!
[00:37]  * Keybuk images the possibilities
[00:37] <Keybuk> ...err...possibility
[00:37] <Keybuk> ...err...
[00:37] <Amaranth> heh
[00:41] <Keybuk> damnit
[00:41] <Keybuk> I just realised why this kernel build is taking forever
[00:41] <Keybuk> forgot to comment out the additional flavours
[00:42] <Amaranth> building 5 kernels is always fun
[00:44] <Keybuk> I had to turn my heating off :p
[00:44] <rickspencer3> Keybuk, is that kernel build going to make the desktop come up faster?
[00:44] <rickspencer3> hehe
[00:44] <Keybuk> rickspencer3: it includes a patch to the i915 KMS driver
[00:44] <rickspencer3> we're down to 11.82s
[00:44] <Keybuk> rickspencer3: I saw
[00:45] <rickspencer3> chip chip chip
[00:45] <Keybuk> rickspencer3: I love the fact that a quick bug fix to the X package got it within budget
[00:45] <Amaranth> rickspencer3: based on previous experience I think my compiz packaging changes will drop that down to 11
[00:45] <Keybuk> I don't think tjaalton even realised it was a performance problem
[00:45] <Keybuk> though that being said
[00:45] <Keybuk> xkbcomp caching isn't working
[00:45] <Keybuk> so X may get even faster again
[00:45] <Amaranth> If X gets under budget we could use some of that time :)
[00:45] <rickspencer3> Amaranth, thank you :)
[00:46] <Amaranth> rickspencer3: but seb128 doesn't seem to want me to do it the way I am
[00:46] <rickspencer3> hmm
[00:46] <Amaranth> so I'll have to have ugly package names like compiz-plugins-universe
[00:47] <rickspencer3> usually turns out seb128 is right ;)
[00:47] <Amaranth> Well I want to add about 70 new binary packages (one for each plugin) instead of just splitting things into "stuff we use" and "stuff we don't use"
[00:47] <rickspencer3> hmm
[00:48] <rickspencer3> s'lot
[00:48] <asac> 70 binary packages feels bad ;)
[00:48] <asac> without knowing anything ;)
[00:48] <Amaranth> we have a lot of plugins :)
[00:48] <Amaranth> actually it'd be 54 new binary packages
[00:48] <asac> yeah. but maybe packages is not the right mechanism to split them up on a one-by-one base
[00:48] <Amaranth> since I wouldn't split the compiz-fusion-plugins-extra package
[00:48] <asac> what would we gain by such a split?
[00:49] <Amaranth> well the main goal is to not install plugins we don't use
[00:49] <asac> e.g. how does that reflect on user experience?
[00:49] <Amaranth> but I figured why I was in there I could make it possible for users to only install the plugins they actually use as well
[00:49] <asac> why not? disk usage (unlikely) startup time due to unneeded loading?
[00:49] <asac> (why not ship not used plugins)
[00:49] <rickspencer3> asac, compiz only loads the plugins in use?
[00:49] <asac> i dont know
[00:49] <asac> ;)
[00:50] <Amaranth> well not installing compiz-fusion-plugins-extra cut 0.5 seconds off login time
[00:50] <asac> i want to understand the motiviation. maybe it loads everything on startup and just disregards what is not used (this would indicate that not installing it might help in time consumptioN)
[00:50] <Keybuk> what happens if you link all the plugins into compiz itself?
[00:50] <Keybuk> so instead of loading 1,461,395 .so files
[00:50] <Amaranth> compiz stats at least the .so and the .xml file and libcompizconfig (and thus compiz via the ccp plugin) loads the information for _every_ installed plugin
[00:50] <Keybuk> it just has them all built in?
[00:50] <Amaranth> Keybuk: I was thinking about that, actually
[00:51] <Amaranth> link at least some of them directly to compiz and hack it so when it tries to load those plugins it just dlopens itself
[00:51] <Keybuk> no
[00:51] <Keybuk> no dlopen
[00:52] <Keybuk> link them directly to compiz with an array of structures
[00:52] <Amaranth> we already dlopen and I don't want to hack that much :P
[00:52] <Keybuk> which have function pointers
[00:52] <Keybuk> that's my whole point you numpty
[00:52] <Keybuk> dlopen() is slow
[00:52] <Keybuk> the relocations caused by dlopen() are slow
[00:52] <Amaranth> I was talking to get rid of the IO
[00:52] <asac> dlopen is slow for already loaded stuff even?
[00:52] <Keybuk> there is no I/O
[00:52] <Keybuk> asac: yes, because you still relocate
[00:52] <Amaranth> hrm
[00:52]  * Keybuk sees nothing but CPU
[00:52] <asac> hmm. thought some scope might just fail quick saying "already loaded"
[00:52] <Amaranth> I see a little IO on mine
[00:52] <Keybuk> and I would bet money that at least some of that is the overhead of dlopen()ing everything
[00:53] <Keybuk> rather than just having them builtin with an array of structures
[00:53] <asac> instead of doing all the actual linking etc.
[00:53] <Amaranth> oh, that reminds me, we're screwing up huge with compiz right now
[00:53] <asac> also adding so many packages kicks our already slow packaging index a bit further
[00:53] <Amaranth> the first time compiz is loaded the ccp plugin loads the XML files and writes out protobuf versions which it can then use instead
[00:53] <Amaranth> they load a lot faster
[00:54] <Amaranth> but I'm pretty sure we don't generate those for the .deb so when you guys bootchart the first boot after install...
[00:54] <asac> where does it load that to atm? user home?
[00:54] <asac> protobuf that is
[00:55] <Amaranth> asac: yeah, ~/.cache/compizconfig/
[00:56] <Amaranth> much less CPU time to parse protobuf vs XML (especially since it uses XPath)
[00:56] <asac> so can that be pregenerated in a system location?
[00:56] <asac> would that be useful? or does that need to be regenned because of user settings anyway?
[00:57] <Amaranth> although in the bootcharts by the time you see it spawn compiz-decorator all plugins and settings are initialized and most of the CPU usage is after that
[00:57] <Amaranth> asac: It only needs to change when the xml file changes
[00:57] <asac> those are system xml files?
[00:57] <Amaranth> right
[00:57] <asac> e.g. could be done by a trigger or update-compiz-stuff in postinst?
[00:57] <Amaranth> the user settings are in gconf
[00:57] <Amaranth> it could, yes
[00:58] <asac> ok. but changing those user settings would also require a full cache regen?
[00:58] <asac> in .cache... ?
[00:58] <Amaranth> but then compiz would build-dep on libcompizconfig
[00:58] <Amaranth> no, changing user settings has nothing to do with the xml or protobuf files
[00:58] <asac> ok
[00:58] <asac> how much time would you think will those protobuf files save?
[00:58] <asac> is that worth the effort?
[00:58] <Amaranth> dunno
[00:58] <asac> ;)
[00:59] <Amaranth> I'd need to do a clean install of lucid then two boots
[00:59] <asac> what state do they remember?
[00:59] <Amaranth> the protobuf files hold exactly the same information as the xml files
[00:59] <asac> so you still need to open .so's to decide whether you want that loaded or not?
[00:59] <Amaranth> so plugin dependencies, options, descriptions of the plugins and the options
[00:59] <asac> plugins
[01:00] <Amaranth> bleh, I bet that's why removing compiz-fusion-plugins-extra saved so much time
[01:01] <Amaranth> asac: no, compiz should just be loading the core.xml file and the plugins and xml files for plugins specified on the command line then ccp tells it what the active_plugins setting is and it loads those plugins and xml files
[01:02] <Amaranth> but compiz can also tell you what plugins are enabled and I'm pretty sure it checks that on startup by stat'ing everything in /usr/lib/compiz...
[01:02] <Amaranth> s/enabled/installed/
[01:03] <asac> hmm
[01:03] <asac> stating or dlopening?
[01:04] <asac> Amaranth: ?
[01:04] <Amaranth> just stat, iirc
[01:04] <asac> that should be quite quick. if its just a timestamp compare
[01:04] <asac> at least i dont have a zilions of files there ;)
[01:04] <asac> so the xml files parsing would be saved by doing the caching?
[01:06] <Amaranth> ok, it doesn't stat all the plugins unless you ask it to via dbus so that isn't a problem
[01:06] <Amaranth> so the main thing is going to be core reading the XML files (required) and not having the protobuf cache for libcompizconfig
[01:07] <asac> right. and the protobuf saves us from doing more parsing?
[01:08] <Amaranth> but at least on my latest bootchart almost all the CPU usage is _after_ compiz-decorator is started which means at that point compiz has initialized all the plugins and loaded all of their settings from gconf
[01:08] <Amaranth> so the only way to know if there is any win at all is to try it
[01:08] <asac> yeah. probably
[01:08] <Amaranth> so I need a clean lucid install and bootcharts for the first boot and the second boot
[01:09] <Amaranth> I have no idea how people are producing bootcharts for their mini 10v systems though
[01:09] <Amaranth> If the first boot already has bootchart and that is being used this could be a win
[01:09] <Amaranth> if not, we've already got the protobuf files
[01:10] <Amaranth> but that does seem to prove dlopen isn't hurting at all unlike what Keybuk was saying
[01:11] <Keybuk> I produce lots of bootcharts for mini10vs
[01:11] <Keybuk> what charts would you like?
[01:11] <Amaranth> Keybuk: When you do the daily bootcharts is that automated?
[01:11] <Keybuk> yes
[01:11] <Amaranth> If so, is that the very first boot into the installed system?
[01:12] <Keybuk> second boot
[01:12] <Amaranth> Ok, so now I'm lost
[01:12] <Keybuk> what would you like to know?
[01:12] <Amaranth> What the heck compiz is doing using so much CPU _after_ it has loaded all of the plugins and their configuration :)
[01:13] <Keybuk> I suspect printf() will be your friend
[01:13] <Amaranth> If you look on your bootchart all the compiz CPU usage is after compiz-decorator starts but that doesn't start until compiz is "finished" loading
[01:14] <Keybuk> some deferred work in the main loop perhaps?
[01:14] <Keybuk> an idle timer function?
[01:14] <Amaranth> I don't think we even have those
[01:14] <Keybuk> http://people.canonical.com/~scott/tmp/max-lucid-20091209-1.png
[01:14] <Amaranth> wow that's a very long chart
[01:14] <Keybuk> that's a "first boot" chart of alpha 1
[01:14] <Keybuk> http://people.canonical.com/~scott/tmp/max-lucid-20091209-2.png
[01:14] <Keybuk> that's the "second boot" chart
[01:15] <Keybuk> (the second boot charts are the ones that get published on daily-bootcharts)
[01:15] <Keybuk> Amaranth: mine are longer than most people's ... I don't like to brag
[01:15] <Amaranth> heh, what is up with udevd there?
[01:15] <Keybuk> nothing
[01:16] <Keybuk> bootchart normally condenses things a bit
[01:16] <Amaranth> ok on your charts compiz is showing a lot of CPU usage before compiz-decorator loads too
[01:16] <Keybuk> hides a lot of the detail
[01:16] <Amaranth> but most of it is still after
[01:16] <Keybuk> when I generate them myself, I tell it not to do that, so I get all of the processes and detail
[01:16] <Keybuk> they're less easy to read, but have more information
[01:17] <Keybuk> Amaranth: so what I'd do is start sticking printfs throughout compiz
[01:17] <Amaranth> this is going to suck :P
[01:17] <Keybuk> grab the kernel uptime clock and put that at the front
[01:17] <Keybuk> (or just write to the kmsg device)
[01:17] <Keybuk> then you'll have numbers that tell you how far into the boot it was doing what
[01:19] <Amaranth> oh, it looks like robert-ancell already did all of this
[01:19] <Amaranth> there is a nice 090_profiling patch in compiz that just needs a build flag to enable
[01:20] <Amaranth> a nice patch which I broke with my changes, whee
[01:30] <Keybuk> don't you just hate that
[01:30] <Keybuk> gcc has stuff to add profiling hooks to functions too
[01:30] <Keybuk> that's quite handy
[01:30] <Keybuk> you build your source with extra flags
[01:30] <Keybuk> and LD_PRELOAD in a hook library when you run it
[01:31] <Keybuk> your hook gets called for every function call
[01:31] <Keybuk> so you can instrument it
[01:32] <Amaranth> neat
[01:33] <Amaranth> if I'm reading this correctly even with a warm cache and already logged in compiz takes 2.14 seconds to load :/
[01:34] <Amaranth> takes 0.01 seconds to load and parse the core.xml file, not as bad as I thought
[01:35] <Amaranth> 0.06 seconds to load our "required" plugins (ccp, move, resize, decoration, place)
[01:35] <Amaranth> oh, and crap
[01:36] <Amaranth> it loads the settings for each plugin as it loads the plugin (duh) so we've only loaded those 5 plugins when compiz-decorator starts
[01:37] <Amaranth> I'll have to check this on boot but it looks like loading most of the plugins is "free"
[01:37] <Amaranth> except of course for the ones we absolutely want to have (wall, animation, commands, etc)
[01:37] <Amaranth> brb, rebooting
[01:44] <Amaranth> hmm, according to this compiz starts in about 0.6 seconds on boot
[01:45] <Amaranth> but 0.77 the second boot (with ureadahead that time)
[01:45] <Amaranth> hrm
[01:45] <Keybuk> on your bootchart?
[01:46] <Amaranth> no, with this profiling patch
[01:46] <Keybuk> I think you're getting too preoccupied with when compiz hits the main loop
[01:46] <Amaranth> it goes from startup to the first time eventLoop is idle
[01:46] <Keybuk> if it hits the main loop quickly, that's nice
[01:46] <Keybuk> it's still churning away
[01:46] <Keybuk> so whatever is eating all the CPU must be happening afterwards
[01:46] <Amaranth> and apparently compiz does have idle timers because all plugin loading happens in the eventLoop
[01:47] <Amaranth> so the first time it is idle that should mean it is done loading
[01:47] <Amaranth> it hits the first idle after it has loaded all of the plugins and their settings, anyway
[01:48] <Amaranth> so any further processing is within the plugins and the (most likely) unavoidable overhead of using compiz
[01:51] <Amaranth> at this point I'm thinking using metacity by default in lucid is going to be far less painful then trying to optimize the animation plugin
[01:54] <Keybuk> why is there any animation?
[01:54] <Keybuk> nothing is happening on screen
[01:54] <Keybuk> just a big window in front of everything with a bit of a throbber
[01:54] <Amaranth> Keybuk: the animation plugin does something with basically every X event
[01:55] <Keybuk> can we turn that plugin off until we're ready? :p
[01:55] <Amaranth> compiz sort of "flashes" when you enable/disable a plugin
[01:55] <Keybuk> so make the plugin start "off"
[01:55] <Keybuk> and don't hook into X until it's turned "on"
[01:55] <Amaranth> hmm, actually it doesn't seem to flash anymore
[01:56] <Amaranth> heck we could delay enabling every plugin except ccp, move, resize, place, and decoration if you want to go down that route
[01:56] <Amaranth> oh, and session
[01:56] <Keybuk> why do we even need those?
[01:57] <Keybuk> we have no windows to move, resize, place or decorate
[01:57] <Keybuk> just one big plymouth/xsplash window which was already in the right place anyway
[01:57] <Amaranth> well we need ccp, session, and decoration so we can put everything back where it was before (if you saved a session)
[01:57] <Amaranth> the others are just the ones we force you to have enabled and the way we do that prevents us from doing any tricks with delayed loading
[01:57] <Keybuk> it doesn't need to get put back until after everything else is loaded surely?
[01:58] <Amaranth> Do you want xsplash to go away _then_ have all of your windows gain a decoration and jump to the proper position?
[01:59] <Keybuk> no
[01:59] <Keybuk> just do it last
[01:59] <Keybuk> in one step
[01:59] <Amaranth> otherwise for the rest I guess I just need compiz to hook into the same thing xsplash does to know when to go away
[02:00] <Amaranth> of course now we're cheating and dumping all the CPU load right at the time the user is going to start trying to use the system...
[02:01] <Keybuk> no, just before
[02:01] <Amaranth> but I guess we do that with other things too
[02:01] <Keybuk> basically
[02:01] <Amaranth> right, it'll start happening while xsplash is doing the fade
[02:01] <Keybuk> if you're saying that CPU load is all compiz responding to things that are happening that the user can't see anyway
[02:01] <Keybuk> why not disable all that
[02:02] <Keybuk> and then, just before xsplash goes away, do it all in one great big lump
[02:02] <Keybuk> then take xsplash away
[02:02] <Keybuk> no
[02:02] <Keybuk> do it before xsplash fades
[02:02] <Amaranth> uh, how?
[02:02] <Keybuk> co-operate between the two
[02:02] <Amaranth> I'd like to point out compiz doesn't do dbus
[02:02] <Keybuk> xsplash tells compiz it's going to fade, and waits for compiz to say "I'm done"
[02:02] <Keybuk> that kind of thing
[02:02] <Keybuk> really?
[02:02]  * Keybuk spies a compiz dbus plugin
[02:02] <Amaranth> well, we have a dbus plugin but then we'd have to load a plugin :P
[02:02] <Amaranth> Yeah, I sort of wrote that plugin :P
[02:03] <Keybuk> you said loading plugins was free :p
[02:03] <Keybuk> and were blaming what the plugins did when nobody could see <g>
[02:03] <Keybuk> all I'm pointing out is that there's a solution for any problem :D
[02:03] <Amaranth> well looking at the profiling the delta between loading that plugin and loading the next is 0.01 or so
[02:03] <Amaranth> sure but a solution that requires 10 hours of work is going to take a month for me to finish
[02:04] <Keybuk> that's cool
[02:04] <Keybuk> we have more than four
[02:04] <Keybuk> for now, adding sleep (10) into compiz startup would be a good way to find out if that was the problem? :p
[02:04] <Keybuk> if we make compiz start, init, then just sleep
[02:05] <Keybuk> see what happens
[02:05] <Amaranth> yeah, I could put that right before eventLoop, would be a great way of seeing if all of this is happening in the eventLoop anyway
[02:06] <Keybuk> if you throw me a deb (PPA is good) then I'll happily test it out on the mini
[02:06] <Amaranth> hrm, I really need another computer to run this stuff on
[02:06] <Amaranth> having to keep rebooting the one I'm on IRC with is lame
[02:08]  * Amaranth debates wiping out the computer people play games on
[02:14] <Amaranth> Keybuk: btw, that idea of linking plugins directly to compiz is starting to sound better and better
[02:15] <Amaranth> I've thought up a way to do it without getting too crazy and would still allow loading plugins the normal way
[02:15] <Keybuk> oh? :)
[02:16] <Keybuk> usual way is that each plugin has some kind of struct-o-function-pointers
[02:16] <Keybuk> which is what you find with dlopen() anyway
[02:16] <Amaranth> And we do, right
[02:16] <Keybuk> to build them in, you just have a script make a C file that turns those into an array
[02:16] <Keybuk> then for (plugin **p = builtin_plugins; p && *p; p++)
[02:16] <Keybuk>   *p->init()
[02:16] <Keybuk> type thing
[02:17] <Amaranth> yep, will look at that this weekend
[02:17] <Keybuk> this is
[02:17] <Keybuk> exactly
[02:17] <Keybuk> how the kernel works ;)
[02:17] <Keybuk> if you =y, you get the same code (mostly)
[02:18] <Keybuk> then an auto-generated C file that has pointers to them all
[02:18] <Amaranth> of course if I also want to make compiz stop loading the XML for the plugins this could get somewhat more complicated
[02:18] <Amaranth> but XPath is apparently not as slow as I thought
[02:18] <Amaranth> Either way compiz in lucid is going to look nothing like upstream though :/
[02:19] <Amaranth> but they do want to be able to compile plugins into core upstream as well so I suppose I could just port the stuff to the C++ code and submit it there once I'm done
[05:21] <Omen_20> hi. can u use the same image ud install from a cd, on a usb pendrive?
[05:23] <robert_ancell> Omen_20, yes, use System>Administration>Startup Disk Creator
[05:23] <jmarsden> See also https://help.ubuntu.com/community/Installation/FromUSBStick
[05:24] <Omen_20> oh ok. so this makes an iso image usable from a pendrive?
[05:24] <robert_ancell> yes
[05:25] <Omen_20> sweet. thanks! I hoped there was an easy way. CDs were starting to feel wasteful and now that im on break and have a TB drive I want to try out tons of stuff.
[05:25] <robert_ancell> Omen_20, np, have fun!
[05:26] <Omen_20> :D
[06:49] <pitti> Good morning
[06:53] <didrocks> Guten Morgen pitti
[06:53] <pitti> bonjour didrocks
[07:29] <glatzor> morning pitti
[07:32] <pitti> hey glatzor
[07:49] <glatzor> hello bryce, do you know how I could access the icon of a window from gtk?
[07:49] <glatzor> bryce, the WM_ICON_NAME property doesn't seem to be handled very well by metacity
[07:49] <glatzor> it is just the same as WM_NAME
[07:54] <tjaalton> Keybuk: what was a performance problem?
[07:54] <baptistemm> heya
[08:36] <chrisccoulson> good morning everyone
[08:39] <seb128> hello desktopers
[08:41] <chrisccoulson> hello seb128
[08:41] <seb128> hey chrisccoulson
[08:41] <seb128> did you manage to sleep at all? ;-)
[08:42] <seb128> you seem to always be there :-p
[08:42] <chrisccoulson> seb128 - i slept for 3 hours :)
[08:42] <seb128> urg
[08:43] <seb128> you must be glad that tomorrow is saturday ;-)
[08:43] <chrisccoulson> i shall be brewing my coffee extra strong this morning
[08:43] <chrisccoulson> yeah, i'm glad that tomorrow is saturday ;)
[08:43] <didrocks> salut seb128
[08:43] <didrocks> morning chrisccoulson
[08:43] <chrisccoulson> hey didrocks
[08:43] <seb128> hum, coffee, looks like a good idea indeed
[08:44] <seb128> hey didrocks
[08:48] <pitti> bonjour seb128, hey chrisccoulson
[08:48]  * pitti back from pm-utils debugging
[08:48] <chrisccoulson> good morning pitti
[08:49] <seb128> hey pitti
[08:49] <seb128> how are you?
[08:51] <seb128> pitti, btw not sure if you read log from night in the morning or not
[08:52] <seb128> pitti, the work item count for lucid is somewhat wrong
[08:53] <pitti> http://piware.de/workitems/desktop/lucid/report.html ?
[08:53] <pitti> seems fine to me
[08:53] <pitti> (no, I didn't see that bit)
[08:54] <seb128> pitti, somewhat around 1am hour time
[08:54] <seb128> if you have log
[08:54] <pitti> I do
[08:54] <seb128> basically some specs have alpha3 or beta1 wis
[08:54] <seb128> and those are on no count
[08:54] <pitti> right
[08:55] <pitti> that's a current limitation in the parser
[08:58] <seb128> hum, it should perhaps list anything in the "work item.*:" format as for lucid now?
[08:58] <seb128> right now we have tens of items not on the charts
[08:59] <seb128> so the trend and counts are somewhat biased
[08:59] <pitti> right
[09:01] <pitti> ok, let me look into that
[09:02] <seb128> thanks
[09:06] <seb128> pitti, btw while I'm a it review from the indicator package in new is welcome
[09:06] <seb128> I sponsored it for kenvandine yesterday
[09:06] <seb128> but I didn't want to source NEW since I uploaded
[09:06] <pitti> ok
[09:07] <seb128> thanks
[09:08]  * seb128 stops bothering pitti now
[09:24] <chrisccoulson> ah
[09:25] <chrisccoulson> it seems my phone was playing up when i went away for breakfast
[09:25] <seb128> hehe
[09:25]  * seb128 start looking at strace and http://people.canonical.com/~seb128/nautilus again now
[09:26] <chrisccoulson> excellent, that will probably keep you occupied for some time ;)
[09:26] <seb128> I wonder if we could reduce the number of stats on alternative paths
[09:26] <seb128> like /usr/local/...
[09:26] <seb128> and if that would make a difference
[09:26] <seb128> I guess stat calls are cheap usually
[09:28] <chrisccoulson> yeah, i'm not too sure
[09:29] <chrisccoulson> how come it needs to stat() user folders such as downloads and public when it starts?
[09:29] <chrisccoulson> if it's not displaying a window
[09:29] <chrisccoulson> anyway, time for me to grab another coffee:)
[09:29] <seb128> could comment
[09:29] <seb128> ups, "good comment"
[09:33] <seb128> grep stat nautilus.strace | grep ENO | wc -l -> 707
[09:33] <seb128> 652 of those being for icons
[09:34] <seb128> I'm wondering if we could check for /usr/local/icons earlier and avoid stating each subdir
[09:34] <seb128> or /usr/local/share/icons rather
[09:37] <chrisccoulson> seb128 - so, it checks for subdirectories of /usr/local/share/icons before making sure that the parent directory exists?
[09:38] <seb128> 1420  14:24:08.630795 stat64("/usr/local/share/icons/hicolor/16x16/apps", 0xbfb17340) = -1 ENOENT (No such
[09:38] <seb128> file or directory)
[09:38] <seb128> 1420  14:24:08.631034 stat64("/usr/share/nautilus/icons/hicolor/16x16/apps", 0xbfb17340) = -1 ENOENT (No su
[09:38] <seb128> ch file or directory)
[09:38] <seb128> 1420  14:24:08.631357 stat64("/usr/local/share/icons/hicolor/16x16/categories", 0xbfb17340) = -1 ENOENT (No
[09:38] <seb128>  such file or directory)
[09:38] <seb128> etc
[09:38] <seb128> etc
[09:38] <seb128> it does that for each dir from the index
[09:40] <chrisccoulson> vuntz - do you know what is happening about implementing a new shutdown API in consolekit, to unbreak the current situation in gnome-session with policykit-1? (i think i've asked you about this before). Do you know if anyone has offered to do the work in either consolekit or gnome-session yet?
[09:40] <chrisccoulson> seb128 - there seems like an opportunity for some optimisations there :)
[09:41] <seb128> yes
[09:41] <seb128> those stats are cheap though
[09:41] <seb128> like 1ms or less
[09:41] <seb128> but if we could spare some hundred calls...
[09:41] <chrisccoulson> 1ms each, or for all of them?
[09:42] <seb128> look at the lines I copied
[09:42] <seb128> it's like 0.3ms each
[09:42] <chrisccoulson> ah yes
[09:43] <seb128> I will start by looking at backgrounds and what you pointed about standard dirs
[09:56] <vuntz> chrisccoulson: mccann is supposed to do the work in consolekit, and I'm supposed to do the work in gnome-session
[09:56] <vuntz> chrisccoulson: but if you want to help, that would certainly be welcome!
[09:57] <vuntz> chrisccoulson: https://bugs.freedesktop.org/show_bug.cgi?id=24493
[09:57] <chrisccoulson> vuntz - yeah, i was thinking of helping:)
[10:00] <pitti> seb128: http://piware.de/workitems/desktop/lucid/report.html
[10:00] <pitti> seems more realistic now
[10:00]  * pitti fixes the y steps
[10:00] <seb128> pitti, you rock
[10:01] <pitti> I updpated the howto, I'll mail an announcement
[10:01] <pitti> since the semantics now slightly changed
[10:01] <pitti> asac: ^ this should address your concern from a week ago, too
[10:01] <seb128> pitti, thanks!
[10:32] <baptistemm> seb128, for system call performance you might be interested by systemtap
[10:32] <baptistemm> ie benching open, read, ...
[10:33] <seb128> baptistemm, did you ever use it?
[10:34] <baptistemm> just a little bit, it requires to have debuild package for kernel, it might difficult a first sight but it is rather powerful
[10:34] <baptistemm> this is d-trace for linux
[10:40] <seb128> ok
[10:41] <seb128> waouh, alex rocks as usual ;-)
[10:41] <seb128> http://git.gnome.org/cgit/nautilus/commit/?id=55f1438bf898c819504dae540a7540ec30508f1e
[10:41] <seb128> that fixes the .gtk-bookmarks being opened and rewrite 5 times on start
[10:41] <seb128> it's read only once now
[10:49] <MacSlow> How can I avoid being asked for my password everytime I push or pull something to lp?
[10:50] <seb128> use a ssh agent, gnome-keyring for example?
[11:02] <MacSlow> seb128, reading up on http://live.gnome.org/GnomeKeyring makes me not want to touch this at all atm
[11:04] <seb128> MacSlow, why not?
[11:05] <MacSlow> seb128, uncharted lands... for me at least and I don't want to mess up and lock myself out
[11:05] <seb128> ?
[11:05] <seb128> gnome-keyring is running on your box in any case
[11:05] <MacSlow> seb128, besides... I would really like to know when (what) I did to have this in place
[11:05] <seb128> I'm surprised the agent doesn't kick in when you use ssh, it should
[11:06] <seb128> it works out of the box usually
[11:06] <MacSlow> seb128, on my laptop I don't ahve those issues
[11:06] <seb128> env | grep SSH?
[11:06] <Keybuk> seb128: just so you know, there may still be a "gdm doesn't start" bug
[11:06] <Keybuk> I'll fix that today if there is :p
[11:06] <MacSlow> SSH_AGENT_PID=3800
[11:06] <MacSlow> SSH_AUTH_SOCK=/tmp/ssh-nQMTFj3753/agent.3753
[11:06] <seb128> Keybuk, ok
[11:07] <seb128> Keybuk, good to see that today's upgrade bring some speedup to boot ;-)
[11:07] <Keybuk> does it? :p
[11:07] <Keybuk> I would have thought it'd be slightly slower
[11:08] <seb128> today's upgrade reduced boot from about 1 second apparently
[11:08] <Keybuk> oh right
[11:08] <Keybuk> maybe all that mucking around with gdm and plymouth did actually work out
[11:08] <seb128> well guess-time seems to think the linux time went down 2 seconds
[11:10]  * Keybuk was mucking around with kernels as well
[11:10] <Keybuk> certainly one apw uploads the next kernel, it'll go down a second or so <g>
[11:10] <seb128> xorg time when 0.5 seconds down too
[11:10] <Keybuk> ah that's good to know
[11:10] <seb128> when -> went
[11:10] <Keybuk> I thought xorg might get faster
[11:10] <Keybuk> (no vt mucking around now)
[11:10] <pitti> seb128: did that already include dropping of usplash?
[11:10] <Keybuk> there's actually a bug in the xorg packages
[11:10] <Keybuk> tjaalton: you might want to look into it
[11:11] <Keybuk> the xkbcomp caching patches aren't working
[11:11] <seb128> pitti, could be, let me look
[11:11] <Keybuk> (nothing ends up in /var/lib/xkb :p)
[11:11] <seb128> Keybuk, and after 1 day of looking at nautilus I managed to get one improvement :-p
[11:11] <pitti> seb128: ooh?
[11:12] <seb128> it opens .gtk-bookmark 1 time now
[11:12] <seb128> before it was opening it 11 times
[11:12] <seb128> and renaming it 5 times
[11:12] <tjaalton> Keybuk: yes, I knew it's disabled. bryce fixed the pacth to apply, but it still doesn't build
[11:12] <seb128> thanks to alex for the actual fix in git, I've just been spotting the issue
[11:13] <Keybuk> tjaalton: oh, right, would be nice to get that working ;)
[11:13] <Keybuk> that's another .25-.5s :)
[11:15] <seb128> pitti, right, no usplash
[11:15] <seb128> no plymonth either apparently
[11:16] <pitti> plymouth> no MIR yet, still in universe
[11:21] <Keybuk> pitti: there so is an MIR
[11:21] <Keybuk> bug #495184
[11:22] <pitti> Keybuk: ah, wasn't there yet on my review yesterday
[11:22] <Keybuk> pfft. *yesterday* :p
[11:27] <seb128> MacSlow, it seems that you have an another agent than gnome-keyring
[11:28] <mac_v> pitti: hi... i found this in the sudo changelog... "Rename pwstars to pwfeedback"  , is that for the helper too?
[11:28] <seb128> MacSlow, ps ax | grep 3800
[11:28] <pitti> mac_v: grepping for "pwfeed" doesn't give anything in our sudo version
[11:28] <pitti> perhaps it's in a later version, or only cvs head
[11:28] <MacSlow> seb128, got a hint from pedro_ ... all I was missing was to call ssh-add
[11:29] <mac_v> pitti: aw :( , nvm then :)
[11:29] <MacSlow> seb128, still no clue why this was needed on my desktop but not on my laptop
[11:29] <seb128> MacSlow, you shouldn't need that
[11:29] <seb128> MacSlow, well you have an agent taking over gnome-keyring...
[11:31] <mac_v> pitti: maybe our version is very old. i found the changelog entry in git , it seems to be done somewhere in feb
[11:31] <mac_v> anyway , thanks for looking into it :)
[12:50] <huats> hi everyone
[12:56] <chrisccoulson> hi huats
[12:57] <huats> hey chrisccoulson
[12:57] <chrisccoulson> huats - how are you?
[12:57] <huats> chrisccoulson, I am fine
[12:57] <huats> I am about to see the end of my long lasting work marathon :)
[12:58] <huats> you ?
[13:01] <chrisccoulson> huats - yeah, i'm not too bad. i'm just preparing to finish work for the week :)
[13:08] <huats> chrisccoulson, :)
[13:09] <huats> chrisccoulson, I have been quite away lately, is the baby arrived ?
[13:09] <chrisccoulson> huats - yes, she arrived during the week of UDS :)
[13:09] <huats> :)
[13:09] <huats> is everything ok ?
[13:10] <chrisccoulson> yeah, she's doing ok. although, she's going through a bit of a growth spurt the last couple of days and is feeding a lot more than she is sleeping ;)
[13:11] <huats> :)
[13:16] <chrisccoulson> pitti - how is it determined whether to show the "Safely Remove Device" option in Nautilus for a particular device?
[13:16] <chrisccoulson> i noticed last night that it is shown for my internal card reader
[13:17] <Keybuk> I want a second option
[13:17] <Keybuk> "Dangerously Remove Device"
[13:17] <chrisccoulson> and clicking it unfortunately leaves the card reader powered down until I reboot (or open the case and reconnect it to the internal USB port)
[13:18] <chrisccoulson> Keybuk - that would be a fourth option (in addition to Unmount, Eject and Safely Remove Device)
[13:18] <chrisccoulson> l(
[13:18] <chrisccoulson> ;)
[13:18] <chrisccoulson> i see all 3 options for my card reader
[13:18] <Keybuk> chrisccoulson: I was more channelling mpt; if something can be done Safely then there should be a Dangerously
[13:18] <Keybuk> if Safely is the only option, why say Safely? :p
[13:18] <chrisccoulson> that is a fair point
[13:19] <Keybuk> the Mini 10v has an odd problem like that
[13:19] <Keybuk> if you power down a USB device, you lose the port
[13:19] <pitti> chrisccoulson: the problem with internally-wired USB card readers was the very reason why this option is exposed in the UI in the first place, and isn't the default when you click the eject symbol
[13:20] <pitti> chrisccoulson: the problem is that it's hard to determine whether an USB controller is system-internal or external
[13:20] <Keybuk> you have to power the netbook off and on again properly to get the port back
[13:20] <Keybuk> pitti: it's not hard
[13:20] <pitti> some devices want to be unpowered to stop whining about "dangerous to remove me"
[13:20] <Keybuk> you just quirk them
[13:20] <Keybuk> "this device on this board => don't power off"
[13:21] <pitti> Keybuk: we looked at the udev and dmidecode data, and nothing on the dell thing where it was reported tells you that it's on-board :(
[13:21] <Keybuk> pitti: right, but the combination of the dmi of the board and the device tells you
[13:21] <pitti> right, you'd need per-vendor/product lists
[13:21] <Keybuk> yes
[13:21] <Keybuk> that'd be part of the hardware certification process
[13:21] <pitti> which is a bit crazy to maintain
[13:21] <Keybuk> it's basically what we have to do for sound cards anyway
[13:21] <Keybuk> "this codec, from this vendor, on this device id, on this sound card device/vendor, on this board => these quirks"
[13:22] <Keybuk> there's a generic approach to this going into the kernel
[13:22] <Keybuk> devicetree
[13:22] <pitti> I think kay figured a way how to extract it from some device descriptors, so that when the OEM does its job properly it'd just work
[13:22] <Keybuk> Kay tends to think per-device
[13:22] <Keybuk> this is for system quirks
[13:22] <Keybuk> idea being that you end up with a big database of quirks that everyone shares
[13:22] <Keybuk> quirks are cross-device, that's kinda the point
[13:23] <chrisccoulson> in my case, i just purchased a card reader and shoe-horned it in to my already cramped case. i don't know how a quirks database would handle that
[13:23] <Keybuk> chrisccoulson: if it were a property of the physical card reader, the device you bought would be quirked
[13:26] <chrisccoulson> so, it seems the problem is more complicated than i first thought :)
[13:26] <chrisccoulson> anyway, home time for me now
[13:26] <Keybuk> yeah
[13:26] <Keybuk> the problem is because another device, with an identical chip, probably works fine
[13:26] <Keybuk> and all we see is the chip from a driver POV
[13:27] <chrisccoulson> yeah, the same chip is probably used in a different external card reader somewhere
[13:27] <chrisccoulson> so, i don't know how cases like that would be handled
[13:27] <Keybuk> that's where devicetree is supposed to help
[13:28] <Keybuk> it lets you combine matches across multiple devices
[13:28] <Keybuk> "this chip, with three ports numbered X, Y and Z, with this other chip on the same PCI device => this actual device"
[13:28] <Keybuk> then you add properties to the actual devices which udev can pick up
[13:28] <chrisccoulson> that sounds promising anyway:)
[13:29] <chrisccoulson> right, bbl
[14:01] <Ng> which package should I file a wishlist bug on if I want to propose using a device-specific icon for a particular USB device?
[14:01] <Ng> (my iphone looks like a camera in computer:// ;)
[14:05] <virtuald> i guess it's nautilus
[14:10] <pitti> Ng: known bug, I think
[14:10]  * pitti looks
[14:11] <chriscc0> bah, ISP fail.
[14:12] <seb128> Ng, no need to open a bug
[14:12] <seb128> Ng, we don't build the gvfs afc code yet
[14:12] <seb128> because required libs are waiting on mir in lucid
[14:12] <seb128> iphones are very specific devices
[14:12] <mclasen> Ng: is it a gphoto mount ?
[14:12] <pepsifx357> Has anyone else been having problems with the mouse in 9.10?
[14:14] <pitti> asac: do you happen to know why nm-applet constantly updates gconf with the "timestamp" value of wifis?
[14:14] <pitti> what's that used for?
[14:15] <Keybuk> we should have those yummy Fedora nautilus patches
[14:15] <Keybuk> that actually let you access all the data on your iphone
[14:15] <mclasen> Keybuk: they are all upstream, I hope
[14:15] <pitti> it does that every minute or so, which prevents hard drives from ever going to powersave mode
[14:16] <asac> pitti: not sure. what timestamp are you referring to?
[14:16] <asac> pitti: NM keeps track of "last connected time"
[14:17] <asac> so it can decide which net to prefer in case there are more than one known in sight
[14:17] <pitti> ah, that
[14:17] <asac> is that an issue?
[14:17] <pitti> nevermind, it's not actually rewritten each minute
[14:17] <asac> how often do you see those updates?
[14:17] <pitti> I just mis-looked
[14:17] <asac> kk
[14:18] <Ng> mclasen: yes, it's not wrong to give it a camera icon, I'm just being picky because I'd like it to be a icon representing an iphone ;)
[14:18] <Ng> pitti: seb128: ok, thanks :)
[15:12] <Keybuk> mclasen: you've not worked with Fedora much, have you? :p
[15:12] <Keybuk> they're infamous for carrying patches in Fedora for software they're upstream for!
[15:35] <dobey> heh
[15:38] <dobey> Ng: hrmm, it really should be specifying "phone-apple-iphone(-{3g, 3gs})" which should fall back to "phone"
[15:39] <seb128> dobey, the issue is that iphones are cameras and phones too
[15:39] <seb128> ie several devices to list for gvfs
[15:39] <dobey> seb128: device icons should be shown as what the device *is*. they are phones that just happen to have cameras or that can play mp3s
[15:39] <rickspencer3> seb128, I found your bug in lazr that was keeping bughugger from working bug #495326
[15:40] <seb128> rickspencer3, I got the subscription email, thank you
[15:40] <seb128> I didn't try the change yet though
[15:40] <seb128> will do that a bit later
[15:40] <rickspencer3> seb128, why not wait until the bug is fixed?
[15:40] <dobey> a phone is a phone, even if it can microwave a sausage.
[15:40] <rickspencer3> should be an update next week
[15:40] <seb128> ok
[15:40] <Ng> I want a phone that can microwave sausages
[15:41] <seb128> I wanted to try bughugger
[15:41] <rickspencer3> did you guys see this:
[15:41] <rickspencer3> http://www.dell.com/content/topics/segtopic.aspx/ubuntu?c=us&cs=19&l=en&s=dhs&~ck=anavml
[15:41] <seb128> but that's probably not for today now
[15:41] <rickspencer3> seb128, it's a one line change if you just want to implement it yourself
[15:41] <dobey> Ng: with a slight adjustment of power, i'm sure the iphone can do it
[15:41] <pitti> Ng: you want http://www.youtube.com/watch?v=udlxr8t1nZM thhen
[15:41] <pitti> Ng: (sorry, German sound)
[15:41] <Ng> hehe
[15:41] <seb128> rickspencer3, nice!
[15:42] <dobey> Ng: or http://www.youtube.com/watch?v=sgt2dJU2TNk
[15:43] <seb128> ok, I've to be away for a bit
[15:43] <seb128> bbl
[15:43] <rickspencer3> note that Dell website is a bit odd ... you can get better Ubuntu options if you go to the small business section of the site
[15:51] <mclasen> Keybuk: at least we are upstream...
[15:51] <czajkowski> rickspencer3: you had to get quickly into the shotofjaq tweet ;)
[15:52] <rickspencer3> czajkowski, you know me well
[15:53] <czajkowski> rickspencer3: to be fair you don't tweet it that often
[15:53] <rickspencer3> but when I do, I tweet about Quickly
[15:55] <czajkowski> you tweet quality!
[15:57] <pitti> rickspencer3, kenvandine: since I need to leave in 35 mins, any chance that either of you could lurk in the release meeting today? I'll cover the desktop part, but just in case there are followup questions/things later on?
[15:58] <Keybuk> mclasen: only because if you're not upstream, you nih it
[15:58] <rickspencer3> pitti, ack
[15:58] <kenvandine> sure
[15:58] <Keybuk> mclasen: (I'm mostly only teasing really :p)
[15:58]  * rickspencer3 joins
[15:58] <Keybuk> but ABRT!
[15:58]  * rickspencer3 join #ubuntu-meeting
[15:59] <rickspencer3> seb128, pitti, kenvandine, anybody:
[15:59] <rickspencer3> I want to get a python library packaged and in a ppa today
[15:59] <kenvandine> rickspencer3, ok
[15:59] <rickspencer3> is there a definitive guide that will walk me through this that one of you can recommend to me?
[16:00] <kenvandine> python-mkdebian
[16:00] <kenvandine> :)
[16:00] <rickspencer3> aah the quitessential linux smart ass answer
[16:00] <rickspencer3> ;)
[16:00] <kenvandine> hehe
[16:00] <kenvandine> or use my quickly branch that does it :)
[16:01] <rickspencer3> kenvandine, that didn't work either
[16:01] <mclasen> Keybuk: I know, I know...
[16:01] <kenvandine> rickspencer3, oh?
[16:01] <kenvandine> what happened?
[16:01] <didrocks> hey rickspencer3 :)
[16:01] <rickspencer3> kenvandine, I'd be happy to trouble shoot it with you, but I was hoping not to bother you guys with this today, and just learn how to fish
[16:02] <kenvandine> you need a pretty simple setup.py and run python-mkdebian
[16:03] <kenvandine> that will get you like 90%
[16:03] <kenvandine> not sure of a definitive guide :)
[16:03] <pitti> there's always the python policy
[16:03] <pitti> but I'd just take a look at an existing small python library package
[16:03] <didrocks> pitti, seb128: I've almost finished the session thing (both une and gdm default session choice). Do I update the cra... hem, the impacted packages to the desktop team ppa this week-end? :)
[16:04] <pitti> didrocks: nice! sure, or just upload..
[16:04] <didrocks> pitti: ok, I'll first check I can upload all packages depending on the change (should be ok)
[16:05] <rickspencer3> d'oh! no devscripts installed on this machine
[16:05]  * rickspencer3 face palm
[16:06] <didrocks> hum... this reminds me that I didn't add a WI for devscripts dependency on Quickly (investigate and remove the postfix install)
[16:07] <didrocks> oh no, there is one :)
[16:26] <pitti> I'm off for the weekend, cu on Monday!
[16:28] <didrocks> pitti: have a good week-end!
[16:31] <chrisccoulson> hello everyone
[16:45] <rickspencer3> hi chrisccoulson
[16:45] <chrisccoulson> hi rickspencer3 - how are you?
[16:46] <rickspencer3> doing well
[16:46] <rickspencer3> been working a lot o bughugger, and by extension my new pet project
[16:46] <rickspencer3> how is the baby?
[16:46] <chrisccoulson> yeah, she's doing ok. she's actually asleep at the moment :)
[16:46] <rickspencer3> :)
[19:54] <djsiegel2> hey Amaranth
[21:42] <Amaranth> djsiegel: pong
[22:00] <djsiegel> yo Amaranth
[22:00] <Amaranth> hey
[22:00] <djsiegel> will this work for you: https://bugs.edge.launchpad.net/hundredpapercuts/+bug/495641 /
[22:01] <djsiegel> is that enough info to write the patch? it links to a wiki page
[22:02] <djsiegel> and tell me what you think of:
[22:02] <djsiegel> https://bugs.edge.launchpad.net/hundredpapercuts/+bug/495641
[22:02] <djsiegel> brb
[22:02] <Amaranth> djsiegel: Looks good
[22:02] <Amaranth> djsiegel: I can probably make clicking on the desktop exit scale too
[22:13] <djsiegel> Amaranth: seriously?
[22:13] <djsiegel> that would be awesome
[22:13] <Amaranth> sure, we already have the hook for making it show desktop and the code to exit scale
[22:13] <djsiegel> I really dont want clicking on the desktop to Show Desktop
[22:13] <djsiegel> sweet
[22:14] <Amaranth> I just need to hook the two together
[22:15] <djsiegel> I think it should rather be if click on window x, exit scale and focus x; else exit scale
[22:15] <djsiegel> i.e. a click in Scale mode either picks a window or exits
[22:15] <djsiegel> if we just do click on desktop to exit scale, scale won't exit if the user clicks on the panel, for example, Amaranth
[22:16] <Amaranth> Alright, I should be able to do that as well
[22:16] <Amaranth> Did you mention that use case in the bug report?
[22:16] <djsiegel> Totally rad, you rock.
[22:16] <Amaranth> Otherwise I'll probably forget and just make it for the desktop
[22:17] <djsiegel> ok, I will add that
[22:17] <djsiegel> should I add to the LP bug or the upstream one?
[22:17] <Amaranth> I wish launchpad had some way of identifying priority other than the Critical, High, Medium, Low, and Wishlist
[22:17] <Amaranth> LP bug
[22:17] <djsiegel> ok
[22:17] <Amaranth> I guess I can target the bugs to a release for priority
[22:18] <djsiegel> ok, I changed the description to suggest "Click to Exit Scale" instead of "Click Desktop to Exit Scale"
[22:20] <jcastro> djsiegel: do you have the settings you are working on someplace? I'd like to follow along
[22:21] <jcastro> djsiegel: something I can click and mess with?
[22:22] <djsiegel> jcastro: yeah
[22:23] <djsiegel> jcastro: $ bzr branch lp:compiz-settings-lucid; cd compiz-settings-lucid; python compiz-settings.py
[22:23] <djsiegel> jcastro: these are pretty close to what we'll use
[22:23] <jcastro> thanks!
[22:23] <djsiegel> a few things don't load right when you do that, like minimize animations and a color in the viewport switcher
[22:32] <djsiegel> hey Amaranth, one more quick thing
[22:33] <djsiegel> in the specs, I am writing color values as "outline_color = #FFFFFF32"
[22:33] <djsiegel> where the first 6 hex digits are RGB, and the last 2 are alpha
[22:33] <djsiegel> I am not sure how you need to encode RGBA in the patch though
[22:33] <Amaranth> white with 32% transparency or white with 32 out of 255 transparency?
[22:33] <Amaranth> You should probably encode the alpha in hex too
[22:33] <djsiegel> 32 of 255
[22:33] <Amaranth> oh, you are :)
[22:34] <djsiegel> ah, wait
[22:34] <Amaranth> wait, now I'm confused
[22:34] <Amaranth> 32 in hex out of FF, right?
[22:34] <djsiegel> #32 is 50/255 deciaml
[22:34] <djsiegel> dec.
[22:34] <djsiegel> yes
[22:34] <Amaranth> ok, assuming I don't try to overthink it when making the change that shouldn't be a problem
[23:08] <cj> which one of you lives in Bryant again?  would you mind joining us at #ubuntu-wa-us for a moment?
[23:10] <rickspencer3> I just received two of the three Dell Mini's that I ordered
[23:10]  * rickspencer3 resists pull to get distracted from work and set them up
[23:11] <Amaranth> arg, chrome switched from a User Scripts folder to doing some weird thing with extensions being user scripts so I can't just copy the launchpad ones in anymore
[23:12] <chrisccoulson> rickspencer3 - 3 dell mini's? what are you going to do with them all? ;)
[23:12] <rickspencer3> one for me, and one for each of my kids
[23:12] <cj> rickspencer3: I bet it's you ;)
[23:12] <rickspencer3> hehe
[23:12] <rickspencer3> nope, kind of a christmas gift for my wife in a way, keep the kids off of her computer :)
[23:13] <rickspencer3> in any case, I ordered them with Ubuntu 8.04 installed, but I'll put Lucid on my and Karmic on the other two
[23:13] <cj> rickspencer3: we're planning a release event at UW for Lucid over on #ubuntu-wa-us ;)
[23:13] <rickspencer3> seriously?
[23:13] <rickspencer3> can I come?
[23:13] <cj> rickspencer3: yeah.  we want to get a running start
[23:13] <cj> rickspencer3: of course ;)
[23:13] <rickspencer3> I didn't even know there was a #ubuntu-wa-us
[23:14] <cj> it's been quiet.  Paul's the only one who's been there since its inception like 2 years ago
[23:14] <rickspencer3> heh
[23:14] <cj> rickspencer3: if you don't know Paul, you should get to know him.  I met him at LFNW when he was like 15 or something.
[23:14] <rickspencer3> I've been to a couple of gslug meetings, but not for over a  year
[23:14] <cj> yeah, me too.
[23:14] <rickspencer3> who's Paul?
[23:14] <rickspencer3> we could get together with eeejay and do some hacking
[23:15] <cj> rickspencer3: peanutb
[23:15] <cj> rickspencer3: is he back in town?
[23:15] <cj> (eeejay)
[23:16] <rickspencer3> eeejay? so far as I know, but I didn't know he left town
[23:16] <cj> eeejay_away: where you at these days?
[23:16]  * rickspencer3 hopes he didn't move away
[23:16] <cj> I think last time I asked if he wanted to have lunch he was in a different state
[23:17] <rickspencer3> cj, I just got from having lunch in the udistrict
[23:17] <rickspencer3> is that where you are?
[23:17] <cj> rickspencer3: do you think we could hit Canonical up for some bumper stickers or other swag at a table in front of the HUB?
[23:17] <rickspencer3> fo' sho'
[23:17] <cj> rickspencer3: usually, but my office flooded due to a burst pipe, so I'm working from home
[23:17] <rickspencer3> :)
[23:18] <rickspencer3> bummer
[23:18] <cj> yeah.  being at the office would keep me from concentrating on finishing the final anyway ;)
[23:18] <rickspencer3> hehe
[23:18]  * rickspencer3 gets ready to do a (hopefully not too hairy) merge
[23:19]  * rickspencer3 hates merging
[23:19] <cj> merging's not so bad.  manual conflict resolution is the painful part ;)
[23:20] <rickspencer3> right
[23:20] <rickspencer3> I think trunk diverged a bit from my branch
[23:20] <cj> heh, pull on every commit!
[23:23] <Amaranth> yay, I (mostly) got my user scripts back
[23:25] <Amaranth> bleh, I forgot to give the extension permissions
[23:35] <rickspencer3> only 1 merge conflict, and it was easy