[00:45] <TheMuso> chrisccoulson: When doing a merge, please pass the version number of the last Ubuntu package version to dpkg-buildpackage with the -v flag, so we get the Debian changelog entries in the changes file when you upload.
[00:47] <chrisccoulson> TheMuso - no problem
[00:54] <fagan> hmmm are we going to revisit the decision to get rid of EOG now that the F-Spot developers fixed the viewer?
[00:56] <fagan> wheres rickspencer3 when I need him :)
[00:57]  * fagan will find him tomorrow 
[01:00] <TheMuso> fagan: He is off till Monday.
[01:01] <fagan> oh thanksgiving I forgot
[01:01] <fagan> thanks TheMuso :)
[01:01] <fagan> It can wait
[01:44] <lifeless> TheMuso: please fila  bug on bzr-builddeb to do that automatically.
[02:47] <TheMuso> c
[06:39] <pwnguin> anyone know how to turn firefox debugging output on?
[06:41] <pwnguin> strike that, incontravertial proof found
[07:33] <pitti> Good morning
[07:41] <ajmitch> morning pitti
[08:34] <seb128> good morning there
[08:34] <pitti> hey seb128
[08:35] <seb128> hello mr pitti
[08:35] <seb128> how are you?
[08:35] <pitti> I'm great, thanks! I'm in  the middle of implementing jockey-hotplug-support :)
[08:35] <seb128> ;-)
[08:35] <pitti> so depending on when mvo gets around to approving it, I might have it working even before approval :-P
[08:36] <pitti> how are you?
[08:36]  * pitti hugs mvo
[08:36] <seb128> oh, apparently robert_ancell made good use of upload rights this night!
[08:36] <seb128> I'm good thanks
[08:36] <pitti> yeah
[08:37] <mvo> pitti: is it ready for review yet? I can do it now, its a nice change from wirting specs ;)
[08:37] <pitti> mvo: pending approval since yesterday
[08:37] <pitti> mvo: should take you two minutes or less, I figure
[08:41] <mvo> pitti: thanks, done
[08:41] <pitti> \o/ danke
[08:46] <didrocks> good morning there
[08:47] <mvo> :)
[08:48] <pitti> hey didrocks
[08:48] <didrocks> Guten Morgen pitti
[08:48]  * pitti mumbles about the "dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct" he gets in lucid now
[08:48] <pitti> does anyone else get that in lucid, too, when calling jockey-gtk ?
[08:53] <seb128> hey didrocks
[08:53] <seb128> pitti, yes
[08:53] <pitti> thanks
[08:53] <seb128> pitti, yes, get the same error there, "dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct"
[08:57] <didrocks> lut seb128
[09:01] <didrocks> So, regarding gconf tweaking, I see that in the variable are either ENV_MANDATORY_PATH or ENV_DEFAULTS_PATH (I guess, we should use MANDATORY for UNE as we don't want the panels to be changed)
[09:02] <didrocks> The issue is that /etc/gconf/2/path "include" them (waiting for a tree path like in ~/.gconf). So xml files generated by udpate-gconf-defaults aren't read.
[09:02] <didrocks> We can either tweak update-gconf-defaults to add an option to export to a directory tree structure or add a new "xml:readonly:ENV_GCONF_MANDATORY_SESSION" in /etc/gconf/2/path. What's the best option to your opinion?
[09:02] <seb128> ?
[09:04] <didrocks> oh, I can maybe try something else, one sec
[09:04] <seb128> gconf should be smart and understand both formats
[09:04] <seb128> bbib, restart after upgrades
[09:20] <seb128> re
[09:28] <seb128> pitti, btw did you read my messages about bootchart yesterday evening?
[09:29] <pitti> seb128: about pybootchartgui? we discussed that quickly, yes
[09:29] <seb128> pitti, no, about me storing regular charts from now on the same url
[09:29] <pitti> ah, no, I missed that
[09:29] <seb128> http://people.canonical.com/~seb128/bootchart
[09:30] <seb128> I will keep uploading bootcharts from my mini10v
[09:30] <seb128> at least weekly ones
[09:30] <seb128> but maybe extra charts for noticable changes, etc
[09:30] <seb128> lucid yesterday was 26s to boot, almost 15 seconds for desktop
[09:30] <seb128> I'm doing a new one now with compiz and pulseaudio updates
[09:34] <pitti> lucid is a second longer than karmic? shame
[09:34] <pitti> seb128: oh, can you please install ureadahead?
[09:34] <seb128> no
[09:35] <seb128> I want to stick with lucid
[09:35] <seb128> and not start diverting
[09:35] <seb128> if that's what we should use somebody should land that in lucid
[09:35] <pitti> we'll use that
[09:35] <pitti> it's in karmic-proposed and about to go to -updates
[09:35] <seb128> ok, good, so I will wait for it to be used ;-)
[09:35] <pitti> okay
[09:36] <seb128> I've cleaned the karmic install there anyway
[09:37] <seb128> pitti, I might try the u version later but for now I want to measure the impact of the compiz and pulseaudio changes
[09:37] <seb128> and I don't want to add extra changes to the equation
[09:38] <pitti> right
[09:38] <pitti> also, I guess sreadahead works reasonably well on SSD
[09:40] <seb128> my laptop stoped creating bootchart images on lucid for some reason
[09:40] <seb128> there are only .tgz since I upgraded
[09:41] <seb128> oh, I'm using the java version there
[09:41]  * seb128 switches to the python one
[10:08] <pitti> mvo: would you mind having a quick look at http://bazaar.launchpad.net/~ubuntu-core-dev/update-notifier/ubuntu/revision/541 to see whether I forgot something in the structure?
[10:09]  * mvo looks
[10:09] <pitti> oh
[10:09] <pitti> [HOOKS]
[10:09] <pitti> pre-build = ./autogen.sh
[10:09] <pitti> mvo: ^ so that's the trick :)
[10:09] <pitti> cool
[10:09] <mvo> pitti: yeah
[10:09] <mvo> pitti: I wrote that on irc yesterday, but maybe it got lost
[10:12] <mvo> pitti: looks good to me
[10:12] <didrocks> seb128: I think I caught the issue. Even if I export ENV_MANDATORY_PATH before executing gnome-session in the shell launched by .desktop file, gconf is probably initialized differently. This environment variable isn't in its /proc/<pid>/environ (all environment variable in the gnome-session wrapper aren't in gconfd environment)
[10:13] <pitti> mvo: thanks
[10:13]  * pitti sends lucidwards
[10:14] <didrocks> pitti: consequently to ^, your GDMSESSION isn't useful in gnome-stracciatella (GDMSESSION seems to be exported by default from <GDMSESSION>.desktop)
[10:14] <seb128> didrocks, it's probably because gconf is dbus activated
[10:15] <pitti> didrocks: I don't understand, I'm afraid
[10:15] <seb128> didrocks, why isn't GDMSESSION useful?
[10:15] <seb128> it works for ie notify-osd
[10:15] <seb128> GDMSESSION is correctly set for gnome-session
[10:15] <didrocks> yes, GDMSESSION is exported by default from <name>.desktop. I'm speaking about the gnome-stracciatella wrapper
[10:16] <didrocks> (the wrapper export GDMSESSION before running gdm-session)
[10:16] <didrocks> but GDMSESSION can already be set by default from the desktop file
[10:17] <seb128> that doesn't make sense
[10:17] <seb128> gdm is the one exporting this variable
[10:17] <seb128> not the .desktop
[10:20] <didrocks> let's say I create a gnome-foo.desktop executing only gnome-session in /usr/share/xsessions/
[10:20] <didrocks> I got an GDMSESSION=gnome-foo, right?
[10:20] <seb128> yes
[10:21] <seb128> gdm sets it
[10:21] <didrocks> what I mean is that I don't understand why in gnome-stracciatella, GDMSESSION is exported before executing gnome-session
[10:21] <didrocks> (/usr/bin/gnome-stracciatella is executed by /usr/share/xsessions/gnome-stracciatella.desktop)
[10:22] <didrocks> and that's the only thing the wrapper does
[10:22] <seb128> oh you mean we could drop a line
[10:22] <seb128> that's possible
[10:22] <didrocks> yeah
[10:22] <seb128> having an extra export doesn't make me not sleep at night though...
[10:22] <didrocks> I tried and it works
[10:23] <seb128> maybe old gdm didn't work the same way
[10:23] <didrocks> ok, but that troubled me because for une, I tried to add an extra value and I only saw one in gconf environment (GDMSESSION) :)
[10:23] <seb128> and we didn't clean that since
[10:23] <seb128> alright
[10:23] <seb128> open a bug I guess ;-)
[10:24] <didrocks> ok, I'll clean that. But that doesn't help me for gconf initialisation :/
[10:25] <seb128> diverting gconf config is not something trivial
[10:25] <seb128> I expected it would be hacky,create troubles...
[10:26] <didrocks> yeah, that's why setting the environment variable would have been the less messy for other desktop sessions
[10:30] <didrocks> I just wonder if anyone has tried once setting one of those two environment variables and get it works :)
[10:31] <seb128> no reason it wouldn't work
[10:31] <seb128> but you need to have gconfd have it set
[10:31] <seb128> and it's not trivial since we dbus active gconf
[10:33] <didrocks> yes, I understand what's the matter is, I'm trying to find a way to achieve this
[10:35] <seb128> use .gconf.path?
[10:36] <didrocks> if I do that, every sessions will inherit UNE-desktop gconf values, not only "une desktop" session
[10:37] <seb128> what do you need to change exactly?
[10:38] <didrocks> the idea was to add UNE default gconf values like one panel, one workspace only to get a une default experience
[10:39] <didrocks> a bad solution would be to set those values (without touching ~/.gconf) in the wrapper one after another :/
[10:45] <seb128> didrocks, you don't want to set those values or the normal session will get them too
[10:47] <didrocks> ok so, that doesn't solve it. The only solution is to get this environment variable into gconfd so that the additional gconf values are only read on UNE desktop session
[10:47] <seb128> right
[10:47] <seb128> or to code patch things
[10:49] <didrocks> seb128: opening /usr/share/gconf/${GDMSESSION}.path for instance during default value loading?
[10:49] <seb128> yes
[10:50] <seb128> is GDMSESSION sets for the gconf env?
[10:50] <didrocks> I think I'll do this
[10:50] <didrocks> yes
[11:06] <seb128> pitti, mvo, Amaranth: not good
[11:06] <seb128> lucid takes 5 seconds longer to boot today
[11:06] <pitti> :(
[11:06] <seb128> seems compiz doesn't register to the session since the update
[11:07] <seb128> so gnome-session goes: wait wait wait wait wait wait timeout
[11:08] <seb128> pitti, mvo: http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091126-28.png
[11:09] <seb128> on a good note compiz.real was starting after 4 seconds
[11:09] <seb128> and compiz starts after 2 seconds now there
[11:09] <seb128> so we won 2 seconds with the wrapper drops for compiz and pulseaudio
[11:10] <pitti> cool
[11:10] <pitti> WTH is the long delay from gtk-window-decorator?
[11:10] <seb128> what I just wrote before
[11:10] <pitti> until panel is started?
[11:11] <pitti> ah
[11:11] <pitti> sorry
[11:11] <seb128> compiz doesn't register
[11:11] <pitti> is it importnat to have the WM running before we can start nautilus/panel/etc.?
[11:11] <seb128> gnome-session does that because it's supposed to be efficient
[11:12] <seb128> avoid having theme flickering etc
[11:12] <seb128> and to have the cost of getting things drawned once with no theme and then moved and themed
[11:12] <seb128> ie, start g-d-s and wm first
[11:12] <seb128> and then applications
[11:36] <seb128> pitti, mvo: there is something else weird there
[11:37] <seb128> the compiz bar activity divided by two or something
[11:37] <pitti> seb128: for https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-suspend-quirks-halsectomy I used the existing Halsectomy page and work items; please let me know if you prefer a real spec wiki page
[11:37] <seb128> pitti, no I'm fine with the whiteboard, thanks
[11:38] <pitti> seb128: oh? I just see a single block
[11:38] <pitti> seb128: the "spec" link points to wiki.u.c./Halsectomy which has the details
[11:38]  * pitti -> lazy, and rather prefers working on the actual code
[11:39] <seb128> pitti, the bar was around 8 seconds yesterday
[11:40] <seb128> it's much shorter today
[11:40] <seb128> the colored part I mean
[11:40] <seb128> pitti, well updating a wikipage or items on a whiteboard is about the same work or I don't understand the question?
[11:41] <cassidy> seb128, hi. Would be cool to fix https://bugs.edge.launchpad.net/ubuntu/+source/telepathy-gabble/+bug/488709 in Karmic. We just add a chat with the admin of this server and removed it from git but that won't help if it's still in Karmic
[11:41] <seb128> in fact wiki tend to be much slower to respond that blueprint edit
[11:41] <seb128> cassidy, looking
[11:42] <seb128> bah it's a shame than firefox does much better a displaying images than eog
[11:43] <pitti> seb128: "understand the question" > what was the question?
[11:43] <seb128> pitti, why would a wiki page be easier?
[11:43] <pitti> seb128: I meant that I didn't leave the blueprint entirely without a wiki link
[11:43] <pitti> seb128: I keep the work items in the whiteboard, of course
[11:43] <seb128> "* pitti -> lazy, and rather prefers working on the actual code"
[11:43] <seb128> was that related to the wiki discussion?
[11:44] <seb128> sorry I'm just being confused
[11:44] <pitti> seb128: sorry, no; I meant, I didn't create a new spec wiki page to repeat the same informatino than on Halsectomy in a different format
[11:44] <seb128> is there some spec of mine you suggest changing?
[11:44] <seb128> I didn't do that either
[11:44] <pitti> seb128: no, just pointing it out because you are the approver of that :)
[11:44] <seb128> oh ok
[11:44] <seb128> now it makes sense
[11:44] <seb128> I though you were using your spec as an example to make a point about the login speed one
[11:45] <seb128> gotcha
[11:45] <seb128> pitti, it's all good, no need of a real wiki page
[11:48] <seb128> cassidy, how is this list of servers built? is there some other which might turn problematic?
[11:50] <cassidy> seb128, it has been built from http://coccinella.im/servers/servers_by_proxy_bytestreams.html
[11:51] <cassidy> seb128, I'm about to fix a bug that should reduce the nb of query (only query proxies when we actually need them)
[11:51] <seb128> cassidy, are those supposed to be public proxy servers?
[11:51] <cassidy> yeah
[11:51] <seb128> so why is using that one an issue?
[11:51] <seb128> if the guy doesn't want users he shouldn't made a public proxy
[11:52] <cassidy> the admin of this server claims he hasn't be asked to be on that list
[11:52] <cassidy> and he has a fair point saying that having a proxy open doesn't mean to you want all the Ubuntu and Fedora users to use it :)
[11:52] <seb128> well, he runs a public proxy, anybody is free to use it...
[11:53] <cassidy> I agree, but also understand his point, that's a big difference now that lot of people are using Empathy
[11:54] <seb128> I'm still unsure about that
[11:54] <seb128> we don't want to play upload every day because servers changes or admin want users or not
[11:54] <seb128> would it possible to build that list dynamically somewhat and not have it in the source?
[11:55] <seb128> is the issue that the server is used there?
[11:55] <cassidy> seb128, we are investigating a better solution
[11:55] <seb128> or is it that the bug you are fixing DoS servers?
[11:56] <cassidy> like have proxy.collabora.co.uk and do DNS balacing or something
[11:56] <seb128> in which case I would rather recommend fixing the DoS issue
[11:57] <seb128> ie will the server use still be an issue once the overuse is fixed too?
[11:57] <cassidy> I suspect it will. As more and more people are going to use file transfer and tubes
[11:58] <seb128> ok
[11:58] <seb128> I will fix that one and wait for you guys to fix the collabora proxy thing later ;-)
[11:58] <cassidy> we are thinking atm about implemeting a better solution
[11:58] <cassidy> thanks!
[11:58] <seb128> np, thank you for pointing the bug
[11:59] <seb128> I'm not subscribed to gabble
[11:59] <cassidy> It's a bit my fault, I didn't realise that the gain of popularity of Empathy would cause such issue
[12:08] <cassidy> seb128, we are about to remove all the proxies and set our own (not deployed yet)
[12:09] <cassidy> plan is to ask to server admin if they mind to be added
[12:09] <cassidy> and we'll add them using DNS round robin
[12:09] <cassidy> so maybe you should wait for this patch before doing the upload
[12:10] <seb128> cassidy, how long do you think it will take?
[12:10] <seb128> I've the sru ready for upload
[12:10] <seb128> but I don't really care either way
[12:10] <seb128> I like your solution better though ;-)
[12:11] <seb128> but if it takes some weeks and the guy get really angry meanwhile...
[12:11] <cassidy> hopefully server will be up today but it will probably take a will before we got the reply from admins
[12:12] <seb128> ok
[12:12] <seb128> I will you decide since you talked to the admin
[12:13] <Keybuk> hah
[12:13] <Keybuk> someone freed up some space on antimony
[12:13]  * Keybuk just heard the ubuntu jingle from upstairs
[12:14] <seb128> Keybuk, hey
[12:14] <seb128> Keybuk, do you have a box where boot was blocking on antimony disk space?
[12:14] <Keybuk> new cdimage
[12:14] <Keybuk> must have just rsync'd and one of the minis just installed it and booted
[12:15] <seb128> ah ok
[12:15] <seb128> speaking about mini
[12:15] <seb128> we won 2 seconds today with compiz and pulseaudio wrappers drop
[12:15] <seb128> and have an extra 8 seconds due to compiz registration which broke on the way
[12:15] <seb128> you might want to chase mvo about the new compiz issue ;-)
[12:16] <Keybuk> hehe
[12:17] <Keybuk> you win some, you fail some
[12:17] <seb128> I'm wondering why seahorse-daemon is in this chart
[12:17] <seb128> I though we stopped installing it by default
[12:17] <seb128> hum no
[12:18] <seb128> I confuse it with the agent
[13:08] <pitti> seb128: FYI, I removed the xorg/hal work item from desktop-lucid-startup-speed and linked the separate spec as a dependency
[13:16] <Keybuk> pitti: Michael Frey on the OEM team has built some Xorg packages with the current set of udev replacement patches applied
[13:16] <Keybuk> hopefully they'll generally do the right thing
[13:16] <pitti> oh, great
[13:16] <pitti> Keybuk: I wrote a spec about it yesterday
[13:16] <pitti> bryce said that jcristau's patches don't apply well to our current one and wanted to wait for 1.7
[13:16] <Keybuk> when is that coming out?
[13:17] <pitti> I have some udev rules which port the keyboard/synaptics fdis
[13:18] <pitti> Keybuk: unsure, I just know "couple of weeks"
[13:19] <Keybuk> the patches applied fine here btw
[13:19] <Keybuk> it's mostly just adding a new backend after all
[13:20] <pitti> Keybuk: you took them from http://cgit.freedesktop.org/~jcristau/xserver/ ?
[13:20] <pitti> I'm happy to build one and then beat my udev rules into shape
[13:20] <Keybuk> I took them from the mailing list
[13:20] <Keybuk> looks like the same set though
[13:22] <pitti> you don't happen to have built .debs, do you?
[13:22] <Keybuk> Michael probably does
[13:23] <pitti> ok, great
[13:23] <Keybuk> (ChickenCutlass on #oem)
[13:25] <seb128> pitti, ok good
[13:26] <Keybuk> not that I mean to rush
[13:26] <Keybuk> but we don't have many alphas to test things ;)
[13:31] <pitti> Keybuk: ah, it's in the status area of https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-halsectomy
[13:31]  * pitti looks at PPA
[13:31] <Keybuk> and ripping HAL back out of X is the kind of thing we really want to test ;)
[13:32] <pitti> absolutely
[13:33] <Keybuk> and is one of the really important cards in the boot speed house ;)
[13:35] <pitti> I think I'll wait for Michael to wake up and test his packages
[13:35] <pitti> no need to spend time on fixing the patches if he already did
[13:35] <Keybuk> yeah, this week is "everyone's on holiday" anyway :)
[13:35] <pitti> oh heck, right
[13:36] <pitti> nothing in https://edge.launchpad.net/~mfrey/+archive/ppa anyway
[13:50] <pitti> Keybuk: ah, they apply just fine to xorg-edgers; trying that
[14:05] <pitti> bryce: do you know why xorg-edgers has server 1.7.99 while we are actually heading for 1.7?
[14:05] <pitti> i. e. are we deliberately using the previous version, or is it just a weird numbering scheme?
[14:13] <Keybuk> that compiz bug screwed up my bootcharts ;-)
[14:13] <Keybuk> it goes idle while compiz is running, so they get cropped
[14:16] <seb128> and mvo doesn't seem to be around today
[14:16] <seb128> maybe Amaranth will show up soon ;-)
[14:16] <Keybuk> I fixed them
[14:16] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/
[14:17] <Keybuk> X got the xkbcomp patches?
[14:18] <seb128> Keybuk, it did
[14:18] <seb128> 2 days ago
[14:18] <Keybuk> that made a big difference!
[14:19] <Keybuk> if you're on chromium, you can see the Xorg graph drop!
[14:19] <Keybuk> did the -nr patches go in too?
[14:19] <seb128> what chromium has to do with that?
[14:19] <seb128> yes
[14:19] <seb128> they both did in the recent upload
[14:20] <Keybuk> sweet, so when we use plymouth, another 1s or so should magically vanish
[14:20] <Keybuk> seb128: Firefox can't render SVG in <img> tags
[14:20] <Keybuk> so you don't see the cute graphs at the top of the daily-bootcharts URL
[14:20] <seb128> indeed
[14:20] <seb128> I just see a table
[14:21] <seb128> but that's enough to see the 1 second xorg drop
[14:21] <seb128> and the extra 8 seconds for desktop
[14:21] <Keybuk> yeah
[14:23] <mvo> seb128: I was just ignoring you ;)
[14:24] <seb128> mvo, I see ... no tea for you!
[14:26] <seb128> hum
[14:27] <mvo> seb128: I get back to it, I just need to finish some other stuff
[14:27] <seb128> why is jockey-gtk on Keybuk's chart...
[14:27] <seb128> mvo, no hurry, thanks
[14:27] <seb128> pitti, ^
[14:27] <seb128> pitti, did you drop the sleep for starting jockey?
[14:28] <Keybuk> jockey seems to be using a lot of CPU there
[14:28] <Keybuk> but that could be just python startup
[14:29] <Keybuk> appearing to take a long time because the CPU is busy being used elsewhere
[14:29] <Keybuk> I don't think that should be updating cache or anything
[14:29] <Keybuk> post-install, I have:
[14:30] <Keybuk> dbus-daemon --system
[14:30] <Keybuk> jockey-text -u || true
[14:30] <Keybuk> jockey-text -c || true
[14:30] <Keybuk> kill $(cat /var/run/dbus/pid) || true
[14:30] <Keybuk> rm -f /var/run/dbus/pid /var/run/dbus/system_bus_socket
[14:30] <Keybuk> which should force a jockey cache update before the first reboot ;-)
[14:31] <Keybuk> at least, that's the ide
[14:31] <Keybuk> +a
[14:34] <seb128> Keybuk, why do you need to do that?
[14:34] <Keybuk> otherwise on the first boot jockey updates its caches and stuff
[14:34] <Keybuk> and that shows up
[14:35] <Keybuk> there's a broadcom wireless card in them thar minis
[14:42] <pitti> urgh, xorg-edgers looks scary
[14:42] <pitti> seb128: I didn't no
[14:42] <pitti> seb128: but jockey shouldn't be called at all any more, except on very first startup
[14:42] <pitti> I think we can drop even that one once it's integrated in the installer
[14:43] <Keybuk> pitti: how does it decide what "first startup" is?
[14:43] <pitti> but the sleep is currently done within jockey indeed, so we'd still have the interpreter startup
[14:43] <pitti> Keybuk: presence of /var/cache/jockey/check
[14:44] <Keybuk> pitti: would the shell code I pasted above create that?
[14:44] <pitti> should, yes
[14:44] <Keybuk> jockey-gtk only appears on today's
[14:44] <pitti> unless jockey wouldn't actually write it if it didn't detect any drivers; I need to  check that
[14:45] <Keybuk> and on both SSD and HDD
[14:45] <Keybuk> that implies a software bug ;)
[14:45] <Keybuk> pitti: both should have the broadcom wireless
[14:45] <pitti> one odd thing might be that jockey is currently broken completely
[14:45] <pitti> due to some polkit-1 regression
[14:45] <pitti> dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct
[14:46] <pitti> but I'll keep it on my list
[14:48] <Keybuk> haha
[14:48] <Keybuk> let me check
[14:48] <Keybuk> meh
[14:48] <Keybuk> no jockey output in debug log
[14:48] <pitti> so it couldn't ever write that cache file on a fresh install
[14:48] <pitti> jockey-text --list
[14:49] <pitti> ^ does that work for you?
[14:49] <pitti> I bet it raises an exception
[14:49] <Keybuk> no idea
[14:49] <Keybuk> the machines wipe themselves after install
[14:50] <pitti> Keybuk: well, I bet it's that
[14:51] <Keybuk> oh, wait
[14:51] <Keybuk> they only wipe the MBR :p
[14:53]  * pitti installs udevified x.org and holds his breath
[14:53] <Keybuk> pitti: you were quite correct
[14:54] <Keybuk> I got that PK error
[14:54] <Keybuk> pitti: remember the x11_driver thing ;)
[14:54] <Keybuk> that's important
[14:54] <pitti> Keybuk: yes, I have my udev rules in place
[14:54] <pitti> things use evdev, except the touchpad which uses synaptics
[14:54] <pitti> and it knows my keyboard layout, too
[14:54]  * pitti pulls trigger, brb (hopefully)
[14:55] <Keybuk> good luck :D
[14:58]  * pitti grins evily
[14:58] <pitti>  lshal
[14:59] <pitti> Could not initialise connection to hald.
[14:59] <pitti> (II) config/udev: Adding input device "AT Translated Set 2 keyboard" (/dev/input/event4)
[14:59] <pitti> (II) config/udev: Adding input device "AlpsPS/2 ALPS DualPoint TouchPad" (/dev/input/event11)
[14:59] <pitti> (II) LoadModule: "synaptics"
[14:59] <pitti> \o/
[15:00] <Keybuk> sweet
[15:00] <Keybuk> it worked for me on the mini 10s too
[15:00] <Keybuk> pitti: SHIP IT!
[15:02] <pitti> that's xorg-edgers crack of the day
[15:03] <pitti> with a "nice" intel bug
[15:03] <pitti> (II) LoadModule: "synaptics"
[15:03] <pitti> oops
[15:03] <pitti> https://bugs.freedesktop.org/show_bug.cgi?id=25031
[15:03] <pitti> but it's good enough for testing the udev rules stuff
[15:04] <pitti> Caught signal 11 (Segmentation fault). Server aborting
[15:04] <pitti> ^ oh, and I guess this needs to be fixed, too; but details.. :-)
[15:04] <pitti> Keybuk: anyway, I think if we get that, we can move hal from upstart job to dbus-activation
[15:04] <Keybuk> it's nice to know that sanity first-passes work though
[15:04] <pitti> so that it's not in the critical path any more
[15:04] <Keybuk> pitti: to be honest, I'd rather leave HAL disabled for a while ;)
[15:04] <Keybuk> make it really obvious what's using it and encourage them to fix it
[15:04] <Keybuk> then do the activation thing later on
[15:05] <pitti> right
[15:05] <pitti> https://wiki.ubuntu.com/Halsectomy has a pretty complete list
[15:05] <pitti> like, gdm itself
[15:05] <Keybuk> sure, but it's amazing how things show up you didn't know about
[15:05] <pitti> but that's on my list
[15:06] <pitti> Keybuk: by not starting it at all, we'd screw the Kubuntu guys pretty thoroughly, though
[15:08] <Keybuk> I like to think of it as them screwing themselves by not keeping up ;)
[15:11] <pitti> in a new PPA now
[15:12] <pitti> Keybuk: actually, I think we can do something different
[15:13] <Keybuk> such as?
[15:13] <pitti> Keybuk: we have three remaining rdepends on a standard install now, AFAICS: xserver-xorg (see above), gdm (will fix), gparted
[15:13] <pitti> it doesn't seem too hard to make it fall off the CD completely
[15:13] <Keybuk> ah
[15:13] <Keybuk> make sure it falls off the CD you mean?
[15:13] <Keybuk> and flag it if it ever comes back?
[15:13] <Keybuk> that works for me
[15:14] <pitti> hm, gparted -- that's in the live system for rescue love
[15:14]  * pitti wonders if we could just sell palimpsest as a replacement
[15:15] <Keybuk> isn't gparted used by ubiquity? :p
[15:15] <pitti> libparted is
[15:15] <pitti> (I think)
[15:15] <pitti> I don't have hal running now
[15:15] <pitti> and it does detect my internal partitions
[15:16] <pitti> it doesn't react to hotplugging any more, though
[15:16] <Keybuk> it'd be really nice to have those patches in on the sooner timescale ;)
[15:16] <Keybuk> though obv. they depend on a new X :p
[15:16] <Keybuk> really?
[15:16] <pitti> the gdm one doesn't
[15:16] <Keybuk> the code I read through looked like it should just fine
[15:16] <pitti> I'll look into this now
[15:16] <Keybuk> the X code that is
[15:16] <pitti> X code?
[15:17] <pitti> Keybuk: above I was speaking about gparted
[15:17]  * pitti goes to unhalify gdm
[15:17] <Keybuk> ohh
[15:17] <Keybuk> I was going to say, the X code looked right, and reacted to udevadm when I played
[15:18] <Keybuk> udevadm working is important
[15:18] <Keybuk> otherwise how else does one un-stick one's mouse when empathy steals it? :p
[15:18]  * pitti tries hotplugging
[15:18] <pitti> works like a charm
[15:20] <Keybuk> heh
[15:20] <Keybuk> it's amazing how we're getting awesome functionality while removing code :p
[15:28] <JanC> the installer uses libparted, and I think gparted can work without hal now
[15:29] <JanC> I think curtis has a patch for that in gparted git
[15:36] <JanC> http://git.gnome.org/cgit/gparted/commit/?id=d9b892a73f2f078ae6314c4925b438e43fe4392e --> should be in GParted 0.4.8
[15:36] <pitti> JanC: oh, that's just for locking hal/dk-disks
[15:37] <JanC> I don't think GParted uses hal for something else?
[15:37] <pitti> JanC: without hal I apparently loose hotplug detection
[15:37] <JanC> I don't think GParted does any detection of new disks while it's running?
[15:38] <pitti> oh, it doesn't? well, then it's fine
[15:51] <pitti> JanC: confirmed; I have to press control-r after hotplug either way
[15:51] <pitti> hush, away with the hal dep then! :-)
[15:52] <JanC> up to 0.4.7 it depended on the hal lock mechanism, since 0.4.8 it can use both
[15:53]  * pitti confirms http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558022
[15:55] <pitti> JanC: it didn't "depend" on hal before either
[15:55] <pitti> if hal-lock/hal isn't even there, no reason to lock it
[15:55] <pitti> JanC: thanks! (uploaded)
[15:58] <JanC> pitti: no problem, I host/admin the GParted forum, so I somewhat have to know about most of what is going on with GParted development  ;)
[16:21] <mpt> kwwii, are text[NORMAL] and fg[NORMAL] GTK-specific?
[16:23] <kwwii> mpt: they are defined in gtk, yes
[16:23] <mpt> kwwii, so the details about using them can't go in the Icon Naming Specification?
[16:24] <kwwii> mpt: no, not realisticaly without an explanation
[16:24] <mpt> kwwii, I've just completed http://www.freedesktop.org/wiki/SymbolicIcons
[16:24] <kwwii> not all desktops use the same number/names of variables anyway
[16:25] <seb128> yeah for chrisccoulson, didrocks and robert_ancell uploads!
[16:25] <and471> mvo : was there anything wrong with the code?
[16:26] <chrisccoulson> heh, i thought i should start doing some merges now, after not doing very much all week
[16:27] <mvo> and471: nothing wrong, I just would like to see a bit of cleanup on the bits that contruct the spinner from the single image. its currently using hardcoded sizes (24, 72)
[16:27] <mvo> and471: I meant to send a mail about it, but got caught up in other stuff :/
[16:28] <and471> mvo: does it? I thought I replaced them..
[16:28] <mvo> and471: oh, let me check if I really got the lasted rev then
[16:28] <and471> mvo: is that all? in which case I shall fix it now
[16:28] <and471> mvo: no I am sure you did, I probably left out something
[16:29]  * mvo merges again
[16:29] <mpt> kwwii, is that useful for you?
[16:29] <kwwii> mpt: yes, it is well written, somehow I think I could help explain it better
[16:29] <mvo> and471: animatedimage.py is still havng the hardcoded sizes, it would be very nice to fix that
[16:29] <mpt> kwwii, it's a wiki page, go to town :-)
[16:30] <and471> mvo: okay
[16:30] <mvo> and471: I had something else too (something equally small :)
[16:30] <and471> mvo: sure
[16:30] <mvo> and471: give me a sec to remember
[16:31] <mvo> and471: is "fixed1" actually used? in the ui file? it not referenced. or is it a trick to get gtk to layout as you want it to layout?
[16:31] <and471> seb128: have you seen the new version of gThumb? look's pretty slick, I am sure there will now be an argument about f-spot vs gthumb http://www.omgubuntu.co.uk/2009/11/new-gthumb-linux-plugins-f-spot-killer.html
[16:31] <kwwii> dobey: erm, how can I get a login for the freedesktop wiki? and/or do I have one and not know about it?
[16:31] <and471> mvo: nope, the tab page needs some widget inside it, or it doesn't display it, so I just used that, you can change it if you like
[16:32] <seb128> and471, total code write, urg, doesn't seem something for a lts
[16:33] <and471> seb128: yup but it certainly doesn't make it an easier decision :-)
[16:33] <mvo> and471: thats fine, I was just curious if it was deliberate or a left-over :)
[16:33] <and471> mvo: okay I shall clean that up and push
[16:34] <seb128> and471, decision is easy looking to this webpage, we keep what we have
[16:34] <seb128> and471, it still doesn't have timeline nor export to flickr, etc
[16:34] <seb128> and it's not tested
[16:34] <seb128> new codebase
[16:34] <seb128> nothing we want for a lts
[16:34] <and471> seb128: okay okay... :-)
[16:35] <mvo> and471: setup_database_rebuilding_listener() appears to be duplicated, could you please check that
[16:35] <and471> mvo: okay
[16:35] <mvo> and471: nice that you added the sepeartor :)
[16:35]  * mvo likes that
[16:35] <and471> mvo: what's that?
[16:37] <and471> mvo: one thing before I eat, in my branch I added some code that makes */- lists actual HTML lists, however the RegEX is not quite right, it leaves the '*' or '-' at the beginning of the list item. Could you look at this as I have no clue at regex's
[16:38] <mvo> and471: yeah, I can have a look
[16:38] <mvo> and471: I will most likely also move the code that does the subpixbuf() in ShowImageDialog and AnimatedImage into a single function, afaics its the same code
[16:39] <mvo> and471: please let me know when I can re-merge (and thanks for working on it!)
[16:43] <mvo> seb128: compiz is running twice you said in your bootchart? so it re-execs itself?
[16:44] <seb128> mvo, no, I said it doesn't register to the session
[16:45] <seb128> mvo, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091126-28.png
[16:45] <seb128> see the 8 seconds waiting
[16:46] <seb128> I guess it's the "gnome-session waits for compiz to send registration ack which it doesn't"
[16:46] <mvo> seb128: hm, I do not see currently how the no-wrapper patch changes this
[16:46]  * mvo looks deeper
[16:46] <mvo> seb128: gnome-session did not change in any way?
[16:46] <seb128> no
[16:47] <seb128> but gnome-session is picky on who registers
[16:47] <seb128> the binary naming change could make a difference
[16:47] <mvo> ohh
[16:47] <Amaranth> hrm
[16:47] <seb128> let me look in gnome-session if we hardcode compiz.real
[16:47]  * Amaranth hides from seb128
[16:47] <Amaranth> oh, yeah
[16:47] <seb128> Amaranth, that's from Keybuk you should hide
[16:47]  * Amaranth blames gnome-session
[16:47] <Amaranth> but hey, 2 second win :)
[16:48] <Amaranth> I wonder why I never noticed the problem
[16:48] <seb128> what problem?
[16:48] <Amaranth> Probably because I have so much crap running my bootcharts are crazy anyway
[16:48] <Amaranth> gnome-session stalling waiting for compiz to respond
[16:48] <seb128> it was not there before your upload ;-)
[16:49] <Amaranth> I've been using it since I initially wrote the patch though
[16:49] <Amaranth> but my boot times fluctuate a lot anyway, I need to do a clean install and not install web servers
[16:50] <seb128> gnome-session doesn't seem to hardcore anything
[16:51] <Amaranth> mvo: changing gtk/gnome/50-compiz-desktop-key.xml.in won't actually do anything since we ship the metacity version of that file
[16:52] <Amaranth> Which is a change you made, actually :)
[16:53] <mvo> Amaranth: could it be this:
[16:53] <mvo> 	if [ ! -z "$DESKTOP_AUTOSTART_ID" ]; then
[16:53] <mvo> 		COMPIZ_OPTIONS="$COMPIZ_OPTIONS --sm-client-id $DESKTOP_AUTOSTART_ID"
[16:53] <mvo> 	fi
[16:53] <Amaranth> d'oh
[16:54] <Amaranth> I thought gnome-session would just call compiz with --sm-client-id
[16:54] <Amaranth> It did back when we made session save/restore work
[16:54] <seb128> gnome-session will run whatever is in the desktop
[16:54] <mvo> 50-compiz-desktop-key.xml.in> right, that can go away I think
[16:55] <mvo> Amaranth: hm, I have no idea if/why it does not use sm-clinet-id, seb128?
[16:55] <mvo> or maybe vuntz knows?
[16:55] <seb128> vuntz, ^
[16:56] <Amaranth> looks like metacity was fixed to look for DESKTOP_AUTOSTART_ID back in 2007
[16:56] <Amaranth> which means this isn't a gnome-session rewrite problem
[16:58]  * Amaranth adds similar code to compiz
[16:58] <and471> mvo: ah yes the separator :-)
[16:59] <mvo> Amaranth: \o/
[16:59] <mvo> Amaranth: I have dinner now, but I check back in some minutes
[16:59] <seb128> Amaranth, you rock ;-)
[16:59]  * mvo hugs and471 along the way
[16:59] <and471> mvo: hehe
[16:59] <seb128> mvo, enjoy!
[16:59] <mvo> thanks!
[17:00] <vuntz> mvo, seb128: I have no clue how you start compiz :-)
[17:02] <seb128> vuntz, set the session key to  "compiz"
[17:02] <Keybuk> vuntz: "carefully"
[17:02] <seb128> and have no wrapper
[17:03] <seb128> ie just run the compiz binary
[17:03] <seb128> session key = required component wm
[17:05]  * Amaranth builds and tests
[17:05]  * Amaranth wonders how to see if this helps...
[17:05] <and471> mvo: about the hardcoded values, is this any issue? The path to the icon is hardcoded (softwarecenter-progress.png) and so therefore it won't change
[17:06] <mpt> mvo, hi, how's the showing-all-packages stuff going?
[17:06] <Amaranth> mpt: He went to dinner :)
[17:06] <vuntz> so gnome-session can't really pass --sm-client-id since, well, it doesn't know if apps support --sm-client-id
[17:08] <Amaranth> brb, rebooting for bootchart
[17:08] <jwm1> I just upgraded to Karmic and my dual monitor system isn't going -- can anyone help?
[17:08] <and471> mvo: I have removed the duplicate function and per above I think it is now ready to merge :-) If not, please email me
[17:09] <jwm1> or should I be making this inquiry elsewhere?
[17:09] <mpt> mvo, when you're back, can we discuss these work items?
[17:11] <seb128> Keybuk, the login target will be hard to get ...
[17:11] <jwm1> hmm?
[17:11] <seb128> with no desktop effect and no nautilus running we still do 7 seconds
[17:12] <seb128> so it's not only a matter to speed those
[17:12] <mpt> seb128, that's why we have geniuses to work on it
[17:12] <seb128> and we will not bring them to no time
[17:12] <Keybuk> 4 of those seconds are the weird gap to gnome-session
[17:12] <Keybuk> that means you're just 3s
[17:12] <Keybuk> which is 1s under your budget ;)
[17:12] <Keybuk> I didn't randomly invent numbers
[17:13] <seb128> mpt, oh, we got that, good I had the feeling it was just plain old stupid desktop guys there! ;-)
[17:13] <Keybuk> if you remember the flight to brussels, I did a 10s boot
[17:13] <Keybuk> now we're just redoing it in packages
[17:13] <Amaranth> seb128: If gnome-panel starts less than a second after compiz does that mean it's fixed?
[17:14] <seb128> Amaranth, yes
[17:14] <mac_v> seb128: pitti: mpt: why hasnt Bug #194472 been fixed in Ubuntu? Upstream has added the option to show stars if the Distribution chooses , but still it hasnt been fixed?
[17:14] <Amaranth> yay
[17:14] <Amaranth> I guess I get to upload now, let's see if I remember how
[17:14] <seb128> Keybuk, I was not in brussels but still, that will be though, those are not random gaps no
[17:14] <pitti> mac_v: simply because nobody got around to doing it in karmic
[17:14] <mac_v> lol ;)
[17:14] <seb128> Keybuk, it's just that gnome-session order starts
[17:15] <Keybuk> actually that's all stuff before gnome-session
[17:15] <seb128> Keybuk, like it takes 1 second to g-s-d to set themes, etc
[17:15] <Keybuk> starting one at a time to set environment
[17:15] <Keybuk> neat hack to fix that
[17:15] <mac_v> pitti: then could you schedule it for Lucid? so that we dont forget again? :)
[17:15] <Keybuk> decide the environment and tell them ;-)
[17:16] <mpt> mac_v, no idea. Presumably someone needs to change the package to set the pwstars option by default
[17:17] <mac_v> hehe , david rejected it as a papercut twice .. and a similar bug got filed again today ;)
[17:17] <pitti> mac_v: I assigned it to me for now, but it's really loooow prio
[17:17] <mac_v> pitti: yup , sure its low.. thanks :)
[17:17] <seb128> Keybuk, I only see a one second gap before gnome-settings-daemon there
[17:18] <seb128> g-s-d takes some 1 second to set themes, etc
[17:18] <chrisccoulson> you see a 1 second gap between gnome-session starting and g-s-d starting?
[17:18] <seb128> then wm starts
[17:18] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091126-max.png
[17:18] <Keybuk> this shows it quite well
[17:18] <Keybuk> the red dashed line is drawn where the session starts
[17:18] <seb128> chrisccoulson, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091126-28.png
[17:18] <Keybuk> actually, look at 20 sorry
[17:18] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091120-max.png
[17:19] <Keybuk> a lot of that gap before compiz is quite easy to remove
[17:19] <Keybuk> rather than do
[17:19] <Keybuk> start prog 1
[17:19] <Keybuk> prog 1 inits
[17:19] <Keybuk> prog 1 does stuff
[17:19] <Keybuk> prog 1 listens on a socket
[17:19] <Keybuk> prog 1 sets environment
[17:19] <seb128> yours is weird
[17:19] <Keybuk> prog 1 start prog 2
[17:19] <Keybuk> prog 2 ...
[17:19] <Keybuk> etc.
[17:19] <Keybuk> pre-set all the environment variables
[17:20] <Keybuk> and start prog 1, 2, 3, 4 in parallel
[17:20] <seb128> the one I did today has only 1 second before g-s-d start
[17:20] <Keybuk> today's gnome is a bit off
[17:20] <Keybuk> I'm not trusting it until I see repeatability on that :p
[17:20] <seb128> why?
[17:20] <Keybuk> because other things are broken
[17:20] <seb128> I did some 25 charts today
[17:20] <seb128> and the current ones don't have compiz
[17:20] <Keybuk> there's still >1s after ssh-agent
[17:20] <Keybuk> etc.
[17:20] <seb128> g-s-d starts some 1.5 seconds after gnome-session
[17:21] <Keybuk> 1.5s is almost half your budget
[17:21] <Keybuk> 1.5s is a *LONG* time
[17:21] <Keybuk> what is happening in those 1.5s ?
[17:21] <seb128> I don't debate that
[17:21] <Keybuk> are you really doing over 7.5 trillion operations?
[17:21] <seb128> I agree we can win those
[17:21] <seb128> but my current chart is 7 seconds without nautilus running
[17:21] <seb128> so we still have 1.5s with no compiz nor nautilus nor x11 scripts...
[17:22] <chrisccoulson> the delay between gnome-session starting and g-s-d starting is gconfd starting up
[17:22] <seb128> we will need to add nautilus back
[17:22] <chrisccoulson> thats the first thing that gnome-session does
[17:22] <Keybuk> your chart has 3.5s between the session starting and the window manager starting
[17:22] <Keybuk> why?
[17:22] <Keybuk> that 3.5s should be 0
[17:22]  * vuntz hates people working on gnome-session because it creates lots of highlight event in irc for him ;-)
[17:22] <cassidy> seb128, did you already upload the gabble patch ?
[17:23] <Keybuk> chrisccoulson: no it isn't
[17:23] <seb128> cassidy, no
[17:23] <Keybuk> the 3.5s is *before* gnome-session is started
[17:23] <Keybuk> it's the ubuntu Xsession.d directory
[17:23] <seb128> there is over 1 second wanted there
[17:23] <seb128> g-s-d setting the theme etc
[17:23] <seb128> gnome-session start those in order
[17:23] <Keybuk> yes
[17:23] <seb128> theme first, then wm, then rest of the world
[17:24] <Keybuk> the g-s-d 1s is the bit I think is necessary of that
[17:24] <cassidy> seb128, hang on then, I'll have a nice patch for you improving the whole proxy management
[17:25]  * Amaranth crosses his fingers and runs dput
[17:26] <seb128> cassidy, thanks
[17:26] <Amaranth> well nothing exploded...
[17:26] <Amaranth> [ubuntu/lucid] compiz 1:0.8.4-0ubuntu5 (Accepted)
[17:26]  * Amaranth cheers
[17:27] <seb128> Amaranth, congrats!
[17:27] <Amaranth> and now I must run, going to a thanksgiving dinner
[17:27] <Amaranth> seb128: thanks, hopefully it actually fixes the problem :)
[17:27] <seb128> I will tell you once it's available there
[17:30] <pitti> I'm off for today, still some gdm debugging to do, and then dinner/cinema
[17:30] <seb128> pitti, enjoy
[17:31] <seb128> pitti, I'm taking a swap day tomorrow
[17:31] <seb128> so don't freak out if I'm not around
[17:31] <pitti> enjoy!
[17:31] <seb128> thanks
[17:37] <cassidy> seb128, would be awesome if you could apply https://bugs.edge.launchpad.net/ubuntu/+source/telepathy-gabble/+bug/488709/comments/3 asap
[17:37] <cassidy> so admins will stop bitching at us :)
[17:37] <seb128> ok, will have a look
[17:37] <cassidy> thanks
[17:37] <seb128> Keybuk, ok, I moved Xsession.d away
[17:37] <seb128> 8 seconds for desktop
[17:37] <cassidy> seb128,  this patch has been reviewed and merged upstream btw
[17:38] <seb128> with no Xsession.d, no compiz, no nautilus
[17:38] <seb128> Keybuk, we will do what we can but my view is that it's going to be hard
[17:38] <seb128> especially that everybody is busy with other things, ie nobody will be able to do that full time
[17:39] <Keybuk> I didn't say it would be easy
[17:39] <seb128> and we need a better backup plan than drop nautilus and compiz
[17:39] <Keybuk> your priorities are between you and Rick ;)
[17:39] <seb128> that's clearly not enough ;-)
[17:40] <Keybuk> mutter is a reasonable replacement for compiz
[17:40] <Keybuk> and it's arguable that desktop icons aren't a feature we care about ;)
[17:40] <mpt> O_o
[17:40] <seb128> Keybuk, well those 8 seconds are without compiz and no nautilus at all
[17:41] <seb128> ie I removed it from the session components
[17:41] <Keybuk> seb128: bootchart?
[17:42] <Amaranth> So 8 seconds is the goal?
[17:43] <Amaranth> Keybuk: mutter is slower and does less :)
[17:43] <seb128> http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091126-52.png
[17:43] <seb128> Keybuk, http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20091126-52.png
[17:44] <Keybuk> Amaranth: 4s
[17:44] <Keybuk> seb128: you still have 1s before gnome-settings-daemon starts
[17:46] <Keybuk> and 3s before most other things
[17:48] <Amaranth> 4 seconds for the whole desktop? impossible
[17:48] <Keybuk> Amaranth: why?
[17:48] <Keybuk> xfce comes up in 1.5s
[17:49] <seb128> xfce does nothing
[17:49] <seb128> it has no menu by default
[17:49] <seb128> no applet
[17:49] <Keybuk> no, it does everything that gnome does
[17:49] <Keybuk> as far as just about everyone except gnome developers are concerned
[17:49] <Keybuk> you have a panel
[17:49] <Keybuk> it has clock and network and stuff on it
[17:49] <Keybuk> and a button to get your apps
[17:50] <seb128> I've tried xfce during the sprint and honestly you can't compare both
[17:50] <seb128> to add a GNOME applet you need a wrapper which takes some several meg of ram
[17:50] <seb128> and you need one wrapper running by applet
[17:50] <seb128> their places menu is just ugly
[17:50] <seb128> their clock has no locations
[17:50] <Keybuk> so?
[17:51] <Keybuk> it takes 1.5s ;)
[17:51] <Keybuk> you've got 4
[17:51] <Keybuk> that's almost three times as long
[17:51] <seb128> I don't think it's a good trade or something users want
[17:51] <Keybuk> frankly, it really sounds like you don't even want to try
[17:51] <Keybuk> so I suggest you talk to your manager
[17:51] <seb128> user prefer taking 10 seconds to start and have something nice
[17:52] <seb128> I didn't say I don't want to try
[17:52] <Amaranth> How long do we take right now?
[17:52] <Amaranth> subtract the 8 second compiz stall and what is the number?
[17:52] <seb128> I would not have turned my netbook to a test box otherwise
[17:52] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/ has the numbers
[17:52] <seb128> it's just that I'm pretty sure we will not hit the target
[17:52] <Keybuk> desktop is 13-14s currently
[17:53] <Amaranth> ppc, ia64, and armel just FTBFS compiz
[17:53] <seb128> let's be realistic
[17:53] <Keybuk> seb128: with that attitude, we won't hit the target
[17:53] <seb128> we can try but I don't want to promise things we will not deliver
[17:53] <Keybuk> if you think it can't be done, you need to talk to your manager, and he needs to talk to Mark
[17:53] <Keybuk> :)
[17:53] <Keybuk> I know it can be done
[17:53] <seb128> I've been doing that
[17:53] <Keybuk> it's just hard
[17:54] <seb128> there is no way we can do that with 1 GNOME maintainer this cycle
[17:54] <seb128> they moved our second maintainer to oem
[17:54] <seb128> reaching that target is not a side work some hours a week
[17:54] <seb128> but you are right I should talk to my manager rather
[17:55] <Keybuk> sure :-)
[17:55] <Keybuk> I was surprised by that rotation
[18:00] <Amaranth> Doesn't gnome-session do everything /etc/gdm/Xsession does?
[18:03] <mnemo> jono: was it decided at UDS which Firefox release that will go into Lucid?
[18:04] <Amaranth> Keybuk: your netbook isn't using KMS?
[18:04] <Keybuk> it is
[18:04] <Keybuk> though bear in mind that usplash does KMS "wrong"
[18:05] <Keybuk> you still go back to KD_TEXT before X
[18:07]  * Amaranth heads out
[18:19] <mvo> mpt: no changes in non-apps since we talked last
[18:20] <mvo> mpt: work items - give me a minute, I need to prepare
[18:20] <mpt> ok
[18:20] <mvo> mpt: non-apps> the de-duplication of pkg/apps is still a tricky buisiness
[18:25] <mvo> mpt: http://paste.ubuntu.com/328687/ that would be my ordering (most important to least important)
[18:26] <mvo> mpt: maybe with history one higher up, not sure
[18:26] <mvo> mpt: foundations-lucid-software-center-repository-based-index is hard and we could live without, also its very nice to have
[18:27] <mpt> mvo, here's mine: http://paste.ubuntu.com/328690/
[18:28] <mpt> so we agree on #1
[18:28] <mvo> mpt: not bad :)
[18:28] <mpt> we differ mainly on the LP-related ones
[18:29] <mvo> mpt: history requires some work on apt to be really useful, otherwise it will be limited to stuff that you installed via the center. but I agree that its not very important (also nice to have)
[18:29] <mpt> yeah
[18:29] <mpt> mvo, is that the sort of work David might be interested in?
[18:30] <mvo> mpt: possibly, also he has already taken on some other challenges
[18:30] <mvo> mpt: the libapt bits are hopefully not that hard, but might get a bit fiddly with the details
[18:31] <mvo> mpt: i think we should move it up, but make a target of opporunity or something. having some design mockups would be nice too
[18:31] <mpt> Well I definitely don't think it's more important than ratings and reviews :-)
[18:31] <mvo> mpt: repository based indexes can be #2, I'm fine with that
[18:31] <mpt> ok
[18:31] <mvo> #5 then maybe?
[18:31] <and471> mvo: (about the history stuff, in my history branch, there is parsing of the dpkg.log and an xml file that sofwtare-center can generate)
[18:32] <mvo> and471: I would like to move that into libapt, because it known what actions belong together. the disadvantage of dpkg.log is that its hard to tell what operatons where one "transation" (apt run)
[18:32] <mvo> and471: using dpkg.log is of course nice and the best we have for now
[18:32] <mpt> mvo, I'm assuming for both repository-based-index and ratings-and-reviews that it will involve a bit of work from our part, and then a lot of work from the LP team while we work on other things. The main reason I put them high up is so that we unblock the LP team.
[18:33] <and471> mvo: yup sure, just a proof of concept :-)
[18:33] <mvo> mpt: right, so lets move history above -backend and I think we are mostly set
[18:34] <mvo> and471: :) I still have not had a chance to look at this branch :/
[18:34]  * mvo wants more time
[18:34] <and471> mvo: hehe
[18:35] <mpt> mvo, sounds good to me. What does -backend involve? I.e. "support packagekit session API elsewhere on desktop" means support it where, exactly?
[18:35] <mvo> mpt: the session api should really be not part of that spec
[18:36] <mvo> mpt: the idea is to provide a compatible (dbus) api  to PK so that stuff like nautilus can request installation of e.g. mime type based software
[18:36] <mvo> mpt: glatzor was working on this, I think he made some good progress. but it really does not belong into this particular spec :)
[18:38] <mvo> mpt: for some of the above specs I put workitems in, feel free to adjust/update with your own
[18:39] <mpt> mvo, I saw that, thanks, I think I'll see if I can get some advice from rickspencer3 on how to integrate that with bugs that need fixing etc
[18:40] <mvo> I think you can just add bugnumbers to it and leave the assignee out
[18:40] <mvo> but I have not used it that much myself
[18:41] <mpt> mvo, http://paste.ubuntu.com/328698/
[18:42] <mpt> mvo, I mean bugs that are outside of any of those blueprints
[18:42] <mpt> i.e. work items in general
[18:42] <mvo> ok
[18:42] <mvo> mpt: looks good now to me
[18:43] <mpt> thanks mvo, I'll CC you on the reply
[18:49] <mpt> mvo, now you've got me thinking about de-duplication of packages and applications
[18:50] <mpt> mvo, one rule might be: If the package for application X is the only package that Depends: on package Y, then package Y should be hidden inside X
[18:53] <mvo> mpt: interessting idea, for idea like this I can generate you code that tests this idea relatively easily and output what would be hidden. doing that in a realtime search is a bit more tricky though ;)
[18:54] <mpt> mvo, that seems like it might require several iterations of trying it out, like the subcategories will
 mvo: about the hardcoded values, is this any issue? The path to the icon is hardcoded (softwarecenter-progress.png) and so therefore it won't change
 mvo: I have removed the duplicate function and per above I think it is now ready to merge :-) If not, please email me
[18:58] <Tm_T> in my mind hardcoded paths are always unwanted unless there's really good reason
[22:36] <seb128> hey robert_ancell
[22:36] <robert_ancell> seb128, hey
[22:37] <seb128> robert_ancell, did you need anything from me on the gir issue? or did you just copy me the email for information?
[22:37] <robert_ancell> just for information.  I'm still not sure what to do but Joss pointed me to a document where gir policy has changed.  Will need to patch some packages
[22:39] <seb128> which ones?
[22:39] <seb128> we should just rebase on Debian
[22:40] <robert_ancell> gnome-games :)
[22:40] <robert_ancell> I think there were some others....
[22:42] <seb128> ok
[23:14] <fagan> bug hugger is awesome :)
[23:15]  * fagan was just playing about rick"quickly"spencer3 did a great job
[23:21] <Amaranth> wtf
[23:21] <Amaranth> My package got rejected because someone else uploaded an ubuntu5 compiz package? :/
[23:23] <fagan> Amaranth: bump the number then or just ask the person who uploaded the newer one
[23:23] <Amaranth> First I have to figure out who uploaded the newer one
[23:23] <Amaranth> And then beat them up for not pushing to bzr first :)
[23:24] <seb128> Amaranth, no it didn't
[23:24] <Amaranth> seb128: I got a rejected email from launchpad
[23:24] <fagan> Look at the bzr changelog Amaranth
[23:24] <seb128> Amaranth, https://edge.launchpad.net/ubuntu/+source/compiz/1:0.8.4-0ubuntu5
[23:24] <seb128> you uploaded twice?
[23:25] <Amaranth> no...
[23:25] <Amaranth> weird
[23:25] <Amaranth> anyway, yay
[23:25] <seb128> dunno then
[23:25] <seb128> but your upload made it
[23:25] <fagan> is this for lucid
[23:25] <seb128> yes
[23:25] <Amaranth> seb128: Did you try it?
[23:26] <TheMuso> Amaranth: according to lucid changes you uploaded ubuntu5.
[23:26] <fagan> I got a failed upgrade of compiz
[23:26] <seb128> Amaranth, no but I can do that now
[23:26]  * fagan checks 
[23:26] <Amaranth> fagan: Failed how?
[23:27] <fagan> I have compiz.ubuntu5 and I get a could not calculate upgrade error and there are no other updates
[23:28] <Amaranth> fagan: I need more details :)
[23:28] <Amaranth> It may be the Qt transition..
[23:28]  * fagan gos looking 
[23:30]  * fagan realised that it would be a lot easier to find the info if he upgraded through terminal
[23:31] <fagan> compiz-wrapper is the problem
[23:32] <fagan> its asking to be removed
[23:32] <seb128> why asking?
[23:32] <seb128> did you divert that one?
[23:32] <fagan> nope
[23:32] <seb128> why would a package ask to change content...
[23:33] <fagan> Calculating upgrade... Done
[23:33] <fagan> The following packages will be REMOVED
[23:33] <seb128> could you copy the error there?
[23:33] <seb128> or on paste.ubuntu.com
[23:34] <fagan> http://pastebin.ubuntu.com/328894/
[23:34] <Amaranth> fagan: It's supposed to get removed
[23:34] <Amaranth> compiz-core Conflicts/Replaces it
[23:37] <seb128_> re
[23:37] <seb128_> disconnect
[23:37] <seb128_> I was saying
[23:37] <seb128_> could you copy the error there?
[23:37] <Amaranth> seb128_: There is no error
[23:38] <Amaranth> It is wanting to remove compiz-wrapper is all
[23:38] <seb128_> oh ok, good
[23:39] <fagan> when I try to do it in the update manager it gives a failed to calculate upgrade error
[23:39]  * fagan gets the exact error 
[23:39] <fagan> http://pastebin.ubuntu.com/328896/
[23:39] <fagan> The only problem I can see is compiz-wrapper
[23:39] <fagan> seb128: ^^
[23:40] <fagan> Amaranth: is that not a problem?
[23:40] <Amaranth> fagan: Nope, compiz-wrapper is not used anymore
[23:40] <fagan> Oh ok
[23:40] <Amaranth> That's the point of the changes I've been making :)
[23:40]  * fagan just thought it was used 
[23:40] <fagan> My bad
[23:50] <Amaranth> seb128: Did it help?
[23:52] <seb128_> Amaranth, it seems
[23:52] <Amaranth> yay
[23:52] <seb128_> I will confirm with a bootchart next time I reboot
[23:52] <seb128_> but starting a guest session takes some 5-6 seconds now
[23:52] <seb128_> so it seems good
[23:54] <Amaranth> awesome
[23:54] <Amaranth> so with a warm cache we're close to the goal :)