Re: upstart: please update to latest upstream version

2012-03-03 Thread Florian Weimer 
* Matthias Klumpp:

> He does not want portability patches in systemd, because much
> invasive changes would be needed, making the code more difficult to
> read (which might even lead to buggy code).

It seems that this also applies to older Linux versions.  According to
the documentation, the current version requires kernel 2.6.39.  This
might cause trouble during upgrades.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k432rtce@mid.deneb.enyo.de

Re: Do not use tabs in /etc/init.d/[script]

2012-03-03 Thread Alexey 
Sorry guys,

I really think that scripts can looks better without tabs (or without spaces 
where should be tabs), but I realized that it is simply impossible to get one 
style for scripts.
Even in *skeleton* almost everywhere used tabs, but in few places (where should 
be tabs) — spaces.

I was wrong that asked you do this thing.

Sorry for my english. 

Thank you all for what you doing and let's forget about this idea.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f9258b5-2bbc-45da-8e83-4be902a43...@gmail.com

pdiff for Translation files, increased times

2012-03-03 Thread Joerg Jaspert 
Hi

i took the BSP i am at right now to look at that pdiff shit, and after i
finished yelling at that code, we now are creating pdiff files for
changed Translation-*.bz2 too.

That is, we just started, so there is only the pdiff for the -en file
available, but whenever the other languages get updates they will gain a
.diff too. 

I have no idea if this is support in apt&friends already, but I'm using
the exact same stuff as for the other pdiff files, so shouldn't be too
hard to get into them if not yet.


Also, I changed the amount of pdiff files we store, from 14 up to 56,
which should mean we will go up to around 14 days of pdiff again, from
the ~3.5days we have now.

-- 
bye, Joerg
 also dies ist so ziemlich der einzige chanel wo ich meist 0 peile
 ich schreibe etwas dann rennen se alle gegen die wand und schreien 
aua


pgp7rSCuUiPhO.pgp
Description: PGP signature

Re: Link-Time Optimisation

2012-03-03 Thread Thorsten Glaser 
Aron Xu dixit:

>You might be interested in reading this thread:
>http://lists.debian.org/debian-devel/2011/06/msg00149.html

Ok, will have a look, thanks.

>Activating LTO by default seems not to be a reasonable idea (reasons

Right, it is not.

>are in the given thread), but if maintainer of a package see it's
>appropriate then he can use it in the package.

Yes, that was my intention, I just wondered whether people
were using it in their packages at all, and provided an
example for others to use or even improve.

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool.”
-- Edward Burr


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1203031539410.24...@herc.mirbsd.org

Bug#658139: evince: missing mime entry

2012-03-03 Thread Giovanni Biscuolo 
Dear Raphael,

thank you for your update on the status of this issue

> On Wed, 29 Feb 2012, Giovanni Biscuolo wrote:

[...]

> Please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779

OK thanks a lot for the link, now I understand very well what is
happening :-)

this bug is definetly linked to #497779... a bug started on 2008.09.04,
more than 3 years ago :-(

more than 3 years ago Josselin Mouette was tired:
"I’m tired of receiving bug reports asking to add a debian/mime file to
support an outdated MIME system that no application I know besides mutt
still uses."

and today we are in the very same situation, with people like me still
commeting on bugs Josselin Mouette is tired of receive

sure the solution should be to patch mime-support and close #497779 once
and forever, rumors says that all is needed is a one liner script
somewhere... so **what is the problem**??? :-)

but why drop mime-support usage from evince (and others packages)
**before** resolving #497779?
...because no one uses mutt or other programs that rely on mailcap?!?
...why just drop /etc/mailcap from Debian?

thanks to brian m. carlson it seems we now have a patch for
mime-support, a patch that "took less than an hour" as he said:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497779#20

three years for a "less than an our" patch?!? (still to test and
deploy, obviously)

three years to discuss the new policy "let's drop update-mime
(and mailcap) support, who cares about an outdated MIME system"!?
Debian developers considers mailcap outdated?
you should write it down in some official document, like debian-policy

why can we just collaborate on issues instead of discuss on who is rigth
and who is wrong... for 3 years?!?

I think a more clear policy on multimedia handlers should be specified:
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-mime
in particular *if* mailcap (and update-mime) have to be used in packages
like evince

Ciao
Giovanni

-- 
Giovanni Biscuolo

Xelera - IT infrastructures
http://xelera.eu/contact-us/


signature.asc
Description: Digital signature

Split arch:all contents to Contents-all.gz

2012-03-03 Thread Joerg Jaspert 
Hi

I don't think it was on -devel yet, so here it goes:

Copying from Ansgars original message:

--88---
The arch:all part of Contents-*.gz are ~15 MB of the total 20 MB per 
architecture (as could be seen on Contents-armhf.gz which has no 
arch:any packages yet).  I was wondering if we might want to move this 
to a Contents-all.gz that could be shared between all architectures.

Note that this would also require changes to tools using the contents 
files as they would need to also download (and use) the -all file.
--88---

I do think we should do it, and even think it should be in time for
Wheezy, if we do it soonish. For the user it shouldn't change anything,
the tools need to download 2 files and use them, and our dists/ will get
smaller...

-- 
bye, Joerg
<40293f1b.8130...@news.individual.de>
Windows ME? Mit 13? Kann der nicht lieber Drogen nehmen wie andere Kinder
in dem Alter?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762el4kyy@lennier.ganneff.de

Re: Linux kernel hardening - link restrictions

2012-03-03 Thread Ben Hutchings 
On Fri, 2012-03-02 at 07:43 +, Lars Wirzenius wrote:
> On Fri, Mar 02, 2012 at 05:11:58AM +, Ben Hutchings wrote:
> > +  * The new kernel version includes security restrictions on links, which
> > +are enabled by default.  These are specified in
> > +Documentation/sysctl/fs.txt in the linux-doc-3.2 and linux-source-3.2
> > +packages.
> 
> It'd be helpful to also point at a web page where one can read that text.

Maybe, but I don't know where it would go.  Normally I would point to
http://www.kernel.org/doc/... but that won't be valid until these
changes get into an upstream release.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.


signature.asc
Description: This is a digitally signed message part

Re: Linux kernel hardening - link restrictions

2012-03-03 Thread Adam D. Barratt 

On 02.03.2012 10:47, Holger Levsen wrote:

On Freitag, 2. März 2012, Kees Cook wrote:
> +  * The new kernel version includes security restrictions on 
links,
> +These restrictions may cause some legitimate programs to 
fail.
> +In particular, if the 'at' package is installed, you should 
either:
> +- Upgrade it to at least version 3.1.13-1 (or a backport of 
that)

> +- Set sysctl fs.protected_hardlinks=0 (see /etc/sysctl.conf)
It's a trivial patch[1] to fix "at". How about just backporting that
change to stable, to avoid that known trouble too? This is what 
Ubuntu
did for the Lucid LTS release that was getting backported kernels 
(with

link restrictions) built for it.


sounds like a reasonable plan to me, cc:ing debian-release to get a 
comment

on this, and cc:ing the at maintainer too.


[1]

http://anonscm.debian.org/gitweb/?p=collab-maint/at.git;a=commitdiff;h=f4114656c3a6c6f6070e315ffdf940a49eda3279


(Predictably enough) I'd like to see a debdiff before a final ack, but 
in principle it looks okay; thanks.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/3568a2229c033ded546b0c51ec353...@mail.adsl.funky-badger.org

Bug 644138: kcc and heimdal-client both install /usr/bin/kcc

2012-03-03 Thread Edward Allcutt 

Hi devel,

These packages do not remotely have the same functionality:
kcc: Kanji code filter
heimdal-clients: Heimdal Kerberos - clients

kcc appears to have shipped /usr/bin/kcc approximately since 1997.

heimdal-clients introduced /usr/bin/kcc in September 2011 and #644138
was filed shortly thereafter.

The bug was closed by upload:
   * Add conflicts with kcc to heimdal-clients. Closes: #644138

and reopened the next day as "not an appropriate use of Conflicts". Quoting
policy 10.1:

 Two different packages must not install programs with different
 functionality but with the same filenames.  (The case of two programs
 having the same functionality but different implementations is handled
 via "alternatives" or the "Conflicts" mechanism.  See Section 3.9,
 `Maintainer Scripts' and Section 7.4, `Conflicting binary packages -
 `Conflicts'' respectively.) If this case happens, one of the programs
 must be renamed.  The maintainers should report this to the
 `debian-devel' mailing list and try to find a consensus about which
 program will have to be renamed.  If a consensus cannot be reached,
 _both_ programs must be renamed.

It has now been five months without either maintainer raising this.

--
Edward Allcutt


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.02.1203031820140.1...@jago.allcutt.me.uk

Re: Bug 644138: kcc and heimdal-client both install /usr/bin/kcc

2012-03-03 Thread Jelmer Vernooij 
On Sat, 2012-03-03 at 18:41 +, Edward Allcutt wrote:
> These packages do not remotely have the same functionality:
> kcc: Kanji code filter
> heimdal-clients: Heimdal Kerberos - clients
> 
> kcc appears to have shipped /usr/bin/kcc approximately since 1997.
> 
> heimdal-clients introduced /usr/bin/kcc in September 2011 and #644138
> was filed shortly thereafter.

Thanks for bringing this up.

I think it would be reasonable for Heimdal to rename kcc to kcc.heimdal
or something like that.

Heimdal upstream has been shipping kcc since 2010, but we haven't
included it in Debian before, so that probably causes the least upgrade
issues.

Cheers,

Jelmer


signature.asc
Description: This is a digitally signed message part

Re: upstart: please update to latest upstream version

2012-03-03 Thread David Weinehall 
On Tue, Feb 28, 2012 at 02:36:11PM +, Ian Jackson wrote:
> Josselin Mouette writes ("Re: upstart: please update to latest upstream 
> version"):
> > Or, as has been said countless times otherwise: kFreeBSD should not
> > hinder the improvement of the Linux ports.
> 
> It's not just kFreeBSD.  Accepting systemd, in the current state,
> means permanently tying ourselves to the Linux kernel.
> 
> The Linux kernel project has some serious and ongoing structural
> problems and I think it's very important that as a project we keep our
> options open.

I'd be very curious to hear what these serious and ongoing structural
problems are.


Kind regards: David Weinehall
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120303210533.gc17...@suiko.acc.umu.se

Re: Bug#644138: Bug 644138: kcc and heimdal-client both install /usr/bin/kcc

2012-03-03 Thread Russ Allbery 
Jelmer Vernooij  writes:

> Thanks for bringing this up.

> I think it would be reasonable for Heimdal to rename kcc to kcc.heimdal
> or something like that.

> Heimdal upstream has been shipping kcc since 2010, but we haven't
> included it in Debian before, so that probably causes the least upgrade
> issues.

I would contact Heimdal upstream and ask if they'd be willing to change
the name of the binary, given that it's a relatively new program and is
much more recent than the other package.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipil75rj@windlord.stanford.edu

Status of opensync in Debian - mass removal very likely

2012-03-03 Thread Neil Williams 
opensync/multisync is a complete mess, collecting 25 RC bugs between 20
source packages and a collective 17,626 days waiting to enter testing.
dd-list attached.

Summary:
libopensync-plugin-gnokii   1462 days old (needed 10 days)  libopensync0
RC x 2
libopensync-plugin-gpe  1462 days old (needed 10 days)  libopensync0
RC x 2
libopensync-plugin-irmc 976 days old (needed 10 days)   libopensync0
RC
libopensync-plugin-kdepim   1025 days old (needed 10 days)  libopensync0
RC
libopensync-plugin-moto 1207 days old (needed 10 days)  libopensync0
RC x 2
libopensync-plugin-opie 1190 days old (needed 10 days)  libopensync0
RC x 2
libopensync-plugin-palm 1461 days old (needed 10 days)  libopensync0
RC x 2
libopensync-plugin-python   1347 days old (needed 10 days)  libopensync0
RC x 2
libopensync-plugin-sunbird  1456 days old (needed 10 days)  libopensync0
RC x 2
osynctool   765 days old (needed 10 days)   RC
opensync663 days old (needed 10 days)   RC x 3
libopensync-plugin-xmlformat754 days old (needed 10 days)   opensync
libopensync-plugin-vformat  768 days old (needed 10 days)   opensync
libopensync-plugin-syncml   755 days old (needed 10 days)   opensync
libopensync-plugin-file 755 days old (needed 10 days)   opensync
libopensync-plugin-evolution2   755 days old (needed 10 days)   libcamel-1.2-23 
et al
multisync0.90   825 days old (needed 10 days)   libopensync0
RC x 2
synce-sync-engine   depends opensync, libopensync-plugin-python
libopensync-plugin-google-calendar  libopensync0 (experimental) RC x 3
synce-kpm   depends on synce-sync-engine

Most depend on libopensync0 which does not exist anymore, those which
have been updated are split between libopensync1exp3 and
libopensync1exp7. libopensync1exp3 does not exist, libopensync1exp7 has
3 RC bugs.

If there's no response (I'm NOT expecting fixes, just *some* idea of
whether these RC bugs *can* be fixed and all the packages migrated to
whatever counts as the latest available libopensync version), ALL of
these packages will have to be removed. I'm afraid it's SO unlikely
that anything is going to be truly fixed by Wheezy, the only real
option for a deadline is 7 days to get *SOME* kind of expression of
interest, some idea of a plan. Naturally, if the maintainers wish to
file the removal bugs themselves, that would be appreciated.

I know all of these have already been removed from testing, but the
packages in unstable are completely unusable / not installable. Just
leaving RC bugs in unstable for years should not be acceptable.

There are packages in experimental too but those appear to be gathering RC
bugs as well, so I'll also file removal bugs for those.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



dd-list
Description: Binary data


pgphGSLD2VdIZ.pgp
Description: PGP signature

Re: Status of opensync in Debian - mass removal under way.

2012-03-03 Thread Neil Williams 
On Sat, 3 Mar 2012 23:15:16 +
Neil Williams  wrote:

> opensync/multisync is a complete mess, collecting 25 RC bugs between 20
> source packages and a collective 17,626 days waiting to enter testing.
> dd-list attached.

Was so busy preparing the summary, didn't notice that the maintainer
had already come back to me on IRC. Filing the RM bugs tonight.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp2QPguJZrTn.pgp
Description: PGP signature

Bug#662080: ITP: hadori -- Hardlinks identical files

2012-03-03 Thread Timo Weingärtner 
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: hadori
Version: 0.2
Upstream Author: Timo Weingärtner 
URL: https://github.com/tiwe-de/hadori
License: GPL3+
Description: Hardlinks identical files
 This might look like yet another hardlinking tool, but it is the only one
 which only memorizes one filename per inode. That results in less merory
 consumption and faster execution compared to its alternatives. Therefore
 (and because all the other names are already taken) it's called
 "HArdlinking DOne RIght".
 .
 Advantages over other hardlinking tools:
  * predictability: arguments are scanned in order, each first version is kept
  * much lower CPU and memory consumption
  * hashing option: speedup on many equal-sized, mostly identical files

The initial comparison was with hardlink, which got OOM killed with a hundred 
backups of my home directory. Last night I compared it to duff and rdfind 
which would have happily linked files with different st_mtime and st_mode.

I need a sponsor. I'll upload it to mentors.d.n as soon as I get the bug 
number.


Greetings
Timo


signature.asc
Description: This is a digitally signed message part.

Re: Enabling package installation for non-root users

2012-03-03 Thread David Weinehall 
On Mon, Feb 27, 2012 at 09:32:04AM +0100, Josselin Mouette wrote:
> Le lundi 27 février 2012 à 05:19 +0100, Sebastian Heinlein a écrit : 
> > Am Donnerstag, den 23.02.2012, 18:46 +0200 schrieb Timo Juhani
> > Lindfors: 
> > > Josselin Mouette  writes:
> > > > (We even have a patch to allow only a subset of packages but it is
> > > > unfortunately a bit too hackish.)
> > > 
> > > Would be really nice to have some standard sets available (think
> > > "browser extensions", "command-line tools that ship no services or suid
> > > binaries"). I'd certainly let my desktop users install these without
> > > having to ask me or having to install them manually to their $HOME..
> > 
> > Do you need a whitelist or a blacklist?
> 
> This should clearly be a whitelist. I don’t think there’s real use for a
> blacklist, it is too dangerous.

Wouldn't both be best?  Let's say the whitelist contains all packages of
a certain category.  The blacklist could then be used to make an
exception for a specific package within that category.


Regards: David
-- 
 /) David Weinehall  /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120304003944.gd17...@suiko.acc.umu.se

Re: Split arch:all contents to Contents-all.gz

2012-03-03 Thread Paul Wise 
Sounds like a win to me.

The tools that might need changing:

debmirror
apt-file
UDD
collab-qa/filecontents/*-contents.py

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6fknh-oawejimvcj61qoe4emedqgxhnhf7zok2b6zy...@mail.gmail.com

Re: Multiarch file overlap summary and proposal

2012-03-03 Thread Goswin von Brederlow 
m...@linux.it (Marco d'Itri) writes:

> On Mar 01, Russ Allbery  wrote:
>
>> The situation with refcounting seems much less fragile than the situation
>> without refcounting to me.
> I totally agree.
>
> Also, why does refcounting have to be "perfect"?
> What would break if it did not actually check that the two files 
> provided by the same package for different architectures are identical?

Everything that can go wrong when splitting packages. You would loose
the stability advantage.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa3wkhpv.fsf@frosties.localnet

Re: Multiarch file overlap summary and proposal

2012-03-03 Thread Goswin von Brederlow 
Guillem Jover  writes:

> On Wed, 2012-02-15 at 16:32:38 -0800, Russ Allbery wrote:
>> Guillem Jover  writes:
>> > If packages have to be split anyway to cope with the other cases, then
>> > the number of new packages which might not be needed otherwise will be
>> > even smaller than the predicted amount, at which point it makes even
>> > less sense to support refcnt'ing.
>> 
>> I don't think the package count is really the interesting metric here,
>> unless the number of introduced packages is very large (see below about
>> -dev packages).  I'm more concerned with maintainer time and with
>> dependency complexity, and with the known problems that we introduce
>> whenever we take tightly-coupled files and separate them into independent
>> packages.
>
> Well, people have been using the amount of packages as a metric, I've
> just been trying to counter it. It also in a way represents the amount
> of work needed.
>
> About tightly-coupled files, they can cause serious issues also with
> refcounting, consider that there's always going to be a point when
> unpacking one of the new instances will have a completely different
> vesion than the other already unpacked instance(s). So packages could
> stop working for a long time if say unpacked libfoo0:i386 1.0 has
> file-format-0, but new libfoo0:amd64 4.0 has file-format-2, and the
> file didn't change name (arguably this could be considered an upstream
> problem, depending on the situation), this would be particularly
> problematic for pseudo-essential packages.

That is not an argument for or against refcounting. If at all it would
be marginally for refcounting:

The same situation would occur with libfoo0:i386 1.0, libfoo0:amd64 4.0
and libfoo0-common:all 2.0. But now even worse because you have 3
versions that can be out-of-sync.

Actualy if the file is shipped in the package then ref counting would
automatically detect the difference in contents and fail to install the
new libfoo0:amd64 4.0. And if the file is not shipped in the package
then ref counting has no effect on it. Again ref counting comes out
better.

Ref counting would catch some of those cases but not all and it never
makes it worse. What solves this problem is the same version requirement
or simply adding Breaks: libfoo0 (<< 4.0~) to libfoo0:* 4.0. The only
point you've made is that ref counting isn't a magic bullet that brings
us world peace.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762ekkh3g.fsf@frosties.localnet

Bug#662111: ITP: fonts-lato -- sans-serif typeface family font

2012-03-03 Thread Vasudev Kamath 
Package: wnpp
Severity: wishlist
Owner: Vasudev Kamath 

* Package name: fonts-lato
   Version: 1.104
  Upstream Author : ��ukasz Dziedzic
* URL  :  http://www.latofonts.com
* License: OFL 1.1
  Programming Lang: font
  Description : sans-serif typeface family font

Lato is a sanserif type��face fam��ily designed by 
Warsaw-������based designer
��ukasz Dziedzic (���Lato��� means 
���Sum��mer��� in Pol��ish).
Lato fam��ily was pub��lished under the open-������source 
Open Font License by
his foundry tyPoland, with sup��port from Google.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120304071920.22601.59212.reportbug@copyninja

Re: Bug#644138: Bug 644138: kcc and heimdal-client both install /usr/bin/kcc

2012-03-03 Thread Osamu Aoki 
Hi,

Wait a moment ...  what about removing kcc package. (See below)

On Sat, Mar 03, 2012 at 01:07:28PM -0800, Russ Allbery wrote:
> Jelmer Vernooij  writes:
> > I think it would be reasonable for Heimdal to rename kcc to kcc.heimdal
> > or something like that.

This is, as I understand, our standard procedure but ... what about
removing kcc package after seeing how it is now.

> > Heimdal upstream has been shipping kcc since 2010, but we haven't
> > included it in Debian before, so that probably causes the least upgrade
> > issues.
> 
> I would contact Heimdal upstream and ask if they'd be willing to change
> the name of the binary, given that it's a relatively new program and is
> much more recent than the other package.

There are so many encoding convertes.  This one seems to be outdated and
not so popular and not maintained.  (It used to be popular as I remember
but that may be as old as in 1998 when nkf was in non-free ...)

Reality checks:

I locally have 2 of them:
 libc-bin: /usr/bin/iconv (The most basic one without huristics)
 nkf: /usr/bin/nkf(The best huristic Japanese optimized one)

As I quickly checked for japanese optimized ones, I found 3:
nkf popcon = about 2000  last upload [2011-05-31] active
kcc popcon < 200 last upload [2004-11-29] no change from oldstable
ack popcon < 100 last upload [2008-07-24] no change from oldstable
http://qa.debian.org/popcon-graph.php?packages=kcc+ack+nkf&show_installed=on&want_legend=on&want_ticks=on&beenhere=1

nkf: UTF-8 supported (in Description)
kcc ack: UTF-8 not supported (in Description)

Both kcc and ack maintainers are not active these dya as I vaguely
recall.  (CCed) 

Regards,

Osamu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120304071629.GA5188@localhost