[05:51] <bryce_> pitti: you around?  I've a few questions for you on bug 269509
[06:21] <bryce_> pitti: guess you're out; I'll ask on the bug
[07:19] <pitti> bryce_: right, I'll answer on the bug
[07:38] <didrocks> morning o/
[07:46] <didrocks> hi mvo :)
[07:50] <mvo> hey didrocks!
[07:53] <didrocks> mvo: I have two gifts for you:
[07:53] <didrocks> lp:~didrocks/+junk/totem
[07:53] <didrocks> lp:~didrocks/+junk/totem-pl-parser
[07:53] <didrocks> hope you will like them :)
[07:53] <Tm_T> what are those?
[07:58] <didrocks> Tm_T: totem's gnome update, put in bzr
[07:58] <Tm_T> I see
[07:59] <Tm_T> what hew hotness I should look at?
[07:59] <mvo> thanks didrocks - geting them now
[08:00] <didrocks> mvo: I made some dependency changes, nothing really risky but I think this is correct
[08:01] <didrocks> Tm_T: for totem, you can look at the changelog, everything is in it. For other package, ask mvo & seb128 :)
[08:36] <mvo> didrocks: totem build fine, I'm checking the debdiff now (sorry that it took so long, got distracted)
[08:37] <slomo> mvo: when are you going to upload the python-apt with gtk stuff? :)
[08:37] <mvo> slomo: its in experimental already and in jaunty too - its not a ideal time for it in sid I think :/
[08:38] <mvo> slomo: we still need some little backend script that can be run as like synaptic - so that we don't have to run the main gui as root. but thats trivial
[08:38] <slomo> ok :) but experimental is fine, i'll wait until that backend script exists ;)
[08:39] <mvo> slomo: I try to work on gnome-codec-install a bit every day, its a nice and fun project :)
[08:39] <slomo> thanks :)
[08:40] <mvo> and I seem to have figured bzr-svn enough to not have to bother you with every single commit (I hope)
[08:41] <slomo> i could add you to pkg-gstreamer if you want
[08:42] <mvo> slomo: if that is ok with the team I'm fine with that too
[08:43]  * mvo hugs glatzor
[08:45] <slomo> mvo: what's the name of your alioth account?
[08:45] <glatzor> morning mvo and slomo
[08:45] <mvo> slomo: should be mvo
[08:45] <slomo> hi glatzor :)
[08:50] <didrocks> mvo: no pb, take you time :)
[08:53] <slomo> mvo: added you
[08:55] <seb128> hello everybody there
[08:55] <seb128> pochu: there? any news about the libproxy 0ubuntu1 version?
[08:55] <didrocks> hi seb128, slomo and glatzor ;)
[08:56] <seb128> hey didrocks, did you do the other updates yesterday? ;-)
[09:02] <seb128> go go go pitti ;-)
[09:03] <pitti> hey seb128
[09:03] <seb128> (just got a apport retracer service email ;-)
[09:03] <pitti> seb128: :-)
[09:03] <seb128> hey pitti
[09:03] <pitti> seb128: I'm having the hardy and intrepid ones catch up first, before I start working on jaunty
[09:03] <seb128> I guess there is a long queue
[09:03] <pitti> seb128: I noticed that we can't send mail from ronne :(
[09:04] <seb128> will be the second flood of the day
[09:04] <pitti> I updated the RT for this, but not sure when it will be done
[09:04] <pitti> so the polling will need to continue for a while
[09:04] <seb128> the first one was bug watch updates, we got around 500 of those during the night on desktop bugs
[09:04] <seb128> ok
[09:04] <pitti> but I think until then we can work around this by adding a "ssh ronne test_if_running" into our .bashrc or so
[09:04] <seb128> ;-)
[09:04] <pitti> and look into the log what went wrong
[09:05] <seb128> yeah
[09:07] <didrocks> seb128: yes, mvo is on it (lp:~didrocks/+junk/totem, lp:~didrocks/+junk/totem-pl-parser)
[09:07] <didrocks> mvo: I am in a meeting. will be available in one hour :)
[09:08] <seb128> didrocks, mvo: ok, thanks guys
[09:10] <pitti> seb128: oh, indeed, I got a bug watch updater flood as well
[09:11] <mvo> seb128: totem is in progress, some smallish stuff needs attention first I think, including a Vcs-Bzr header ,) - should we put it under ~ubuntu-core-dev or ~ubuntu-desktop, what do you prefer?
[09:12] <seb128> mvo: ubuntu-desktop would be cool, what do you think?
[09:12] <pitti> seb128: yay for bug 207072 fixed upstream
[09:12] <seb128> pitti: indeed!
[09:12] <seb128> pitti: will be a bit short for 8.04.2 though
[09:12] <seb128> lut huats
[09:13] <pitti> would really be nice, though, but yes
[09:13] <huats> hello seb128 and pitti
[09:13] <mvo> seb128: fine with me, we just need to keep in mind that people added there will have write access to the bzr branche
[09:13] <pitti> hey huats
[09:13] <huats> :)
[09:13] <seb128> mvo: the team has been created for that purpose in fact, we already had desktop-bugs for bug triagers
[09:14] <mvo> seb128: yeah, just checked the members, looks fine
[09:14] <mvo> seb128: would be nice if we could give ubuntu-core-dev implicit permission on the branches too
[09:15] <seb128> mvo: does launchpad allow to do that by setting one team as member of the other one or something?
[09:16] <mvo> I think it does, however I think its good asking first (#launchpad maybe) just to ensure it has no bad side-effects (like some sort of mail spamming or similar)
[09:23] <huats> seb128: I have an answer for the gnome-keyring stuff (which is blocking for seahorse...)
[09:23] <seb128> huats: ah good, which one?
[09:23] <seb128> crevette: lut
[09:23] <huats> it is a development stuff that upstream don't understand how we can have that
[09:23] <crevette> hello gentlemen
[09:23] <seb128> crevette: t'as corrigé ta maj de gedit?
[09:24] <huats> so he asked me to debug a bit with him...
[09:24] <huats> what I will do of course :)
[09:24] <seb128> huats: what do you mean?
[09:24] <crevette> seb128, non pas du tout
[09:24] <seb128> crevette: :-(
[09:24] <seb128> crevette: c'est une ligne à changer et tu bloques l'update
[09:24] <seb128> crevette: t'as commencé donc personne d'autre va la faire et elle est buggée donc peut pas être uploadée, ca serait bien de corriger ;-)
[09:25] <crevette> ah desolé
[09:25] <crevette> je pensais que tu pouvais le corriger
[09:25] <crevette> ce soir ca va ?
[09:25] <seb128> crevette: je peux le corriger si tu veux
[09:25] <seb128> crevette: oui
[09:25] <crevette> seb128, si tu peux le corriger c'est super
[09:26] <seb128> ok
[09:26] <crevette> let continue in english
[09:27] <crevette> I thought as you sent me the fix you were going to correct the package,sorry
[09:27] <crevette> :/
[09:27] <seb128> huats: ok, I got the email
[09:27] <huats> seb128: I have forwarded the email :)
[09:27] <seb128> crevette: that's ok, I was just telling you how to fix it so you can learn ;-)
[09:29] <huats> seb128: if crevette is bit busy I can have a look :)
[09:29] <seb128> huats: there is other updates for you if you want to do some
[09:29] <huats> hehe
[09:29] <huats> ok :)
[09:30] <huats> (i was saying that because I think I did a gedit update on my computer just before I realized that crevette already did it... but I am not that sure...)
[09:33] <seb128> huats: feel free to fix it, he opened a bug and did the changelog update but there is also a .install to update
[09:34] <huats> seb128: no no
[09:34] <huats> crevette: you need to learn :)
[09:35] <seb128> huats: want an another update to do?
[09:35] <seb128> hey tseliot
[09:35] <huats> seb128: sure
[09:35] <huats> :)
[09:35] <tseliot> hey seb128
[09:36] <huats> (well on the other side I might finish the anjuta one first... since I have some stuffs related like libgda)
[09:36] <seb128> huats: about gnome-keyring it's probably only failing because we use -Wl,-z,defs which enforce proper building, you told that to upstream right?
[09:36] <huats> yep
[09:36] <seb128> huats: you can try to comment the LDFLAGS in the rules and see if it builds otherwise
[09:37] <huats> that was something I was about to do this morning :)
[09:37] <seb128> huats: as you want, I prefer to focus on the standard desktop first and then on side applications usually ;-)
[09:37] <huats> ok
[09:37] <huats> so I'll follow you order sir ;)
[09:37] <huats> give me something to do :)
[09:39] <seb128> huats:
[09:39] <seb128> http://download.gnome.org/sources/deskbar-applet/2.25/deskbar-applet-2.25.4.tar.gz
[09:39] <huats> ok
[09:39] <huats> I am on it
[09:40] <huats> btw seb128, have you worked on the 'new' desktop package page that norsetto initiated ?
[09:40] <huats> (I was wondering that during holidays :))
[09:41] <seb128> huats: not yet, but we should
[09:41] <huats> seb128: ok :)
[09:42] <seb128> let's catch up on work and updates first and then we will work on the workflow ;-)
[09:44] <huats> seb128: I was just asking :)
[09:51] <huats> seb128: it gnome-keyring builds fine without that flags
[09:51] <seb128> ok, that was expected ;-)
[09:51] <huats> yep
[09:51] <huats> so I can tell him that it builds fine without that flags
[09:55] <huats> seb128: what do I do ?
[09:55] <huats> I put the package without that flags ?
[09:55] <huats> or I work with upstream in order to have a package with the flags ?
[09:55] <seb128> huats: let's wait a bit on upstream to reply, the bug should be easy to fix
[09:55] <huats> ok
[09:56] <seb128> huats: we use those flags for a reason ;-)
[09:56] <huats> seb128: I know :)
[09:56] <seb128> so better to fix issues than to workaround
[09:56] <huats> sure
[09:56] <huats> (I was just asking)
[09:56] <huats> thanks
[10:07] <crevette> huats, the thing is I can only do updates during the night, and at work I can just talk but not package. feel free to correct my package if you want
[10:07] <huats> crevette: I understand
[10:07] <huats> but master seb128 told you to learn, so learn ;)
[10:08] <crevette> I would never find how to fix the package myself
[10:08] <huats> crevette: I am sure you will
[10:10] <crevette> huats, if you want to correct the package, seb told me to just remove the *.ui line in gedit.install, they get installed in gedit-common anyway now and it builds correctly
[10:49] <didrocks> "huats> that was something I was about to do this morning :)" -> fake job :p
[10:50] <huats> LOL
[10:50] <huats> thanks didrocks
[10:50] <didrocks> y/w huats !
[10:50] <didrocks> :)
[11:03] <didrocks> seb128: if you have any other update in the pipe (and bzr-ianisation to do) that I can do this evening, just shout :)
[11:03] <seb128> didrocks: just ask this evening, the list will move during the day
[11:04] <didrocks> oki
[12:24] <pochu> seb128: morning :) here you have, please review it ;) http://emilio.pozuelo.org/~deb/libproxy_0.2.3-0ubuntu1.dsc
[12:26] <seb128> pochu: hey, thanks
[12:26] <seb128> pochu: want to do the mir for it too? ;-)
[12:30] <pochu> seb128: yeah I can do it, but later today
[12:30] <seb128> pochu: thanks
[12:30] <seb128> pochu: I've reviewed the package, good work
[12:31] <pochu> \o/
[12:31] <pochu> thanks
[12:31] <seb128> pochu: I'll sponsor the upload and ask pitti to NEW it
[12:31] <seb128> so it has a second review
[12:31] <pochu> seb128: I can upload it myself, btw ;)
[12:31] <pochu> but feel free to upload it :)
[12:31] <seb128> pochu: do it please then
[12:31] <pochu> ok
[12:32] <seb128> hum
[12:32] <seb128> it doesn't build
[12:32] <pochu> bah
[12:33] <seb128> it'll build on the buildds
[12:33] <pochu> I only built it in a Debian pbuilder
[12:33] <seb128> that's because it changes the configure and that triggers an autotools run
[12:33] <pochu> what's the error?
[12:33] <seb128> ../../libtool: line 818: X--tag=CC: command not found
[12:33] <seb128> classic libtool issue when autotools are not ran in the right order
[12:33] <pochu> and it won't trigger it in the buildd?
[12:33] <seb128> but that's only because automake is installed and got triggered
[12:33] <pochu> ah
[12:33] <pochu> ok
[12:33] <seb128> no, automake will not be installed there
[12:34] <pochu> ok, uploading
[12:34] <seb128> thanks
[12:34] <pochu> Successfully uploaded packages.
[12:34] <pochu> :)
[12:37] <seb128> pitti: can I get you to have a quick look to libproxy in NEW? I already checked it but there is one file not under a standard license and I would like to have your opinion on that
[12:44] <pochu> seb128, pitti: this is the thread from my ITP in Debian which lead to a few concerns from a security POV: http://lists.debian.org/debian-devel/2008/12/msg00730.html
[12:44] <seb128> hum
[12:45] <seb128> "mozjs.c:32:19: error: jsapi.h: No such file or directory
[12:45] <seb128> "
[12:45] <pochu> mvo: hi! you have mail :)
[12:46] <pochu> seb128: I'll look at it tonight, need to run to the university
[12:47]  * pochu waves at pedro_ :)
[12:47] <seb128> pochu: ok thanks, see you later
[12:47] <pochu> see you!
[12:47] <pedro_> pochu: hello!
[12:48] <seb128> asac: there for a xulrunner question?
[12:50] <soc> seb128: are you here?
[12:50] <seb128> soc: hi
[12:51] <soc> ah cool
[12:51] <soc> it's about #157398
[12:51] <soc> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/157398
[12:51] <soc> i found the root cause of the problem
[12:52] <seb128> the xrandr code is using 96 dpi
[12:52] <seb128> so when you have used the xrandr capplet you get 96 dpi used
[12:52] <soc> https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/157398/comments/7 this is the comment i described the wrong behavior and https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/157398/comments/8 describe the problem
[12:52] <seb128> that's not a bug
[12:53] <seb128> that gconf setting has been added back because there was too many bug configs
[12:53] <soc> it's a bug that debian tries to hardcode it themselves
[12:53] <seb128> we tried to use the autodetected dpi some cycles ago
[12:53] <seb128> no it's not
[12:53] <soc> because debian pathced the code in 2007 to handle that more gracefully
[12:53] <soc> seb128: when did you try that?
[12:54] <soc> because debian patched the code in 2007 to handle that more gracefully, i meant
[12:54] <soc> so the debian code is duplicate
[12:54] <seb128> ?
[12:54] <seb128> they patched what?
[12:54] <soc> and makes debugging more complex
[12:54] <seb128> debugging of what?
[12:55] <soc> they try to detect the dpi and if the dpi is in an reasonable range they use, if not they hardcode 96 dpi
[12:55] <soc> so it's useless to hardcode it in that debian file
[12:55] <soc> because the first part will never get executed
[12:55] <seb128> we tried during the gutsy cycle
[12:56] <seb128> the issue is not "not reasonable range"
[12:56] <soc> mhh, then what is the issue?
[12:56] <seb128> but 80 dpi listed when the screen is 96 dpi for example
[12:56] <soc> because gnome thinks the value in that %gconf.xml is set by the user, it doesn't even try to get the dpi from the xserver
[12:56] <seb128> read bug #118745
[12:57] <seb128> soc: we did try the xorg way and rolled back due to the flood of bugs
[12:57] <seb128> soc: there is many configs where xorg just doesn't get it right
[12:57] <soc> and then why use 96?
[12:58] <soc> that's just a random value which is almost never right anymore
[12:58] <seb128> because it's near of a correct value and create less trouble for most users
[12:58] <seb128> we don't have many users complaining
[12:58] <soc> from my testing at least nv, nvidia and radeonhd get it right
[12:58] <seb128> I don't think "almost never right" is a correct statement
[12:58] <soc> i'm sure about it
[12:59] <asac> seb128: yes
[12:59] <seb128> well, let's see xorg autodetection get it less right then
[12:59] <seb128> brb just restarting IRC to try something
[13:00] <soc> seb: modern displays don't even have an integer dpi anymore, as well as they don't have the same dpi for the vertical and horicontal range
[13:00] <seb128> asac: pkg-config --cflags --libs mozilla-js lists -I/usr/include/xulrunner-1.9.0.5/stable is that normal?
[13:00] <seb128> soc: I'm not interested in this discussion, we get not complain using the current way, you tried your way you can read the bug and the number of duplicates
[13:01] <soc> seb128: no complains?
[13:01] <seb128> soc: I don't really care what is right or not we do what is best to not annoy users
[13:01] <soc> i see at last five different bug reports on that
[13:01] <soc> and at least as many entries on brainstorm
[13:01] <seb128> soc: well, that's much smaller than the angry flood of users we had when trying the xorg way
[13:01] <soc> it would be nice to maybe fix that issue once
[13:02] <seb128> asac: libproxy uses jsapi.h which is the unstable directory and pkg-config on mozilla-js, is that correct?
[13:02] <seb128> soc: what I got from the xorg team by then is that the issue can't be fixed on a lot of non modern hardware
[13:03] <seb128> soc: where the monitor doesn't communicate enough to the computer to get that value right
[13:03] <soc> so then gnome falls back to 96 dpi, so what's the problem?
[13:03] <asac> seb128: what is libproxy?
[13:03] <seb128> soc: I can raise the issue to the next desktop team meeting or discuss it on #ubuntu-x and we can probably try dropping the set value again and see users reactions, maybe xorg does a better job now
[13:04] <asac> is that something (in future) important?
[13:04] <soc> seb128: i'm sure that the situation has improved ...
[13:04] <seb128> asac: that's something GNOME 2.25 depends on, it's blocking GNOME updates in jaunty and my priority for this week now
[13:04] <soc> could you point me to the file where it gets hardcoded?
[13:04] <soc> i thought the file was in gconf2-common, but it wasn't
[13:04] <asac> seb128: what elements of jsapi does it use?
[13:05] <asac> just some constant or real abi?
[13:05] <seb128> soc: /usr/share/gconf/defaults/10_libgnome2-common
[13:05] <soc> soc: i will prepare patches, so the team has some facts to discuss about
[13:05] <soc> thanks
[13:05] <seb128> asac: dget http://emilio.pozuelo.org/~deb/libproxy_0.2.3-0ubuntu1.dsc
[13:05] <seb128> soc: patch? it's dropping one line in a .gconf-defaults
[13:05] <soc> sure
[13:05] <asac> seb128: what part of gnome depends on it?
[13:05] <seb128> soc: no need to bother, I did set the value and know how to unset it, it just needs to be discussed, but thanks
[13:06] <soc> ok
[13:06] <seb128> asac: libsoup depends on it now, which is used by libgweather
[13:06] <soc> another thing to think about would be the standard font size
[13:06] <seb128> asac: it's blocking the gvfs update which fix samba active directory browsing, libgweather, gnome-panel and some other things too
[13:06] <soc> now, when the dpi is set correctly, it might be possible to set it to something "which sucks less"TM
[13:06] <soc> :-P
[13:07] <seb128> soc: those discussions might be better placed on #ubuntu-x btw
[13:07] <soc> btw, when is the next desktop team meeting?
[13:07] <seb128> soc: next tuesday at 16h30 utc
[13:07] <seb128> on this channel
[13:08] <soc> so yesterday was the last meeting?
[13:08] <seb128> asac: the source using it is mozjs.c
[13:08] <seb128> soc: right, those are weekly meeting, usually at the same time but that might change after next one due to team reorganisations
[13:09] <soc> ah k
[13:10] <soc> seb128: btw, why is the current wallpaper called "warty......png"?
[13:11] <seb128> soc: because we usually don't touch user configuration on upgrade and changing the name would break a working configuration for users which have that filename set in their config
[13:11] <soc> ah, ok interesting
[13:11] <mvo> pochu: thanks, was having lunch
[13:11] <seb128> that's one of the thing we might consider trying to fix in upgrade tools at some point though
[13:12] <seb128> we still have evolution-2.2.desktop for the same reason
[13:12] <seb128> mvo: we forgot to discuss that at UDS, maybe at the distro sprint or next UDS
[13:12] <pitti> pochu: so wpad will get disabled by default?
[13:12] <pitti> seb128: okay
[13:13] <seb128> pitti: danke
[13:13] <soc> last thing to that dpi-problem: that dpi input box in gnome-appearance-properties would be better placed in the gnome-display-properties
[13:13] <soc> because many people are bausing that dpi-setting to change the font-size ...
[13:14] <soc> s/bausing/abusing
[13:14] <pitti> seb128: in exchange, I'd appreciate if you could review calibre, since I uploaded it and thus can't NEW it
[13:14] <seb128> soc: right, that's a good point, should probably be discussed upstream though
[13:14] <seb128> pitti: sure, will do
[13:14] <soc> do you know if o maintainer of display-properties is around here?
[13:15] <seb128> distro maintainer or upstream hacker?
[13:15] <soc> any one
[13:15] <seb128> the GNOME packages are team maintained, usually mvo or I do the gnome-control-center updates but that's distro work, not really upstream hacking
[13:15] <soc> ah ok
[13:15] <seb128> upstream guys are on #control-center on irc.gnome.org
[13:16] <soc> thanks
[13:16] <mvo> seb128: hm? evo2.2?
[13:16] <seb128> you're welcome
[13:16] <pitti> seb128: the license looks fine to me; what do you see wrong with it?
[13:16] <mvo> pochu: nice, thanks
[13:16] <asac> seb128: pkg doesnt even build here at all :/
[13:16] <seb128> pitti: nothing, I just wanted an another opinion, I'm never comfortable jugging licenses
[13:17] <pitti> seb128: it sounds fairly common (MIT license)
[13:17] <seb128> asac: libproxy?
[13:17] <asac> yeah
[13:17] <asac> ;)
[13:17] <pitti> seb128: it's just a slightly reworded MIT, yes
[13:17] <seb128> pitti: no need to have a COPYING for it or something right?
[13:17] <pitti> seb128: the license would need to be in src/plugins/xhasclient.c
[13:17] <seb128> pitti: is that required or not?
[13:18] <asac> seb128: anyway. please do something in this spirit: http://paste.ubuntu.com/101643/
[13:18] <asac> seb128: also remove xul dep then
[13:18] <pitti> seb128: required, and it is there
[13:18] <asac> mozjs is not a lib and cannot be supported
[13:18] <seb128> ups, closing wrong dialog
[13:18] <seb128> asac: url again please? ;-)
[13:19] <asac> seb128: use irssi in a screen ;)
[13:19] <asac> 14:18 < asac> seb128: anyway. please do something in this spirit: http://paste.ubuntu.com/101643/
[13:19] <pitti> seb128: so all in all, package looks good to me
[13:19] <pitti> seb128: (accepted)
[13:19]  * pitti -> lunch, bbl
[13:19] <asac> seb128: adjust build-deps accordingly. if there is an issue with disabling it ... we have to look/talk also with upstream
[13:20] <seb128> asac: http://people.ubuntu.com/~seb128/configure_check_for_dbus.patch.gz
[13:20] <asac> from the build failure it looks like the package needs to be re-libtoolized or something
[13:20] <seb128> asac: updated patch if you want to build it
[13:20] <asac> seb128: is that re-autostuff?
[13:20] <seb128> asac: the previous one fails if you have automake installed, that got run but it doesn't work correctly using the current libtool
[13:21] <seb128> asac: yeah, one configure.ac change (you get an error saying what to add if you run autoreconf and autoreconf run)
[13:21] <asac> ok cool. will try. but mozjs is just a plugin so i guess it should be safe to disable for now
[13:21] <seb128> pitti: thanks
[13:22] <seb128> asac: ok thanks, yeah we don't need plugins, just the library
[13:22] <seb128> asac: it doesn't tell me if the bug is libproxy or a xulrunner one though ;-)
[13:22] <asac> seb128: spidermonkey folks know about this issue (they didnt know a few weeks ago) and understand that they need to do ABI tracking to become a real lib
[13:22] <seb128> asac: ie if mozilla-js is not the correct thing to pkg-config
[13:23] <asac> seb128: the bug is that libproxy tries to use a lib that isn't main-worthy
[13:23] <seb128> ok, fair enough
[13:23] <asac> hence we dont ship it at a static location ... so -rpath wont work ... so we cannot allow mozjs things in
[13:23] <seb128> I will let those guys sort that then
[13:24] <asac> tell them that spidermonkey folks know about that issue ... they can support them by asking for ABI/API policy and proper SONAME in bugzilla ;)
[13:25] <seb128> ok ;-)
[13:25] <seb128> asac: thanks for looking into the issue
[13:26] <asac> welcome
[14:16] <seb128> vuntz: hey
[14:16] <seb128> vuntz: so gnome-panel 2.25.3 doesn't build ;-)
[14:16] <seb128> vuntz: clock.c:2737: undefined reference to `bonobo_ui_component_set_prop'
[14:16] <seb128> vuntz: known issue?
[14:18] <vuntz> seb128: hrm. weird
[14:18] <vuntz> it does build here
[14:18] <vuntz> let me finish something and I'll look at it
[14:19] <seb128> vuntz: we use -Wl,-z,defs so you probably dropped the -llibbonobo but still use some symbols which is wrong
[14:19] <seb128> or -lbonoboui
[14:20] <seb128> or whatever defines the symbol you are using ;-)
[14:25] <vuntz> seb128: libpanelapplet-2.0.pc contains libbonoboui-2.0
[14:25] <vuntz> hrm
[14:25] <seb128> vuntz: is that .pc used when building gnome-panel?
[14:25] <seb128> vuntz: circular depends? ;-)
[14:27] <vuntz> seb128: well, I think libpanelapplet-2.0-uninstalled.pc is used when building gnome-panel, but it still contains libbonoboui-2.0
[14:27] <vuntz> so something is wrong somewhere
[14:27] <vuntz> ah
[14:27] <vuntz> I think I know
[14:28] <seb128> hum
[14:29] <vuntz> just need to add LIBPANEL_APPLET_CFLAGS and LIBPANEL_APPLET_LIBS to all applets
[14:29] <seb128> vuntz:
[14:29] <seb128> PKG_CHECK_MODULES(CLOCK, pango >= $PANGO_REQUIRED gtk+-2.0 >= $GTK_REQUIRED glib-2.0 >= $GLIB_REQUIRED gio-2.0 >= $GLIB_REQUIRED $LIBECAL_REQUIREMENT libglade-2.0 >= $LIBGLADE_REQUIRED librsvg-2.0 dbus-glib-1 gweather >= $GWEATHER_REQUIRED)
[14:29] <seb128> vuntz: that would work
[14:29] <vuntz> actually we already have LIBPANEL_APPLET_CFLAGS for the clock
[14:30] <seb128> vuntz: where?
[14:30] <seb128> ah
[14:31] <seb128> vuntz: right, you don't have the LIBS though
[14:31] <seb128> which is what create the ldd issue
[14:32] <vuntz> yep, will commit the fix in one minute (building to make sure it's okay)
[14:33] <seb128> vuntz: thanks!
[14:35] <vuntz> committed
[14:35] <vuntz> thanks
[14:36] <seb128> vuntz: thank you ;-)
[14:36]  * seb128 hugs vuntz
[14:36] <seb128> vuntz: you don't have the patch handy somewhere by any chance?
[14:37] <seb128> sucks that viewvc doesn't have the changeset, you need to get the diff for each file there
[14:37] <vuntz> seb128: http://svn.gnome.org/viewvc/gnome-panel?view=revision&revision=11435
[14:37] <vuntz> yeah
[14:38] <vuntz> don't have more than this
[14:38] <seb128> ok, let's middle click
[14:38] <seb128> vuntz: that's ok, I was just being lazy ;-)
[14:44] <tedg> seb128, pitti: Hey guys.  So the pidgin folks basically messed up their DBus bindings in that many of the functions were signed when they weren't supposed to be.  They're planning on fixing it in the next release.  Not a huge deal, but do I need to build a FUSA package that says not the newest version for Intrepid?
[14:45] <seb128> tedg: "that says not"?
[14:45] <tedg> seb128: > x  && < y instead of just > x
[14:45] <seb128> ah
[14:45] <seb128> no, we will not upgrade pidgin in intrepid so no need to change fusa there
[14:45] <pitti> tedg: you mean if someone tries to locally install a newer pidgin?
[14:45] <pitti> that won't help I think
[14:46] <pitti> since a local "sudo make install" won't use dpkg dependencies
[14:46] <tedg> I was more worried about backports and/or PPAs.
[14:46] <pitti> if we ever do a backport, we need to backport fusa, too, though
[14:46] <pitti> tedg: either way, I don't think we should (and ever did) do SRUs just to guard against prospective backports, etc.
[14:47] <tedg> Okay, sounds good to me (less work :) )
[14:54] <seb128> vuntz: confirming that the change works correctly ;-)
[15:05] <seb128_> ok
[15:06] <seb128_> opening a guest session crash my laptop on jaunty, yeah for unstable distros or maybe not ;-)
[15:06] <seb128_> could be that the issue is not specific to the guest session but just when opening a second session but I don't want to crash my box again just to try
[15:08] <mvo> seb128: I bet its a issue with the second X
[15:30] <seb128> grrr
[15:31] <seb128> normal user switching seems to work but when closing the other session the computer is good to reboot
[15:45] <glatzor> mvo, I added the packaging to aptdaemon, policykit support and a small executable demo application
[15:46] <mvo> glatzor: nice
[15:46] <glatzor> mvo, it has the meaningful name gaptd-client :)
[15:47] <mvo> glatzor: how different (other than the prefix) is the dbus interface compared to pk?
[15:47] <mvo> glatzor: is it in your ppa?
[15:48] <glatzor> mvo, I am thinking about adding a compatibility layer - if this was the intention of your question
[15:49] <mvo> it was :)
[15:50] <glatzor> mvo, aptdaemon doesn't handle package objects (currently)
[15:52] <glatzor> mvo, but I am not sure if it is worth the work, since session-installer will already deal with PackageKit session interface, which will be used by the client applications (e.g. abiword installing plugins)
[15:53] <glatzor> mvo, the rich package manager in Ubuntu/Debian  e.g. synaptic, g-a-i, update-manager are a lot more advanced than the PackageKit ones
[15:57] <glatzor> mvo, adding the Terminal signal to PackageKit by a patch would be doable, but patching all the clients to show the terminal and deal with debconf question and file conflicts without forcing the user to the terminal widget would be a quiet unpleasant work
[15:59] <mvo> glatzor: right, I agree -  the session interface should be good enough and the use cases are usually limited
[16:01] <glatzor> mvo, oh, I should propose a change to the package details api of PackageKit to support an end of maintenance field
[16:01] <mvo> great idea
[16:01] <mvo> !
[16:02] <mvo> (distro meeting - I'm a bit slow to repond)
[17:07] <crevette> seb128, as you did the gedit update, can I help you with something this evening once back home?
[17:10] <seb128> crevette: you can do the vino or vinagre update if you want
[17:10] <crevette> okay, I'll do both if you want
[17:10] <crevette> and If I can
[17:10] <seb128> cool
[19:20] <crevette> hey ladies & gents
[19:35] <didrocks> plop crevette
[19:36] <crevette> salut didrocks
[19:52] <pochu> crevette: there's no gtk-vnc 0.3.8 in jaunty yet...
[19:52] <pochu> pitti: I'm looking at the WPAD issue
[19:52] <crevette> yeah I saw
[20:27] <seb128> re
[20:28] <seb128> pochu: there?
[20:28] <pochu> seb128: hey
[20:29] <seb128> pochu: hello
[20:29] <seb128> pochu: I did some changes to libproxy during the afternoon
[20:29] <pochu> yeah, I've seen your upload mail
[20:29] <pochu> thanks for fixing it!
[20:30]  * pochu is looking at the WPAD stuff right now
[20:30] <seb128> pochu: updates the autotools part of your patch to work when using the new libtool, stopped building the xulrunner code (it depends on a lib which is not stable enough yet) and fixed the shlibs right now
[20:30] <pochu> upstream has told me he'll accept a patch to disable it by default
[20:30] <seb128> pochu: don't specify the debian revision in build-depends, depends or shlibs if not required, ie you added -1 there
[20:31] <pochu> did I?
[20:31] <seb128> which doesn't bring any value since that the same that no revision in debian
[20:31] <seb128> but it broke the -0ubuntu1 upload
[20:31] <pochu> ah
[20:31] <seb128> pochu: the shlibs in your rules had the revision specified yes
[20:31] <pochu> right
[20:32] <pochu> thanks, I'm removing it from svn
[20:32] <seb128> I noticed when building libsoup, it depends on a version not available ;-)
[20:32] <seb128> ie on the revision 1 where we have 0ubuntun
[20:32] <pochu> right
[20:33] <pochu> :)
[20:33] <seb128> pochu: you think you can do the mir tonight?
[20:33] <seb128> pochu: it's blocking GNOME in jaunty right now
[20:33] <pochu> seb128: is it? it's not a blessed external dependency yet...
[20:34] <seb128> pochu: libsoup, libgweather and gvfs depends on it
[20:34] <seb128> pochu: or rather libsoup depends on it and gvfs uses libsoup-gnome which uses libproxy
[20:34] <pochu> seb128: I'll at least start it, and if possible finish it too
[20:35] <seb128> pochu: if you don't finish it let me know and I'll do the remaining work tomorrow
[20:35] <pochu> ok
[20:38] <seb128> crevette: the changelog syntax is lp: #number, the gedit bug didn't get closed because you didn't have the # I think
[20:38] <crevette> yeah I seen that afterward
[20:38] <crevette> well, I hope I'll educe the number of mistakes
[20:38] <crevette> reduce
[20:40] <seb128> that's alright, everybody needs to learn ;-)
[20:41] <seb128> fta: there? do you want to do the cairo 1.8.6 update?
[20:42] <crevette> seb128: vinagre is stuck due to a dependency on latest libgtk-vnc
[20:42] <seb128> ah right
[20:44] <fta> seb128, ok. nothing to merge from debian ? no patch you from git you need ? I remember i needed one for mozilla, i'll recheck
[20:44] <fta> +need
[20:46] <seb128> fta: debian has 1.8.6 in experimental if you want to base the update on it, not sure about firefox you probably knows better about that
[20:47] <fta> ok, i'll have a look at debian too
[20:47] <seb128> thanks
[20:48] <crevette> seb128: I tried to build vino in pdebuild and I have a question
[20:48] <seb128> crevette: just ask then ;-)
[20:48] <crevette> reading the autogen.sh output I saw it did have keyring support despite having gnome-keyring-dev as build-dep
[20:49] <seb128> I think that's a configure option
[20:49] <seb128> look in the debian directory, in the rules
[20:49] <crevette> this need to be forced
[20:49] <crevette> ?
[20:49] <seb128> not sure now but I think we didn't do it and for a reason
[20:49] <crevette> I'm adding libunique support as vino add that as dependecy and it was off too
[20:50] <seb128> right, that lib was in universe, that changed now since nautilus use it though
[20:50] <crevette> DEB_CONFIGURE_EXTRA_FLAGS += \
[20:50] <crevette> 	--enable-avahi \
[20:50] <crevette> 	--enable-libnotify
[20:50] <seb128> gnome-keyring is an issue because if your gnome-keyring is not unblocked that will break the vnc connection or something
[20:50] <seb128> it'll block on somebody to enter the gnome-keyring password locally
[20:51] <crevette> but why there is no switch like --enable-keyring=no
[20:51] <crevette> ah perhaps detection is not automatic ?
[20:51] <seb128> upstream doesn't enable it by default either I think
[20:52] <seb128> so you just need an option if you want to use it
[20:52] <crevette> [use gnome keyring for storing password [default=no]] in configure.in
[20:53] <crevette> so does it makes sense to keep a dependency on keyring if we don't use it
[20:53] <seb128> there is one?
[20:54] <seb128> pochu: ^ do you know about that?
[20:54] <crevette> libgnome-keyring-dev is in buil-depends
[20:56] <pochu> I guess you can remove it
[20:56] <crevette> okay
[20:56] <seb128> I would say that too
[20:56] <pochu> just check if it disables anything else
[20:58] <pochu>   [ Loic Minier ]
[20:58] <pochu>   * Disable GNOME Keyring support as per discussion in GNOME #344839;
[20:58] <pochu>     closes: #421222.
[20:58] <crevette> seb128: how do check build locally ? you use debuild ?
[20:58] <seb128> crevette: debuild
[20:59] <crevette> seb128: I'm trying pdebuild but it put a really mess in the source directory, I end wih files owned by root :/
[20:59] <crevette> pochu: where did see that ? in debian changelog ?
[20:59] <crevette> ah yeah
[21:00] <seb128> crevette: that should not be an issue
[21:02] <crevette> I wonder if I have to add --enable-libunique in rules, as it is stated to be automatically detected
[21:03] <crevette> seemed to not work in pdebuild
[21:04] <seb128> crevette: look to the config.log in the build directory to see why it's not enabled
[21:17] <cj> seb128: hey there.  we mentioned you when you were away.  someone was asking about the maximized totem problem (bug 283592)
[21:20] <crevette> seb128: by the way there is  https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/312522
[21:20] <seb128> crevette: you should subscribe the sponsor team if that's not done so those are listed correctly
[21:20] <seb128> cj: what about it?
[21:50] <cj> seb128: there was a repro.  here, I'll paste the log... moment...
[21:50] <seb128> cj: better to comment on the bug
[21:50] <seb128> cj: so whoever read the bug will get the details
[21:52] <cj> http://rafb.net/p/bT7giF32.html
[21:52] <cj> okay
[21:53] <cj> done
[22:06] <crevette> cj: are you sure you pasted the right conversation (I'm refering to https://bugs.edge.launchpad.net/ubuntu/+source/metacity/+bug/312522/comments/8) to the right bug?
[22:16] <pochu> fta: we should fix bug 295490 for Intrepid too (see bug 309640)
[22:18] <fta> pochu, yep, feel free, it's the same patch
[22:19] <pochu> fta: should we use the one from 295490 or from 309108?
[22:21] <fta> pochu, 309108
[22:21] <fta> http://paste.ubuntu.com/87290/
[22:22] <pochu> ty
[22:31] <kwah> night
[22:31] <kwah> anyone?
[22:41] <cj> I'm not
[23:01] <jng1> hi all.. can anyone point me at the code for the jaunty notification system?
[23:46] <maxb> notification system for what?
[23:48] <johanbr> jng1: I've been looking for that too. Not sure if any code exists yet. At least not anywhere public...
[23:56] <Amaranth> The demo at UDS was just that, a demo
[23:56] <Amaranth> No real usable code exists, afaik
[23:58] <Tm_T> :-P