Re: bug #122994

2001-12-19 Thread Speed Blue

hello,

> > just reply to the bug number and include the patch (_NOT_ as an
> > attachment) and then tag the bug "patch".  It is the maintainer's job to
> > then apply the patch, test, release and close the bug.
>
> Yep - absolutely *don't* send mail to n-done@bugs if you're not the
> maintainer. See the various instructions on http://bugs.debian.org/.

thanks for the help, I have reply to #120311 and #122994 and have taged them 
to patch.

--
SpeedBlue


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




[정보] ★ 드라이브 코스 안내

2001-12-19 Thread 한석봉
Title: ::: 추천! 드라이브코스 :::





  

  
  

  
  

  
  

  
  

  
  

  
  

  


  


  


  


  





Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Colin Watson
On Wed, Dec 19, 2001 at 10:46:55PM +1300, Andrew McMillan wrote:
> Given the stability of the interfaces to evolution (gtkhtml, camel, ...)
> I know that if _I_ was the DD responsible I wouldn't be too stressed for
> the missing architectures at this stage.  Once we get the base system
> ready in January or so,

The base system has already been frozen, FYI, although the freeze hasn't
reached the point where it concerns evolution yet. Some of GNOME is
involved in the current stage of the freeze.

-- 
Colin Watson  [EMAIL PROTECTED]



Re: bug #122994

2001-12-19 Thread Colin Watson
On Wed, Dec 19, 2001 at 03:48:55PM -0800, Sean 'Shaleh' Perry wrote:
> On 19-Dec-2001 Speed Blue wrote:
> >   I have fix the bug #122994 for bison, I'd like to know what to do for
> > commit the fix. Do I send a mail to [EMAIL PROTECTED] with
> > the diff file ? or use the bts command to close the bug.
> 
> just reply to the bug number and include the patch (_NOT_ as an attachment)
> and then tag the bug "patch".  It is the maintainer's job to then apply the
> patch, test, release and close the bug.

Yep - absolutely *don't* send mail to [EMAIL PROTECTED] if you're not the
maintainer. See the various instructions on http://bugs.debian.org/.

-- 
Colin Watson  [EMAIL PROTECTED]



[정보] ★ 드라이브 코스 안내

2001-12-19 Thread 한석봉
Title: ::: Ãßõ! µå¶óÀ̺êÄÚ½º :::





  

  
  

  
  

  
  

  
  

  
  

  
  

  


  


  


  


  





Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Colin Watson

On Wed, Dec 19, 2001 at 10:46:55PM +1300, Andrew McMillan wrote:
> Given the stability of the interfaces to evolution (gtkhtml, camel, ...)
> I know that if _I_ was the DD responsible I wouldn't be too stressed for
> the missing architectures at this stage.  Once we get the base system
> ready in January or so,

The base system has already been frozen, FYI, although the freeze hasn't
reached the point where it concerns evolution yet. Some of GNOME is
involved in the current stage of the freeze.

-- 
Colin Watson  [[EMAIL PROTECTED]]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: bug #122994

2001-12-19 Thread Colin Watson

On Wed, Dec 19, 2001 at 03:48:55PM -0800, Sean 'Shaleh' Perry wrote:
> On 19-Dec-2001 Speed Blue wrote:
> >   I have fix the bug #122994 for bison, I'd like to know what to do for
> > commit the fix. Do I send a mail to [EMAIL PROTECTED] with
> > the diff file ? or use the bts command to close the bug.
> 
> just reply to the bug number and include the patch (_NOT_ as an attachment)
> and then tag the bug "patch".  It is the maintainer's job to then apply the
> patch, test, release and close the bug.

Yep - absolutely *don't* send mail to n-done@bugs if you're not the
maintainer. See the various instructions on http://bugs.debian.org/.

-- 
Colin Watson  [[EMAIL PROTECTED]]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: bug #122994

2001-12-19 Thread Sean 'Shaleh' Perry

On 19-Dec-2001 Speed Blue wrote:
> Hello,
>   I have fix the bug #122994 for bison, I'd like to know what to do for
commit
> the fix. Do I send a mail to [EMAIL PROTECTED] with the diff file ? or
> use the bts command to close the bug.
> 

just reply to the bug number and include the patch (_NOT_ as an attachment)
and then tag the bug "patch".  It is the maintainer's job to then apply the
patch, test, release and close the bug.



bug #122994

2001-12-19 Thread Speed Blue
Hello,
I have fix the bug #122994 for bison, I'd like to know what to do for 
commit 
the fix. Do I send a mail to [EMAIL PROTECTED] with the diff file ? or 
use the bts command to close the bug.

Thanx for help.
--
Julien Lemoine / SpeedBlue



Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Grant Bowman
* Robert Bihlmeyer <[EMAIL PROTECTED]> [011219 13:10]:
> Grant Bowman <[EMAIL PROTECTED]> writes:
> > MUST all platforms be fixed simultaneously?
> 
> Yes, evolution must be at the same version on all architectures. Archs
> that were never able to build a package are exempt, so that these
> hold-ups are usually due to a arch-specific regression.
> 
> http://buildd.debian.org/build.php?&pkg=evolution> lists all
> build attempts with links to full logs. At least the m68k failure does
> not seem like evolution's responsibility.
> [... art omitted ...] 

Excellent, thank you very much.  I wasn't aware this is where the build
logs are stored.

-- 
-- Grant Bowman   <[EMAIL PROTECTED]>



Re: bug #122994

2001-12-19 Thread Sean 'Shaleh' Perry


On 19-Dec-2001 Speed Blue wrote:
> Hello,
>   I have fix the bug #122994 for bison, I'd like to know what to do for
commit
> the fix. Do I send a mail to [EMAIL PROTECTED] with the diff file ? or
> use the bts command to close the bug.
> 

just reply to the bug number and include the patch (_NOT_ as an attachment)
and then tag the bug "patch".  It is the maintainer's job to then apply the
patch, test, release and close the bug.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




bug #122994

2001-12-19 Thread Speed Blue

Hello,
I have fix the bug #122994 for bison, I'd like to know what to do for commit 
the fix. Do I send a mail to [EMAIL PROTECTED] with the diff file ? or 
use the bts command to close the bug.

Thanx for help.
--
Julien Lemoine / SpeedBlue


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Robert Bihlmeyer
Grant Bowman <[EMAIL PROTECTED]> writes:

> MUST all platforms be fixed simultaneously?

Yes, evolution must be at the same version on all architectures. Archs
that were never able to build a package are exempt, so that these
hold-ups are usually due to a arch-specific regression.

http://buildd.debian.org/build.php?&pkg=evolution> lists all
build attempts with links to full logs. At least the m68k failure does
not seem like evolution's responsibility.



FWIW is this (from one of the logs) some kind of commandline art?

[...]
 -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11
 -lm -ldl -lXi -lXext -lX11 -lm -lz -lm -lz -lm -lm -lm -lm -lm -lz
 -lz -lz -lm -lm -lm -lm -lm -lm -ldl -ldl -ldl -ldl -ldl -ldl -ldl
 -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -ldl -ldl
 -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi
 -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi
 -lXext -lX11 -lm -lz -lm -lm -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl
 -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi
 -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -lz -lm -lz -lm -lm
 -lm -lm -lm -lz -lz -lz -ldl -lXi -lXext -lX11 -lm -lz -lz -lz
[... and so on for dozens of lines ...]

-- 
Robbe


signature.ng
Description: PGP signature


Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Grant Bowman
Thanks Andrew for your reply.  I'll address the issue at hand first.  I
don't know if Takuo subscribed so I'm CC'ing him too.

* Andrew McMillan <[EMAIL PROTECTED]> [011219 02:04]:
> On Wed, 2001-12-19 at 07:33, Grant Bowman wrote:
> > So, back to the issue at hand.  The update_excuses looks like this:
> > 
> > * evolution/alpha unsatisfiable Depends: libgnome-pilot1 (>= 0.1.63) 
> > ['gnome-pilot']
> > * out of date on arm: evolution, evolution-dev, libcamel-dev, libcamel0 
> > (from 0.99.2-1)
> > * evolution/i386 unsatisfiable Depends: libgnome-pilot1 (>= 0.1.63) 
> > ['gnome-pilot']
> > * out of date on ia64: evolution, evolution-dev, libcamel-dev, libcamel0 
> > (from 0.99.0-2)
> > * out of date on m68k: evolution, evolution-dev, libcamel-dev, libcamel0 
> > (from 0.15-3)
> > * out of date on mips: evolution, evolution-dev, libcamel-dev, libcamel0 
> > (from 0.99.0-2)
> > * out of date on mipsel: evolution, evolution-dev, libcamel-dev, libcamel0 
> > (from 0.99.2-1)
> > * out of date on powerpc: evolution, evolution-dev, libcamel-dev, libcamel0 
> > (from 0.99.2-1)
> > * out of date on s390: evolution, evolution-dev, libcamel-dev, libcamel0 
> > (from 0.99.2-1)
> > * out of date on sparc: evolution, evolution-dev, libcamel-dev, libcamel0 
> > (from 0.99.0-2)
> > * Not considered
> > * Depends: evolution gnome-pilot
> > 
> > Would fixing libgnome-pilot1 or changing this to a recommend instead of
> > depend allow evolution to move into woody?  MUST all platforms be fixed
> > simultaneously?
> 
> If it has ever built for a platform then it is expected to build for it
> again and therefore it is a bug if it doesn't.

OK, makes sense.  Thanks for the clarification

> Yes, libgnome-pilot1 will need to build on these platforms before
> evolution will be considered for installation in testing.  I suspect
> that everything will need to build on all of the "out of date" platforms
> as well.

That's alot of work for the 8 above platforms, I realize, assuming it's
really a true Depends: package.  If it only needs Recommends:, that may
be good solution as well but I don't know enough about the packages yet.
Intuitively, I would expect that a pilot synching function is optional
for evolution.

> If you want to use this I would recommend that either you (a) use
> 'unstable' (personally, I would recommend this) or (b) use the
> /etc/apt/apt.conf hack to let you use a mix of 'testing' and 'unstable'
> packages.
> [...]
> Given the stability of the interfaces to evolution (gtkhtml, camel, ...)
> I know that if _I_ was the DD responsible I wouldn't be too stressed for
> the missing architectures at this stage.  Once we get the base system
> ready in January or so, _that's_ when I'd start seriously looking at it
> and deciding that either (A) Alpha is not important, or (B) now is the
> hour to make it all work on alpha.  To do it now is really makework, or
> potentially makework, and we're all volunteers.  At this time of the
> year there is plenty of other stuff to do in our real lives.
> [...]

Your recommendation of waiting to get base stabilized is a good one.
thanks for taking the time to explain this.

Cheers,

-- 
-- Grant Bowman   <[EMAIL PROTECTED]>



Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Grant Bowman

* Robert Bihlmeyer <[EMAIL PROTECTED]> [011219 13:10]:
> Grant Bowman <[EMAIL PROTECTED]> writes:
> > MUST all platforms be fixed simultaneously?
> 
> Yes, evolution must be at the same version on all architectures. Archs
> that were never able to build a package are exempt, so that these
> hold-ups are usually due to a arch-specific regression.
> 
> http://buildd.debian.org/build.php?&pkg=evolution> lists all
> build attempts with links to full logs. At least the m68k failure does
> not seem like evolution's responsibility.
> [... art omitted ...] 

Excellent, thank you very much.  I wasn't aware this is where the build
logs are stored.

-- 
-- Grant Bowman   <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Robert Bihlmeyer

Grant Bowman <[EMAIL PROTECTED]> writes:

> MUST all platforms be fixed simultaneously?

Yes, evolution must be at the same version on all architectures. Archs
that were never able to build a package are exempt, so that these
hold-ups are usually due to a arch-specific regression.

http://buildd.debian.org/build.php?&pkg=evolution> lists all
build attempts with links to full logs. At least the m68k failure does
not seem like evolution's responsibility.



FWIW is this (from one of the logs) some kind of commandline art?

[...]
 -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11
 -lm -ldl -lXi -lXext -lX11 -lm -lz -lm -lz -lm -lm -lm -lm -lm -lz
 -lz -lz -lm -lm -lm -lm -lm -lm -ldl -ldl -ldl -ldl -ldl -ldl -ldl
 -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -ldl -ldl
 -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi
 -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi
 -lXext -lX11 -lm -lz -lm -lm -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl
 -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi
 -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -lz -lm -lz -lm -lm
 -lm -lm -lm -lz -lz -lz -ldl -lXi -lXext -lX11 -lm -lz -lz -lz
[... and so on for dozens of lines ...]

-- 
Robbe



signature.ng
Description: PGP signature


Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Grant Bowman

Thanks Andrew for your reply.  I'll address the issue at hand first.  I
don't know if Takuo subscribed so I'm CC'ing him too.

* Andrew McMillan <[EMAIL PROTECTED]> [011219 02:04]:
> On Wed, 2001-12-19 at 07:33, Grant Bowman wrote:
> > So, back to the issue at hand.  The update_excuses looks like this:
> > 
> > * evolution/alpha unsatisfiable Depends: libgnome-pilot1 (>= 0.1.63) 
>['gnome-pilot']
> > * out of date on arm: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.2-1)
> > * evolution/i386 unsatisfiable Depends: libgnome-pilot1 (>= 0.1.63) ['gnome-pilot']
> > * out of date on ia64: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.0-2)
> > * out of date on m68k: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.15-3)
> > * out of date on mips: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.0-2)
> > * out of date on mipsel: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.2-1)
> > * out of date on powerpc: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.2-1)
> > * out of date on s390: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.2-1)
> > * out of date on sparc: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.0-2)
> > * Not considered
> > * Depends: evolution gnome-pilot
> > 
> > Would fixing libgnome-pilot1 or changing this to a recommend instead of
> > depend allow evolution to move into woody?  MUST all platforms be fixed
> > simultaneously?
> 
> If it has ever built for a platform then it is expected to build for it
> again and therefore it is a bug if it doesn't.

OK, makes sense.  Thanks for the clarification

> Yes, libgnome-pilot1 will need to build on these platforms before
> evolution will be considered for installation in testing.  I suspect
> that everything will need to build on all of the "out of date" platforms
> as well.

That's alot of work for the 8 above platforms, I realize, assuming it's
really a true Depends: package.  If it only needs Recommends:, that may
be good solution as well but I don't know enough about the packages yet.
Intuitively, I would expect that a pilot synching function is optional
for evolution.

> If you want to use this I would recommend that either you (a) use
> 'unstable' (personally, I would recommend this) or (b) use the
> /etc/apt/apt.conf hack to let you use a mix of 'testing' and 'unstable'
> packages.
> [...]
> Given the stability of the interfaces to evolution (gtkhtml, camel, ...)
> I know that if _I_ was the DD responsible I wouldn't be too stressed for
> the missing architectures at this stage.  Once we get the base system
> ready in January or so, _that's_ when I'd start seriously looking at it
> and deciding that either (A) Alpha is not important, or (B) now is the
> hour to make it all work on alpha.  To do it now is really makework, or
> potentially makework, and we're all volunteers.  At this time of the
> year there is plenty of other stuff to do in our real lives.
> [...]

Your recommendation of waiting to get base stabilized is a good one.
thanks for taking the time to explain this.

Cheers,

-- 
-- Grant Bowman   <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




System-dependent libraries X programs must link with

2001-12-19 Thread Amaya
There friends,

This a "just in case" question.

I am packaging fkiss (see #106140). It was finally released under GPL
(yeeha!).

I see that in  configure, upstream checks:

# [EMAIL PROTECTED] says this is needed for Ultrix, if the X
# libraries were built with DECnet support.  And [EMAIL PROTECTED] says
# the Alpha needs dnet_stub (dnet does not exist).
echo $ac_n "checking for dnet_ntoa in -ldnet""... $ac_c" 1>&6
echo "configure:1794: checking for dnet_ntoa in -ldnet" >&5
ac_lib_var=`echo dnet'_'dnet_ntoa | sed 'y%./+-%__p_%'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
  echo $ac_n "(cached) $ac_c" 1>&6
else
  ac_save_LIBS="$LIBS"
LIBS="-ldnet  $LIBS"
cat > conftest.$ac_ext 

System-dependent libraries X programs must link with

2001-12-19 Thread Amaya

There friends,

This a "just in case" question.

I am packaging fkiss (see #106140). It was finally released under GPL
(yeeha!).

I see that in  configure, upstream checks:

# [EMAIL PROTECTED] says this is needed for Ultrix, if the X
# libraries were built with DECnet support.  And [EMAIL PROTECTED] says
# the Alpha needs dnet_stub (dnet does not exist).
echo $ac_n "checking for dnet_ntoa in -ldnet""... $ac_c" 1>&6
echo "configure:1794: checking for dnet_ntoa in -ldnet" >&5
ac_lib_var=`echo dnet'_'dnet_ntoa | sed 'y%./+-%__p_%'`
if eval "test \"`echo '$''{'ac_cv_lib_$ac_lib_var'+set}'`\" = set"; then
  echo $ac_n "(cached) $ac_c" 1>&6
else
  ac_save_LIBS="$LIBS"
LIBS="-ldnet  $LIBS"
cat > conftest.$ac_ext 

Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Andrew McMillan
On Wed, 2001-12-19 at 07:33, Grant Bowman wrote:
> 
> So, back to the issue at hand.  The update_excuses looks like this:
> 
> * evolution/alpha unsatisfiable Depends: libgnome-pilot1 (>= 0.1.63) 
> ['gnome-pilot']
> * out of date on arm: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
> 0.99.2-1)
> * evolution/i386 unsatisfiable Depends: libgnome-pilot1 (>= 0.1.63) 
> ['gnome-pilot']
> * out of date on ia64: evolution, evolution-dev, libcamel-dev, libcamel0 
> (from 0.99.0-2)
> * out of date on m68k: evolution, evolution-dev, libcamel-dev, libcamel0 
> (from 0.15-3)
> * out of date on mips: evolution, evolution-dev, libcamel-dev, libcamel0 
> (from 0.99.0-2)
> * out of date on mipsel: evolution, evolution-dev, libcamel-dev, libcamel0 
> (from 0.99.2-1)
> * out of date on powerpc: evolution, evolution-dev, libcamel-dev, libcamel0 
> (from 0.99.2-1)
> * out of date on s390: evolution, evolution-dev, libcamel-dev, libcamel0 
> (from 0.99.2-1)
> * out of date on sparc: evolution, evolution-dev, libcamel-dev, libcamel0 
> (from 0.99.0-2)
> * Not considered
> * Depends: evolution gnome-pilot
> 
> Would fixing libgnome-pilot1 or changing this to a recommend instead of
> depend allow evolution to move into woody?  MUST all platforms be fixed
> simultaneously?

If it has ever built for a platform then it is expected to build for it
again and therefore it is a bug if it doesn't.

Yes, libgnome-pilot1 will need to build on these platforms before
evolution will be considered for installation in testing.  I suspect
that everything will need to build on all of the "out of date" platforms
as well.

If you want to use this I would recommend that either you (a) use
'unstable' (personally, I would recommend this) or (b) use the
/etc/apt/apt.conf hack to let you use a mix of 'testing' and 'unstable'
packages.

Filing bugs against evolution will only get people's backs up because
evolution is not the problem here.  What you are doing is like filing
bugs against Sawfish because it depended on a particular new version of
glibc that wouldn't compile against sparc.

If you really want to help, make libgnome-pilot1 compile on the missing
architectures.  If you can't help on that, hassling the developer will
do nothing more than annoy a bunch of fairly ornery volunteers.

Given the stability of the interfaces to evolution (gtkhtml, camel, ...)
I know that if _I_ was the DD responsible I wouldn't be too stressed for
the missing architectures at this stage.  Once we get the base system
ready in January or so, _that's_ when I'd start seriously looking at it
and deciding that either (A) Alpha is not important, or (B) now is the
hour to make it all work on alpha.  To do it now is really makework, or
potentially makework, and we're all volunteers.  At this time of the
year there is plenty of other stuff to do in our real lives.

"Testing" is not normally a distribution that is actually runnable.  The
distributions that are usable are either 'stable' (should be always
usable) or 'unstable' (expect occasional breakage).  Maybe that doesn't
seem right, but 'testing' as a distribution, has only been around since
'potato' was released.  There are tricks to make it 'mostly usable' but
you will have a lot less pain with 'unstable', and bug reports against
'unstable' are a lot more useful to developers.

Regards,
Andrew McMillan
-- 

Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201MOB: +64(21)635-694OFFICE: +64(4)499-2267
   Are you enrolled at http://schoolreunions.co.nz/ yet?



Unidentified subject!

2001-12-19 Thread Fred Strauss
unsubscribe



Re: Bug#123769: Problems for evolution into woody

2001-12-19 Thread Andrew McMillan

On Wed, 2001-12-19 at 07:33, Grant Bowman wrote:
> 
> So, back to the issue at hand.  The update_excuses looks like this:
> 
> * evolution/alpha unsatisfiable Depends: libgnome-pilot1 (>= 0.1.63) ['gnome-pilot']
> * out of date on arm: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.2-1)
> * evolution/i386 unsatisfiable Depends: libgnome-pilot1 (>= 0.1.63) ['gnome-pilot']
> * out of date on ia64: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.0-2)
> * out of date on m68k: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.15-3)
> * out of date on mips: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.0-2)
> * out of date on mipsel: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.2-1)
> * out of date on powerpc: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.2-1)
> * out of date on s390: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.2-1)
> * out of date on sparc: evolution, evolution-dev, libcamel-dev, libcamel0 (from 
>0.99.0-2)
> * Not considered
> * Depends: evolution gnome-pilot
> 
> Would fixing libgnome-pilot1 or changing this to a recommend instead of
> depend allow evolution to move into woody?  MUST all platforms be fixed
> simultaneously?

If it has ever built for a platform then it is expected to build for it
again and therefore it is a bug if it doesn't.

Yes, libgnome-pilot1 will need to build on these platforms before
evolution will be considered for installation in testing.  I suspect
that everything will need to build on all of the "out of date" platforms
as well.

If you want to use this I would recommend that either you (a) use
'unstable' (personally, I would recommend this) or (b) use the
/etc/apt/apt.conf hack to let you use a mix of 'testing' and 'unstable'
packages.

Filing bugs against evolution will only get people's backs up because
evolution is not the problem here.  What you are doing is like filing
bugs against Sawfish because it depended on a particular new version of
glibc that wouldn't compile against sparc.

If you really want to help, make libgnome-pilot1 compile on the missing
architectures.  If you can't help on that, hassling the developer will
do nothing more than annoy a bunch of fairly ornery volunteers.

Given the stability of the interfaces to evolution (gtkhtml, camel, ...)
I know that if _I_ was the DD responsible I wouldn't be too stressed for
the missing architectures at this stage.  Once we get the base system
ready in January or so, _that's_ when I'd start seriously looking at it
and deciding that either (A) Alpha is not important, or (B) now is the
hour to make it all work on alpha.  To do it now is really makework, or
potentially makework, and we're all volunteers.  At this time of the
year there is plenty of other stuff to do in our real lives.

"Testing" is not normally a distribution that is actually runnable.  The
distributions that are usable are either 'stable' (should be always
usable) or 'unstable' (expect occasional breakage).  Maybe that doesn't
seem right, but 'testing' as a distribution, has only been around since
'potato' was released.  There are tricks to make it 'mostly usable' but
you will have a lot less pain with 'unstable', and bug reports against
'unstable' are a lot more useful to developers.

Regards,
Andrew McMillan
-- 

Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201MOB: +64(21)635-694OFFICE: +64(4)499-2267
   Are you enrolled at http://schoolreunions.co.nz/ yet?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]




Unidentified subject!

2001-12-19 Thread Fred Strauss

unsubscribe


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]