Bug#274514: Debian transition to Aspell 0.60
On Fri, Jan 21, 2005 at 01:40:47AM -0800, Brian Nelson wrote:
> You may find the new aspell packages available at:
>
> http://people.debian.org/~pyro/pending/
>
> Please test building dictionaries with the new packages and let me know
> if you have any problems. Also, if you find any flaws in my proposal,
> please let me know.
>
(Note, I am bcc'ing aspell dicts maintainers rather than cc'ing them, alioth
do not like long cc lines and your first mail did not get archived. Sorry
those that receive this mail twice. Not {b}cc'ing the aspell depending
pakages)
Please find updated aspell-gl-minimos packages in
http://dict-common.alioth.debian.org/aspell6/
(with parts in the sources subdir). It is built using affix compression
(7,3M -> 363k). Since this might be of help to others I am giving some info
about the required steps, xx stands for the two letter code of your
language (e.g. en), or for the two letters code + variant (e.g. gl-minimos
in my package)
I find this very interesting when all dicts are built from the same source,
or can be done this way.
** Building the hash:
You need to adapt the xx.dat file with the affix info, e.g.
# --- .dat file
# xx data file
name xx
charsetiso8859-1
soundslike xx
affix xx
affix-compress true
# --
The last two lines are the important ones to add.
You need to have the myspell affix file (e.g. xx_XX.aff), although aspell
will expect it as xx_affix.dat (a symlink should suffice for hash
building).
You also need the munched wordlist in the ispell format (myspell one simply
has an extra leading line with the number of roots for parsing speedup). If
you only have the myspell dict, something like
cat xx_XX.mydict | sed '1d' | aspell create .. options ..
should help, but you can use directly the ispell munchlist if you have it
without stripping the first line,
cat languagexx.ispelmunchlist | aspell create .. options ..
** Installing everything
Besides the usual files, remember to install xx_affix.dat (with that name)
in /usr/lib/aspell-0.60 (Remember that /usr/share/aspell seems no longer used
by dicts, and that you must install now in /usr/lib/aspell-0.60 rather than
in /usr/lib/aspell)
> I'm going on a pseudo-vacation for the next two weeks and would really
> like to upload the new packages when I return. I'd appreciate it if
> someone would setup a staging area to collect all of the newly built
> dictionaries so that they can all be uploaded together. Please
> coordinate on the [EMAIL PROTECTED] mailing list,
> unless of course Agustin objects. ;)
>
No objection at all, of course.
Some other remarks for aspell dicts.
Please register your aspell dict for use in emacs, look at
http://dict-common.alioth.debian.org/dsdt-policy.html#aspell-registration
You do not need to add all the entries the equivalent ispell dict has, just
the ones that are relevant to aspell (e.g., no need to add most of the tex
variants).
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343443: linux-image-2.6.14-2-k7: Doesn't boot: /sys/block/hde/dev not found
severity 343443 critical merge 343048 343443 thanks On Thu, Dec 15, 2005 at 11:36:07PM +1300, Srdjan wrote: > Package: linux-image-2.6.14-2-k7 > Version: 2.6.14-5 > Severity: grave > Justification: renders package unusable > > After upgrade doesn't boot, cannot cat /sys/block/hde/dev Already reported against linux-2.6 source package as [#343048] linux-image-2.6.14-2-686: ide fails to initialize, fails to boot and against yaird package as [#343042] linux-image-2.6.14-2-686: Boot aborts with message '/bin/cat: /sys/block/hda/hda1/dev: No such file or directory' [#343280] linux-image-2.6.14-2-k7: Will not boot due to block device error Adjusting severity and merging linux-2.6 bug reports. Please look at #343048 and #343042 bugreports for more detailed information about the problem. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306604: Bug#337687: Spell checking accented characters in emacs with american dictionary
retitle 337687 Please improve README.emacs for ispell+accented characters
customized entries
thanks
On Sat, Nov 05, 2005 at 08:24:04PM +0100, Norbert Preining wrote:
> I am having a hard time to get ispell in emacs to check words containing
> umlauts and accented characters.
>
> I tried the following (according to README.emacs):
>
> I added a new dictionary entry to ispell-local-dictionary-alist using
> customize:
>
> (custom-set-variables
> '(ispell-local-dictionary-alist
> (quote (("american8" "[A-ZÄÖÜäöüß]" "[^A-ZÄÖÜäöüß]" "[']" nil
> ("-B" "-d" "american") "~latin1" iso-8859-1)
>
> (Besides this my test .emacs is empty!)
>
> Which I though should work.
>
> Then I selected the american8 dictionary and wanted to check
> Gödel
> and got
> "Ispell and its process have different character maps."
>
> How can I get ispell/emacs to check this correctly?
Hi, Norbert and David
I am afraid that is a limitation of current Debian ispell,
---
$ echo "Gödel" > test.data
$ cat test.data | ispell -l -d american
del
---
That is what triggers the error message, and will happen when a word with
characters not in ispell declared chars (in the aff file) is spellchecked. If
the offending char is not in the Casechars/Not-Casechars sections for
ispell.el will be treated as a boundary char and there will be no
complain about that (although sometimes might derive in misalignment
errors).
The example in README.emacs was originally for aspell (and arised after
#299725), although unfortunately I did not explicitely mention that. I
will add specific info about that.
The proper fix would be to update ispell to the most recent version, whose
american dict allows in its aff file much more 8 bit characters, but that is
definitely an ispell issue. The presence of a newer ispell has already been
reported (#306604), so I am sending a followup there. I will close the
dictionaries-common part of this bug report once I improve documentation.
I am not cloning it and merging with #306604, but feel free to do that
by yourself.
--
Agustin
Bug#306604: Bug#337687: Spell checking accented characters in emacs with american dictionary
On Mon, Nov 07, 2005 at 02:30:26AM +0100, Norbert Preining wrote:
> On Son, 06 Nov 2005, Agustin Martin wrote:
> > I am afraid that is a limitation of current Debian ispell,
> >
> > ---
> > $ echo "Gödel" > test.data
> > $ cat test.data | ispell -l -d american
> > del
> > ---
> >
> > That is what triggers the error message, and will happen when a word with
> > characters not in ispell declared chars (in the aff file) is spellchecked.
> > If
>
> Ah. Thanks. Well, but then, this could easily be solved:
>
> Add (also to the README) a comment about adding
> -w "öÖäÄüÜß"
> to the cmdline of ispell and it works.
>
> My .emacs now contains:
> (custom-set-variables
> '(ispell-local-dictionary-alist (quote (("american8" "[A-ZÄÖÜäöüß]"
> "[^A-ZÄÖÜäöüß]" "[']" nil
> ("-B" "-d" "american" "-w" "öÖäÄüÜß") "~latin1" iso-8859-1)
>
> which works perfectly also with files containing "Gödel".
Fine, thanks for the suggestion. And even better, octal codes seem to work
too (avoiding things be accidentally saved as utf-8) and to make things even
better aspell does not (currently) complain about the -w option.
> I would say that a slight adjustment in the README should be
> enough to close the bug.
Committed to our CVS, will go in next upload.
Thanks a lot for your feedback
--
Agustin
Bug#306604: Bug#337687: Spell checking accented characters in emacs with american dictionary
On Tue, Nov 08, 2005 at 02:03:34AM +0100, Norbert Preining wrote:
> Hi Agustin!
>
> On Die, 08 Nov 2005, Agustin Martin wrote:
> > > My .emacs now contains:
> > > (custom-set-variables
> > > '(ispell-local-dictionary-alist (quote (("american8" "[A-ZÄÖÜäöüß]"
> > > "[^A-ZÄÖÜäöüß]" "[']" nil
> > > ("-B" "-d" "american" "-w" "öÖäÄüÜß") "~latin1" iso-8859-1)
> > >
> > > which works perfectly also with files containing "Gödel".
> >
> > Fine, thanks for the suggestion. And even better, octal codes seem to work
> > too (avoiding things be accidentally saved as utf-8) and to make things even
>
> Idea: Would it be possible to use the regexp teaching emacs additional
> word boundary chars (in my case the "[A-ZÄÖÜäöüß]") to automatically
> create the -w option?
>
> I guess, if you tell emacs that these chars are word components, ispell
> should also (automatically) know about it.
>
> The problem of course is that the one thing is an regexp, while the
> other is just a char list. But for many cases this could be done.
The problem, as you point out, is that can contain regexps that are not the
trivial A-Za-z that can easily be stripped (by the way, is a-z not missed in
your example?).
Another possibility I am thinking about is to do that in a per-encoding
basis, that is, with a list containing elements like
("iso-8859-1" . "àáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ")
so if ispell is used with an iso-8859-1 dict, that long string would be
passed to ispell -w
--
Agustin
Bug#337687: Spell checking accented characters in emacs with american dictionary
On Tue, Nov 08, 2005 at 02:37:46PM +0100, Norbert Preining wrote:
> On Die, 08 Nov 2005, Agustin Martin wrote:
> > trivial A-Za-z that can easily be stripped (by the way, is a-z not missed in
> > your example?).
>
> Thanks.
>
> > Another possibility I am thinking about is to do that in a per-encoding
> > basis, that is, with a list containing elements like
> >
> > ("iso-8859-1" .
> > "àáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ")
>
> Don't you miss
> ß
> here? Only in case you work with cut and paste ;-)
Yes, thanks. I took the string from a lower-to-upper-case code in
ispellaff2myspell, so ß was missing.
I still have to take a look about how things work in emacs-cvs ispell.el, to
make changes as forward compatibles as possible, but at least with the
current code, seems this can be easily implemented.
--
Agustin
Bug#337687: Spell checking accented characters in emacs with american dictionary
On Tue, Nov 08, 2005 at 12:59:38PM +0100, Norbert Preining wrote:
> On Die, 08 Nov 2005, Agustin Martin wrote:
> > Another possibility I am thinking about is to do that in a per-encoding
> > basis, that is, with a list containing elements like
> >
> > ("iso-8859-1" .
> > "àáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ")
>
> Or based on the encoding of the visited file? Can this be adjusted
> dynamically?
In most cases (not for xemacs21-nomule) ispell.el handle this change internally.
In some languages and encodings mule-ucs is needed, but that is all.
--
Agustin
Bug#335612: debconf question asked on every upgrade
tag 335612 +unreproducible thanks On Tue, Oct 25, 2005 at 01:07:41PM +0200, Agustin Martin wrote: > Hello, Artur > > I cannot reproduce that here. Your desired behavior is what I get here > and what current code should do. ... > Can you please run something like > > # LANG=C DEBCONF_DEBUG=developer apt-get install --reinstall ipolish > > and send the transcript to the bug page? Since I received no more feedback on this in 15 days, I am tagging this bug report as unreproducible. This way other users might want to try it and also report feedback if possible. Note that this problem should strike a lot of people, so if in a reasonable time (say about 2 months) I receive no further feedback on this problem I will consider closing this bug report. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#338454: dictionaries-common-dev belongs in section devel, not text
On Thu, Nov 10, 2005 at 12:14:12PM +0100, Jonas Smedegaard wrote: > Package: dictionaries-common-dev > Version: 0.62.3 > Severity: normal > > As subject says, I believe dictionaries-common-dev belongs in section > devel, not section text. Agreed, Fixed in CVS, will go in next upload. Thanks for pointing out this. -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335612: debconf question asked on every upgrade
On Fri, Nov 11, 2005 at 04:16:09PM +0100, Artur R. Czechowski wrote:
> Hello,
>
> I'm sorry for the delay in reply.
No problem, thanks for the info
> Preconfiguring packages ...
> debconf (developer): starting /tmp/ipolish.config.40471 configure 20051023-1
> debconf (developer): <-- VERSION 2.0
> debconf (developer): --> 0 2.0
> debconf (developer): <-- METAGET shared/packages-ispell owners
> debconf (developer): --> 0 iamerican, ibritish, ipolish
> debconf (developer): <-- METAGET iamerican/languages default
> debconf (developer): --> 0
> debconf (developer): <-- METAGET ibritish/languages default
> debconf (developer): --> 0
> debconf (developer): <-- METAGET ipolish/languages default
> debconf (developer): --> 0 polish (Polish)
> debconf (developer): <-- METAGET dictionaries-common/default-ispell choices
> debconf (developer): --> 0 polish (Polish), Manual symlinks setting
Here is a problem, you are not getting default value for either
iamerican/languages or ibritish/languages, should read
debconf (developer): <-- METAGET shared/packages-ispell owners
debconf (developer): --> 0 iamerican, ibritish, ipolish
debconf (developer): <-- METAGET iamerican/languages default
debconf (developer): --> 0 american (American English)
debconf (developer): <-- METAGET ibritish/languages default
debconf (developer): --> 0 british (British English)
debconf (developer): <-- METAGET ipolish/languages default
debconf (developer): --> 0 polish (Polish)
debconf (developer): <-- METAGET dictionaries-common/default-ispell choices
debconf (developer): --> 0 american (American English), british (British
English), polish (Polish), Manual symlinks setting
Have you recently experienced problems with your /var partition? I mean
something like it being nearly full.
Please take a look at your /var/cache/debconf/templates.dat file, iamerican
and ibritish entries should look something like
Name: iamerican/languages
Default: american (American English)
Description:
Type: text
Owners: iamerican/languages
Name: ibritish/languages
Default: british (British English)
Description:
Type: text
Owners: ibritish/languages
after the corresponding values in
/var/lib/dpkg/info/i{american,british}.templates
If the above templates.dat entries are not present or look strange, but the
correct templates files are in the /var/lib/dpkg/info your debconf database
is probably corrupt. If so, please read
/usr/share/doc/dictionaries-common/README.problems and try to reinstall
again ipolish after having fixed the database.
> debconf (developer): <-- INPUT critical dictionaries-common/default-ispell
> debconf (developer): --> 30 question skipped
> debconf (developer): <-- TITLE Dictionaries-common: Ispell dictionary
> debconf (developer): --> 0
> debconf (developer): <-- GO
> debconf (developer): --> 0 ok
Seems that this time question was not asked, but the above problem remains.
Let me know what happens.
Thanks for your feedback
[PS: No need to mail me directly, just reply to the bug address, I will receive
it]
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344636: [INTL:el] Greek language update
On Sat, Dec 24, 2005 at 12:11:50PM +0200, Konstantinos Margaritis wrote: > Package: dictionaries-common > Version: 0.63.2 > Severity: minor > Tags: patch l10n > > Please included Greek language update (done by Emmanuel Galatoulas). Committed to our CVS, will go in next upload Thanks for the update -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#336735: please remove Emacs cruft from dictionaries-common.NEWS
On Tue, Nov 01, 2005 at 07:04:49AM +, Martin Michlmayr wrote: > Package: dictionaries-common > Version: 0.62.0 > Severity: minor > > I just made a dist-upgrade and in the news sent to me by > apt-listchanges, the formating was broken because of the Emacs stuff > included in dictionaries-common.NEWS. > > Can you please remove this? I don't use Emacs myself but I've been > told that it automatically recognizes debian/changelog these days. If > it doesn't recognize debian/*NEWS, pleases file a bug on Emacs or > change your configuration. Thanks. Committed to our CVS. Will go in next upload. The only thing that might be useful there is the coding, but since I would like to avoid non 7bit chars in NEWS, that should not be relevant. > Local Variables: > mode: debian-changelog > coding: utf-8 > End:spamassassin (3.1.0a-1) unstable; urgency=low By the way, seems that what is really breaking formatting is the lack of a newline in dictionaries-common.NEWS. Anyway, since the emacs stuff is currently not needed, I am removing it. Thanks for your feedback, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337214: dictionaries-common: Problem with the character ??
reassign 337214 ifrench-gut
retitle 337214 ifrench-gut: problem with oe as single char
thanks
On Thu, Nov 03, 2005 at 10:53:03AM +0100, Prakash Countcham wrote:
> Package: dictionaries-common
> Version: 0.62.1
> Severity: normal
>
> Hi,
>
> I have already sent this bug report a few days ago, but as I cannot find
> it, I resend it. So, sorry for duplicates.
>
> I have got problems when checking spells of words containing the letter
> ? in Emacs (both emacs21 and emacs-snapshot).
> Here is an example:
> 1 - I start Emacs with emacs -q
> 2 - In the *scratch* buffer, I type neud
> 3 - I check its spell with M-$
> 4 - The choice numered 1 is n[1/2]ud instead of n?ud ([1/2] is a single
> character).
This seems to be ifrench-gut responsability. I have tried with the other
ispell french dict (The Hydro-Quebec version) which seems to suffer the
same problem, so what I did should apply to ifrench-gut as well.
I have rebuilt the package with a new explicit latin0 entry that includes
the oe OE single chars inCasechars/Non-casechars and declares the dict as
iso-8859-15 and seems to work here (I cannot see it properly, because one
font seems to be missing in emacs). Before doing those changes I also
found that problem.
Note that this will not work for emacs-snapshot, that is not affected by the
dictionaries-common policy, nor with aspell-fr that is iso-8859-1.
Regarding other french dicts, aspell-fr seems to use "oe" as a two char
sequence, thus defaulting to iso-8859-1, while ifrench* variants use it
as a single char one (iso-8859-15), but are declared as iso-8859-1, a
bit confusing. This is why I added a new name, so the old behavior is
similar for both ispell and aspell.
> * dictionaries-common/default-ispell: francais GUTenberg (French GUTenberg)
I am thus reassigning this bug report to ifrench-gut, so Nicolas Sabouret
can decide what to do here. I am attaching a diff with the changes I
tested. I am not sure if adding that new entry is really desirable.
Thanks for your info
--
Agustin
diff -u ifrench-1.4/debian/changelog ifrench-1.4/debian/changelog
--- ifrench-1.4/debian/changelog
+++ ifrench-1.4/debian/changelog
@@ -1,3 +1,12 @@
+ifrench (1.4-19really20.0.1) unstable; urgency=low
+
+ * debian/info-ispell:
+- Removed obsolete pspell entry
+- New latin0 entry with 'Å' and 'Å' added to {Not-,}Casechars,
+ declared explicitely as iso-8859-15
+
+ -- Agustin Martin Domingo <[EMAIL PROTECTED]> Thu, 3 Nov 2005 17:29:55 +0100
+
ifrench (1.4-20) unstable; urgency=low
* Changed priority to optional
diff -u ifrench-1.4/debian/info-ispell ifrench-1.4/debian/info-ispell
--- ifrench-1.4/debian/info-ispell
+++ ifrench-1.4/debian/info-ispell
@@ -1,3 +1,16 @@
+Language: francais0 Hydro-Quebec (French Hydro-Quebec latin0)
+Hash-Name: francais
+Emacsen-Name: francais0
+Debconf-Display: no
+Casechars: [A-Za-zÀÂÇÈÉÊËÎÏÔÙÛܼàâçèéêëîïôùûü½]
+Not-Casechars: [^A-Za-zÀÂÇÈÉÊËÎÏÔÙÛܼàâçèéêëîïôùûü½]
+Otherchars: [-']
+Many-Otherchars: yes
+Additionalchars: ÀÂÇÈÉÊËÎÏÔÙÛܼàâçèéêëîïôùûü½
+Ispell-Args:
+Extended-Character-Mode: ~list
+Coding-System: iso-8859-15
+
Language: francais Hydro-Quebec (French Hydro-Quebec)
Hash-Name: francais
Emacsen-Name: francais
@@ -10,3 +23,2 @@
-Extended-Character-Mode: ~list
+Extended-Character-Mode: ~latin1
Coding-System: iso-8859-1
-Pspell-Ispell: fr iso8859-1
Bug#337214: dictionaries-common: Problem with the character ??
On Thu, Nov 03, 2005 at 05:41:22PM +0100, Agustin Martin wrote:
> I am thus reassigning this bug report to ifrench-gut, so Nicolas Sabouret
> can decide what to do here. I am attaching a diff with the changes I
> tested. I am not sure if adding that new entry is really desirable.
Forgot to mention that you can add a local entry in your ~/.emacs file having
that behavior, something like
(setq ispell-local-dictionary-alist
(append ispell-local-dictionary-alist
'(("francais0" ; French latin0
"[A-Za-zÀÂÇÈÉÊËÎÏÔÙÛܼàâçèéêëîïôùûü½]"
"[^A-Za-zÀÂÇÈÉÊËÎÏÔÙÛܼàâçèéêëîïôùûü½]"
"[-']"
t
("-d" "francais")
"~list"
iso-8859-15
so you can test if this works as expected or not. This should work for
emacs-snapshot too.
This might be added to the ifrench{-gut} README, until is decided if all
french ispell and aspell dicts should be standarized to have similar
behavior.
--
Agustin
Bug#337214: dictionaries-common: Problem with the character ??
On Thu, Nov 03, 2005 at 06:08:32PM +0100, Agustin Martin wrote: > Forgot to mention that you can add a local entry in your ~/.emacs file having > that behavior, something like > > (setq ispell-local-dictionary-alist Will work with emacs-snapshot. Not yet with emacs, there was a bug in dictionaries-common ispell.el about that. Just uploaded a fix. -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#337214: dictionaries-common: Problem with the character ??
On Fri, Nov 04, 2005 at 12:34:13PM +0100, Prakash Countcham wrote:
> Agustin Martin <[EMAIL PROTECTED]> writes:
> > (setq ispell-local-dictionary-alist
> > (append ispell-local-dictionary-alist
> > '(("francais0" ; French latin0
> Thanks for the tip. I have tried something similar without success.
That should work now, but until yesterday's dictionaries-common upload there
was a bug still pending. Fixed version (0.62.2) should be today in mirrors.
> Is there a simple way to override the default dictionary?
Just naming the entry as francais instead of francais0 should work,
(setq ispell-local-dictionary-alist
(append ispell-local-dictionary-alist
; '(("francais0" ; French latin0 explicit
'(("francais" ; French latin0 override
"[A-Za-zÀÂÇÈÉÊËÎÏÔÙÛܼàâçèéêëîïôùûü½]"
"[^A-Za-zÀÂÇÈÉÊËÎÏÔÙÛܼàâçèéêëîïôùûü½]"
"[-']"
t
("-d" "francais")
"~list"
iso-8859-15
(Much better with the octal codes instead of the explicit 8bit chars)
[Since this might be of more general interest interest for ifrench{,-gut}
users I am also mailing the bug address]
--
Agustin
Bug#140017: emacs21: First call to ispell process reports some errors
On Tue, Mar 26, 2002 at 04:59:52PM +0100, matousek wrote:
> Package: emacs21
> Version: 21.1-7
> Severity: normal
>
> Hello,
>
> whenever I enter any of the ispell modes for the first time in an emacs
> session, the following error messages appears and nothing happends:
>
> Word 'císa?ové' contains illegal characters
>
> Word 'centralistického' contains illegal characters
>
> Word 'centralistické' contains illegal characters
>
> Word 'braniborských' contains illegal characters
>
> Word 'bohoslu?ebních' contains illegal characters
>
> Word 'bavívali' contains illegal characters
>
> Word 'baráky' contains illegal characters
>
> Word 'areálu' contains illegal characters
>
> Word 'Arelát' contains illegal characters
>
> When I run the ispell again, it works fine. For me, it looks like a bug
> in one of dictionaries, but the default dictionary is set to british
> (not czech). My charset is set to iso-8859-2, but some characters
> doesn't display correctly in the
> error message, so it can also be a bug related with dictionary encoding
> - some rules misencoded... Or?
Hi,
I am reviewing spellchecking related {x}emacs bugs.
Is this bug still present?
If so, please provide a detailed guide to reproduce it, so we can understand
what is happening.
Thanks for your feedback
--
Agustin
Bug#208642: #208642 flyspell don't like walking on words with accentued letters
On Thu, Sep 11, 2003 at 06:07:46PM +0200, Martin Quinson wrote: > Hello, > > I double checked, and the issue seem to come to the fact that when I type a é > using iso-accents-mode, I get the char that [C-x =] repports as (04351, 2281, > 0x8e9, file E9). When I save the buffer and reopen it, the char is changed to > (07551, 3945, 0xf69, file E9). > > I have no idea of where it comes from, and why the flyspell-buffer is happy > with that char when walking on the word with flyspell is not ok. > Hi, Martin New ispell.el being shipped with dictionaries-common contains some code from emacs-cvs that should take care of some of these encoding problems. Since it is already in sarge, can you please check if this is still an issue for sarge? Thanks for your feedback -- Agustin
Bug#177004: xemacs21: Xemacs/ispell - can't check cyrillic documents (koi8-r)
On Thu, Jan 16, 2003 at 06:05:13PM +0300, Dmitry Tsitelov wrote: > Package: xemacs21 > Version: 21.4.11-1 > Severity: normal > > Hello! > > After one of xemacs21-* upgrades (unfortunately, I didn't track which one) > xemacs's ispell interface (ispell-buffer function, for example) stoped > checking cyrillic documents (koi8-r encoding). > > Any attempt to spell-check russian document produces message: > "No such coding system: koi8-r" > > Brief investigation showed, that problem occurs in decode-coding-string > call. > Can you please check if this is still an issue? sarge is now released and a lot of things are changed there. Thanks for your feedback, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#149127: upper case Umlauts at beginning of word don't work with flyspell
On Wed, Jun 05, 2002 at 05:50:02PM +0200, Erik Thiele wrote:
> Package: xemacs21
> Version: 21.4.8-1
>
Hi all,
I am reviewing the spellcheck related {x}emacs bugs,
> start xemacs.
> open a new file foobar.tex
> you will be in "LaTeX" mode.
> type M-x ispell-change-dictionary
> type ndeutsch8
> type M-x flyspell
> to enter flyspell mode.
>
> Enter the german word
> "äußerst". it will be black which means all is ok with that word.
> enter "kjshdf" to see it marked red.
>
> ok now try:
>
> "änderung"
>
> it will be yellow which means a slight error in the word. use the
> second mouse button to get "Änderung" as a proposal, which is correct,
> since one must write this word in upper case. choose that alternative.
> now you will see "Änderung" as expected, but the "Ä" is black, the
> rest is red. the "Ä" at the beginning of the word is not considered a
> part of the word.
That seems an encoding problem, where Ä is internally differently in xemacs
until the file is saved (lack of latin fonts unification). There have been a
lot of woody->sarge changes in both xemacs and ispell.el (now provided by
dictionaries-common package), so please check if that problem still holds.
I remember some possibly related problems appearing when LANG was an euro
variant (iso-8859-15), because the same char was considered internally
different if iso-8859-1 or iso-8859-15, so if you write as iso-8859-15 and
flyspell returns the corrected char as iso-8859-1, they are internally
considered as different, even being the same char. If that is the reason,
if you save that file, reopen it, and spellcheck it, Ä should be
spellchecked O.K.
I have tried to reproduce it, but everything seems to be working here,
änderung
Änderung
dfsdfs
äußerst
flyspell-buffer only tags "änderung" and "dfsdfs" as mispelled. Please
confirm if that is the same at your site and we can close this bug
report.
Thanks for your feedback,
Cheers,
--
Agustin
Bug#313525: INTL:vi
tag 313525 +pending thanks On Tue, Jun 14, 2005 at 03:51:31PM +0930, Clytie Siddall wrote: > Package: dictionaries-common > Version: 0.30.0 > Severity: minor > Tags: l10n, patch > > The Vietnamese translation for debconf: dictionaries-common > > translated and submitted by: > > Clytie Siddall, Vietnamese localization team / nhóm Vi???t hóa Thanks for your contribution. Committed to our CVS, will go in next release. Cheers, -- Agustin
Bug#208642: #208642 flyspell don't like walking on words with accentued letters
On Fri, Jun 10, 2005 at 09:27:00PM +0200, Martin Quinson wrote: > On Thu, Jun 09, 2005 at 02:59:36PM +0200, Agustin Martin wrote: > > New ispell.el being shipped with dictionaries-common contains some code from > > emacs-cvs that should take care of some of these encoding problems. > > > > Since it is already in sarge, can you please check if this is still an issue > > for sarge? > > Yes, flyspell works again for me. But only if I ispell-change-dictionnary to > something else and then back to my default setting (french). No idea why, > and a bit annoying, but ways better than the previous situation, thanks. > Thanks for the feedback, Martin My guess is that it selects american when loading flyspell.el (#261669) or entering flyspell mode. One of the things I have pending in dictionaries-common is to integrate flyspell.el, so a recent flyspell.el is used and is integrated into the spellchecking system. I still have to decide if latest upstream (1.7i) is mature enough and is working properly. Since flyspell.el is not yet part of the dictionaries-common system I am leaving this bug report open and belonging to emacs21. Once I integrate flyspell.el into the system I will close this bug report. I will let you know when I have something more ellaborated in case you want to test it before. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Tue, May 24, 2005 at 03:13:41PM +0200, Matthias Klose wrote: > Package: aspell > > Many aspell dictionaries depend on the libaspell15 package. with the > next soversion (or the coming C++ ABI change), the package name has to > be changed, as well as other 24 dictionary packages. That's just a > maintainance burden. Package dictionaries may depend on aspell (>= > 0.60) instead, but you may argue, that the aspell binary isn't > necessarily needed. Proposing: > > - a new libaspell package, which depends on the current libaspell15 > package (a provides is not enough, because dictionaries have to > depend on an version, and versioned provides don't yet exist) > > - alternatively dictionary packages should depend on aspell. > > - a short paragraph in README.Debian as a mini policy. > Hi, Matthias and Brian Just to note that after Brian suggestion, one of the things that are waiting in dictionaries-common for sarge release is aspell-autobuidhash, allowing the binary hashes being built from dict postinst. This is still very experimental, and would require for dicts using it that not only libaspellxx is installed but also aspell-bin, but should make dependencies simpler for those dicts, since the dependency would be on aspell-bin, which is synced to the appropriate libaspellxx because it depends on it. This has the advantage that dicts will be arch: all packages, because endianess would be dealt with at hash building (our mirrors will be happy). The drawback is that aspell-bin is required, that more space is used in the system and that for slow systems the on-the-fly build might not be as fast as expected (aspell efficiency on this is much higher now, so this might no longer be a problem, but is still to be tested with aspell-0.60) Apps using aspell should depend on the libaspellxx they are linked to, as currently. [No need to cc me, I am subscribed to aspell PTS] Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Wed, May 25, 2005 at 12:26:45AM -0700, Brian Nelson wrote: > Agustin: What's the status of aspell-autobuildhash? I'd like to start > seriously testing it very soon, within the next couple of weeks, so that > we can start transitioning the dictionary packages as soon as sarge > releases. I left it in the background some time ago, before aspell-0.60 Debian packages were uploaded, because I wanted to make sure that it worked with aspell-0.60. But once it was uploaded I was busy with other things, so did not work further on this. Sarge freeze for standard packages was an aditional reason for this (dictionaries-common is standard). However I (vaguely) remember it was in a resonable state for passing to wider testing and discuss details with you. It is currently in a dictionaries-common branch (aspell-autobuildhash) which is rather outdated wrt MAIN. Since my experience with aspell-0.60 and affix compression is possitive, I think that code should also work for it, so I expect everything can be arranged without much problem. I did put some experimental stuff at http://dict-common.alioth.debian.org/aspell-autobuildhash/ but I do not remember exactly its status, and I think was not tested for aspell-0.60. I am now syncing the aspell-autobuildhash branch to MAIN and will build new packages hopefully soon. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Tue, May 24, 2005 at 11:30:05PM +0200, Agustin Martin wrote: What is currently in http://dict-common.alioth.debian.org/aspell-autobuildhash is pretty old. It tried to keep different aspell variants coexisting. Do not try to test it, I wrote something newer and will put it there ASAP, for a single aspell version each time, much closer to the ispell implementation, but simpler. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310844: Fails with strings starting by \sp (e.g., \spanish, \special)
Package: ispell Version: 3.1.20.0-4 Severity: normal Hi, David and Geoff I have noticed a strange ispell behavior when strings starting by \sp are in the text, like in \spanish or \special, $ cat test.txt \special \spanish $ cat test.txt | ispell -l -d american ecial anish The same happens for $ ispell -d american test.txt On the contrary, aspell does the expected thing, $ cat test.txt | aspell list -d american spanish Other backslashed words seem to have no problem. This behavior is usually masked by the tex deformatter when file extension is .tex, but gives strange results when is not or when file is piped for use of the -l option, like in flyspell-large-region. I tested this originally in our rather old ispell (3.1.20). But the same problem is present in 3.3.01, $ ./test.sh #!/bin/sh -v WORDS="\special \spanish \exdfre" ./ispell -v | head -1 @(#) International Ispell Version 3.3.01 1 May 2005 echo $WORDS \special \spanish \exdfre echo $WORDS | ./ispell -l -d ./american ecial anish exdfre so I am (X-Debbugs-)cc'ing upstream for this. [Do not reply to me directly, I will read replies to the bug number address] -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1) Versions of packages ispell depends on: ii dictionaries-comm 0.25.12Common utilities for spelling dict ii iamerican [ispell 3.1.20.0-4 An American English dictionary for ... removed some other dicts ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libncurses5 5.4-4 Shared libraries for terminal hand -- no debconf information Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310844: Fails with strings starting by \sp (e.g., \spanish, \special)
On Thu, May 26, 2005 at 05:53:26PM +0200, Geoff Kuenning wrote: > > I have noticed a strange ispell behavior when strings starting by \sp are in > > the text, like in \spanish or \special, > > > > $ cat test.txt > > \special > > \spanish > > This is a feature, not a bug. > > By default, ispell uses the nroff deformatter. \sp is a control > sequence in nroff. (More accurately, \s where n is a number, is a > control sequence, but ispell's deformatter is a bit dumb about it.) > You'll find similar problems with \f and \(. > > If you want plain-text deformatting, ispell 3.3 offers the "-o" option > to do that. Thanks for the info, I found this thing when examining how flyspell-large-region works, piping the file to ispell -l +opts with no explicit deformatting options. I used the spanish tex FAQ (a large sgml file) for this and results did show those stripped strings. The "-o" ispell 3.3 option should take care of this, thanks. David, I think we can leave this bug open until ispell 3.3 is packaged for Debian and uploaded. Fortunately none of my dicts will be affected by this change (all use ispell-autobuildhash). Feel free to retitle and/or to adjust severity to minor or wishlist. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306604: Ispell 3.3.00 released
On Wed, Apr 27, 2005 at 12:48:26PM -0400, David Coe wrote: > Package: ispell > Version: 3.1.20.0-4 > Severity: wishlist > > Note to self: this release reportedly fixes lots of our > old bugs. I'll test when I can, and follow up on the > specific affected bug reports... And now even ispell 3.3.01 is available, good news. Before uploading to Debian we should make sure which changes are needed in the enchant package, that contains a librarized standalone ispell (does not use ispell through a pipe), so the new ispell dicts are usable for enchant. I am cc'ing enchant at p.d.o, so Masayuki Hatta is aware of this future change. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Wed, May 25, 2005 at 09:33:32PM +0200, Agustin Martin wrote: > What is currently in > > http://dict-common.alioth.debian.org/aspell-autobuildhash > > is pretty old. It tried to keep different aspell variants coexisting. Do not > try to test it, I wrote something newer and will put it there ASAP, for a > single aspell version each time, much closer to the ispell implementation, > but simpler. Hi, Brian I have put a more recent version of everything there. While still very experimental, seems to work. Includes a dictionaries-common package with aspell-autobuildhash and my ispell-gl package (giving aspell-gl-minimos) adapted for aspell-autobuildhash. I think that is a good example, since it uses affix compression, but the code should also work with a plain wordlist. Version numbers are smaller than current ones in unstable. aspell-gl-minimos experimental package will not work with unstable dictionaries-common (although I hope at least installation does not fail noisily), only with the experimental dictionaries-common with aspell-autobuildhash support. For the first tests aspell do not need anything special, but if this becomes more solid, code like if [ "$1" = "configure" ] ; then if [ -x /usr/sbin/aspell-autobuildhash ]; then aspell-autobuildhash fi fi should be added to aspell.postinst, as well as a compat string to file /usr/share/aspell/aspell.compat. The format for that string is something like 0.60_c1 where the substring before "_" will be added to /usr/lib/aspell- to know the datadir, and everything after will represent possible incompatibilities between 0.60 versions (not desirable, but who knows). If something in the string is changed dicts will be autorebuilt. Comments are welcome, Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#306604: [agustin.martin@hispalinux.es: Re: Bug#306604: Ispell 3.3.00 released]
Now really sending that to the enchant package, - Forwarded message from Agustin Martin <[EMAIL PROTECTED]> - X-Mozilla-Status: 0011 X-Mozilla-Status2: From: Agustin Martin <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Bug#306604: Ispell 3.3.00 released X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at hispalinux.es X-UIDL: meD"!&oS"!1a-"!6e$#! X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on mala.aq.upm.es X-Spam-Level: X-Spam-Status: No, score=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 On Wed, Apr 27, 2005 at 12:48:26PM -0400, David Coe wrote: > Package: ispell > Version: 3.1.20.0-4 > Severity: wishlist > > Note to self: this release reportedly fixes lots of our > old bugs. I'll test when I can, and follow up on the > specific affected bug reports... And now even ispell 3.3.01 is available, good news. Before uploading to Debian we should make sure which changes are needed in the enchant package, that contains a librarized standalone ispell (does not use ispell through a pipe), so the new ispell dicts are usable for enchant. I am cc'ing enchant at p.d.o, so Masayuki Hatta is aware of this future change. Cheers, -- Agustin - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Thu, May 26, 2005 at 07:22:32PM +0200, Agustin Martin wrote:
...
> should be added to aspell.postinst,
Typo:
s/aspell.postinst/aspell-bin.postinst/
> as well as a compat string to file
> /usr/share/aspell/aspell.compat. The format for that string is something
> like
>
> 0.60_c1
>
> where the substring before "_" will be added to /usr/lib/aspell- to know the
> datadir, and everything after will represent possible incompatibilities
> between 0.60 versions (not desirable, but who knows). If something in the
> string is changed dicts will be autorebuilt.
Just commenting that the effect of no compat string present is that dir
/usr/lib/aspell-0.60 will always be used, and that dicts will be rebuilt at
any aspell-bin re{installation,configuration}.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Tue, May 31, 2005 at 03:08:49PM +0200, Christoph Berg wrote: > Re: Agustin Martin in <[EMAIL PROTECTED]> > > Just to note that after Brian suggestion, one of the things that are waiting > > in dictionaries-common for sarge release is aspell-autobuidhash, allowing > > the > > binary hashes being built from dict postinst. This is still very > > experimental, and would require for dicts using it that not only libaspellxx > > is installed but also aspell-bin, but should make dependencies simpler for > > those dicts, since the dependency would be on aspell-bin, which is synced to > > the appropriate libaspellxx because it depends on it. > > > > This has the advantage that dicts will be arch: all packages, because > > endianess would be dealt with at hash building (our mirrors will be happy). > > The drawback is that aspell-bin is required, that more space is used in the > > system and that for slow systems the on-the-fly build might not be as fast > > as > > expected (aspell efficiency on this is much higher now, so this might no > > longer be a problem, but is still to be tested with aspell-0.60) > > Hi, > > the recently (6 weeks ago) added aspell-de-alt package builds the > hashes in the postinst. The packaging was trivial, and since noone > complained yet, I assume it works for users. (Of course I did > extensive install/remove tests myself before uploading.) Thanks for the info, That makes the mirrors happy because the aspell dict is now arch:all, but does not cause hashes being rebuilt if a new aspell with incompatible binary hash format is uploaded. That is what ispell-autobuildhash is currently doing and is what is expected from aspell-autobuildhash. There are some problems pending, like a /usr/lib/aspell-0.60 explicitely hardcoded path that will complicate a transition to e.g. 0.61, while everything would be simpler if a plain /usr/lib/aspell is used. These are the kind of things that are still to be considered. In my experimental dictionaries-common with aspell-autobuildhash support, things seems to be working pretty well, I tested things with my asspell galician dict, as well as with the catalan dict. This last is very important, since without affix compression the hash file reached over 100Mb (not a typo, we had to strip down the wordlist to have something of a reasonable size), so I expect that testing the system for that dict is a good measure about how realistic is the system. I have to say that worked pretty well, useable and with a 3.7Mb hash file (apart from a lot of error messages from the myspell aff file that were probably silent to myspell, but really noisy for aspell) Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311436: fp-compiler: Error installing package
On Wed, Jun 01, 2005 at 12:04:21AM -0300, Guilherme Mesquita Gondim (semente) wrote: > Package: fp-compiler > Version: 2.0.0-2 > Severity: grave > Justification: renders package unusable > Setting up fp-compiler (2.0.0-2) ... > update-alternatives: slave link name /usr/share/man/man1/pc.1.gz duplicated > dpkg: error processing fp-compiler (--configure): Reproduced, Carlos and Kenshi, the problem seems to be that the alternative is not removed from the prerm, so the postinst tries to set it again over an already existent alternative. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311436: fp-compiler: Error installing package
tag 311436 patch thanks On Wed, Jun 01, 2005 at 01:15:00PM +0200, Agustin Martin wrote: > On Wed, Jun 01, 2005 at 12:04:21AM -0300, Guilherme Mesquita Gondim (semente) > wrote: > > Package: fp-compiler > > Version: 2.0.0-2 > > Severity: grave > > Justification: renders package unusable > > > Setting up fp-compiler (2.0.0-2) ... > > update-alternatives: slave link name /usr/share/man/man1/pc.1.gz duplicated > > dpkg: error processing fp-compiler (--configure): > > Reproduced, > > Carlos and Kenshi, the problem seems to be that the alternative is not > removed from the prerm, so the postinst tries to set it again over an > already existent alternative. s/prerm/preinst/ Please consider the attached patch Cheers, -- Agustin diff -Naur fpc-2.0.0.carlos/debian/changelog fpc-2.0.0/debian/changelog --- fpc-2.0.0.carlos/debian/changelog 2005-06-01 13:37:06.0 +0200 +++ fpc-2.0.0/debian/changelog 2005-06-01 13:34:45.0 +0200 @@ -1,3 +1,12 @@ +fpc (2.0.0-2.1) unstable; urgency=high + + * debian/fp-compiler.preinst: +- New file. We need to remove /usr/bin/fpc as a pc alternative in the + preinst, so it can be recreated from the postinst without failing on + duplicated link error. Fixes RC-Bug (closes: #311436) + + -- + fpc (2.0.0-2) unstable; urgency=low * debian/fp-compiler.postinst.in: forgot to reapply the patch that diff -Naur fpc-2.0.0.carlos/debian/fp-compiler.preinst fpc-2.0.0/debian/fp-compiler.preinst --- fpc-2.0.0.carlos/debian/fp-compiler.preinst 1970-01-01 01:00:00.0 +0100 +++ fpc-2.0.0/debian/fp-compiler.preinst2005-06-01 13:30:41.0 +0200 @@ -0,0 +1,9 @@ +#! /bin/sh + +set -e + +# Remove fpc from pc alternative +/usr/sbin/update-alternatives --remove pc /usr/bin/fpc + +# Debhelper code +#DEBHELPER#
Bug#311436: fp-compiler: Error installing package
On Wed, Jun 01, 2005 at 10:54:22AM -0300, Carlos Laviola wrote: > 2005/6/1, Agustin Martin <[EMAIL PROTECTED]>: > > On Wed, Jun 01, 2005 at 12:04:21AM -0300, Guilherme Mesquita Gondim > > (semente) wrote: > > > Setting up fp-compiler (2.0.0-2) ... > > > update-alternatives: slave link name /usr/share/man/man1/pc.1.gz > > > duplicated > > > dpkg: error processing fp-compiler (--configure): > > > > Reproduced, > > > > Carlos and Kenshi, the problem seems to be that the alternative is not > > removed from the prerm, so the postinst tries to set it again over an > > already existent alternative. > > Yes, that's true. I have prepared a new package based on your patch > that also removes the link on prerm if it's not an upgrade. Hi, Carlos Putting the removal code only in prerm without extra checkings should suffice. I was confused and did in preinst, but prerm is the right place after policy manual, since it is run both in upgrades and in removals. I have been trying to check if the upgrade from the buggy package to a fixed one works with only the prerm change, or needs some ad-hoc stuff, but funnily I cannot reproduce the problem today. Reinstalling fp-compiler 2.0.0-2 over and over, which should have triggered this problem, is working well. Surprise... Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311436: fp-compiler: Error installing package
On Thu, Jun 02, 2005 at 12:01:06PM -0300, Carlos Laviola wrote:
> 2005/6/2, Agustin Martin <[EMAIL PROTECTED]>:
> > I have been trying to check if the upgrade from the buggy package to
> > a fixed one works with only the prerm change, or needs some ad-hoc
> > stuff, but funnily I cannot reproduce the problem today. Reinstalling
> > fp-compiler 2.0.0-2 over and over, which should have triggered this
> > problem, is working well. Surprise...
>
> It's probably because you've removed the duplicate alternative by
> hand. The problem was actually in 2.0.0-1; 2.0.0-2 mitigated it, but
> didn't fix the problem introduced by -1. If you want to test, test by
> going from -1 to -2 to your -2.1 or something.
You are right, I had a wrong idea of the bug reason, thought that what
failed was update-alternatives re-setting the same alternative without
previously removing it, but is that -1 with its fpc<->pc typo causes,
when upgraded, two different values for the slave corresponding to the
same master value.
FYI, I have tested with a homemade 2.2 just built with a
mv fp-compiler.preinst fp-compiler.prerm
from my previous -2.1 version, that is, without any preinst stuff.
Upgrading from -1 to -2.2 or from -1 -> -2 -> -2.2, I get for the first
run,
--
311436# LC_ALL=C dpkg -i fp-{compiler,units-rtl}_2.0.0-2.2_i386.deb
(Reading database ... 117165 files and directories currently installed.)
Preparing to replace fp-compiler 2.0.0-1.1 (using
fp-compiler_2.0.0-2.2_i386.deb) ...
Unpacking replacement fp-compiler ...
Preparing to replace fp-units-rtl 2.0.0-1.1 (using
fp-units-rtl_2.0.0-2.2_i386.deb) ...
Unpacking replacement fp-units-rtl ...
Setting up fp-units-rtl (2.0.0-2.2) ...
Setting up fp-compiler (2.0.0-2.2) ...
update-alternatives: slave link name /usr/share/man/man1/pc.1.gz duplicated
dpkg: error processing fp-compiler (--install):
subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
fp-compiler
---
But after an inmediate second run,
---
311436# LC_ALL=C dpkg -i fp-{compiler,units-rtl}_2.0.0-2.2_i386.deb
(Reading database ... 117165 files and directories currently installed.)
Preparing to replace fp-compiler 2.0.0-2.2 (using
fp-compiler_2.0.0-2.2_i386.deb) ...
Unpacking replacement fp-compiler ...
Preparing to replace fp-units-rtl 2.0.0-2.2 (using
fp-units-rtl_2.0.0-2.2_i386.deb) ...
Unpacking replacement fp-units-rtl ...
Setting up fp-units-rtl (2.0.0-2.2) ...
Setting up fp-compiler (2.0.0-2.2) ...
--
Seems that to make things really smooth something in the preinst is
needed in this case to work around the bug introduced in -1, just
reconfiguring after -2.2 does not help.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311436: fp-compiler: Error installing package
On Thu, Jun 02, 2005 at 03:08:04PM -0300, Carlos Laviola wrote:
> 2005/6/2, Agustin Martin <[EMAIL PROTECTED]>:
> > Seems that to make things really smooth something in the preinst is
> > needed in this case to work around the bug introduced in -1, just
> > reconfiguring after -2.2 does not help.
>
> This is weird. Here's what I get:
>
> [EMAIL PROTECTED]:~/debian$ sudo update-alternatives --display pc
> pc - status is auto.
> link currently points to /usr/bin/gpc
> /usr/bin/gpc - priority 20
> slave pc.1.gz: /usr/share/man/man1/gpc.1.gz
> Current `best' version is /usr/bin/gpc.
> [EMAIL PROTECTED]:~/debian$ sudo dpkg -i
> fp-{compiler,units-rtl}_2.0.0-1_i386.deb
...
> update-alternatives: slave link name /usr/share/man/man1/pc.1.gz duplicated
...
> [EMAIL PROTECTED]:~/debian$ sudo update-alternatives --display pc
> pc - status is auto.
> link currently points to /usr/bin/gpc
> /usr/bin/gpc - priority 20
> slave pc.1.gz: /usr/share/man/man1/gpc.1.gz
> /usr/bin/fpc - priority 20
> slave pc.1.gz: /usr/share/man/man1/fpc.1.gz
> Current `best' version is /usr/bin/gpc.
> [EMAIL PROTECTED]:~/debian$ sudo dpkg -i
> fp-{compiler,units-rtl}_2.0.0-2_i386.deb
...
> So installing -2 now works fine here without any manual intervention.
> I'm a bit puzzled.
Hi, Carlos,
I am now at home on dial-up with a woody box, so everything writen below
should not be taken very seriously, I am writing after what I remember from
this CET afternoon,
diffing fp-compiler.postinst-1 and fp-compiler.postinst-2 showed a typo
where pc was mistyped as fpc (or the opposite, but I think it was this way).
The problem you describe seems to appear when a new alternative having the
other string (the wrong one) is being installed against the other one
(having the right one), or the opposite, that is
fp-compiler -1 (bad string) -> -2 (good string) with no gpc installed
gpc(default) (good string) -> fp-compiler-1 (bad string)
shoud fail, but
gpc(default) (good string) -> fp-compiler-2 (good string)
should work, if gpc has the same string as fp-compiler-2, the right one (I
cannot check that now).
This is the only possibility that seems consistent to me, but I cannot
properly check. I will try to take a look at this tomowrrow in the morning
in a sid box.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311436: fp-compiler: Error installing package
On Fri, Jun 03, 2005 at 12:57:21AM +0200, Agustin Martin wrote: > Hi, Carlos, > > I am now at home on dial-up with a woody box, so everything writen below > should not be taken very seriously, I am writing after what I remember from > this CET afternoon, > > diffing fp-compiler.postinst-1 and fp-compiler.postinst-2 showed a typo > where pc was mistyped as fpc (or the opposite, but I think it was this way). yes, it was this way, the edited diff, --- fpc-2.0.0/debian/fp-compiler.postinst.in (2.0.0-1) +++ fpc-2.0.0.carlos/debian/fp-compiler.postinst.in(2.0.0-2) ---slave /usr/share/man/man1/pc.1.gz fpc.1.gz /usr/share/man/man1/fpc.1.gz +--slave /usr/share/man/man1/pc.1.gz pc.1.gz /usr/share/man/man1/fpc.1.gz and as expected gpc uses --slave /usr/share/man/man1/pc.1.gz pc.1.gz /usr/share/man/man1/gpc.1.gz with pc.1.gz as slave name > > The problem you describe seems to appear when a new alternative having the > other string (the wrong one) is being installed against the other one > (having the right one), or the opposite, that is > > fp-compiler -1 (bad string) -> -2 (good string) with no gpc installed fails (this was indeed #311436) > gpc(default) (good string) -> fp-compiler-1 (bad string) verified to fail > > shoud fail, but > > gpc(default) (good string) -> fp-compiler-2 (good string) > > should work, if gpc has the same string as fp-compiler-2, the right one (I > cannot check that now). verified to work > > This is the only possibility that seems consistent to me, but I cannot > properly check. I will try to take a look at this tomowrrow in the morning > in a sid box. > Seems clear now. > From your first mail: > > Yes, that's true. I have prepared a new package based on your patch > that also removes the link on prerm if it's not an upgrade. I thought better about this and you are right, conditionally removing the alternative from prerm only if not an upgrade, as gpc does, seems the right thing, removing it unconditionally might cause manual mode be lost or default changed (untested, but seems very possible). Regarding the alternative removal from preinst, I would keep it for some time, until the -1 -> -2+ mess is mostly addressed by users (say, at most 1-2 months), and then remove it. It is a bug that might cause manual mode be lost, but will make upgrades from -1 easier. Another possibility would be to check in preinst if old version to be upgraded is "2.0.0-1" and remove alternative only if so. This would be cleaner, but considering that none of -1 or -2 are going into sarge, that we are in unstable, and that we are at the beginning of the post-sarge stage, this is probably an overkill. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#311436: fp-compiler: Error installing package
On Fri, Jun 03, 2005 at 01:21:24PM +0200, Agustin Martin wrote: > Regarding the alternative removal from preinst, I would keep it for some > time, until the -1 -> -2+ mess is mostly addressed by users (say, at most > 1-2 months), and then remove it. It is a bug that might cause manual mode be > lost, but will make upgrades from -1 easier. Another possibility would be to > check in preinst if old version to be upgraded is "2.0.0-1" and remove > alternative only if so. This would be cleaner, but considering that none > of -1 or -2 are going into sarge, that we are in unstable, and that we are > at the beginning of the post-sarge stage, this is probably an overkill. > I have been playing with this last possibility, I expect something like the attached patch should do the work. I somewhat edited it before submission, so please check in your system that nothing is missed. Cheers, -- Agustin --- fpc-2.0.0.orig/debian/fp-compiler.preinst +++ fpc-2.0.0/debian/fp-compiler.preinst @@ -0,0 +1,12 @@ +#! /bin/sh + +set -e + +# Remove fpc from pc alternative if buggy 2.0.0-1 version is upgraded + +if [ "$1" = "upgrade" ] && [ "$2" = "2.0.0-1" ]; then +/usr/sbin/update-alternatives --remove pc /usr/bin/fpc +fi + +# Debhelper code +#DEBHELPER# --- fpc-2.0.0.orig/debian/fp-compiler.prerm +++ fpc-2.0.0/debian/fp-compiler.prerm @@ -0,0 +1,12 @@ +#! /bin/sh + +set -e + +# Remove fpc from pc alternative + +if [ "$1" != "upgrade" ]; then +/usr/sbin/update-alternatives --remove pc /usr/bin/fpc +fi + +# Debhelper code +#DEBHELPER#
Bug#304609: New patch for #304609, #303663 and #300989 (Was: Does not build when two dri...)
Hi again, Amaya Please take a look at the attached patch to lirc-modules-source Makefile. It applies to lirc (0.7.1pre2-6). It has some important changes with respect to the previous one: #303663 [lirc_sir.ko cannot be loaded, unknown symbols] #304609 [Does not build when two drivers requiring lirc_dev are selected] - lirc_dev target renamed to dev for consistency with the other targets having the dir name stripped of lirc_. Target dependencies adapted for this. - Adding lirc_it87 lirc_bt829 lirc_atiusb to the clean target - Includes a proposed fix for #303663, as previous patch did. #300989 [Does not Build the atiusb driver properly] * This bug is tagged as fixed, but I think should be reopened. Seems that there were errors when applying #300989 patch and there is some rubbish flying around in the Makefile, and some things only partially changed. I also have not clear why a double colon is used in the atiusb target, since no other similar target seems there. Removed the double colon, removed the rubbish, and changed as appropriate, adding lirc_atiusb to the clean target. and a couple of cosmetic changes. I could only check that builds, but do not have any lirc device here, so I could not make sure that the result really works. By the way seems that atiusb is not offered at the debconf prompt, is that intentional? Saludos, -- Agustin diff -Naur lirc-0.7.1pre2.amaya/debian/modules-source/Makefile lirc-0.7.1pre2/debian/modules-source/Makefile --- lirc-0.7.1pre2.amaya/debian/modules-source/Makefile 2005-04-15 12:41:28.768676000 +0200 +++ lirc-0.7.1pre2/debian/modules-source/Makefile 2005-04-15 12:43:20.581678184 +0200 @@ -83,50 +83,39 @@ exit 1;\ fi - atiusb:: modules sanity-check -- mv drivers/atiusb_i2c/lirc_atiusb.$(KEXT) modules -- @echo $(KVERS) $(KSRC) > modules/lirc_i2c.$(KEXT).KVERS -+ mv drivers/lirc_atiusb/lirc_atiusb.$(KEXT) modules -+ @echo $(KVERS) $(KSRC) > modules/lirc_atiusb.$(KEXT).KVERS - -atiusb:: modules sanity-check - $(MAKE) -e -C drivers SUBDIRS="lirc_atiusb lirc_dev" +dev: modules sanity-check + $(MAKE) -e -C drivers SUBDIRS="lirc_dev" mv drivers/lirc_dev/lirc_dev.$(KEXT) modules - mv drivers/atiusb_dev/lirc_dev.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_dev.$(KEXT).KVERS - mv drivers/atiusb_i2c/lirc_atiusb.$(KEXT) modules + +atiusb: modules sanity-check dev + $(MAKE) -e -C drivers SUBDIRS="lirc_atiusb" + mv drivers/lirc_atiusb/lirc_atiusb.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_atiusb.$(KEXT).KVERS -i2c: modules sanity-check - $(MAKE) -e -C drivers SUBDIRS="lirc_i2c lirc_dev" - mv drivers/lirc_dev/lirc_dev.$(KEXT) modules - @echo $(KVERS) $(KSRC) > modules/lirc_dev.$(KEXT).KVERS +i2c: modules sanity-check dev + $(MAKE) -e -C drivers SUBDIRS="lirc_i2c" mv drivers/lirc_i2c/lirc_i2c.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_i2c.$(KEXT).KVERS -gpio: modules sanity-check - $(MAKE) -e -C drivers SUBDIRS="lirc_gpio lirc_dev" - mv drivers/lirc_dev/lirc_dev.$(KEXT) modules - @echo $(KVERS) $(KSRC) > modules/lirc_dev.$(KEXT).KVERS +gpio: modules sanity-check dev + $(MAKE) -e -C drivers SUBDIRS="lirc_gpio" mv drivers/lirc_gpio/lirc_gpio.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_gpio.$(KEXT).KVERS it87: modules sanity-check $(MAKE) -e -C drivers SUBDIRS="lirc_it87" - @echo $(KVERS) $(KSRC) > modules/lirc_it87.o.KVERS mv drivers/lirc_it87/lirc_it87.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_it87.$(KEXT).KVERS - + bt829: modules sanity-check $(MAKE) -e -C drivers SUBDIRS="lirc_bt829" mv drivers/lirc_bt829/lirc_bt829.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_bt829.$(KEXT).KVERS - + serial: DEFS += $(SERIAL_CFLAGS) -serial: modules sanity-check - $(MAKE) -C drivers SUBDIRS="lirc_serial lirc_dev" DEFS="$(DEFS)" - mv drivers/lirc_dev/lirc_dev.$(KEXT) modules - @echo $(KVERS) $(KSRC) > modules/lirc_dev.$(KEXT).KVERS +serial: modules sanity-check dev + $(MAKE) -C drivers SUBDIRS="lirc_serial" DEFS="$(DEFS)" mv drivers/lirc_serial/lirc_serial.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_serial.$(KEXT).KVERS @@ -137,11 +126,11 @@ @echo $(KVERS) $(KSRC) > modules/lirc_parallel.$(KEXT).KVERS sir: DEFS += $(SIR_CFLAGS) -sir: modules sanity-check +sir: modules sanity-check dev $(MAKE) -C drivers SUBDIRS="lirc_sir" DEFS="$(DEFS)" mv drivers/lirc_sir/lirc_sir.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_sir.$(KEXT).KVERS - + install: @for file in modules/*.$(KEXT); \ do \ @@ -169,5 +158,5 @@ done clean: - $(MAKE) clean -C drivers SUBDIRS="lirc_seri
Bug#304388: lirc-modules-source: Does not compile: cut: modules/*.ko.KVERS: No such file or directory
On Fri, Apr 15, 2005 at 09:52:23PM +0200, Hadmut Danisch wrote: > > >Did you select any drivers? > > sure, the usb driver. That was not in the debconf entry I pointed out, I guess you added it (atiusb) manually, but unfortunately that entry is known to be buggy in the Makefile http://bugs.debian.org/300989 Can you please try the patch I proposed to lirc maintainers in that bug www page? That Makefile is what should go into /usr/src/modules/lirc/Makefile Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304609: New patch for #304609, #303663 and #300989 (Was: Does not build when two dri...)
On Fri, Apr 15, 2005 at 01:11:24PM +0200, Agustin Martin wrote: > Hi again, Amaya > > Please take a look at the attached patch to lirc-modules-source Makefile. It > applies to lirc (0.7.1pre2-6). > ... > and a couple of cosmetic changes. I could only check that builds, but do not > have any lirc device here, so I could not make sure that the result really > works. Tested with a kworld card (uses lirc_gpio). Working properly. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304819: spca5xx -- Device driver for USB webcams based on the spca5xx chips
On Wed, Apr 20, 2005 at 05:57:02PM -0700, Jeff Carr wrote: > Jurij Smakov wrote: > > >Since it is becoming more and more a kernel topic, you might also want > >to move discussion to debian-kernel. > > Could someone give us a simple rundown of how we would submit a patch to > the debian kernel sources to add spca5xx support? The spca5xx driver > adds support for a large number of USB cameras. Recently Carlos posted > something about adding support to debian-devel and Jurij suggested we go > here as it is a kernel issue. Since you contacted the spca5xx developer, and he didn't seem to care about putting that driver into the main kernel, I do not see the point in trying to bypass him for that, even for the Debian kernel. Also I see that the original ITP is from Stephen Birch, please coordinate your steps with him. I would also keep [EMAIL PROTECTED] cc'ed for the records in that wnpp bug entry. As Jurij sugested I would go first for a spca5xx-modules-source package, so users can build spca5xx-modules packages for the kernel they want, by means of make-kpkg or directly. A patch package would require rebuilding the whole kernel, what is usually not desirable, unless some of the kernel files are being modified. In most cases a modules package can be built out of the modules-source package just having the appropriate kernel sources package installed. > The module dir is self contained and "smart" in that it uses `uname -r` > to determine the kernel headers. So, one can just go into the dir and > type make;make install and spca5xx.ko will automatically be loaded the > next time the user boots. And if you want to build the modules for a different kernel? That said, I have one of these sunplus cameras, I am happy to see that modules packaged for Debian. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308335: Bug#308373: dictionaries-common: Prevents Emacs from installing
Hi, Daniel, Joerg and Aaron (cc'ing all related bugs) On Tue, May 10, 2005 at 02:47:57PM +0200, Daniel Brockman wrote: > (See below for why this message is cross-posted to several bugs.) > > Agustin Martin <[EMAIL PROTECTED]> writes: > > > If I am not wrong, that should also be reproduced by a plain > > > > # dpkg-reconfigure emacs21 > > Yes, you are right. > > > I can only check that now in a woody+dict-common system, and I > > cannot reproduce that problem. I am not in dial up and cannot try a > > real reinstall. Please check if 'dpkg-reconfigure emacs21' also > > gives that problem in your system. Please also provide info about > > the emacs version you are trying. > > It does. I'm using emacs21-21.4a-1 (and CVS Emacs from last night, > packaged with Jerome Marant's emacs-snapshot). > Considering that this has been silent for emacs21 <= 21.3 and just issuing a warning for xemacs21, is possible that emacs-21.4 has changed handling of this things, raising severities. If this is true, this problem should only become evident with emacs-snapshot. Another possibility I would think of is that some package is so broken that has managed to raise from its /etc/emacs/.. files the severity emacs has with this things (not sure if this can be done), and does this in a non local way, so is inherited by others. I never tried emacs-snapshot packages, so the dictionaries-common system is completely untested for it. I do not know if has any special thing that might also influence this. > Yes, you are quite right. I can't believe I missed this. The error > does not occur unless I also have auctex installed (some other package > that I do not have installed and whose first letter is a, b, c, or d > might also provoke it). I will try looking at this tomorrow in a real sid box with sid emacsen flavours. > >> I don't know what would be a good solution in this case, but you > >> may find it helpful to know that I've filed a similar couple of > >> bugs on the dictionary-el and BBDB packages (Bug#308335 and > >> Bug#308336, respectively) --- which also cause this same problem. > > > > The trivial fix is to surround the code by a condition-case, so we > > work around other packages bugs. I do not think that is desirable, > > so I wait for your log. > > I agree. Sorry, I do not have time to investigate further and/or > create a log right now, but I will follow up on this tonight. If we confirm that this is a problem only with emacs-snapshot, there is no hurry in making a quick fix go to sarge. Anyway, using condition-case in this (load), with a big error message in case of failure, is probably desirable to make code more robust. The (load file t) way Aaron plans for dictionary-el will not work here, the file to be loaded exists, but the autoloads triggered by that load not. Along with this I would consider filing bug reports against the packages that when byte-compiling load startup scripts for no good reason. > > Yes. I'm CCing the other bugs so that the maintainers of those > packages (bbdb and dictionary-el) do not have to worry so much > about this. (Sorry guys!) > > Maybe these bugs can even be closed. (Assuming that it actually is > considered OK for a package to require byte-compiled files in their > /etc/emacs/site-start.d scripts.) > I will leave this bug report open for a while, until I add the condition-case statement, or a better fix. Regarding byte-compiled files load from /etc/emacs/site-start.d/.., if the emacs ispell pop-up menus are to be updated with the really installed dictionaries, we require loading of ispell.elc itself (another place where that might fail) from startup scripts, so we really need those byte compiled files be loaded (that will be triggered by ispell-change-dictionary call). Thanks again for your feedback, Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#308772: libmyspell3: Suggestions do not display accented characters
reassign 308772 myspell-fr
severity 308772 normal
retitle 308772 myspell-fr: missing egrave character in fr.aff TRY line
tag 308772 patch
thanks
On Thu, May 12, 2005 at 10:28:07AM +0100, Ivan Kanis wrote:
>
> 1) Using mozilla or oowriter type in the following word: frere
> 2) Run spell check
> 3) Select French language
>
> I get the following words in the suggestions list: ferre frire
>
> I should bet getting fr`ere (brother)
This is a problem in the myspell-fr package, where egrave is missing from
the TRY line.
Attached patch seems to work here. myspell-fr maintainer, please verify the
preferences ordering and that there are no more missing 8bit french chars
there (seems that at least {a,e,o}-hat are also missing, not added in the
patch).
I am reassigning this bug report to myspell-fr with a lowered severity, it
does not affect all accented characters.
Cheers,
--
Agustin
--- fr.aff.orig 2005-05-12 12:58:28.0 +0200
+++ fr.aff 2005-05-12 12:59:07.0 +0200
@@ -1,5 +1,5 @@
SET ISO8859-1
-TRY aeioàéìòsinrtlcdugmphbyfvkw
+TRY aeioàéìòsinrtlcdugmphbyfvkwè
PFX R Y 2
PFX R 0 re [^aàâeèéêiîoôuh]
Bug#309541: dictionaries-common: [INTL:fr] French debconf templates translation
On Tue, May 17, 2005 at 10:59:30PM +0200, Christian Perrier wrote: > Please find attached the french debconf templates update, proofread by the > debian-l10n-french mailing list contributors. > > > This file corrects some variable substitution errors... Thanks for the update. Committed to our CVS. Expect an upload soon today. Since the way for l10n changes passing to sarge is not fully closed by tomorrow's deadline, I plan to ask debian-release around the beginning of next week for this change (and a previous Russian update) passing to sarge. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293926: dictionaries-common needs a "don't muck with my config files" option
On Sun, Feb 06, 2005 at 01:19:24PM -0800, Don Armstrong wrote:
> Package: dictionaries-common
> Severity: important
> Version: 0.24.7
>
> dictionaries-common needs to have an option in the debconf prompting
> such that a user can decline to have dictionaries-common munge their
> precious configuration settings.
>
Rather than a debconf option I would say some way to allow those settings
be preserved, but I agree that something must be done. Having a debconf
query at package install will add an extra question (really two) for a
probably minor audience, but will annoy more people unless we give that
question a low priority.
I am more for allow setting a manual mode from
select-{ispell,wordlist}-default, either with a runtime option or with a
question from the script itself. That will not deal with upgrades from
woody, but will preserve manual mode afterwards if selected.
All this will require changes in a number of places, so will need extensive
testing before upload, and much more testing before I try to put this in
sarge (dictionaries-common is standard because standard wamerican depends on
it, so it is frozen)
> That is, if I've got a dicionary and hash file installed that
> dicionaries-common doesn't know about, I should be able to keep as my
> default if I've set the symlinks myself.
Note that hash format also changes in the woody->sarge transition, old dicts
will not work.
> [This probably is a serious bug, since it doesn't allow administrators
> to preserve their configuration file settings, but I'll leave the RC
> nature of this bug to your discretion.]
>
I will leave it with the current priority. There are more things than
symlinks involved in the setting of default ispell dict, and the better
way to have all this joined together is to locally package such dict the
Debian way. But some people might still prefer to do things manually.
Thanks for pointing out this,
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293926: dictionaries-common needs a "don't muck with my config files" option
On Mon, Feb 07, 2005 at 10:25:04AM -0800, Don Armstrong wrote: > On Mon, 07 Feb 2005, Agustin Martin wrote: > > Rather than a debconf option I would say some way to allow those > > settings be preserved, but I agree that something must be done. > > Having a debconf query at package install will add an extra question > > (really two) for a probably minor audience, but will annoy more > > people unless we give that question a low priority. > > I was actually thinking of just another option in the default > dictionary prompting phase to the effect of "don't change my > settings". I also thought about that, but I saw some preliminary drawbacks. On the one side the debconf prompting is only done in some rare cases, for most cases a reasonable guess can be done after the value of the LANG variable, and that will fortunately result in no debconf prompt at all. On the other hand it will imply more interaction with debconf, changing database values and so on. Not a big problem, we already do some black magic with that, but I expect it to be harder to debug, although I actually did not yet tried coding things that way. I have been playing with something somewhat different, e.g., # update-default-ispell [--auto|--manual] to switch between automatic and manual modes, and launch the dict selection menu if appropriate. This is something closer to the update-alternatives manual mode. Another possibility I am considering is prompting from update-default-* before the selection menu instead of using options. Current tests use debconf to store the values for wordlists and ispell dicts, but since it is not a reuse of something introduced at the preconfigure stage of package install (like we currently do with update-default-*), I find that to be a rather clear debconf abuse. I will probably use a file under /usr/lib like update-alternatives does. I am still in the 'test many things' stage, so adding an extra debconf entry is not fully discarded, if I find some way to make it solid enough. > > > All this will require changes in a number of places, so will need > > extensive testing before upload, and much more testing before I try > > to put this in sarge (dictionaries-common is standard because > > standard wamerican depends on it, so it is frozen) > > Yeah... but assuming the testing gets done, there's no reason not to > try for proposed-updates (unless the release team thinks differently) I will try it anyway, > > No problem. [I actually saw it from another bug... wamerican is > actually installed but something has caused it to disappear from the > list of dictionaries that dictionaries-common knows about... but I > haven't tracked that one down enough to know what is going on there.] I will try to take a look at that. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#293926: dictionaries-common needs a "don't muck with my config files" option
On Mon, Feb 07, 2005 at 10:25:04AM -0800, Don Armstrong wrote: > I was actually thinking of just another option in the default > dictionary prompting phase to the effect of "don't change my > settings". I have to experiment with dictionaries-common providing that entry as if it were another dict. This might be robust enough. Time for bed. -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307679: dictionaries-common: [INTL:ru_RU] Updated russian translation
On Wed, May 04, 2005 at 09:03:56PM +0400, Yuri Kozlov wrote:
> Package: dictionaries-common
> Version: 0.24.10
> Severity: wishlist
>
> This is update russian translation.
Thanks for the update.
Unfortunately it was done after the sarge version, when the unstable version
has a minor difference, please look for
#. Type: select
#. Choices
#: ../dictionaries-common.templates:34
msgid "${choices}, Manual symlinks setting"
msgstr ""
in the attached file.
I have also modified a couple of entries in your po file where ${xxspell}
is expected instead of plain ispell, because I expect to use them in the
post-sarge for aspell-autobuildhash. There was also a minor change in
unstable, some extra trailing whitespaces were removed and that made (in
a harmless way) fuzzy a number of entries when building the package. I
have unfuzzied them, but please check that I did not unfuzzy more than
I should.
All the above is committed to our CVS, and I wait for your reply. I
cannot make sure it will go into sarge, along with the pending final
changes, but I will try as soon as the last uploaded version enters
sarge after being accepted by the release team.
I am attaching the ru.po file as is currently in our CVS.
Cheers,
--
Agustin
# translation of ru.po to Русский язык
# translation of ru.po to Russian
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans#
#Developers do not need to manually edit POT or PO files.
# Nikolai Prokoschenko <[EMAIL PROTECTED]>, 2004.
#
msgid ""
msgstr ""
"Project-Id-Version: ru\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2005-04-30 17:13+0200\n"
"PO-Revision-Date: 2005-05-05 11:42+0200\n"
"Last-Translator: Yuri Kozlov <[EMAIL PROTECTED]>\n"
"Language-Team: Russian \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 0.9.5\n"
"Plural-Forms: nplurals=3; plural=(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%"
"10<=4 && (n%100<10 || n%100>=20) ? 1 : 2);\n"
#. Type: note
#. Description
#: ../dictionaries-common.templates:3
msgid "An invalid debconf value [${value}] has been found"
msgstr "Было найдено неверное значение debconf
[${value}]"
#. Type: note
#. Description
#: ../dictionaries-common.templates:3
msgid "It does not correspond to any installed package in the system."
msgstr "Оно не соответствует ни одному пакету
в системе."
#. Type: note
#. Description
#: ../dictionaries-common.templates:3
msgid ""
"That is usually caused by problems at some time during packages "
"installation, where the package providing [${value}] was selected for "
"installation but finally not installed because of errors in other packages."
msgstr ""
"Обычно это связано проблемами в процессе
установки пакетов, если пакет, "
"содержащий [${value}] был помечен для
установки, но в итоге не был "
"установлен из-за ошибок в других пакетах."
#. Type: note
#. Description
#: ../dictionaries-common.templates:3
msgid ""
"To fix this error, reinstall (or install) the package that provides the "
"missing value. Then, if you don't want this package on your system, remove "
"it, which will also remove its debconf entries. Menu to be shown after this "
"message will try to leave the system in a working state until then."
msgstr ""
"Чтобы исправить эту ошибку,
переустановите (или поставьте) пакет,
содержащий "
"недостающее значение. Затем, если вам этот
пакет не нужен, удалите его, этим "
"вы заодно уберёте и все значения debconf.
Диалог, показанный после этого "
"сообщения, попытается оставить систему в
работоспособном состоянии, пока не "
"будет исправлена ошибка."
#. Type: note
#. Description
#: ../dictionaries-common.templates:3
msgid ""
"This error message can also appear during ispell dictionary or wordlist "
"renaming (e.g., wenglish-> wamerican). In this case it is harmless and "
"everything will be fixed after you select your default in the menu(s) shown "
"after this message."
msgstr ""
"Это сообщение об ошибке может также
появиться во время переименования "
"словаря ispell или списка слов (например, wenglish
-> wamerican). В этом "
"случае оно безвредно и ошибка будет
исправлена после того, как вы выберете "
"ваше значение по умолчанию в меню
показанном после этого сообщения."
#. Type: select
#. Description
#: ../dictionaries-common.templates:25
msgid "Which ispell dictionary should be the system's default?"
msgstr "Какой словарь ispell станет в системе
словарём по умолчанию?"
#. Type: select
#. Description
#: ../dictionaries-common.templates:25
msgid ""
"Because more than one ispell dictionary will be available in your system, "
"please select
Bug#307679: dictionaries-common: [INTL:ru_RU] Updated russian translation
On Thu, May 05, 2005 at 07:20:15PM +0400, Yuri Kozlov wrote: > On Thu, 5 May 2005 12:15:43 +0200 > Agustin Martin <[EMAIL PROTECTED]> wrote: > > > >I am attaching the ru.po file as is currently in our CVS. > > Fixed version attached. Thanks for the update, Committed to our CVS. Expect an upload by the end of next week or beginning of next one, once current sid package (already unblocked) passes to sarge. I will try later to have this included in sarge, along with any other l10n change I receive in the meantime. Since it will contain only l10n changes, I hope it will be passed. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#307862: ftp.debian.org: Please remove some spurious dictionaries-common packages
Package: ftp.debian.org Version: N/A; reported 2005-05-06 Severity: normal Hi, Just noticed that we have in the pool the files dictionaries-common_0.22.40sarge7.dsc dictionaries-common_0.22.40sarge7.tar.gz dictionaries-common_0.22.40sarge7_all.deb dictionaries-common-dev_0.22.40sarge7_all.deb All them come from an upload to testing-proposed-updades that was superseeded by a direct pass to sarge of the sid package with a higher version. I think all them can safely be removed from the pool. Thanks in advance -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux debian 2.6.11-1-686 #1 Sun Apr 3 06:20:48 EDT 2005 i686 Locale: LANG=es_ES, LC_CTYPE=es_ES Cheers, -- Agustin pgpShvpl6gIOi.pgp Description: PGP signature
Bug#308373: dictionaries-common: Prevents Emacs from installing
On Mon, May 09, 2005 at 10:01:05PM +0200, Daniel Brockman wrote: > Package: dictionaries-common > Version: 0.25.9 > Severity: normal > > Steps to reproduce: > >apt-get install dictionaries-common aspell-sv (or some other) >apt-get install --reinstall emacs21 If I am not wrong, that should also be reproduced by a plain # dpkg-reconfigure emacs21 I can only check that now in a woody+dict-common system, and I cannot reproduce that problem. I am not in dial up and cannot try a real reinstall. Please check if 'dpkg-reconfigure emacs21' also gives that problem in your system. Please also provide info about the emacs version you are trying. After your description, every upgrade should trigger that problem (As a matter of fact a harmless error message is sometimes shown for xemacs probably due to that problem), but I could never see it for FSF emacs, and I have gone through a number of install/upgrade/reinstall runs (I am not sure about reinstalls, but should be similar). I cannot be sure that something in the emacs error handling is not changed in sid, but I am surprised that I never found that problem for FSF emacs. I am also surprised that this bug, considering what causes it, has never been reported. Read below for a possible reason. > > This likely results in dpkg failing noisily upon running the emacs-install > script for some completely unrelated Emacs package. You won't be able to get > your Emacs back unless you first remove dictionaries-common. Then you can > install Emacs, and finally put back dictionaries-common if you like. > > This becomes a real problem when you want to install a new Emacs flavor > (something which also provokes this bug). The worst part may be that the > error messages give no hint about what is really causing the problem. > > The problem is that /etc/emacs/site-start.d/50dictionaries-common.el calls > >(load "/var/cache/dictionaries-common/emacsen-ispell-dicts.el" t) > > and /var/cache/dictionaries-common/emacsen-ispell-dicts.el calls > >(debian-ispell-add-dictionary-entry ...) > > which causes the autoload for `debian-ispell-add-dictionary-entry' to attempt > to load the library "debian-ispell". Here's where things break down. dictionaries-common emacsen-install is called with --no-site-file for emacs21* and with -no-site-file for xemacs21*, so that configuration files (etc/etc/emacs/site-start.d/* stuff) should not be loaded, look at the *real* dictionaries-common section install/dictionaries-common: Byte-compiling for emacsen flavour emacs21 Wrote /usr/share/emacs21/site-lisp/dictionaries-common/debian-ispell.elc Wrote /usr/share/emacs21/site-lisp/dictionaries-common/ispell.elc Done (No loads from /etc at all) But other packages might have missed this, and they are blindly loading everything under /etc/emacs/site-start.d when byte-compiling. Can you please submit the full byte-compile log?, so we can better locate the problem. > > I don't know what would be a good solution in this case, but you may find it > helpful to know that I've filed a similar couple of bugs on the dictionary-el > and BBDB packages (Bug#308335 and Bug#308336, respectively) --- which also > cause this same problem. The trivial fix is to surround the code by a condition-case, so we work around other packages bugs. I do not think that is desirable, so I wait for your log. Note that those other packages might also not be guilty for this problem. Thanks for your report, ... and waiting for your feedback, Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298981: dictionaries-common: Can't install or remove wordlists
retitle 298981 More type 1 db corruption
severity 298981 normal
reassign 298981 debconf
merge198297 224400 298981
thanks
On Fri, Mar 11, 2005 at 01:13:10AM +0100, Agustin Martin wrote:
> On Thu, Mar 10, 2005 at 11:05:00PM +0100, Ferenc Wágner wrote:
> > # dpkg --remove wcatalan
> > (Reading database ... 157936 files and directories currently installed.)
> > Removing wcatalan ...
> > Can't call method "choices" on an undefined value at
> > /usr/share/perl5/Debconf/Question.pm line 85, line 4.
> > dpkg: error processing wcatalan (--remove):
> > subprocess post-removal script returned error exit status 9
> > Errors were encountered while processing:
> > wcatalan
>
> That seems debconf type 1 db corruption, see e.g.,
>
> http://bugs.debian.org/198297
>
...
> If this is what seems to be I will reassign this bug report to debconf and
> merge it with #198297.
Hi, Ferenc
I am reassigning this bug to debconf, with severity lowered to allow its
merging with #198297 and #224400. I think this should also be merged with
the #{247849,255193,282587,284287,297534} saga, but I leave that to debconf
maintainers consideration.
Your mail address seems to be temporarily bouncing. Please look at my
previous mail to http://bugs.debian.org/298981 or the above link for some
directions about how to deal with the problem. Something I did not mention
there, some people suggest that this problem is related to nearly full /var
partitions.
Cheers,
--
Agustin
Bug#299541: dictionaries-common: string not translatable in debconf templates
On Mon, Mar 14, 2005 at 09:47:44PM +0100, Denis Barbier wrote:
> Package: dictionaries-common
> Version: 0.24.10
> Severity: minor
>
> Hi,
>
> the dictionaries-common/languages template cannot be translated, and
> it indeed appeared in English when upgrading. Moreover you should
> avoid using first person sentences, as described in the developer's
> reference ("Do not use first person" section).
Hi, Denis
dictionaries-common system uses a complex setup to extract values from
templates provided by the different ispell dicts/wordlists and join them
together into a common shared question choices field. This is powerful, but
has as drawback that the english strings will always be extracted, even if
they have a translation. That is the reason why that string is tagged as
non-translatable in dictionaries-common as well as in all the ispell dicts
and wordlists.
Other entries for that shared question use some sort of poor man
localization [local name (english name)], but that is not possible here,
where the value means that the sysadmin wants to do things manually, and is
provided by a language neutral package.
The only possible simple improvement I see is to reduce that entry string
to "~manual~", what is by itself less explanatory, and add a localizable
explanation in the shared question main text
(dictionaries-common/default-ispell and dictionaries-common/default-wordlist),
but I do not find that desirable for sarge, because that will require all po
files be updated.
Another more complex fix would be to split that question (boolean
manual/auto) but that would require a number of changes in the
dict/wordlist autodetection code being run after debian-installer values,
and if possible (I did not test it) would also require po files update. I
thought about this latter possibility, but did not even try it because of
the po files update need, and of the expected much higher complexity
(probably too much for a frozen package).
Regarding first person, I do not have policy document now available, but
I think policy does not apply to this first person use. This use refers
to the sysadmin that is to act, not to the computer, it cannot be
considered as giving the computer any kind of human consideration.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299725: dictionaries-common: Can no longer customise case/non-case chars in Emacs
On Wed, Mar 16, 2005 at 02:32:57AM +0100, Reuben Thomas wrote:
>
> Since the current version of dictionaries-common and aspell-0.60,
> spell checking in Emacs using aspell no longer works properly for me.
>
Even if the problem has been triggered now, there is nothing new related
to this problem in either dictionaries-common or aspell not already present for
the last two years.
I guess you did not notice that previously because you had no ispell dicts
at all installed and all the installed aspell dicts did not register for
use with the dictionaries-common system. The difference is that aspell-en
now does.
For that reason you were using ispell.el provided by emacs while now you are
using ispell.el provided by dictionaries-common. This latter is more recent,
but the system nulls the ispell-dictionary-alist provided by ispell.el and
refills it with the values provided by dict maintainers, either ispell or
aspell.
> A bit of background: I use accented characters in my British English
> words (as does the Oxford English Dictionary). Having looked over the
> new version of dictionaries-common, it seems what I need to do is add
> an entry to ispell-local-dictionary-alist. I erased my previous
> customisation of ispell-dictionary-alist, added one for
> ispell-local-dictionary-alist, and added accented letters to the case
> and non-case character classes. But words like "rôle"
> (r-ocircumflex-l-e) still get mangled: aspell flags up "le" as not a
> word, treating the ô as not a letter.
ispell.el is probably buggy related to ispell-local-dictionary-alist, while
it should read it everytime it gets casechars and so on, seems that it is
only read at load time before reading ~/.emacs. There is a patch for that
in the emacs21 CVS I was considering for adition, but in the meantime I
suggest you to use in ~/.emacs the same function
(debian-add-dictionary-entry) used by dictionaries-common for this, just
adding ñ and ô to ths {non}-casechars entries would look like
(debian-ispell-add-dictionary-entry
'("british+accs"
"[A-ZÑÔa-zñô]"
"[^A-ZÑÔa-zñô]"
"[']"
nil
("-B" "-d" "british-w_accents")
nil
iso-8859-1)
"aspell")
and then feed debian-ispell-dictionary-alist to ispell-dictionary-alist,
(setq ispell-dictionary-alist debian-ispell-dictionary-alist)
This way something like
-
rôle
Local Variables:
ispell-program-name: "aspell"
ispell-local-dictionary: "british+accs"
End:
-
should work, even if the dict is not shown as one of the possible values in
ispell-change-dictionary (it should with the current dictionaries-common
unstable version, 0.24.11, but I cannot check now).
If you are going to add more changes, or the unpatched ispell.el can be run
sometimes, is probably better to test for function availability,
(if (fboundp 'debian-ispell-add-dictionary-entry)
(progn
(debian-ispell-add-dictionary-entry ... )
(debian-ispell-add-dictionary-entry ... )
)
)
Using this function has the drawback that is too Debian specific, but has
another advantages for the future. On the one hand it should allow the entry
be shown as one of the possible values for ispell-change-dictionary
(although not in the popup menus). On the other hand, the trailing "aspell"
is currently not used, but is intended to mean that the dict is available for
aspell only. In the future I would like, for systems having both ispell and
aspell installed, allow an automatic selection of the spellchecker program
based on the value of ispell-program-name and dict availability for that
entry and spellchecker. I have promising code for this, but requires
flyspell.el modification and a lot of testing.
I have definitely to write something about this in the README file. That
should close the bug report.
Thanks for yur feedback,
Cheers,
--
Agustin
Bug#299541: dictionaries-common: string not translatable in debconf templates
On Tue, Mar 15, 2005 at 12:19:02AM +0100, Agustin Martin wrote: > The only possible simple improvement I see is to reduce that entry string > to "~manual~", what is by itself less explanatory, and add a localizable > explanation in the shared question main text > (dictionaries-common/default-ispell and dictionaries-common/default-wordlist), > but I do not find that desirable for sarge, because that will require all po > files be updated. > Hi, Denis I will proceed this way, for now I am reducing the string to "~manual~", that is more l10n neutral. Once sarge releases I will add a localizable description of that tag in the global question text. Since this latter will not be done now I will keep this bug report open until it happens. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299816: installdeb-myspell is unable to install openoffice hypenation files
severity 299816 wishlist retitle 299816 Please make installdeb-myspell also install openoffice hyphenation files thanks On Wed, Mar 16, 2005 at 08:00:07PM +0100, Matthias Klose wrote: > Package: dictionaries-common-dev > > $ cat $ cat debian/info-myspell > DICT da DK da_DK > HYPH da DK hyph_da_DK > > $ installdeb-myspell --srcdir=da_DK/hyph > Use of uninitialized value in concatenation (.) or string at > /usr/bin/installdeb-myspell line 33, line 4. > There is no da_DK/hyph/da_DK.aff file here > Please see . Hi, Mathias It is not intended for that, please see the man page, OPTIONS --srcdir=dir Will look for .aff/.dic files in the specified directory and install them in the default target directory. Base name will be extracted from the info-myspell file --- Since I agree that this is a nice thing to add I am not closing this bug report, but setting it severity wishlist. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299541: dictionaries-common: string not translatable in debconf templates
On Wed, Mar 16, 2005 at 08:27:14PM +0100, Denis Barbier wrote:
>
> Such strings can most always be translated, see e.g. the tasksel/first
> template in tasksel. I would be very surprised if it cannot be
> translated, but did not yet investigate.
>
Hi, Denis
Thanks for the hint, after a quick look it might also work for
dictionaries-common, since only the last entry is to be localized, and not
every intermediate one (and made match). Just removing
dictionaries-common/languages and adding the string to
dictionaries-common/default-{ispell,wordlist} should have the same effect as
before, but localizable, and will ensure it is presented last.
Fully putting it now at this sarge stage is something I am more reluctant,
but will think about this once I really test the system.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298981: dictionaries-common: Can't install or remove wordlists
On Wed, Mar 16, 2005 at 11:12:02PM +0100, Ferenc Wagner wrote: > Agustin Martin <[EMAIL PROTECTED]> writes: > > > Your mail address seems to be temporarily bouncing. Please > > look at my previous mail to http://bugs.debian.org/298981 > > or the above link for some directions about how to deal > > with the problem. Something I did not mention there, some > > people suggest that this problem is related to nearly full > > /var partitions. > > > thank you very much for your kind attention, my mail server > was broken down indeed. I already checked the Web interface > and much of that seems to apply for this machine, as it > crashed hard a couple of times and its /var did fill up > during a recent upgrade. Those people may be on the right > track. As soon as I have a chance I'll try to add some new > detail to the picture. Thanks for the feedback. I am sending this reply to the bug BTS entry, to have it recorded there. Since I already reassigned this bug report to debconf, please send further info to [EMAIL PROTECTED] Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299816: installdeb-myspell is unable to install openoffice hypenation files
On Wed, Mar 16, 2005 at 11:27:09PM +0100, Agustin Martin wrote: > It is not intended for that, please see the man page, > > > OPTIONS > --srcdir=dir Will look for .aff/.dic files in the specified directory >and install them in the default target directory. Base >name will be extracted from the info-myspell file > --- > Just noticed that hyphenation files also use the .dic extension. The above entry refers only to affix files and dicts. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299816: installdeb-myspell is unable to install openoffice hypenation files
On Wed, Mar 16, 2005 at 11:27:09PM +0100, Agustin Martin wrote: > On Wed, Mar 16, 2005 at 08:00:07PM +0100, Matthias Klose wrote: > > Package: dictionaries-common-dev > > > > $ cat $ cat debian/info-myspell > > DICT da DK da_DK > > HYPH da DK hyph_da_DK > > > > $ installdeb-myspell --srcdir=da_DK/hyph > > Use of uninitialized value in concatenation (.) or string at > > /usr/bin/installdeb-myspell line 33, line 4. > > There is no da_DK/hyph/da_DK.aff file here > > Please see . > > Hi, Mathias > > It is not intended for that, please see the man page, > > > OPTIONS > --srcdir=dir Will look for .aff/.dic files in the specified directory >and install them in the default target directory. Base >name will be extracted from the info-myspell file > --- > > Since I agree that this is a nice thing to add I am not closing this bug > report, but setting it severity wishlist. Hi, Matthias, I have been playing with a way of using installdeb-myspell also to install hyphenation ooo files and add the appropriate debhelper snippets. In the course of this I noticed that this has nothing to to with myspell itself, apart from sharing the same dictionaries.lst file and that the hyph files are installed under /usr/share/myspell, but with the diferent hyphenation packages. I have prepared an installdeb-myspell that does that, and since I find that this can be useful for ooo hyphen packages to use the same dictionaries.lst updating mechanism as myspell dicts I am cc'ing the debian-openoffice list for feedback. myspell dicts would do as usual, and ooo hyhpenation packages could do something like (package stands for the package name and using da_DK as an example) debian/package.info-myspell: HYPH da DK hyph_da_DK (better not change the -myspell prefix, even if this is not myspell) debian/rules: In the build target, installdeb-myspell -ppackage --srcdir=. This should try to install hyph_da_DK.dic from the current dict into /usr/share/myspell/dicts and create the appropriate debhelper snippets so update-openoffice-dicts is called and dictionaries.lst updated. Comments? Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299541: dictionaries-common: string not translatable in debconf templates
On Wed, Mar 16, 2005 at 08:27:14PM +0100, Denis Barbier wrote:
> Such strings can most always be translated, see e.g. the tasksel/first
> template in tasksel. I would be very surprised if it cannot be
> translated, but did not yet investigate.
>
Hi,
It is being a bit more complex than expected but I hope will work
Changing the string to
"${choices}, Manual symlinks setting"
I will mail last po translators with a request for this localization
change. I plan to do that around this weekend (I am in Easter
vacation with limited net access), so you are still in time of
suggesting a better wording for that choice.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#283948: [Dict-common-dev] [Fwd: Bug#283948: PLease integrate squirrelmail with dictionaries-common]
On Tue, Feb 08, 2005 at 11:12:48AM +0100, Thijs Kinkhorst wrote: > Hello people, > > I need some assistance with the bug below that has been posted to the BTS > under squirrelmail. I've looked into it but cannot seem to find out how to > detect the information needed. > Original Message > Subject: Bug#283948: PLease integrate squirrelmail with > dictionaries-common From:"Alastair McKinstry" <[EMAIL PROTECTED]> > Date:Thu, December 2, 2004 15:16 > To: "Debian Bug Tracking System" <[EMAIL PROTECTED]> > -- > > Package: squirrelmail > Version: 2:1.4.3a-3 > Severity: wishlist > > > Squirrelmail should be integrated with dictionaries-common, to > detect which dictionaries are present for ispell, and which is set for the > default. > Hi, Thijs, Sorry I did not write before. The change I suggested in my last mail is present in dictionaries-common-0.25.0, already uploaded to sid for some days. Since wamerican is a standard package, dictionaries-common is and so, it is currently sarge-frozen. Since this change is simple I do not expect problems from the release team to make it pass to sarge, but we should doubleckeck before that everything is working as expected to minimize release team load. Note that unless you put some conditionals in the code (checking for the list file existence, which will make squirrelmail migrations to testing easier) you should make squirrelmail depend on dictionaries-common (>=0.25) Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299725: dictionaries-common: Can no longer customise case/non-case chars in Emacs
On Sun, Mar 20, 2005 at 11:38:17PM +0100, Reuben Thomas wrote:
> OK. I reactivated dictionaries-common's .el init code, added the
> following:
>
> >(debian-ispell-add-dictionary-entry
> > '("british+accs"
> > "[A-ZÑÔa-zñô]"
> > "[^A-ZÑÔa-zñô]"
> > "[']"
> > nil
> > ("-B" "-d" "british-w_accents")
> > nil
> > iso-8859-1)
> > "aspell")
> >(setq ispell-dictionary-alist debian-ispell-dictionary-alist)
>
> to my .emacs, set ispell-local-dictionary to "british+accs", and it
> doesn't work: accented characters are still treated as non-word
> characters (so "rôle" doesn't spell-check).
>
Strange, that is working here with the sample file I copied. Furthermore,
directly modifying ispell-dictionary-alist also works, as long as you do not
reload ispell.el,
; ---
(setq ispell-dictionary-alist
(append ispell-dictionary-alist
'(("british+accs" ; British version
"[A-ZÑÔa-zñô]"
"[^A-ZÑÔa-zñô]"
"[']"
nil
("-B" "-d" "british-w_accents")
nil
iso-8859-1
;
* Blind guess: Was the original code filed as latin1 or utf8?
Try with the octal codes (I hope they are not messed), that is how the
example is expected to go in the new README.emacs file.
;
(debian-ispell-add-dictionary-entry
'("british+accs"
"[A-Z\321\324a-z\361\364]"
"[^A-Z\321\324a-z\361\364]"
"[']"
nil
("-B" "-d" "british-w_accents")
nil
iso-8859-1)
"aspell")
;
After Easter I will take a look at the ispell-local-dictionary-alist stuff,
to see how to make it work as expected.
Thanks for your feedback,
Cheers,
--
Agustin
Bug#314714: dictionaries-common: debconf asks me question with absurd choice
On Fri, Jun 17, 2005 at 05:38:00PM -0500, Branden Robinson wrote:
> Package: dictionaries-common
> Version: 0.30.1
> Severity: normal
>
> Upgrading from sarge:
>
> Preconfiguring packages ...
> Dictionaries-common: Ispell dictionary
> --
>
> Because more than one ispell dictionary will be available in your system,
> please select the one you'd like applications to use by default.
>
> You can change the default ispell dictionary at any time by running
> "select-default-ispell".
>
> 1. 2. Manual symlinks setting
>
> Which ispell dictionary should be the system's default? 1
Hi, Branden,
Seems you have no ispell dicts installed at all, so the debconf choices
string becomes something like
, Manual symlinks setting
The original debconf string being
${choices}, Manual symlinks setting
where ${choices} is substituted after the installed ispell dicts/wordlists
(ispell dicts in your case). I am a bit puzzled, since nothing in that code
has been changed since 0.25.4 (11Apr2005), and that changes are currently in
sarge, with no bugreports.
I am rather confident I checked that possibility, at least on removal, and
worked, but I am not sure if something in debconf has been changed in the
meantime, or may be I left something missing behind.
I am cc'ing debconf package in case something has been changed there (An
extra whitespace?).
I will also take a look about doublechecking this kind of things, that
should not be difficult.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314714: dictionaries-common: debconf asks me question with absurd choice
On Sat, Jun 18, 2005 at 05:09:01PM +0200, Agustin Martin wrote:
> On Fri, Jun 17, 2005 at 05:38:00PM -0500, Branden Robinson wrote:
> > Package: dictionaries-common
> > Version: 0.30.1
> > Severity: normal
> >
> > Upgrading from sarge:
> >
> > Preconfiguring packages ...
> > Dictionaries-common: Ispell dictionary
> > --
> >
> > Because more than one ispell dictionary will be available in your system,
> > please select the one you'd like applications to use by default.
> >
> > You can change the default ispell dictionary at any time by running
> > "select-default-ispell".
> >
> > 1. 2. Manual symlinks setting
> >
> > Which ispell dictionary should be the system's default? 1
>
> Hi, Branden,
>
> Seems you have no ispell dicts installed at all, so the debconf choices
> string becomes something like
>
> , Manual symlinks setting
>
> The original debconf string being
>
> ${choices}, Manual symlinks setting
>
> where ${choices} is substituted after the installed ispell dicts/wordlists
> (ispell dicts in your case). I am a bit puzzled, since nothing in that code
> has been changed since 0.25.4 (11Apr2005), and that changes are currently in
> sarge, with no bugreports.
I was re-checking the code and that section is not called when upgrading
dictionaries-common from sarge with no ispell dicts installed (I cannot check
the real upgrade now, but the only sarge+ changes in dictionaries-common were
po files and a standalone script in dictionaries-common-dev that is called
only on demand). As a mater of fact I see no possibility that the above
string is called with an empty ${choices} field, unless something became
broken in some way.
So I think of three possibilities:
a) debconf database broken
Try
# dpkg-reconfigure dictionaries-common
If the problem persists, run
# /usr/share/debconf/fix_db.pl
and try again with
# dpkg-reconfigure dictionaries-common
If the problem is still present, this is not the reason for it.
b) You have a single ispell dict installed that, when upgraded along with
dictionaries-common, has a wrong (empty) Default: field in
${dict_name}/languages template, causing the wrong string being passed
to debconf.
c) Something new in debconf is broken
This is not the case if you have no ispell dicts since, as I mentioned
above, that string is not used on upgrades from sarge. I am keeping
debconf being cc'ed, but I see no bugreports that might seem related to
this problem. But if you have ispell dicts installed, debconf subst
might not be working well.
I will try to reproduce this problem tomorrow in a sarge -> sid upgrade
*only* for dictionaries-common. If I cannot reproduce this problem, I will
need as much possible information, like installed ispell dicts and
preferrably an upgrade log with the relevant dictionaries-common
information, preferrably obtained with the
DEBCONF_DEBUG=developer
prefix. This last is very important for (b) and (c).
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Tue, May 31, 2005 at 04:55:17PM +0200, Agustin Martin wrote: > That makes the mirrors happy because the aspell dict is now arch:all, but > does not cause hashes being rebuilt if a new aspell with incompatible binary > hash format is uploaded. That is what ispell-autobuildhash is currently > doing and is what is expected from aspell-autobuildhash. There are some > problems pending, like a /usr/lib/aspell-0.60 explicitely hardcoded path that > will complicate a transition to e.g. 0.61, while everything would be > simpler if a plain /usr/lib/aspell is used. These are the kind of things > that are still to be considered. Hi Brian, Can local/extra dirs be selected besides /usr/lib/aspell-0.60? Something like aspell looking for dicts and datas in both /usr/lib/aspell-0.60 /usr/lib/aspell-auto Something like this would be good for the autobuildhash stuff, if the auto-dicts are installed in /usr/lib/aspell-auto. This way, when upgrading to e.g., aspell-0.61 autobuilt hashes will be rebuilt and found by the new aspell at /usr/lib/aspell-auto, new aspell stuff would be installed in /usr/lib/aspell-0.61 and obsolete dicts at /usr/lib/aspell-0.60 would be ignored. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314622: emacs21: ispell.el and dictionnary list
On Fri, Jun 17, 2005 at 03:53:27PM +0200, Pascal A. Dupuis wrote:
> Package: emacs21
> Version: 21.4a-1
> Severity: normal
> under Tools->Spell Check, there are only a few dictionnaries
> available. I tried switching to dutch, to no avail, although aspell-nl
> is installed. Then I noticed there are three ispell.el:
> /usr/share/emacs21/site-lisp/dictionaries-common/ispell.elc
> /usr/share/emacs21/site-lisp/dictionaries-common/debian-ispell.elc
> /usr/share/emacs/21.4/lisp/textmodes/ispell.elc (from emacs21-common)
> /usr/share/emacs/21.4/lisp/textmodes/ispell.el (from emacs21-el)
> /usr/share/emacs/site-lisp/dictionaries-common/ispell.el
> /usr/share/emacs/site-lisp/dictionaries-common/debian-ispell.el (from
> dictionnaries.common)
>
> so ... which is the "right" one ?
/usr/share/emacs/site-lisp/dictionaries-common/ispell.el
/usr/share/emacs/site-lisp/dictionaries-common/debian-ispell.el (from
dictionaries.common)
The alist is voided by debian-ispell.el and refilled by information provided
by ispell and aspell dict packages. Unlike in original ispell.el aspell
dicts are also shown if they register for use under the different
emacsen
>
> The dictionary-alist is
> (("american" "[a-zA-Z]" "[^a-zA-Z]" "[']" nil
> ("-d" "en_US")
> nil iso-8859-1)
> ("british" "[a-zA-Z]" "[^a-zA-Z]" "[']" nil
> ("-d" "en_GB")
> nil iso-8859-1)
> ("canadian" "[a-zA-Z]" "[^a-zA-Z]" "[']" nil
> ("-d" "en_CA")
> nil iso-8859-1)
> ("english" "[a-zA-Z]" "[^a-zA-Z]" "[']" nil
> ("-d" "en")
> nil iso-8859-1)
> ("francais"
> "[A-Za-z\xf40\xf42\xf47\xf48\xf49\xf4a\xf4b\xf4e\xf4f\xf54\xf59\xf5b\xf5c\xf60\xf62\xf67\xf68\xf69\xf6a\xf6b\xf6e\xf6f\xf74\xf79\xf7b\xf7c]"
>
> "[^A-Za-z\xf40\xf42\xf47\xf48\xf49\xf4a\xf4b\xf4e\xf4f\xf54\xf59\xf5b\xf5c\xf60\xf62\xf67\xf68\xf69\xf6a\xf6b\xf6e\xf6f\xf74\xf79\xf7b\xf7c]"
> "[-']" t
> ("-d" "francais")
> "~list" iso-8859-1)
> ("francais-ch"
> "[A-Za-z\xf40\xf42\xf47\xf48\xf49\xf4a\xf4b\xf4e\xf4f\xf54\xf59\xf5b\xf5c\xf60\xf62\xf67\xf68\xf69\xf6a\xf6b\xf6e\xf6f\xf74\xf79\xf7b\xf7c]"
>
> "[^A-Za-z\xf40\xf42\xf47\xf48\xf49\xf4a\xf4b\xf4e\xf4f\xf54\xf59\xf5b\xf5c\xf60\xf62\xf67\xf68\xf69\xf6a\xf6b\xf6e\xf6f\xf74\xf79\xf7b\xf7c]"
> "[-']" t
> ("-d" "fr_CH-60")
> "~list" iso-8859-1)
> ("francais-lrg"
> "[A-Za-z\xf40\xf42\xf47\xf48\xf49\xf4a\xf4b\xf4e\xf4f\xf54\xf59\xf5b\xf5c\xf60\xf62\xf67\xf68\xf69\xf6a\xf6b\xf6e\xf6f\xf74\xf79\xf7b\xf7c]"
>
> "[^A-Za-z\xf40\xf42\xf47\xf48\xf49\xf4a\xf4b\xf4e\xf4f\xf54\xf59\xf5b\xf5c\xf60\xf62\xf67\xf68\xf69\xf6a\xf6b\xf6e\xf6f\xf74\xf79\xf7b\xf7c]"
> "[-']" t
> ("-d" "fr_FR-lrg")
> "~list" iso-8859-1)
> ("francais-sml"
> "[A-Za-z\xf40\xf42\xf47\xf48\xf49\xf4a\xf4b\xf4e\xf4f\xf54\xf59\xf5b\xf5c\xf60\xf62\xf67\xf68\xf69\xf6a\xf6b\xf6e\xf6f\xf74\xf79\xf7b\xf7c]"
>
> "[^A-Za-z\xf40\xf42\xf47\xf48\xf49\xf4a\xf4b\xf4e\xf4f\xf54\xf59\xf5b\xf5c\xf60\xf62\xf67\xf68\xf69\xf6a\xf6b\xf6e\xf6f\xf74\xf79\xf7b\xf7c]"
> "[-']" t
> ("-d" "fr_FR-sml")
> "~list" iso-8859-1)
> (nil "[A-Za-z]" "[^A-Za-z]" "[']" nil
> ("-B")
> nil iso-8859-1))
>
> Is this a bug ?
Yes, but neither in emacs21, whose ispell.el is no longer used, nor in
dictionaries-common, that provides the tools for this registration
http://dict-common.alioth.debian.org/dsdt-policy.html#aspell-registration
If myspell-nl gets registered everything will work again.
> Shouldn't this list be longer ?
The original list is different, for instance the french variants are not
present there, since aspell entries having no equivalent ispell dict
installed are not shown there. The same for canadian, not originally in
ispell.el. If aspell-nl is not registered it will not be displayed, unless
the equivalent dutch ispell dict is present.
In Debian ispell-dictionary-alist is now built after the really installed
ispell or aspell dictionaries (all of them should register). This saves us
from some noise (like the old naming for german dicts) and allows aspell
dicts to appear under Tools->Spell Check, because the check for that was
done only for ispell dicts, making everything not having a corresponding
ispell dict disappear from the [Tools->Spell Check] menu as soon as
ispell.el was loaded.
> Is there a specific mechanism/conf to add more dictionnaries support ?
For package maintainers,
http://dict-common.alioth.debian.org/
For users extra settings
/usr/share/doc/dictionaries-common/README.emacs
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314714: dictionaries-common: debconf asks me question with absurd choice
On Mon, Jun 20, 2005 at 02:12:18AM +0200, Agustin Martin wrote: > > I will try to reproduce this problem tomorrow in a sarge -> sid upgrade > *only* for dictionaries-common. I cannot reproduce this in a normal dictionaries-common 0.25.12 -> 0.31.1 upgrade with apt from a sarge box. Details on your setup are appreciated. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314714: dictionaries-common: debconf asks me question with absurd choice
On Tue, Jun 21, 2005 at 01:20:58AM -0500, Branden Robinson wrote:
> This bug is *not* new to the version of dictionaries-common in sid; I was
> wrong about that. I can dpkg-reconfigure the version in sarge and see the
> same behavior.
Strange,
---
# dpkg-reconfigure -f readline dictionaries-common
remove/dictionaries-common: Purging byte-compiled files for flavour emacs20
remove/dictionaries-common: Purging byte-compiled files for flavour emacs21
remove/dictionaries-common: Purging byte-compiled files for flavour xemacs21
Dictionaries-common: Ispell dictionary
--
Because more than one ispell dictionary will be available in your system,
please select the one you'd like applications to use by default.
You can change the default ispell dictionary at any time by running
"select-default-ispell".
1. american (American English) 2. Manual symlinks setting
Which ispell dictionary should be the system's default? 1
... other stuff ...
--
using dictionaries-common 0.30.1 (which has the same code for this as
sarge version 0.25.12) and iamerican 3.1.20.0-4 (the only ispell dict I have
installed in this test)
I suppose you will have the same problem running
# dpkg-reconfigure iamerican
If so, please run
# DEBCONF_DEBUG=developer dpkg-reconfigure -f readline iamerican
and send me the output. The reason to do this with only iamerican is to
get rid of wordlists output, so if that does not reproduce your problem,
send me the output of
# DEBCONF_DEBUG=developer dpkg-reconfigure -f readline dictionaries-common
In the box I am using I have in /var/cache/debconf/config.dat
Name: dictionaries-common/default-ispell
Template: dictionaries-common/default-ispell
Value: Manual symlinks setting
Owners: dictionaries-common
Flags: seen
Variables:
choices = american (American English)
and the config value returned by debconf is
debconf: <-- METAGET dictionaries-common/default-ispell choices
debconf: --> 0 american (American English), Manual symlinks setting
because the choices string in the template is
${choices}, Manual symlinks setting
Last element is then stripped to get the real choices list.
Seems as if your system is returning something different after
metaget("dictionaries-common/default-ispell","choices") call. For that
reason I really need to have the DEBCONF_DEBUG=developer ... stuff.
> Oddly, select-default-ispell *does* work, and I *do* have at least one
> ispell dictionary installed. Running select-default-ispell, though, does
> NOT fix the problem with the debconf question.
This seems to suggests that your iamerican/languages Default entry in
/var/cache/debconf/templates.dat is not void, what is O.K, but does not give
any light on the problem.
I am waiting for the DEBUG output. Thanks for your feedback
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314839: maintaining dutch
On Mon, Jun 20, 2005 at 07:09:23PM +0200, Thomas Hood wrote: > Kurt Roeckx wrote: > > I'm willing to adopt this package is nobody else wants it. > > > dutch (1:0.1e-36) unstable; urgency=low > > . > >* Orphaning: set maintainer to QA. > > > What is involved in maintaining this package? Is upstream active? For the one that finally takes this package I have a couple of patches nearly ready. a) Registering aspell-nl for use under emacsen. This will make aspell-nl be properly recognized and used under emacs. This will fix #314622, filed against emacs21. I did not reassign it yet, and prefer to wait until the mail does not go to the QA team. b) Use aspell-0.60 affix compression for aspell-nl. This is still incomplete, and also gives some warnings that need to be debugged by somebody speaking dutch. Seem harmless, and might be interesting for upstream, if active. I also suggest the new maintainer to take a look at http://dict-common.alioth.debian.org/ and subscribe to dict-common-dev mailing list there. That is a low traffic list and, even open, has little spam. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: aspell dictionaries depend on libaspell15 package name, that might change
On Thu, Jun 23, 2005 at 05:31:19AM +0300, Brian Nelson wrote: > Are there any good reasons to not do require dicts to be autobuild, > aside from having to do a transition? Not many, I think that even for today's low end computers aspell is behaving quite efficiently building hashes. I tried in a PII-350 and worked very reasonably. I do not expect people using aspell having less powerful computers. The only remaining drawback is that requires more disk space, but if computer is running with such space limitations, is problematic anyway, not only because aspell autobuilt dicts take more space (gzipped sources + hash instead of only hash). This will be less important once affix compression is implemented in all dicts. Still need to check this with one of the huge dicts, I think currently only aspell-gl-minimos uses this compression and works well. I have done some experiments with aspell-ca and aspell-nl and also seem to work well, but not yet tested in the slow computer. > > > But in that case I think is better if things are > > put in a non-versioned directory, so the dict location does not change > > in case of a non binary-compatible aspell upgrade, just hashes are > > autorebuilt. That could be something like > > > > /usr/lib/aspell-auto > > I'll buy that. I could change aspell to use /usr/lib/aspell-auto, and > the only thing that would break would be current dictionaries, right? > If a dictionary were not autobuilt but installed stuff into > /usr/lib/aspell-auto directly from the .deb, would aspell-autobuildhash > be able to cope? That is not an aspell-autobuildhash problem, but an aspell one, and it deals with this. Hashes built with aspell-autobuildhash will not be created there, but in /var/lib/aspell, with /usr/lib/aspell/$hash.rws -> /var/lib/aspell/$hash.rws symlinks. Is the same for aspell to find a symlink or the real hash. Everything else would be installed in /usr/lib/aspell. aspell-autobuildhash does not fiddle into that directory, but relies on /usr/share/aspell/$hash.mwl.gz and /var/lib/aspell/$hash.compat. > Of course, if both auto and non-auto dicts could share the > /usr/lib/aspell-auto, we might as well go back to just calling it > /usr/lib/aspell... Agreed, > > > If new hashes are sought for in a versioned dir, we would need to move the > > dicts links when a new binary incompatible aspell is uploaded, making things > > unnecesarily complicated. > > Yeah. The only real benefit from having a version in the directory name > is to support concurrent installs of incompatible aspells, which of > course we don't need... And that would require duplication of dicts for both versions, with some apps linked against one aspell and other against the other, and aspell-bin linked to only one. I think this would be a big mess with a poor benefit. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314622: Adopting dutch dicts + emacs21: ispell.el and dictionnary list
On Thu, Jun 23, 2005 at 12:30:16PM +0200, Pascal A. Dupuis wrote: > To get aspell-nl properly registred, I did the following: > > 1) extract the file idutch from package idutch, found under >/var/lib/dictionaries-common/ispell > 2) copied it as /var/lib/dictionnaries-common/aspell/aspell-nl > 3) ran /usr/sbin/update-dictcommon-aspell > > So, what's missing: > - the proper dictionnary definition aspell-nl > - postinst and postrm scripts which update the aspell dict list > Thanks for taking a look at this. You are right in the steps, but is better to add this in aspell-nl package directly. dutch dicts are currently orphaned, http://bugs.debian.org/314839 I already mailed the two interested persons about patches I had nearly ready for dutch dicts, one will deal only with registration and the other will also deal with affix compression (available for aspell 0.60). This second revealed some possible inconsistencies in the wordlist that might be of interest upstream. I am cc'ing these two persons now. I will reassign this bugreport to aspell-nl as soon as it has a new maintainer, I do not want to put noise on QA people in the meantime. If nodoby finally takes the package I will take it temporarily until finds a better (dutch speaking) home. Since seems I already have a working package, I have put dutch dicts at http://dict-common.alioth.debian.org/testing/ including both changes. Comments are welcome. A signed changes file is at the sources subdir. Thomas and Kurt: If you want I can upload the modified dutch package (of course with a correct version) or make the QA work for it until one of you takes it. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315876: [INTL:bg] New Bulgarian translation
On Sun, Jun 26, 2005 at 07:52:37PM +0300, Yavor Doganov wrote: > Package: dictionaries-common > Version: 0.30.0 > Severity: wishlist > Tags: patch l10n > > Attached is Bulgarian translation of the debconf template. > Thanks for your contribution. Committed to our CVS, will go in next upload. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: Notes On Building Aspell Dictionaries
On Thu, Jun 30, 2005 at 05:39:29AM -0600, Kevin Atkinson wrote: > > A few things to take into consideration. > > 1) To Minimize the Space Used The Word List Should be Compressed with > "prezip -s". (The "-s" is to resort the word list using the "C" local > which is needed for maximum compressed with prezip). And than further > compressed with bzip2. You can decompress it by piping it through "bzcat > | precat". To give you an idea on sizes using various methods here are > the file sizes for en-common.wl (.cwl is the word list compressed with > prezip) > > 1224 en-common.wl > 424 en-common.cwl > 136 en-common.cwl.bz2 > 164 en-common.cwl.gz > 432 en-common.wl.bz2 > 332 en-common.wl.gz > > yes bzip2 is WORSE than gzip on a sorted word list. > > Also prezip and friends consists of an ANSI C program and some shell > scripts which can easily be separated out into a separate package so that > you can also use them with Ispell if so desired. Thanks for the hints, Kevin I assume this applies only to non affix compressed wordlists. I think we should also encourage affix compression when possible, hash sizes are much better. Regarding bzip2, it implies adding another dependency. While most systems already have it installed I personally prefer using gzip, which must always be present, even if that implies a larger size. All the last tests I did were using plain gzip and affix compressed wordlists. Only the very first tests were done with gzipped raw (no prezip) wordlists. Since the system seems viable, I will add support for prezip/precat if wordlist name is of the form .cwl.gz. > > 2) To avoid spitting out a bunch of warnings during compile you should > clean it by piping it though "aspell clean strict". This will remove all > problem words and affix flags that Aspell will complain about when > compiling. The compiled dictionary should be the same with either the > dirty or the clean word list. You can also use "aspell clean" but that > but that handles some errors in a different way and the resulting compiled > dictionary may be different. > > 3) Aspell by defaults performs a number of checks when creating a > word list, some if these can be expensive. You can disable the expensive > one with "--dont-validate-affixes". If you clean the word list first this > should be 100% safe. It should also be safe to use on a dirty word list > as the invalid affix flags don't cause a problem in the compiled word > list. You may also consider using "--validate-words" but those checks are > not very expensive. This is very interesting info, I was worrying about the bunch of bug reports that would follow all those warnings about non applicable affix flags. Again, thanks for your feedback Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: Notes On Building Aspell Dictionaries
On Thu, Jun 30, 2005 at 11:27:48AM -0600, Kevin Atkinson wrote: > > I assume this applies only to non affix compressed wordlists. > > No it also helps with affix compressed word lists. Fine, I added today support for *.cwl.gz files to our aspell-autobuildhash branch. This should work for prezip+gzip affix compressed wordlists as long as they have that extension. > > > I think we > > should also encourage affix compression when possible, hash sizes are much > > better. > > If the language in question does not have does not have any sort of > soundslike data, than affix compression is a clear win; however, if > the language uses phonetic soundslike data (such as German, French, and > most importunately English) than the choice to enable affix compression > in the compiled hash table is much more difficult. Aspell will support > both affix compression and phonetic soundslike lookup but the results may > not be as good. Thus I, in general, don't recommend it. You should use > the settings in the official dictionary package. This seems something to be decided in a per dict basis and delegated on dict maintainers. For some dicts the replacements code might suffice, but for some others real phonetic code is needed. Not to mention sizes. When we played with an aspell version of the catalan dictionary, the hash file went over 100MB (yes, not a typo), but in my experiments with affix compression, I think it went below 4MB (not have the dict here). The choice at that time was to severely strip down the dictionary so the hash was manageable (I think was ~10MB). Brian, we should write something about this so dict maintainers have a clue. > > > Regarding bzip2, it implies adding another dependency. While most systems > > already have it installed I personally prefer using gzip, which must always > > be present, even if that implies a larger size. > > Well bzip2 is very common now and in fact my dictionary packages use bzip2 > and no one has complained yet. This sounds like a policy decision that > should possibly be discussed with other Debian developers (or whoever the > appropriate people are on policy decisions such as that). But that is for building the hash, that is usually done by dict package maintainer. In our case hash will be built by each user, so each user is forced to have bzip2 installed. The vast majority will have it, but I am rather reluctant to force that. And from other message, > > You may also consider using "--validate-words" but those checks are > > not very expensive. > That should be "--dont-validate-words". Thanks, I only added "--dont-validate-affixes", I tested only gl-minimos and ca, and catalan dict has some useless flags. Piping through "aspell clean strict" gave me a lot of errors on the 'point in the middle char' that is used in catalan as part of words, and I think that I had errors even on flag slashes in the affix compressed ispell wordlist. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#310590: Notes On Building Aspell Dictionaries
On Thu, Jun 30, 2005 at 06:08:28PM -0600, Kevin Atkinson wrote: > > This seems something to be decided in a per dict basis and delegated on dict > > maintainers. > > Yes that is why I suggest you use the settings in the official > Aspell dictionary package. If the Debian dictionary maintainer thinks > otherwise I would appreciate an email to that effect. We usually try to avoid duplicating sources, so many of the aspell dicts are not built from the official Aspell dictionary package, but from the original (usually ispell) wordlist + aff table, with some elements taken from the official Aspell dictionary package. Also the versioning of official Aspell dictionary packages makes difficult to know which is the involved upstream version, and doing things this way makes that more clear. Fixing things is also simpler this way. Unpackaging the .cwl, fixing things and repackaging would be problematic in our packaging system, that cannot represent binary diffs against the sources. I currently maintain only one aspell dict, aspell-gl-minimos, and is directly built from ispell-gl upstream sources instead of from the official Aspell package. I plan to try taking Debian aspell-es maintenance in the near future; since I maintain the espa~nol source package, that provides ispanish and myspell-es, all the required sources are already there (and more up to date, using espa~nol 1.8 instead of 1.7). Since this has no phonetic code, is a clear candidate for affix compression. Many other Debian aspell dicts are not built from the official Aspell packages, but from upstream sources, with stuff taken from aspell official dict package. I can think now of aspell-ca aspell-nl aspell-tl but I am sure there are more. I see that aspell6-ca in aspell.sf.net already uses affix compression and has a more up-to-date myspell aff file than the one at Debian ispellcat package for myspell. > You need to be sure to specify the correct language ie "aspell clean > strict -l " the set of warnings should be the same as when compiling > the word list, if not you did something wrong. Thanks, I missed -l [P.S., no need to cc me, I am subscribed to Debian aspell package mail] Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318917: dictionaries-common: [ispell.el]: Does not allow to safe word if it thinks is is a new composition
On Mon, Jul 18, 2005 at 06:25:41PM +0200, Frank Küster wrote: > Package: dictionaries-common > Version: 0.25.12 > Severity: normal > > Hi, Hi, Frank > > the word "Schaft" is not in the german ispell dictionary (it's meaning > is similar to the english "shaft", or stem). When running > ispell-whatever on a text containing the word, it offers a couple of > corrections, and it offers to record it as a "correct composition of the > derivative" 'Schaf+t'. This composition does not exist, but there is no > possibility to safe the word itself instead. Seems that even if ispell.el suggests that 'Shaft' might come from Schaf+t (that is, something in the form Schaf/FLAG), what is actually saved in ~/.ispell_ngerman is 'Schaft', the word, and not ROOT/AFFIX FLAG. At least that is what I find here. Is the same at your site? > > I'm not familiar with using ispell outside of Emacs, but it seems to me > as if ispell does not have the problem: > > $ ispell -d ndeutsch ispelltest.txt > Schaft File: ispelltest.txt > ... > 11: Schuft > ??: Schaf+t > > [SP] R)epl A)ccept I)nsert L)ookup U)ncap Q)uit e(X)it or ? for help > > Here it seems I can both use Schaf+t (??) or Insert the word "Schaft". ? will give you the help screen, not something substituting for Schaft. I do not see that this results in things being saved in the form ROOT/AFFIX FLAG. That ?? probably means for ispell some sort of call for attention, probably meaning that the word will be affix compressed if the personal wordlist is munched. Another thing is if Schaf+t is a correct derivative from the root Schaf with the german affix table, but that is an ingerman issue. Cheers, -- Agustin
Bug#318917: dictionaries-common: [ispell.el]: Does not allow to safe word if it thinks is is a new composition
On Tue, Jul 19, 2005 at 09:17:54AM +0200, Frank Küster wrote:
> Agustin Martin <[EMAIL PROTECTED]> wrote:
> > Is the same at your site?
>
> Yes, it seems so. This still means that the user interface is somewhat
> confusing, I have to give a linguistically wrong answer ("Yes, it is a
> composition") to get the word safed.
Agreed, I will probably make it something like
Use option 'i' if this is a correct composition from the derivative
root or the word is valid by itself.
But that will not be inmediate.
>
> > Another thing is if Schaf+t is a correct derivative from the root Schaf with
> > the german affix table, but that is an ingerman issue.
>
> I don't know, however, whether ispell can distinguish between nouns and
> verbs (based on the former's capitalization in german), or otherwise
> handle affixes word-specifically.
No, ispell knows only of roots, affixes and prfixes
Thanks for your feedback
Cheers,
--
Agustin
Bug#41741: ispell-autobuildhash?
On Thu, Mar 24, 2005 at 02:13:27PM +0100, Jonas Smedegaard wrote: > In this bugreport, and in changelog entry for 3.1.20.0-3, you mention > ispell-autobuildhash. I see the postinst code - but where is the actual > script? In dictionaries-common package. I have also been playing with an equivalent aspell-autobuildhash script (currently in the aspell-autobuildhash branch at alioth dict-common, not yet moved to HEAD) In the dictionaries-common source there is a modified (by me) version of Piotr update-ispell-hash script, just to have it at a public CVS. It includes some sort of dialog support, but I did not yet have enough time to extensively test it. > Oh, and Piotr: If you like cdbs, then have a look at my attempt at > making a dict snippet here: http://debian.jones.dk/auryn/pool/jones/dsdo/ > > The actual snippet is here: > http://debian.jones.dk/auryn/pool/jones/dsdo/debian/cdbs/1/class/dict.mk > > the goal is to make it universal, so input on requirements (also for > handling postinst hashing) are most welcome :-) Thanks, I will try to take a look at it. Cheers, -- Agustin (maintaining dictionaries-common) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299541: dictionaries-common: string not translatable in debconf templates
On Thu, Mar 24, 2005 at 09:31:20PM +0100, Denis Barbier wrote:
> Hi,
>
> I am not sure to fully understand what this choice is about, but maybe
> "${choices}, Do not modify current symlinks"
> is better?
>
Hi, Denis,
They might be not set.
The choice is about manually setting
/etc/dictionaries-common/default.{hash,aff} ->
/usr/lib/ispell/your_personally_built_dict.{hash,aff}
/etc/dictionaries-common/words ->
/usr/share/dicts/your_personally_gathered_wordlist
and honouring that selection. Otherwise they will be set after sysadmin
selection.
It is intended for advanced users needing/wanting manual settings for
whatever reason (see #293926: dictionaries-common needs a "don't muck with
my config files" option). For normal users 'Do not modify current symlinks'
is achieved by just pressing 'Enter' when installing a *new* dict (or by
having noninteractive debconf frontend selected).
'Do not modify current symlinks' looks like not requiring further action
from the sysadmin while it probably does, and also looks like being a
reasonably conservative option while really intended for skilled users. It
also does not make clear that you are entering a manual mode for that symlink
maintenance. However, the presence of the word 'manual' somewhat suggests
being for experienced users, so I tend to prefer the initial wording.
Thanks for your feedback,
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#299725: dictionaries-common: Can no longer customise case/non-case chars in Emacs
On Mon, Mar 28, 2005 at 03:06:53AM +0200, Reuben Thomas wrote:
> >* Blind guess: Was the original code filed as latin1 or utf8?
>
> What exactly do you mean? I think this may be something to do with it.
I meant that .emacs might have been erroneously saved as utf8 (that
sometimes happens, e.g., that recently happened to me with a .procmailrc
that tried to exclude some >128 chars combinations, and was accidentally
saved a utf8, so the strings were not correct and everything was messed up)
>
> I have just tried again. This time my .emacs file contained only the
> following:
>
> -
> (debian-ispell-add-dictionary-entry
> '("british+accs"
> "[A-Z\321\324a-z\361\364]"
> "[^A-Z\321\324a-z\361\364]"
> "[']"
> nil
> ("-B" "-d" "british-w_accents")
> nil
> iso-8859-1)
> "aspell")
>
> (setq ispell-dictionary-alist debian-ispell-dictionary-alist)
> --
>
> and I tried to run ispell-buffer on a Latin1 encoded file containing
> (shouldn't matter what the encoding of the file is, though, should it?
> Emacs takes care of this...).
Should not be a problem, as long as the encoding is known to emacs and can
be fully converted to the ispell dict encoding (expect misalignment errors
otherwise)
>
> --
> rôle
>
> Local Variables:
> ispell-program-name: "aspell"
> ispell-local-dictionary: "british+accs"
> End:
> --
>
> and it gave the error I complained about before.
I am completely puzzled by this, because is working like a charm here (in a
woody box, but I am sure ?? I tested it also in a sid box before Easter). Can
you
please add to your .emacs file
(setq debian-dict-common-debug "yes")
and see what is the related information in the messages buffer? Some keys to
what you will find there,
bfcs: buffer-file-coding-system
ecs: emacs coding system (mime charset of bfcs)
ics: ispell dict coding system
did: default Debian ispell dictionary
dad: default Debian aspell dictionary
ild: ispell local dictionary
Here I have:
did: nil
dad: nil
ild: british+accs
bfcs: iso-latin-1-unix
ecs: iso-8859-1
ics: iso-8859-1
I hope to have access tomorrow to my development sid box and retry
everything again.
Cheers,
--
Agustin
Bug#301524: wspanish don't upgrade, failure configure in sarge
On Sat, Mar 26, 2005 at 03:06:58PM +0100, Roberto wrote: > Package: wspanish > Version: 1.0.14 > > When I upgrade wspanish with apt-get in Sarge, after uncompressed > wspanish, apt-get gives error because: > > Can't call method "choices" on an undefined value at > /usr/share/perl5/Debconf/Question.pm line 85, line 5. > > and apt-get don't install wspanish. > > ¿is this a bug of wspanish? > > > I am using Debian GNU/Linux Sarge, kernel > 2.4.27-2-k7 Let me guess, is your /var partition nearly full? That seems debconf type 1 db corruption >From the (not yet uploaded) dictionaries-common README.problems file: === Problems removing a wordlist/ispell dictionary -- Something like --- # dpkg --purge wbritish (Reading database ... 111027 files and directories currently installed.) Removing wbritish ... Can't call method "choices" on an undefined value at /usr/share/perl5/Debconf/Question.pm line 85, line 4. dpkg: error processing wbritish (--purge): subprocess post-removal script returned error exit status 29 Errors were encountered while processing: wbritish --- is usually related to debconf type 1 db corruption, see e.g., http://bugs.debian.org/198297 or pages for bug reports 224400, 247849, 255193, 282587, 284287, 297534. Please take a look at those bug reports to check whether the problem is actually the same, and see if you can provide more information about the problem before proceeding further. As a side note, it has been pointed out that there is a high probability of this problem being related to a nearly full /var partition. After that, the suggested fix is, quoting Joey Hess message in above bug page > By purging and reinstalling the package, you only fixed the entries for > that package. I suggest you run /usr/share/debconf/fix_db.pl as root, > which will delete all the orphaned questions. You may end up having to > repeat your answers to some debconf questions during future upgrades, > but that's a small price to pay for a consistent debconf database. == While it deals with removal, seems the same problem. Unless not the case, I will reassign this bug report top debconf. Cheers, -- Agustin
Bug#301524: wspanish don't upgrade, failure configure in sarge
reassign 301524 debconf retitle 301524 debconf: type 1 db corruption when installing wspanish merge301524 198297 thanks On Mon, Mar 28, 2005 at 08:49:39PM +0200, Rober wrote: > El lun, 28-03-2005 a las 20:00 +0200, Agustin Martin escribió: > > On Sat, Mar 26, 2005 at 03:06:58PM +0100, Roberto wrote: > > > Package: wspanish > > > Version: 1.0.14 > > > > > > When I upgrade wspanish with apt-get in Sarge, after uncompressed > > > wspanish, apt-get gives error because: > > > > > > Can't call method "choices" on an undefined value at > > > /usr/share/perl5/Debconf/Question.pm line 85, line 5. > > > > > > and apt-get don't install wspanish. > > > > > > ¿is this a bug of wspanish? > > > > > > > > > I am using Debian GNU/Linux Sarge, kernel > > > 2.4.27-2-k7 > > > > Let me guess, is your /var partition nearly full? > > > > That seems debconf type 1 db corruption > > > Hi Agustin: > > Yes I have a nearly full /var partition; this morning, I did apt-get > clean, and I upgrade Sarge (I think that upgrade new version of debconf) > and then wspanish install and configure very well. Now, all is right. > > Thank you for your message. > > Sorry, my English is very bad, I'm Spanish. Me too ;-) I am reassigning this bug report to debconf and merging it with some other similar ones. Thanks for your feedback Saludos, -- Agustin
Bug#299725: dictionaries-common: Can no longer customise case/non-case chars in Emacs
On Tue, Mar 29, 2005 at 02:25:41AM +0200, Reuben Thomas wrote:
> >I meant that .emacs might have been erroneously saved as utf8 (that
> >sometimes happens, e.g., that recently happened to me with a .procmailrc
> >that tried to exclude some >128 chars combinations, and was accidentally
> >saved a utf8, so the strings were not correct and everything was messed up)
>
> OK, that definitely DID happen with my test .emacs. I fixed it with
> recode, and then (to avoid switching my .emacs around all the time) put
> it in a file called emacs.ispell and ran emacs with
>
That is the reason why is good to use the octal codes.
Anyway, I am back to my sid box with aspell-0.60 and could finally reproduce
your problem.
* When the problem appears?
When the aspell dict is built for a 'canonical' locale, but run from emacs
implicitely using a different one.
I was testing everything in my es_ES (iso-8859-1) locale and then
everything matched. For that reason I could not reproduce your problem.
* What is the reason for that problem?
With LANG=en_GB.UTF-8 when emacs calls aspell it implicitely expects utf8
and returns utf8. emacs however thinks the dict is iso-8859-1 and sends and
expects iso-8859-1. For that reason ispell-check rôle sends a iso-8859-1
string, but aspell returns an utf-8 string having what emacs thinks is a
two word string and complains about
Checking spelling of RÔLE...
ispell-word: Ispell and its process have different character maps.
or the equivalent problem you found for ispell-buffer. This happens with
aspell-0.60, but not with previous versions that had no utf8 support.
* How to ( quick & dirty ) work around this:
Set explicitely the communication encoding to the dict encoding, e.g.
;
(debian-ispell-add-dictionary-entry
'("british+accs"
"[A-Z\321\324a-z\361\364]"
"[^A-Z\321\324a-z\361\364]"
"[']"
nil
("-B" "-d" "british-w_accents" "--encoding=iso8859-1")
nil
iso-8859-1)
"aspell")
(setq ispell-dictionary-alist debian-ispell-dictionary-alist)
; ---
Please try if this works as seems to be working here. If so I will add this
mention to the README.emacs file.
I currently see no easy way of handling it more generally, unless there is
an option to aspell saying 'do not implicitely reencode after LANG' that
could be appended to ispell-program-name if appropriate.
But I do not see it.
Another possibility might be working out some table with the charset
namings equivalences and use it for aspell-0.60 to make sure the 'native'
encoding is used. I have to think about this.
I am cc'ing aspell maintainer to make sure he is aware of this problem.
Cheers,
--
Agustin
Bug#299725: aspell-0.60 + dictionaries-common: Can no longer customise case/non-case chars in Emacs
On Wed, Mar 30, 2005 at 04:15:48PM +0200, Reuben Thomas wrote:
> On Tue, 29 Mar 2005, Agustin Martin wrote:
>
> >Please try if this works as seems to be working here. If so I will add this
> >mention to the README.emacs file.
>
> Yes, this seems to work fine now.
Not yet added, until the best fix is clear.
> Why can't I just use "utf8" as the
> encoding in debian-ispell-add-dictionary-entry, though?
It should work (with utf-8, utf8 is not recognised by emacs as a mime charset)
as long as you put your casechars/non-casechars also in utf8 (even if you
put the octal codes, I think you need to put them for the utf-8 string
components). Otherwise you will get some errors,
(Next local Ispell command will use british+accs dictionary)
Starting new Ispell process... [2 times]
ispell-get-word: Invalid regexp: "Unmatched [ or [^"
In the meantime I noticed that aspell seems to accept encoding names in
the emacs mime-charset format, (e.g., iso-8859-1 intead of iso8859-1),
so another possibility is to try handling this from within ispell.el,
in pseudo-code something like
if (running_aspell){
append_to_args("--encoding=" . ispell-coding-system)
}
This will not work with the spellchecking program defined in the Local Vars
section (at least in my preliminary tests), but should work with it defined
in ~/.emacs.
I could make this be a bit more clever so is not used for aspell 0.33, but
this should not be a big problem, I doubt anybody is using the
dictionaries-common system in woody with aspell-0.33.
Unless Brian Nelson (aspell maintainer) suggests something better this seems
a promising way to go, since this problem might also be present for some of
the official dicts too.
There also is a huge patch flying around,
http://sourceforge.net/tracker/index.php?func=detail&aid=945391&group_id=245&atid=300245
to make all the ispell.el <-> aspell communication be done in the buffer
encoding, but since it is rather large, I prefer to wait for ispell.el
upstream reaction on it.
By the way, I remembered that Brian was subscribed to the dictionaries-common
package, no need to cc him. Just slightly changing bug's title to attract his
attention.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#314714: dictionaries-common: debconf asks me question with absurd choice
tag 314714 +unreproducible tag 314714 +moreinfo thanks On Tue, Jun 21, 2005 at 02:20:58PM +0200, Agustin Martin wrote: > > I am waiting for the DEBUG output. Thanks for your feedback > Hi, Branden, Since I received no more feedback on this and I cannot reproduce the problem at all I am tagging this bug report as unreproducible and moreinfo. If this is a real problem it should hit a lot of people, so I should receive more evidences of it in some time. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317422: wbritish-large: sightlines/metallicity
reassign 317422 wbritish-large thanks On Fri, Jul 08, 2005 at 09:02:12PM +1000, Tim Connors wrote: > Package: dictionaries-common > Version: 0.30.1 > Severity: normal > > > look sightline > > sightliness > sightliness's > > Sightline is a word we use in astronomy a bit. Sightlines is also > valid usage. > > Sightliness is something that hadn't even occurred to me, but of > course it means: The state of being sightly; comeliness; > conspicuousness. > > Sightliness's ?? I don't think that can be valid? > > > I have also found that some dictionaries contain metallicity, and > thought I had seen it in /usr/share/dict/words somewhere, but it is > not in the british-large dictionary. Thanks for the info, dictionaries-common package has no wordlists by itself, just provides some common elements for spellchecking related packages. Since you have british-large selected as default wordlist I assume that is the place for this bug report. For that reason I am reassigning this bug report to wbritish-large -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317775: flyspell-buffer fails using aspell error: Can't check region
On Mon, Jul 11, 2005 at 02:33:22PM +0200, Martin Leopold wrote: > Package: emacs21 > Version: 21.4a-1 > > Hi. > After not using flyspell for some time I noticed that it had stopped > functioning since I tried it last. It is quite possible that I upgraded > emacs, flyspell, aspell or some combination since last time. As of aspell 0.60 'aspell -l' option is no longer equivalent to list. For large buffers flyspell runs 'aspell -l' to get a list of mispellings and fails. This will be fixed when a patched flyspell is included in the dictionaries-common policy. There is some new stuff in dictionaries-common I would like to have extensively checked before passing to adding flyspell. I would also prefer to monitor emacs and xemacs CVS before and wait a bit to make sure last upstream flyspell.el is mature enough. That means do not expect big changes in approx 1 month. Rob, if in the meantime you want to fix this in emacs, let me know so I provide you with the appropriate patch. -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317950: ftp.debian.org: Please remove aspell-es source package
Package: ftp.debian.org Severity: normal As of espa-nol_1.8-4, just accepted into the pool, aspell-es binary package is built from the espa-nol source package, together with ispanish and myspell-es. The old aspell-es source package is now obsolete and can be removed. In particular, source aspell-es_1.8-3, uploaded today to make sure the maintainer name is changed (seemed to take longer than expected) needs to be removed, together with appropriate links. Could you please remove aspell-es source package from unstable? aspell-es source package will still be present in sarge. Thanks in advance, -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27 Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1) -- Agustin signature.asc Description: Digital signature
Bug#284078: acknowledged by developer (Bug #284078: closing. Not a bug.)
Alastair McKinstry <[EMAIL PROTECTED]> wrote: > > On further examination, I am confirming that this is not a bug in > whiptail, and am closing this bug. > > whiptail interprets all arguments starting with '-' as options, and > gives errors accordingly. If you wish to have arguments which start with > a dash, you must first precede the last non-option argument with '--' , > e.g. Thanks for taking care of this. > This works as desired in both whiptail and dialog. I have documented > this in the whiptail man page. Excellent, after your debugging the only remaining stuff was this documentation clarification. This completely closes the bug report. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304388: lirc-modules-source: Does not compile: cut: modules/*.ko.KVERS: No such file or directory
On Sat, Apr 16, 2005 at 09:17:04PM +0200, Agustin Martin wrote: > On Fri, Apr 15, 2005 at 09:52:23PM +0200, Hadmut Danisch wrote: > > > > >Did you select any drivers? > > > > sure, the usb driver. > > That was not in the debconf entry I pointed out, > > I guess you added it (atiusb) manually, but unfortunately that entry > is known to be buggy in the Makefile > > http://bugs.debian.org/300989 > > Can you please try the patch I proposed to lirc maintainers in that > bug www page? > > That Makefile is what should go into /usr/src/modules/lirc/Makefile Hi, Hadmut I finally found the same problem when recompiling my kernel modules. I have been playing with the Makefile and it seems to now be dealing with that problem. I am attaching the modifled Makefile in case you want to give it a try. It should go as /usr/src/modules/lirc/Makefile. As usual, take with care. If you try it please report results to this bug report address. Amaya, There are some other modifications in the Makefile, that should close #300989, #303663, and #304609 bugs, besides this #304388. I am attaching the full Makefile, since it is not that bigger than diff -u and this way is easier to evaluate the changes. Cheers, -- Agustin include /etc/lirc/lirc-modules-source.conf # An space should be left at the end of each CFLAGS variable for the # sanity-check to work. SERIAL_CFLAGS := $(subst ",,$(LIRC_SERIAL_CFLAGS) \ -DLIRC_PORT=$(LIRC_SERIAL_PORT) \ -DLIRC_IRQ=$(LIRC_SERIAL_IRQ) ) SIR_CFLAGS := $(subst ",,$(LIRC_SIR_CFLAGS) \ -DLIRC_PORT=$(LIRC_SIR_PORT) \ -DLIRC_IRQ=$(LIRC_SIR_IRQ) ) PARALLEL_CFLAGS := $(subst ",,-DLIRC_PORT=$(LIRC_PARALLEL_PORT) \ -DLIRC_TIMER=$(LIRC_PARALLEL_TIMER) \ -DLIRC_IRQ=$(LIRC_PARALLEL_IRQ) ) i2c_MAKEFLAGS="-e" gpio_MAKEFLAGS="-e" it87_MAKEFLAGS="-e" bt829_MAKEFLAGS="-e" KSRC=/usr/src/linux/$(shell uname -r)/build KERNEL_LOCATION = $(KSRC) CC = gcc -D__KERNEL__ -I $(KSRC)/include CFLAGS= -O2 -g -Wall DEFS=-DHAVE_CONFIG_H -I. -I../.. KVERS=$(shell sed -n -e '/UTS_RELEASE/s/^[^"]*"\([^"]*\)".*$\/\1/p' $(KSRC)/include/linux/version.h) KPATCHLEVEL=$(shell echo $(KVERS) | sed -n -e 's/^[0-9]*\.\([0-9]*\)\..*/\1/p') KEXT=o ifeq ($(KPATCHLEVEL),6) KEXT=ko endif export KERNEL_LOCATION CC alldrivers = atiusb i2c gpio it87 bt829 serial parallel sir comma := , all: $(alldrivers) test: @echo '$(LIRC_SERIAL_IRQ)' @echo $(LIRC_SIR_IRQ) @echo $(LIRC_PARALLEL_IRQ) @echo $(SERIAL_CFLAGS) @echo $(SIR_CFLAGS) @echo $(PARALLEL_CFLAGS) UNCONFIGURED: #Do nothing if the user didn't configure which drivers to build #debconf: $(subst ", ,$(LIRC_MODULES:,=)) debconf: $(subst $(comma), ,$(subst ", ,$(LIRC_MODULES))) modules: mkdir modules sanity-check: @if \ expr "$(DEFS)" : '.* -DLIRC_IRQ= ' > /dev/null\ || expr "$(DEFS)" : '.* -DLIRC_PORT= ' > /dev/null \ || expr "$(DEFS)" : '.* -DLIRC_TIMER= '> /dev/null \ || expr "$(DEFS)" : '.*UNCONFIGURED'> /dev/null;\ then \ echo ;\ echo "##";\ echo "## CONFIGURATION ERROR: ##";\ echo "##";\ echo ;\ echo "You should reconfigure lirc-modules-source and make";\ echo "sure you don't leave blank any one of IRQ, IO Port or ";\ echo "Timer (parallel only)";\ echo ;\ echo "Hint1: use \"dpkg-reconfigure lirc-modules-source\"";\ echo "Hint2: If you selected \"automagical\" configuration of";\ echo " kernel modules you should probably reconfigure lirc";\ echo " instead.";\ echo "Hint3: you may instead edit /etc/lirc/lirc-modules-source.conf";\ exit 1;\ fi lirc_dev: modules sanity-check $(MAKE) -e -C drivers SUBDIRS="lirc_dev" mv drivers/lirc_dev/lirc_dev.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_dev.$(KEXT).KVERS atiusb: modules sanity-check lirc_dev $(MAKE) -e -C drivers SUBDIRS="lirc_atiusb" mv drivers/lirc_atiusb/lirc_atiusb.$(KEXT) modules @echo $(KVERS) $(KSRC) > modules/lirc_atiusb.$(KEXT).KVERS i2c: modules sanity-check lirc_dev $(MAKE) -e -C drivers
Bug#304388: lirc-modules-source: Does not compile: cut: modules/*.ko.KVERS: No such file or directory
On Tue, Apr 12, 2005 at 10:10:23PM +0200, Hadmut Danisch wrote: > Hi, > > I try to build the debian packages from the source: > > # debian/rules binary-modules KSRC=/mnt/andromeda/homx/root/linux-2.6.11 > sed -e "s!\$KVERS!`sed -n -e '/UTS_RELEASE/s/^[^"]*"\([^"]*\)".*$/\1/p' > /mnt/andromeda/homx/root/linux-2.6.11/include/linux/version.h`!g; > s!\$KSRC!/mnt/andromeda/homx/root/linux-2.6.11!; s!\$KARCH!i386!; > s!\$KEMAIL!!; s!\$KMAINT!!; s!\$KDREV!"Custom.1.00"!; s!\$DEBDATE!Di, 12 Apr > 2005 22:07:35 +0200!" debian/control.in > debian/control > dh_testdir > dh_testroot > dh_clean -k > dh_installdirs > # Add here commands to install the package into debian/lirc-modules. > /usr/bin/make install prefix=/usr/src/modules/lirc/debian/lirc-modules-`sed > -n -e '/UTS_RELEASE/s/^[^"]*"\([^"]*\)".*$/\1/p' > /mnt/andromeda/homx/root/linux-2.6.11/include/linux/version.h` > make[1]: Entering directory `/usr/src/modules/lirc' > cut: modules/*.ko.KVERS: No such file or directory > make[1]: *** [install] Error 1 > make[1]: Leaving directory `/usr/src/modules/lirc' > make: *** [install] Error 2 > > Any idea? > > * lirc-modules-source/drivers: Did you select any drivers? # dpkg-reconfigure lirc-modules-source If this is indeed the problem debian/rules should fail more gracefully with a useful error message. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334752: dictionaries-common: Emacs startup file shouldn't set user settings
On Wed, Oct 19, 2005 at 01:23:28PM -0400, Peter S Galbraith wrote: > Package: dictionaries-common > Version: 0.24.10 > Severity: normal > File: /etc/emacs/site-start.d/50dictionaries-common.el > > Hi, > > For reference, see: > > http://lists.debian.org/debian-emacsen/2005/10/msg00036.html > > The file /etc/emacs/site-start.d/50dictionaries-common.el sets some user > settings as: > > (if (or (eq window-system 'x) (eq window-system 'gtk)) > (progn > (setq ispell-menu-xemacs nil) > (ispell-change-dictionary nil) > ) > ) > > > It would be preferable that Emacs user configuration preferences not > be done in a system file (which users don't have the privileges to edit) > but rather through the use of an Emacs customization variable > (defcustom). > > I realize that this isn't an Emacs package and you may not have the > skills to implement this. Let me know if a patch is required. Thanks for the report and the offer, The problem here is that the default behavior should be to refresh emacs spellcheck pop-up menu on calling the above code, so it shows the really available dictionaries, and the optional one not to do that, at least in X environments. If I am not wrong, ~/.emacs is loaded last, so I do not think that can be done straighforward from ~/.emacs at the stage it is loaded. Thinking again about this, some sort of final hook might be useful, provided it is available for both emacs and xemacs. Do you think that after-init-hook would be appropriate for this? Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334752: dictionaries-common: Emacs startup file shouldn't set user settings
On Wed, Oct 19, 2005 at 09:39:29PM +0200, Agustin Martin wrote: > On Wed, Oct 19, 2005 at 01:23:28PM -0400, Peter S Galbraith wrote: > > Package: dictionaries-common > > Version: 0.24.10 > > Severity: normal > > File: /etc/emacs/site-start.d/50dictionaries-common.el ... > > It would be preferable that Emacs user configuration preferences not > > be done in a system file (which users don't have the privileges to edit) > > but rather through the use of an Emacs customization variable > > (defcustom). > > > > I realize that this isn't an Emacs package and you may not have the > > skills to implement this. Let me know if a patch is required. > > Thanks for the report and the offer, > > The problem here is that the default behavior should be to refresh emacs > spellcheck pop-up menu on calling the above code, so it shows the really > available dictionaries, and the optional one not to do that, at least in X > environments. If I am not wrong, ~/.emacs is loaded last, so I do not think > that can be done straighforward from ~/.emacs at the stage it is loaded. > > Thinking again about this, some sort of final hook might be useful, provided > it is available for both emacs and xemacs. Do you think that after-init-hook > would be appropriate for this? I hope something like the code below (in debian-ispell.el) should help with this (only minimally tested) - snip ;;; -- ;;; Handle ispell.el load at startup ;;; -- (defcustom debian-ispell-load-on-startup-nox nil "*Load ispell on startup for console mode sessions" :type 'boolean :group 'ispell) (defcustom debian-ispell-load-on-startup-x t "*Load ispell on startup for X sessions" :type 'boolean :group 'ispell) (defun debian-ispell-load-on-startup () (if (or (and (or (eq window-system 'x) (eq window-system 'gtk)) debian-ispell-load-on-startup-x) (and (not window-system) debian-ispell-load-on-startup-nox)) (progn (setq ispell-menu-xemacs nil) (ispell-change-dictionary nil))) ) (add-hook 'after-init-hook 'debian-ispell-load-on-startup) - snip and make it really an user option, allowing us to remove the problematic code from the startup file (Yes, I also do not like that file to be user editable). Suggestions are welcome, Cheers -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334752: dictionaries-common: Emacs startup file shouldn't set user settings
On Wed, Oct 19, 2005 at 04:13:44PM -0400, Peter S Galbraith wrote:
>
> Well, I'm not sure that is actually a problem, but... Tell you what, I
> now understand better what the code is about. It's isn't really a user
> option at all, and should be done. So forget my initial report!
I also do not like those emacs startup files be configurable, and agree that
if possible we should take this outside the initialization files to the user
options area. I have just sent another mail with a possible fix for this.
>
> The undesired side-effect of loading ispell is unfortunate. You're
> saying you have to load ispell.el to make "Spell Checking" menu list
> within the "Tools" menu? I notice that by default ispell isn't loaded
> and has a more elaborate menu. Can the code required to regenerate the
> menu correctly be added to 50dictionaries-common.el without loading all
> of ispell?
The problem is that the code is in loaddefs.el, and that is where the menu
is built. I do not know how to modify that menu from outside, but I fear I
would need at least non small parts of ispell.el. I really never looked into
this, and I do not consider my current lisp skills enough for that, for
somebody more skilled, this might be easier, but I never fiddled with
{x}emacs pop-up menus.
>
> If so, then that's my bug report.
> If not, feel free to close this and sorry for waisting your time!
Not a time waste at all, that is a real (minor) problem. I think that
making that load user-configurable would at least make things much
better.
If the proposed fix for this last works, do you prefer to leave this bug
report open for the menu part, or should I just close it on upload?
Anyway, Peter, thanks for your feedback and comments. They are all welcome.
Cheers,
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334752: dictionaries-common: Emacs startup file shouldn't set user settings
On Wed, Oct 19, 2005 at 10:48:16PM +0200, Agustin Martin wrote:
> I hope something like the code below (in debian-ispell.el) should help with
> this (only minimally tested)
>
> - snip
>
> ;;; --
> ;;; Handle ispell.el load at startup
> ;;; --
...
> (defun debian-ispell-load-on-startup ()
> (if (or (and (or (eq window-system 'x)
> (eq window-system 'gtk))
> debian-ispell-load-on-startup-x)
> (and (not window-system)
> debian-ispell-load-on-startup-nox))
> (progn
> (setq ispell-menu-xemacs nil)
> (ispell-change-dictionary nil)))
> )
...
Just a minor change here,
(defun debian-ispell-load-on-startup ()
(if (or (and (not window-system)
debian-ispell-load-on-startup-nox)
(and window-system
debian-ispell-load-on-startup-x))
(progn
(setq ispell-menu-xemacs nil)
(ispell-change-dictionary nil)))
)
emacs is running in a window system unless window-system is nil.
I have tested this setup using after-init-hook and seems to be working
pretty well for both {x}emacs. Committed this first cut to our cvs.
On Thu, Oct 20, 2005 at 09:28:35AM -0400, Peter S Galbraith wrote:
> Let me look at this this evening (or soon anyway). I think it can be
> done without using after-init-hook.
Thanks Peter, I will wait for your feedback
--
Agustin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335612: debconf question asked on every upgrade
tag 335612 moreinfo thanks On Tue, Oct 25, 2005 at 01:33:10AM +0200, Artur R. Czechowski wrote: > Package: dictionaries-common > Version: 0.60.1 > Severity: normal > > Hello, > Everytime I upgrade any wordlist or ispell dictionary I am asked about > my preferred language. It is rather annoying, especially because if > upgrade of two languages is done at the same time I am being asked about > it twice. Or even three times (or more) if it's a really bad day ;) > Could you, please, remember a given answer and ask it only if a list > of installed dictionaries/wordlist is a subject to change? Hello, Artur I cannot reproduce that here. Your desired behavior is what I get here and what current code should do. # LANG=C apt-get install --reinstall ipolish Reading package lists... Done Building dependency tree... Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0B/886kB of archives. After unpacking 0B of additional disk space will be used. Do you want to continue [Y/n]? Preconfiguring packages ... (Reading database ... 131459 files and directories currently installed.) Preparing to replace ipolish 20051023-1 (using .../ipolish_20051023-1_all.deb) ... Unpacking replacement ipolish ... Setting up ipolish (20051023-1) ... Processing dict: polish --- with ipolish previously installed (and many other dicts), I get no questions at all. Can you please run something like # LANG=C DEBCONF_DEBUG=developer apt-get install --reinstall ipolish and send the transcript to the bug page? -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#320078: whiptail is unable to handle special characters not present in current locale
On Wed, Jul 27, 2005 at 09:11:21AM -0400, Thomas Dickey wrote:
> On Wed, Jul 27, 2005 at 02:50:06PM +0200, Micha Lenk wrote:
> > Is it even not possible to prevent the user from entering non-locale
> > characters? As a user I would prefer to get multiple other but legal
> > characters when I enter a non-locale character, wich I am able to delete
> > just after. In cases where I enter such a non-locale character by
> > accident I would at least be able to correct my mistake.
>
> There are two cases: displaying data that it reads from some other location
> and data entered from the keyboard. whiptail should of course distinguish
> between the two. If it cannot at least let you delete the keyboard entry,
> that's a defect in whiptail.
Hi, Alastair
Regarding this I would like to point to a closely related problem that
should probably fit into this bugreport (please let me know if you prefer me
to open a new one).
When some utf-8 text is injected into whiptail, and seen from a single byte
environment, utf8 strings are shown as a concatenation of the single byte
chars, not funny, but really the expected behavior. However, when
those single byte chars contain any char that is not displayable in the
local encoding, whiptail seems to be confused in menu items, and anything
after that char is skipped on display for that item, although if selected
returns the complete string as expected. Surprisingly in text the
non-displayable char is shown as a code, and further text is properly
displayed, what seems acceptable.
I am attaching a sample script to reproduce that, to be run in a latin1
environment. It contains bulgarian in cyrillic followed by a 7bit string,
"$the_utf8_string means bulgarian" and displays it both as text and as
a menu item. The problem is that the utf8 string contains \212, which is
not displayable for latin1, as fourth char, and some similar chars
afterwards, so menu is shown as (what is in square brackets is what should
be the first menu item, after non-displayable->something)
-
Here goes the text with
[бÑ<8A>лгаÑ<80>Ñ<81>ки means bulgarian]
бÑ
normal text
-
and in menu item everything after \212 is ignored, and only Ð±Ñ is
shown in that item.
dialog works as expected, but on display replaces non-displayable chars by ~
Cheers,
--
Agustin
#!/bin/sh
# -*- coding: utf-8 -*-
: ${DIALOG=whiptail}
tempfile=`tempfile 2>/dev/null` || tempfile=/tmp/test$$
trap "rm -f $tempfile" 0 1 2 5 15
function analyze {
retval=$1
option=$2
case $retval in
0)
echo "[`cat $tempfile`] chosen fror $option";;
1)
echo "Cancel pressed.";;
255)
if test -s $tempfile ; then
cat $tempfile
else
echo "ESC pressed."
fi
;;
esac
}
text="бÑлгаÑÑки means bulgarian"
#--msgbox text height width
$DIALOG --msgbox "$text" 30 50
# --menu text height width menu-height [ tag item ] ...
$DIALOG --menu "Here goes the text with\n[$text]" 30 50 20 "$text" "" "normal
text" "" 2> $tempfile
analyze $? --menubox
