Bug#858500: diff NMU for sanlock_3.3.0-2.1

[Milan Zamazal]

Anton Gladky  writes:

> If you are agree with this upload, I can reschedule it to day/0 and
> let it be built right now.

Yes, I agree.

Thanks,
Milan

Bug#858500: diff NMU for sanlock_3.3.0-2.1

[Milan Zamazal]

Anton Gladky  writes:

> I have prepared an NMU (versioned as 3.3.0-2.1) and
> uploaded to DELAYED/5.

Thank you very much for the NMU!

Regards,
Milan

Bug#843922: stockfish: FTBFS: g++: error: unrecognized command line option '-m32'

[Milan Zamazal]

> "SJ" == Sven Joachim  writes:

SJ> I haven't looked at the stockfish source, but I can imagine that
SJ> this is not going to improve the situation on 32-bit arches.  If
SJ> the config machinery cannot find out the pointer size by itself,
SJ> dpkg-architecture provides DEB_HOST_ARCH_BITS for you.

Thanks for the tip, applied.

SJ> Inspecting the build system I found out that there is no config
SJ> machinery, just a Makefile.  The attached patch fixes the
SJ> problem for the usual build in Debian, although you might want
SJ> to fix some other code paths as well (e.g. if someone builds
SJ> with COMP=clang).

Thanks for the patch, indeed, there's no need to use the option with (at
least) g++.  Applied.

Regards,
Milan

Bug#843922: stockfish: FTBFS: g++: error: unrecognized command line option '-m32'

[Milan Zamazal]

Thanks for the report.  I changed the default build architecture to
general-64, I guess that's a good default these days.  Let's see what
happens (I'm afraid this package will require a bit more experiments
before it builds on all architectures, sorry about that).

Regards,
Milan

-- 
http://www.zamazal.org

Bug#782005: ovirt-guest-agent spu

[Milan Zamazal]

"László Böszörményi (GCS)"  writes:

> Please use the following: dget -x
> http://www.barcikacomp.hu/gcs/ovirt-guest-agent_1.0.10.2.dfsg-2+deb8u1.dsc

Thank you.  I checked it and:

- It works for me with sysvinit.

- With systemd, there is the same permission problem as in unstable with
  /var/log/ovirt-guest-agent.  If I fix the directory owner then it
  works for me.  Probably worth to add that fix to stable as well?

Thanks,
Milan

Bug#782005: ovirt-guest-agent spu

[Milan Zamazal]

László Böszörményi (GCS)  writes:

> [1] dget -x 
> http://http.debian.net/debian/pool/main/o/ovirt-guest-agent/ovirt-guest-agent_1.0.10.2.dfsg-2.dsc

Is the URL correct?  This is the package from February 2015, isn't it?

Bug#754177: stumpwm does not work if `cl-asdf' is not installed.

[Milan Zamazal]

 EL == Emilio Lopes ec...@gmx.net writes:

EL after installing `stumpwm' I could not start the window manager.  There
EL was some error message mentioning `asdf', which was *not* installed.

EL Note that `cl-asdf' is not `required' by `stumpwm', just `recommended'.

EL After `cl-asdf' was installed, I could start `stumpwm' as expected.

Stumpwm can run on different Common Lisp implementations and perhaps not
all of them require cl-asdf to run Stumpwm.  So Stumpwm shouldn't depend
on cl-asdf.  Recommended packages should be installed unless you know
what you're doing, see Debian Policy:

  The `Recommends' field should list packages that would be found
  together with this one in all but unusual installations.

So I'd say `Recommends: cl-asdf' is OK here.  Do you think otherwise?


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#752726: stumpwm: FTBFS - SIGSEGV cannot be cured.

[Milan Zamazal]

It looks like a CLISP bug to me, so I've reassigned it to clisp.
FWIW, it doesn't crash on my system when built using cowbuilder.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725513: xprintidle: FTBFS: required file './compile' not found

[Milan Zamazal]

 HY == Hideki Yamane henr...@debian.or.jp writes:

HY Attached patch would fix this FTBFS, could you consider to apply
HY it, please?

Thanks for the patch, I'll try to handle it soon.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#694676: Bug#693472: emacsen-common, emacs23: many emacs addons fail to install if emacs22 (lenny) is still installed

[Milan Zamazal]

 AM == Agustin Martin agmar...@debian.org writes:

AM I am attaching a patch that may help here with speechd-el. For
AM emacs21 and emacs22 it checks if a standalone eieio package is
AM installed and otherwise warns and skips byte-compilation for
AM that flavour.

Thanks for the patch.  Nevertheless I dropped support for old Emacsen
completely as current speechd-el should be run on Emacs = 23.2.  The
compilation would still fail with Emacs 23.1 but that one is not a part
of any official Debian release, so I didn't bother to handle it.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666648: slime: FTBFS: mkdir: cannot create directory `././sbuild-nonexistent': Permission denied

[Milan Zamazal]

 CE == Christoph Egger christ...@debian.org writes:

CE This one looks like writing to $HOME which is not allowed and
CE will not fail in a cowbuilder environment normally. Would be
CE easy to test building with HOME=/something-not-existing

Thanks for explanation, indeed it's the case.  I'll try to set HOME to
some of the package build directories as a workaround.




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#666648: slime: FTBFS: mkdir: cannot create directory `././sbuild-nonexistent': Permission denied

[Milan Zamazal]

 LN == Lucas Nussbaum lu...@lucas-nussbaum.net writes:

LN Source: slime
LN Version: 1:20111027-2
LN Severity: serious
LN Tags: wheezy sid
LN User: debian...@lists.debian.org
LN Usertags: qa-ftbfs-20120331 qa-ftbfs
LN Justification: FTBFS on amd64

LN Hi,

LN During a rebuild of all packages in sid, your package failed to build on
LN amd64.

[...]

 kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 
tcrm1000
 mkdir: cannot create directory `././sbuild-nonexistent': Permission 
denied
 mkdir: cannot create directory `././var/cache/fonts/pk': Permission 
denied
 mktexpk: /usr/share/texlive/texmf/web2c/mktexdir 
/var/cache/fonts/pk/ljfour/jknappen/ec failed.
 kpathsea: Appending font creation commands to missfont.log.
 s/map/pdftex/updmap/pdftex.map}] (./slime-refcard.aux) )
 !pdfTeX error: pdflatex (file tcrm1000): Font tcrm1000 at 600 not found
 == Fatal error occurred, no output PDF file produced!
 /usr/bin/texi2dvi: pdflatex exited with bad status, quitting.
 make[1]: *** [slime-refcard.pdf] Error 1

Current slime version builds fine in my current cowbuilder on amd64.
Perhaps it was a bug in another package which got fixed in the meantime?




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#623565: speechd-el: installation fails: make: *** [braille.elc] Error 255 / emacs-install failed

[Milan Zamazal]

speechd-el doesn't work with Emacs 23.3.  Reported upstream.

Thanks for the bug report.




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#611711: speech-dispatcher: Logrotate file breaks other packages configuration

[Milan Zamazal]

I believe the fix is trivial, but it seems I don't have working squeeze
compilation environment available to build the package properly now and
I don't have time to fix it today.  So please anybody feel free to make
NMU if you can and to contact the release team.  The fix is attached.

Thanks for the report.

commit d502393fb04706c80e3aa6d608d0d6bee7ef4927
Author: Milan Zamazal p...@debian.org
Date:   Wed Feb 2 17:34:32 2011 +0100

Fix logrotate script breaking logrotate configuration of other packages (#611711)

diff --git a/debian/changelog b/debian/changelog
index c6835c1..7159ae5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+speech-dispatcher (0.7-7) unstable; urgency=low
+
+  * Fix logrotate script breaking logrotate configuration of other
+packages; closes: #611711.
+
+ -- Milan Zamazal p...@debian.org  Wed, 02 Feb 2011 17:33:51 +0100
+
 speech-dispatcher (0.7-6) unstable; urgency=low
 
   * Make flite output working again; thanks to Samuel Thibault
diff --git a/debian/speech-dispatcher.logrotate b/debian/speech-dispatcher.logrotate
index 3fafd5c..f35cc91 100644
--- a/debian/speech-dispatcher.logrotate
+++ b/debian/speech-dispatcher.logrotate
@@ -1,9 +1,8 @@
-daily
-compress
-missingok
-sharedscripts
-
 /var/log/speech-dispatcher/speech-dispatcher.log /var/log/speech-dispatcher/speech-dispatcher-protocol.log {
+  daily
+  compress
+  missingok
+  sharedscripts
   rotate 7
   postrotate
 /etc/init.d/speech-dispatcher reload /dev/null
@@ -11,6 +10,10 @@ sharedscripts
 }
 
 /var/log/speech-dispatcher/debug-epos-generic /var/log/speech-dispatcher/debug-festival /var/log/speech-dispatcher/debug-flite {
+  daily
+  compress
+  missingok
+  sharedscripts
   rotate 2
   postrotate
 /etc/init.d/speech-dispatcher reload /dev/null

Bug#592720: dictionaries-common: flyspell.el breaks flyspell-mode

[Milan Zamazal]

Package: dictionaries-common
Version: 1.5.11
Severity: serious

dictionaries-common distributes flyspell.el that breaks flyspell-mode
in emacs 23.1+1-5.  When I call `M-x flyspell-mode' in my Emacs, I
receive error message

  Enabling Flyspell mode gave an error

and flyspell mode doesn't work.  I have to load the original Emacs
flyspell.el to make flyspell-mode working again.

(IMHO dictionaries-common, serving as a base package for important
packages depending on them, shouldn't override standard Elisp files
without being requested to do so.  Its main purpose is different than
changing Emacs behavior and doing so should be disabled, and not
enabled, by default.  Changing Emacs behavior is extra functionality of
the package which should be enabled only when the user actually wants
it, especially when it's not for the first time when dictionaries-common
breaks spelling in Emacs and it's not straightforward to detect the
cause of the problem for the user.)

I mark this bug as release critical because it breaks an unrelated
package and it should be fixed before squeeze release.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (910, 'testing'), (900, 'stable'), (400, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-vserver-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dictionaries-common depends on:
ii  debconf [debconf-2.0] 1.5.33 Debian configuration management sy
ii  libtext-iconv-perl1.7-2  converts between character sets in

dictionaries-common recommends no packages.

Versions of packages dictionaries-common suggests:
ii  emacsen-common1.4.19 Common facilities for all emacsen
ii  ispell3.1.20.0-7 International Ispell (an interacti
pn  jed-extra none (no description available)

-- debconf information:
  dictionaries-common/invalid_debconf_value:
  dictionaries-common/selecting_ispell_wordlist_default:
* dictionaries-common/default-ispell: american (American English)
  dictionaries-common/default-wordlist:
  dictionaries-common/ispell-autobuildhash-message:
  dictionaries-common/old_wordlist_link: true
  dictionaries-common/move_old_usr_dict: true
  dictionaries-common/remove_old_usr_dict_link: false




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#577217: Speech dispatcher is still started by default = raison for clsoing is wrong

[Milan Zamazal]

When I install speech-dispatcher = 0.7 for the first time, it is not
started by default.  If it is not installed for the first time, it is
naturally still started by default as before (assuming that if it was
running before, it should remain running and not suddenly disappear).

Do you observe different behavior?  Or do you think it should behave
otherwise?




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#577896: [PATCH] speech-dispatcher: FTBFS: flite.c:435: undefined reference to `register_cmu_us_kal'

[Milan Zamazal]

 AM == Andres Mejia mcita...@gmail.com writes:

AM Here's a patch that will fix the build failure. flite-1.4 now
AM uses new_voice() instead of register_cmu_us_kal().

Thanks for the patch.  I've applied it and uploaded.  Speech Dispatcher
doesn't work for me now, but I don't know whether it is caused by this
change or something else.  I'll investigate it once new upstream version
is released (which should hopefully happen soon).




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#577217: [PATCH] speech-dispatcher locks main audio pcm preventing other apps to use sound

[Milan Zamazal]

 AM == Andres Mejia mcita...@gmail.com writes:

AM Attached is a patch that updates the packaging to make
AM speech-dispatcher use pulse by default instead of alsa. The idea
AM was taken from upstream [1]. This would prevent the locking of
AM audio devices from speech-dispatcher.

I'm not sure this is a good idea, PulseAudio used to have its own
problems.  A better idea might be not to start system wide Speech
Dispatcher by default or to add a debconf option to specify how to start
Speech Dispatcher.

AM What would probably be better is to package a new version of
AM speech-dispatcher from the 0.6.8~unofficial~rc2 release
AM [2]. 

No.  According to the official Speech Dispatcher maintainer the patches
included in this release require significant cleanup work.  He now works
on it and prepares official 0.7 release which is expected to be ready
this month.  When it is released I'll package it and will fix the Debian
packaging bugs.




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#562946: fails to install

[Milan Zamazal]

The preinst test is there to prevent crm114 breakage (and contingent
loss of your e-mail etc.) in case you upgrade from an older crm114
version with incompatible .css files.

Under normal circumstances a debconf dialog is displayed asking you
whether you want to proceed with the upgrade or not.  I guess your
piuparts tests discard all the debconf interaction.  If so, then it's
probably not exactly failure of the crm114 package.

I can see I've forgotten to add NEWS entry for this version, I'll fix it
in the next upload.

Regards,
Milan Zamazal




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529720: crm114: Changes in .css files leads to data loss

[Milan Zamazal]

[Better late than never.]

The discussion with upstream has lead to no better solution than already
proposed, i.e. prompting the users on upgrade.  Future crm114 versions
may provide .css incompatibilities again (e.g. the recently released
beta version does).

So I've uploaded new package version today that implements debconf
prompting.  I tried to be as aggressive with the prompting as possible:

- The prompting is performed in preinst.  This is probably generally
  very discouraged, but I don't know about a better place for the given
  purpose.

- I ask a boolean debconf question instead of using a note.  This
  enforces user confirmation of the prompt.

- The debconf option value is reset before prompting in order to enforce
  displaying the question.

Would you please review `preinst' script and debconf `templates' in
crm114 20090423-2 to check whether they do the right thing?




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529720: CRM114's .css format

[Milan Zamazal]

FYI in the meantime (the cause of the problem is unknown for now):
According to upstream, if you use mailreaver then all (lost) mail should
be stored in your mailreaver cache.




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529720: CRM114's .css format

[Milan Zamazal]

Thanks for all the suggestions.  I'll discuss the problem with upstream
again and then decide what to do.

On the Debian side, I'll probably implement the big debconf message.  It
should inform the user about the change and suggest stopping MTA on the
computer until crm114 behavior is checked (and fixed if necessary).  The
installation script could offer to stop the MTA itself, but I'm afraid
of situations when this action would fail, resulting in various problems
up to mail loss again.




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529720: crm114: Changes in .css files leads to data loss

[Milan Zamazal]

 CP == Christian Perrier bubu...@debian.org writes:

CP Oh, I certainly got warned by mail as there is a NEWS.Debian
CP entry about this...and I ust apt-listchanges. Unfortunately,
CP that mail got trashed just like others.

If you want to prevent such problems, configure apt-listchanges to
display information before installation and to ask for confirmation.

CP I find such change inacceptable for release and I already
CP imagine what wll happen to people who upgrade their mail servers
CP from lenny to squeeze.

This has nothing to do with Debian.  It's an upstream decision.  It's
definitely not popular and if you hate it so much, there are some
options what you can do: 1. complain upstream; 2. use other classifier
than crm114; 3. fork crm114 and develop and maintain your own derivate;
4. write a .css file converter.

CP Actually, even the advice of recreating .css files is another
CP way to lose data.

I don't understand.  Recreating the .css files with mailreaver is
relatively easy and may even clean up and improve the .css files.

CP I'm really very seriously considering if I should keep on using
CP crm114 if such changes happen and, at this very moment, I don't
CP think this software verson is suitable for release in Debian.

I can understand your rage but as I've explained above I can't see in
your report what I should fix in the Debian package.




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529720: crm114: Changes in .css files leads to data loss

[Milan Zamazal]

 JM == Josselin Mouette j...@debian.org writes:

JM Simple: if there is no reasonable upgrade path, you need to
JM change the binary package name. And of course, to do that in a
JM way that does not install the new version automatically. 

This may be a good idea.  Do you know about packages with similar
properties (i.e. changing their data formats incompatibly) so that I
don't invent my own binary package naming scheme?  I can think about
PostgreSQL, but this is bound to upstream versions which is not the case
of crm114 (it doesn't change its data format with each upstream
version).

JM Bonus points go for changing the binary names as well, so that
JM both versions can be installed at once on the system.

I hate changing binary names across releases.




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529720: crm114: Changes in .css files leads to data loss

[Milan Zamazal]

 CP == Christian Perrier bubu...@debian.org writes:

CP The duty of the Debian maintainer is to smooth down impacts from
CP upstream changes. One of the recognized qualities of Debian is
CP such stability. So, we need to prepare our stable releases to
CP avoid such breakages.

CP Another is probably bringing feedback to upstream that such
CP changes are very unwished by their users.

This is not the first time .css format change has happened.  And yes, it
was reported and discussed upstream in the past.  They are willing to
avoid such changes but it may not always be easy.  More pressure
(i.e. from more users) on the upstream maintainers may or may not
improve things.  The .css format is generally not considered as very
fixed, e.g. it's not portable across architectures after all.

There were other upgrade problems in the past.  For instance, I
personally don't simply believe .crm scripts from the last version work
with a new one without changes and I always test that crm114 still works
after the upgrade.  I'd say that backward compatibility is not a crm114
feature and one must expect problems when upgrading crm114 to a new
version.  Of course, a user may not think about crm114 when typing
`apt-get upgrade'.  This wouldn't be a big problem if crm114 wasn't
typically used for things like e-mail delivery.

So the primary problem is how to _warn_ users that crm114 gets upgraded
with higher than casual risk of breaking things.  The current practice
of warning about important changes in NEWS.Debian seemed to work well so
far.  But I agree it may not be enough and I'm open to suggestions how
to improve it.

CP But, at least, I expect my problems to benefit other users and
CP particularly to avoid what I consider to be enhanced to enter
CP testing and then break much more setups.

Sure, you brave unstable users get hit by such problems and by reporting
them you prevent wider impacts.

CP At the very minimum, a critical priority debconf note displayed
CP when upgrading from a pre-20090423 version would be a good way
CP to try your best preventing the problem to appear. Debconf notes
CP are discouraged but I think that, here, we have a case where it
CP would be better having it than nothing.

Right now, I like this suggestion better than the binary package name
changes.  Some might not like it, but I may just try to add it and we'll
see what happens.

CP I also came back on the NEWS.Debian entry and I think it is not
CP alarming enough as it mentions on some architectures (which a
CP careless reader would translate to probably not on the most
CP common ones) and it just mentions that CRM114 might not work
CP but not thatmails piped through it will vanish.

Good remark.

CP Maybe more people will come up with better suggestions. 

If no applicable precedent in other Debian packages is presented here,
I'll probably discuss the problem on debian-mentors.

CP I really think that this bug should remain release critical so
CP that it gets the deserved attention by both you and other
CP developers (I bet that many use crm114 and many clever people
CP can come up with good suggestionsthis is also what RC bugs
CP are about).

Of course, I don't get rid of RC bugs without discussing them first.

CP Please accept some forms of apologies for showing up my rage
CP in the bug report (I admit I was) but also please don't take the
CP RC bug as a personal attack but more as a way to help you to
CP provide the best possible package for that software.

There is no need to apologize.  I just missed identification of the
_Debian package_ problem in your initial report and you've fixed it
now. :-)  Thanks for the report.




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#529720: crm114: Changes in .css files leads to data loss

[Milan Zamazal]

 MD == Mehdi Dogguy mehdi.dog...@pps.jussieu.fr writes:

MD Unison maintainer did that for some period because of protocol
MD changes. There have been unison and unison2.13.16 installable
MD and usable together in the same system, thank to
MD alternatives. The latter was kept for compatibility reasons with
MD older distributions.

Thanks for the suggestion.  I'm not familiar with the unison case, but I
guess the split was introduced to be able to talk to other computers?
This is not the case with crm114, I can't see any common reason having
more than one crm114 version on a single computer.  The crm114 problem
is different, how to prevent unnoticed upgrade.

Josselin, it's not clear to me how your package name arrangement would
ensure the opposite thing, that people don't miss new versions.
E.g. when one upgrades from lenny to squeeze, he could end up with old
lenny crm114 package after the upgrade, without noticing there is
something new in squeeze.  Or when one performs regular unstable
updates, how to retain crm114 up to date?




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#511147: speech-dispatcher: installation does not end cleanly + it will prevent the system of starting

[Milan Zamazal]

 PR == Patrick Ringl patri...@freenet.de writes:

PR it results in speech-dispatcher moaning about a non-existing
PR directory:

This is just a harmless info message, not an error.  I don't have
~/.speech-dispatcher and Speech Dispatcher works fine for me.

PR It seems to run in an endless loop. Anyway after rebooting the
PR same happened since /etc/default/speech-dispatcher is set to YES
PR it'll be run at boot time. Even a clear ctrl+c to end the
PR process at boot time does not work and has not any effect - the
PR mashine/bootprocess will just 'freeze'.

I have never heard about such a problem so it may be just a result of
some problem in your system.  There are only a few things Speech
Dispatcher does before forking, so the blocking you describe is strange.

Could you please investigate what's the problem?  Set LogLevel to 5 in
/etc/speech-dispatcher/speechd.conf.  Then try to start Speech
Dispatcher and look at all files in /var/log/speech-dispatcher/.  If you
don't identify the cause there, would you send me contents of those
files?

Regards,

Milan Zamazal



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#386578: speechd-el: speechd-speak-read-.* don't speak

[Milan Zamazal]

 BD == Boris Daix [EMAIL PROTECTED] writes:

BD Errors may be polite warnings.  speechd-enable-ssip and
BD speechd-enable-braille variables could be set to t by default:
BD speechd-speak would load corresponding libraries, would try to
BD connect to speech-dispatcher and brlapi, would politely warn
BD user if one of them is unavailable.  The user may as well set
BD one of these variables to nil so that neither loading nor
BD probing/warning happen anymore.  It is my expectation, what do
BD you think of it?  At least, speechd-speak-read-.* may warn user
BD if none of ssip or braille are loaded.

Well, thinking about it loading and activating all the drivers by
default is the simplest way to make speechd-el work for first-time
users, especially those who are blind and must rely on the alternative
output to figure out what's going on.  I can make this change
immediately in the Debian package.

In the upcoming speechd-el 2.1 release I'll add an additional message
giving a hint about customizing speechd-out-active-drivers to disable
the errors/warnings.

Thanks for your suggestions.

Regards,

Milan Zamazal



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386578: speechd-el: speechd-speak-read-.* don't speak

[Milan Zamazal]

 BD == Boris Daix [EMAIL PROTECTED] writes:

BD Nice!  It works perfectly now.  

Thanks for testing.

BD My conclusion is that speechd-el is not fully installed.  Could
BD you add the lines mentioned in point 5, section 2.1
BD installation of speechd-el info file to
BD /etc/emacs/site-start.d/50speechd-el.el?  

I don't think this is a good idea, since users who don't use speech
output (e.g. when they use Braille output only) would receive error
messages about not being able to connect to Speech Dispatcher.

BD Otherwise you could drop a note about it in README.Debian as
BD user is required to resume the installation.

Yes, it should be documented more visibly.  It's documented in
installation instructions in README, but apparently not all users read
it :-), especially on upgrades (you're not the first one who got
confused).  I'll put a warning into README.Debian and NEWS.Debian.  Do
you have some suggestion where to put the necessary instructions in the
general speechd-el documentation so that even non-Debian users wouldn't
overlook them?

Regards,

Milan Zamazal



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#386578: speechd-el: speechd-speak-read-.* don't speak

[Milan Zamazal]

 BD == Boris Daix [EMAIL PROTECTED] writes:

BD   - BRLTTY 3.7.2-3.1 started up and running in text-mode with correct
BD perms on BRLAPI key file (not sure it helps but speechd-el info
BD mentions BRLAPI),
BD   - speech-dispatcher 0.6.1-2 started up and running with
BD speech-dispatcher-festival 0.6.1-2 module,
BD   - GNU Emacs{21-nox,-snapshot-nox} started with -q flag,
BD   - M-x speechd-speak RET issued i.e. global speaking toggled on.

BD Well I can't get any speech from any of
BD speechd-speak-read-{line,buffer,region,...} defuns despite M-x
BD speechd-say-text RET Hello world! RET does speak perfectly.

It looks to me like you haven't load the necessary drivers.  Try

M-x load-library RET speechd-ssip RET
M-x load-library RET speechd-brltty RET

and tell me whether it helps.

Regards,

Milan Zamazal



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#377978: crm114: classifies as UNSURE spam with scores lower than -180

[Milan Zamazal]

 LM == Lieven Marchand [EMAIL PROTECTED] writes:

LM Given that nowhere in the source any reference was made to
LM learncounts I suspected the css files too. With empty css files
LM everything worked again, after training off course.

OK, thanks for testing.

Regards,

Milan Zamazal

-- 
http://www.zamazal.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#377978: crm114: classifies as UNSURE spam with scores lower than -180

[Milan Zamazal]

 LM == Lieven Marchand [EMAIL PROTECTED] writes:

LM With the standard mailfilter.cf I get the following

LM [EMAIL PROTECTED]:~$ /usr/share/crm114/mailfilter.crm -u .crm114/ test
LM test

LM  Aw, crud.  mailfilter.crm broke.  Here's the error:

LM /usr/bin/crm: *ERROR* This file should have learncounts, but
LM doesn't, and the learncount slot is busy.  It's hosed.  Time to
LM die.  Sorry, but this program is very sick and probably should
LM be killed off.  This happened at line 917 of file
LM /usr/share/crm114/mailfilter.crm

Thank you for trying it out.  The error message looks strange to me --
the line 917 of mailfilter.crm is inside a commentary:

  #End of blacklist processing.  

Could you please look at the line in your
/usr/share/crm114/mailfilter.crm whether it is the same there?

BTW, did you upgrade from crm114 20060118 or from an older version?  I'd
guess from the error message that your *.css files either got damaged or
belong to a different classification method (the default classification
method has changed in 20060118).

Regards,

Milan Zamazal



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#378084: crm114: mailfiter is broken

[Milan Zamazal]

 SHG == Steinar H Gunderson [EMAIL PROTECTED] writes:

SHG When trying to learn new mail as spam, I get the following
SHG error twice:

SHG  Aw, crud.  mailfilter.crm broke.  Here's the error:

SHG /usr/bin/crm: *ERROR* This program wants to use a nonexistent
SHG variable named: ':text_cache:' Sorry, but this program is very
SHG sick and probably should be killed off.  This happened at line
SHG 218 of file /usr/share/crm114/mailfilter.crm

You should update your mailfilter.cf, see
/usr/share/crm114/mailfilter.cf.  I should put a warning about it into
NEWS.Debian.  I'll do it, but first I'd like to know whether there are
more problems with the new crm114 package, see bug #377978.  Could you
please test it?  crm114 seems to work fine for me with both the default
new configuration and my own old configuration, so I need help from
other users.

Thanks for the report.

Regards,

Milan Zamazal



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#377978: crm114: classifies as UNSURE spam with scores lower than -180

[Milan Zamazal]

 LM == Lieven Marchand [EMAIL PROTECTED] writes:

LM Every spam gets classified as UNSURE, now matter how low the
LM score. This off course negates the concept spamfilter

Could you provide more information about your setup, please?  I can't
reproduce the problem -- on my system it reports Good/UNSURE/SPAM in
accordance with the :thick_threshold: value with the default
mailfilter.crm script and configuration.

Regards,

Milan Zamazal


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#304380: upload?

[Milan Zamazal]

 FL == Frank Lichtenheld [EMAIL PROTECTED] writes:

FL In the bug report you replied that this patch will be included
FL in the next upstream version of this package. Please note that
FL this is now an RC bug and if the next upstream version is not
FL due very soon you should definetly upload a patched package...

I'm aware of the situation.  I hope I'll manage to upload new upstream
version within the next week.

Regards,

Milan Zamazal

-- 
Having GNU Emacs is like having a dragon's cave of treasures.
Robert J. Chassell


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#305938: Bug#301630: crm114: fails when .css files get full

[Milan Zamazal]

 JCGS == Jose Carlos Garcia Sogo [EMAIL PROTECTED] writes:

JCGS  I am still not sure about binary named changed. 

Neither am I.

JCGS I think you should provide a link to the old binary name, as
JCGS if you don't do that installations in which the old name will
JCGS break silently, which is a bad thing. 

What I'm afraid of is that new CRM114 users could start use the wrong
binary name, thus forcing the package to carry cruft forever.  And it
would mean introducing the cruft into stable Debian version (crm114 is
not present in woody).

Providing a warning during installation or making the link optional
looks like overkill to me.

Making /usr/bin/crm114 a wrapper script providing some warning may be
dangerous.

Making just the crm114 link and add a big warning in README.Debian
probably doesn't solve the problem since most users don't read
README.Debian files I guess.  But this could make a nice excuse for
me :-) when the link gets removed sometimes in the future, so this is
what I'm most likely to do.

Any better suggestion?

JCGS  About the css files being full, I have tested and with the
JCGS new version, after running cssutil -b spam.css (which was the
JCGS full file) I got a lot of empty slots, and things seem to be
JCGS working again.

OK, thanks for testing.  IIRC, there were some microgrooming related
bugs in older CRM114 versions, maybe this was one of their
manifestations.

Regards,

Milan Zamazal

-- 
http://www.zamazal.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]