[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#559522: marked as done (transition: evolution-data-server 2.28)

Your message dated Mon, 07 Dec 2009 23:15:55 +0100
with message-id <4B1D7E9B.5040907@debian.org>
and subject line Re: Bug#559522: [pkg-cli-libs-team] Bug#559522: transition: evolution-data-server 2.28
has caused the Debian Bug report #559522,
regarding transition: evolution-data-server 2.28
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
559522: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559522
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

evolution-data-server is having some difficulty getting into testing, which
is holding up quite a few other packages, so I've tried to analyze the
situation a bit; I hope this is helpful.

libevolution5.0-cil (src:evolution-sharp) is basically broken; it hasn't
been ported to evolution-data-server 2.28 and fails to build against it.
The bug has been sent upstream but upstream say no more than "yes, we should
fix this". It might be possible to just override the check and make it build,
or that might result in another FTBFS, or a broken build... perhaps the
e-d-s or evo# maintainers could suggest how to move forward?

If evo# (132 popcon votes) was removed, we'd lose tasque, gfax,
gnome-do-plugins and beagle (34, 42, 347 and 939 popcon votes respectively).
gnome-do-plugins and beagle could presumably both be compiled with Evolution
support disabled, if evo# remains broken for long enough to make it necessary?

mail-notification-evolution is uninstallable in sid, but according to #559106
a simple rebuild works fine. Could it just be binNMU'd?

Meanwhile, xiphos ties the transition to xulrunner, which seems unfortunate.
It's a leaf package with about 500 installations, 70 votes in popcon.

I believe that when evolution-data-server goes into testing,
the gnome-panel / libgnomekbd / libxklavier cluster will be able to go in
too, although they may well need hinting to go together.

Regards,
    Simon

Attachment: signature.asc
Description: Digital signature


--- End Message ---
--- Begin Message --- 
Iain Lane wrote:
> Hiya,
> 
> (please keep pkg-cli-libs-team@ldo cced in replies)
> 
> On Sat, Dec 05, 2009 at 02:12:21AM +0000, Simon McVittie wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian.org@packages.debian.org
>> Usertags: transition
>>
>> [...]
>>
>> libevolution5.0-cil (src:evolution-sharp) is basically broken; it hasn't
>> been ported to evolution-data-server 2.28 and fails to build against it.
>> The bug has been sent upstream but upstream say no more than "yes, we
>> should
>> fix this". It might be possible to just override the check and make it
>> build,
>> or that might result in another FTBFS, or a broken build... perhaps the
>> e-d-s or evo# maintainers could suggest how to move forward?
>>
>> If evo# (132 popcon votes) was removed, we'd lose tasque, gfax,
>> gnome-do-plugins and beagle (34, 42, 347 and 939 popcon votes
>> respectively).
>> gnome-do-plugins and beagle could presumably both be compiled with
>> Evolution
>> support disabled, if evo# remains broken for long enough to make it
>> necessary?
>>
>> [...]
> 
> I/we (pkg-cli-libs) aren't sure how upstream determines compatibility.
> We have been thinking about disabling evo# compatibility for some time
> now, and indeed did this in the gnome-do-plugins package. It's probably
> a good idea to do this as far as we can for the other packages, and then
> to maybe investigate bumping compatibility in evo# and bringing back
> packages when they are known to be work (or to hassle upstream more).
> 
> I'm concerned that we don't want to hold back a transition, but also
> that this situation should not be permenant — so evo# should be removed
> from testing but should be retained (as broken) in unstable, in order to
> allow us to fix in a reasonable amount of time.
> 
> Does that sound possible?

Yes, that's what I did earlier today.

Cheers

Luk

--- End Message ---
Reply to: