[00:33] these ffmpeg-extras packages are a nightmare, libswscale-dev was uninstallable because it depends on libswscale0 | libswscale-extra-1 (which isn't a package) [00:36] doing a no change rebuild of gstreamer0.10-ffmpeg against the newer libavutil now though to see if thats all thats needed to fix it [00:44] Sarvatt: If thats all thats needed, let me know and I'll upload it for you. [00:46] xvid's work again! \o/ gstreamer0.10-ffmpeg just needs a no change rebuild against the newer libavutil-dev [00:47] Depends: libavcodec52 (>= 4:0.6~svn20100505-1) | libavcodec-extra-52 (>= 4:0.6~svn20100505-1), libavformat52 (>= 4:0.6~svn20100505-1) | [00:47] libavformat-extra-52 (>= 4:0.6~svn20100505-1), libavutil50 (>= 4:0.6~svn20100505-1) | libavutil-extra-50 (>= [00:47] 4:0.6~svn20100505-1), libc6 (>= 2.7), libglib2.0-0 (>= 2.24.0), libgstreamer-plugins-base0.10-0 (>= 0.10.22), libgstreamer0.10-0 [00:47] (>= 0.10.24), liboil0.3 (>= 0.3.6), libpostproc51 (>= 4:0.6~svn20100505-1) | libpostproc-extra-51 (>= 4:0.6~svn20100505-1), [00:47] libswscale0 (>= 4:0.6~svn20100505-1) | libswscale-extra-0 (>= 4:0.6~svn20100505-1) [00:48] TheMuso: well there might be something else up with it, I pinged siretart about it [00:48] Sarvatt: ok. [00:51] libavutil.so.50 => /usr/lib/i686/cmov/libavutil.so.50 (0x00111000) after a rebuild, before /usr/lib/gstreamer-0.10/libgst-ffmpeg.so was looking for libavutil.so.49 => not found and the libavutil-extra-49 package is empty [00:52] and the codec installer wouldn't work because the empty package was installed already so it didn't find anything to install === jono_ is now known as jono [03:06] TheMuso, can you sponsor glib? [03:06] Sure. [03:38] robert_ancell: uploaded [03:38] TheMuso, thanks [03:38] np [03:42] Can someone check for me that /var/log/dmesg is readable only by root and the adm group on your system? [03:43] RAOF: yep [03:43] Cool. More apport bugs! [03:47] Hi! I need help with my Dell Latitude [03:47] please indicate to me which version of ubuntu I need to install [03:49] ravibn: This isn't a support channel; #ubuntu or ubuntuforums.org are better places for support. That said, the most recent Ubuntu release is almost always the best, particularly since Ubuntu 10.04 is a long-term-support release. [03:50] I tried that forum and also the latest 64bit LTS THe machine would not even boot [03:52] RAOF : my latitude has core i7 720QM cpu (i686 ) with nVidia 3100 nvs [03:53] RAOF : I want to understand whether the server version (10 LTS) supports the i686 [03:54] RAOF : I mean 64bit version of ubuntu [03:55] It does. You might be having problems because of your… ok. === oubiwann is now known as oubiann [06:54] good morning [06:56] Bonjour didrocks :) [06:59] hey nigelb :) [07:12] ls [07:12] Ahem. Focus fail! [07:13] heh [07:14] Now that I've got a second monitor hooked up again I want a head-tracking dohicky to ensure the focus is always on the screen I'm looking at :) [07:16] lol [07:17] RAOF: how about dual touchscreens? :-) [07:18] We need xserver 1.9 for that so that we can apply transformations on the device inputs! [07:19] Who feels invigorated to upload a little xorg with an updated apport hook? http://cooperteam.net/Packages/xorg_7.5+6ubuntu2_source.changes [07:28] * TheMuso is working a little early today, so is out of here in a minute or so, so don't have time sorry. === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === oubiann is now known as oubiwann [08:19] hey there [08:32] Good morning [08:32] hey pitti [08:32] pitti, how are you? got a better night? [08:32] bonjour seb128 [08:32] seb128: absolutely, I slept well [08:33] mvo: hi [08:33] nice ;-) [08:33] cjwatson and I hacked until 1, but then I allowed myself to sleep in until 9 :) [08:33] mvo: can i just confirm the plan for debfile.py? [08:33] hey kiwinote [08:33] good morning [08:33] kiwinote: let me check the mail [08:34] hey mvo [08:34] kiwinote: yep :) [08:34] hey seb128 [08:34] kiwinote: its a bit of a historc thing, please make sure you get the latest gdebi trunk that includes the python-0.8 port changes [08:35] kiwinote: and it may be worthwhile to convert some of the tests to be run automatically, but I will leave that you to decide [08:35] mvo: so first I merge the files from gdebi and python-apt, keeping the 'shape' of the python-apt file, but grabbing the functionality from gdebi [08:35] kiwinote: yeah [08:35] mvo: and then i port gdebi to use python-apt rather than it's own debfile class? [08:35] kiwinote: correct [08:35] kiwinote: its going to be a bit of work I imagine :/ [08:36] mvo: ok, thanks [08:36] kiwinote: let me know if I can help in any way [08:36] mvo: will do [08:36] seb128: I run your upgrade test currently [08:36] seb128: triggered a bug in *my* code ! [08:36] seb128: bad boy [08:37] mvo, lol [08:37] * seb128 hugs mvo [08:37] :) [08:37] * mvo hugs seb128 [08:37] all good, SRU for it is almost ready [08:38] mvo, speaking of which you should join the sru team [08:38] * mvo nods [08:39] that is probably a good idea, but I already feel that I'm not on top of things without another thing to look after [08:39] pitti, ^ [08:40] mvo, well it's load balancing, while pitti is on rotation and slangasek moving team we are pretty much blocked on sru reviews [08:40] mvo, I'm pondering joining as well, but that wouldn't unblock my issue which is that my stack of desktop uploads need review ;-) [08:41] I'll do some this morning [08:41] but I (or, rather, OEM) really needed that hackathon in the past three days, sorry [08:44] seb128: ok, let me see how the buy-something progress of today goes and if it looks promising I can do some on monday === oubiwann is now known as oubiann [08:45] pitti, slangasek did 3 of those yesterday which is something ;-) === oubiann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [08:45] pitti, thanks for doing that, still if mvo and I join that will help balancing load [08:46] pitti, ie for next round if that's not this one [08:47] absolutely, that'd be great [08:54] mvo, s-c hates unity [08:54] seb128: ha! I'm sure its the other way around ;) [08:54] seb128: s-c is build with extra-love inside [08:54] mvo, no, if I type "unity" in the search entry in s-c maverick it lists nothing [08:54] hum same for "gnome" [08:55] ok, so maybe the index is broken or something [08:55] seb128: that's fixed in trunk [08:55] kiwinote, thanks [08:55] *cough* [08:55] I should do a new upload, but yeah, trunk works and unity is #1 hit [08:56] mvo, ok, in fact it works if I select something else than "get softwares" [08:56] well it does list other things before unity [08:56] but it does list things ;-) [08:56] mvo, do you plan to do an upload before a2? [08:56] yes [08:56] definitely [08:56] lots of good stuff inside [08:58] mvo, upload upload upload! [08:58] :) [08:58] ;-) [08:59] mvo: speaking of things hating each other, apt officially hates me [08:59] I've done like 10 followup commits, and it's still not perfect [08:59] works with everything else now, but apt-xapian-index is still taking infinite time (literally) [08:59] so I need to track that down as well; please ignore the MP for now [08:59] pitti: ok [09:00] but I learned a lot about apt's inner workings :) [09:00] pitti: I can imagine :) [09:01] seb128: btw, I added support for "do-release-upgrade -d" from lucid -> maverick directly now [09:01] (you asked IIRC) [09:01] (and others too) [09:01] mvo, indeed, thanks [09:02] np [09:19] didrocks, ok, normal update-manager maverick upgrade works and bring it unity places binaries [09:19] seb128: sweet \o/ thanks for testing :) [09:20] those places are quite slow to display icons though [09:20] it takes over one second with blank icons and then screen is changing to real colored icons [09:20] seb128: yeah, known issue [09:21] seb128: kamstrup told there are low hanging fruit to fix that [09:21] also, there isn't any preferences/settings [09:21] right [09:21] and it doesn't take XDG_CONFIG_DIRS into account [09:21] still it's very nice [09:21] but for a first iteration, it's not bad at all :) [09:24] didrocks, there is no way to get the expose mode now with those places? [09:24] seb128: I think not, it's hidden right now with the ws switcher which has no ui [09:25] ok [09:28] thanks for pointing me to unity-places-* - i was wondering what that empty black screen is all about :P [09:43] morning [09:54] morning huats [09:54] morning didrocks ! [10:03] seb128: so the original error seems to be fixed with your upload, but now I get "Atk-1.0.gir" as a addtional file overwrite error (from libatk1.0-dev" - known issue? [10:04] mvo, bug #547244 I guess [10:04] Launchpad bug 547244 in atk1.0 (Ubuntu) "package libatk1.0-dev 1.29.92-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/share/gir-1.0/Atk-1.0.gir', which is also in package gobject-introspection-repository 0:0.6.5-0ubuntu1 (affects: 6) (heat: 54)" [Low,New] https://launchpad.net/bugs/547244 [10:04] (libatk1.0-dev <-> gobject-introspection-repository) [10:04] seb128: yeah, sounds like it [10:05] seb128: I wait until its finished, but I think #574837 is verfication-done [10:05] mvo, thanks [10:06] mvo, I will get the atk issue on the .1 lucid buglist [10:06] thanks [10:12] mvo, the atk bug is milestoned for lucid .1 and assigned to TheMuso now [10:13] TheMuso, I've assigned you that atk replaces issue, would be nice to fix when you update atk to the current stable, thanks [10:35] didrocks, huats: do you know when our anjuta package gets libanjuta-dev? or should packages waiting on it get changed to use anjuta-dev? [10:36] geser, when somebody does the merge on debian I guess? [10:37] geser, you are welcome to do it if you want [10:37] seb128, I can try to handle it otherwise later today or monday [10:38] hey huats [10:38] if you want to do it you are welcome ;-) [10:39] seb128, I know I know... and you have not idea how much I'd like to do it... [10:39] I am just lacking time :( [10:39] but I still hope :) [10:41] huats: didn't you take some tasks already last week? [10:41] huats: reviewing and integrate patches IIRC [10:41] didrocks, yep [10:41] I had [10:41] huats: don't take too much on your plate :) [10:41] but I should have much time starting monday [11:01] mvo: would I be right in assuming that the cache file from python-apt is more complete/actively developed, but that it is still missing functionality from the gdebi cache file? [11:02] kiwinote: that is possible, if so I think we should also port the missing bits (if they make sense). whats bits are that in particular? [11:03] mvo: gdebi's debfile was calling cache.getProvidersFor(), but I can't find an equivalent for that in python-apt's cache [11:04] kiwinote: right, lets move it over then :) [11:04] mvo: ok ;) [11:12] mvo: u-n's autogen.sh says "do not use gnome-autogen.sh as long as it's broken"; it works fine in current lucid, do you happen to remember what was broken in particular? [11:14] mvo: but in fact merely using autoreconf works just fine, and that's the upstream recommended way now [11:14] mvo: would you mind if I clean that up a bit? i. e. using autoreconf, move to configure.ac, etc. [11:14] * pitti is in cleanup mood [11:18] oh, it is already [11:18] just with an extra bunch of stuff [11:19] seb128, hello [11:19] seb128, may I point you to #389766? [11:20] seb128, should the gconf defaults be shipped with gnome-settings-daemon or with packagekit? [11:21] seb128, g-s-d detects an installed packagekit and tries to load the font installer extension. but this isn't installed, since we don't support this feature. [11:21] seb128, we would have to set [11:21] /apps/gnome_settings_daemon/gtk-modules/pk-gtk-module [11:21] to false [11:23] glatzor, is there a schemas for this key somewhere? [11:26] seb128, no. I haven't found any. [11:26] I'm not sure to understand the bug [11:26] what is checking that key if it's not set anywhere? [11:27] seb128, gnome-settings-daemon [11:27] seb128: would you mind checking the maverick status of the gdm and empathy SRU bugs on http://people.canonical.com/~ubuntu-archive/pending-sru.html? [11:27] glatzor, no it's not [11:27] seb128, oh. true [11:27] glatzor, grepping for "pk-gtk" in g-s-d sources lists nothing [11:27] I did so too now. [11:27] hmm. [11:27] strange. [11:28] well, whatever defines this key should be changed [11:28] not sure what component that is though but it's not g-s-d [11:28] pitti, doing that, dunno if you read my comments yesterday where I said I would take care of updating maverick tasks for the gdm sru [11:29] seb128: I did read that, but I wasn't sure what "take care" means -> close the bugs or apply the patches, etc. [11:29] seb128, sorry. I have mixed something up in my mind. [11:29] pitti, well, it means close the tasks that should be closed and comment on other and milestone them as they should [11:30] seb128, the schema is part of gnome-packagekit [11:30] pitti, I said I will not waste efforts to backport git commits to maverick when we will get a gdm next version in the next days [11:30] glatzor, ok, so that's the one that should set the default value [11:30] seb128: ok, thanks; so I just keep gdm and empathy in proposed until I see the followup [11:30] pitti, it don't worry I will do things as they should ;-) [11:31] it->ie [11:34] didrocks, ^ can you update the empathy ones, closing the maverick tasks for things fixed in 2.31.3? [11:34] seb128: hum? I didn't list them? weird [11:34] sure, let me check [11:36] seb128: ok, all wasn't listed in the changelog (one without upstream task, the other upstream bug not listed in NEWS) but the 2 remaining were ok. Fixing the 2 others [11:36] didrocks, not listed, but you didn't do the 2.31.3 update so those didn't get closed [11:36] done [11:36] didrocks, thanks [11:36] pitti, I'm not sure what you want on the gdm bugs in fact, you want the maverick bugs to be closed before accepting the sru to updates? [11:37] seb128: that, or milestoned to maverick alpha-3 or so [11:37] pitti, because the tasks are already in a correct state, I've milestoned them now [11:37] to alpha2 [11:37] I really don't want changes in SRUs which are forgotten about in maverick [11:37] I will get that on monday if they didn't roll a tarball [11:37] pitti, well they are not forgot, they are in git waiting for a tarball to be rolled [11:37] seb128: and a check that our packaging changes are all in bzr at least [11:38] ok, it wasn't me, afraid of doing something wrong. Yeah, it was a debian merge :) [11:38] pitti, right, I've done that as well, those are fix released in maverick already [11:38] like 06_run_xsession.d.patch [11:38] seb128: packaging changes released and other changes in upstream git is sufficient [11:38] thanks! [11:39] pitti, np, sorry that this update is a bit of a mess, with the version revert in proposed [11:39] I know, I introduced the broken one :-/ [11:43] pitti, well to be fair I asked if you could help on GNOME sru updates and asked you to look at this one ;-) [11:43] pitti, anyway all sorted now [11:43] * seb128 hugs pitti [11:43] * pitti hugs you back [11:58] Anyone feel like a nice simple Xorg upload to add pitti's wonderful attach_drm_info to the xorg apport hook? [11:58] can do [11:59] RAOF: got a debdiff or branch? [11:59] Thanks! OEM stuff is more calm today, then? :) [11:59] http://cooperteam.net/Packages/xorg_7.5+6ubuntu2_source.changes [11:59] RAOF: yes, we are out of ideas, and need to wait for the Lexington guys to wake up anyway :) [11:59] (and we should be over the finish line anyway) [11:59] Or the ubuntu branch in pkg-xorg git. [11:59] will that close some of the workitems on your a2 list? [11:59] you have the higher count for the team right now ;-) [12:00] That will, yes. [12:00] nice [12:00] would be nice if you could try to get those a2 work items in shape for next week [12:00] ie delay those you will not get done [12:01] an icon we were using in lucid from gnome-icon-theme (stock_contact) is no longer in that package in maverick, any idea? [12:01] Will do. [12:01] thanks [12:02] rodrigo_, g-i-t 2.30 change IIRC [12:02] rodrigo_, it's avatar-default now [12:02] seb128, ah, ok [12:02] rodrigo_, check to be sure but there was a similar issue in empathy [12:02] RAOF: nudged archivewards [12:02] and those changes are why we didn't update g-i-t in lucid [12:02] avatar-default is available, yeah [12:03] lunch time, bbl [12:03] pitti: Awesomeitude. [12:03] lunch! now, that's a bright idea [12:03] ;-) [12:38] lunch for real now, bbl [12:39] pitti: enjoy === MacSlow is now known as MacSlow|lunch === ayan-afk is now known as ayan [13:26] hey [13:26] mvo, bug #394642 [13:26] Launchpad bug 394642 in gnome-app-install (Ubuntu) "merged duplicate strings to reduce # of msgstrs (affects: 1) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/394642 [13:26] mvo, could you review the patch there? it's on the review team list [13:27] can do [13:28] mvo, thanks [13:57] mvo: ah, I found out about xapian; it does work, just takes ages; I suppose it's due to a lot of seek operations (it accesses p-apt's .record field a lot) [13:57] I'll look into this in python-apt [13:58] mvo: I'm just about unsure what to work against -- lp:python-apt seems to be fairly out of date [13:58] is there a more recent trunk somewhere? lp:~ubuntu-core-dev/python-apt/ubuntu is just our packaging branch, right? [13:59] pitti: hold on a second, there should be a debian-sid branch somewhere [13:59] pitti: ours is the ubuntu branch that is also very up-to-date [13:59] lp:~mvo/python-apt/debian-sid is 44 weeks old [14:00] mvo: so should I just use that then? [14:00] lp:~ubuntu-core-dev/python-apt/ubuntu I mean [14:01] http://bzr.debian.org/apt/python-apt/debian-sid -- aah! [14:01] pitti: yeah, this one or the lp:~mvo/python-apt/debian-sid-mirrored (that should be the one that debian is using [14:02] mvo: perfect, thanks [14:02] pitti: I made lp:python-apt point to this one now [14:02] ah, https://code.edge.launchpad.net/python-apt updated for this [14:02] * pitti hugs mvo [14:02] cheers, thanks for pointing this out [14:03] so, let's see what I can do about the performance problem [14:03] mvo: otherwise it seems that lp:~pitti/apt/compressed-indexes works pretty well these days [14:05] mvo: and yay for p-apt having a nice test suite :) [14:05] yep! [14:06] mvo: it doesn't seem to have any kind of local repo for debs, though? just an "edgy" sources.list [14:07] ah, just seems to use the system one [14:07] fine for me :) [14:10] ccheney, hey [14:10] ccheney, is there any news about that presentation and compiz issue? [14:15] seb128, haven't had time to work on it yet, hopefully over this weekend i can look at it [14:16] seb128, been beating on a kernel bug related to server [14:16] ccheney, ok [14:16] ccheney, we need it uploaded by end of next week [14:17] this is for lucid sru, right? [14:17] or in maverick? [14:17] lucid sru [14:17] we want it in .1 [14:17] which is at end of july, but time validate the sru, build images, etc [14:25] seb128, do you know if the gstreamer packges will stay at the current version for maverick ? [14:26] ogra, they will most likely not [14:26] (TI is rebasing some work/patches and want to know if the version stays) [14:26] seb128, thanks ! [14:26] ogra, we are still very early in the cycle, depends of upstream but I guess they will roll updates during the cycle [14:26] ogra, though I don't know when [14:26] ok [14:27] worst case they have to forward port the patches :) [14:27] ogra, I can try to figure if that's important [14:27] right [14:32] alf__: hey, why did you removed control.in? I remember asking you to put it back and generate debian/control from it :) [14:33] alf__: also, how is the discussion with the DD btw about dh 7 and such? [14:35] didrocks: I must have missed that, sorry. That being said, what is the need for control.in when using dh7? I thought it was only useful when using cdbs. [14:35] alf__: hum, good point, I think debian has still some uploaders: for DM and such, let me check if it's the case for this package [14:36] alf__: yeah, they have the GNOME_TEAM for uploaders. Not sure they have the fix for dh7 and that btw (and not sure the debian GNOME team wants to use dh7) [14:36] alf__: did you check with them? [14:37] didrocks: Not yet, I am going to send a mail in a while [14:37] alf__: ok, let me check the rest first [14:41] alf__: why did you bump libcairo2-dev to 1.6? configure.ac says 1.4 [14:41] didrocks: let me check [14:43] didrocks: ...because README says > 1.6, I didn't notice configure.ac was different. Now, what to believe? :) [14:44] alf__: ahah, that's the question :) [14:44] let me check what we have [14:44] alf__: well, in any case, we are higher even in lucid, I would say don't care and keep 1.6 :) [14:44] (even hardy has 1.6) [14:45] alf__: is the json stuff mandatory? what's used for? [14:47] didrocks: json is used for loading predefined interfaces (like eg XML is used for glade) [14:47] alf__: it's just from my curiousity, but some clutter interfaces are json documents? [14:49] didrocks: They can be :) [14:50] didrocks: There is a small example in the Clutter wikipedia article [14:50] alf__: oh sweet, I will have a look, thanks! back on the review [14:51] didrocks: BTW, thanks for taking the time to review, I know you are very busy :) [14:52] alf__: why did you conflict the two -dev package against libclutter-1.0-dev, do they install the same file? [14:52] alf__: no worry, sorry for it taking so long :) [14:54] I assume that eglx-es11 and eglx-es20 are installing the same library name, hence the conflict, as well on -dev package but for glx backend, it's another story, no? [14:54] didrocks: Unfortunately all -dev install pkg-config files using the same name. [14:54] urgh :/ [14:55] didrocks: We have talked to upstream about this... [14:55] yeah, that's not good at all :/ [14:55] alf__: will they fix it? [14:55] didrocks: No, answer yet... [14:56] alf__: ok [14:56] alf__: I saw you added a bunch of patch [14:56] mvo: I've finished merging the debpackage, debsrcpackage, cache files with the python-apt cache and debfile files. [14:56] mvo: It took a bit longer than it should have, but I've done some testing and it seems to work. [14:57] mvo: I'll start porting gdebi now, and hope that things still work nicely ;) [14:57] alf__: while I'm not sure about debian/patches/fix_po_makefile_out_of_tree_build.patch and debian/patches/fix_test_data_path.patch (they should be other way to fix it, I'll have a look), can you add infos on them following this format: http://dep.debian.net/deps/dep3/ [14:58] alf__: it enables knowing that the patch has been forwarded upstream, and description/authors [14:58] kiwinote: cool, let me know once there is a branch to look at [14:59] didrocks: Ok, I 'll take a look. I have already pushed some of them upstream. [14:59] mvo: I'll push python-apt once I've finished doing gdebi, as for some reason bzr wants to upload 70mb, which takes 30mins over here. I can pastebin the files if you want to have a look now though [15:00] kiwinote: thanks, I will just wait for the push, that is fine [15:00] ok [15:01] alf__: we usually use one -dbg package by source package [15:01] alf__: do you have name collision? [15:01] alf__: I think you can with eglx-es11-1.0 and eglx-es20-1.0 so files, right? [15:02] didrocks: Yes, these two produce the same .so file [15:02] alf__: ok, forget it so :) [15:05] alf__: it's cool, you call dh_girepository and using gir:depends :) Just one gir file copied from es20? (es11 and e20 shared library can be used with the same gir file? same interface?) [15:07] didrocks: Yes, they are (at least they are supposed to be :)) completely ABI compatible. [15:07] alf__: sweet! very good work, all the remaining seems good to me [15:08] that's really a bunch of good work :) [15:08] alf__: so, I would say: fix remaining things I noticed previously and talk to debian [15:08] alf__: on the bright side, if you don't want to carry the autoreconf patch, you should build-dep on dh-autoreconf and add the call to dh_autoreconf [15:09] didrocks: Thank you, so just to be clear, the remaining stuff is only the patches info? [15:09] alf__: let me check :) [15:11] alf__: yeah, patch info + looking for the control.in if debian has something for their GNOME_TEAM in dh7 [15:11] and then, talk to debian :) [15:11] alf__: dh-autoreconf if you have the time too, it's really good [15:11] again, nice work :-) [15:11] didrocks: thank you, and thank you for reviewing it :) [15:11] alf__: yw :) [15:13] (hum, the json interface builder is fun :)) [15:22] didrocks, what's that? [15:22] kenvandine: for clutter, see the wikipedia page [15:22] * kenvandine looks [15:23] ah... [15:23] nice [15:23] better than xml stuff [15:24] although... i find it annoying that when using json-glib to parse json it is just as painful as dealing with xml parsing [15:24] python-simplejson ftw! [15:26] kenvandine, Riddell: could you update https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus if you have anything to note there? [15:27] ok [15:27] kenvandine, I'm pinging you but I'm not sure it's required since dbarth does dx summaries [15:27] seb128, btw... did i mention i'll be gone on vacation next week? [15:27] seb128, no worries.. sometimes i do have stuff :) [15:28] kenvandine: can you access to your futon? [15:28] (the couchdb one :)) [15:28] kenvandine, I don't think you did before, enjoy those ;-) [15:28] no [15:28] seb128, sorry... meant to mention it earlier in the week [15:28] that's ok [15:28] kenvandine, your work items for a2 at done so nothing to worry about ;-) [15:29] kenvandine, could you make sure your a3 work items reflect what you will do during the next iteration though? [15:29] kenvandine, not sure if you did review those yet [15:29] kenvandine, is the tpapprover still blocked on something? [15:30] seb128, not anymore [15:30] i think... [15:30] should be ready for me to work on when i get back [15:30] ok [15:31] they merged what i needed [15:31] but nobody has really used it yet [15:32] seb128, i am about to do the first release of libgwibber [15:32] kenvandine, ok [15:33] 2in 21 === virtuald_ is now known as virtuald [16:02] mvo mvo mvo [16:02] hello [16:02]