[06:58] <pitti> Good morning
[08:32] <MacSlow> hey seb128
[08:33] <seb128> hello MacSlow
[08:33] <pitti> hey seb128
[08:33] <seb128> hey pitti
[08:33] <MacSlow> Mahlzeit pitti
[08:33] <pitti> can I still use glade-3 to create gtk-builder files?
[08:33] <pitti> or do I need a new tool for that?
[08:33] <MacSlow> pitti, I believe so
[08:33] <MacSlow> pitti, you can set in the project-preferences what output to create
[08:34] <pitti> hm, there's a gtk-builder-convert program
[08:34] <seb128> pitti: why not?
[08:34] <seb128> pitti: gtk-builder is the new thing, why would they drop it?
[08:34] <pitti> seb128: I want to convert apport from glade to gtk.Builder
[08:34] <pitti> seb128: I just wondered about the GUI tool
[08:35] <MacSlow> pitti, just checked ... you can create gtkbuilder files with glade-3
[08:35] <pitti> MacSlow: cool, thanks
[08:35] <seb128> glade-3 ask the format to use when you start it
[08:35] <seb128> default is gtkbuilder nowadays
[08:35] <seb128> you can also gtk-builder-convert the .glade
[08:35] <MacSlow> pitti, now that you mentioned it... did so some weeks ago
[08:35] <pitti> gtk-builder-convert seems to do a reasonable job, though
[08:35] <seb128> it's done for that ;-)
[08:35] <seb128> there is no much difference between .glade and .ui anyway
[08:36] <pitti> just some renamed tags, apparently
[08:36] <MacSlow> seb128, but the API is different :)
[08:36] <seb128> right, the idea was the basically get the .glade feature in gtk
[08:36] <seb128> they just did some adjustement on the way
[08:36] <seb128> MacSlow: right but conversion should be easy
[08:36] <pitti> I just finished the hal-sectomy of apport, so while I'm at cleaning old stuff, glade should go with it
[08:37] <MacSlow> seb128, never really looked at the pure xml of these to formats
[08:37] <seb128> pitti: http://library.gnome.org/devel/gtk/stable/gtk-migrating-GtkBuilder.html
[08:37] <pitti> seb128: htnaks
[08:37] <pitti> (urgh)
[08:40] <seb128> yuor welocme
[08:40] <pitti> the most important question isn't explained anywhere -- what's the file extension for gtkbuilder xml files? :-)
[08:41] <seb128> .ui
[08:41] <pitti> aah
[08:41] <seb128> dlocate .ui
[08:41] <seb128> you will see that most of GNOME use it nowadays ;-)
[08:42] <seb128> that's one of those "GNOME3 goals"
[08:42] <pitti> right, I wanted to do my share of converting apport and jockey
[08:42] <pitti> so that I'm not the one who will be responsible for keeping libglade in teh default install :)
[08:43]  * seb128 hugs pitti
[08:44] <seb128> pitti: http://www.gnome.org/~fpeters/299.html btw
[08:44] <didrocks> morning seb128
[08:44] <seb128> if you want some GNOME stats on all the cleaning
[08:44] <seb128> lut didrocks
[08:44] <didrocks> lut pitti :)
[08:44] <pitti> wow, nice
[08:44] <pitti> hey didrocks
[08:49] <didrocks> oh yes, glade-3 is handling nowdays GtkBuilder \o/
[08:49] <didrocks> short time ago, it was not possible :)
[08:52] <huats> mro,g everyone
[08:52] <huats> oups
[08:52] <huats> morning !
[08:56] <pitti> wow, now that glade->builder conversion was easy
[09:04] <slomo> seb128: do you already have totem 2.27 in ubuntu?
[09:04] <seb128> slomo: not yet but robert_ancell is working on it, why?
[09:04] <seb128> lut huats
[09:04] <seb128> pitti: see ;-)
[09:05] <slomo> seb128: just wanted to know what the experience with it is :)
[09:05] <seb128> slomo: anything specific we should try?
[09:06] <seb128> slomo: I expect we will get quite some users unhappy about the lack of totem-xine
[09:06] <huats> seb128: help me, I get spammed by millions of bugs handled by robert_ancell on anjuta :D
[09:06] <robert_ancell> huats: mwuhahaha!
[09:06] <seb128> huats: unsubscribe? ;-)
[09:06] <slomo> seb128: oh, check out the new, fancy dvd support, switching between subtitles and different audio tracks of the same file during playback, chained ogg support, etc :)
[09:07] <slomo> seb128: nothing specific, just want to know if all the new stuff works good :)
[09:07] <seb128> ok, will give you feedback
[09:07] <robert_ancell> seb128: speaking of totem, can you look at lp:~robert-ancell/totem/ubuntu?  I can't work out how to make it conflict properly
[09:07] <seb128> DVD playing is still crap in jaunty
[09:07] <slomo> seb128: i don't think anybody will be unhappy that totem-xine is gone
[09:07] <seb128> robert_ancell: "conlict"?
[09:07] <robert_ancell> seb128: conflict/replace the old packages
[09:07] <seb128> slomo: I think people playing DVDs will
[09:08] <seb128> robert_ancell: what issue do you get exactly?
[09:08] <robert_ancell> slomo: I couldn't get totem 2.27 to play DVD for me
[09:08] <slomo> seb128: probably only until they test it with totem-gstreamer :)
[09:08] <seb128> slomo: until they run into bugs like http://bugzilla.gnome.org/show_bug.cgi?id=575568
[09:08] <robert_ancell> seb128: hang on, will get dpkg log for you
[09:09] <seb128> "It looks like this is because the DVD is a music concert, with an LPCM
[09:09] <seb128> (uncompressed audio) track. ResinDVD currently only supports AC3 audio tracks,"
[09:09] <slomo> robert_ancell: that's good to know... do you have gst-plugins-bad installed? and which versions of gstreamer and gst-plugins-base?
[09:09] <seb128> slomo: gstreamer is getting better but is till not there yet
[09:10] <seb128> at least no sound on some DVD is a stopper for me
[09:10] <slomo> seb128: i can look at fixing that bug later (but i don't have such a dvd so someone else needs to try it)
[09:10] <seb128> that would rock ;-)
[09:10] <seb128> let me know if you need testing, I've some of those
[09:10] <robert_ancell> slomo: gst-plugins-bad 0.10.11-2ubuntu1
[09:11] <slomo> robert_ancell: too ancient, you want 0.10.11.2 :)
[09:11] <robert_ancell> slomo: ok, will need to update karmic packages then
[09:12] <chrisccoulson> heh. i use totem-xine in jaunty ;)
[09:18]  * robert_ancell wishes bugzilla.gnome.org would get better software/hardware
[09:19] <robert_ancell> seb128: http://paste.ubuntu.com/172851/
[09:20] <seb128> robert_ancell: oh
[09:21] <robert_ancell> I can't seem to convince dpkg to uninstall all the old packages and then install the new ones
[09:24] <seb128> robert_ancell: debuild clean?
[09:24] <seb128> robert_ancell: your control in bzr is outdated compared to control.in
[09:25] <robert_ancell> I was building with bzr-buildpackage, does that update it?
[09:25] <seb128> no
[09:25] <robert_ancell> damn
[09:25] <seb128> debuild clean to update it
[09:25] <seb128> diff -u control.in control
[09:25] <seb128> and see the difference ;-)
[09:28] <seb128> slomo: btw is there a reason why you upload gstreamer pre-versions to experimental rather than unstable?
[09:28] <robert_ancell> yeah, for some reason I thought it was being applied by bzr-buildpackage - because changing the control.in stopped the -xine.deb being built
[09:29] <seb128> robert_ancell: that's the .install and rules changes which did that
[09:29] <robert_ancell> Ahh ok
[09:29] <didrocks> seb128, robert_ancell : DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes debclean -d is better (-d because some clean target can fail if some files aren't found)
[09:29] <didrocks> robert_ancell: once again, all is written at https://wiki.ubuntu.com/DesktopTeam/Bzr :)
[09:30] <robert_ancell> seb128: I'm finishing up now, do you want to take over the remaining changes for totem?  I'm flying out on Monday so I wont have any time to work on it
[09:30] <seb128> you don't need a binary-post-install for each binary I think, you could call it once with specifying a package
[09:30]  * robert_ancell is currently in a state of information overload.  It will take some time to absorb the Wiki :)
[09:30] <seb128> robert_ancell: if I've time today I will look at it, otherwise it can wait
[09:31] <seb128> I've been trying to get some sponsoring help but seems other people are too busy for that this week
[09:31] <didrocks> robert_ancell: hehe, it's understandable ;)
[09:31] <robert_ancell> seb128: I copied that off gnome-games, I'm a bit hazy in the current state of Python .deb packaging
[09:31] <seb128> didrocks: what does DEB_AUTO_UPDATE_DEBIAN_CONTROL=yes do? is that an environment thing?
[09:31] <robert_ancell> huats: The update flood has ended :)
[09:31] <seb128> robert_ancell: ok, I don't know the python package new policy well either, that will work for sure so let it this way
[09:32] <robert_ancell> I'm needed elsewhere, see you guys in person next week!
[09:32] <slomo> seb128: yes, in the past people complained because often uploading stuff blocked transitions ;)
[09:33] <seb128> robert_ancell: have a good weekend and travel to spain
[09:33] <seb128> see you next week!
[09:33] <didrocks> seb128: my understanding is that it says basically "ignore build-depends not present on my computer"
[09:33] <seb128> slomo: bah, people want unstable to be stable ... ;-)
[09:33] <didrocks> seb128: but to get it taken into account into my host, I have to add -d option
[09:33] <seb128> didrocks: ok, so no interest if debuild clean works
[09:34] <seb128> (which should always be the case on the box where you build the package since build-depends are there for the build)
[09:34] <didrocks> seb128: exctly :)
[09:34] <seb128> but could be handy if you work on a box and use pbuilder to build for example
[09:34] <didrocks> seb128: yes
[10:22] <slomo> seb128: are all gstreamer packages in sync with ubuntu now btw?
[10:24] <seb128> slomo: let me look
[10:25] <seb128> gstreamer0.10-ffmpeg isn't
[10:25] <seb128> but I guess we can sync it, doing that now
[10:25] <seb128> I just backported http://launchpadlibrarian.net/23776863/gstreamer0.10-ffmpeg_0.10.6.2-1_0.10.6.2-1ubuntu1.diff.gz before jaunty
[10:25] <seb128> and that's in the new version
[10:26] <slomo> ok :)
[10:27] <seb128> slomo: and gst-plugins-bad0.10 is not
[10:27] <seb128> otherwise everything else is in sync
[10:29] <slomo> seb128: ok, what's the delta in -bad?
[10:29] <seb128> slomo: http://launchpadlibrarian.net/23125176/gst-plugins-bad0.10_0.10.10-1_0.10.10-1ubuntu1.diff.gz is the only change there
[10:29] <seb128> we spoke about it briefly before jaunty I think
[10:30] <slomo> seb128: ah, please sync gst-plugins-bad and gst-plugins-good from experimental then :) also, do you have gst-plugins-base 0.10.23-2? if not that would be good to have before totem 2.27, otherwise people will complain :)
[10:34] <seb128> slomo: ok, those are synced now, the whole gstreamer stack is in sync now, thanks for your work there ;-)
[10:37] <slomo> seb128: thank you for syncing it all :)
[10:42] <seb128> slomo: btw do you know what is to blame for the bug about totem hitting an xerror (xvimagesink code usually) on some videocard and drivers when using compiz?
[10:42] <seb128> I'm never sure what to do about that
[10:42] <slomo> usually it's a driver bug
[10:44] <seb128> the xorg guys tend to blame it on the software saying that it should handle better those cases and not crash, fallback to x11 or something if required
[11:03] <seb128> slomo: could you add this change to libunique in debian?
[11:03] <seb128> clean::
[11:03] <seb128>         [ -s po/unique.pot ] || rm -f po/unique.pot
[11:04] <seb128> it should not make a difference for debian and that's the only difference with ubuntu right now
[11:04] <seb128> the translation magic doesn't like the empty template
[11:25] <dholbach> heya seb128
[11:25] <seb128> hello dholbach, how are you?
[11:25] <dholbach> diverse_izzue is working on the tracker package - he said you sent him to #ubuntu-motu! :-)
[11:25] <dholbach> good good - TGIF!
[11:25] <dholbach> how 'bout you?
[11:26] <crevette_> hey dholbach
[11:26] <dholbach> heya crevette_!
[11:27] <seb128> dholbach: not sure what he's trying to do on it, I sent him to #ubuntu-motu for questions about updating patches
[11:27] <dholbach> no worries
[11:27] <chrisccoulson> tracker? what's happening to the tracker package?
[11:28] <dholbach> he's struggling with the autotools.patch or something
[11:28] <seb128> dholbach: but tracker is already being handled by chrisccoulson there so this guy should be careful to not duplicate work
[11:28] <dholbach> right
[11:28] <seb128> chrisccoulson: apparently this guy wants to try 0.6.94
[11:28] <seb128> chrisccoulson: so he tried to build a local version and had issues updating the autotools chnage
[11:28] <chrisccoulson> ah, ok. but 0.6.94 doesn't give that much over 0.6.93 really
[11:28] <seb128> hey diverse_izzue
[11:29] <diverse_izzue> hi seb128
[11:29] <dholbach> diverse_izzue: you can have a chat with chrisccoulson - he's mostly taking care of the package - if you want an "easier" update, have a chat with seb128, he hast the best overview over what needs doing in desktop land :)
[11:30] <diverse_izzue> dholbach: thx
[11:31] <dholbach> #ubuntu-desktop is a fun place to be and I hope you'll enjoy doing some packaging here :)
[11:31] <chrisccoulson> it is a fun place to be :)
[11:31] <diverse_izzue> hi chrisccoulson
[11:31] <dholbach> chrisccoulson: when are you applying for MOTU?
[11:31] <dholbach> did I ask already? :)
[11:32] <chrisccoulson> dholbach - i'm working on that. i'll try and do it at the weekend;)
[11:32] <diverse_izzue> chrisccoulson: so the story is i'm trying to update jaunty's tracker package to 0.9.94 and fail to update the 99_autotools.patch
[11:32] <chrisccoulson> hi diverse_izzue
[11:32] <dholbach> chrisccoulson: that's what we like to hear :)
[11:32] <chrisccoulson> diverse_izzue - is this for a SRU or just for yourself locally?
[11:33] <chrisccoulson> the 99_autotools.patch should just update by running "autoreconf -f -i"
[11:33] <diverse_izzue> chrisccoulson: this is just what i chose to be my first packaging experiment
[11:33] <chrisccoulson> you might have to delete the old patch and start again though. the existing patch might not apply if they modified the build system
[11:34] <diverse_izzue> the existing patch does not apply, that's why i'm trying to update it
[11:34] <chrisccoulson> diverse_izzue - just delete it and start again - that's easiest;)
[11:34] <diverse_izzue> problem is, autoreconf: automake failed with exit status: 1
[11:34] <chrisccoulson> hmmmm
[11:34] <chrisccoulson> i could try that, but i can't do it until i get home from work
[11:35] <seb128> pitti: could you tried to wave bug #372746 in, it re-add a change dropped by mistake in the previous jaunty-updates update
[11:35] <chrisccoulson> i don't thin they changed much in the build system in 0.6.94. the only thing i know they changed is to disable the push modules by default
[11:35] <seb128> tried -> try
[11:36] <diverse_izzue> chrisccoulson: just to verify i'm doing everything right. after copying the debian folder over to the new source tree, i apply all patches before the 99_autotools.patch one using quilt push 11_whatever.patch. then i try to execute autoreconf.
[11:37] <chrisccoulson> once you've done that, you need to do "quilt new 99_autotools.patch" (assuming you deleted the old patch), then add all the files to the patch (find | xargs quilt add), then run "autoreconf -f -i"
[11:37] <chrisccoulson> that should work ok
[11:38] <diverse_izzue> chrisccoulson: deleting the old patch is as easy as rm 99_autotools.patch?
[11:38] <chrisccoulson> diverse_izzue - you might need to remove it from debian/patches/series too as I think quilt new will fail
[11:38] <chrisccoulson> you picked a good package to start with - quilt is really nice to use :-/
[11:39] <chrisccoulson> seb128 likes quilt too ;)
[11:39] <chrisccoulson> lol
[11:39] <diverse_izzue> do i sense irony there?
[11:39] <chrisccoulson> sarcasm ;)
[11:40] <chrisccoulson> quilt is quite horrific to use for some tasks
[11:41] <chrisccoulson> diverse_izzue - i don't think tracker 0.6.94 fixes any common issues that users are complaining about at the moment though
[11:41] <chrisccoulson> do you use tracker?
[11:41] <diverse_izzue> chrisccoulson: yes i do
[11:41] <crevette> hello others as well
[11:42] <chrisccoulson> do you have the issue with index corruption and the repeated notification that won't go away?
[11:42] <diverse_izzue> no, it runs quite fine actually. sometimes the tracker-applet crashes, else fine
[11:42] <diverse_izzue> chrisccoulson: it's really just  a random pick for first experiments, as good as any other package
[11:42] <chrisccoulson> ah, ok. i was going to ask you to help test a patch;)
[11:44] <diverse_izzue> chrisccoulson: what do you use as pastebin? can i put the output of autoreconf -i -f there?
[11:45] <diverse_izzue> chrisccoulson: http://pastebin.ubuntu.com/172921/
[11:46] <seb128> chrisccoulson: one of the debian pkg-gnome guy added a patch to the bts to have a quilt command doing the equivalent of the other edit-patch commands
[11:47] <chrisccoulson> seb128 - that's useful to knwo
[11:48] <chrisccoulson> diverse_izzue - i'm not sure why that fails yet. mind if i take a look at that when i get home from work just after lunch?
[11:48]  * chrisccoulson loves fridays
[11:48] <diverse_izzue> chrisccoulson: that'd be great
[11:48] <chrisccoulson> cool
[11:49] <diverse_izzue> i'll try to be around, or at least pop in later in the afternoon
[11:50] <chrisccoulson> no problem. i finish work at 1pm uk time and then it takes me about 25min to drive home afterwards
[11:51] <diverse_izzue> in uk it's 11:50 now?
[11:51] <chrisccoulson> yeah, that's right
[11:51] <diverse_izzue> gotcha. cu later then.
[11:51] <diverse_izzue> thanks for the help
[11:51] <chrisccoulson> you're welcome
[12:43] <chrisccoulson> anyone noticed any dbus issues in jaunty?
[12:43] <chrisccoulson> like messages timing out and things
[12:58] <pitti> seb128: will have a look
[12:58] <seb128> chrisccoulson: what sort of issue or timeout exactly?
[12:58] <seb128> pitti: thanks
[13:01] <chrisccoulson> seb128 - sometimes when an application puts a lot of data on the session bus, everything on the desktop that relies on the session bus stops working and never recovers
[13:01] <chrisccoulson> it's really wierd, and not all that repeatable
[13:02] <chrisccoulson> i noticed dbus-daemon consuming a lot of memory too (900MB)
[13:02] <seb128> nop, didn't notice any of those
[13:02] <chrisccoulson> i suppose i should run it through valgrind really if i can trigger it again
[13:02] <seb128> but I doubt I've "an application puts a lot of data on the session bus"
[13:02] <chrisccoulson> seb128 - tracker does that;)
[13:03] <chrisccoulson> it's terrible for spamming the session bus
[13:03] <seb128> I'm not using it, it's putting a lot of ios on the disk for sure which is enough ;-)
[13:03] <chrisccoulson> i might ask upstream if they would consider using p2p links instead
[13:03] <chrisccoulson> seb128 - tracker 0.7.x is supposed to perform much better with regards to IO;)
[13:03] <seb128> how?
[13:03] <seb128> I though the issue was inotify
[13:04] <crevette> hey, if someone has time for https://bugs.edge.launchpad.net/bugs/373199, 2.26.0 was already pushed to karmic, it just need the same package except removing the Depends on gnome-bluetooth-2.27.0
[13:04] <chrisccoulson> no idea. upstream say they've noticed a welcome performance improvement after removing all the qdbm code
[13:04] <chrisccoulson> i haven't tried it out yet though, so I can't say how much better it is
[13:04] <seb128> I'm waiting to see ;-)
[13:05] <seb128> for sure tracker is getting work nowadays so it should become better
[13:05] <chrisccoulson> the new version should resolve a lot of the issues that users currently complain about, particularly the index corruption problems
[13:06] <seb128> we could perhaps reconsider installing it by default in karmic
[13:06] <seb128> karmic is going to be the cycle where all the rewrote and changes land anyway
[13:06] <seb128> ie *kit, e-d-s to dbus, plymouth, etc
[13:07] <seb128> I'm pondering trying to push the new gdm too now, especially if next cycle is a lts
[13:07] <chrisccoulson> seb128 - i'm not sure about installing it by default in karmic. i need to speak with upstream really and see how confident they are of having a solid stable release in time, considering the changes in 0.7.x are pretty significant
[13:07] <chrisccoulson> it might be good to let the dust settle and install it by default in karmic+1
[13:08] <crevette> it's time to use ext4 by default then, in order to have change in the full stack
[13:08] <seb128> well my logic is that we need to land changes this cycle if we want those in the lts
[13:08] <crevette> :)
[13:08] <chrisccoulson> seb128 - that's a fair point. some of the new stuff this cycle sounds interesting
[13:08] <seb128> we don't want to get tracker on by default in a lts cycle without testing it before
[13:08] <seb128> so either it's this cycle and we have testing feedback and can evaluate it for lts
[13:08] <seb128> or it's after the lts
[13:08] <chrisccoulson> crevette - i recently converted to ext4 and now i see frequent lockups when deleting files :(
[13:09] <crevette> chrisccoulson, yeah I'll wait few cycle before using that
[13:09] <seb128> crevette: I don't see the point of being crack addict on filesystem really
[13:09] <seb128> you expect those to be stable
[13:09] <crevette> seb128, yeah me too
[13:09] <seb128> crevette: you are the one suggesting the change though ;-)
[13:10] <crevette> seb128, there was a :-) two lines below
[13:10] <seb128> no, there was a ":)" ;-)
[13:10] <chrisccoulson> seb128 - i'm going to work on getting tracker 0.7 in karmic over the next few days. uploading after you guys come back from UDS might be good timing though, as I spoke to mbiebl who maintains it in debian and he says it crashes a lot at the moment in its current state ;)
[13:10] <seb128> chrisccoulson: ok, good
[13:11] <chrisccoulson> i'm still working on a jaunty SRU for tracker at the moment though
[13:11] <seb128> trying to fix what? the index corruption?
[13:15] <chrisccoulson> seb128 - we can't fix the index corruption in jaunty. i'm trying to fix the issue where the error notification repeatedly appears and can't be dismissed
[13:16] <chrisccoulson> the problem is is that i can't recreate the issue here and the people that are experiencing it are being somewhat less then co-operative with providing useful information ;)
[13:16] <seb128> don't spend too much time on jaunty srus
[13:16] <seb128> I would recommend uninstalling tracker on jaunty
[13:17] <chrisccoulson> yeah, it does have a lot of issues in jaunty
[13:17] <seb128> you will not realistically get it great there
[13:17] <seb128> so better to focus on getting it in shape in karmic than patchworking jaunty
[13:18] <seb128> and tell to jaunty users that the current version is not ready and they should better not use it if they have issues
[13:20] <chrisccoulson> i think that the current package in my PPA will make it better for users experiencing the issues (it actually reindexes properly without the user having to do anything and shouldn't spam the user with lots of error notifications), but i'm having difficulty finding people to test it now
[13:20] <chrisccoulson> i think most people already got fed up of it and uninstalled it;)
[13:22] <diverse_izzue> chrisccoulson: ...or they are quite happy with the one currently in the repos. 0.6.93 runs quite stably for me, at least the indexer works very well now
[13:22] <seb128> chrisccoulson: as said don't spend to much efforts on that imho, better focussing on having the new version stable
[13:23] <chrisccoulson> seb128 - yeah, i'll do that.
[13:23] <chrisccoulson> diverse_izzue - the jaunty version has quite a lot of issues still;)
[13:23] <chrisccoulson> right, i've got to go anyway. time for me to go home
[13:24] <seb128> chrisccoulson: see you later
[13:47] <seb128> pitti: apparently you didn't merge your notify-osd changes before jaunty in bzr?
[13:47] <seb128> notify-osd (0.9.11-0ubuntu3) jaunty; urgency=low
[13:47] <seb128>   * Correctly check for multihead_mode, to make bubbles always appear on the
[13:47] <seb128>     primary screen. Cherrypicked from trunk. (LP: #331369)
[13:48] <seb128> pitti: this change is not in lp:~ubuntu-desktop/notify-osd/ubuntu
[13:51] <pitti> seb128: it's in bzr+ssh://bazaar.launchpad.net/%7Eubuntu-desktop/notify-osd/notify-osd-jaunty/
[13:51] <pitti> sorry, seems I forgot to update Vcs-Bzr:
[13:51] <seb128> notify-osd-jaunty?
[13:51] <seb128> should that be merged in ubuntu too?
[13:52] <pitti> there unfortunately was some confusion, and notify-osd got changes which weren't appropriate for jaunty at that time
[13:52] <seb128> I'm not sure why you changed the bzr there?
[13:52] <pitti> so I left that in the "packaging trunk" for kamic, and created a jaunty branch
[13:52] <pitti> seb128: it should be merged, yes
[13:52] <seb128> ok, makes sense now
[13:52] <seb128> thanks
[13:52] <pitti> I can't remember exactly any more, I'm afraid
[13:53] <pitti> but yes, the jaunty branch shoudl be merged into trunk
[13:53] <seb128> ok thanks
[13:53] <seb128> agateau was asking me about it
[13:53] <seb128> they try to work on a sru
[13:53] <pitti> yeah, I warned them to request them on the LP bugs before starting to work on it :)
[13:53] <seb128> and that created some confusion, we are good now
[13:53] <seb128> thanks!
[13:54] <pitti> sorry for the mess
[13:54] <seb128> pitti: yeah, he was just trying to figure was bzr revision was used in jaunty
[13:54] <seb128> don't worry, bzr doesn't make things always easier we know that ;-)
[14:08] <chrisccoulson> diverse_izzue - i just tried running autoreconf on tracker-0.6.94 here, and it works ok
[14:08] <diverse_izzue> chrisccoulson: this is not fair!
[14:08] <tjaalton> hmm, polkit-auth doesn't list org.fd.hal.power-management when I'm logged in, perhaps that's why the menus don't have any entries to suspend etc?
[14:08] <tjaalton> on karmic
[14:09] <chrisccoulson> tjaalton - hasn't the power stuff been disabled in hal now?
[14:09] <chrisccoulson> pitti will know ;)
[14:09] <pitti> no, it hasn't been disabled
[14:09] <pitti> it's just not used any more by g-p-m
[14:09] <tjaalton> ok, so what does g-p-m use?
[14:10] <pitti> devicekit-power
[14:10] <tjaalton> oh wait, devicekit-power
[14:10] <pitti> tjaalton: that's still strange, you shuold still have those privileges
[14:10] <tjaalton> so, it doesn't seem to work here :)
[14:10] <pitti> I do have suspend/hibernate in the shutdown menu
[14:10] <pitti> polkit-auth|grep power-management has them all
[14:11] <tjaalton> empty
[14:11] <pitti> ugh
[14:11] <pitti> tjaalton: check ck-list-sessions ?
[14:11] <tjaalton> is-local =TRUE
[14:11] <tjaalton> oh
[14:11] <pitti> active = TRUE ?
[14:11] <tjaalton> active = FALSE
[14:11] <pitti> that'd be it
[14:11] <tjaalton> heh
[14:12] <chrisccoulson> diverse_izzue - could you run "autoreconf -f -i -v" to get more output?
[14:18] <tjaalton> pitti: ok, found the problem. I had gdm on tty1
[14:19] <pitti> tjaalton: hm, why woudl that break CK?
[14:19] <diverse_izzue> chrisccoulson: done, http://pastebin.ubuntu.com/173011/
[14:19] <tjaalton> pitti: beats me..
[14:22] <tjaalton> pitti: perhaps this would help? http://cvs.fedoraproject.org/viewvc/devel/ConsoleKit/ConsoleKit-0.3.0-get-vt-from-display-instead-of-controlling-tty.patch?revision=1.1&view=markup
[14:22] <pitti> tjaalton: btw, do you guys plan to upload -intel 2.7.1 to karmic soon? right now it's just in the jaunty -updates repo, right?
[14:22] <pitti> tjaalton: by the name of it it might indeed
[14:22] <tjaalton> pitti: last I heard was that bryce was working on it
[14:23] <pitti> *sigh* I wish John would apply patches that get sent to him
[14:25] <chrisccoulson> diverse_izzue - do you have gtk-doc-tools installed?
[14:25] <tjaalton> pitti: ok, bug 375877 now has consolekit too, so close that part if/when you add it :)
[14:25] <pitti> tjaalton: thanks
[14:26] <pitti> tjaalton: well, the boot flicker is pretty irrelevant with KMS, right? It's mainly an issue for older drivers which won't get ported to KMS, I guess?
[14:26] <chrisccoulson> or closed ones like nvidia;)
[14:26] <diverse_izzue> chrisccoulson: installed it and now autoreconf passes!
[14:26] <tjaalton> pitti: there's a state change even with krm
[14:26] <tjaalton> uh
[14:26] <tjaalton> *kms
[14:26] <chrisccoulson> diverse_izzue - cool:)
[14:27] <diverse_izzue> indeed. so the procedure is to first create a new patch using quilt, then add all files to that patch, then call autoreconf, and then use quilt to update that patch?
[14:28] <chrisccoulson> that is sometimes what i do. but you have to be careful that autoreconf might create new files, and these won't get added to the patch
[14:29] <diverse_izzue> chrisccoulson: ...the safe way would be what then?
[14:29] <chrisccoulson> sometimes i create a copy of the source directory (with all patches applied), run autoreconf in one, then create a diff and use that as the patch
[14:30] <diverse_izzue> i'll try the easy version first :-) so much to learn.
[14:36] <seb128> chrisccoulson: are you still working on some merges out of trackeR?
[14:37] <chrisccoulson> i'm not doing anything specific with tracker just yet
[14:37] <seb128> ok so remove the tracker part
[14:37] <seb128> are you working on some merges still? ;-)
[14:38] <seb128> gnome-panel I think
[14:38] <seb128> I'm not sure if you said you would do gnome-applets too
[14:38] <diverse_izzue> chrisccoulson: so now i have a patch that quilt complains "does not remove cleanly". might i have run in the kind of situation you were mentioning?
[14:38] <chrisccoulson> ah, yes. i've still to finish gnome-panel. it's pretty much there, but the delta to debian is huge
[14:38] <chrisccoulson> and yes, gnome-applets is on my list
[14:38] <seb128> ok excellent
[14:38] <seb128> chrisccoulson: I know the delta is not trivial, thanks for taking over the task ;-)
[14:39] <chrisccoulson> i think the gnome-panel delta looks worse than it really is because of the all the indicator-applet and fusa migration stuff. and debian have some patches that we're not really interested in too
[14:40] <chrisccoulson> hmmm, there's no version 1.3 for gvfs listed on bugzilla.gnome.org :-/
[14:40] <seb128> yeah, I quickly copy autotools, etc change over to have a sane diff when I work on such changes
[14:40] <seb128> that's because there is no 1.3 tarball
[14:40] <seb128> use trunk
[14:40] <seb128> the karmic version is a git snapshot
[14:42] <chrisccoulson> seb128- thanks
[14:42] <chrisccoulson> diverse_izzue - did you run "quilt refresh" before trying to remove the patch ;)
[14:42] <chrisccoulson> it's a common pitfall with quilt
[14:42]  * pitti ponders http://launchpadlibrarian.net/26754645/buildlog_ubuntu-karmic-amd64.gnome-power-manager_2.26.1-0ubuntu2_FAILEDTOBUILD.txt.gz
[14:43] <pitti> none of libgnomeui, gnome-panel, libbonoboui has been updated recenlty
[14:43] <chrisccoulson> i thought a lot of gnome stuff dropped dependencies on libgnomeui?
[14:43] <chrisccoulson> are you sure it really needs it?
[14:44] <pitti> chrisccoulson: it might be obsolete, I'll check it
[14:44] <pitti> I just updated the apport hook, so I didn't do a lot of other checks
[14:45] <chrisccoulson> i don't think g-p-m needs libgnomeui (although that doesn't solve the issue with libgnomeui, but it might mean you can build g-p-m)
[14:45] <chrisccoulson> there's no check for gnomeui in g-p-m's configure.ac
[14:45] <chrisccoulson> i think that dependency has gone
[14:45] <pitti> cool
[14:45] <seb128> pitti: just retry it, I bet it's anything under it in the stack having arch any all mismatch between i386 and amd64 builds
[14:46] <pitti> ah, perhaps
[14:46] <seb128> anything -> something
[14:46] <pitti> seb128: but indeed, isntead of retrying I'll throw out the obsolete build deps
[14:46] <pitti> yay cruft removal :)
[14:46] <seb128> right
[14:46]  * seb128 always diff configure.{ac,in} between versions
[14:46] <chrisccoulson> yeah, i just did that now
[14:47] <seb128> we should have a hook for that somewhere
[14:47] <chrisccoulson> gnomeui was required in 2.24 but not in 2.26 now
[14:47] <seb128> I did the configure.{ac,in}, debdiff debs and check symbols for each uploads
[14:47] <seb128> do we have a clever way we could hook those with bzr-buildpackage?
[14:48] <seb128> and also look to the NEWS and copy that to changelog ;-)
[14:48] <chrisccoulson> that would be nice, although not everything in NEWS is interesting
[14:48] <seb128> well, copy then you can clean
[14:48] <seb128> I usually take changes which are not translations
[14:49] <seb128> I've a small bit of code which indent and clean the (....) at the end of each lines
[14:49] <seb128> those are usually upstream bug numbers of names, which we don't care about in the changelog
[14:49] <seb128> "or"
[14:53] <pitti> chrisccoulson: hah, doesn't help; libpanel-applet2-dev depends: libgnomeui-dev, and g-p-m needs the former
[14:54] <chrisccoulson> :(
[14:54] <pitti> but at least it doesn't explicitly mention it any more
[14:54] <chrisccoulson> that's a shame
[14:54] <pitti> and I'm pretty sure that the panel still uses at least bonobo
[14:54] <chrisccoulson> yeah, it does unfortunately
[15:01] <seb128> chrisccoulson: you just won ubuntu-desktop membership congrats ;-)
[15:01] <chrisccoulson> seb128 - thanks:)
[15:02] <seb128> will make easier for you to work on desktop updates, you can push directly to the team bzr now
[15:02] <chrisccoulson> thanks
[15:02]  * pitti hugs chrisccoulson, you do amazing work!
[15:02] <seb128> you're welcome, thank you for the good work ;-)
[15:02]  * chrisccoulson hugs pitti and seb128
[15:02]  * seb128 hugs chrisccoulson and pitti
[15:03] <pitti> hugfest!
[15:03] <seb128> desktop team hug ;-)
[15:03]  * pitti hugs seb128 and chrisccoulson
[15:03] <chrisccoulson> pitti - that dependency issue appears to be related to libesd-alsa0
[15:03] <chrisccoulson> "libesd-alsa0: Depends: esound-common (>= 0.2.41-3) but it is not going to be installed"
[15:03] <pitti> chrisccoulson: OMG, is that thing still alive?
[15:04] <chrisccoulson> yeah, seems so
[15:04] <seb128> can we get ride of this?
[15:04] <chrisccoulson> i just tried it in a karmic chroot
[15:04]  * pitti prepares a Verteron pulse and directs it against esound
[15:04] <seb128> I guess libgnome still use libesd for sound events
[15:04] <chrisccoulson> seb128 - it seems so
[15:04] <pitti> seb128: didn't we have a patch like ages ago to make libgnome use aplay? :-)
[15:04] <seb128> ring a bell ;-)
[15:11] <chrisccoulson> is there no documentation for gvfs? i can't find any in the source tree
[15:13] <seb128> what are you trying to do exactly?
[15:13] <seb128> the user side is mostly gio which is in glib
[15:13] <chrisccoulson> i'm trying to debug a crash at the moment
[15:14] <seb128> gvfs is mostly a set of backends for access other locations through gio
[15:14] <chrisccoulson> upstream will probably have it fixed before i've worked out what's going on though ;)
[15:14] <seb128> accessing
[15:15] <seb128> anything special you are looking for? in which code does it crash?
[15:17] <chrisccoulson> gvfsd-computer crashes for me on startup with gvfs-gdu-volume-monitor, but works ok with the gvfs-hal-volume-monitor
[15:17] <seb128> chrisccoulson: http://library.gnome.org/devel/gio/unstable is mostly the gio, gvfs documentation
[15:18] <seb128> chrisccoulson: I was having https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/376145 yesterday on my desktop in case that's a similar issue
[15:18] <seb128> but opening an upstream bug is usually a good strategy for gvfs bugs, they are responsive
[15:18] <seb128> or try #nautilus on irc.gnome.org
[15:19] <chrisccoulson> yeah, i think that's a different crash. the one i'm seeing is http://bugzilla.gnome.org/show_bug.cgi?id=582772
[15:22] <seb128> chrisccoulson: "        filename = 0x1557990 "ð\030V\001"" is weird
[15:23] <chrisccoulson> seb128 - i don't think that filename is initialized to anything at the point it crashes
[15:23] <seb128>         basename = 0x0
[15:23] <seb128> is the issue I guess
[15:24] <chrisccoulson> yeah, that's the issue. that happens because g_drive_get_name (file->drive) returns that
[15:24] <chrisccoulson> but that's as far as i got ;)
[15:25] <seb128> chrisccoulson: you can talk to davidz on #gnome-hackers he's the one working on that and usually responsive
[15:26] <seb128> you can try to see what name is listed in gvfs-mount -li too
[15:26] <chrisccoulson> yeah, i might pop over there in a bit. i don't want to pester him too much - i expect he's already quite busy;)
[15:27] <chrisccoulson> i'll have a look at the output of gvfs-mount -li in a second - just need to boot the machine again
[15:30] <chrisccoulson> seb128 - my floppy drive has no name according to the output of gvfs-mount -li
[15:30] <seb128> lol
[15:30] <chrisccoulson> i really need to get rid of that!
[15:30] <seb128> the floppy drive is stricking back ;-)
[15:30] <chrisccoulson> "Drive(0): (null)"
[15:31] <chrisccoulson> thanks, i'll add that to the bugzilla
[15:31] <seb128> you're welcome
[15:32] <seb128> I guess those informations are mostly coming from devicekit
[15:32] <pitti> what's a floppy drive?
[15:32] <seb128> dunno if you can lskit in some way though
[15:32] <pitti> yes, devkit-disks --dump should have it
[15:35] <chrisccoulson> pitti - according to devkit-disks, there is no vendor or model name for my floppy drive
[15:35] <chrisccoulson> that'll be the problem then ;)
[15:35] <diverse_izzue> chrisccoulson: OMG it built! thanks for your patience!
[15:36] <chrisccoulson> good stuff diverse_izzue
[15:36] <diverse_izzue> i know - small step for humanity :-)
[16:03] <pitti> seb128: so, we want bug 351577 ?
[16:03] <seb128> pitti: well it's a feature which has been listed in GNOME 2.26 notes and that some users and press article wondered why it was not working in jaunty
[16:04] <seb128> I'm not looking for extra work really but apparently that's something some users rely on
[16:04] <pitti> okay
[16:07] <crevette> does someone think having bluetooth service starting on bluetooth devices add and removal (managed by udev) is something to have?
[16:08] <seb128> that would be nice to not have those running if you have no bluetooth devices
[16:09] <crevette> yeah, I seen people requesting that
[16:09] <crevette> fedora did that, and and udev rules (that I don't know)  seems quite simple
[16:09] <seb128> cool
[16:10] <crevette> the tricky part is the init script which seems to me complicated
[16:33] <dobey> seb128, pitti: do either of you have any idea why setup.py would complain about --build-base ?
[16:35] <pitti> I've never seen that
[16:40] <dobey> pitti: http://launchpadlibrarian.net/26766895/buildlog_ubuntu-jaunty-i386.ubuntuone-client_0.90.1-0%2Br17-0~ubuntu.9.04_FAILEDTOBUILD.txt.gz
[16:40] <dobey> cd . && python setup.py build --build-base="/build/buildd/ubuntuone-client-0.90.1-0+r17/./build"
[16:40] <dobey> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
[16:40] <dobey> :(
[17:06] <pitti> seb128: grabbing totem-pl-parser
[17:06] <seb128> pitti: thanks!
[17:10] <pitti> oh, robert creates his own branches instead of committing to ~ubuntu-desktop
[17:10] <pitti> seb128: ^ did you ask him to?
[17:12] <seb128> pitti: no
[17:12] <seb128> pitti: but I think he started on that before that you added him to the ubuntu-desktop team on launchpad
[17:12] <pitti> ah, perhaps
[17:14] <pitti> seb128: you commented on g-python-extras, doing that yourself?
[17:14]  * pitti grabs sane-backends
[17:14] <seb128> pitti: yes, I will review it in a bit again
[17:16] <crevette> wow, phoronix tells 9.10 alpha-1 is 100% pure sugar in regads of 9.04
[17:17] <crevette> "Muxixam performance" as would say Zorglub :)
[17:17] <crevette> "Mumixam" rather (/me has problem with zorglang)
[17:31] <localgod11> I was trying to install lirc and something has gone very wrong now when I install anything i get pastebin.com/mef7fd51
[17:35] <seb128> use #ubuntu for user questions
[17:36] <localgod11> tried that no love there
[17:38] <pitti> ok, that's it for today
[17:38] <pitti> have a nice weekend, and see you in Barcelona!
[17:39] <pitti> I'll shut down my IRC proxy, won't have time for that I guess
[18:14] <lool> seb128: Would you mind syncing esound over from Debian incoming?  it's likely to fix the build issue on i386 which breaks all ubuntu livefs builds
[18:15] <seb128> lool: looking
[18:15] <lool> I didn't actually test built it without network, but saw no download in my squid log
[18:21] <seb128> lool: synced
[18:34] <seb128> lool: ok, it built on i386 now
[18:40] <tedg> dobey: BTW, you might look at the python script that was done for the Breathe icon set.  It's similar to icontool but handles cropping the SVG images as well.  lp:breathe-icon-set
[18:41] <tedg> dobey: Or atleast the render part of icontool
[19:00] <lool> seb128: thanks!
[20:22] <mpontillo> So I'm trying to do a simple Debian merge, and there is a conflict in 99_autoreconf.patch. Is the best way to resolve this to [do a temp hack to the quilt-based package to support the apply-pathces target and] drop into a cdbs-edit-patch shell, then run "autoreconf -i -v" and remove the autom4te.cache?
[20:25] <seb128> mpontillo: that's a good way
[20:25] <seb128> mpontillo: other way is to push the patch before that in the serie, copy the dir manually, autoreconf, clean cach, diff and copy the patch to the package source
[20:29] <mpontillo> thanks seb128. it sounds like there is a need for quilt-edit-patch script? ;) (or in this case, quilt-replace-patch, I suppose...)
[20:29] <seb128> right
[20:29] <seb128> having cdbs-edit-patch working on quilt packages would be nice
[20:30] <seb128> there is a debian quilt bug which has been recently opened with a such change apparently too
[20:30] <mpontillo> I don't think it would be too difficult. just run the patch target instead of apply-patches?
[20:30] <crevette> heya
[20:30] <mpontillo> (if quilt is the what-patch)
[20:32] <mpontillo> ... I suppose the only twist might be if patch order was important, and the series file was different than the sorted contents of debian/patches?
[20:33] <seb128> right
[20:35] <mpontillo> think the ltmain.sh --as-needed patch we've got everywhere will ever be incorporated into libtool?
[20:38] <seb128> I've no clue about that
[20:38] <seb128> that's a good question of upstream rather
[21:48] <bryce> tjaalton, pitti: I rolled the 2.7.1 merge for x-updates but since we were frozen, and since I figured debian would have it packaged soon, I figured I'd wait.  But I didn't get around to it yesterday, and I'm off today and traveling monday so won't get to it before spain.
[21:50] <bryce> tjaalton: on the other hand, I figure we're likely to pull in 2.8 rc stuff following uds, so 2.7.1 would have a pretty short life ;-)
[22:26] <nrg> hello
[22:29] <nrg> I have an Hardy box that I can't manually start gnome-volume-manager on.
[22:30] <nrg> It exits 0 and no verbosity.
[22:30] <nrg> I am running it with:
[22:30] <nrg> gnome-volume-manager --sm-disable -n
[22:31] <nrg> I have a feeling that this is a dbus issues.  Any suggestions on what to look at?
[22:44] <chrisccoulson> nrg - you should probable try #ubuntu for support
[22:45] <chrisccoulson> why you want to run g-v-m on hardy though?
[22:46] <chrisccoulson> and are you sure it exits? does it not just daemonize?
[22:46] <chrisccoulson> (not sure, as I have never looked at the g-v-m code)
[23:13] <nrg> chrisccoulson: g-v-m is an app requirement and it exits immediately with the '-n' switch
[23:14] <nrg> chrisccoulson: which is suppose to keep it in the foreground
[23:14] <chrisccoulson> ah, ok. i haven't had to use g-v-m since the last time it was installed by defaul
[23:14] <chrisccoulson> t
[23:20] <nrg> chrisccoulson: you think this a better question for #ubuntu?
[23:20] <chrisccoulson> nrg - yes
[23:20] <nrg> will do... thanks