[01:01] <rickspencer3> robert_ancell: welcome back, glad your on the mend
[01:01] <rickspencer3> thanks for the great call, I'm going to log off in a moment
[01:04] <robert_ancell> rickspencer3: no problem
[01:51] <MagicFab> hi all
[01:53] <MagicFab> how do I *disable* update check from command line ? (same as system >admin>update manager>settings...>updates tab>automatic update>uncheck [ ] check for updates) ?
[06:35] <pitti> Good morning
[07:01] <pitti> bryce: now I know what you meant with exchanging bugs, just reported my first UXA hang to upstream :/
[07:01] <pitti> bryce: thanks a lot for preparing the -intel jaunty patch!
[07:02] <pitti> bryce: perhaps we should put it into -proposed immediately, to get some more widespread testing?
[07:02] <bryce> pitti: sure
[07:02] <pitti> bryce: I can do that for you (plus reenable compiz in -proposed), so that you can get to sleep
[07:03] <bryce> pitti: thanks, _greatly_ appreciated
[07:03]  * pitti hugs bryce
[08:18] <pitti> hey seb128
[08:18] <seb128> hello pitti
[08:36] <robert_ancell> seb128: pitti: hi guys
[08:37] <seb128> hello robert_ancell
[08:37] <seb128> robert_ancell: how was the bug fighting today?
[08:38] <robert_ancell> I got caught on a wild goose chase - I had a quick look at bug 350683 but it seems to be something weird going on in GTK+. Instead of adding a border to the 22x22 icon (as it does for other icons) it scales down the 32x32
[08:39] <seb128> the solution for such issues is to have the right variant
[08:39]  * robert_ancell has been through the bowels of GTK+/glib/gio and boy does it have a lot of indirection
[08:40] <robert_ancell> if you create a 24x24 icon it still doesn't work...
[08:41] <seb128> did you update the icon cache?
[08:41] <didrocks> hi robert_ancell & seb128
[08:41] <seb128> lut didrocks
[08:41] <robert_ancell> seb128: updated icon cache, menus, restarted gnome-panel
[08:42] <seb128> robert_ancell: that doesn't make sense
[08:45] <robert_ancell> seb128: no, you're right.  I just tried it again and now it works...
[08:45] <seb128> robert_ancell: anyway let's not spend too much efforts on small graphical glitch
[08:45] <seb128> robert_ancell: ah ;-)
[08:45] <seb128> robert_ancell: did you manage to investigate the rhythmbox codec issue?
[08:45] <robert_ancell> seb128: well I learnt a lot about icon loading anyway
[08:46] <robert_ancell> seb128: still haven't found the cause
[08:46] <seb128> that's not wasted effort then ;-)
[08:46] <seb128> robert_ancell: what does gst-typefind says for the buggy file?
[08:47] <robert_ancell> application/x-id3
[08:48] <seb128> ok, I guess the bug is not that trivial ;-)
[08:48] <seb128> what else did you look at today?
[08:49] <robert_ancell> been looking at ekiga on the request of rick
[08:50] <seb128> specific issues? or just trying to get the bug list under control?
[08:51] <seb128> I need to speak to rick, first compiz and new ekiga, soon you will have no free slot for GNOME ;-)
[08:51] <robert_ancell> seb128: getting the hang of the bugs.  I started trying to fix a bug but my ekiga segfaulted for an entirely different reason :)
[08:52] <robert_ancell> good point - what are the gnome packages most in need of love at the moment?
[08:56] <seb128> robert_ancell: bug triage wise or bug fixing?
[08:56] <robert_ancell> seb128: fixing
[08:56] <pitti> some aren't even maintained in the first place
[08:57] <pitti> I was hoping that kenvandine_wk fell in love with ekiga enough to take that
[08:57] <seb128> robert_ancell: nothing too urgent, jaunty is quite in shape and karmic just opened
[08:57] <seb128> robert_ancell: totem and gstreamer could do with some upstreaming of issues though
[08:57] <seb128> robert_ancell: so keep the work you have started there ;-)
[08:58] <robert_ancell> are there any gstreamer experts here?  I've been doing some gstreamer work but its a complex codebase to get into so been making slow progress
[08:58] <pitti> robert_ancell: slomo is maintaining them quite actively
[08:58] <pitti> just not online right now
[08:59] <robert_ancell> pitti: thanks, will look him up for questioning :)
[09:00] <seb128> robert_ancell: oh btw tomorrow is a national holiday there
[09:00] <seb128> so I will not be around, or not early in the morning at least
[09:00] <robert_ancell> seb128: ok, will see you next week then
[09:01] <seb128> right
[09:01] <seb128> I'm still there for the day though ;-)
[09:02] <seb128> I think you already have some bugs on your list and if you are bored with those triaging some desktop bugs is welcome
[09:02] <robert_ancell> It'll be Friday night - I wont!!
[09:02] <seb128> hehe
[09:04] <robert_ancell> seb128: question regarding the gtk icon cache - I built a new ekiga with the new icon and installed it but that doesn't trigger the icon cache?  Is there a way to make apt trigger that?
[09:05] <seb128> robert_ancell: dh_icons should be used in the debian rules
[09:05] <seb128> which would add the cache update to /var/lib/dpkg/info/ekiga.postinst
[09:06] <robert_ancell> it's missing... I'll fix that up tomorrow then
[09:06] <seb128> though hicolor seems to be on a not-cache list for some reason
[09:06] <seb128> I need to investigate that
[09:31] <robert_ancell> seb128: pitti: everyone:  Do you know if the codec installer is part of the standard rhythmbox?
[09:31] <seb128> robert_ancell: yes, we have no ubuntu change
[09:31] <pitti> seb128: oh, I thought it was a local ubuntu feature
[09:32] <seb128> pitti: easy codec install in gstreamer has been canonical sponsored work in gutsy?
[09:32] <seb128> but it has landed upstream
[09:32] <seb128> gnome-app-install is the ubuntu part
[09:32] <seb128> the upstream code allow to call any codec installer you want
[09:32] <seb128> or gnome-codec-install now
[09:33] <robert_ancell> seb128: so is it triggered through rhythmbox or gstreamer?
[09:33] <seb128> robert_ancell: rhythmbox uses the gstreamer feature
[09:35] <seb128> robert_ancell: see shell/rb-missing-plugins.c
[09:35] <robert_ancell> seb128: thanks, been looking through that#
[09:36] <pitti> seb128: ah, right, I remember
[09:41] <robert_ancell> off now, see you guys later
[09:41] <seb128> robert_ancell: have fun, see you next week
[10:01] <huats> hello everyone !
[10:04] <seb128> lut huats
[10:05] <huats> hey seb128 :)
[10:53] <asac> anyone running karmic yet?
[10:54] <asac> in case: xulrunner-1.9 --gre-version ... does that work there?
[10:55] <pitti> asac: o/
[10:55] <pitti> $ xulrunner-1.9 --gre-version
[10:55] <pitti> 1.9.0.10
[10:55] <asac> hmm
[10:55] <asac> odd i have someone who gets bus-errors
[10:55] <asac> ;)
[10:55] <asac> thanks for confirming
[10:58] <pitti> asac: amd64 here
[10:58] <crevette> huats, hey
[10:59] <huats> hello crevette
[10:59]  * pitti uploads the devicekit/gnome-disk-utility/gvfs-devkit crack into desktop ppa
[11:00] <pitti> still a bit rough, but works
[11:00] <asac> pitti: so how would one use devicekit to get info about wifi/modem devices?
[11:00] <asac> is it just udev through dbus?
[11:01] <pitti> asac: right now you can't
[11:01] <asac> ;)
[11:01] <asac> whats the plan in future?
[11:01] <pitti> asac: there's no devkit-network just yet
[11:01] <pitti> asac: I'm not sure, but probably just asking udev
[11:01] <asac> yeah
[11:01] <pitti> I don't see the value of having another daemon for that
[11:01] <pitti> i. e. a devkit-network _and_ networkmanager
[11:02] <pitti> since NM is already a d-bus service for net devices
[11:02] <asac> pitti: right. but NM folks say they want to move away from hal to devkit
[11:02] <pitti> asac: but about the plan, you tell me :)
[11:02] <pitti> devkit -s net
[11:02] <pitti> that works quite fine
[11:03] <pitti> but of course DK itself doesn't offer special services what to _do_ with net devices, you can just enumerate and monitor their appearance/disappearance
[11:03] <asac> indeed
[11:03] <asac> yeah. enumeration and monitoring is all NM needs
[11:03] <asac> so seems its just a udev wrapper on that level?
[11:04] <pitti> asac: yes, DK itself is just a shim to make the udev db available over d-bus
[11:04] <pitti> devicekit will probably disappear entirely sooner or later
[11:04] <pitti> in favor of dk-* talking to udev directly
[11:04] <asac> cool. so i think i understood the mystery then ;)
[11:05] <pitti> there's pulse, network-manager, and X.org input
[11:05] <pitti> if we can solve these three in karmic, we can stop shipping hal by default
[11:05] <pitti> GNOME seems to go well, I played with git snapshots and patches, and I have it running without hal/gnome-mount now
[11:06] <pitti> still pretty rough, and currently breaks libgphoto, cdda, and obexftp backends, but we still have time
[11:06] <pitti> gnome-power-manager/dk-power is in karmic already
[11:06] <asac> we should definitly keep hal for another round ... modemmanager which we want to use (if not in main distro, definitly in oem builds) probably wont be ready for non-hal
[11:06] <pitti> asac: oh, I'm not saying that we can remove the package ;)
[11:06] <asac> ;)
[11:06] <asac> kk
[11:06] <pitti> asac: there are hundreds of packages depending on hal
[11:07] <asac> hehe
[11:07] <pitti> asac: it would just be nice to throw it out of the standard install
[11:07] <asac> yeah. lets see. maybe modemmanager will get a hardware detection re-write soon. have to check that
[11:07] <pitti> so if you install modemmanager, it'll pull in hal, but that's fine
[11:08] <pitti> hal can coexist just fine with dk-*
[11:08] <pitti> (anything else would be sheer madness)
[11:08] <asac> yeah. thats all just guess work anyway. personally i would prefer to have modemmanager by default even; but then, it should at least go to the same approach that NM currently uses: udev rules
[11:09] <pitti> asac: if we don't manage to throw it out in karmic, so be it
[11:09] <pitti> asac: but with lazy lobster being LTS (most probably), I'd like to do the painful transitions rather earlier
[11:10] <crevette> asac, just write the patch for moemmanager to use dk instead of hal :)
[11:10] <crevette> it is so simple :)
[11:11] <asac> pitti: so in hal we label/mark devices ... now in udev we also label/mark devices somehow (e.g. by adding "env" entries). does devicekit have his own label/mark config format?
[11:11] <asac> or will it just use whatever udev adds to env?
[11:11] <pitti> asac: no, dk doesn't store anything itself
[11:11] <asac> ok. so really just a projection of udev db.
[11:11] <pitti> you can use it to store properties in the udev db (I think)
[11:12] <asac> crevette: indeed. not really sure why devicekit is better than libudev though
[11:12] <pitti> asac: that's indeed the reason why it will disappear again
[11:13] <asac> but probably just the "its modern because its dbus" ;)
[11:13] <pitti> asac: talking to udev directly is just fine
[11:13] <crevette> I was kidding, but honnestly I don't know API of udev /hal /dk so I can't help
[11:13] <pitti> asac: if you are a daemon running as root, you can use udev
[11:13] <pitti> asac: but if you are an user session program, you can't (since the netlink socket is root only)
[11:13] <asac> very true
[11:14] <crevette> modemmanager is the piece of code to work with NM for modem right?
[11:16] <asac> yeah
[11:16] <asac> https://edge.launchpad.net/~modemmanager/+archive/ppa
[11:22] <pitti> seb128: mind if I delete some cruft from desktop ppa?
[11:22] <seb128> pitti: no, feel free to clean anything you see as outdated or not useful
[11:22] <pitti> seb128: the ones which have newer versions in jaunty
[11:23] <seb128> sure, I trust you to clean things which make sense ;-)
[11:23] <asac> i think PPAs should not display those by default that are superseeded in real archive ;)
[11:24] <pitti> ok, done
[11:30] <Ampelbein> seb128: hi. i finished working on the merge of gnome-vfs, bug 369395. but i do have a question about it: http://paste.ubuntu.com/161314/ - is the result of list-missing. What can I do about that? From the *.install files I see the doc-files should have been installed to the -dev package. This is confirmed by looking at the package.
[11:30] <seb128> Ampelbein: hi, they are probably just moved to an another directory?
[11:34] <Ampelbein> seb128: or could be the utils.mk list-missing hook be flawed? because the files are installed but list-missing doesn't seem to notice.
[11:34] <seb128> Ampelbein: they are installed in the exact same directory than the debian/tmp one?
[11:35] <Ampelbein> seb128: not exactly the same.
[11:35] <seb128> ok, so that's why they are listed
[11:35] <Ampelbein> ah, now i think i understand.
[11:35] <seb128> this code compare debian/tmp with all binaries
[11:35] <seb128> it's not clever enough to track renames and moves
[11:36] <seb128> that's why the schemas are listed too
[11:36] <seb128> they are moved to usr
[11:39] <Ampelbein> ok.
[11:41] <Ampelbein> another problem: the /usr/lib/gnome-vfs-2.0/modules/libnntp.so is not installed and looking at previous releases never was installed because it's missing in libgnomevfs2-0.install: debian/tmp/usr/lib/gnome-vfs-2.0/modules/lib{network,file,tar,computer,gzip,vfs-test,sftp,dns-sd}.so - should I fix that?
[11:43] <seb128> look to the changelog that might be on purpose
[11:44] <Ampelbein> seb128: only mention was a changelog entry from 2004.
[11:44] <Ampelbein> seb128: http://paste.ubuntu.com/161328/
[11:44] <seb128> right and gnome-vfs didn't change since
[11:45] <seb128> don't change that
[11:45] <Ampelbein> ok
[11:47] <asac> karmic has gcc 4.4 right?
[11:48] <Ampelbein> asac: gcc (Ubuntu 4.4.0-0ubuntu5) 4.4.0
[11:48] <asac> gcc --version
[11:48] <asac> please
[11:48]  * asac thinks about upgrading
[11:50] <Ampelbein> seb128: final question: while applying the patches, patch complained about offsets in some debian-patches. I figure I should not update them to apply cleanly as to not create additional diff?
[11:50] <seb128> Ampelbein: right
[11:51] <Ampelbein> seb128: ok, then I think the debdiff is good for review.
[11:52] <Ampelbein> thanks for answering my questions.
[11:52] <seb128> thank you for working on the update
[13:17] <seb128> does anybody how to add color to a wiki table for a row?
[13:19] <vuntz> dobey: hey, so I tested your intltool patch
[13:19] <vuntz> dobey: works fine, except one little thing...
[13:19]  * vuntz creates a small patch
[13:19] <james_w> seb128: check the bugday pages
[13:19] <james_w> seb128: it's something like <bgcolor="#dddddd">
[13:19] <seb128> james_w: thanks
[13:20] <vuntz> dobey: if test -h $script -o ! -s $script; then rm -f $script; fi
[13:20] <vuntz> dobey: instead of if test -h $script; then rm -f $script; fi
[13:21] <vuntz> dobey: (to remove empty files that were created with touch in the past)
[13:23] <asac> gnome-web-photo ... will this use webkit in karmic?
[13:23]  * asac reviews xulrunner rdepends
[13:24] <seb128> asac: ask chpe
[13:25] <asac> k
[13:25] <seb128> asac: you are trying to move things away from using xul? ;-)
[13:26] <asac> i could spend lots of time on webkit if i wouldnt need to do lengthy backports
[13:26] <asac> actually i dont mind whether its webkit or the new mozilla embedding api
[13:27] <asac> just as long as our rdepends dont touch into the moving xulrunner apis ;)
[13:28] <asac> but i guess it will take ages or a bunch of archive removals to get there
[13:30] <seb128> asac: GNOME is moving slowly to webkit
[13:30] <seb128> epiphany-webkit will be default this cycle
[13:30] <asac> thats a good start. do you know which apps are lagging behind for webkit support?
[13:31] <asac> i think that helping out there would be better spend than doing backports forever ;)
[13:35] <seb128> asac: evolution? ;-) but it doesn't use xulrunner either, just gtkhtml
[13:36] <kenvandine_wk> seb128: the components in orange, you looking for people to pick those up?
[13:36] <seb128> asac: otherwise I think that everything in the GNOME desktop (ie what we have on the CD) is webkit ready
[13:37] <seb128> kenvandine_wk: those are the components not maintained actively right now yes
[13:37] <kenvandine_wk> i spend quite a bit of time in f-spot... would be happy to take that
[13:37] <seb128> kenvandine_wk: I'm going to add some extra colors
[13:37] <seb128> I just need to decide on which ones ;-)
[13:37] <kenvandine_wk> hehe
[13:38] <seb128> I'm wondering if "green" for all the things actively worked is useful
[13:38] <seb128> or would rather make too much color
[13:38] <kenvandine_wk> yeah... seems kind of silly since most things should be worked on
[13:38] <seb128> and I'm pondering a light color for "easy things"
[13:38] <kenvandine_wk> i would focus on highlighting the things that are different
[13:39] <seb128> ie things which are mostly done by debian where we should look to bugs every now and then
[13:39] <seb128> and which are not moving too much upstream either
[13:39] <seb128> the alacarte sort of thing
[13:39] <kenvandine_wk> yeah
[13:39] <kenvandine_wk> makes sense
[13:50] <seb128> kenvandine_wk: ok, I added some yellow lines now
[13:56] <asac> willl archive refuse to accept binaries when there are NEW for some archs? like https://edge.launchpad.net/ubuntu/+source/xcb-util/0.3.4-1
[13:58] <asac>  libcairo2-dev: Depends: libcairo2 (= 1.8.6-1ubuntu2) but it is not going to be installed
[13:58] <asac>                  Depends: libxcb-render-util0-dev but it is not installable
[13:59] <seb128> asac: they will go to NEW
[13:59] <seb128> asac: and it could be that they have been accepted to universe but that's a main package trying to use those
[13:59] <asac> hmm
[13:59] <asac> but they are DONE except for one arch
[13:59] <james_w> only ppc is in NEW
[14:00] <asac> yeah. so will the others DONE go to NEW or have they been newed and wait for ppc?
[14:00] <asac> (to get to ACCEPTED)
[14:01] <james_w> they should be in the archive
[14:01] <james_w> libxcb-render-util0-dev |    0.3.4-1 |        karmic | hppa
[14:01] <james_w> libxcb-render-util0-dev |    0.3.4-1 | karmic/universe | amd64, armel, i386, lpia
[14:03] <asac> ok so they need to be put to main?
[14:03] <james_w> sounds like it
[14:03] <james_w> was your paste from a build log?
[14:04] <asac> yes: http://launchpadlibrarian.net/26174824/buildlog_ubuntu-karmic-i386.xulrunner-1.9_1.9.0.10%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[14:04] <james_w> yeah, so it's a component mismatch
[14:05] <asac> but its not a new depends of cairo-dev
[14:05] <seb128> re
[14:05] <james_w> http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt has it
[14:05] <asac> so they were demoted?
[14:05] <james_w> possibly
[14:06] <asac> who did that? sounds like an accident
[14:08] <seb128> asac: binaries go to universe by default
[14:08] <seb128> have those ever been in main?
[14:08] <asac> seb128: well. that package isnt new afaics
[14:08] <asac> seb128: libcairo2-dev depends on that package in jaunty
[14:08] <seb128> which one?
[14:09] <asac> ibxcb1-dev, libxcb-render0-dev, libxcb-render-util0-dev
[14:09] <asac> libxcb1-dev, libxcb-render0-dev, libxcb-render-util0-dev
[14:21] <dobey> vuntz: cool, thanks
[14:22] <seb128> hey rickspencer3
[14:23] <seb128> asac: on what arch do you have the issue?
[14:25] <pitti> hey rickspencer3
[14:25] <seb128> pitti: wb
[14:25] <seb128> so
[14:25] <seb128> pitti, rickspencer3: https://wiki.ubuntu.com/DesktopTeam/Components first version
[14:25] <rickspencer3> hey pitti, seb128, asac
[14:25] <seb128> orange = need extra work
[14:25] <rickspencer3> thanks seb128!
[14:25] <seb128> yellow = easy components
[14:26] <seb128> white = everything else
[14:26] <rickspencer3> kick ass!
[14:26] <pitti> seb128: that's excellent, thanks!
[14:26] <seb128> we don't have most bindings there though
[14:26] <rickspencer3> does "debian" mean you feel ilt does not require a Ubuntu maintainer?
[14:26] <seb128> ie *gnome{java,mm,perl}
[14:26] <seb128> rickspencer3: no, it means most of the work is done by debian (ie we are on sync)
[14:27] <pitti> can we add tracker to that list? (or demote it)
[14:27] <seb128> pitti: that's an open list, please add it as orange
[14:27]  * pitti does
[14:27] <pitti> chrisccoulson might want to put his name there :)
[14:27] <seb128> I used the desktop-bugs package report for a base
[14:28] <seb128> and the team is not subscribe to tracker
[14:28] <seb128> (and some others that I added)
[14:28] <pitti> seb128: desktop-bugs is basically "needs maintainer", right?
[14:28] <seb128> pitti: no, "desktop-bugs" and white is basically "need somebody to look to bugs every now and then and those components are covered"
[14:28] <pitti> oh, ok
[14:29] <seb128> pitti: ie those which I feel pedro and I and bug triager cover correctly
[14:29] <pitti> I have it as yellow/desktop-bugs right now
[14:29] <seb128> nobody assigned specifically but we do the job
[14:29] <seb128> pitti: which one?
[14:29] <pitti> tracker (just added)
[14:29] <seb128> orange would be better?
[14:29] <pitti> sorry, I meant "orange"
[14:29] <seb128> ok good
[14:30] <pitti> done
[14:30] <seb128> pitti: so right, "desktop-bugs" is ... team is trying to do what it can but nobody is specifically assigned
[14:30] <seb128> when desktop-bugs is not there is that we slack totally on it
[14:31] <seb128> though desktop-bugs could be added on some easy components lines
[14:31] <seb128> as said that's a rough first version
[14:31] <seb128> I'm open to suggestions for changes ;-)
[14:31]  * pitti hugs seb128, good work on that
[14:32]  * seb128 hugs pitti back
[14:33] <rickspencer3> seb128: those are package names, right? So it would be trivial for me to use launchpad lib to get bug status on those?
[14:34] <seb128> rickspencer3: yes
[14:34] <seb128> rickspencer3: source package names
[14:34] <rickspencer3> seb128: interesting point about evolution-exchange
[14:35] <seb128> rickspencer3: the list is basically https://bugs.edge.launchpad.net/~desktop-bugs/+packagebugs with tweaking
[14:35] <pitti> rickspencer3: if only we had a former MS employee who could provide that :-P
[14:35] <rickspencer3> pitti: hmmm
[14:35] <seb128> lol
[14:36] <rickspencer3> I can't get cheap licenses for business use, only for "personal" use :(
[14:36] <pitti> j/k
[14:36] <seb128> for the record I'm not interested to get an exchange license even if somebody can get me one ;-)
[14:36] <rickspencer3> I wonder if we can just rent the service from someone though
[14:36] <rickspencer3> seb128: I was hoping you would be running Vista. Aren't you doing that now?
[14:36]  * rickspencer3 ducks
[14:37] <seb128> sure, I'm only running this ubuntu thing in vmware under vista
[14:37] <pitti> so that's what the gnome 3.0 theme is called like then :)
[14:37] <rickspencer3> lol
[14:37] <rickspencer3> !
[14:37] <seb128> why do you think my intel card is working correctly?
[14:37] <seb128> ;-)
[14:37] <rickspencer3> oh man, I needed a good laugh
[14:43] <jcastro> godaddy has hosted exchange for 7 bucks a month or something
[14:43] <jcastro> I have a guy I roped in for likewise testing that might be able to test exchange, I'll find out
[14:45] <kenvandine_wk> jcastro: that would rock
[14:45] <kenvandine_wk> i know none of us want to do it :)
[14:46]  * kenvandine_wk has never used exchange... amazing at my age to have never worked anywhere with exchange :-D
[14:46] <seb128> my current way is to comment on the bugs asking to people to open a bug directly to GNOME if they can
[14:46] <seb128> explaining that we are short on people having access to exchange servers and that GNOME guys would be able to work better on those issues
[14:47] <jcastro> heh, ok, this guy can test karmic VMs or PPAs, and he does have an exchange environment so if we have like a set of tests or something
[14:47] <jcastro> seb128: I assume the upstream novell evo guys would have access to exchange? or do the bugs just pile up there?
[14:47] <seb128> they do have access
[14:48] <seb128> same for evolution-mapi
[14:48] <seb128> the redhat guys have some access too apparently
[14:48] <jcastro> -mapi is the openchange one right? the one that is supposed to work better?
[14:48] <seb128> the one which is new
[14:48] <jcastro> right
[14:48] <seb128> and support exchange 2007
[14:48] <seb128> I would not say "better"
[14:49] <jcastro> well, it doesn't screen scrape like -exchange does I don't think
[14:49] <seb128> right
[14:49] <seb128> but it's a bit new
[14:49] <seb128> no doubt it will be better ;-)
[14:51] <hyperair> did someone say exchange?
[14:51]  * hyperair uses exchange to access his university email
[14:53] <dobey> jcastro: evolution-exchange doesn't screenscrape. it uses the outlook web access api
[14:53] <seb128> hyperair: we are short on people having access to exchange and wanting to upstream and triage launchpad bugs for it and evolution-mapi too
[14:53] <hyperair> hmm. i think i can help with that.
[14:53] <hyperair> i've fixed an exchange bug before
[14:53] <hyperair> and i'll be having access to exchange for at least the next 3 years
[14:54] <jcastro> dobey: ah
[14:54] <dobey> i don't think i've ever used the exchange plug-in, but i've fixed plenty of bugs in it
[14:54] <seb128> hyperair: that would be nice thanks ;-)
[14:54] <hyperair> seb128: is there a todo anywhere?
[14:54] <jcastro> seb128: so maybe in this cycle when we have a hug day on evo we should try to find people with access to exchange
[14:54] <seb128> jcastro: right
[14:54] <seb128> jcastro: we usually don't have days for evolution though
[14:55] <jcastro> I think a -mapi day might work if we find people
[14:55] <seb128> indeed
[14:55] <seb128> hyperair: not really, just a pile of untriaged launchpad bugs
[14:55] <jcastro> I'll work on finding people with exchange to triage bugs and whatnot
[14:55] <hyperair> seb128: i'll go dig through them then. what's the source package name again?
[14:55] <seb128> hyperair: I think a good part could be triaged without access to exchange though
[14:55] <seb128> hyperair: https://edge.launchpad.net/ubuntu/+source/evolution-exchange/+bugs
[14:56] <seb128> hyperair: https://edge.launchpad.net/ubuntu/+source/evolution-mapi/+bugs
[14:56] <seb128> jcastro: I've been trying to convince the server team without too much success
[14:57] <jcastro> convince them to do what?
[14:57] <mvo> lool: thanks for your debian compiz abiver patches, that is a good idea, I integrate them into the ubuntu compiz now
[14:58] <seb128> jcastro: that exchange access is a server feature ;-)
[14:58] <seb128> jcastro: ie that they should be looking at those bugs and do testing
[14:59] <jcastro> ah
[14:59] <jcastro> seb128: hot potato no one wants I gather.
[14:59] <seb128> indeed
[15:00] <jcastro> at the minimum I'll start hunting for testers.
[15:01] <jcastro> seb128: -mapi is supposed to supercede -exchange right? At least eventually?
[15:02] <seb128> jcastro: I think so, though I'm not sure
[15:02] <seb128> jcastro: I don't need if there is setups where you just have access to the web interface
[15:02] <seb128> jcastro: ie firewall blocking whatever mapi is using
[15:02] <jcastro> most exchange people I know shut off the web interface anyway
[15:02] <jcastro> so for some people -mapi is probably their only hope
[15:02] <asac> seb128: so the build failure happens on all archs
[15:03] <seb128> asac: what package?
[15:03] <asac> seb128: what do you mean? libcairo2-dev depends on it ... and its in universe.
[15:03] <asac> i guess that means all main packages with libcairo depend fail now
[15:03] <seb128> asac: ok, can we start from scratch? ;-)
[15:03] <asac> seb128: its xulrunner-1.9 rebuild
[15:03] <seb128> ok
[15:03] <seb128> let me look
[15:03] <asac> http://launchpadlibrarian.net/26174824/buildlog_ubuntu-karmic-i386.xulrunner-1.9_1.9.0.10%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
[15:03] <asac> good ;)
[15:07] <seb128> asac: somebody did send libxcb-render-util0-dev to universe indeed
[15:07] <asac> ok sounds like an accident
[15:07] <asac> please repromote
[15:08] <asac> or talk to whoever did that first ;)
[15:08] <seb128> somebody did overwrite all the queue binaries to universe
[15:08] <seb128> dunno why it was in binary NEW though
[15:10]  * hyperair never knew about mapi. will try now
[15:11] <asac> one binary package makes all binary packages pop up in new queue i guess
[15:11] <asac> from there its probably easy to just demote all ;)
[15:12] <seb128> asac: right
[15:20] <asac> seb128: will you promote and give back (with normal build score) xulrunner-1.9?
[15:20] <asac> (and others that might have failed due to cairo2 ;)
[15:26] <seb128> asac: I did promote, I can't give back with score though
[15:26] <seb128> I'm not buildd admin
[15:26] <seb128> I've no access to scoring
[15:26] <seb128> and retry get the lower priority possible I think
[15:26] <seb128> you need doko or pitti there
[15:27] <mvo> seb128: I think the compiz abi version mismatch madness is finally going away (well, hopefully :)
[15:27] <seb128> mvo: good ;-)
[15:33] <seb128> mvo: are the ubuntu and debian compiz packages much different nowadays?
[15:37] <mvo> seb128: yeah, I looked at them today
[15:37] <mvo> seb128: debian ships compiz-gtk in addtion to compiz-gnome, that seems a bit much to me
[15:37] <mvo> seb128: but then, we share most of the patches
[15:37] <seb128> mvo: and all the libs, etc?
[15:38] <mvo> how do you mean? that we have similar lib packages? that yes
[15:39] <seb128> mvo: I was just wondering how far we are from being able to sync libcompizconfig, etc
[15:39] <seb128> mvo: since debian has 0.8.2 too now
[15:40] <seb128> mvo: anyway I will have a look, I'm just asking before compiz should land on the desktop team plates this cycle
[15:40] <seb128> so I'm trying to figure how much we will get from debian
[15:40] <mvo> I think we could (should?) merge full with them, but that is a bit of a non-trivial operation and requires some convicing about e.g. compiz-gtk
[15:40] <seb128> and how much ubuntu work we have to do still ;-)
[15:40] <mvo> we have stuff like compiz-wrapper that we need to keep for kubuntu
[15:41] <seb128> mvo: well as compiz itself has change but I was expecting libcompizconfig, python, extra, etc to be syncable one day
[15:41] <mvo> its unlikely that we can just sync
[15:41] <mvo> yeah, the chances for that are much better indeed
[15:41] <mvo> we should co-mainain it, unfortunately they use git
[15:42] <mvo> and refuse to use cdbs (also cdbs is perfect for the simple packages)
[15:44] <seb128> right
[15:45] <mvo> I merged the abi depends patches now, that should be fine for now
[15:46] <mvo> I think we should be ok with the karmic version for some weeks, we should discuss it further at uds
[15:46] <mvo> (probably not in a official session, but just in between)
[15:47] <seb128> ok
[16:09] <pitti> I'm off for today then, will do another 15 mins of mail catchup and then I'll be gone until Monday
[16:09] <pitti> have a good weekend everyone!
[16:11] <seb128> same for me
[16:11] <seb128> pitti: enjoy your weekend
[16:11] <james_w> bye pitti, have a good one
[16:11] <james_w> you too seb128
[16:11] <pitti> seb128: enjoy the holiday tomorrow!
[16:12] <pitti> james_w: and you!
[16:12] <seb128> thanks
[16:12] <james_w> not for us :-)
[16:12] <seb128> on monday for you then?
[16:12] <james_w> not until Monday at least
[16:42] <chrisccoulson> everyones having a nice long weekend are they?
[16:44] <Ampelbein> yeah.
[16:44] <chrisccoulson> nice:)
[19:40] <salty-horse> can anyone confirm? open gnome-panel's "Run application" feature (with alt+f2?) and type "nautilus". The icon will be that of the cd burner
[19:41] <hyperair> salty-horse: i can confirm
[19:42] <pedro_> salty-horse: yeah confirmed, the icon is the one of brasero
[19:42] <salty-horse> any idea why that happens? /usr/share/applications/nautilus.desktop lists the correct file
[19:42] <salty-horse> and "show list of known apps" lists the cd creator
[19:58] <dobey> salty-horse: because the "cd creator" desktop launcher does "nautilus burn:///" or something like that
[19:58] <dobey> salty-horse: and it's getting indexed in front of the other nautilus launchers
[20:04] <salty-horse> dobey, know how to fix it? :)
[20:05] <dobey> no
[20:05] <mclasen> its the old problem of desktop files not being suitable as a real application registry...
[20:05] <dobey> well i get the nautilus-cd-burner icon instead of brasero
[20:06] <dobey> i don't think the storage method matters, if the sort for matches is still wrong
[20:13] <mvo> meh, tracker-indexer is eating all my IO here :(
[20:14] <chrisccoulson> mvo - you checked your ~/.local/share/tracker-indexer.log?
[20:14] <chrisccoulson> you haven't had a notification about a corrupt index no?
[20:14] <mvo> chrisccoulson: good question, I have not seen one, but then the machine was idle for ~1h
[20:15] <mvo> chrisccoulson: what should I look for in the log?
[20:15] <chrisccoulson> a whole load of "failed to store word" messages off the top of my head
[20:15] <chrisccoulson> you on karmic or jaunty?
[20:18] <mvo> chrisccoulson: jaunty, my log contains some:
[20:18] <mvo> 30 Apr 2009, 20:54:21: Tracker-Warning **: Invalid byte sequence in conversion input
[20:19] <chrisccoulson> i don't think those are anything to worry about. i always get a few of those when the indexer starts
[20:19] <chrisccoulson> if those are the only messages, then the indexer might just be working correctly. but IO performance seems to suck quite a bit in general at the moment :(
[20:27] <mvo> chrisccoulson: yeah :/
[20:27] <mvo> chrisccoulson: thanks!
[20:28] <chrisccoulson> which version of tracker are you running in jaunty at the moment? is it the version in jaunty-proposed?
[21:54] <mvo> chrisccoulson: sorry, I missied your earlier question. I was running the jaunty final version
[21:55] <mvo> chrisccoulson: well, I never use tracker, I was suprised that it turned itself on for me
[21:55] <chrisccoulson> mvo - there's a bug in the jaunty final version that causes indexing to start when you insert any removable media
[21:55] <chrisccoulson> that could be why
[21:55] <mvo> yeah
[21:55] <mvo> that makes sense
[21:56] <mvo> I inserted a usb stick just some minutes before
[21:56] <mvo> thanks chrisccoulson!
[21:56] <chrisccoulson> i've fixed that in jaunty-proposed, but that version contains a fix for another bug which some users are still having issues with
[22:03] <chrisccoulson> mvo - fwiw i've just been hovering over in #tracker, and it seems that the new sqlite FTS version of tracker is bringing some welcome performance improvements:)
[22:03] <chrisccoulson> and fixes some other annoying bugs which currently make tracker less-than-useful
[22:03] <mvo> nice
[22:03] <mvo> that is good to hear
[22:03] <mvo> when is it expected to land?
[22:04] <chrisccoulson> i'll ask them next week. if the timeframe is this cycle (which I think is pretty much guaranteed now), then it might be worth me taking a snapshot of current GIT and getting it in to karmic
[22:05]  * mvo nods
[22:05] <chrisccoulson> i'm going to try it out over the weekend anyway
[22:15] <pace_t_zulu> anyone interested in bug #36189
[22:34] <dobey> pace_t_zulu: seems to work ok here, at least with all the resolution changes that wine causes
[22:34] <pace_t_zulu> the bug still exists
[22:34] <dobey> pace_t_zulu: though i have lost windows from wine... it makes some stuff go off my screen, and out of the window list
[22:35] <dobey> pace_t_zulu: i think it only breaks if you don't lock the applets
[22:35] <dobey> pace_t_zulu: if you lock the applet's position it seems ok
[22:35] <pace_t_zulu> dobey: not true...
[22:35] <pace_t_zulu> dobey: witnessed it on coworker's machine with default layout... nothing changed
[22:36] <pace_t_zulu> dobey: but properties messed up... lose right_stick property
[22:36] <dobey> ah, well it seems ok on my machine anyway
[22:37] <dobey> and going down to 640x480 then back up to 2048x1152 would i think generally show the problem... but it doesn't here
[22:38] <pace_t_zulu> i am still seeing it in jaunty
[22:38] <pace_t_zulu> i think i have almost tracked it down
[22:52] <pace_t_zulu> dobey: I am getting close to pinpointing the bug
[22:52] <dobey> cool
[22:54] <pace_t_zulu> dobey: I think I have identified the function responsible
[22:55] <dobey> you should comment on the report and upstream then to help it get fixed... i was just stating that i don't see the problem on my machine
[23:02] <pace_t_zulu> dobey: do you have any applets on your panel(s)?
[23:02] <pace_t_zulu> dobey: any applets that have the "right stick" property set?
[23:03] <dobey> i don't know what the "right stick" property is
[23:03] <dobey> i have lots of applets on my panel though
[23:03] <dobey> and several are locked to the right side
[23:04] <dobey> clock/weather/volume/systray are all on the right side