Paul Wise p...@debian.org 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
Adam Borowski kilobyte at 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
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).
There are probably many more embedding different parts of the Unicode
data,
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
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 that. I
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
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
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 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
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.
Paul Wise p...@debian.org 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
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
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 does
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?
Perhaps
14 matches
Mail list logo
