[01:01] robert_ancell: welcome back, glad your on the mend [01:01] thanks for the great call, I'm going to log off in a moment [01:04] rickspencer3: no problem [01:51] hi all [01:53] 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] Good morning [07:01] bryce: now I know what you meant with exchanging bugs, just reported my first UXA hang to upstream :/ [07:01] bryce: thanks a lot for preparing the -intel jaunty patch! [07:02] bryce: perhaps we should put it into -proposed immediately, to get some more widespread testing? [07:02] pitti: sure [07:02] bryce: I can do that for you (plus reenable compiz in -proposed), so that you can get to sleep [07:03] pitti: thanks, _greatly_ appreciated [07:03] * pitti hugs bryce === tkamppeter_ is now known as tkamppeter [08:18] hey seb128 [08:18] hello pitti [08:36] seb128: pitti: hi guys [08:37] hello robert_ancell [08:37] robert_ancell: how was the bug fighting today? [08:38] 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:38] Launchpad bug 350683 in ekiga "launcher icon looks fuzzy" [Low,Triaged] https://launchpad.net/bugs/350683 [08:39] 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] if you create a 24x24 icon it still doesn't work... [08:41] did you update the icon cache? [08:41] hi robert_ancell & seb128 [08:41] lut didrocks [08:41] seb128: updated icon cache, menus, restarted gnome-panel === Zdra` is now known as Zdra [08:42] robert_ancell: that doesn't make sense [08:45] seb128: no, you're right. I just tried it again and now it works... [08:45] robert_ancell: anyway let's not spend too much efforts on small graphical glitch [08:45] robert_ancell: ah ;-) [08:45] robert_ancell: did you manage to investigate the rhythmbox codec issue? [08:45] seb128: well I learnt a lot about icon loading anyway [08:46] seb128: still haven't found the cause [08:46] that's not wasted effort then ;-) [08:46] robert_ancell: what does gst-typefind says for the buggy file? [08:47] application/x-id3 [08:48] ok, I guess the bug is not that trivial ;-) [08:48] what else did you look at today? [08:49] been looking at ekiga on the request of rick [08:50] specific issues? or just trying to get the bug list under control? [08:51] I need to speak to rick, first compiz and new ekiga, soon you will have no free slot for GNOME ;-) [08:51] 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] good point - what are the gnome packages most in need of love at the moment? [08:56] robert_ancell: bug triage wise or bug fixing? [08:56] seb128: fixing [08:56] some aren't even maintained in the first place [08:57] I was hoping that kenvandine_wk fell in love with ekiga enough to take that [08:57] robert_ancell: nothing too urgent, jaunty is quite in shape and karmic just opened [08:57] robert_ancell: totem and gstreamer could do with some upstreaming of issues though [08:57] robert_ancell: so keep the work you have started there ;-) [08:58] 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] robert_ancell: slomo is maintaining them quite actively [08:58] just not online right now [08:59] pitti: thanks, will look him up for questioning :) [09:00] robert_ancell: oh btw tomorrow is a national holiday there [09:00] so I will not be around, or not early in the morning at least [09:00] seb128: ok, will see you next week then [09:01] right [09:01] I'm still there for the day though ;-) [09:02] 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] It'll be Friday night - I wont!! [09:02] hehe [09:04] 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] robert_ancell: dh_icons should be used in the debian rules [09:05] which would add the cache update to /var/lib/dpkg/info/ekiga.postinst [09:06] it's missing... I'll fix that up tomorrow then [09:06] though hicolor seems to be on a not-cache list for some reason [09:06] I need to investigate that === sabdfl1 is now known as sabdfl [09:31] seb128: pitti: everyone: Do you know if the codec installer is part of the standard rhythmbox? [09:31] robert_ancell: yes, we have no ubuntu change === davmor21 is now known as davmor2 [09:31] seb128: oh, I thought it was a local ubuntu feature [09:32] pitti: easy codec install in gstreamer has been canonical sponsored work in gutsy? [09:32] but it has landed upstream [09:32] gnome-app-install is the ubuntu part [09:32] the upstream code allow to call any codec installer you want [09:32] or gnome-codec-install now [09:33] seb128: so is it triggered through rhythmbox or gstreamer? [09:33] robert_ancell: rhythmbox uses the gstreamer feature [09:35] robert_ancell: see shell/rb-missing-plugins.c [09:35] seb128: thanks, been looking through that# [09:36] seb128: ah, right, I remember [09:41] off now, see you guys later [09:41] robert_ancell: have fun, see you next week === dpm_ is now known as dpm [10:01] hello everyone ! [10:04] lut huats [10:05] hey seb128 :) [10:53] anyone running karmic yet? [10:54] in case: xulrunner-1.9 --gre-version ... does that work there? [10:55] asac: o/ [10:55] $ xulrunner-1.9 --gre-version [10:55] 1.9.0.10 [10:55] hmm [10:55] odd i have someone who gets bus-errors [10:55] ;) [10:55] thanks for confirming [10:58] asac: amd64 here [10:58] huats, hey [10:59] hello crevette [10:59] * pitti uploads the devicekit/gnome-disk-utility/gvfs-devkit crack into desktop ppa [11:00] still a bit rough, but works [11:00] pitti: so how would one use devicekit to get info about wifi/modem devices? [11:00] is it just udev through dbus? [11:01] asac: right now you can't [11:01] ;) [11:01] whats the plan in future? [11:01] asac: there's no devkit-network just yet [11:01] asac: I'm not sure, but probably just asking udev [11:01] yeah [11:01] I don't see the value of having another daemon for that [11:01] i. e. a devkit-network _and_ networkmanager [11:02] since NM is already a d-bus service for net devices [11:02] pitti: right. but NM folks say they want to move away from hal to devkit [11:02] asac: but about the plan, you tell me :) [11:02] devkit -s net [11:02] that works quite fine [11:03] 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] indeed [11:03] yeah. enumeration and monitoring is all NM needs [11:03] so seems its just a udev wrapper on that level? [11:04] asac: yes, DK itself is just a shim to make the udev db available over d-bus [11:04] devicekit will probably disappear entirely sooner or later [11:04] in favor of dk-* talking to udev directly [11:04] cool. so i think i understood the mystery then ;) [11:05] there's pulse, network-manager, and X.org input [11:05] if we can solve these three in karmic, we can stop shipping hal by default [11:05] GNOME seems to go well, I played with git snapshots and patches, and I have it running without hal/gnome-mount now [11:06] still pretty rough, and currently breaks libgphoto, cdda, and obexftp backends, but we still have time [11:06] gnome-power-manager/dk-power is in karmic already [11:06] 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] asac: oh, I'm not saying that we can remove the package ;) [11:06] ;) [11:06] kk [11:06] asac: there are hundreds of packages depending on hal [11:07] hehe [11:07] asac: it would just be nice to throw it out of the standard install [11:07] yeah. lets see. maybe modemmanager will get a hardware detection re-write soon. have to check that [11:07] so if you install modemmanager, it'll pull in hal, but that's fine [11:08] hal can coexist just fine with dk-* [11:08] (anything else would be sheer madness) [11:08] 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] asac: if we don't manage to throw it out in karmic, so be it [11:09] asac: but with lazy lobster being LTS (most probably), I'd like to do the painful transitions rather earlier [11:10] asac, just write the patch for moemmanager to use dk instead of hal :) [11:10] it is so simple :) [11:11] 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] or will it just use whatever udev adds to env? [11:11] asac: no, dk doesn't store anything itself [11:11] ok. so really just a projection of udev db. [11:11] you can use it to store properties in the udev db (I think) [11:12] crevette: indeed. not really sure why devicekit is better than libudev though [11:12] asac: that's indeed the reason why it will disappear again [11:13] but probably just the "its modern because its dbus" ;) [11:13] asac: talking to udev directly is just fine [11:13] I was kidding, but honnestly I don't know API of udev /hal /dk so I can't help [11:13] asac: if you are a daemon running as root, you can use udev [11:13] asac: but if you are an user session program, you can't (since the netlink socket is root only) [11:13] very true [11:14] modemmanager is the piece of code to work with NM for modem right? [11:16] yeah [11:16] https://edge.launchpad.net/~modemmanager/+archive/ppa [11:22] seb128: mind if I delete some cruft from desktop ppa? [11:22] pitti: no, feel free to clean anything you see as outdated or not useful [11:22] seb128: the ones which have newer versions in jaunty [11:23] sure, I trust you to clean things which make sense ;-) [11:23] i think PPAs should not display those by default that are superseeded in real archive ;) [11:24] ok, done [11:30] 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] Launchpad bug 369395 in gnome-vfs "Please merge gnome-vfs 2.24.1-1 from debian unstable" [Undecided,New] https://launchpad.net/bugs/369395 [11:30] Ampelbein: hi, they are probably just moved to an another directory? [11:34] 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] Ampelbein: they are installed in the exact same directory than the debian/tmp one? [11:35] seb128: not exactly the same. [11:35] ok, so that's why they are listed [11:35] ah, now i think i understand. [11:35] this code compare debian/tmp with all binaries [11:35] it's not clever enough to track renames and moves [11:36] that's why the schemas are listed too [11:36] they are moved to usr [11:39] ok. [11:41] 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] look to the changelog that might be on purpose [11:44] seb128: only mention was a changelog entry from 2004. [11:44] seb128: http://paste.ubuntu.com/161328/ [11:44] right and gnome-vfs didn't change since [11:45] don't change that [11:45] ok [11:47] karmic has gcc 4.4 right? [11:48] asac: gcc (Ubuntu 4.4.0-0ubuntu5) 4.4.0 [11:48] gcc --version [11:48] please [11:48] * asac thinks about upgrading [11:50] 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] Ampelbein: right [11:51] seb128: ok, then I think the debdiff is good for review. [11:52] thanks for answering my questions. [11:52] thank you for working on the update [13:17] does anybody how to add color to a wiki table for a row? [13:19] dobey: hey, so I tested your intltool patch [13:19] dobey: works fine, except one little thing... [13:19] * vuntz creates a small patch [13:19] seb128: check the bugday pages [13:19] seb128: it's something like [13:19] james_w: thanks [13:20] dobey: if test -h $script -o ! -s $script; then rm -f $script; fi [13:20] dobey: instead of if test -h $script; then rm -f $script; fi [13:21] dobey: (to remove empty files that were created with touch in the past) [13:23] gnome-web-photo ... will this use webkit in karmic? [13:23] * asac reviews xulrunner rdepends [13:24] asac: ask chpe [13:25] k [13:25] asac: you are trying to move things away from using xul? ;-) [13:26] i could spend lots of time on webkit if i wouldnt need to do lengthy backports [13:26] actually i dont mind whether its webkit or the new mozilla embedding api [13:27] just as long as our rdepends dont touch into the moving xulrunner apis ;) [13:28] but i guess it will take ages or a bunch of archive removals to get there [13:30] asac: GNOME is moving slowly to webkit [13:30] epiphany-webkit will be default this cycle [13:30] thats a good start. do you know which apps are lagging behind for webkit support? [13:31] i think that helping out there would be better spend than doing backports forever ;) [13:35] asac: evolution? ;-) but it doesn't use xulrunner either, just gtkhtml [13:36] seb128: the components in orange, you looking for people to pick those up? [13:36] asac: otherwise I think that everything in the GNOME desktop (ie what we have on the CD) is webkit ready [13:37] kenvandine_wk: those are the components not maintained actively right now yes [13:37] i spend quite a bit of time in f-spot... would be happy to take that [13:37] kenvandine_wk: I'm going to add some extra colors [13:37] I just need to decide on which ones ;-) [13:37] hehe [13:38] I'm wondering if "green" for all the things actively worked is useful [13:38] or would rather make too much color [13:38] yeah... seems kind of silly since most things should be worked on [13:38] and I'm pondering a light color for "easy things" [13:38] i would focus on highlighting the things that are different [13:39] ie things which are mostly done by debian where we should look to bugs every now and then [13:39] and which are not moving too much upstream either [13:39] the alacarte sort of thing [13:39] yeah [13:39] makes sense [13:50] kenvandine_wk: ok, I added some yellow lines now [13:56] 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] libcairo2-dev: Depends: libcairo2 (= 1.8.6-1ubuntu2) but it is not going to be installed [13:58] Depends: libxcb-render-util0-dev but it is not installable [13:59] asac: they will go to NEW [13:59] asac: and it could be that they have been accepted to universe but that's a main package trying to use those [13:59] hmm [13:59] but they are DONE except for one arch [13:59] only ppc is in NEW [14:00] yeah. so will the others DONE go to NEW or have they been newed and wait for ppc? [14:00] (to get to ACCEPTED) [14:01] they should be in the archive [14:01] libxcb-render-util0-dev | 0.3.4-1 | karmic | hppa [14:01] libxcb-render-util0-dev | 0.3.4-1 | karmic/universe | amd64, armel, i386, lpia [14:03] ok so they need to be put to main? [14:03] sounds like it [14:03] was your paste from a build log? [14:04] yes: http://launchpadlibrarian.net/26174824/buildlog_ubuntu-karmic-i386.xulrunner-1.9_1.9.0.10%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz [14:04] yeah, so it's a component mismatch [14:05] but its not a new depends of cairo-dev [14:05] re [14:05] http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt has it [14:05] so they were demoted? [14:05] possibly [14:06] who did that? sounds like an accident [14:08] asac: binaries go to universe by default [14:08] have those ever been in main? [14:08] seb128: well. that package isnt new afaics [14:08] seb128: libcairo2-dev depends on that package in jaunty [14:08] which one? [14:09] ibxcb1-dev, libxcb-render0-dev, libxcb-render-util0-dev [14:09] libxcb1-dev, libxcb-render0-dev, libxcb-render-util0-dev [14:21] vuntz: cool, thanks [14:22] hey rickspencer3 [14:23] asac: on what arch do you have the issue? [14:25] hey rickspencer3 [14:25] pitti: wb [14:25] so [14:25] pitti, rickspencer3: https://wiki.ubuntu.com/DesktopTeam/Components first version [14:25] hey pitti, seb128, asac [14:25] orange = need extra work [14:25] thanks seb128! [14:25] yellow = easy components [14:26] white = everything else [14:26] kick ass! [14:26] seb128: that's excellent, thanks! [14:26] we don't have most bindings there though [14:26] does "debian" mean you feel ilt does not require a Ubuntu maintainer? [14:26] ie *gnome{java,mm,perl} [14:26] rickspencer3: no, it means most of the work is done by debian (ie we are on sync) [14:27] can we add tracker to that list? (or demote it) [14:27] pitti: that's an open list, please add it as orange [14:27] * pitti does [14:27] chrisccoulson might want to put his name there :) [14:27] I used the desktop-bugs package report for a base [14:28] and the team is not subscribe to tracker [14:28] (and some others that I added) [14:28] seb128: desktop-bugs is basically "needs maintainer", right? [14:28] 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] oh, ok [14:29] pitti: ie those which I feel pedro and I and bug triager cover correctly [14:29] I have it as yellow/desktop-bugs right now [14:29] nobody assigned specifically but we do the job [14:29] pitti: which one? [14:29] tracker (just added) [14:29] orange would be better? [14:29] sorry, I meant "orange" [14:29] ok good [14:30] done [14:30] pitti: so right, "desktop-bugs" is ... team is trying to do what it can but nobody is specifically assigned [14:30] when desktop-bugs is not there is that we slack totally on it [14:31] though desktop-bugs could be added on some easy components lines [14:31] as said that's a rough first version [14:31] I'm open to suggestions for changes ;-) [14:31] * pitti hugs seb128, good work on that [14:32] * seb128 hugs pitti back [14:33] 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] rickspencer3: yes [14:34] rickspencer3: source package names [14:34] seb128: interesting point about evolution-exchange [14:35] rickspencer3: the list is basically https://bugs.edge.launchpad.net/~desktop-bugs/+packagebugs with tweaking [14:35] rickspencer3: if only we had a former MS employee who could provide that :-P [14:35] pitti: hmmm [14:35] lol [14:36] I can't get cheap licenses for business use, only for "personal" use :( [14:36] j/k [14:36] for the record I'm not interested to get an exchange license even if somebody can get me one ;-) [14:36] I wonder if we can just rent the service from someone though [14:36] seb128: I was hoping you would be running Vista. Aren't you doing that now? [14:36] * rickspencer3 ducks [14:37] sure, I'm only running this ubuntu thing in vmware under vista [14:37] so that's what the gnome 3.0 theme is called like then :) [14:37] lol [14:37] ! [14:37] why do you think my intel card is working correctly? [14:37] ;-) [14:37] oh man, I needed a good laugh [14:43] godaddy has hosted exchange for 7 bucks a month or something [14:43] I have a guy I roped in for likewise testing that might be able to test exchange, I'll find out [14:45] jcastro: that would rock [14:45] 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] my current way is to comment on the bugs asking to people to open a bug directly to GNOME if they can === rickspencer3 is now known as rickspencer3-afk [14:46] 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] 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] seb128: I assume the upstream novell evo guys would have access to exchange? or do the bugs just pile up there? [14:47] they do have access [14:48] same for evolution-mapi [14:48] the redhat guys have some access too apparently [14:48] -mapi is the openchange one right? the one that is supposed to work better? [14:48] the one which is new [14:48] right [14:48] and support exchange 2007 [14:48] I would not say "better" [14:49] well, it doesn't screen scrape like -exchange does I don't think [14:49] right [14:49] but it's a bit new [14:49] no doubt it will be better ;-) [14:51] did someone say exchange? [14:51] * hyperair uses exchange to access his university email [14:53] jcastro: evolution-exchange doesn't screenscrape. it uses the outlook web access api [14:53] 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] hmm. i think i can help with that. [14:53] i've fixed an exchange bug before [14:53] and i'll be having access to exchange for at least the next 3 years [14:54] dobey: ah [14:54] i don't think i've ever used the exchange plug-in, but i've fixed plenty of bugs in it [14:54] hyperair: that would be nice thanks ;-) [14:54] seb128: is there a todo anywhere? [14:54] 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] jcastro: right [14:54] jcastro: we usually don't have days for evolution though [14:55] I think a -mapi day might work if we find people [14:55] indeed [14:55] hyperair: not really, just a pile of untriaged launchpad bugs [14:55] I'll work on finding people with exchange to triage bugs and whatnot [14:55] seb128: i'll go dig through them then. what's the source package name again? [14:55] hyperair: I think a good part could be triaged without access to exchange though [14:55] hyperair: https://edge.launchpad.net/ubuntu/+source/evolution-exchange/+bugs [14:56] hyperair: https://edge.launchpad.net/ubuntu/+source/evolution-mapi/+bugs [14:56] jcastro: I've been trying to convince the server team without too much success [14:57] convince them to do what? [14:57] lool: thanks for your debian compiz abiver patches, that is a good idea, I integrate them into the ubuntu compiz now [14:58] jcastro: that exchange access is a server feature ;-) [14:58] jcastro: ie that they should be looking at those bugs and do testing [14:59] ah [14:59] seb128: hot potato no one wants I gather. [14:59] indeed === rickspencer3-afk is now known as rickspencer3 [15:00] at the minimum I'll start hunting for testers. [15:01] seb128: -mapi is supposed to supercede -exchange right? At least eventually? [15:02] jcastro: I think so, though I'm not sure [15:02] jcastro: I don't need if there is setups where you just have access to the web interface [15:02] jcastro: ie firewall blocking whatever mapi is using [15:02] most exchange people I know shut off the web interface anyway [15:02] so for some people -mapi is probably their only hope [15:02] seb128: so the build failure happens on all archs [15:03] asac: what package? [15:03] seb128: what do you mean? libcairo2-dev depends on it ... and its in universe. [15:03] i guess that means all main packages with libcairo depend fail now [15:03] asac: ok, can we start from scratch? ;-) [15:03] seb128: its xulrunner-1.9 rebuild [15:03] ok [15:03] let me look [15:03] http://launchpadlibrarian.net/26174824/buildlog_ubuntu-karmic-i386.xulrunner-1.9_1.9.0.10%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz [15:03] good ;) [15:07] asac: somebody did send libxcb-render-util0-dev to universe indeed [15:07] ok sounds like an accident [15:07] please repromote [15:08] or talk to whoever did that first ;) [15:08] somebody did overwrite all the queue binaries to universe [15:08] dunno why it was in binary NEW though [15:10] * hyperair never knew about mapi. will try now [15:11] one binary package makes all binary packages pop up in new queue i guess [15:11] from there its probably easy to just demote all ;) [15:12]