On Sep 6, 2005, at 11:04 AM, AIDA Shinra wrote:
I want --enable-extra-encodings.
Can you explain this, please? I do not understand your request.
The libiconv supports some extra encodings which are disabled by
default. The /usr/lib/libiconv.2.2.0.dylib is configured with
--enable-extra-e
> > I want --enable-extra-encodings.
>
> Can you explain this, please? I do not understand your request.
The libiconv supports some extra encodings which are disabled by
default. The /usr/lib/libiconv.2.2.0.dylib is configured with
--enable-extra-encodings, but the /sw/lib/libiconv.2.2.0.dylib i
On Sep 6, 2005, at 10:25 AM, AIDA Shinra wrote:
I want --enable-extra-encodings.
Can you explain this, please? I do not understand your request.
-- Dave
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
Septembe
I want --enable-extra-encodings.
> I have updated the gettext and libiconv packages: the new versions
> are currently in experimental/dmrrsn/base if anybody would like to
> help test.
>
> For gettext, in addition to bringing the program to the latest
> version, the division into splitoffs h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 8, 2005, at 10:00 AM, David R. Morrison wrote:
On Mar 5, 2005, at 10:01 PM, Tony Arnold wrote:
Hi All,
Peter O'Gorman wrote:
| I really wish I could propose some magic that would make everyone
happy in
| the upgrade process, but I can not.
Is pa
On 08 Mar 2005, at 16:00, David R. Morrison wrote:
The case at hand is tricky. For quite good reasons, it is being
proposed to move some of the executable files out of the gettext-bin
package and into a new package (gettext-tools). Since quite a number
of packages already declare Depends or Bu
On Mar 5, 2005, at 10:01 PM, Tony Arnold wrote:
Hi All,
Peter O'Gorman wrote:
| I really wish I could propose some magic that would make everyone
happy in
| the upgrade process, but I can not.
Is package refactoring something that's planned for the future? I've
hit this a couple of times before, a
'almost done, no?'
Yes _ looks so. Congratulations !
From a first look, small points:
1) in gettext-emacs, the "rm %i/share" in the InstallScript leads
in the PostInstallScript to:
install/gettext-tools: byte-compiling for emacs21
cp: cannot stat `/sw/share/emacs/site-lisp/gettext-tools/po-mode.el'
On 06 Mar 2005, at 19:58, TheSin wrote:
so they are a builddep and a runtime dep...if so why not just keep
them in -bin and builddep and dep on it/them?
Wonderful to see how we always agree ...
JF
---
SF email is sponsored by - The IT Product Gu
so they are a builddep and a runtime dep...if so why not just keep them
in -bin and builddep and dep on it/them?
---
TS
http://southofheaven.org
Chaos is the beginning and end, try dealing with the rest.
On 6-Mar-05, at 11:06 AM, Jean-François Mertens wrote:
On 06 Mar 2005, at 18:07, TheSin wrote
On 06 Mar 2005, at 18:07, TheSin wrote:
I disagree here, -dev should be all thing that should never be
depended on and that are needed to build pkgs. ie: %p/bin/%n-config
should ALWAYS be in the -dev pkg.
Of course !
Here there is no -config or .pc file _ that's why it wasn't mentioned;
the list
After read through the thread I see the problem is with keeping the old
version. Could we not just keep the old -shlibs and make this -dev and
-bin provide the old pkg names? ie: libgettext3-dev provides
gettext-dev and then we can drop the old gettext for the new one and
the next version cou
I disagree here, -dev should be all thing that should never be depended
on and that are needed to build pkgs. ie: %p/bin/%n-config should
ALWAYS be in the -dev pkg. I personally think we should find a way to
correct this in gettext and make it done, even if it becomes a multi
step solution.
Hi Chris,
Cf below for an additional reason to revert to the layout of the
current gettext pkg
(ie, -dev containing only the headers, *.a, *.la, and the final .dylib
links, and all
executables in /sw/bin).
Further. I'm sure that in that case all switching problems disappear...
(I'm basically just
Hi All,
Peter O'Gorman wrote:
> | I really wish I could propose some magic that would make everyone happy in
> | the upgrade process, but I can not.
Is package refactoring something that's planned for the future? I've
hit this a couple of times before, and the response has always been
don't renam
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Peter O'Gorman wrote:
| Chris Zubrzycki wrote:
|
| | Any thoughts/suggestions?
|
| Well, we need the new gettext, I agree, but we also need for users to be
| able to run a successful selfupdate and update-all. It does not seem that
| the package wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Zubrzycki wrote:
| Any thoughts/suggestions?
Well, we need the new gettext, I agree, but we also need for users to be
able to run a successful selfupdate and update-all. It does not seem that
the package which you have put into your experimental d
Hi Chris,
On 03 Mar 2005, at 17:06, Chris Zubrzycki wrote:
I have prepared a new gettext package to use, based on the latest
code (jan 04).
As you had asked to test it, I've been using it since one month,
rebuilding everything
using gettext3 (and readline -> readline5, gdbm -> gdbm3, netpbm ->
n
18 matches
Mail list logo
