[02:10] <cody-somerville> Hi bfiller :)
[02:10] <bfiller> cody-somerville: hey there
[02:10] <bfiller> cody-somerville: what's going on?
[02:11] <cody-somerville> Trying to diagnose a bug in gnome-power-manager at the moment. Yourself?
[09:33] <crevette> hello seb128
[09:33] <seb128> lut crevette
[09:39] <didrocks> plop seb128 & crevette
[09:39] <crevette> salut dobey
[09:39] <crevette> salut didrocks
[09:40] <crevette> salut *
[09:40] <didrocks> seb128: swfdec0.8 and gnome-swfdec ready to go (bug #279207) :)
[09:40] <ubottu> Launchpad bug 279207 in swfdec-gnome "Please sponsor swfdec-gnome 2.24.0 and swfdec 0.8 to intrepid" [Undecided,In progress] https://launchpad.net/bugs/279207
[09:40] <seb128> lut didrocks
[09:40] <seb128> didrocks: I noticed, will have a look later
=== davmor2 is now known as davmor2_away
[10:34] <seb128> slomo: hum, gstreamer still doesn't build, is it really required to build the html documentation at build time? it's not shipped in the upstream tarball?
[10:35] <slomo> seb128: please sync the next versions from experimental, i.e. 0.10.21-2 of core and base :) there was a bug that required gtk-doc to be installed in any case
[10:35] <slomo> seb128: for the other build failure... could you get me backtraces from one of the machines where it fails? :)
[10:36] <seb128> slomo: I tried locally and no luck, will try to ping some buildd admin about that
[10:37] <slomo> seb128: it might be that the file system has problems with mmap'd files, iirc the registry is loaded via mmap() if possible... but then this should've happened in older versions too
[10:40] <seb128> didrocks: how are the gimp mir writting going?
[10:40] <seb128> slomo: let's see how the new version build or not
[10:41] <slomo> seb128: well, the docs build failure should be gone... everything else is unchanged :)
[10:41] <slomo> mvo: ping? :)
[10:41] <seb128> slomo: I think all those failed on the doc builds
[10:42] <slomo> seb128: all that called just binary-arch failed while installing the html docs, the binary-indep/binary-arch build failed with a segfault or something while loading the registry for generating docs
[10:42] <mvo> slomo: pong
[10:42] <slomo> mvo: seb128 said that you know what the plan with the codec installation stuff is... :)
[10:43] <seb128> slomo: right, which brings back to "why do you need to generate those a buildtime"?
[10:43] <seb128> slomo: the GNOME packages usually have the html in the tarball, building those again is just increasing the build-depends, build time and trouble
[10:43] <mvo> slomo: heh :) the plan keep what we have for intrepid and decide in intrepid+1 :)
[10:43] <seb128> mvo: we are in the middle of a transition for intrepid no?
[10:44] <mvo> seb128: yes, but I added code to make the new stuff appear in the old stuff. so we should be fine
[10:44] <slomo> mvo: so you're changing all gstreamer packages that seb128 synced back to the old behaviour? ;)
[10:44] <slomo> seb128: good question
[10:44] <mvo> slomo: no, I just added code in the codec extraction script that checks the Packages files in addtion to the package themselfs
[10:45] <didrocks> seb128: currently doing the second one
[10:45] <seb128> didrocks: thanks ;-)
[10:45] <mvo> slomo: so we don't need to modify the current codec installer. its less flexible
[10:45] <didrocks> seb128: I have a job too, you know ;)
[10:45] <didrocks> well huats do not call it a job ^^
[10:45] <didrocks> s/do/does
[10:45] <seb128> didrocks: right, but you worked on swfdec so I though you maybe had finished those
[10:45] <mvo> slomo: but meant that we had only minimal code changes after feature freeze
[10:46] <didrocks> seb128: no, swfdec was "for the pleasure" :)
[10:46] <seb128> ok ;-)
[10:46] <didrocks> seb128: I will finish the second one in the hour
[10:46] <mvo> slomo: will you come to UDS? I think it will be a topic there then
[10:46] <slomo> mvo: oh, ok :) then you just have to make sure that _no_ package containing gstreamer codecs is build with the new dh_gstscancodecs but doesn't have the new control fields
[10:46] <slomo> mvo: nope :) but if there's something to discuss i'll try to attend from here
[10:47]  * didrocks still waiting for UDS sponsorshing answers :)
[10:47] <mvo> slomo: thanks, that is good to know. sounds like I should double check that as well
=== nm-rocker is now known as asac_
[10:47] <mvo> nm-rocker?!?
[10:48] <slomo> mvo: i think the codec installation stuff as it's in debian now is more or less perfect... only the installation application needs some tweaking, some parts are still a bit hacky, there's no use documentation and we need more translations than just french and german :)
[10:49] <mvo> slomo: cool, good to know
[10:50] <mvo> hm, the only package that not got synced seems to be "plugins-farsight" from aug 05
[10:50] <slomo> mvo: for example the searching for the required packages currently is done from the main thread with polling the main loop every n packages ;) i was too lazy to find out how threads in python work
[10:51] <slomo> seb128: did you sync gst-ffmpeg already?
[10:51] <seb128> slomo: oh no forgot about this one
[10:51] <seb128> slomo: it has ubuntu changes though, can't be synced
[10:52] <seb128> "     - debian/rules: enable the encoders" should be easy ;-)
[10:52] <seb128> ups
[10:52] <seb128> gst-ffmpeg is the old version
[10:52] <mvo> just to clarify (and so that I can double check if the adapter code is ok) - what packages are going to be synced?
[10:55] <seb128> slomo: gstreamer0.10-ffmpeg experimental 0.10.5-1 is the one to sync right?
[10:55] <slomo> seb128: yes
[10:56] <seb128> slomo: synced
=== asac_ is now known as asac
[11:18] <seb128_> slomo: ok so it built everywhere but on i386 now
[11:18] <seb128_> slomo: I'm tempted to just disable the documentation build
[11:34] <seb128> slomo: I get the build failure locally but I'm not sure how to debug it
[11:41] <didrocks> seb128: the two MIR are ready (bug #279563 and bug #279565)
[11:41] <ubottu> Launchpad bug 279563 in gegl "Main Inclusion Request: gegl" [Undecided,New] https://launchpad.net/bugs/279563
[11:41] <ubottu> Launchpad bug 279565 in babl "Main Inclusion Request: babl" [Undecided,New] https://launchpad.net/bugs/279565
[11:42] <seb128> pitti: can you have a look to those today? they are gimp 2.6 build requirements
[11:42] <seb128> can -> could
[11:47] <didrocks> seb128: is there someone handling fspot update?
[11:47] <slomo> seb128: which one?
[11:48] <slomo> seb128: GST_REGISTRY_FORK="no" $command
[11:48] <slomo> and that in gdb
[11:50] <pitti> seb128: would like to finish my current debugging session, after lunch is ok?
=== asac_ is now known as asac
[11:58] <seb128> pitti: sure no hurry
[11:59] <seb128> slomo: sorry I was having lunch
[11:59] <seb128> slomo: gtk-doc: Running scanner gstreamer-scan
[11:59] <seb128> Could not initialize GStreamer
[12:00] <seb128> slomo: but I don't know what command to run, running ./gstreamer-scan does lead to an error
[12:08] <didrocks> seb128: maybe you didn't read it :) I was asking you if anybody is handling fspot update :)
[12:08] <seb128> didrocks: no I didn't, nobody replied no
[12:09] <didrocks> ok, so, let's try it (this evening too) :)
[12:10] <seb128> didrocks: bug #271895, it looks like somebody started working on it
[12:10] <ubottu> Launchpad bug 271895 in f-spot "update f-spot to 0.5" [Wishlist,New] https://launchpad.net/bugs/271895
[12:11] <didrocks> seb128: ok, great :)
[12:11] <didrocks> will find another thing to do ^^
[12:16] <slomo> seb128: hmm, it's more or less gst-inspect-0.10 that is called there...
[12:16] <seb128> slomo: I don't know what argument to give it
[12:16] <seb128> stracing ellipsize the arguments lists
=== davmor2_away is now known as davmor2
[12:32] <slomo> seb128: it's not exactly easy... you have to tell gsteamer where the plugins are, you have to set LD_LIBRARY_PATH, etc... hrm, i'll tell you what to do later, ok?
[12:32] <seb128> slomo: ok thanks
[12:33] <seb128> what I don't get is that make works but debuild doesn't
[12:47] <mvo> seb128: -v -s 1024 should give you full srace output
[12:47] <seb128> mvo: ah right, thanks
=== pedro__ is now known as pedro_
[13:18] <lool> mvo: Over the WE, I wanted to change gdebi to use some helper process instead of relying on a vte patch in response to some Debian RC bug; but some Debian guy actually wrote exactly that over the WE; do you think we can merge this solution in the upstream gdebi tree?
[13:18] <lool> or is there still an advantage in the vte solution?
=== philwyett_ is now known as philwyett
[13:25] <mvo> lool: let me have a look at the patch
[13:27] <mvo> lool: in what bug is the patch ? I had a look at the debian page and the two "patch-available" bugs are both translation updates
[13:28] <mvo> lool: that reminds me that gdebi should probably move into pkg-gnome or something (because strato is no longer active with it and I lack time to properly maintain it in debian)
[13:29] <lool> mvo: search for nmu diff
[13:30] <lool> mvo http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493353
[13:30] <ubottu> Debian bug 493353 in gdebi "[gdebi] can't install packages" [Grave,Closed]
[13:30] <lool> diff is inline in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493353#39
[13:31] <lool> mvo: yeah stratus got pulled in the black hole
[13:32] <lool> mvo: it's ok to host it in pkg-gnome, but it would still need someone to actively care for it in Debian   :-/
[13:32] <lool> update-manager and notifier are comparable and suffer from lack of love as well
[13:35] <mvo> lool: geh, that is really a hack :/ and just because my python-vte patch is not accepted? oh well
[13:39] <seb128> mvo: vte is a pkg-gnome package so using the patch in debian should be no issue
[13:43] <mvo> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501133 has the patch
[13:43] <ubottu> Debian bug 501133 in vte "please add patch to allow keeping fds open" [Important,Closed]
[13:44] <test> im having parachat issues
[13:44] <test> lol
[13:44] <test> can anyone help me
[13:44] <mvo> iirc the keep fd stuff is important for progress reporting inside gdebi as well (install progress reporting)
[13:45] <didrocks> lool: yeah, libbabl-0.0-0dev is a really awful name :)
[13:45] <mvo> seb128: the patch for the keep-fd for vte got submited but is not applied (tv submited it)
[13:46]  * mvo feels a bit gulity but he just does not have time to maintain all the packages in both debian and ubuntu
[13:46] <seb128> mvo: but it could be applied if lool wanted to do it for example
[13:46] <mvo> seb128: right, that would be good IMO - I think the progress reporting in gdebi is broken without it too (would have to double check though)
=== reynaldo_ is now known as reynaldo
[13:50] <mvo> seb128: my i965 system is currently upgrading, I will let you know about compiz when its done
[13:51] <seb128> mvo: ok thanks
[13:56] <lool> mvo: Well I kind of agree with the fact the gdebi shouldn't rely on special vte features, especially if not merged upstream, and having an intermediate binary to relay the data makes complete sense to me
[13:56] <lool> mvo: But we could work on the implementation
[13:57] <lool> seb128: IIRC, I considered the patch a long while ago, and was convinced not to take it because upstream didn't want it
[14:21] <mvo> asac: network manager is telling me (during a release upgrade) that it can not find some of its resources and that it can not continue. is that a known issue?
[14:22] <mvo> asac: (hardy -> intrepid)
[14:24] <asac> mvo: yes. thats a known issue. wait a second please
[14:25] <asac> mvo: (to test ;))
[14:26] <asac> mvo: thats a dialog that repeatetly pops up right?
[14:26] <asac> mvo: if so please dont change anything ;)
[14:26] <asac> mvo: its #277084
[14:27] <asac> mvo: please try:
[14:27] <asac> <asac> ln -s /usr/share/icons/hicolor/22x22/apps/nm-vpn-active-lock.png
[14:27] <asac> /usr/share/icons/hicolor/22x22/apps/nm-vpn-lock.png
[14:27] <asac> and the same for nm-device-wired-autoip  icon
[14:27] <asac> (just link it somewhere else)
[14:28] <tjaalton> there's a 2GB file limit on gvfs-sftp?
[14:28] <seb128> tjaalton: not that I know but I didn't try to copy one of those either
[14:29] <seb128> brb, downgrading intel video driver
[14:31] <mvo> asac: it seems to have just come up once, I clicked on it and now its gone
[14:32] <mvo> asac: but a icon problem sounds plausible, the icon for it looks broken now
[14:50] <mvo> seb128: compiz&vidoe playing is fine here (i965) - strnage
[14:50] <seb128> bah
[14:51] <asac> mvo: yes. just wondered if you could create those links and see if the problem goes away
[14:51] <asac> i would then ship them in the applet to not cause this transition issue
[14:51] <seb128> mvo: gst-launch displays those on my installation
[14:51] <seb128> X Error of failed request:  BadAlloc (insufficient resources for operation)
[14:51] <seb128>   Major opcode of failed request:  140 (XVideo)
[14:51] <seb128>   Minor opcode of failed request:  19 ()
[14:52] <mvo> asac: is that the pending fix? if so, I can do it in a test VM (the upgrade on real HW is always a bit more work to setup with partimage etc)
[14:53] <asac> mvo: would be nice if you could verify that those are all resources missing before i implement the fix
[14:53] <asac> mvo: i am scared that it also wants to load "glade" resources :(
[14:54] <asac> mvo: if you want a prepared fix to test, I would have to do that first :)
[14:54] <mvo> asac: adding the symlinks should be fine, give me some minutes, I add it
[14:54] <asac> let me know. i would jump on that train now then
[14:54] <asac> ok cool
[14:55] <mvo> I can't see a train here?
[14:55] <asac> heeh
[14:55] <mvo> sorry, that was lame :)
[15:03] <mvo> asac: I'm running the test now (will take a bit)
[15:46] <asac> mvo: go go go ;)
[15:50] <mvo> asac: its still going strong!
[15:51] <asac> mvo: rock ;) ... so which links did you setup? just the two above?
[15:51] <mvo> asac: just the two above (before statring the install)
[15:51] <asac> mvo: before?
[15:51] <asac> shouldnt those icons be there before the upgrade?
[15:52] <asac> oh ... ok i think i know what you meann
[15:52] <asac> :)
[15:52] <asac> i will most likely not create link to not need to do any preinst stuff, but ship the icons duped instead
[15:52] <mvo> asac: sure, that is fine
[15:53] <asac> mvo: or is replacing files with links to files save? (vs. replacing links to directories)?
[15:54] <mvo> asac: I don't get the last sentence, but I think just duping the files (few and small) is a good appraoch
[15:55] <asac> mvo: i meant if its save to replace files with links to files during upgrade ;)
[15:55] <mvo> asac: should be yes, dpkg is pretty smart about this
[15:55] <asac> anyway, better safe than sorry ... i will dupe
[16:52] <glatzor> hello mvo
[16:53] <mvo> hey glatzor!
[16:53] <glatzor> mvo, I would like to introduce an alternative for gnome-codec-install
[16:53] <glatzor> mvo, would a corresponding patch be still accepted?
[16:53] <glatzor> This would help me to avoid dpkg-divert in packagekit
[16:54] <glatzor> mvo, do you know any details about your Ubucon partipation?
[16:54] <glatzor> mvo, I will be there from friday evening to Sunday evening.
[16:54] <mvo> still not, sorry
[16:55] <mvo> glatzor: slomo reworked it for debian, its now part of the packages file (the information)
[16:55] <mvo> glatzor: depends on the patch :)
[16:55] <mvo> a dpkg-divert would certainly not be ideal
[16:58] <glatzor> mvo, It should only be 10 lines of death :)
[16:59] <mvo> glatzor: it sounds pretty dangerous at this point of release, is it worth it?
[17:00] <glatzor> mvo, not really
[17:00] <glatzor> :)
[17:01] <mvo> glatzor: I have a look if its small and not dangerous, promised :)
[17:26] <slomo> glatzor: gnome-codec-install is nowadays (in debian) just an application that provides the gstreamer-codec-install alternative
[17:36] <seb128> slomo: I'll disable the html api build in ubuntu for now as a workaround
=== Ng_ is now known as Ng
[18:12] <slomo> seb128: ok :)
[18:14] <seb128> slomo: still let me know if you have ideas on how to debug details later or if you want to disable the api build in debian, I would prefer to keep the packages in sync ;-)
[18:15] <slomo> seb128: i'll give you details tomorrow... best would be if you could tell me how to reproduce it ;)
[18:15] <seb128> slomo: try building gstreamer0.10 on an intrepid
[18:17] <slomo> seb128: ok, will do... you said "make" works while debuild doesn't, right?
[18:18] <seb128> slomo: right, it's weird, I tried to figure why, I'm wondering if that's not a out of srcdir build against srcdir build issue
[18:18] <seb128> slomo: I just use debuild, it breaks
[18:19] <seb128> then I can debuild binary how many times I want it still breaks
[18:19] <seb128> but make works
[18:19] <seb128> make after the failed debuild
[18:19] <seb128> ie, same configure options, etc
[18:20] <slomo> weird
[18:20] <slomo> maybe the env variables set by debuild?
[18:20] <seb128> could be, I'm not sure what it sets though
[18:44] <mvo> seb128: do you have a opinion on https://bugs.edge.launchpad.net/ubuntu/+source/rarian/+bug/256131 ?
[18:44] <ubottu> Launchpad bug 256131 in rarian "failed to upgrade : "update-xmlcatalog: error: entity already registered"" [High,Triaged]
[18:45] <mvo> I was not able to reproduce this myself yet, have you seen it somewhere?
[18:47] <davmor2> mvo: is this a straight upgrade from hardy?
[18:57] <mvo> davmor2: I think so, but I haven't alnalyzed in deep yet
[18:59] <davmor2> mvo: If you want I can try an upgrade tomorrow morning and if I get the error let you know if you want
[19:00] <mvo> davmor2: I suspect only a small subset of people see it, I don't get it here in my vm upgrade test for example
[19:00] <davmor2> mvo: I'm testing on hw with nvidia card in
[19:11] <ember> mvo i get it from etch to unstable in Debian
=== fta_ is now known as fta
[20:07] <mvo> ember: hm, thanks. I hope I can find out more aobut it
[22:09]  * walters wonders why the forums require a login just to view an attachment