[00:33] <Sarvatt> 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] <Sarvatt> 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] <TheMuso> Sarvatt: If thats all thats needed, let me know and I'll upload it for you.
[00:46] <Sarvatt> xvid's work again! \o/ gstreamer0.10-ffmpeg just needs a no change rebuild against the newer libavutil-dev
[00:47] <Sarvatt> Depends: libavcodec52 (>= 4:0.6~svn20100505-1) | libavcodec-extra-52 (>= 4:0.6~svn20100505-1), libavformat52 (>= 4:0.6~svn20100505-1) |
[00:47] <Sarvatt>          libavformat-extra-52 (>= 4:0.6~svn20100505-1), libavutil50 (>= 4:0.6~svn20100505-1) | libavutil-extra-50 (>=
[00:47] <Sarvatt>          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] <Sarvatt>          (>= 0.10.24), liboil0.3 (>= 0.3.6), libpostproc51 (>= 4:0.6~svn20100505-1) | libpostproc-extra-51 (>= 4:0.6~svn20100505-1),
[00:47] <Sarvatt>          libswscale0 (>= 4:0.6~svn20100505-1) | libswscale-extra-0 (>= 4:0.6~svn20100505-1)
[00:48] <Sarvatt> TheMuso: well there might be something else up with it, I pinged siretart about it
[00:48] <TheMuso> Sarvatt: ok.
[00:51] <Sarvatt> 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] <Sarvatt> and the codec installer wouldn't work because the empty package was installed already so it didn't find anything to install
[03:06] <robert_ancell> TheMuso, can you sponsor glib?
[03:06] <TheMuso> Sure.
[03:38] <TheMuso> robert_ancell: uploaded
[03:38] <robert_ancell> TheMuso, thanks
[03:38] <TheMuso> np
[03:42] <RAOF> Can someone check for me that /var/log/dmesg is readable only by root and the adm group on your system?
[03:43] <ajmitch> RAOF: yep
[03:43] <RAOF> Cool.  More apport bugs!
[03:47] <ravibn> Hi! I need help with my Dell Latitude
[03:47] <ravibn> please indicate to me which version of ubuntu I need to install
[03:49] <RAOF> 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] <ravibn> I tried that forum and also the latest 64bit LTS THe machine would not even boot
[03:52] <ravibn> RAOF : my latitude has core i7 720QM cpu (i686 ) with nVidia 3100 nvs
[03:53] <ravibn> RAOF : I want to understand whether the server version (10 LTS) supports the i686
[03:54] <ravibn> RAOF : I mean 64bit version of ubuntu
[03:55] <RAOF> It does.  You might be having problems because of your… ok.
[06:54] <didrocks> good morning
[06:56] <nigelb> Bonjour didrocks :)
[06:59] <didrocks> hey nigelb :)
[07:12] <RAOF> ls
[07:12] <RAOF> Ahem.  Focus fail!
[07:13] <TheMuso> heh
[07:14] <RAOF> 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] <TheMuso> lol
[07:17] <bryce_> RAOF: how about dual touchscreens? :-)
[07:18] <RAOF> We need xserver 1.9 for that so that we can apply transformations on the device inputs!
[07:19] <RAOF> 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.
[08:19] <seb128> hey there
[08:32] <pitti> Good morning
[08:32] <seb128> hey pitti
[08:32] <seb128> pitti, how are you? got a better night?
[08:32] <pitti> bonjour seb128
[08:32] <pitti> seb128: absolutely, I slept well
[08:33] <kiwinote> mvo: hi
[08:33] <seb128> nice ;-)
[08:33] <pitti> cjwatson and I hacked until 1, but then I allowed myself to sleep in until 9 :)
[08:33] <kiwinote> mvo: can i just confirm the plan for debfile.py?
[08:33] <mvo> hey kiwinote
[08:33] <mvo> good morning
[08:33] <mvo> kiwinote: let me check the mail
[08:34] <seb128> hey mvo
[08:34] <mvo> kiwinote: yep :)
[08:34] <mvo> hey seb128
[08:34] <mvo> 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] <mvo> 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] <kiwinote> 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] <mvo> kiwinote: yeah
[08:35] <kiwinote> mvo: and then i port gdebi to use python-apt rather than it's own debfile class?
[08:35] <mvo> kiwinote: correct
[08:35] <mvo> kiwinote: its going to be a bit of work I imagine :/
[08:36] <kiwinote> mvo: ok, thanks
[08:36] <mvo> kiwinote: let me know if I can help in any way
[08:36] <kiwinote> mvo: will do
[08:36] <mvo> seb128: I run your upgrade test currently
[08:36] <mvo> seb128: triggered a bug in *my* code !
[08:36] <mvo> seb128: bad boy
[08:37] <seb128> mvo, lol
[08:37]  * seb128 hugs mvo
[08:37] <mvo> :)
[08:37]  * mvo hugs seb128
[08:37] <mvo> all good, SRU for it is almost ready
[08:38] <seb128> mvo, speaking of which you should join the sru team
[08:38]  * mvo nods
[08:39] <mvo> 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] <seb128> pitti, ^
[08:40] <seb128> 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] <seb128> 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] <pitti> I'll do some this morning
[08:41] <pitti> but I (or, rather, OEM) really needed that hackathon in the past three days, sorry
[08:44] <mvo> seb128: ok, let me see how the buy-something progress of today goes and if it looks promising I can do some on monday
[08:45] <seb128> pitti, slangasek did 3 of those yesterday which is something ;-)
[08:45] <seb128> pitti, thanks for doing that, still if mvo and I join that will help balancing load
[08:46] <seb128> pitti, ie for next round if that's not this one
[08:47] <pitti> absolutely, that'd be great
[08:54] <seb128> mvo, s-c hates unity
[08:54] <mvo> seb128: ha! I'm sure its the other way around ;)
[08:54] <mvo> seb128: s-c is build with extra-love inside
[08:54] <seb128> mvo, no, if I type "unity" in the search entry in s-c maverick it lists nothing
[08:54] <seb128> hum same for "gnome"
[08:55] <seb128> ok, so maybe the index is broken or something
[08:55] <kiwinote> seb128: that's fixed in trunk
[08:55] <seb128> kiwinote, thanks
[08:55] <mvo> *cough*
[08:55] <mvo> I should do a new upload, but yeah, trunk works and unity is #1 hit
[08:56] <seb128> mvo, ok, in fact it works if I select something else than "get softwares"
[08:56] <seb128> well it does list other things before unity
[08:56] <seb128> but it does list things ;-)
[08:56] <seb128> mvo, do you plan to do an upload before a2?
[08:56] <mvo> yes
[08:56] <mvo> definitely
[08:56] <mvo> lots of good stuff inside
[08:58] <seb128> mvo, upload upload upload!
[08:58] <mvo> :)
[08:58] <seb128> ;-)
[08:59] <pitti> mvo: speaking of things hating each other, apt officially hates me
[08:59] <pitti> I've done like 10 followup commits, and it's still not perfect
[08:59] <pitti> works with everything else now, but apt-xapian-index is still taking infinite time (literally)
[08:59] <pitti> so I need to track that down as well; please ignore the MP for now
[08:59] <mvo> pitti: ok
[09:00] <pitti> but I learned a lot about apt's inner workings :)
[09:00] <mvo> pitti: I can imagine :)
[09:01] <mvo> seb128: btw, I added support for "do-release-upgrade -d" from lucid -> maverick directly now
[09:01] <mvo> (you asked IIRC)
[09:01] <mvo> (and others too)
[09:01] <seb128> mvo, indeed, thanks
[09:02] <mvo> np
[09:19] <seb128> didrocks, ok, normal update-manager maverick upgrade works and bring it unity places binaries
[09:19] <didrocks> seb128: sweet \o/ thanks for testing :)
[09:20] <seb128> those places are quite slow to display icons though
[09:20] <seb128> it takes over one second with blank icons and then screen is changing to real colored icons
[09:20] <didrocks> seb128: yeah, known issue
[09:21] <didrocks> seb128: kamstrup told there are low hanging fruit to fix that
[09:21] <didrocks> also, there isn't any preferences/settings
[09:21] <seb128> right
[09:21] <didrocks> and it doesn't take XDG_CONFIG_DIRS into account
[09:21] <seb128> still it's very nice
[09:21] <didrocks> but for a first iteration, it's not bad at all :)
[09:24] <seb128> didrocks, there is no way to get the expose mode now with those places?
[09:24] <didrocks> seb128: I think not, it's hidden right now with the ws switcher which has no ui
[09:25] <seb128> ok
[09:28] <htorque> thanks for pointing me to unity-places-* - i was wondering what that empty black screen is all about :P
[09:43] <huats> morning
[09:54] <didrocks> morning huats
[09:54] <huats> morning didrocks !
[10:03] <mvo> 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] <seb128> mvo, bug #547244 I guess
[10:04] <ubot2> 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] <mvo> (libatk1.0-dev <-> gobject-introspection-repository)
[10:04] <mvo> seb128: yeah, sounds like it
[10:05] <mvo> seb128: I wait until its finished, but I think #574837 is verfication-done
[10:05] <seb128> mvo, thanks
[10:06] <seb128> mvo, I will get the atk issue on the .1 lucid buglist
[10:06] <mvo> thanks
[10:12] <seb128> mvo, the atk bug is milestoned for lucid .1 and assigned to TheMuso now
[10:13] <seb128> 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] <geser> 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] <seb128> geser, when somebody does the merge on debian I guess?
[10:37] <seb128> geser, you are welcome to do it if you want
[10:37] <huats> seb128, I can try to handle it otherwise later today or monday
[10:38] <seb128> hey huats
[10:38] <seb128> if you want to do it you are welcome ;-)
[10:39] <huats> seb128, I know I know... and you have not idea how much I'd like to do it...
[10:39] <huats> I am just lacking time :(
[10:39] <huats> but I still hope :)
[10:41] <didrocks> huats: didn't you take some tasks already last week?
[10:41] <didrocks> huats: reviewing and integrate patches IIRC
[10:41] <huats> didrocks, yep
[10:41] <huats> I had
[10:41] <didrocks> huats: don't take too much on your plate :)
[10:41] <huats> but I should have much time starting monday
[11:01] <kiwinote> 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] <mvo> 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] <kiwinote> mvo: gdebi's debfile was calling cache.getProvidersFor(), but I can't find an equivalent for that in python-apt's cache
[11:04] <mvo> kiwinote: right, lets move it over then :)
[11:04] <kiwinote> mvo: ok ;)
[11:12] <pitti> 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] <pitti> mvo: but in fact merely using autoreconf works just fine, and that's the upstream recommended way now
[11:14] <pitti> 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] <pitti> oh, it is already
[11:18] <pitti> just with an extra bunch of stuff
[11:19] <glatzor> seb128, hello
[11:19] <glatzor> seb128, may I point you to #389766?
[11:20] <glatzor> seb128, should the gconf defaults be shipped with gnome-settings-daemon or with packagekit?
[11:21] <glatzor> 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] <glatzor> seb128, we would have to set
[11:21] <glatzor>  /apps/gnome_settings_daemon/gtk-modules/pk-gtk-module
[11:21] <glatzor>  to false
[11:23] <seb128> glatzor, is there a schemas for this key somewhere?
[11:26] <glatzor> seb128, no. I haven't found any.
[11:26] <seb128> I'm not sure to understand the bug
[11:26] <seb128> what is checking that key if it's not set anywhere?
[11:27] <glatzor> seb128, gnome-settings-daemon
[11:27] <pitti> 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] <seb128> glatzor, no it's not
[11:27] <glatzor> seb128, oh. true
[11:27] <seb128> glatzor, grepping for "pk-gtk" in g-s-d sources lists nothing
[11:27] <glatzor> I did so too now.
[11:27] <glatzor> hmm.
[11:27] <glatzor> strange.
[11:28] <seb128> well, whatever defines this key should be changed
[11:28] <seb128> not sure what component that is though but it's not g-s-d
[11:28] <seb128> 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] <pitti> seb128: I did read that, but I wasn't sure what "take care" means -> close the bugs or apply the patches, etc.
[11:29] <glatzor> seb128, sorry. I have mixed something up in my mind.
[11:29] <seb128> pitti, well, it means close the tasks that should be closed and comment on other and milestone them as they should
[11:30] <glatzor> seb128, the schema is part of gnome-packagekit
[11:30] <seb128> 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] <seb128> glatzor, ok, so that's the one that should set the default value
[11:30] <pitti> seb128: ok, thanks; so I just keep gdm and empathy in proposed until I see the followup
[11:30] <seb128> pitti, it don't worry I will do things as they should ;-)
[11:31] <seb128> it->ie
[11:34] <seb128> didrocks, ^ can you update the empathy ones, closing the maverick tasks for things fixed in 2.31.3?
[11:34] <didrocks> seb128: hum? I didn't list them? weird
[11:34] <didrocks> sure, let me check
[11:36] <didrocks> 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] <seb128> didrocks, not listed, but you didn't do the 2.31.3 update so those didn't get closed
[11:36] <didrocks> done
[11:36] <seb128> didrocks, thanks
[11:36] <seb128> 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] <pitti> seb128: that, or milestoned to maverick alpha-3 or so
[11:37] <seb128> pitti, because the tasks are already in a correct state, I've milestoned them now
[11:37] <seb128> to alpha2
[11:37] <pitti> I really don't want changes in SRUs which are forgotten about in maverick
[11:37] <seb128> I will get that on monday if they didn't roll a tarball
[11:37] <seb128> pitti, well they are not forgot, they are in git waiting for a tarball to be rolled
[11:37] <pitti> seb128: and a check that our packaging changes are all in bzr at least
[11:38] <didrocks> ok, it wasn't me, afraid of doing something wrong. Yeah, it was a debian merge :)
[11:38] <seb128> pitti, right, I've done that as well, those are fix released in maverick already
[11:38] <pitti> like 06_run_xsession.d.patch
[11:38] <pitti> seb128: packaging changes released and other changes in upstream git is sufficient
[11:38] <pitti> thanks!
[11:39] <seb128> pitti, np, sorry that this update is a bit of a mess, with the version revert in proposed
[11:39] <pitti> I know, I introduced the broken one :-/
[11:43] <seb128> 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] <seb128> pitti, anyway all sorted now
[11:43]  * seb128 hugs pitti
[11:43]  * pitti hugs you back
[11:58] <RAOF> Anyone feel like a nice simple Xorg upload to add pitti's wonderful attach_drm_info to the xorg apport hook?
[11:58] <pitti> can do
[11:59] <pitti> RAOF: got a debdiff or branch?
[11:59] <RAOF> Thanks!  OEM stuff is more calm today, then? :)
[11:59] <RAOF> http://cooperteam.net/Packages/xorg_7.5+6ubuntu2_source.changes
[11:59] <pitti> RAOF: yes, we are out of ideas, and need to wait for the Lexington guys to wake up anyway :)
[11:59] <pitti> (and we should be over the finish line anyway)
[11:59] <RAOF> Or the ubuntu branch in pkg-xorg git.
[11:59] <seb128> will that close some of the workitems on your a2 list?
[11:59] <seb128> you have the higher count for the team right now ;-)
[12:00] <RAOF> That will, yes.
[12:00] <seb128> nice
[12:00] <seb128> would be nice if you could try to get those a2 work items in shape for next week
[12:00] <seb128> ie delay those you will not get done
[12:01] <rodrigo_> 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] <RAOF> Will do.
[12:01] <seb128> thanks
[12:02] <seb128> rodrigo_, g-i-t 2.30 change IIRC
[12:02] <seb128> rodrigo_, it's avatar-default now
[12:02] <rodrigo_> seb128, ah, ok
[12:02] <seb128> rodrigo_, check to be sure but there was a similar issue in empathy
[12:02] <pitti> RAOF: nudged archivewards
[12:02] <seb128> and those changes are why we didn't update g-i-t in lucid
[12:02] <rodrigo_> avatar-default is available, yeah
[12:03] <seb128> lunch time, bbl
[12:03] <RAOF> pitti: Awesomeitude.
[12:03] <pitti> lunch! now, that's a bright idea
[12:03] <seb128> ;-)
[12:38] <pitti> lunch for real now, bbl
[12:39] <didrocks> pitti: enjoy
[13:26] <seb128> hey
[13:26] <seb128> mvo, bug #394642
[13:26] <ubot2> 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] <seb128> mvo, could you review the patch there? it's on the review team list
[13:27] <mvo> can do
[13:28] <seb128> mvo, thanks
[13:57] <pitti> 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] <pitti> I'll look into this in python-apt
[13:58] <pitti> mvo: I'm just about unsure what to work against -- lp:python-apt seems to be fairly out of date
[13:58] <pitti> is there a more recent trunk somewhere? lp:~ubuntu-core-dev/python-apt/ubuntu is just our packaging branch, right?
[13:59] <mvo> pitti: hold on a second, there should be a debian-sid branch somewhere
[13:59] <mvo> pitti: ours is the ubuntu branch that is also very up-to-date
[13:59] <pitti> lp:~mvo/python-apt/debian-sid is 44 weeks old
[14:00] <pitti> mvo: so should I just use that then?
[14:00] <pitti> lp:~ubuntu-core-dev/python-apt/ubuntu I mean
[14:01] <pitti> http://bzr.debian.org/apt/python-apt/debian-sid -- aah!
[14:01] <mvo> pitti: yeah, this one or the lp:~mvo/python-apt/debian-sid-mirrored (that should be the one that debian is using
[14:02] <pitti> mvo: perfect, thanks
[14:02] <mvo> pitti: I made lp:python-apt point to this one now
[14:02] <pitti> ah, https://code.edge.launchpad.net/python-apt updated for this
[14:02]  * pitti hugs mvo
[14:02] <mvo> cheers, thanks for pointing this out
[14:03] <pitti> so, let's see what I can do about the performance problem
[14:03] <pitti> mvo: otherwise it seems that lp:~pitti/apt/compressed-indexes works pretty well these days
[14:05] <pitti> mvo: and yay for p-apt having a nice test suite :)
[14:05] <mvo> yep!
[14:06] <pitti> mvo: it doesn't seem to have any kind of local repo for debs, though? just an "edgy" sources.list
[14:07] <pitti> ah, just seems to use the system one
[14:07] <pitti> fine for me :)
[14:10] <seb128> ccheney, hey
[14:10] <seb128> ccheney, is there any news about that presentation and compiz issue?
[14:15] <ccheney> seb128, haven't had time to work on it yet, hopefully over this weekend i can look at it
[14:16] <ccheney> seb128, been beating on a kernel bug related to server
[14:16] <seb128> ccheney, ok
[14:16] <seb128> ccheney, we need it uploaded by end of next week
[14:17] <ccheney> this is for lucid sru, right?
[14:17] <ccheney> or in maverick?
[14:17] <seb128> lucid sru
[14:17] <seb128> we want it in .1
[14:17] <seb128> which is at end of july, but time validate the sru, build images, etc
[14:25] <ogra> seb128, do you know if the gstreamer packges will stay at the current version for maverick ?
[14:26] <seb128> ogra, they will most likely not
[14:26] <ogra> (TI is rebasing some work/patches and want to know if the version stays)
[14:26] <ogra> seb128, thanks !
[14:26] <seb128> ogra, we are still very early in the cycle, depends of upstream but I guess they will roll updates during the cycle
[14:26] <seb128> ogra, though I don't know when
[14:26] <ogra> ok
[14:27] <ogra> worst case they have to forward port the patches :)
[14:27] <seb128> ogra, I can try to figure if that's important
[14:27] <seb128> right
[14:32] <didrocks> alf__: hey, why did you removed control.in? I remember asking you to put it back and generate debian/control from it :)
[14:33] <didrocks> alf__: also, how is the discussion with the DD btw about dh 7 and such?
[14:35] <alf__> 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] <didrocks> 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] <didrocks> 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] <didrocks> alf__: did you check with them?
[14:37] <alf__> didrocks: Not yet, I am going to send a mail in a while
[14:37] <didrocks> alf__: ok, let me check the rest first
[14:41] <didrocks> alf__: why did you bump libcairo2-dev to 1.6? configure.ac says 1.4
[14:41] <alf__> didrocks: let me check
[14:43] <alf__> didrocks: ...because README says > 1.6, I didn't notice configure.ac was different. Now, what to believe? :)
[14:44] <didrocks> alf__: ahah, that's the question :)
[14:44] <didrocks> let me check what we have
[14:44] <didrocks> alf__: well, in any case, we are higher even in lucid, I would say don't care and keep 1.6 :)
[14:44] <didrocks> (even hardy has 1.6)
[14:45] <didrocks> alf__: is the json stuff mandatory? what's used for?
[14:47] <alf__> didrocks: json is used for loading predefined interfaces (like eg XML is used for glade)
[14:47] <didrocks> alf__: it's just from my curiousity, but some clutter interfaces are json documents?
[14:49] <alf__> didrocks: They can be :)
[14:50] <alf__> didrocks: There is a small example in the Clutter wikipedia article
[14:50] <didrocks> alf__: oh sweet, I will have a look, thanks! back on the review
[14:51] <alf__> didrocks: BTW, thanks for taking the time to review, I know you are very busy :)
[14:52] <didrocks> alf__: why did you conflict the two -dev package against libclutter-1.0-dev, do they install the same file?
[14:52] <didrocks> alf__: no worry, sorry for it taking so long :)
[14:54] <didrocks> 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] <alf__> didrocks: Unfortunately all -dev install pkg-config files using the same name.
[14:54] <didrocks> urgh :/
[14:55] <alf__> didrocks: We have talked to upstream about this...
[14:55] <didrocks> yeah, that's not good at all :/
[14:55] <didrocks> alf__: will they fix it?
[14:55] <alf__> didrocks: No, answer yet...
[14:56] <didrocks> alf__: ok
[14:56] <didrocks> alf__: I saw you added a bunch of patch
[14:56] <kiwinote> mvo: I've finished  merging the debpackage, debsrcpackage, cache files with the python-apt cache and debfile files.
[14:56] <kiwinote> mvo: It took a bit longer than it should have, but I've done some testing and it seems to work.
[14:57] <kiwinote> mvo: I'll start porting gdebi now, and hope that things still work nicely ;)
[14:57] <didrocks> 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] <didrocks> alf__: it enables knowing that the patch has been forwarded upstream, and description/authors
[14:58] <mvo> kiwinote: cool, let me know once there is a branch to look at
[14:59] <alf__> didrocks: Ok, I 'll take a look. I have already pushed some of them upstream.
[14:59] <kiwinote> 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] <mvo> kiwinote: thanks, I will just wait for the push, that is fine
[15:00] <kiwinote> ok
[15:01] <didrocks> alf__: we usually use one -dbg package by source package
[15:01] <didrocks> alf__: do you have name collision?
[15:01] <didrocks> alf__: I think you can with eglx-es11-1.0 and eglx-es20-1.0 so files, right?
[15:02] <alf__> didrocks: Yes, these two produce the same .so file
[15:02] <didrocks> alf__: ok, forget it so :)
[15:05] <didrocks> 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] <alf__> didrocks: Yes, they are (at least they are supposed to be :)) completely ABI compatible.
[15:07] <didrocks> alf__: sweet! very good work, all the remaining seems good to me
[15:08] <didrocks> that's really a bunch of good work :)
[15:08] <didrocks> alf__: so, I would say: fix remaining things I noticed previously and talk to debian
[15:08] <didrocks> 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] <alf__> didrocks: Thank you, so just to be clear, the remaining stuff is only the patches info?
[15:09] <didrocks> alf__: let me check :)
[15:11] <didrocks> alf__: yeah, patch info + looking for the control.in if debian has something for their GNOME_TEAM in dh7
[15:11] <didrocks> and then, talk to debian :)
[15:11] <didrocks> alf__: dh-autoreconf if you have the time too, it's really good
[15:11] <didrocks> again, nice work :-)
[15:11] <alf__> didrocks: thank you, and thank you for reviewing it :)
[15:11] <didrocks> alf__: yw :)
[15:13] <didrocks> (hum, the json interface builder is fun :))
[15:22] <kenvandine> didrocks, what's that?
[15:22] <didrocks> kenvandine: for clutter, see the wikipedia page
[15:22]  * kenvandine looks
[15:23] <kenvandine> ah...
[15:23] <kenvandine> nice
[15:23] <kenvandine> better than xml stuff
[15:24] <kenvandine> 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] <kenvandine> python-simplejson ftw!
[15:26] <seb128> kenvandine, Riddell: could you update https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus if you have anything to note there?
[15:27] <kenvandine> ok
[15:27] <seb128> kenvandine, I'm pinging you but I'm not sure it's required since dbarth does dx summaries
[15:27] <kenvandine> seb128, btw... did i mention i'll be gone on vacation next week?
[15:27] <kenvandine> seb128, no worries.. sometimes i do have stuff :)
[15:28] <didrocks> kenvandine: can you access to your futon?
[15:28] <didrocks> (the couchdb one :))
[15:28] <seb128> kenvandine, I don't think you did before, enjoy those ;-)
[15:28] <kenvandine> no
[15:28] <kenvandine> seb128, sorry... meant to mention it earlier in the week
[15:28] <seb128> that's ok
[15:28] <seb128> kenvandine, your work items for a2 at done so nothing to worry about ;-)
[15:29] <seb128> kenvandine, could you make sure your a3 work items reflect what you will do during the next iteration though?
[15:29] <seb128> kenvandine, not sure if you did review those yet
[15:29] <seb128> kenvandine, is the tpapprover still blocked on something?
[15:30] <kenvandine> seb128, not anymore
[15:30] <kenvandine> i think...
[15:30] <kenvandine> should be ready for me to work on when i get back
[15:30] <seb128> ok
[15:31] <kenvandine> they merged what i needed
[15:31] <kenvandine> but nobody has really used it yet
[15:32] <kenvandine> seb128, i am about to do the first release of libgwibber
[15:32] <seb128> kenvandine, ok
[15:33] <highvoltage> 2in 21
[16:02] <mpt> mvo mvo mvo
[16:02] <mvo> hello
[16:02] <mpt> hi :-)
[16:03] <mpt> mvo, if you could save a text file containing the name of every package installed on your computer, what could you use it for?
[16:03] <mvo> you mean from a security perspective? or from a cool-things-to-do-with-that perspective?
[16:04] <mpt> mvo, cool-things-to-do-with-that
[16:04] <mvo> with just the names relatively little, with name+version we could tell what needs updating and download it
[16:04] <mpt> Take it to another computer and "cat inventory.txt | xargs apt-get install", or something like that?
[16:05] <mvo> with enough data (and some cleverness) we could data-mine it and try to make suggestions
[16:05] <mvo> yeah, clone the package list
[16:05] <mvo> the installed packages
[16:05] <mvo> to me cloning is the most interessting use case
[16:05] <mvo> and reinstall of course
[16:05] <mvo> re-install into the same system as before
[16:06] <mpt> yes
[16:06] <mpt> We'd need to record somehow which archive (e.g. PPA) each package belonged to
[16:06] <mvo> when using it with a clever backup system it can avoid backup a lot of data
[16:07] <mvo> right, so (packagelist+versoin, sources.list-conent) is needed
[16:07] <mvo> and for a full "backup" some way to re-create packages that are not/no-longer downloadable
[16:07] <mvo> (not sure if that is something to care about)
[16:07] <mpt> More than that, if someone has forced a particular version
[16:07]  * mvo nods
[16:08] <mpt> ok, thanks mvo
[16:08] <mvo> cheers
[16:13] <didrocks> mvo: mpt: the issue is recording packagelist + version is when you save the list on lucid and want to install it on maverick, for instance
[16:14] <mpt> yes
[16:14] <didrocks> (same issue with sources.list, is the new ppa/source available for the new version?)
[16:14] <didrocks> s/version/release
[17:16] <seb128> chrisccoulson, hi
[17:16] <seb128> chrisccoulson, bug #578281
[17:16] <ubot2> Launchpad bug 578281 in ubufox (Ubuntu Maverick) (and 2 other projects) "Add search plugin for Baidu (affects: 1) (heat: 79)" [High,Triaged] https://launchpad.net/bugs/578281
[17:17] <chrisccoulson> hi seb128
[17:17] <seb128> chrisccoulson, do you think you can get that done next week? we are getting close of the upload line for .1 updates
[17:17] <chrisccoulson> seb128 - yeah, that's already on my list of things to look at
[17:17] <seb128> chrisccoulson, ok, thanks
[17:18] <seb128> rickspencer3, ^
[17:19] <rickspencer3> thanks seb128 and chrisccoulson
[17:22] <rickspencer3> so, looks like a bit of work for me to get 10.04.1 organized next week
[17:22] <rickspencer3> :/
[17:22] <rickspencer3> time for a bit of a break then, I think :)
[17:23] <seb128> rickspencer3, see, this week didn't end yet that you are already loaded with tasks for next week
[17:23] <pitti> good night everyone, have a nice weekend!
[17:23] <seb128> rickspencer3, isn't working in Ubuntu great ;-)
[17:23] <seb128> pitti, thanks, enjoy your weekend as well!
[17:25] <didrocks> enjoy your week-end pitti
[17:36] <rickspencer3> seb128, indeed!
[17:53] <kiwinote> mvo: lp:~kiwinote/gdebi/use-python-apt and lp:~kiwinote/python-apt/merge-gdebi-changes
[17:53] <kiwinote> mvo: the latter includes my patches from yesterday
[17:59] <mvo> kiwinote: thanks. cache.downloadable() can go, there is "package.candidate.downloadable" now
[17:59] <mvo> kiwinote: I guess that needs updating in the debfile.py as well, let me check
[18:04] <mvo> kiwinote: and for get_providers_for() I wonder if we can merge that with get_providing_packages() they are very similar
[18:04] <didrocks> kenvandine: is there a way to know if couchdb has finished or not its replication?
[18:05] <kenvandine> ~/.cache/desktop-couch/log/desktop-couch-replication.log
[18:05] <kenvandine> didrocks, ^^
[18:05] <didrocks> kenvandine: no API :)
[18:05] <didrocks> ?
[18:05] <kenvandine> probably
[18:06] <mvo> kiwinote: hm, I guess a mail is better than irc :)
[18:06] <kenvandine> ask CardinalFang in #ubuntuone
[18:06] <kenvandine> didrocks, that is the current documentation :)
[18:06] <kenvandine> didrocks,  did you say futon wasn't working for you too?
[18:06] <didrocks> kenvandine: ok, is it intended to clean this log one day
[18:06] <didrocks> kenvandine: yeah
[18:06] <kenvandine> i think it is rotated now
[18:07] <didrocks> kenvandine: because it's something like 65 MB here
[18:07] <kenvandine> oh that is nothing
[18:07] <kenvandine> :)
[18:07] <didrocks> kenvandine: and on lucid, before reformatting it went to 300 MB
[18:07] <kenvandine> in feb at the sprint... we looked at mine, and it was 1.5G
[18:07] <kenvandine> do you have .1, .2?
[18:07] <kenvandine> etc
[18:07] <kenvandine> or actually .[date]
[18:08] <kenvandine> although... i have nearly a months worth of logs there
[18:08] <kenvandine> i hope it deletes old ones...
[18:10] <didrocks> kenvandine: I have .[date]
[18:10] <didrocks> but very old
[18:10] <kenvandine> humm.. i have a bunch
[18:10] <kenvandine> weird
[18:11] <didrocks> kenvandine: can you ask OLS to work on that? it's hundreds of MB spoilt there
[18:11] <didrocks> (and I don't use gwibber)
[18:11] <kenvandine> yeah... ok
[18:12] <kenvandine> well my whole directory is 31M
[18:12] <kenvandine> is the current file the big one?
[18:13] <mvo> kiwinote: the gdebi changes look fine, thanks for workinG on this
[18:14] <didrocks> 328M/home/didrocks/.cache/desktop-couch/log/
[18:14] <didrocks> if every softwares did that…
[18:14] <didrocks> kenvandine: no, it's not the biggest
[18:14] <didrocks> kenvandine: but would be nice to make some cleaning there…
[18:15] <didrocks> even my weechat log folder, which is older is smaller. and I'm on 30 irc channels everyday
[18:15] <kenvandine> yeah
[18:48] <kiwinote> mvo: thanks for the comments, will fix those this evening
[18:49] <kiwinote> mvo: I will look at automatic testing sometime later
[18:55] <om26er> fta, there?
[18:56] <om26er> fta, gwibber-daily needs to depend on python-libproxy else gwibber dont start.
[19:11] <fta> kenvandine, ^^ (gwibber), do you still maintain it?
[19:11] <kenvandine> yup
[19:11] <kenvandine> which branch is it again that the dailies pull from?
[19:11] <fta> bug 597744
[19:11] <ubot2> Launchpad bug 597744 in gwibber "Missing dependancy: python-libproxy (affects: 9) (dups: 3) (heat: 36)" [Undecided,Confirmed] https://launchpad.net/bugs/597744
[19:12] <fta> kenvandine, http://bazaar.launchpad.net/~fta/+junk/ppa-confs/annotate/head:/ppabot-pkgs-gwibber.conf
[19:13] <fta> let me know if it's now in another branch
[19:16] <kenvandine> i am merging the dep change into that branch
[19:16] <kenvandine> sorry, i forgot about your dailies :)
[19:17] <fta> thanks
[19:17] <fta> kenvandine, it seems lots of people are using those dailies
[19:18] <kenvandine> fta, i pushed the change to that branch... but i can't build it locally
[19:18] <kenvandine> fails to construct the tarball... no time to look at it...
[19:18] <kenvandine> sorry, hopefully your daily will build :)
[19:19] <fta> respinning, we'll know soon enough
[19:22] <kenvandine> thx fta
[19:26]  * kenvandine -> lunch... bbiab
[20:06] <ccheney> seb128, if i disappear over the next week unexpectedly it will be due to a medical emergency, i can fill you guys in later if you want to know
[20:08] <ccheney> seb128, my wife might have to be hospitalized, she is going to see a doctor on tuesday afternoon if she is ok until then
[20:11] <seb128> ccheney, oh ok, thanks for letting us know and take care of your wife, work tasks can wait
[20:12] <ccheney> seb128, ok, i think that she will be ok, she's going downhill but not nearly as rapidly as back in sep 2007 (not sure if you knew about that)
[20:12] <ccheney> seb128, and we think we might finally know the root cause of the problem
[20:15] <seb128> ccheney, (no I didn't) ok, that's a least something I guess, let us know how it goes
[21:18] <fta> *sigh* http://codereview.chromium.org/2838023
[21:54] <fta> kenvandine, https://bugs.edge.launchpad.net/gwibber/+bug/597744/comments/3
[21:54] <ubot2> Launchpad bug 597744 in gwibber "Missing dependancy: python-libproxy (affects: 9) (dups: 3) (heat: 36)" [Undecided,Fix released]