[04:41]  * TheMuso starts to respond to the conversation in -devel, but decides not to. He won't listen.
[04:41] <lifeless> which one
[04:42] <TheMuso> About removing plymouth/upstart et al.
[04:42] <ajmitch> some discussions are best left
[04:42] <TheMuso> Agreed.
[04:43] <lifeless> hmm, subject? I seem to be sparse on u-d mail
[04:44]  * TheMuso is talking about #ubuntu-devel on IRC.
[04:44] <lifeless> oh
[04:44] <lifeless> now it makes sense :)
[04:45] <ajmitch> this is far from the first time he's visited :)
[04:45] <TheMuso> Yeah I remember seeing him ask a questino the other day about removing upstart and going back to sysvinit.
[04:45] <TheMuso> *question
[04:45] <lifeless> oh wow
[04:45] <RAOF> That doesn't seem like a winner :)
[07:04] <pitti> Good morning
[07:06] <didrocks> Guten Morgen pitti
[07:06]  * pitti goes to test the new netbook images
[07:07] <didrocks> pitti: is the boot issue fixed?
[07:07] <pitti> yes
[07:08] <didrocks> great, I'll give it a try too this morning
[07:37] <didrocks> pitti: is it just me, or there is no NotifyOSD in the live session?
[07:42] <pitti> didrocks: right, it's notification-daemon for me in the netbook live session
[07:44] <didrocks> pitti: did you test the desktop one or should I have a look ?
[07:44] <pitti> I didn't test notifications there
[07:44] <pitti> so please do
[07:44] <didrocks> ok, syncing the image
[07:44] <pitti> didrocks: hm, somehow this places thing is still a little unorganized; defaulting to "all applications", and defaulting to that empty view, etc.
[07:44] <pitti> it's really hard to find the installer
[07:45] <pitti> shouldn't there be some kind of "Favourites" somewhere?
[07:45] <pitti> didrocks: "System" apps is empty, is that known?
[07:46] <didrocks> pitti: right, it should default to "all applications" when there is no file in file applications
[07:46] <didrocks> pitti: there is only in the launcher right now
[07:46] <didrocks> yeah, it's known
[07:46] <didrocks> then, there will be an additional places for most common tasks
[07:46] <didrocks> like browsing, listening music, and so on…
[07:47] <pitti> hm, I can't actually find it in "all apps" either?
[07:48] <pitti> I thought that got fixed yesterday
[07:48] <pitti> oh, in _that_ launcher, sorry
[07:50] <didrocks> pitti: yeah, I can only add it in the launcher (to be clear, let's call other "places") :)
[07:51] <didrocks> or we will confuse until the end of times!
[07:51]  * pitti apologizes for his bad terminology
[07:51] <pitti> right, makes sense
[07:52] <didrocks> pitti: for the fun part, try adding a lot of items in the launcher
[07:52] <didrocks> pitti: you should see the "accorderon" effect
[07:52] <didrocks> accordeon*
[07:53] <pitti> doesn't take much; launch terminal, gedit, and eog, and I have it
[07:53] <pitti> but it feels a bit weird when I expand it
[07:54] <didrocks> yeah, I don't like the physics as well
[07:54] <pitti> it doesn't autoscroll to the top again
[07:54] <pitti> it just expands beyond the upper edge into the void
[07:55] <didrocks> there are some bugs like that and the fact that the one you point isn't always the one is select after expand
[07:55] <didrocks> but well, still WIP :-)
[07:57] <didrocks> NotifyOSD works in the GNOME session
[08:04] <pitti> so, netbook install works fine now
[08:04] <pitti> boot looks a little weird, lots of text cursors and no plymouth
[08:04] <pitti> but it works
[08:05] <didrocks> same here
[08:07] <didrocks> I've logged a bug for notify-osd and will add it to iso.qa
[08:20] <robert_ancell> pitti, if I do a SRU for sane-backends will that automatically go to -proposed?  i.e. should I upload it, blog it so people do some testing and we decide only if it should go from -proposed to -updates?
[08:31] <robert_ancell> seb128,  if I do a SRU for sane-backends will that automatically go to -proposed?  i.e. should I upload it, blog it so people do some testing and we decide only if it should go from -proposed to -updates?
[08:31] <seb128> robert_ancell, hey
[08:31] <seb128> robert_ancell, you need to upload to "lucid-proposed"
[08:32] <seb128> it will go in moderation queue, somebody from the sru team will review and accept it, then it will need to be verified and after one week without issue some archive admin will copy it to lucid-updates
[08:33] <robert_ancell> seb128, I guess the question is "should I upload it, given it's not a small fix"
[08:33] <seb128> yes
[08:33] <seb128> it will sit in lucid-proposed for a while time to get testing
[08:34] <seb128> but I guess that's ok
[08:34] <seb128> robert_ancell, reading your reply to my email
[08:35] <seb128> robert_ancell, the "I don't know what you are working on" was rather a "I don't know if you are up to take on other tasks or if you are busy enough" ;-)
[08:35] <robert_ancell> heh
[08:35] <seb128> robert_ancell, "I think we should get d-bus out there and used asap."
[08:35] <seb128> you meant "d-conf"?
[08:36] <robert_ancell> yes
[08:36] <robert_ancell> is LP *really* unreliable for you guys at the moment?  Most of my connections are stalling
[08:37] <seb128> didn't try today
[08:37] <didrocks> robert_ancell: kvalo told me it was quite fast for him this morning. I didn't get issues there
[08:37] <seb128> robert_ancell, gtk3 and gtk2, right mclasen said he would not take any new feature in gtk2 because he doesn't want to encourage app writers to keep using it
[08:38] <seb128> robert_ancell, there was some recent discussion on the gtk list about that
[08:38] <robert_ancell> didrocks, it must be my isp.  real pita all day...
[08:41] <robert_ancell> seb128, do you know of debians plans regarding GTK3?
[08:41] <seb128> robert_ancell, slomo started some work on it in their svn
[08:42] <seb128> robert_ancell, it's basically the gtk2 packaging with a sed gtk2 -> gtk3
[08:42] <seb128> speaking of him
[08:42] <robert_ancell> seb128,  that's what I figured
[08:42] <seb128> slomo, hey ;-)
[08:42] <slomo> hi seb128
[08:42] <seb128> slomo, did you or anybody continued work on getting gtk3 in debian?
[08:43] <slomo> nope, but you might want to talk to bigon about the dconf package
[08:43] <seb128> slomo, and did you read my ping yesterday or the bug report I filed about gsettings schemas trigger?
[08:43] <seb128> slomo, why? is there an issue with it?
[08:43] <slomo> yes, i'll add it with next upload
[08:43] <seb128> thanks
[08:43] <slomo> unless joss did it already ;)
[08:43] <seb128> slomo, he said he would sponsor it to debian and added it to pkg-gnome
[08:44] <slomo> no idea, but it might be incompatible with yours or something
[08:44] <seb128> no, it's ours he added there
[08:44] <slomo> ah it is your package? good :)
[08:44] <seb128> with some cleaning
[08:47] <bigon> you want me to upload d-conf today?
[08:47] <bigon> or do we wait to see if we can resolve the name clash?
[08:47] <bigon> first*
[08:50] <seb128> bigon, what name clash?
[08:50] <seb128> bigon, the source name "dconf"?
[08:50] <bigon> yep
[08:51] <seb128> I would prefer to see d-conf uploaded since some things will start depending on it including empathy
[08:51] <seb128> is anybody trying to get the "dconf" game renamed in debian or dropped or something?
[08:52] <bigon> fredp told me that robert_ancell already asked, if I'm not wrong
[08:54] <seb128> robert_ancell, ^ did you contact the debian dconf maintainer about the name clash?
[08:54] <pitti> bonjour seb128
[08:54] <seb128> hey pitti
[08:54] <robert_ancell> seb128, bigon, I'm trying to think...
[08:54] <seb128> how are you?
[08:55] <alf__> Hi all! What is the targeted cairo version for maverick?
[08:55] <seb128> didrocks, your clutter update failed and depwait on gir1.0-json-glib now
[08:55] <seb128> alf__, 1.10
[08:55] <seb128> alf__, I will upload 1.9.10 after the alpha2 freeze
[08:55] <robert_ancell> I don't think I opened a bug
[08:55] <seb128> robert_ancell, ok
[08:56] <didrocks> seb128: hum, weird, that's probably a locally installed package. I have to find the json typlib file somewhere, thanks for the notice
[08:56] <seb128> didrocks, seems neither debian or maverick have that binary
[08:56] <seb128> didrocks, I'm wondering where you got it
[08:57] <didrocks> seb128: I should have mistyped something, there was an issue with the missing json typelib file
[08:57] <seb128> didrocks, oh, it's named gir1.0-json-glib-1.0
[08:57] <didrocks> ok, typo so :)
[08:57] <didrocks> yeah, it's that one
[08:57] <didrocks> fixing and uploading
[08:57] <didrocks> thanks
[08:57] <seb128> thanks
[08:58] <seb128> bigon, so no, robert_ancell didn't, I would not block on it or it will take weeks
[08:59] <bigon> ok
[09:00] <bigon> robert_ancell: is it possible that the dbus activation of d-conf is not working? I've tested it on maverick with empathy git and I had to launch the daemon by hand?
[09:00] <Zdra> bigon, works for me
[09:01] <Zdra> with the d-conf package we have in telepathy-devel ppa
[09:01] <seb128> Zdra, which one is that? the one from maverick?
[09:01] <robert_ancell> bigon, yeah, I haven't had to run it by hand either
[09:02] <alf__> seb128: Excellent, thanks! One thing that is missing though (at least from the current debian packaging) and which I mostly need is a binary package for cairo-trace, cairo-perf-trace.
[09:02] <bigon> ok so my bad I guess
[09:02] <alf__> seb128: I can send you a patch when you have uploaded the new version.
[09:03] <seb128> alf__, the new version will come from debian
[09:03] <seb128> robert_ancell, should running dconf-editor start dconf-service?
[09:03] <seb128> (it doesn't)
[09:03] <Zdra> seb128, yep
[09:03] <alf__> seb128: So I should send a patch directly to them?
[09:03] <seb128> alf__, dget http://ftp.debian.org/debian/pool/main/c/cairo/cairo_1.9.10-1.dsc
[09:04] <seb128> alf__, that would be nice yes, we can apply a change in ubuntu as well while they consider it but it's better if we can stay in sync
[09:04] <seb128> alf__, slomo is maintaining cairo in Debian so you can try asking him if he would be wanting to take that change
[09:05] <robert_ancell> seb128, I expect it should.  I'm still trying to work out why dconf-editor exists at all, and it's not gsettings-editor (I'll be asking this one at guadec)
[09:05] <alf__> seb128: Thanks, I 'll get in touch with him
[09:05] <seb128> alf__, he's on this channel ;-)
[09:05] <seb128> robert_ancell, ok, do we have anything using dconf in maverick right now?
[09:05] <alf__> seb128: Even better ;)
[09:05] <slomo> alf__: why do you need cairo-trace and friends?
[09:05] <robert_ancell> seb128, I don't think so
[09:06] <robert_ancell> except for the command line dconf tools
[09:06] <seb128> robert_ancell, ok, time to upload this new calculator of yours :p
[09:06] <robert_ancell> seb128, is A3 out yet?
[09:06] <alf__> slomo: Hi! For https://blueprints.launchpad.net/ubuntu/+spec/arm-m-ui-and-test-heads
[09:06] <pitti> robert_ancell: in three weeks :)
[09:06] <seb128> robert_ancell, it's a2 and no right, but it should be today, ie you can update it tomorrow if you want
[09:07] <slomo> alf__: can you give me a summary? ;)
[09:07] <seb128> pitti, will we get respins or can we do updates now?
[09:07] <robert_ancell> pitti, :P
[09:07] <pitti> we are currently respinning server ISOs
[09:07] <robert_ancell> seb128, will do it tomorrow then
[09:08] <seb128> robert_ancell, thanks
[09:08] <pitti> and all kubuntu images and ubuntu DVDs weren't tested yet
[09:08] <pitti> so they might need more fixes
[09:08] <seb128> ok, let's wait a bit then
[09:08] <alf__> slomo: Sure :) We are compiling a set of benchmarks that will be available for testing graphic stack implementations on the linaro platform.
[09:08] <seb128> tomorrow will do
[09:08] <pitti> seb128: so ATM, only "safe" ones, please (no complicated dependency changes, etc.)
[09:08] <robert_ancell> seb128, I've been holding back packages so A2 is more stable
[09:09] <pitti> it took enough work to get http://people.canonical.com/~ubuntu-archive/testing/maverick_probs.html down to 1 uninstallable on i386/amd6 :)
[09:09] <seb128> robert_ancell, it's a wise decision ;-)
[09:09] <slomo> alf__: ok, but you're aware that this needs the cairo script backend and that the API of it is public but not stable?
[09:09] <slomo> alf__: also i don't know if enabling that backend has other implications
[09:10] <seb128> robert_ancell, btw what do you think about shotwell against f-spot?
[09:10] <robert_ancell> seb128, what about it?
[09:11] <seb128> robert_ancell, how is shotwell going? I didn't watch their work but it seems you did
[09:11] <seb128> robert_ancell, f-spot got maintained again, I'm wondering if we should still consider changing the default
[09:13] <robert_ancell> seb128, shotwell is going great.  F-Spot is working on their library changes to integrate with banshee so I think that will slow down their progress.  The speed of shotwell is a huge selling point.  It has some UI improvements that need to be worked on, but I think it's ahead of F-Spot and heading in the right direction.
[09:13] <robert_ancell> I've only ever had UI issues with it, not stability
[09:13] <seb128> ok, nice
[09:13] <seb128> how active is shotwell upstream atm?
[09:14] <alf__> slomo: How will this affect trace playback? Do you mean that trace scripts produced by one version be incompatible (eg non-replayable) by another?
[09:14] <robert_ancell> seb128, very
[09:14] <seb128> robert_ancell, excellent
[09:14] <robert_ancell> seb128, just released 0.6, now working on 0.7
[09:14] <robert_ancell> which will be the release for 10.10.  They've aligned their schedule to match ours
[09:14] <seb128> robert_ancell, I'm testing 0.6 right now and I don't see many difference with what I tried at UDS that's why I was asking
[09:15] <seb128> robert_ancell, ok, let's discuss doing the change during the sprint as well
[09:15] <seb128> robert_ancell, thanks
[09:15] <slomo> alf__: that's the case, yes. also the interface that can be used by application to use the cairoscript backend might change the api
[09:15] <robert_ancell> seb128, sure.  You might have been using the unstable releases before so you wouldn't notice much
[09:16] <seb128> robert_ancell, that's possible
[09:17] <robert_ancell> seb128, I need someone to sponsor sane-backends (in main), what is the best way to give the packaging info?  I've attached a debdiff but it is huge
[09:17] <robert_ancell> bug 600516
[09:17] <ubot2> Launchpad bug 600516 in sane-backends (Ubuntu) "Update sane-backends in Lucid to 1.0.21 (affects: 1) (heat: 6)" [Wishlist,New] https://launchpad.net/bugs/600516
[09:18] <seb128> robert_ancell, upload to your ppa and ask somebody to sponsor that to ubuntu?
[09:18] <robert_ancell> seb128, ok it is here: https://edge.launchpad.net/~robert-ancell/+archive/sane-backends/+packages
[09:18] <seb128> robert_ancell, ok, I will sponsor that
[09:19] <seb128> robert_ancell, hum, that's a merge version?
[09:19] <alf__> slomo: I don't think any of these is going to be a problem for our use case. The plan is to use the cairo-perf-trace util to play back traces that we will supply in a separate package, so we can update the scripts package in case of incompatible changes.
[09:19] <robert_ancell> seb128, yeah, do you think I should try and do it non-merged?
[09:20] <alf__> slomo: scripts package=the separate packages containing the traces
[09:20] <robert_ancell> seb128, that's the problem with this update. it's going to be huge no matter how you look at it
[09:20] <seb128> robert_ancell, the less un-required changes the better chance you have to get it accepted for a sru
[09:20] <slomo> alf__: ok
[09:20] <seb128> robert_ancell, well drivers are one thing and upstream code change
[09:20] <slomo> alf__: file a bug with a patch against the debian package please
[09:20] <seb128> robert_ancell, changing the packaging is another one
[09:20] <slomo> alf__: or send me a mail with the patch
[09:21] <seb128> robert_ancell, ie let's keep the packaging changes low so we know we will not get issues from there
[09:21] <alf__> slomo: sure, thanks!
[09:21] <seb128> robert_ancell, or check with pitti he's the one approving those sru usually
[09:21] <seb128> robert_ancell, but usually we try to not changing packaging in stable updates
[09:23] <robert_ancell> gtg
[09:25] <robert_ancell> seb128, I'll package it up tomorrow without the merge changes
[09:25] <seb128> ok
[09:25] <seb128> robert_ancell, have fun, see you later
[09:26] <seb128> RAOF, hi
[09:26] <RAOF> seb128: Good morning/evening.
[09:26] <seb128> RAOF, how are you?
[09:26] <RAOF> Pretty good.
[09:27] <RAOF> Yourself?
[09:27] <seb128> RAOF, thanks for getting your a2 items in shape and responding to that xorg bug I pinged you about the other day ;-)
[09:27] <seb128> RAOF, I'm fine thanks
[09:27] <RAOF> No problem :)
[09:27] <RAOF> It appears to be open-season on X bugs.
[09:29] <seb128> I've the feeling it's always an open-season with bugs ;-)
[09:29] <seb128> though to be honest desktop ones did settle down a bit now
[09:30] <seb128> the after new version crazyness is over, we are back to the normal busy activity
[09:30] <RAOF> I get to have one more cycle of that when we move to xserver 1.9 and mesa 7.9.
[09:31] <RAOF> On the other hand, there's a bunch of fixes in there, and some nice bootspeed improvements.
[09:32] <seb128> I've started upgrading this box to maverick yesterday and got issues due nvidia binaries hijacking libglx
[09:32] <seb128> which made GLX fail to work since I'm on intel
[09:32] <seb128> is there any known issue about thise?
[09:32] <RAOF> Doesn't that have an awesome failure mode?  Did you get the upside-down, mirrored textures? :)
[09:32] <seb128> I'm not sure why nvidia-current got installed on upgrade
[09:32] <pitti> seb128: anything new from the gnome world or from implemented desktop specs which should be in https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview ? (unity/appmenu is already covered)
[09:33] <seb128> no I didn't, just no compiz ;-)
[09:33] <didrocks> oh unclutter is now installed by default, nice :-)
[09:33] <seb128> didrocks, "nice" if you like it ;-) I find it confusing
[09:33]  * RAOF doesn't really like unclutter.  It sounded like a good idea, though.
[09:34] <RAOF> seb128: There was a bug where nvidia-current got pulled in.  I thought that had been resolved (and was in something like mythtv?)
[09:34] <seb128> pitti, checking but I don't think so no
[09:34] <didrocks> seb128: just noticed it and find it good when reading webpage. I will see how it goes today with normal activity :)
[09:35] <seb128> didrocks, I find the change on screen disturbing
[09:35] <seb128> I'm used to put the cursor out of the way but then I notice something changing somewhere when it's hidden which is weird
[09:35] <didrocks> seb128: I think it's a question of habits, did you try it for a long time?
[09:35] <seb128> I also get often confused trying to find it on screen to not what movement I need to do to click where I want
[09:35] <seb128> didrocks, 2 weeks now
[09:36] <didrocks> ok, so you have more experienced in it
[09:36] <seb128> "to know what"
[09:36] <didrocks> :)
[09:37] <didrocks> I just find it to be hidden in a too fast right now
[09:37] <RAOF> It also seems to get in the way of Chromium's “hover over the url to get the status text expanded into a non-ellipsised url” thnigy.
[09:41] <seb128> pitti, no, nothing fancy out of merges with debian and platform updates which is already listed
[10:21] <mvo> didrocks: re login> there is code in the lazr branch for this that uses ubuntu-sso
[10:22] <mvo> didrocks: how does it currently work with ubuntuone?
[10:22] <didrocks> mvo: thanks. I'll have a look. Not sure it's working with u1 right now and how to make the u1 website discoverable
[10:22] <didrocks> mvo: I'll see what u1 preferences will implement in near futur and base on the same thing, I think
[10:24] <mvo> didrocks: ok, we just need to make sure we have a single login thing
[10:24] <didrocks> mvo: yeah, with u1 preferences/usc/oneconf
[10:25] <didrocks> mvo: I'll ask rodrigo this afternoon
[10:26] <mvo> didrocks: ok, what s-c can do for you currently is to get a oauth token from ubuntu-sso, that is the status-quo, but it should be trivial to extend. if u1 can give  me this (oauth ubuntu-sso token) then that is fine with me as well
[10:27] <didrocks> mvo: ok, just need to ensure that we have one token stored somewhere and be common to the 3
[10:29] <mvo> didrocks: yep, no multiple login dialogs
[10:29] <mvo> didrocks: I merge the lazr branch today I think into trunk
[10:29] <didrocks> mvo: agreed, what I will do is just the sign-in or Join Ubuntu One… to call your dialog (https://wiki.ubuntu.com/SoftwareCenter#oneconf)
[10:30] <didrocks> not sure you have distiction between sign-in or join btw
[10:31] <mvo> didrocks: the join is not implemented in gtk, it will just spawn a website
[10:31] <mvo> but login is of course
[10:31] <didrocks> mvo: ok, so, just sign-in will launch your dialog
[10:31] <didrocks> and we need to ensure u1 is using the same token
[10:32] <didrocks> thanks :)
[10:33] <mvo> yeah, or that we have a u1login object that can re-use username/password if we can not use the same token
[10:33] <asac> seb128: could you please NEW all the current librtcom-telepathy-glib binaries that are in the queue? (sparc etc. will take a bit longer)
[10:33] <asac> thx man
[10:33] <seb128> asac, ok
[10:33] <mvo> didrocks: we will figure something out :)
[10:33] <asac> seb128: rock!
[10:33] <didrocks> mvo: sure :)
[10:37] <huats> morning
[10:37] <didrocks> salut huats
[10:38] <seb128> asac, newed
[10:38] <seb128> lut huats
[10:38] <asac> merci
[10:39] <seb128> asac, de rien ;-)
[10:39] <huats> hello didrocks and seb128
[10:42] <seb128> didrocks, do you have any clue what happened to evolution-alarm-notify in the new evo?
[10:44] <seb128> pitti, is jockey supposed to work currently?
[10:44] <pitti> supposed to, yes, but I never tested it on maverick
[10:45] <seb128> hum
[10:45] <seb128> "Downloading package indexes failed..."
[10:45] <seb128> I guess I need to go online for it to say something
[10:46] <didrocks> seb128: no, I didn't investigate though. Just think that it's related to e-d-s protocol change
[10:46] <seb128> didrocks, ok, because you kept the ubuntu desktop file to start it with the session but there is no binary to start
[10:47] <seb128> didrocks, so either we need to drop that autostart or to get the binary back ;-)
[10:47] <didrocks> seb128: when I told you I didn't investigate… :-)
[10:47] <pitti> seb128: yes, it has always required to have current apt indexes
[10:47] <didrocks> let me see where is the binary
[10:48] <seb128> pitti, yeah, ignore me, it's always the same "you need to get online to get jockey to tell you this box needs binary drivers to get internet to work"
[10:48] <pitti> ethernet FTW :)
[10:48] <seb128> I've on cable only on my desktop and my laptop is docked with it right now
[10:49] <seb128> if IRC wouldn't suck and handle the eth to wifi change I would grab it ;-)
[10:49] <pitti> back in ~ 1 hour
[10:51] <seb128> didrocks, don't bother I will sort that
[10:51] <chrisccoulson> good morning everyone
[10:51] <seb128> didrocks, upstream got an autostart for it it seems so in any case the debian one should be dropped
[10:51] <seb128> hey chrisccoulson, how are you?
[10:51] <chrisccoulson> hey seb128, i'm good thanks. i got a bit of a sleep in today :)
[10:51] <chrisccoulson> how are you?
[10:52] <seb128> nice
[10:52] <seb128> I'm fine thanks
[10:52] <didrocks> seb128: oh ok, so we just don't install the upstream one. Thanks for working on this. I'm stopping looking and go back to hacking :)
[10:52] <didrocks> hey chrisccoulson
[10:55] <chrisccoulson> hey didrocks, how are you?
[10:55] <didrocks> chrisccoulson: I'm fine thanks, it's quite hot here! :)
[10:55] <chrisccoulson> nice! it's not so hot here today
[10:56] <chrisccoulson> although, still quite warm
[10:56] <chrisccoulson> my laptop doesn't like the heat ;)
[11:05] <chrisccoulson> is anybody having issues with flash in ff3.6.6?
[11:05] <baptistemm> a lot of message stating that flash is taking too much cpu?
[11:06] <chrisccoulson> baptistemm, i was thinking more along the lines of the flash content not displaying at all ;)
[11:07] <chrisccoulson> it seems a lot of users have issues with the flash plugin crashing after upgrading to 3.6.6
[11:07] <chrisccoulson> on lucid and hardy
[11:07] <seb128> chrisccoulson: wfm on maverick
[11:07] <chrisccoulson> seb128, thanks
[11:07] <chrisccoulson> i'm a bit stuck, i can't recreate it and i'm not sure what to do to debug it really :/
[11:09] <seb128> it's a crashing issue? on what arch?
[11:10] <seb128> chrisccoulson: what flash version do they use as well?
[11:10] <seb128> my laptop was running lucid with the mozilla security ppa versions until yesterday and I didn't get any crash
[11:10] <chrisccoulson> seb128 - they're using the adobe-flashplugin package from the partner repository
[11:11] <seb128> chrisccoulson: did you get bugs on i386? or is that amd64 rather?
[11:12] <chrisccoulson> seb128 - just i386. the new OOPP feature doesn't work for the plugin on amd64
[11:12] <chrisccoulson> which seems to be what is causing all the issues
[11:13] <seb128> is there a way to trigger the bug? how often does it crash?
[11:13] <seb128> I'm not using flash a lot
[11:13] <seb128> but I do browse quite some website with flash advertissements etc
[11:15] <chrisccoulson> seb128 - for some users, it just crashes right away on any page with flash content
[11:15] <seb128> urg
[11:16] <chrisccoulson> i'm wondering if i can get apport to catch the crashes from the plugin-container process
[12:17] <pitti> didrocks: wrt. bug 600567, I assume nouveau doesn't have 3D; so is that because we do not currently have an automatic fallback to -efl?
[12:17] <ubot2> Launchpad bug 600567 in netbook-meta (Ubuntu) "Netbook launcher doesn't start (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/600567
[12:18] <didrocks> pitti: right, there is no netbook-launcher and unity doesn't have a fallback
[12:18] <pitti> thanks; that's something for the release notes
[12:18] <pitti> didrocks: is there already a bug for this, or should I brush this up a little and make it the master bug?
[12:18] <didrocks> pitti: there is a blueprint for fallback but nobody to implement it seriously
[12:19] <pitti> didrocks: oh, is that hard to do? I thought unity would just need to exec n-l-efl if it sees that it doesn't have (enough) 3D?
[12:20] <didrocks> pitti: you have to start gnome-panel too, and so on
[12:20] <pitti> right, so not n-l-efl, but gnome-session
[12:20] <didrocks> pitti: and my fallback system doesn't catch all corner cases
[12:20] <didrocks> gnome-session is already run, you just need to execute additional component
[12:21] <didrocks> I *could* maybe retake my work done, but integrating that in jockey would have more sense (setting the default session)
[12:21] <didrocks> there was a discussion and blueprint at UDS about that, ask ogra
[12:21] <pitti> jockey?
[12:21]  * pitti searches for the spec, to link against the bug
[12:22] <ogra> pitti, linaro took the spec but then didnt have the resources
[12:22] <didrocks> https://blueprints.edge.launchpad.net/ubuntu/+spec/arm-m-une-launcher-on-arm
[12:22] <pitti> ah, that's the one I just found; thanks
[12:22] <ogra> yeah
[12:23] <ogra> i'll care for lightweight panel and if possible at least set the default session to une-efl on armel
[12:25] <ogra> didrocks, btw, the session is still called like that, right ?
[12:25] <pitti> ok, bug updated and added to tech overview
[12:26] <didrocks> ogra: I think so, I didn't touch it, IIRC n-l-efl has the .desktop file (the name is the .desktop file one)
[12:26] <didrocks> pitti: thanks
[12:27] <ogra> didrocks, thanks
[12:28] <mvo> kiwinote: thanks for your mail/status update. one thing I would love to see is a quick look on the start speed, it feels like we are regressing here. not ugent, just wanted to mention it
[12:49] <alf__> slomo: Would you prefer libcairo-script-interpreter in a separate binary package or as part of libcairo2?
[12:50] <slomo> alf__: a new libcairo with only the script interpreter? no, i think i'd prefer to have it in the main libcairo2
[12:50] <slomo> alf__: or is it a separate library anyway?
[12:51] <alf__> slomo: It is a separate library (note that the relevant headers are already shipped in libcairo2-dev)
[12:52] <slomo> alf__: how large?
[12:53] <alf__> slomo: 137312 bytes stripped
[12:54] <vish> seb128: hi , for Ibus bugs, merge is OK , or.. ? I'm not sure where upstream for IBus is
[12:54] <slomo> alf__: well, put it in libcairo2 but not in the udeb, ok? ;)
[12:54] <alf__> slomo: of course :)
[12:54] <seb128> vish, I've no clue about ibus
[12:54] <vish> oh!
[13:02] <vish> seb128: who looks after IBus?  ArneGoetje ?
[13:02] <seb128> if somebody does ArneGoetje is your best guess indeed
[13:05] <seb128> hum, iz pitti bog
[13:06] <seb128> bug #570462 is due to the lazy init change
[13:06] <ubot2> Launchpad bug 570462 in libnotify (Ubuntu) "Crash if no notification used (affects: 1) (heat: 6)" [Low,New] https://launchpad.net/bugs/570462
[13:18] <pitti> mjak?
[13:19]  * pitti looks
[13:19] <didrocks> going for a break and some errands before unity release, bbiab
[13:20] <pitti> seb128: ah, I'll have a look
[13:20] <seb128> pitti, thanks
[13:35] <pitti> seb128: fix pushed upstream, and bug updated; does that break anything serious?
[13:35] <pitti> I just get an assertion error on stderr, but no actual crash
[13:36] <seb128> pitti, thanks, no I guess it's only the assertion
[13:37] <pitti> seb128: on that note, git head requires gtk 3..
[13:37] <seb128> pitti, feel free to unassign yourself from the bug, I plan to sync the new libnotify on debian, I think that fix can wait the next tarball
[13:37] <pitti> seb128: will do once it bores me; but for now I want to wait for the reporter's confirmation
[13:38] <pitti> that it wasn't a real crash
[13:38] <seb128> pitti, it should not?
[13:38] <seb128> depends on gtk3
[13:38] <pitti> seb128: upstream git head, not our package
[13:38] <pitti> upstream is at 0.5.0, we have 0.4.5
[13:38] <seb128> pitti, I've 0.5.0 locally
[13:39] <seb128> I'm reviewing bugs before syncing it from debian
[13:39] <pitti> ok, then they changed it after 0.5.0
[13:39] <pitti> checking for GTK3... configure: error: Package requirements (gtk+-3.0) were not met:
[13:39] <seb128> pitti, I guess it's the recent commit to not depends on a specific gtk version
[13:39] <seb128> they use it only for a test
[13:39] <seb128> seems it could be optional
[13:46] <seb128> pedro_, hey
[13:46] <pedro_> hello seb128
[13:46] <seb128> pedro_, could you try to validate the few desktop sru bugs still blue on the list today?
[13:47] <seb128> pedro_, how are you btw? ;-)
[13:47] <pedro_> seb128, yes i'll have a look into those, i'm all into testing today ;-)
[13:48] <pedro_> seb128, I'm good, thanks. what about you?
[13:48]  * pedro_ syncing latest isos
[13:48] <seb128> I'm fine thanks
[14:14] <alf__> slomo: It seems the perf tools also need /usr/lib/cairo/libcairo.so. I can put it in the new cairo-perf-utils package, make a separate package or put it in the libcairo2 package. What would you recommend?
[14:14] <and471> mvo: you free for a question?
[14:15] <alf__> slomo: oops, I meant /usr/lib/cairo/libcairo-trace.so.*
[14:15] <slomo> alf__: i don't understand what you mean
[14:16] <alf__> slomo: the build produces /usr/lib/cairo/libcairo-trace.so.* which is not in any binary package at the moment.
[14:16] <chrisccoulson> hmmmm, i can get the flash plugin to crash frequently in KVM by browsing youtube
[14:17] <chrisccoulson> but gdb says the crash happens deep inside the flash player
[14:17] <chrisccoulson> oh well ;)
[14:17] <alf__> slomo: But the perf utils (cairo-trace in particular) needs this library. I was wondering what is the best package to put it in.
[14:19] <mvo> and471: sure
[14:19] <slomo> alf__: put the library in libcairo2 as discussed and the utilities in the -dev package maybe
[14:20] <and471> mvo, in software-center, to connect javascript functions to python functions, you change the title and then bind the title change signal, is this correct?
[14:20] <mvo> and471: yes
[14:21] <mvo> and471: nowdays it could be done with intercepting JS altert signals too, but in general the support is limited
[14:21] <and471> mvo, what would you say is the best way?
[14:21] <mvo> and471: there is a good chance that this goes away btw, nzmm is working on a native gtk view for the backend
[14:21] <alf__> slomo: Sure, although we are not talking about the same library now (the previous one was libcairo-script-interpreter.so.*)
[14:21] <and471> mvo, gwibber uses links and parses them {(if they start with gwibber:
[14:21] <mvo> and471: I think it does not matter, title change should be fine
[14:22] <and471> mvo, oh cool :-)
[14:22] <and471> mvo, thanks for the advice :-)
[14:22] <alf__> slomo: I was thinking of creating a new package for the utilities (eg cairo-perf-utils) but I guess putting them in -dev is fine
[14:22] <and471> mvo, how will the gtk backend work? with cairo?
[14:22] <mvo> and471: sure, np. I think all ways are equally good/bad
[14:22] <and471> hehe
[14:22] <mvo> and471: yeah, cairo and lots of manual work
[14:23] <and471> mvo, fun fun
[14:23] <and471> mvo, I shall leave you now :-) see you later
[14:34] <slomo> alf__: ok
[14:37] <seb128> desrt, hey there?
[15:05] <desrt> seb128: hi.  what's up?
[15:08] <seb128> desrt, hey
[15:08] <desrt> am i in trouble? :)
[15:08] <seb128> desrt, you still recommend not shipping the gconf gsettings backend?
[15:08] <desrt> that's correct.
[15:09] <desrt> it has priority of -1 for a reason :)
[15:09] <seb128> desrt, no, rather I figured we lack the schemas conversion utility and the config migration one because we turn that option off in the gconf build
[15:09] <desrt> ahh
[15:09] <desrt> it might be appropriate to ship them in a separate package
[15:09] <seb128> desrt, I guess I will turn the option on but not include the backend in the binary
[15:09] <desrt> the config migration *should* be shipped by default
[15:10] <desrt> the schema-migration and backend could be useful in a separate package, indeed
[15:10] <seb128> is the backend required for gsettings-schema-convert?
[15:10] <desrt> no
[15:10] <desrt> gsettings-schema-convert used to be in glib
[15:10] <seb128> ok, so I will just ship that one with gconf
[15:11] <seb128> and don't bother with the backend
[15:11] <desrt> we took it out of glib because (sadly) it's quite totally unmaintained
[15:11] <desrt> vuntz wrote it and forgot about it, basically
[15:11] <desrt> vuntz: bad vuntz :p
[15:11] <seb128> btw
[15:11] <seb128> libglib2.0-doc: /usr/share/doc/libglib2.0-doc/gio/gsettings-schema-convert.html
[15:11] <seb128> not sure if that's fixed in git or still there or wanted
[15:11] <desrt> it's gone in git
[15:12] <desrt> what release was that .html in?
[15:12] <seb128> desrt, doh, I upgraded the lib but not the api binary
[15:12] <desrt> ah
[15:13] <seb128> ok, better now
[15:13] <seb128> desrt, thanks
[15:15] <desrt> seb128: so what's your official policy on gtk3?
[15:15] <desrt> keeping it off the CD?
[15:17] <seb128> yes
[15:18] <seb128> getting the stack ready this cycle as much as we can
[15:18] <seb128> but not having to deal with fitting 2 gtk stack on the CD
[15:18] <desrt> so any app that wants to be on the CD has to be able to build against 2.9x
[15:18] <seb128> 2.2x rather
[15:18] <desrt> huh
[15:18] <desrt> so 3.x will be in the archive?
[15:18] <seb128> we will likely backport gtkapplication to it though
[15:19] <seb128> since that's about the only api required to build updates with gtk2
[15:19] <seb128> desrt, yes, likely in main but not on the CD
[15:19] <desrt> that's pretty reasonable
[15:19] <desrt> i guess maverick+1 will be the 2->3 flagday?
[15:19] <desrt> ie: switch the CD to gtk3-only
[15:19] <seb128> desrt, as said the issue is that we don't think we will be able to port the whole CD to gtk3 (hello firefox etc) and we don't think we can deal with fitting 2 gtk stacks while working details
[15:20] <gicmo> ah firefox
[15:20] <seb128> so we want everything to be ready to transition for maverick
[15:20] <gicmo> how cares about firefox
[15:20] <gicmo> who
[15:20] <gicmo> who needs a browser?!
[15:20] <gicmo> ;-)
[15:20] <seb128> and migrate next cycle
[15:20] <desrt> seb128: sounds great
[15:20] <seb128> gicmo, that's the spirit ;-)
[15:20] <seb128> desrt, ;-)
[15:21] <seb128> desrt, we will likely get GNOME3 or part of it being worked in a ppa
[15:21] <seb128> it will have a double advantage
[15:21] <seb128> it doesn't break maverick
[15:21] <seb128> and we will be able to keep working on it after freeze etc
[15:22] <desrt> seb128: btw...
[15:22] <desrt> why do i have an ubuntu logo instead of a gnome foot in my panel in stracciatella? :)
[15:23] <seb128> hum, seems a bug ;-)
[15:23] <desrt> yes!  it does!
[15:24] <seb128> pitti, ok, so how likely will we need to respin a2 images?
[15:24] <seb128> pitti, or said otherwise, can I upload my gconf update? ;-)
[15:24] <pitti> seb128: go ahead; ubuntu ones are fine
[15:25] <seb128> pitti, thanks
[15:25] <pitti> seb128: still waiting for any test result on kubuntu alternates, but gconf doesn't affect them
[15:26] <desrt> the gconf->gsettings migration situation is dismal :(
[15:27] <desrt> we have like... empathy, gedit, eog, evince
[15:27] <desrt> totem, i think
[15:27] <desrt> gnome-bluetooth
[15:27] <desrt> a few small others, but that's about it
[15:29] <didrocks> yeah, your email was quite clear that maintainers should trust gsettings now (hey desrt btw o/)
[15:30] <alf__> slomo: debian bug #587771
[15:30] <ubot2> Debian bug 587771 in cairo "Package cairo-perf utilities" [Wishlist,Open] http://bugs.debian.org/587771
[16:06] <ronoc> bl8: hey, so mirsal will definitely finish the mpris spec by the end of this week, I plan to work on the mpris 2 support from early next week. So you should have a compliant mpris v2 sound menu for next thurs (implementing play, skip, previous and metadata). the scrub bar is coming shortly,
[16:07] <chrisccoulson> hmm, is anyone having difficulty connecting to LP?
[16:07] <seb128> yes
[16:07] <seb128> it's down it seems
[16:07] <seb128> I can't access my emails either
[16:11] <seb128> ok, it's abck
[16:11] <seb128> back
[16:12] <jcastro> didrocks: have you guys seen this wrt oneconf? https://launchpad.net/stipple
[16:13] <didrocks> jcastro: yeah, we even talked before with duanedesign when she saw the OneConf initiative (it was before UDS)
[16:13] <jcastro> oh ok, rock
[16:13] <didrocks> jcastro: basically, OneConf will be the simple case, that most of our user expect
[16:13] <didrocks> stipple will be the CLI which will do what OneConf doesn't do
[16:13]  * jcastro nods
[16:15] <didrocks> jcastro: if you have some time, the OneConf backend is totally ready, with autoupdating too (but need a coming release of update-notifier)
[16:17] <jcastro> didrocks: my syncing is so unreliable I doubt I could be useful. However popey seemed keen to start playing with it.
[16:17] <didrocks> jcastro: ok, I'll see with him later :-)
[17:32] <jcastro> didrocks: did the amd64 builds of unity places and files get resolved? still missing for me
[17:32] <didrocks> jcastro: still missing? last time I check (on Monday), it was about building, let me finish current release first
[17:33] <jcastro> ok just wondering
[17:37] <didrocks> jcastro: they are built https://edge.launchpad.net/ubuntu/+source/unity-place-files/0.5.2-0ubuntu1/+build/1810913 and https://edge.launchpad.net/ubuntu/+source/unity-place-applications/0.2.1-0ubuntu1/+build/1810921
[17:37] <didrocks> jcastro: did you apt-get install them?
[18:06] <pitti> alpha-2 is out, go break the archive
[18:07]  * didrocks uploads :-)
[18:07] <chrisccoulson> heh, i can't believe how quickly this cycle has flown past me ;)
[18:08] <slomo> alf__: thanks
[18:54] <ogra> didrocks, so i finally managed to get netbook 2D up on arm, and i end up with two panels
[18:55] <ogra> actually with a desktop session that has the efl launcher as desktop
[18:55] <didrocks> ogra: yeah, that's the une 2D session, great :)
[18:55] <ogra> well, i'd like the old 2D session back :)
[18:55] <ogra> with one panel
[18:56] <ogra> and no menu etc
[18:56] <ogra> where is that gone ?
[19:04] <didrocks> ogra: you never had it in the -efl session
[19:04] <didrocks> ogra: it was the une one fallbacking to n-l-efl
[19:04] <ogra> hmm
[19:04] <didrocks> ogra: but you were in une session, not -efl
[19:04] <didrocks> ogra: I've proposed many times to create a settings package :)
[19:04] <ogra> so i need to create a proper session then i guess
[19:05] <ogra> well, i'll do that then :)
[19:05] <didrocks> ogra: yeah, you can have a look at the ubuntu-netbook-default-settings package
[19:05] <ogra> for A3
[19:05] <didrocks> (lucid one, not maverick)
[19:05] <ogra> right
[19:05] <didrocks> you will see which gconf key you need to change
[19:05] <didrocks> and I suggest moving the .desktop session file there too
[19:05] <ogra> where do you set the default session that gdm picks ?
[19:05] <ogra> currently thats pointing to unity for me
[19:06] <didrocks> ogra: I've made a script call /usr/lib/gdm/gdm-set-default-session
[19:06] <ogra> which i dont want
[19:06] <didrocks> called*
[19:06] <ogra> i'll check that, thanks
[19:06] <didrocks> ogra: look at ubuntu-netbook-default-settings, I execute it in postinst
[19:06] <ogra> ok
[19:06] <didrocks> in any case, do not hesitate :)
[19:38] <chrisccoulson> hmmm, libappmenu is making firefox crash like crazy :/
[20:00] <seb128> chrisccoulson: weird, tell tedg or bratsche
[20:09]  * tedg knows nothing bratsche is the guy there
[20:10] <bratsche> Yeah, it probably should not be loaded for Firefox.
[20:10] <lamalex> tedg: congrats on the baby
[20:12] <tedg> lamalex, Thanks, but not quite yet.  Gotta wait a few more weeks :)
[20:13] <lamalex> baby, almost-baby
[20:13] <lamalex> same thing
[20:13] <tedg> lamalex, Heh, tell my 8mo pregnant wife that -- she's ready to be done being pregnant :)
[20:13] <lamalex> haha
[21:32] <seb128> cassidy, hi, did you see bugs similar to bug #597556?
[21:32] <ubot2> Launchpad bug 597556 in empathy (Ubuntu) "Cannot complete Empathy add account wizard (affects: 2) (heat: 12)" [Low,New] https://launchpad.net/bugs/597556
[21:33] <seb128> didrocks, ^ could you try this one tomorrow to make sure it's not a breakage in the sru update which just went to lucid-updates?