Re: bug #122994
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]
[정보] ★ 드라이브 코스 안내
Title: ::: 추천! 드라이브코스 :::
Re: Bug#123769: Problems for evolution into woody
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
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]
[정보] ★ 드라이브 코스 안내
Title: ::: Ãßõ! µå¶óÀ̺êÄÚ½º :::
Re: Bug#123769: Problems for evolution into woody
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
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
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
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
* 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
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
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
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
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
* 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
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
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
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
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
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!
unsubscribe
Re: Bug#123769: Problems for evolution into woody
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!
unsubscribe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
