=== cody-somerville_ is now known as cody-somerville
[08:25] <seb128> are the canonical servers not responding or that's a local issue there?
[09:04] <blueprotein> hello everyone
[09:05] <blueprotein> anyone hear me?
[09:05] <seb128> no, that's IRC, it doesn't has sound
[09:05] <seb128> you can be read though
[09:06] <seb128> or rather what you type can be read there
[09:07] <blueprotein> it's the first time to use this
[09:10] <seb128> usually if you have a question you just ask it, because people tend to be busy and will not randomly chat otherwise
[09:47] <pitti> seb128: argh, that ekiga 3.00 package is a mess
[09:49] <pitti> took me 15 minutes to even get the source, it's weird (plus, he broke all the library packages)
[09:56] <mvo> seb128: when you have a moment, I would like to talk about bug #276878 with you
[09:56] <ubottu> Launchpad bug 276878 in rarian "better package relations for the upgrade" [Medium,Triaged] https://launchpad.net/bugs/276878
[09:56] <seb128> pitti: right, ekiga is no fun, where did you get the package? do you do the update or did some contributor worked on it?
[09:57] <seb128> mvo: I don't have access to launchpad today, can you give details on the channel?
[09:57] <mvo> seb128: sure, basicly that apt-get dist-upgrade will not replace scrollkeeper with rarian-compat
[09:57] <mvo> seb128: neither does smart or aptitutde
[09:57] <pitti> seb128: from the PPA in bug 274085
[09:57] <lool> Wow, it took 15 mns for
[09:57] <ubottu> Launchpad bug 274085 in ekiga "Please update Ekiga to 3.00" [Wishlist,Triaged] https://launchpad.net/bugs/274085
[09:57] <lool> Ups
[09:58] <pitti> seb128: just did a bug followup, the packaging is totally broken; we might actually be better off doing the upgrade ourselves than trying to fix that one, but I'll play with it some more
[09:58] <seb128> lool: are those the ekiga packages you looked at before?
[09:58] <seb128> pitti: ok
[09:58] <seb128> mvo: why not?
[09:58] <seb128> mvo: and it that an issue?
[09:58] <lool> We should make sure we DON'T use the upstream debian packaging for ekiga but ours
[09:59] <seb128> lool: do you know if somebody is working on those updates for debian?
[09:59] <lool> The packages I tried were from snapshots.ekiga.net
[09:59] <seb128> mvo: would changing a bunch of packages to depends explicitly on rarian-compat rather than scrollkeeper fix the issue?
[09:59] <lool> seb128: I think Eugen-revolutionary-calendar-can't-recall-his-name started
[09:59] <mvo> seb128: everything still depeneds on scrollkeeper so all the tools think its better to keep that. we have various option, is there a reason to keep scrollkeeper at all?
[10:00] <lool> seb128: He got to the "branching ekiga to experimental" point
[10:00] <lool> Then disappeared forever after
[10:00] <seb128> lool: ok, not reliable to get something before intepid
[10:00] <mvo> seb128: yeah, that would probably help or a pseudo package "documentation-thing" or something. for now I'm curious if there are specific reason that its done the way its done (i.e. if rarian-compat lacks features for example)
[10:01] <lool> seb128: Not reliable no
[10:01] <seb128> mvo: not really, out of "scrollkeeper is around for a while and known to be working, rarian-compat is new and not sure it does everything scrollkeeper is doing"
[10:01] <mvo> ok
[10:02] <mvo> thanks, I check the options we have and try to come up with a plan
[10:04] <pitti> seb128: ah, so it really doesn't work with our libpt and libopal
[10:10] <lool> mvo: We spent some time making sure the deps are unversionned, and rarian-compat provides scrollkeeper; I know some Debian people have it instaleld as a replacment
[10:11] <lool> the motivation to switch to rarian-compat would be a) speed b) some upstream maintenance
[10:11] <mvo> lool: the thing is that if scrollkeeper and rarian-compat have the same deps and scrollkeeper is the one installed (and rarian conflicts) than apt will prefer scrollkeeper
[10:12] <lool> mvo: Perhaps we should have some default-mail-transport-agent-alike real package depending on one or the other instead of this hack though
[10:12] <mvo> yeah, that was my thinking
[10:12] <lool> I don't like provides
[10:12] <mvo> they are messy to use currently :/
[10:12] <lool> If we ever need a versionned dep we're in trouble
[10:13] <lool> We dropped all versionned deps because thankfully they were mostly satisfied in modern distros
[10:13] <lool> And simply because scrollkeeper didn't change much
=== njpatel is now known as njpatel_away
=== njpatel_away is now known as njpatel
[12:10] <pitti> seb128: ah, I debugged the fclose() segfault in consolekit, fixed package uploaded (it's not fixed in 0.3 either, reported upstream)
=== pedro__ is now known as pedro_
[13:14] <seb128> pitti: ah excellent, just curious how did you managed to debug it? did you find a way to trigger the bug?
[13:14] <pitti> seb128: no, the crash doesn't happen for me
[13:14] <pitti> seb128: I just stared at the backtrace and the code
[13:14]  * pitti currently cleans up the consolekit crasher bugs
[13:14] <pitti> in the end we just have three relevant ones
[13:15] <seb128> we really lack a freedesktop stack active maintainer for ubuntu
[13:15] <pitti> one is the double fclose() from above, one is the vt_thread_start() which is most likely fixed with the 0.3 patch backport in intrepid, and another one which I'm currently looking at (some vprint())
[13:15] <seb128> thanks for taking some time to look at those ;-)
[13:16] <pitti> no problem
[13:22] <pitti> https://edge.launchpad.net/ubuntu/+source/consolekit/+bugs there, that looks much friendlier now
=== njpatel is now known as njpatel_lunch
=== davmor2 is now known as davmor_biab
=== njpatel_lunch is now known as njpatel
=== davmor_biab is now known as davmor2
=== asac_ is now known as asac
=== njpatel is now known as njpatel_away
[17:28] <huats> seb128_: just question: is it 'normal' that we are a bit late in the glom packaging ,
[17:28] <huats> ?
[17:28] <seb128_> yes, too many things to package and not enough people working on those
[17:28] <huats> I mean is is willingly or not / or because nobody did it ?
[17:29] <huats> ok
[17:29] <huats> I might give it a shot thus///
[17:29] <huats> ...
[17:29] <seb128_> good
[17:29] <seb128_> that will probably makes upstream happy
[17:29] <huats> :)
[17:30] <huats> I'll become the guy who makes  murrayc happy (glom + gnome-lirc-properties)
[17:30] <huats> :)
[17:31] <seb128_> huats: yeah ;-)
[17:54] <pedro_> tedg: are you tracking bug 252795 ?
[17:54] <ubottu> Launchpad bug 252795 in fedora "pressing the "Power" button shows a logout dialog" [Unknown,In progress] https://launchpad.net/bugs/252795
[17:56] <tedg> pedro_: Watching yes, I was hoping since Richard got assigned it for Fedora we'd see a fix. :)
[17:57] <tedg> Though, it's getting later and later...
[17:59] <pedro_> tedg: yes it seems that nothing is going on there
[17:59] <pedro_> tedg: there's a patch at the upstream bug though
[18:04] <tedg> pedro_: From that last comment, I'd say that this is a gnome-session bug.  When someone uses a parameter called "shutdown" as "TRUE" it seems that the machine should shutdown, not log out.
[18:06] <pedro_> tedg: ok, may you comment on the report then? would be nice to have it fixed before the final release
[18:06] <tedg> Of course, now looking at the gnome client header file it says: "Setting shutdown to TRUE will initiate a logout"
[18:06] <pedro_> great, thanks you :-)
[18:08] <tedg> seb128_: What's the chance of use rolling back gnome-session?  We're stuck with the new one now, right?
[18:11] <seb128_> tedg: we didn't discuss this option, but that would patch gnome-panel and the other new api client backward
[18:11] <seb128_> to be back in the same situation next cycle
[18:11] <seb128_> I would rather like to move toward fixing than workarounding this way
[18:12] <tedg> Yeah, I wasn't suggesting that as much wondering if it was worth porting GPM to the new API.
[18:13] <seb128_> ok
[18:13] <seb128_> I've to run, bbl
=== asac_ is now known as asac-the-nm-rock
=== asac-the-nm-rock is now known as nm-rocker
=== nm-rocker is now known as asac
=== fta_ is now known as fta
[23:35] <espacious> are there some problems with 8.10 beta?
[23:35] <espacious> md5 is ok but after burning cd check outputs an error
[23:36] <espacious> checked the cd and also tryed to burn on another machine
=== Ng_ is now known as Ng