[09:15] <salty-horse> hi. is there a reason I don't see displayconfig-gtk in the application menu? (file is /usr/share/applications/displayconfig-gtk.desktop )
[10:43] <pochu> salty-horse: are you in KDE?
[10:44] <pochu> salty-horse: it's in Applications->Others here
[10:44] <salty-horse> nope. just upgraded to hardy gnome
[10:44] <salty-horse> I think it's an accidental error.. it should be in system->preferences or administration
[10:45] <salty-horse> "other" is when no category exists
[10:45] <salty-horse> I'll check the repos
[10:46] <salty-horse> what's the meaning of this commit message? http://bazaar.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu/revision/bryce%40canonical.com-20080320034502-g3q97wykkav22so9?start_revid=bryce%40canonical.com-20080320034502-g3q97wykkav22so9&file_id=displayconfiggtk.des-20070322180214-dyw3rxw0wcvy94go-1
[10:48] <salty-horse> I'll ask Bryce
=== asac_ is now known as asac
[11:12] <salty-horse> asac, what's does the ubuntu firefox extension do?
[13:41] <huats> seb128: hello
[13:41] <seb128> hey huats
[13:42] <Hobbsee> hi seb128, huats
[13:42] <huats> hello Hobbsee
[13:42] <huats> :)
[13:44] <seb128> hello Hobbsee
[13:49] <seb128> slomo_: around?
[13:49] <slomo_> seb128: yes
[13:50] <seb128> slomo_: I've noticed an issue in gnome-settings-daemon
[13:51] <seb128> slomo_: the xrdb datas are not installed
[13:51] <slomo_> /usr/share/gnome-settings-daemon/xrdb here
[13:51] <slomo_> right, that should be /etc/gnome/xrdb
[13:51] <seb128> I think the debian gnome-control-center package used to change those and install them under /etc/gnome/config
[13:52] <slomo_> seb128: will move again, thanks :)
[13:52] <seb128> can conffiles be moved between binaries? or does it require some postinst work?
[13:53] <seb128> I think it's one of those annoying cases
[13:53] <seb128> I'm not sure right now though
[13:53] <slomo_> i'll try
[14:03] <seb128> slomo_: http://wiki.debian.org/DpkgConffileHandling can be useful
[14:04] <slomo_> i hate conffiles :)
[14:07] <slomo_> seb128: yay, first time that conffiles don't cause extra work... :)
[14:08] <slomo_> uploaded
[14:08] <seb128> thanks
[14:08] <seb128> how they didn't create extra work?
[14:10] <slomo_> only change needed was the .install file
[14:13] <seb128> hum
[14:13] <seb128> I doubt of that
[14:15] <seb128> slomo_: at least there is a package conflict, since the file moved from capplets-data to an another binary
[14:15] <seb128> slomo_: and those are conffiles and might have been changed by the user, how will that be handled? will it keep the user version of conffile prompt on upgrade?
[14:16] <slomo_> seb128: "Replaces: capplets-data (<< 1:2.21.5)"
[14:16] <slomo_> but for the other part... i don't know :/
[14:17] <seb128> need to talk to cjwatson when he'll be around
[14:18] <seb128> the openssh has a changelog entry about that
[14:25] <slomo_> seb128: another thing... could you move nunit to main and nunit2.2 to universe? last dependency in main is gone now but wants the new version which is supported upstream (while nunit2.2 is very old) ;)
[14:45] <slomo_> seb128: ok, gst-plugins-base0.10 is uploaded now... please sync :) and move nunit stuff around ;)
[14:45] <seb128> what is this nunit about?
[14:45]  * seb128 looks
[14:45] <seb128> dunno this package
[14:46] <seb128> nunit wants to go to main apparently
[14:46] <slomo_> seb128: unit testing... we have old nunit2.2 in main because mono-tools didn't build with nunit some time ago
[14:47] <slomo_> seb128: that's fixed now and we should use the new version because it's supported upstream
[14:47] <seb128> are those the same software?
[14:49] <slomo_> yes
[14:49] <slomo_> just different versions
[14:50] <seb128> ok, will do the changes then
[14:50] <seb128> I doubt pitti will have issues with those
[14:50] <slomo_> nunit2.2 was uploaded to debian only for mono-tools btw :)
[14:50] <seb128> understood ;-)
[14:50] <slomo_> now monodevelop needs it too but that's in universe
[14:53] <seb128> changed
=== MenZa_ is now known as MenZa
[16:48] <slomo_> asac: ping? :)
[17:31] <slomo_> seb128: ok, so the complete gtk#2.12/gnome#2.20 transition thing is done now, everything built fine ;)
[17:31] <seb128> good, that was quick and smooth ;-)
[17:32] <slomo_> except that mono broke in between because we set CPPFLAGS in the build environments now and theyr build system is ugly... yes ;)
[17:33] <seb128> didn't notice, I just upgraded to the new f-spot, the new libgtkhtml thing got installed correct and it's still working
[19:50] <asac> slomo_: ?
[19:51] <slomo_> asac: problem already solved :)
[19:51] <asac> thats good news :)
[19:51] <slomo_> asac: well, not good but solved... how can i get the MOZILLA_HOME for xulrunner? :)
[19:52] <slomo_> asac: before one could simply get the libdir from the pkg-config file
[19:52] <asac> slomo_: if you need that you are doing something wrong
[19:52] <asac> you upgraded mono binding for gtkmozembed
[19:52] <slomo_> asac: no idea if i do something wrong, we have a patch to export the correct MOZILLA_HOME in mono-tools and other packages since ages :)
[19:52] <asac> ?
[19:52] <slomo_> no, mono-tools
[19:52] <asac> slomo_: what does mono-tools do?
[19:52] <slomo_> i mad it build again
[19:53] <slomo_> it contains a unit testing gui, documentation browser, etc
[19:54] <asac> how is the documentation browser calle?
[19:54] <asac> called
[19:54] <asac> i remember something about that one :)
[19:54] <asac> ah ... monodoc-browser
[19:55] <asac> slomo_: so how is MOZILLA_HOME exported?
[19:55] <slomo_> in /usr/bin/monodoc
[19:55] <slomo_> just grep for MOZILLA_HOME and you see it
[19:55] <asac> before xulrunner 1.9 MOZILLA_HOME was needed to set the proper -rpath
[19:55] <asac> but thats not the case anymore
[19:56] <slomo_> ok, so the patch is obsolete... will it hurt?
[19:57] <asac> looking
[20:02] <asac> slomo_: plesae drop the current _home patch and use http://paste.ubuntu.com/5999/ instead
[20:02] <asac> which basically drops the complete mozilla_home business
[20:03] <asac> let me know if it doesn't work