[07:12] <NCommander> Is anyone working on gstreamer0.10?
[07:48] <lool> NCommander: These were uploaded in Debian I think
[07:48] <NCommander> I see
=== Tallken_ is now known as Tallken
[09:31] <lool> seb128: Re: shared-mime-info, I updated the upstream and added a recommends in glib :-/
[09:31] <lool> and a depends in evince
[09:31] <seb128> lool: what made you change opinion on the topic?
[09:32] <lool> mccaslen saying the distributors should require it
[09:32] <lool> I still think evince is broken (as listed upstream)
[09:32] <lool> and glib too, but that's another topic
[09:32] <lool> seb128: In fact, I'm still convinced that this is a broken situation
[09:33] <lool> But I don't want debian/ubuntu to play badly if that's an upstream expectation
[09:33] <lool> IOW, if you ask be about correct packaging, I think the recommends is a bad idea, but because I don't want to hurt upstream I'm adding it nevertheless  :-/
[09:33] <lool> seb128: You see, in the case of evince it's really a Depends
[09:33] <seb128> ok, I was just wondering if there was something which was discussed on IRC or something because the bug discussion is not far from what we discussed on IRC
[09:34] <lool> seb128: When we discussed it on IRC, I went to check whether there was a .spec in glib svn, but as there wasn't, I couldn't check whether fedora was requiring it
[09:35] <lool> It's really sad that they make it an upstream requirement like this, it's really not negligible for chroots or vms
[09:35] <lool> I even suspect it might introduce another build-dep loop when bootstrapping ports
[09:35] <seb128> it's only a recommends
[09:36] <lool> Yeah
[09:36] <seb128> you are not forced to install those
[09:36] <lool> I think they use a stronger dependency than us in the rpm packaging
[09:37] <seb128> well, technically if you want a 100% functionnal gio you need shared-mime-info
[09:37] <lool> So I'm really adding the dependency for upstream's concerns here, not for actually solving evince problem   :-/
[09:37] <seb128> if that the mimetype, icons, etc informations
[09:37] <seb128> s/if that/it has
[09:37] <lool> Yeah but not all apps need this and it's heavy
[09:37] <seb128> I don't think fedora for example cares about minimal environment
[09:37] <seb128> they think standard desktop installation
[09:37] <lool> exactly
[09:37] <seb128> it's not heavy in fedora standards
[09:38] <lool> and glib is used outside of the desktop these days
[09:38] <seb128> it's not heavy for a modern desktop and you want it on a desktop environment
[09:38] <lool> We're not speaking of glibc, but it's the same order of magnitude
[09:38] <seb128> they optimize for what is 99% of their usecase
[09:39] <lool> Like 11500 rdeps on libc and 2150 on libglib
[09:39] <seb128> maybe the debian packaging system lacks granularity
[09:39] <seb128> we should have Desktop-Recommends Server-Recommends Bootstrap-Recommends ;-)
[09:39] <lool> Well in this case we even have the possibility to detect apps using the explicit content type guessing api
[09:39] <lool> Just not via the variadic args
[09:40] <seb128> it's not used only for that though
[09:40] <lool> Perhaps I should only be pulling this instead?  hmm complex and not reliable
[09:40] <seb128> it's used for getting icons properties too for example
[09:41] <NCommander> hey seb128
[09:41] <seb128> hello NCommander*
[09:41] <lool> This is all quite unfortunate   :-/
[09:41] <NCommander> seb128, any news on gstreamer0.10?
[09:41] <crevette> hello
[09:41] <seb128> NCommander: "news"?
[09:41] <seb128> NCommander: like some news are expected?
[09:41] <NCommander> seb128, like someone fixed the FTBFS?
[09:41] <NCommander> or is working on it?
[09:41] <seb128> NCommander: I just come back from weekend care to give some context?
[09:42] <seb128> oh, it ftbfs, I forgot about that
[09:42] <NCommander> *is someone
[09:42] <NCommander> Yeah
[09:42] <NCommander> Nasty one too
[09:42] <lool> there's a new version in debian
[09:42] <seb128> slomo: any idea about http://launchpadlibrarian.net/17880819/buildlog_ubuntu-intrepid-i386.gstreamer0.10_0.10.20.2-1_FAILEDTOBUILD.txt.gz
[09:43] <seb128> lool: I'll have a look to this one ;-)
[09:43] <lool> I'd guess the -scan causes memory corruption
[09:43] <lool> You'd need to valgrind it
[09:44] <NCommander> lool, this is why C is evil, and Ada should replace it
[09:44]  * NCommander runs
[10:13] <Keybuk> seb128: more evo problems today
[10:13] <Keybuk> unread counts in the folder list don't match the folder
[10:13] <Keybuk> *sigh*
[10:13] <Keybuk> I don't suppose there's a configure option to disable the silly sqlite stuff?
[10:13] <seb128> counts are known to be broken and no
[10:13] <Keybuk> I guess there won't be a fix for this before intrepid, since they've released now?
[10:14] <slomo> seb128: that's scary :) since when does it happen?
[10:14] <Keybuk> had another case of "folder contents in evolution don't match server" this morning as well
[10:14] <Keybuk> evo was convinced there were mails in the folder that were unread, server convinced the folder was empty
[10:14] <slomo> seb128: and did it happen with 0.10.21 too? (please sync all gst packages and what's the decision about new codec installation stuff now? bgigest problem are the translations in gnome-codec-install imho)
[10:14] <seb128> slomo: since this sync of gstreamer, I didn't retry since though
[10:15] <seb128> slomo: codecs -> mvo should know better
[10:15]  * crevette points http://bugzilla.gnome.org/show_bug.cgi?id=543389 to Keybuk :)
[10:15] <seb128> slomo: all are stable updates?
[10:15] <ubottu> Gnome bug 543389 in Mailer "Camel Disk summary bugs" [Critical,New]
[10:15] <slomo> seb128: yes, gst0.10-python 0.10.13 and 0.10.21 of core and base
[10:15] <seb128> Keybuk: was that issue in a folder which was working before? is the folder an inbox?
[10:15] <Keybuk> crevette: open bugs that aren't fixed *sigh*
[10:15] <seb128> slomo: ok thanks
[10:15] <Keybuk> seb128: the folder works fine on my hardy box
[10:16] <Keybuk> it's a Maildir via imap
[10:16] <slomo> seb128: if the failure is still there i'll take a look :)
[10:16] <seb128> slomo: thanks
[10:16] <seb128> Keybuk: worded differently, did this folder was showed correctly under 2.24?
[10:16] <slomo> seb128: also, please sync ugly later when i upload it to experimental :) important bugfix... same for ffmpeg ;)
[10:16] <seb128> Keybuk: or is it possible to be a broken index staying there since you used 2.23.
[10:17] <seb128> slomo: ok
[10:17] <Keybuk> seb128: I've wiped my summary db several times
[10:17] <Keybuk> most recently only last week
[10:17] <Keybuk> I can wipe it again and see what happens
[10:17] <seb128> Keybuk: is the folder an inbox or a imap folder?
[10:17] <Keybuk> imap folder
[10:17] <seb128> and do you modify the box by some other means while evolution is running?
[10:18] <Keybuk> only via other imap clients
[10:18] <seb128> ok, I'm wondering if that would be the issue
[10:18] <Keybuk> and tbh, probably not even then - since this is on the laptop
[10:18] <seb128> I've a similar issue on an inbox
[10:18] <seb128> and I start suspecting the fact that I clean this one use fetchmail regularly and that evolution doesn't like the folder to change this way
[10:19] <seb128> Keybuk: do you get some error on the command line when selecting the folder?
[10:19] <Keybuk> err, dunno
[10:20] <Keybuk> I'm currently wiping the .evolution directory :p
[10:20] <seb128> look into the .xsession-errors?
[10:20] <Keybuk> (evolution:18556): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJ
[10:20] <Keybuk> ECT (object)' failed
[10:20] <Keybuk> maybe
[10:20] <Keybuk> (evolution:18556): camel-WARNING **: Camel operation status stack non empty:
[10:20] <Keybuk> maybe
[10:20] <Keybuk> (evolution:18556): camel-WARNING **: Error during searching SELECT uid FROM 'Lis
[10:20] <Keybuk> ts' WHERE (NOT ((junk = 1))): no such table: Lists
[10:20] <Keybuk> but wasn't that folder
[10:21] <Keybuk> sys:1: Warning: g_object_unref: assertion `G_IS_OBJECT (object)' failed
[10:21] <seb128> right
[10:21] <seb128> Keybuk: that's http://bugzilla.gnome.org/show_bug.cgi?id=550998
[10:21] <Keybuk> there's a veritable smorgasbord of scary looking errors here :p
[10:21] <ubottu> Gnome bug 550998 in Mailer "Evolution doesn't refresh the INBOX folder" [Normal,New]
[10:22] <seb128> or it looks similar
[10:36] <slomo> seb128: ok, ugly does not need to be synced, the patch was already there since 0.10.9-1 :)
[10:36] <seb128> slomo: there is probably some other interesting changes no?
[10:37] <seb128> slomo: syncing libgstreamer, base and python now
[10:37] <slomo> seb128: nothing critical was changed in ugly... and there will be new good/bad releases in 2 weeks with some really nice changes (early enough for intrepid?)
[10:39] <seb128> slomo: are those mainly bug fixes new version or disruptive ones? and will they roll pre-versions first?
[10:40] <slomo> seb128: there will be pre-releases this night... and they contain many bugfixes but also new features (and for example the fluendo mpeg demuxer and muxers are in gst-plugins-bad now)
[10:41] <seb128> slomo: new feature are not really an issue, what is an issue is disruptives changes to existant code which could lead to things not working correctly that users expect to be working ;-)
[10:42] <slomo> seb128: well, those kind of changes exist too unfortunately :) but then there's much testing (automated and manual) for regressions before the pre-releases become the real releases
[10:43] <seb128> ok, let's consider those when the pre-versions will be in debian
[10:48] <slomo> seb128: ok :)
[10:49] <seb128> the schedule is a bit tight for intrepid
=== nm-rocker is now known as asac
[11:09] <slomo> seb128: btw, if the gstreamer build failure is still there it would be great if someone with access to those machines could try to reproduce it and give me a backtrace :)
[11:32] <seb128> slomo: http://launchpadlibrarian.net/18252719/buildlog_ubuntu-intrepid-i386.gstreamer0.10_0.10.21-1_FAILEDTOBUILD.txt.gz
=== davmor2 is now known as davmor2_away
=== davmor2_away is now known as davmor2
[12:56] <didrocks> hi seb128 !
[12:56] <seb128> hey didrocks
[12:58] <didrocks> swfdec 0.8 is still in debian NEW, preventing from upgrading gnome-swfdec. Can we take it and reshape it for intrepid? (as this is a new package entitled swfdec0.8, the risk seems to be minor).
[12:58] <seb128> didrocks: do they have a vcs? in which case just take the packaging and do a fake sync upload
[12:59] <didrocks> hum, searching for it
[13:07] <didrocks> hum, nothing show that they are packaging it in a VCS :/
[13:09] <seb128> didrocks: do the update then
[13:09] <seb128> didrocks: http://ftp-master.debian.org/new/swfdec0.8_0.8.0-1.html has a summary
[13:09] <seb128> use the same naming, etc
[13:10] <didrocks> ok, will try this out tonight ^^ (apparently, no special changes in the changelog)
[13:11] <didrocks> (btw, the naming is horrible, but there must be some reasons I do not understand, probably ^^)
[13:11] <seb128> what naming?
[13:12] <didrocks> for binaries packages: swfdec0.8_0.8.0-x...
[13:12] <seb128> well, that's source_version
[13:12] <didrocks> as the version number is used in the package name, it is repeated two times
[13:12] <seb128> they version the source name because upstream does it
[13:12] <seb128> and that allow to install a stable and an unstable version
[13:13] <seb128> not very useful for a distro but that's an upstream choice
[13:13] <didrocks> oh, that's the reason why the version is included in the package name? Ok, thanks for the info :)
[13:14] <didrocks> (having unstable and stable installation, with different package names)
[13:14] <seb128> right ;-)
[13:14] <seb128> ok, restarting to try changes and having lunch, be back later
[14:22] <asac> seb128: when will we get the glib fix for http://launchpadlibrarian.net/18258143/buildlog_ubuntu-intrepid-ia64.network-manager_0.7~~svn20081004t225044-0ubuntu1_FAILEDTOBUILD.txt.gz ?
[14:22] <asac> seb128: (we talked about that a while ago if you remember ... thought it was fix committed upstream)
[14:23] <seb128> asac: it has been commited upstream but they don't roll glib tarballs every week, we can backport the change if you think that's important, I was under the impression than nobody uses intrepid and network-manager on those archs though
[14:25] <asac> seb128: i think powerpc would qualify as a valid "NM" candidate
[14:25] <asac> seb128: i can also workaround in NM
[14:26] <seb128> would be better if you can do that for now, glib is on sync with debian and I don't fancy introducing ubuntu specific diff only to fix a porter arch issue if not required
[14:27] <seb128> asac: they will roll a new tarball for GNOME 2.24.1 before intrepid and you can drop the workaround then
[14:28] <asac> seb128: ok
[14:28] <asac> thats fine
[14:28] <seb128> asac: thanks
[14:33] <seb128> Ampelbein, didrocks, huats: anybody wanting to write the MIR required for gimp 2.6 or work on the f-spot 0.5 update?
[14:37] <didrocks> seb128: I can handle it :)
[14:37] <seb128> didrocks: which one? ;-)
[14:37] <didrocks> let's say gimp it will be my first, so, looking for some doc
[14:38] <seb128> didrocks: ok, gegl and babl need a mir then, that's documented on the wiki let me know if you want the wikipage
[15:03] <didrocks> seb128: sorry, I was on the phone. Yes, if you have directly the wiki page (MIR search give back a lot of results)
[15:06] <seb128> didrocks: https://wiki.ubuntu.com/MainInclusionProcess
[15:07] <didrocks> seb128: thanks a lot :)
[15:07] <seb128> you're welcome ;-)
=== crd1b is now known as crdlb
[16:39] <didrocks> seb128: first MIR done (https://wiki.ubuntu.com/MainInclusiongegl). I will open the bug tomorrow, when the second one will be done.
[16:39] <seb128> didrocks: ok thanks
[18:21] <dobey> seb128: it looks like ubiquity is broken, and the change cjw mentions only exposes the problem in the ubiquity tarball :)
[18:21] <seb128> dobey: could you join #ubuntu-devel and tell that to cjwatson directly? thanks
[18:22] <seb128> or reply on the bug
[18:22] <seb128> thanks for looking to the issue ;-)
[18:22] <dobey> i commented on the bug and marked it fixed, as i added an error check
[18:28] <seb128> dobey: ok, thank you
[18:29] <dobey> no problem
[19:21] <didrocks> seb128: swfdec is now done (https://bugs.edge.launchpad.net/ubuntu/+source/swfdec0.6/+bug/279207), I made it a dependency of swfdec-gnome, merging the changes. I will try to do the swfdec-gnome package tomorrow. Jumping into some social life :)
[19:21] <ubottu> Launchpad bug 279207 in swfdec-gnome "Please sponsor swfdec-gnome 2.24.0 and swfdec 0.8 to intrepid" [Undecided,In progress]
=== MenZa_ is now known as MenZa
=== MenZa_ is now known as MenZa
=== Ng_ is now known as Ng