[01:03] TheMuso, can you sponsor libgweather from bzr? [01:04] robert_ancell: sure thing [01:16] robert_ancell: I don't seem to have /usr/share/cdbs/1/class/python-autotools.mk on my system, and installing libgweather's build dependencies doesn't grab it either. Do you know what package its from? [01:22] TheMuso, Mavericks cdbs [01:23] oh ok [01:23] makes the debian packages _so much better_ but yeah, can't build them on Lucid [01:23] * TheMuso uses a chroot then. [01:34] RAOF, bryceh: How fast can you get an xserver to start on boot? [01:35] robert_ancell: You mean - what service dependencies does the xserver have? [01:36] robert_ancell, depends on hardware [01:36] both dependencies and what the state is now - i.e. is lucid booting x as fast as it can? [01:37] robert_ancell, if you mean "is there anything we can change in xserver to make the xserver portion of the boot faster", I think we pretty much squeezed everything out of it we knew to do [01:38] robert_ancell, however if you mean "Are there other things in the boot process that could get us to a working X session faster"... maybe, I'm not sure there though. [01:38] You could start X sooner in the boot if you didn't have to start it from gdm. I'm not sure how useful that would be, though. [01:38] bryceh, so how long does it take to start on a cut down system, e.g. a dell mini [01:39] I'm asking because I've been working on a new display manager which is as fast as possible. I was wondering how fast you could get X running so then you could run an X app as the boot splash [01:39] robert_ancell, xserver itself takes a second or two on a dell mini with ssd (exact time varies boot to boot, but seb128 and scott had some detailed numbers as proof) [01:39] robert_ancell, if you use xdm and boot into a non-gnome X session using the -vesa driver, you can get things up and running in about a second [01:40] maybe less [01:40] nice, that would be fast enough. run a static image on the fb before that [01:41] robert_ancell, also there is a timing patch floating around for xserver (check the debian/patches/ dir, I think it may be just commented out) [01:41] robert_ancell, if you are able to use fbdev, that may give equivalent performance as vesa [01:42] I'd want to use the same drivers as the desktop would run on, so you don't have to reload anything later in the boot [01:42] ah gotcha [01:43] ok, was going to mention some other "well if you can lock down the hardware, then you can drop..." [01:43] bryceh, robert_ancell: The upstream server now timestamps its logs, as of 1.8. [01:44] RAOF, know if that patch is backported to lucid? (and if it's better than the one we were toying with last release?) [01:44] I certainly haven't backported it to Lucid. I'm not sure if it's been backported to 1.7 [01:45] mm [01:46] anyway, I had gone through the timing data myself and didn't spot any obvious optimizations we could do, so might not be worth the trouble, but patches are available if xserver boot seems slow [01:47] robert_ancell, these days a lot of the goopy stuff amenable to optimization (like edid probing) is done in the kernel side via kms [01:47] ok [01:48] edid caching is a big win, and that's a kernel thingee [01:48] no we can squeeze at least another 400ms out of the xserver startup time by dropping the pci vendor and card name lookup [01:48] it's probably worth testing to be sure it's functioning properly [01:48] Sarvatt, well that's what I was going to mention when I said "if you can lock down the hardware"... ;-) [01:48] which will probably be done in 1.9 [01:48] Sarvatt: We'll pick up those patches for free in 1.9 [01:49] ooh, that sounds nice [01:49] Sarvatt, robert_ancell: but that depends a lot on if you are going to always know ahead of time what the hw is [01:49] its parses the huge pci id list just for mapping the vendor/device name at the very start, the driver prints its own identifying message so its not really useful [01:50] Sarvatt, can you link robert_ancell the patch for that? [01:50] bryceh: No, this is basically just for printing the vendor ID (which most of the DDXs do anyway, in a better way) in Xorg.0.log. [01:50] just the one line - [ 6357.749] (--) PCI:*(0:1:0:0) 1002:94c3:174b:e370 ATI Technologies Inc RV610 video device [Radeon HD 2400 PRO] rev 0, Mem @ 0xd0000000$ [01:50] ah [01:51] http://patchwork.freedesktop.org/patch/989/ http://patchwork.freedesktop.org/patch/990/ [01:55] robert_ancell: uploaded [01:56] it's about 400ms for the lookup here on my netbook, about 150ms on a faster core 2 [01:57] robert_ancell: What is this display manager you are working on? [02:01] TheMuso, lp:lightdm [02:01] ah ok [02:01] it's pre-alpha at the momeny [02:02] moment [02:05] ok [03:29] Would anyone like to sponsor a mesa upload? http://cooperteam.net/Packages/mesa_7.8.1-3ubuntu1_source.changes and http://cooperteam.net/Packages/mesa_7.8.1-3ubuntu1.dsc . I'm going to have some lunch, so if anyone wants to sponsor it I'll be back at about the time your build has finished :) [03:38] RAOF: will take a look. [03:38] Ta. [04:15] RAOF: should do libdrm first? [04:27] Sarvatt: Doh! Of course! [04:27] Stupid local packages. [04:28] That said, mesa builds fine against 2.4.20 [04:30] RAOF: should I wait? [04:30] Let me double check. I _think_ it doesn't matter. [04:31] RAOF: ok [04:32] TheMuso: You can proceed. Mesa builds fine against 2.4.20, and doesn't use any symbols from 2.4.21 as determined by the dpkg dependencies. [04:33] RAOF: ok [04:33] the mesa change is insanely huge to review TheMuso, I'm sorry and thanks for doing it :) [04:33] Sarvatt: np [04:34] We'll want the new libdrm for a new -intel DDX, but that can wait and doesn't need to block mesa. [04:34] speaking of which i should update that in debian [05:05] RAOF: uploading [05:13] Who pinged me? Things are a little bit weird with the electricians rewiring stuff. [05:16] 15:34 < RAOF> We'll want the new libdrm for a new -intel DDX, but that can wait and doesn't need to block mesa. [05:16] 15:34 < Sarvatt> speaking of which i should update that in debian [05:16] 15:59 -!- tedg [~ted@pool-71-96-212-220.dfw.dsl-w.verizon.net] has joined #ubuntu-desktop [05:16] 16:05 < TheMuso> RAOF: uploading [05:16] 16:05 -!- RAOF_ [~RAOF@ppp105-211.static.internode.on.net] has joined #ubuntu-desktop [05:16] 16:13 < RAOF_> Who pinged me? Things are a little bit weird with the electricians rewiring stuff. [05:16] lifeless: Thank you, valiant IRC proxy. === almaisan-away is now known as al-maisan [05:46] TheMuso, can you sponsor poppler from bzr? [05:47] Sure. [06:10] robert_ancell: uploaded [06:10] TheMuso, thanks [08:03] good morning [08:03] RAOF: hey, did you see my question about nvidia? [08:04] didrocks: Good morning. I did not see your question, no. [08:04] Would you like to fix it by sponsoring a rebuild of nvidia-graphics-drivers? :) [08:05] lol [08:05] Good morning [08:05] RAOF: that maybe the cause of that, right: http://paste.ubuntu.com/449524/ ? [08:06] didrocks: Yes, exatly. [08:07] RAOF: if you have something to be sponsored, I will be pleased to do so :) [08:08] didrocks: http://cooperteam.net/Packages/nvidia-graphics-drivers_195.36.24-0ubuntu2_source.changes is available for your sponsoring pleasure. [08:08] RAOF: sweet :) [08:11] * TheMuso worked on the 185 variant at some point in the past, the packaging is interesting. I refer more so to now NVIDIA package the drivers than the Ubuntu/Debian/dkms packaging. [08:11] hello [08:13] RAOF: signed and uploaded for your (and mine) pleasure :) [08:13] thanks [08:13] baptistemm: salut! [08:17] salut didrocks [08:18] desrt, ping [08:19] hey robert_ancell, how are you? [08:19] didrocks, hey, good [08:21] hey robert_ancell, good morning didrocks [08:21] Ok. I'm off to the hardware store to buy some lights for the electricians to put in tomorrow. I think seb's looking for me; I'll be back on later this evening. [08:21] Guten Morgen pitti, how are you? [08:21] splendid, thanks [08:26] hey there [08:27] salut seb128, ça va ? [08:27] fta: your script rocks, thank you! http://sarvatt.com/xorg-edgers/ [08:27] lut didrocks, nickel, et toi ? [08:28] seb128: ça va bien, merci :) [08:28] so mclasen started trolling as well [08:29] robert_ancell, hey [08:30] seb128, morning [08:30] robert_ancell, how are you today? [08:30] busy :) [08:30] robert_ancell, to reply to your email, new poppler depends on cairo 1.9 [08:30] do you think we should update cairo? [08:30] I had that discussion with upstream yesterday [08:31] didrocks, seb128: are bug 528557 and bug 229187 fixed in maverick? I can't copy the lucid-proposed [08:31] they plan their next stable in august [08:31] Launchpad bug 528557 in evolution (Ubuntu Maverick) (and 3 other projects) "cannot turn on alarm for meeting received via email (affects: 4) (heat: 28)" [Low,Fix committed] https://launchpad.net/bugs/528557 [08:31] Launchpad bug 229187 in evolution-data-server (Ubuntu Lucid) (and 2 other projects) "Evolution mailing list does not render accents correctly (affects: 3) (heat: 22)" [Low,Fix committed] https://launchpad.net/bugs/229187 [08:31] but they did plan it in january before [08:31] I would say yes, as long as they don't plan anything crazy [08:31] so I don't really trust them for their schedule [08:31] other distro had to go back to cairo 1.8 previous cycles [08:32] pitti: it's in trunk, we still didn't upload the new version there, but in any case, I'll keep an eye on them [08:32] seb128, hmm, annoying [08:33] cairo 1.10 is a myth! :) [08:34] robert_ancell, upstream would like us to get the new cairo in the xorg-edger ppa for testing [08:34] robert_ancell, if you are interested to get that happening ;-) [08:34] seb128, If there's no specific reason for upgrading, and a risk of it not being ready we should hold back [08:35] I'm willing to do the packaging [08:35] it's in debian experimental [08:35] so it's basically merging our lcd filter change [08:35] I think getting it in the xorg-edget ppa would be a nice start [08:35] it would be there for testing with other xorg edge versions [08:36] I'll put it on the low priority list, and have a look if everything else is working [08:36] is it? i'll put it in the ppa then, i've been building it seperately for over a year now [08:36] robert_ancell, do you read d-d-l? [08:36] Sarvatt, that would be nice, thanks! [08:36] seb128, no [08:36] robert_ancell, ok, that's wise ;-) [08:37] seb128, yes, I had heard legends of how much time it takes to read, so I've never bothered to subscribe [08:37] the lcd filter stuff won't apply i'm sure though [08:38] Sarvatt, so it needs to be updated to apply ;-) [08:45] pitti, what didrocks said [08:46] didrocks: ok, thanks [08:57] ok [08:58] I replied to mclasen troll [09:00] * didrocks didn't read d-d-l still today [09:01] not missing anything [09:03] he's trolling us for shipping desktopcouch and saying that shipping 2 gtk versions is a CD space issue [09:03] then trolling us for not shipping GNOME3 this cycle [09:03] urgh :/ I'm not eager to read this, preferring working first, that's more positive [09:03] saying that we basically don't contribute to it but work on ayatana things at the same time and that we should stop pretending [09:04] how nice this is… [09:04] didrocks, ignore the troll ;-) [09:05] hrmm? where's this post? [09:07] desktop-devel-list [09:07] pitti, if your libusb upload fixes the crash we talked about before lucid that would rock really [09:11] later all [10:14] morning [10:34] seb128: You wanted to talk about my work-items? They might look slightly more scary than they are. I've knocked off two of the bigger ones today, a number of them are for tools outside the archive which won't be affected by the A2 freeze, and some more are documentation WIs. [10:36] hey RAOF [10:36] RAOF, well, we are mid milestone and you have ticked 2 items on 21 [10:36] the maths says you are well behind so I wanted to check if we should delay things ;-) [10:37] it seems those are mostly small tasks though [10:37] so you might have them under control but I wanted to check with you [10:37] Yup. I've now got 4/21 done, and the X server transition is done, as is mesa. [10:37] I also wanted to know if you are tracking the kernel team items [10:37] I've noticed, great work on the transitions btw! [10:38] I haven't been tracking the kernel team items very closely, just every now and then. [10:39] ok [10:39] those seems investigation rather than maverick changes [10:39] could you still try to get an update to know if they still have those on their radars? [10:39] no hurry, when you have time in the next week [10:40] I'll talk to apw. There are a couple of maverick changes that could come as a result of their investigations. [10:40] RAOF, do you need some help on anything or should we look at moving some work items to alpha3 or do you think you have things under control? [10:40] I think I've got things under control. [10:40] ok, great [10:41] I was mainly checking in case you need help or to have some item rescheduled [10:41] RAOF, thanks [10:41] http://people.canonical.com/~pitti/workitems/maverick/canonical-desktop-team-maverick-alpha-2.html [10:41] we are on the trend line today ;-) [10:41] The biggest remaining WI deliverable to the archive is the -intel DDX for i8xx cards, either forward-porting an old DDX and throwing it in universe or re-adding an old codepath to the new DDX so that 8xx cards don't die. [10:43] ok [10:43] seems wayland could be quite some work as well [10:43] Wayland is the thing most likely to slip, yeah. [10:43] that would be fine, we don't rely on it for maverick [10:43] so if we get it a bit later that's fine as well [10:43] Right. It's only going to end up in a PPA for developers to play with. [10:44] and other changes seem mostly investigation, talking to other people, updating tools and documentation [10:44] There's at least one intel hacker interested in re-introducing an old, non-flaming-death codepath for the poor old i8xx cards, so we might get a better outcome than we were dreading at UDS :) [10:44] That's right. [10:44] which shouldn't be an issue either for alpha2 [10:44] RAOF, nice for the i8xx cards ;-) [10:45] RAOF, anyway it seems things look good for alpha2, great work [10:45] Ooh! Dinner has been called! [10:45] RAOF, thanks for the update [10:45] RAOF, enjoy your dinner [10:45] Catch you later :) [10:45] see you [10:45] [10:45] ok [10:46] who knows hiw way with dh7 there? [10:46] how do you make it call dh_girepository [10:46] ? [10:47] seb128: as an addon? or in a particular package? [10:47] pitti, in a package [10:48] if you wnat to run it after e. g. dh_install, you could write something like [10:48] override_dh_install: [10:48] dh_install [10:48] dh_girrepository [10:48] thanks [10:48] trying that [10:49] seb128: "man dh", FTR [10:52] pitti, thanks, I tried man dh7 and man debhelper [10:53] the first one didn't work and the second didn't have what I wanted [11:19] ickle seems open to taking that lcdfilter patch for cairo upstream by the way [11:20] (Chris Wilson) [11:28] Sarvatt, oh, nice [11:28] it was briefly upstream [11:28] and they reverted it because it was breaking some testsuite cases [11:29] that was before 1.8 [11:44] Riddell: hey, can you ping me and alf__ when you have a few minutes to talk about qt and embedded packaging ;)? [11:45] asac: ping [11:52] Riddell: hey [11:52] Riddell: so ... we are thinking what we can do for qt-embedded packaging this cycle ... and of course need your input on our ideas [11:53] Riddell: so qt-embedded needs a different soname - upstream said they will suggest one so that fine. i wonder if you would feel comfortable to make a two run build out of the qt package [11:53] or rather want this to live in a separate source package (copied source) === cking_ is now known as cking [12:05] asac: my initial thought is that qt takes quite long enough to build as it is so separate source packages would be best === MacSlow is now known as MacSlow|lunch [12:22] Riddell: so ... our idea is to make the basic embedded qt stack available in the archive, but then run a ppa for now that has the apps ported to it (probably until lighthouse comes out ... which upstream said they will do a proper sonaming for etc) [12:23] Riddell: however, i wonder if there some kind of "inner-ring" libraries that you would think are essential and we should also make available as embedded packages [12:24] asac: do you have paticular apps in mind? [12:24] asac: qtwebkit is split out into a separate source package in maverick so that's an obvious inner-ring [12:24] possibly phonon too since that's a supported Qt API [12:24] Riddell: havent decided on that yet; we first want to bring the dev/sdk environment up to speed [12:24] Riddell: but alf__ tested a few qt apps and they apparently just built and worked [12:25] we havent went up to kde yet obviously [12:25] guess kdelibs would be inner ring too ;) ... though i doubt thats really easy to do ;) [12:25] alf__: ^^ ... so we should also keep qtwebkit in mind and phonon [12:25] Riddell: did the qtwebkit split already happened? [12:26] yes [12:26] Riddell: do you expect that the libs etc. from maverick are easy to backport for lucid (during alphas having alucid packages for arm often helps as there are times where you cannot produce images etc. from the moving dev release) [12:27] asac: they're easy to backport yes, we have backports in kubuntu-ppa/beta for KDE 4.5 beta backports [12:27] great. that makes things even easier [12:27] Riddell: should i send alf__ to you or someone else from your team for reviewing/sponsoring when he is done with the qt-embedded lib etc.? [12:28] (i will take a first look before, but i think its better if some "qt" expert does the sanity checking) [12:29] asac: sure, he's always welcome on #kubuntu-devel [12:30] nice ;) [12:31] didrocks: do you have good connections to mutter devs for upstreaming? [12:32] asac: I 've post some patches to them, but I don't personnally know them, why? [12:32] didrocks: just wonder if we have an established channel or if should rather go on my own ;) [12:32] asac: you can go on your own, will be the same than me trying :) [12:33] heh ok [12:51] mdz, hi, you asked on design.canonical.com why Ubuntu didn't offer to install Flash for the user test participants. The answer is bug 161818. [12:52] Launchpad bug 161818 in ubufox (Ubuntu) "firefox flash-plugin automatic installation fails on youtube (affects: 6) (dups: 2) (heat: 46)" [Wishlist,Triaged] https://launchpad.net/bugs/161818 [12:54] mpt: hey, did you have some time to work on oneconf USC design yesterday? [12:55] didrocks, no sorry, it was #3 on my list and I didn't get to it, but it's now moved up to #2 [12:55] yeah \o/ ;) [12:56] mpt: no worry, it was just to get this moving as alpha2 is pretty closed now. As long as you can give it a look this week, it will be ok, I hope :) [12:57] mpt: ah, thanks. so they always encountered flash first on Youtube, eh? [12:58] mdz, I don't know (I wasn't in the test), but the bug affects people visiting any Web site that uses Adobe's recommended method of detecting Flash. [12:58] Not just YouTube. [13:00] mpt: do you have a link to those recommendations? [13:00] soren, it's in the bug report [13:01] mpt: ah, thanks. [13:01] test [13:05] mpt: So it seems that people always get pointed to http://get.adobe.com/flashplayer/. Perhaps we could intercept people's attempts to access that and offer them the better way? [13:07] soren: some kind of "if url ==". That sounds sweet :) [13:08] didrocks: one question: why is mutter packaged as a native package :( [13:10] soren, ideally we'd intercept it earlier than that, but that would certainly be better than nothing. [13:10] asac: hum, you mean? the version is 2.31.2-2ubuntu3 and the debian directory is in mutter_2.31.2-2ubuntu3.diff.gz, no? [13:10] didrocks: whatever i copied from the unity ppa was a native package :( [13:11] if you say its ok in archive then i am fine ;) [13:11] asac: previous one was, because of dx packaging, but last one shouldn't, let me check [13:12] asac: hum, ok, I didn't push the last version to the UNE ppa (it's the same level of patch though), so yeah, it was native for dx daily build as patch inlined [13:13] asac: I will update this Thursday mutter in the UNE ppa with maverick version. Same level of functionality (same patches), but at least, a real working version [13:13] ok let me know. i will happily adopt that ;) [13:14] didrocks: is there a good way to test mutter without unity that you would suggest? [13:14] asac: you can run it into your GNOME session with mutter --replace [13:14] ok will try that [13:14] wonder what happens if i do that in efl ;) [13:15] that can be nice to test ^^ [13:15] didrocks: how can i re-replace that back? [13:15] metacity --replace? [13:15] maybe in a tty is safer for killing the process easily with DISPLAY=:1 [13:15] right [13:15] heh [13:15] or even compiz --replace if you trust the non working 3D card :) [13:16] dont ask for too much ;) [13:24] yay [13:24] it works!!! [13:24] artifacts and weird focus issues [13:24] but it works ;) [13:25] not really that many artifacts; just the mouse pointer/caret has a background colored box around it and isnt transparent [13:27] asac: sounds awesome :) [13:27] asac: how does the shiny effects are behaving? [13:28] not too slow? [13:28] didrocks: i dont know if i see the shiny effects ;) [13:28] asac: you have some zoomout/zoomin while reducing/maximizing windows [13:29] didrocks: hmm. i have -efl... there is no minimizing [13:29] asac: closing maybe? you have a zoom out IIRC [13:29] now my board hangs ;) [13:29] (on the window itself) [13:29] urgh :-) [13:29] let me reboot and try to log into a gnome session or something [13:29] wonder if i have gnome session installed [13:30] (this thing only has 256m) [13:30] hum… let's cross the fingers it will start ^^ [13:31] yep === MacSlow|lunch is now known as MacSlow [13:42] didrocks: zooming in and out works with desktop session ;) [13:42] asac: awesome! :) [13:42] but killing mutter kills the board reliably ;) [13:42] * didrocks cross fingers for unity to behave the same so :) [13:42] argh :) [13:53] for unity we have to make clutk a decent piece of software first ;) [13:55] asac: ask to njpatel :) [13:56] didrocks: already did. he redirected me to jay ;) [13:56] ahah ^^ [13:56] but jay seems to hide today ;) [13:56] as if he knew what was coming [13:57] don't trust French people running away from France, they can feel when things can go badly for them :-) [14:00] seb128: rhythmbox upstream has a fix in trunk for the crash we saw yesterday [14:00] didrocks, a workaround, yes [14:00] didrocks, the issue seems a pygobject one [14:01] right, a workaround [14:01] didrocks, don't bother backporting it [14:01] I will do a rhythmbox snapshot update in the next days [14:01] seb128: ok, perfect! Thanks :) [14:01] np [14:01] didrocks, thank you for bringing that upstream and the f-spot issue as well [14:01] and yes I'm watching you ;-) [14:01] chrisccoulson, seb128: so what's the status of firefox and those langpacks? do I have a todo item for copying those to -proposed/-updates or who will? [14:01] * didrocks returns and look at his back [14:02] pitti, they need to go to security [14:02] seb128: no, you aren't there! How do you do? [14:02] didrocks, ;-) [14:02] pitti, but when firefox 3.6.4 will be available from mozilla which is still not the case I think? [14:02] chrisccoulson, ^ [14:02] seb128: ok, so those are on hold for now; the copying to the moz ppa was done, I take it? [14:03] pitti, I would appreciate if you could do the copy on time [14:03] pitti, yes [14:03] pitti, they are in the moz ppa right now [14:03] pitti, they will be copied with the security update [14:03] seb128: I can, but I'd appreciate if someone could poke me when ffox gets copied over [14:03] I guess jdstrand or whoever does the copy will copy all together [14:03] seb128: it'd be the very same process as copying ffox itself [14:03] right, that seems easiest [14:04] instead of doing it by two different persons, I mean [14:04] pitti, so no todo item for you ;-) [14:04] ok, thanks [14:04] I was just wondering what to do with ArneGoetje's mails, but seems that it's being handled [14:04] * pitti hugs you all [14:04] you see, nobody is missing me :) [14:04] * seb128 hugs pitti [14:04] oh, we do! [14:05] * didrocks hugs pitti, we miss you [14:05] pitti, but good point about ArneGoetje's emails, chrisccoulson said he would reply to those some days ago [14:06] chrisccoulson, ^ did you copy the extra langpacks from those emails to the mozilla ppa? could you reply to the email saying where we stand with those updates? [14:06] seb128: I did reply with "waiting for fffox to go to -security" [14:07] thanks [14:07] robert ancell and myself are in incredibly incompatible timezones... [14:07] hey pitti - i don't think you need to do anything with the langpacks do you? they're currently in the u-m-s PPA, and they just get copied to -security with the security update don't they? [14:07] (i think that's how it's working) [14:08] chrisccoulson, right, that's we concluded as well there [14:08] seb128 - i uploaded those extra langpacks but forgot to send an e-mail ;) [14:08] chrisccoulson, could you confirm you did grab the updated ones ArneGoetje listed some days ago? [14:08] chrisccoulson, ok [14:08] chrisccoulson, no news of the update from mozilla yet? [14:08] not yet, but i think it will happen quite soon [14:09] i'm hoping to have karmic in a state that can be tested by tomorrow [14:09] ok [14:33] tremolux, hey [14:34] rickspencer3: hey Rick [14:34] tremolux, I see mpt created a design for new apps [14:34] and you have a work item to implement it [14:34] does it seem feasible to get it done for A2? [14:36] rickspencer3: looking [14:40] rickspencer3: yep, it's feasible for A2 [14:41] sucks not being able to read twitter dev docs because of fail whale! === al-maisan is now known as almaisan-away [14:46] rickspencer3: I should qualify that; we may not have it pixel-perfect for A2, but to have the section there displaying the apps should be doable [14:47] tremolux, could you add a work item such as "refine implementation to match specs" to A3? [14:47] rickspencer3: yes, good idea [14:49] hey kenvandine, have you been following the twitter api thing ryan is concerned about? [14:51] hello everyone [14:51] hi nessita, 'sup? [14:52] rickspencer3: hey there! just now I remember chipaca told me to talk with you about the agenda in the next sprint in prague [14:53] seb128: about the package I uploaded yesterday (ubuntu-sso-client), do I have to do any further steps? I uploaded an update to https://code.launchpad.net/~nataliabidart/ubuntu/maverick/ubuntu-sso-client/maverick [14:53] jcastro, yes... we are stressed about getting that resolved and SRU'd [14:53] seb128: would you be able to sponsor it? [14:53] rickspencer3: not sure what "talk about the agenda" means, but maybe you know :-) [14:54] I don't know :/ [14:54] nessita, hi, sorry I'm quite busy with other things right now [14:54] seb128: no problem, would you know who can be able to do it? [14:54] rickspencer3: heh, I ask Chipaca then [16:09] Sarvatt, excellent. let me know if you have ideas to improve it, or if you need more info on the page [16:11] I'm having a problem with empathy client crashing on incoming voice calls (but not outbound) [16:12] someone suggested upgrading libpurple, another libtelepathy -- do you know if I should try one, or the other, or both? [16:13] alf__: I would say, don't bump the ABI if upstream doesn't do it. Can you convince them to remove the exposal of json_*, force the external dep and so bump the soname? [16:14] Sarvatt, i will probably add a popup for the Repositories, instead of just an "X". and i probably need to cache the data between sessions, so it's faster to update. btw, how often do you update it? [16:16] well I'm just going to guess [16:17] didrocks: I can try :) but I don't expect they will. According to them, the internal json-glib is not supposed to be used by distributions. [16:17] alf__: another solution is to look at rdepends :) [16:17] blue_anna: try on #ubuntu [16:17]