Paul Wise writes:
> Please ask your upstreams to remove the Unicode data files from their
> version control systems and source tarballs and instead check for and
> use external Unicode data files at build-time or run-time. Then your
> packages can Build-Depend or Depend on the unicode-data binary
Adam Borowski angband.pl> writes:
> On Wed, Jun 18, 2014 at 02:54:43PM +0200, Thorsten Glaser wrote:
> > > Unicode 7.0 was recently released. I discovered some source packages
> > > contain outdated copies of various Unicode data files. At minimum, the
> >
> > I know that xterm’s wcwidth.c direl
On Thu, Jun 19, 2014 at 4:46 AM, Thorsten Glaser wrote:
> It’s a bit more than a table. Also, the process involves some
> unfree-for-a-BSD (GNU GPL) code that does part of the transformation.
> For jupp, I have to do other parts by hand, including review…
Could you explain in more detail?
Perhap
On Thu, Jun 19, 2014 at 1:27 AM, Jay Berkenbilt wrote:
> I'd have to study it a little more, but I'm not sure this actually makes
> sense for a package like ICU whose sole purpose in life is handling
> Unicode.
Could you explain in more detail, I'm not following your thought process here?
How do
Henrique de Moraes Holschuh dixit:
>Make it generic, instead. You could just automatize the table update
>through a script, and allow it to either fetch the data over the network
>using curl/wget/whatever (default), or to get the data from a local file.
It’s a bit more than a table. Also, the pr
Paul Wise wrote:
> Hi all,
>
> Unicode 7.0 was recently released. I discovered some source packages
> contain outdated copies of various Unicode data files. At minimum, the
> following packages embed part of the Unicode data (UnicodeData.txt).
>
> . . .
>
> Please ask your upstreams to remove th
On Wed, 2014-06-18 at 20:29:59 +0800, Paul Wise wrote:
> If your package converts the Unicode data to another format at build
> time you should add a Built-Using header to the relevant binary
> packages. The fntsample package is an example of how to do this.
>
> https://www.debian.org/doc/debian-p
On Wed, Jun 18, 2014 at 11:33 PM, Alastair McKinstry wrote:
> I updated unicode-data already to 7.0, so the data is present and
> packaged in Debian
> so there is no need to fetch via curl, etc.
> Build-Dep on unicode-data and then updates should simply be a binNMU ?
That is fine for Debian but u
I updated unicode-data already to 7.0, so the data is present and
packaged in Debian
so there is no need to fetch via curl, etc.
Build-Dep on unicode-data and then updates should simply be a binNMU ?
regards
Alastair
On 18/06/2014 14:40, Paul Wise wrote:
> On Wed, Jun 18, 2014 at 9:22 PM, Henrique
On Wed, Jun 18, 2014 at 9:22 PM, Henrique de Moraes Holschuh wrote:
> Make it generic, instead. You could just automatize the table update
> through a script, and allow it to either fetch the data over the network
> using curl/wget/whatever (default), or to get the data from a local file.
That w
On Wed, 18 Jun 2014, Thorsten Glaser wrote:
> Furthermore, with upstream *and* Debian maintainer hat on, I refuse to
> use a Debian-specific “special way” here. I will only fix this upstream
> (and there, there is no unicode-data package).
Make it generic, instead. You could just automatize the t
On Wed, Jun 18, 2014 at 02:54:43PM +0200, Thorsten Glaser wrote:
> > Unicode 7.0 was recently released. I discovered some source packages
> > contain outdated copies of various Unicode data files. At minimum, the
>
> I know that xterm’s wcwidth.c direly needs updating, and that mgk
> doesn’t do th
On Wed, 18 Jun 2014, Paul Wise wrote:
> Unicode 7.0 was recently released. I discovered some source packages
> contain outdated copies of various Unicode data files. At minimum, the
For mine, mksh and jupp do, but they do not use the data files directly.
Instead, when Unicode is updated, I change
13 matches
Mail list logo
