=== asac_ is now known as asac
[09:25] <geser> does somebody know why building a package with "configure --enable-scrollkeeper" works on Debian while on Ubuntu one needs the pass --disable-scrollkeeper to configure?
[09:27] <seb128> ubuntu is using rarian and debian not?
[09:28] <geser> doesn't build-depending on scrollkeeper install scrollkeeper anymore?
[09:29] <seb128> geser: rarian-compat is similar so any of those can be used
[09:29] <seb128> lut huats
[09:29] <huats> hello seb128
[09:30] <seb128> geser: anyway why would you want to enable this configuration option when it's obviously not what you want? those updates should be done during the installation on the client box and not on the buildd
[09:32] <geser> seb128: I was looking at a FTBFS (gossip) where the error was due to a missing --disable-scrollkeeper and I saw in debian/rules that it called configure with --enable-scrollkeeper
[09:33] <geser> and looking at Debian build logs it builds there successfully
[09:35] <seb128> could be a buildd configuration difference too
[09:35] <seb128> doesn't really matter though, this option should not be used for debian builds since you don't want to index whatever is installed on the buildds
[09:37] <geser> so I should forward the Ubuntu delta to Debian?
[09:37] <geser> lool: ^^ what's your opinion on it as you are a co-maintainer of gossip?
[09:43] <lool> geser: No idea why --enable-scrollkeeper was added
[09:43] <lool> It's not documented why in the changelog
[09:44] <lool> geser: rarian-compat provides scrollkeeper; does it fail to build under Ubuntu with rarian-compat or scrollkeeper?
[09:44] <lool> or both?
[09:47] <geser> lool: I don't have the build log anymore but it failed because it couldn't write in /var/lib/scrollkeeper (or similar) during the build
[09:47] <lool> geser: Perpaps rarian-compat should be fixed?
[09:49] <geser> I'll try later (when I'm back at home) and check if it failed with scrollkeeper or rarian-compat
[09:59] <mvo> seb128: hey! what is the plan for gdm for jaunty (have we one ;) ? I ask because it would be nice if we would use hal to shutdown - then e.g. synaptic could inhibit a shutdown while its working
[10:01] <seb128> mvo: I would say it's time to switch to the new gdm now
[10:03] <mvo> will it use hal for shutdown?
[10:05] <seb128> mvo: it does
[10:08] <mvo> excellent
[10:39]  * mvo recently discovered the compiz now plugin and thinks its awsome
[10:39] <mvo> "snow"
[10:39]  * mvo can't type
=== hggdh|away is now known as hggdh
[13:29] <hggdh> seb128, good morning (for me) afternoon (for you)
[13:29] <seb128> hggdh: hello
[13:30] <hggdh> seb128, re. bug 205999 -- latest fix has some issues on backporting to Hardy
[13:30] <ubottu> Launchpad bug 205999 in evolution-data-server "Attachments names using "ç" are not correctly sent by Evolution (ATT<number>.dat)" [Medium,In progress] https://launchpad.net/bugs/205999
[13:30] <seb128> hggdh: I read your comments, why are glade changes required to fix an encoding issue?
[13:31] <hggdh> seb128, a new configuration option was added (so that the default behaviour will still be rfc2231-compliant)
[13:32] <seb128> we likely don't want changes which add UI changes and new strings to stable
[13:32] <hggdh> I did a make against trunk, and it works fine; I also built against Intrepid, and published it -- but I am really not sure about Hardy
[13:32] <hggdh> exactly
[13:33] <seb128> I would say to not bother doing an hardy backport for now, let's try to get that fixed in intrepid or jaunty first and we will see later if we want to backport the change
[13:33] <hggdh> on the other hand, the previous patch will work on Hardy (in a different way, and it will create wrong attachment filenames -- but they will be usable
[13:34] <hggdh> I agree, but I wanted your input on this (after all, experience counts!)
[13:35] <seb128> ideally microsoft would respect the standards
[13:35] <seb128> anyway we didn't get so many lts users requests for that and I'm not sure adding complex changes or half working changes is worth the trouble
[13:35] <seb128> let's get that tested in intrepid or jaunty
[13:35] <hggdh> I found a page on support.microsoft.com that states Outcrap 2007 will read rfc2231, but will not generate them
[13:36] <hggdh> seb128, k
[13:36] <seb128> thanks for your work on those
[13:36] <seb128> did you get any feedback on the other bugs about the sqlite migration on upgrade?
[13:37] <hggdh> welcome. I am now waiting for field feedback on the Intrepid fix, but I will check upstream if they are going to commit the fix in time for us to use it now
[13:37] <hggdh> on the migration, the reporter commented upstream that it did not quite work. srag asked for the coder to look at it ASAP
[13:38] <seb128> ok
[13:38] <hggdh> (Sankar)
[13:38] <hggdh> seb128, glad to be able to help out a bit
[13:39] <hggdh> seb128, backporting to Hardy will not be a trivial change -- the glade interface was rewritten for 2.24
[13:40] <seb128> I doubt we will be wanting to backport UI changes anyway
[13:40]  * hggdh agrees
=== mpt_ is now known as mpt
[16:09] <mvo> seb128: I looked at the eog bug you mentioned, this particular one seems to be a packages in really bad shape and update-manager seems to be unable to fix that
[16:09] <seb128> mvo: it has been duplicated since no? I think that was another case where the user sent duplicates over random packages due to an install issue
[16:11]  * mvo nods
[16:44] <pitti> seb128: <flamewar gauntlet>so, my gthumb patch for fixing photo import was accepted within 24 hours, while it took weeks for f-spot (and still arguing about the remaining bit); I love gthumb! :-)
[16:44]  * pitti hugs seb128
[16:45] <seb128> pitti: trolll!!!!
[16:45]  * seb128 hugs pitti
[16:45] <pitti> (no worries, I'm just happy that it's upstream now)
=== njpatel is now known as njpatel_away
[18:53] <mpt> Discussion in irc.gnome.org #usability about rearranging the Sound preferences, if anyone is interested
[18:53] <mpt> http://www.gnome.org/~mccann/gnome-volume-control/Screenshot-Sound%20Preferences-1.png
[18:58] <dobey> again?
[18:58] <dobey> whee
=== fta_ is now known as fta