Bug#1072996: cryptmount: No longer working with current sid (e2fsck error)

[Agustin Martin]

Package: cryptmount
Version: 6.2.0-2
Severity: normal

Dear Maintainer,

I have noticed that cryptmount is no longer working well with current
sid in my box. This happened recently, although I do not know where
this started to happen,

$ cryptmount LUKS-test
...
e2fsck 1.47.1 (20-May-2024)
Error determining size of the physical device: No such file or directory
unable to stat() device node
Failed to remove device-mapper target "LUKS-test"

If I add the noextfsck flag to cmtab, mount succeeds,

$ cryptmount LUKS-test

However, I have problems when unmounting,

$ cryptmount -u LUKS-test
Target "LUKS-test" does not appear to be mounted

although device is mounted and accesible,

I noticed that when using cryptmount /dev/mapper/LUKS-test seems not
present, although device is mounted. When using the normal cryptsetup close flow

# umount /media/luks-testdir
# /sbin/cryptsetup close LUKS-test

device is properly unmounted.

If I follow the cryptsetup flow for opening

# /sbin/cryptsetup open /dev/sdc1  LUKS-test
# mount /dev/mapper/LUKS-test /media/luks-testdir/

/dev/mapper/LUKS-test is present and 'cryptmount -u LUKS-test' works.

LUKS-test {
  keyformat=luks
  dev=/dev/sdc1
  keyfile=/dev/sdc1
  dir=/media/luks-testdir
  flags=nofsck
  fstype=ext4
}


Thanks for your work on cryptmount.

Regards,

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (50, 'testing'), (50, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptmount depends on:
ii  libc6   2.38-13
ii  libcryptsetup12 2:2.7.2-2
ii  libdevmapper1.02.1  2:1.02.196-1+b1
ii  libgcrypt20 1.10.3-3
ii  libudev1256~rc4-1

Versions of packages cryptmount recommends:
ii  e2fsprogs  1.47.1-1
ii  udev   256~rc4-1

Versions of packages cryptmount suggests:
ii  dmsetup  2:1.02.196-1+b1

-- Configuration Files:
/etc/cryptmount/cmtab changed [not included]

-- no debconf information

Bug#1027405: regina-rexx FTCBFS: builds for the build architecture

[Agustin Martin]

El mar, 2 abr 2024 a las 13:49, Helmut Grohne () escribió:
> On Fri, Mar 29, 2024 at 01:29:04PM +0100, Agustin Martin wrote:
>
> > However, there is another problem with other arches (e.g. arm64). Some
> > binary files containing compiled error messages are built with a
> > locally built program (msgcmp). Because of incompatible arches, it
> > cannot be run and files cannot be built, and then, build fails when
> > trying to install them (error is disabled during build). The first
> > idea was to have a separate arch:all pakage with those messages, but
> > it would not be arch:all because those messages binary files depend on
> > arch endianness.
>
> Does that mean that it vendors a gettext rather than using the system
> gettext? There is a msgcmp in the gettext package and it is Multi-Arch:
> foreign. If this is something different from gettext, you should likely
> use CC_FOR_BUILD as set by dpkg's buildtools.mk for compiling msgcmp.c.
> I don't think it is installed into any binary package so there likely is
> no need to compile it twice in a cross build.

HI, Helmut,

Thanks for the testing and for the info. Yes, a completely different
system is used for internationalization, not gettext.

By the way, upstream is active and responsive. I have recently opened
a couple of tickets about different things

https://sourceforge.net/p/regina-rexx/support-requests/56/
https://sourceforge.net/p/regina-rexx/support-requests/57/

and reply to first one was more than quick. The other has just been opened.

-- 
Agustin

Bug#1068394: hunspell-it: Verb 'possedere' is in it_IT.dic, but is highlighted as error

[Agustin Martin]

El jue, 4 abr 2024 a las 15:33, Alessio Paonessa
() escribió:
>
> Package: hunspell-it
> Version: 1:24.2.2-1
> Severity: normal
> Tags: l10n
> X-Debbugs-Cc: livm...@hotmail.com
>
> Dear Maintainers,
>
> when I write the conjugations of the verb 'possedere' in a text editor, the
> word is marked as an error.
>
> A quick check to the file it_IT.dic seems to correctly list it at line 60847.
> Nonetheless, the conjugations are highlighted as incorrect.

Hi, Alessio,

I do not speak italian but has looked sometimes at
ispell/myspell2/hunspell affix files, so here go my 2cents.

First, I suggest you to send the exact words that triggered the error,
to make debugging easier. From what I see, the problem might be that
"È" flag is not present in aff file, but used in the dic file

$ grep È /usr/share/hunspell/it_IT.dic
possedere/ÈI
risedere/ÈI
sedere/ÈSI
soprassedere/ÈI

$ grep È /usr/share/hunspell/it_IT.aff
TRY aioertnsclmdpgubzfvhàq'ACMSkBGPLxEyRTVòIODNwFéùèìjUZKHWJYQXÙÀÒÈÌÉ
# Nota: non presenti nel dizionario: ÙÀÒÈÌÉ, vanno aggiunte alla TRY rigenerata
MAP eéèEÉÈ

"I" flag seems to work well,

$ echo possedermi possederti possedervi possederci | hunspell -a -d it_IT
@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.2)
*
*
*
*
Do not know what "È" flag was supposed to handle. By the way, other
words in above list should show similar problems.

I do not speak italian, so I suggest you to report this problem
directly to the upstream email available in it_IT.aff file.

E-Mail: marinalatinilibreofficeorg

Hope this helps,

Regards,

-- 
Agustin

Bug#1027405: regina-rexx FTCBFS: builds for the build architecture

[Agustin Martin]

El vie, 22 mar 2024 a las 11:23, Agustin Martin
() escribió:
>
> On Fri, Dec 30, 2022 at 10:46:18PM +0100, Helmut Grohne wrote:
> >
> > regina-rexx fails to cross build from source, because it builds for the
> > build architecture. Fixing this is not entirely trivial. The obvious fix
> > of passing --build and --host to configure is insufficient. Beyond that,
> > the C compiler must be forced via the CC environment variable. Even
> > then, the build system fails to transfer this assignment over to make.
> > To make matters worse, it skips checking for --version-script (and thus
> > symbol versioning) unless the compiler is exactly gcc. I'm attaching a
> > patch for your convenience.
>
> I am not regina-rexx maintainer, but I am preparing a fix proposal (or
> a NMU if required) for regina-rexx because of #1066314 FTBFS, which
> will include a newer upstream version.
>
> While I am with that, I would also like to address this cross
> compilation problem, and looking at your patch I have some questions,
> even if only to properly document changes.

HI, Helmut,

I finally had time to learn how to test cross compilation from my
amd64 box. I am using the usual pbuilder/cowbuilder chroot for that
with apropriate options (and forcing my local pbuilderrc loaded last
to have PBUILDERSATISFYDEPENDSCMD properly overriden)

> About debian/rules changes,
>
> I wonder if passing CC compiler to configure is done just because
> otherwise C compiler will not be found because of unusual name during
> cross compilation, or there is another reason.
>
> Passing CC to 'make' may not be needed. Another patch changes
> Makefile.in to no longer hardcode CC, CFLAGS, RANLIB and LDFLAGS. As a
> matter of fact, I woud expect no problems if LDFLAGS is not passed.
> CFLAGS is passed only to concat CPPFLAGS (may be CFLAGS += $(CPPFLAGS)
> and export CFLAGS could make that useless).

All this seems needed just because CC is not exported by the build
system . Adding export CC in the right place in debian/rules seems to
make that uneeded.

With that changes I could cross compile i386 from my amd64 box.

However, there is another problem with other arches (e.g. arm64). Some
binary files containing compiled error messages are built with a
locally built program (msgcmp). Because of incompatible arches, it
cannot be run and files cannot be built, and then, build fails when
trying to install them (error is disabled during build). The first
idea was to have a separate arch:all pakage with those messages, but
it would not be arch:all because those messages binary files depend on
arch endianness.

I would like to close this bug report with above changes, even if a
more specific bug report is open afterwards for the remaining stuff.

Better suggestions are welcome.

Regards,

-- 
Agustin

Bug#1066314: regina-rexx: FTBFS: ./rexxext.c:95:7: error: implicit declaration of function ‘getcallstack’; did you mean ‘popcallstack’? [-Werror=implicit-function-declaration]

[Agustin Martin]

El vie, 22 mar 2024 a las 12:01, Alen Zekulic () escribió:
>
> On Sun, Mar 17, 2024 at 21:41:44 +0100, Agustin Martin wrote:
>
> > Some time ago I played a bit with upgrading regina-rexx to a recent
> > upstream version. I think I can find that stuff and try again with
> > last upstream version. In case of success, I would like to push
> > changes to regina-rexx salsa repo for further inspection. Let me know
> > your POV.
>
> Hi Agustin,
>
> I have an objection to that! Please do not hesitate to NMU Regina
> packages.

Hi, Alen,

Thanks for your support. I would like to wait some days for further
feedback on the cross compilation stuff before actually NMUing.
Everything will go to regina-rexx salsa git repo.

Regards,

-- 
Agustin

Bug#1027405: regina-rexx FTCBFS: builds for the build architecture

[Agustin Martin]

On Fri, Dec 30, 2022 at 10:46:18PM +0100, Helmut Grohne wrote:
> Source: regina-rexx
> Version: 3.6-2.4
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> regina-rexx fails to cross build from source, because it builds for the
> build architecture. Fixing this is not entirely trivial. The obvious fix
> of passing --build and --host to configure is insufficient. Beyond that,
> the C compiler must be forced via the CC environment variable. Even
> then, the build system fails to transfer this assignment over to make.
> To make matters worse, it skips checking for --version-script (and thus
> symbol versioning) unless the compiler is exactly gcc. I'm attaching a
> patch for your convenience.

Hi, Helmut,

First thanks a lot for the analysis and the fix proposals.

I am not regina-rexx maintainer, but I am preparing a fix proposal (or
a NMU if required) for regina-rexx because of #1066314 FTBFS, which
will include a newer upstream version.

While I am with that, I would also like to address this cross
compilation problem, and looking at your patch I have some questions,
even if only to properly document changes.

About debian/rules changes,

I wonder if passing CC compiler to configure is done just because
otherwise C compiler will not be found because of unusual name during
cross compilation, or there is another reason.

Passing CC to 'make' may not be needed. Another patch changes
Makefile.in to no longer hardcode CC, CFLAGS, RANLIB and LDFLAGS. As a
matter of fact, I woud expect no problems if LDFLAGS is not passed.
CFLAGS is passed only to concat CPPFLAGS (may be CFLAGS += $(CPPFLAGS)
and export CFLAGS could make that useless).

Other changes in debian/rules are clear and very useful, thanks.

About changes in configure{,.in} I would leave a check for GCC, I
guess upstream wants other compilers supported. I would like to have a
change that might be sent upstream, so for portability I would use a
case statement, now written in a very generic way (see attached diff
for that). Which kind of strings are expected as C compiler during
cross compilation?

Thanks again for everything,

Regards,

-- 
Agustin
Description: Allow a more permissive gcc|g++ check for cross compilation.
 Compiler name may have prefix|suffix when cross compiling.
Bug-Debian: http://bugs.debian.org/1027405
Forwarded:

--- a/configure.in
+++ b/configure.in
@@ -416,9 +416,11 @@ fi
 AC_SUBST(MY_GETOPT_O)
 AC_SUBST(MY_GETOPT_SO_O)
 
-if test "$ac_cv_prog_CC" = "gcc" -o "$ac_cv_prog_CC" = "g++"; then
-   REG_CHECK_GCC_VERSION_SCRIPT
-fi
+case "$ac_cv_prog_CC" in
+   *gcc*|*g++*)
+	REG_CHECK_GCC_VERSION_SCRIPT
+	;;
+esac
 
 dnl enable_posix_threads="yes"
 REG_CHECK_POSIX_THREADS
--- a/configure
+++ b/configure
@@ -6342,7 +6342,8 @@ fi
 
 
 
-if test "$ac_cv_prog_CC" = "gcc" -o "$ac_cv_prog_CC" = "g++"; then
+case "$ac_cv_prog_CC" in
+   *gcc*|*g++*)
 
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether gcc understands --version-script" >&5
 $as_echo_n "checking whether gcc understands --version-script... " >&6; }
@@ -6390,7 +6391,8 @@ fi
 { $as_echo "$as_me:${as_lineno-$LINENO}: result: $mh_cv_version_script" >&5
 $as_echo "$mh_cv_version_script" >&6; }
 
-fi
+	;;
+esac
 
 
 MH_MT_LIBS=""

Bug#1066314: regina-rexx: FTBFS: ./rexxext.c:95:7: error: implicit declaration of function ‘getcallstack’; did you mean ‘popcallstack’? [-Werror=implicit-function-declaration]

[Agustin Martin]

Control: tags -1 +pending

El dom, 17 mar 2024 a las 21:41, Agustin Martin
() escribió:
>
> El vie, 15 mar 2024 a las 18:57, Agustin Martin
> () escribió:
> >
> > Hi, Lucas and Alen.
> >
> > While it is easy to fix this particular error (see attached patch,
> > from upstream repo), other similar error happens afterwards in my
> > tests. The problem is that this package is way behind upstream and I
> > think priority is to upgrade to a recent upstream version and then fix
> > whatever is left.
>
> Hi, Alen,
>
> Some time ago I played a bit with upgrading regina-rexx to a recent
> upstream version. I think I can find that stuff and try again with
> last upstream version. In case of success, I would like to push
> changes to regina-rexx salsa repo for further inspection. Let me know
> your POV.

Hi, Lucas and Alen

I have been working on upgrading upstream version from 3.6 to 3.9.5.
There have been a lot of upstream changes between both versions and I
have tried to quickly look at them in case I find something I do not
like. It was a quick look, so something may have gone unnoticed,
better if maintainer can look better at it. I have upgraded all the
Debian stuff to work with that new version, added some other changes I
found interesting, and verified that everything builds in a recent
pbuilder sid box, so I think package as I have it fixes this problem,
thus the "pending" tag.

I have committed everything to
https://salsa.debian.org/debian/regina-rexx.git, including upstream
and pristine-tar branches. I will leave some time for inspection and,
if no one else uploads before and there are no objections, will upload
NMU myself. In the meantime I would like to look at [#1027405:
regina-rexx FTCBFS: builds for the build architecture] and see how to
adjust supplied patch and deal with this problem. Note that
regina-rexx package is marked for autoremoval from testing on 26
April.

Regards,

-- 
Agustin

Bug#1066314: regina-rexx: FTBFS: ./rexxext.c:95:7: error: implicit declaration of function ‘getcallstack’; did you mean ‘popcallstack’? [-Werror=implicit-function-declaration]

[Agustin Martin]

El vie, 15 mar 2024 a las 18:57, Agustin Martin
() escribió:
>
> Hi, Lucas and Alen.
>
> While it is easy to fix this particular error (see attached patch,
> from upstream repo), other similar error happens afterwards in my
> tests. The problem is that this package is way behind upstream and I
> think priority is to upgrade to a recent upstream version and then fix
> whatever is left.

Hi, Alen,

Some time ago I played a bit with upgrading regina-rexx to a recent
upstream version. I think I can find that stuff and try again with
last upstream version. In case of success, I would like to push
changes to regina-rexx salsa repo for further inspection. Let me know
your POV.

Regards,

-- 
Agustin

Bug#1066314: regina-rexx: FTBFS: ./rexxext.c:95:7: error: implicit declaration of function ‘getcallstack’; did you mean ‘popcallstack’? [-Werror=implicit-function-declaration]

[Agustin Martin]

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> This is most likely caused by a change in dpkg 1.22.6, that enabled
> -Werror=implicit-function-declaration. For more information, see
> https://wiki.debian.org/qa.debian.org/FTBFS#A2024-03-13_-Werror.3Dimplicit-function-declaration
>
> Relevant part (hopefully):
> > cc -DNDEBUG -g -O2 -Werror=implicit-function-declaration 
> > -ffile-prefix-map=/<>=. -fstack-protector-strong 
> > -fstack-clash-protection -Wformat -Werror=format-security
+-fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2
-DREGINA_SHARE_DIRECTORY=\"//usr/share/regina-rexx\" -funsigned-char
-DREGINA_VERSION_DATE=\""31 Dec 2011"\" -DREGINA_VERSION_MAJOR=\"3\"
+-DREGINA_VERSION_MINOR=\"6\" -DREGINA_VERSION_SUPP=\"\"
-DHAVE_CONFIG_H-I. -I. -I./contrib-o rexxext.o -c ./rexxext.c
> > ./rexxext.c: In function ‘__regina_rex_getcallstack’:
> > ./rexxext.c:95:7: error: implicit declaration of function ‘getcallstack’; 
> > did you mean ‘popcallstack’? [-Werror=implicit-function-declaration]
> >95 |   getcallstack( TSD, parms->value );
> >   |   ^~~~
> >   |   popcallstack
> > cc1: some warnings being treated as errors
> > make[1]: *** [Makefile:427: rexxext.o] Error 1

Hi, Lucas and Alen.

While it is easy to fix this particular error (see attached patch,
from upstream repo), other similar error happens afterwards in my
tests. The problem is that this package is way behind upstream and I
think priority is to upgrade to a recent upstream version and then fix
whatever is left.

Not tagging 'patch' since this change alone does not fix build.

Regards,
--- regina-rexx.orig/rexxext.c
+++ regina-rexx/rexxext.c
@@ -55,6 +55,8 @@
 # endif
 #endif
 
+extern void getcallstack( tsd_t *TSD, streng *stem );
+
 streng *rex_userid( tsd_t *TSD, cparamboxptr parms )
 {
 #if defined(WIN32)

Bug#1066086: maxima-emacs: maxima-emacs again not installable with xemacs21

[Agustin Martin]

Package: maxima-emacs,xemacs21
Severity: normal

Dear Maintainers,

Seems that

[#969410] maxima-emacs: maxima-emacs 5.44 does not work with XEmacs
[#999626] maxima-emacs: fails to install with xemacs21

are back, since mmm-mode-el dropped xemacs21 support and no longer
provides cl-lib.

I am including xemacs1 package in case maintainer wants to add something.

I see some possible approaches,

1) Drop xemacs21 support from maxima-emacs. I proposed a patch in #999626,
   should need more test and should probably be updated.
2) Create something like a xemacs21-compat-el package containing cl-lib and
   may be other compatibility stuff.
3) Include cl-lib somewhere in Debian xemacs21 package as a Debian feature.
4) Include cl-lib in maxima-emacs for local use.

Opinions?

Regards,

-- 
Agustin

Bug#1046041: ivtools: Fails to build source after successful build

[Agustin Martin]

El dom, 13 ago 2023 a las 22:16, Lucas Nussbaum () escribió:
>
> Source: ivtools
> Version: 2.0.11d.a1-1
> Severity: minor
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-sab-20230813 ftbfs-source-after-build
> User: debian...@lists.debian.org
> Usertags: qa-doublebuild

> > dpkg-source: error: cannot represent change to refman.pdf: binary file 
> > contents changed
> > dpkg-source: error: add refman.pdf in debian/source/include-binaries if you 
> > want to store the modified binary in the debian tarball
> > dpkg-source: error: unrepresentable changes to source
> > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 1

Hi,

I have been playing with a patch (attached) to handle this from
debian/rules. Besides refman.pdf there were some other things to
remove on clean target.

Regards,
diff --git a/debian/rules b/debian/rules
index 71543bf..9ab42e5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,11 @@ override_dh_auto_configure:
 		--with-PSFontDir=/usr/share/fonts/type1/gsfonts	\
 		--with-clippoly=no
 
+override_dh_clean:
+	rm -f refman.pdf
+	rm -f *.la pnmtopgm Idemo InterViews comterp_run
+	dh_clean
+
 execute_after_dh_install:
 	@echo prevent library files in libiv2 from being duplicated in libiv-unidraw2
 	find debian/libiv2t64/usr/lib -type f -o -type l		\

Bug#1062611: libiv-unidraw2t64 has an undeclared file conflict

[Agustin Martin]

El vie, 2 feb 2024 a las 6:57, Helmut Grohne () escribió:
>
> Package: libiv-unidraw2t64
> Version: 2.0.11d.a1-1.1~exp1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fileconflict
> Control: affects -1 + libiv2 libiv2t64
> X-Debbugs-Cc: Graham Inggs , vor...@debian.org
>
> libiv-unidraw2t64 has an undeclared file conflict. This may result in an
> unpack error from dpkg.
>
> The files
>  * /usr/lib/x86_64-linux-gnu/libIV.so.2
>  * /usr/lib/x86_64-linux-gnu/libIV.so.2.0.0
> are contained in the packages
>  * libiv-unidraw2t64/2.0.11d.a1-1.1~exp1 as present in experimental
>  * libiv2
>* 2.0.11d.a1-1+b4 as present in bookworm
>* 2.0.11d.a1-1+b5 as present in trixie|unstable
>* 2.0.4a1-2 as present in bullseye
>  * libiv2t64/2.0.11d.a1-1.1~exp1 as present in experimental

Hi, Helmut.

I wonder if this is still an issue. Some uploads happened in the
meantime and seems that  those files are currently shipped by a
different package

$ dpkg -S libIV.so.2
libiv2t64:amd64: /usr/lib/x86_64-linux-gnu/libIV.so.2.0.0
libiv2t64:amd64: /usr/lib/x86_64-linux-gnu/libIV.so.2

which apparently handles things well

Package: libiv2t64
Replaces: libiv2
Provides: libiv2 (= 2.0.11d.a1-1.1)
Breaks: libiv2 (<< 2.0.11d.a1-1.1)

Bug#1061266: [PATCH] sgmls: Fix type of signal handlers for C89 compatibility

[Agustin Martin]

El dom, 21 ene 2024 a las 19:45, Florian Weimer () escribió:
>
> Package: linuxdoc-tools
> Version:  0.9.82-1
> Tags: upstream patch
>
> This is another fallout from GCC 14 porting of Fedora.

Hi, Florian,

Thanks for the info. Seems it was fixed in already released 0.9.83.
This is the relevant commit

https://gitlab.com/agmartin/linuxdoc-tools/-/commit/fd6cf2b50d5bd9f013017b53edefe51e0e54f5c4

Please let me know if something is missing.

Regards,

-- 
Agustin

> Without this change, the outcome of two tests are altered due to
> compiler errors:
>
> -#define HAVE_EXTENDED_PRINTF 1
> +/* #define HAVE_EXTENDED_PRINTF 1 */
>
> -/* #define USE_ISASCII 1 */
> +#define USE_ISASCII 1
>
> (Not sure if the second change is a pre-existing bug or not.)
>
> diff --git a/sgmls-1.1/configure b/sgmls-1.1/configure
> index e674d24..898b522 100755
> --- a/sgmls-1.1/configure
> +++ b/sgmls-1.1/configure
> @@ -113,7 +113,7 @@ cat >doit.c <<\EOF
>  #include 
>  #include 
>
> -static int whoops()
> +static void whoops(int signo)
>  {
>_exit(1);
>  }
> @@ -459,7 +459,7 @@ cat >doit.c <<\EOF
>  #include 
>  #include 
>
> -static int whoops()
> +static void whoops(int signo)
>  {
>_exit(1);
>  }
> --
> 2.43.0
>

Bug#1055038: libreoffice-dictionaries: Please enable Esperanto hunspell dict, hyphenation and thesaurus packages.

[Agustin Martin]

El lun, 30 oct 2023 a las 0:18, Agustin Martin () escribió:
>
> Source: libreoffice-dictionaries
> Version: 1:7.5.0-1
> Severity: wishlist
>
> Hi, Rene and Mattia
>
> Please enable Esperanto stuff from libreoffice dictionaries. This
> stuff was added in 2021
>
> I am attaching a diff with what seems to me the required changes for
> Esperanto stuff to be enabled.

Hi,

Attached slightly updated diff (include year in copyright notice and
add esperanto stuff to ass_639_code and ass_639_name variables). Did
not rebuild json list, seems there are some other new dicts.

Regards,

-- 
Agustin
From 925253a9343c290fb07d366b178b4144f9c4e558 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Sun, 29 Oct 2023 23:51:02 +0100
Subject: [PATCH] Enable esperanto hunspell dict, hyphenation and thesaurus
 packages.

---
 debian/control   | 42 ++
 debian/copyright |  4 
 debian/helper.py |  5 +++--
 debian/list.json | 15 +++
 debian/rules.install |  4 
 5 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 9b6f375..193dcb8 100644
--- a/debian/control
+++ b/debian/control
@@ -486,6 +486,48 @@ Description: English (GB) dictionary for hunspell
  terminal interface using Curses library, an Ispell pipe interface and a
  LibreOffice UNO module.
 
+Package: hyphen-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}
+Suggests: libreoffice-writer
+Provides: hyphen-hyphenation-patterns, hyphen-hyphenation-patterns-eo
+Description: Esperanto hyphenation patterns
+ This package contains the Esperanto hyphenation patterns.
+ .
+ You can use these patterns with programs which take advantage of libhyphen,
+ like LibreOffice.
+
+Package: hunspell-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}, ${hunspell:Depends}
+Suggests: hunspell, libreoffice-writer
+Provides: hunspell-dictionary, hunspell-dictionary-eo
+Breaks: myspell-eo (<< 2.1.2000.02.25-62)
+Replaces: myspell-eo (<< 2.1.2000.02.25-62)
+Description: Esperanto dictionary for hunspell
+ This is the Esperanto dictionary for use with the hunspell
+ spellchecker.
+ .
+ Hunspell is a spell checker and morphological analyzer library and program
+ designed for languages with rich morphology and complex word compounding or
+ character encoding. It is based on MySpell and features an Ispell-like
+ terminal interface using Curses library, an Ispell pipe interface and a
+ LibreOffice UNO module.
+
+Package: mythes-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}
+Suggests: libreoffice-writer
+Provides: mythes-thesaurus, mythes-thesaurus-eo
+Description: Esperanto Thesaurus for LibreOffice
+ Libreoffice is a full-featured office productivity suite that provides a
+ near drop-in replacement for Microsoft(R) Office.
+ .
+ This package contains the Esperanto thesaurus for LibreOffice.
+
 Package: hyphen-es
 Architecture: all
 Multi-Arch: foreign
diff --git a/debian/copyright b/debian/copyright
index 82fcc87..8ba57bc 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -187,6 +187,10 @@ License: custom1
  % Please contact the TUGboat editorial staff 
  % for corrections and omissions.
 
+Files: dictionaries/eo/*
+Copyright: 2010 Artur Trzewik 
+License: GPL-2+
+
 Files: dictionaries/es/*
 Copyright: Santiago Bosio 
 License: GPL-3+ or LGPL-3+ or MPL-1.1+
diff --git a/debian/helper.py b/debian/helper.py
index 9436a1e..014785a 100755
--- a/debian/helper.py
+++ b/debian/helper.py
@@ -68,6 +68,7 @@ breaks_replaces = {
  "hunspell-bg": ("myspell-bg", '<<', '4.1-5'),
  "hunspell-en-gb": ("myspell-en-gb", '<<', "1:5.0.1+dfsg-1"),
  "hunspell-en-za": ("myspell-en-za", '<<', "1:5.0.1+dfsg-1"),
+ "hunspell-eo": ("myspell-eo", '<<', "2.1.2000.02.25-62"),
  "hunspell-hr": ('myspell-hr', '<<', '1:6.0.3-2'),
  "hunspell-it": ("myspell-it", '<<', "1:5.0.1+dfsg-1"),
  "hunspell-kmr": ('myspell-ku', '<<', '1:5.1.3-2'),
@@ -171,10 +172,10 @@ Description: German dictionary for hunspell ("frami" version)
 # Code lookup: https://en.wikipedia.org/wiki/ISO_639:$code
 
 # link the pseudo-RFC639-1 used by upstream (the key) to an actual RFC639-1 or RFC638-2
-ass_639_code = {"af_ZA": "af", "an_ES": "an", "ar": "ar", "be_BY": "be", "bg_BG": "bg", "bn_BD": "bn", "bo": "bo", "br_FR": "br", "bs_BA": "bs", "ca": "ca", "cs_CZ": "cs", "da_DK": "da", "de": "de", &q

Bug#1055038: libreoffice-dictionaries: Please enable Esperanto hunspell dict, hyphenation and thesaurus packages.

[Agustin Martin]

Source: libreoffice-dictionaries
Version: 1:7.5.0-1
Severity: wishlist

Hi, Rene and Mattia

Please enable Esperanto stuff from libreoffice dictionaries. This
stuff was added in 2021

https://gerrit.libreoffice.org/c/dictionaries/+/110415

In particular, hunspell dict is an hunspell dict using real hunspell
capabilities. It should work far better that previous myspell-eo,
derived from ispell Esperanto dictionary and limited to pure myspell
capabilities. There were no previous packages for hyphenation patterns
and thesaurus but while we are at this, ...

I am attaching a diff with what seems to me the required changes for
Esperanto stuff to be enabled.

Current myspell-eo conflicts with hunspell-eo, so only required
coordination is to upload a new eo-spell package with myspell-eo made
a transitional package once lo-dicts provide this eo stuff.

Regards,

-- 
Agustin
From 7e1947c35d94594221e62d0cda65e367a4d287ee Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Sun, 29 Oct 2023 23:51:02 +0100
Subject: [PATCH] Enable esperanto hunspell dict, hyphenation and thesaurus
 packages.

---
 debian/control   | 42 ++
 debian/copyright |  4 
 debian/helper.py |  1 +
 debian/list.json | 15 +++
 debian/rules.install |  4 
 5 files changed, 66 insertions(+)

diff --git a/debian/control b/debian/control
index 9b6f375..193dcb8 100644
--- a/debian/control
+++ b/debian/control
@@ -486,6 +486,48 @@ Description: English (GB) dictionary for hunspell
  terminal interface using Curses library, an Ispell pipe interface and a
  LibreOffice UNO module.
 
+Package: hyphen-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}
+Suggests: libreoffice-writer
+Provides: hyphen-hyphenation-patterns, hyphen-hyphenation-patterns-eo
+Description: Esperanto hyphenation patterns
+ This package contains the Esperanto hyphenation patterns.
+ .
+ You can use these patterns with programs which take advantage of libhyphen,
+ like LibreOffice.
+
+Package: hunspell-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}, ${hunspell:Depends}
+Suggests: hunspell, libreoffice-writer
+Provides: hunspell-dictionary, hunspell-dictionary-eo
+Breaks: myspell-eo (<< 2.1.2000.02.25-62)
+Replaces: myspell-eo (<< 2.1.2000.02.25-62)
+Description: Esperanto dictionary for hunspell
+ This is the Esperanto dictionary for use with the hunspell
+ spellchecker.
+ .
+ Hunspell is a spell checker and morphological analyzer library and program
+ designed for languages with rich morphology and complex word compounding or
+ character encoding. It is based on MySpell and features an Ispell-like
+ terminal interface using Curses library, an Ispell pipe interface and a
+ LibreOffice UNO module.
+
+Package: mythes-eo
+Architecture: all
+Multi-Arch: foreign
+Depends: dictionaries-common, ${misc:Depends}
+Suggests: libreoffice-writer
+Provides: mythes-thesaurus, mythes-thesaurus-eo
+Description: Esperanto Thesaurus for LibreOffice
+ Libreoffice is a full-featured office productivity suite that provides a
+ near drop-in replacement for Microsoft(R) Office.
+ .
+ This package contains the Esperanto thesaurus for LibreOffice.
+
 Package: hyphen-es
 Architecture: all
 Multi-Arch: foreign
diff --git a/debian/copyright b/debian/copyright
index 82fcc87..1fc4c84 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -187,6 +187,10 @@ License: custom1
  % Please contact the TUGboat editorial staff 
  % for corrections and omissions.
 
+Files: dictionaries/eo/*
+Copyright: Artur Trzewik 
+License: GPL-2+
+
 Files: dictionaries/es/*
 Copyright: Santiago Bosio 
 License: GPL-3+ or LGPL-3+ or MPL-1.1+
diff --git a/debian/helper.py b/debian/helper.py
index 9436a1e..7f3c471 100755
--- a/debian/helper.py
+++ b/debian/helper.py
@@ -68,6 +68,7 @@ breaks_replaces = {
  "hunspell-bg": ("myspell-bg", '<<', '4.1-5'),
  "hunspell-en-gb": ("myspell-en-gb", '<<', "1:5.0.1+dfsg-1"),
  "hunspell-en-za": ("myspell-en-za", '<<', "1:5.0.1+dfsg-1"),
+ "hunspell-eo": ("myspell-eo", '<<', "2.1.2000.02.25-62"),
  "hunspell-hr": ('myspell-hr', '<<', '1:6.0.3-2'),
  "hunspell-it": ("myspell-it", '<<', "1:5.0.1+dfsg-1"),
  "hunspell-kmr": ('myspell-ku', '<<', '1:5.1.3-2'),
diff --git a/debian/list.json b/debian/list.json
index 859366e..7b325f2 100644
--- a/debian/list.json
+++ b/debian/list.json
@@ -232,6 +232,21 @@
 ],
 "name": "English (GB)"
 },
+{
+"639-1": "eo",
+"code": "eo",
+"hunspell": [
+"eo.aff",
+"eo.dic"
+],
+"hyphen": [
+"hyph_eo.dic

Bug#1037133:

[Agustin Martin]

On Tue, Sep 19, 2023 at 11:43:16AM +, c.bu...@posteo.jp wrote:
> Upstream responded to my questions about how this was fixed.
> They pointed to two PullRequests.
> 
> https://github.com/owncloud/client/pull/10058
> https://github.com/owncloud/client/pull/10065

Hi,

According to https://github.com/owncloud/client/issues/10071 this seems to
be fixed in upstream 2.11.1 version.

Is this stll a problem in current sid/testing 4.2.0.11670+dfsg-1 version?

Regards,

-- 
Agustin

Bug#1051971: owncloud-client-cmd: Error transfering https://BLAH/owncloud/remote.php/webdav/status.php - server replied: Forbidden

[Agustin Martin]

On Tue, Sep 26, 2023 at 10:11:12AM -0600, Sergio Mendoza wrote:
> On Mon, Sep 25, 2023 at 03:40:42PM +0200, Agustin Martin wrote:
> > On Mon, Sep 25, 2023 at 03:16:46PM +0200, Agustin Martin wrote:
> > > On Thu, Sep 14, 2023 at 09:07:38PM -0600, Sergio Mendoza wrote:
> > > > Package: owncloud-client-cmd
> > > > Version: 3.2.0.10193+dfsg-1
> > > > Severity: important
> > > > 
> > > > Dear mainteiner,
> > > > 
> > > >   With the new unstable version ( 3.2.0.10193+dfsg-1 ) of owncloudcmd,
> > > > when I try to sync with the onwcloud server I get the following error:
> > > > 
> > > > 23-09-14 20:45:05:955 [ warning sync.checkserverjob ]:  error: 
> > > > status.php replied 403
> > > > 23-09-14 20:45:05:955 [ fatal default ]:Failed to resolve
> > > > https://BLAH/owncloud/remote.php/webdav Error: Error transferring 
> > > > https://BLAH/owncloud/remote.php/webdav/status.php - server replied: 
> > > > Forbidden.
> > > > Aborted
> > > 
> > > Hi,
> > > 
> > > For the records, that version has been working in my sid box until last
> > > Thursday, where, after server upgrade from 10.12.1.3 to 10.13.1.3, this
> > > error started to appear
> 
>   Yes.  I upgraded the server to version 10.13.1.3 but that was after
> owncloud-client failed.  In any case what I did was to use rclone for
> syncing.  It is slower, but does the job with the experimental bisync
> option it provides.  No idea if I would ever go back to owncloud-client
> since over the years I have had a few problems that are not easily solved.

Hi,

owncloud-client 4.2.0.11670+dfsg-1 has been uploaded to sid (thanks a lot,
Pierre-Elliott).

I confirm that it fixes my problem with 3.2.0.10193+dfsg-1 and owncloud-client
is working again in all my boxes against the common 10.13.1.3, server. For the
records, I previously built a personal package with owncloud-client
3.2.1.10355 and it worked too. 

I think it would be interesting to know if 4.2.0.11670+dfsg-1 also fixes your
problem and this bug report.

Regards,

-- 
Agustin

Bug#1052690: grub2: post-install script overrides manual changes to GRUB_DISABLE_OS_PROBER

[Agustin Martin]

On Tue, Sep 26, 2023 at 09:38:22AM +0200, Bertram Felgenhauer wrote:
> Package: grub2
> Version: 2.12~rc1-10
> 
> It's also worth noting that `update-grub` does not appear to pick up
> files from `/etc/default/grub.d` so putting the setting there is
> ineffective. (I put the setting into `/etc/default/grub.d/99-osprober`
> and update-grub didn't pick it up in my test.)

Hi,

I have my 'local-settings.cfg' in that dir and works as expected.

Does using '/etc/default/grub.d/99-osprober.cfg' work?

Regards,

-- 
Agustin

Bug#1052645: owncloud-client: New 4.2.0.11670 upstream version available

[Agustin Martin]

Package: owncloud-client
Version: 3.2.0.10193+dfsg-1
Severity: wishlist

Dear Maintainer,

Noticed that 4.2.0.11670 upstream version is available from

https://download.owncloud.com/desktop/ownCloud/stable/latest/source/

(Note attic -> download name change)

It seems to fix at least RC

#1037411: nautilus-owncloud: menu doesn't appear due to nautilus API changes

Thank you very much for your work.

Regards,


-- 
Agustin

Bug#1051971: owncloud-client-cmd: Error transfering https://BLAH/owncloud/remote.php/webdav/status.php - server replied: Forbidden

[Agustin Martin]

On Mon, Sep 25, 2023 at 03:16:46PM +0200, Agustin Martin wrote:
> On Thu, Sep 14, 2023 at 09:07:38PM -0600, Sergio Mendoza wrote:
> > Package: owncloud-client-cmd
> > Version: 3.2.0.10193+dfsg-1
> > Severity: important
> > 
> > Dear mainteiner,
> > 
> >   With the new unstable version ( 3.2.0.10193+dfsg-1 ) of owncloudcmd,
> > when I try to sync with the onwcloud server I get the following error:
> > 
> > 23-09-14 20:45:05:955 [ warning sync.checkserverjob ]:  error: status.php 
> > replied 403
> > 23-09-14 20:45:05:955 [ fatal default ]:Failed to resolve
> > https://BLAH/owncloud/remote.php/webdav Error: Error transferring 
> > https://BLAH/owncloud/remote.php/webdav/status.php - server replied: 
> > Forbidden.
> > Aborted
> 
> Hi,
> 
> For the records, that version has been working in my sid box until last
> Thursday, where, after server upgrade from 10.12.1.3 to 10.13.1.3, this
> error started to appear

Forgot to mention that I refer to owncloud-client package.

-- 
Agustin

Bug#1051971: owncloud-client-cmd: Error transfering https://BLAH/owncloud/remote.php/webdav/status.php - server replied: Forbidden

[Agustin Martin]

On Thu, Sep 14, 2023 at 09:07:38PM -0600, Sergio Mendoza wrote:
> Package: owncloud-client-cmd
> Version: 3.2.0.10193+dfsg-1
> Severity: important
> 
> Dear mainteiner,
> 
>   With the new unstable version ( 3.2.0.10193+dfsg-1 ) of owncloudcmd,
> when I try to sync with the onwcloud server I get the following error:
> 
> 23-09-14 20:45:05:955 [ warning sync.checkserverjob ]:  error: status.php 
> replied 403
> 23-09-14 20:45:05:955 [ fatal default ]:Failed to resolve
> https://BLAH/owncloud/remote.php/webdav Error: Error transferring 
> https://BLAH/owncloud/remote.php/webdav/status.php - server replied: 
> Forbidden.
> Aborted

Hi,

For the records, that version has been working in my sid box until last
Thursday, where, after server upgrade from 10.12.1.3 to 10.13.1.3, this
error started to appear

Server replied "403 Forbidden" to PROPFIND https://xxx.xxx.es/remote.php/webdav 
(Unsupported client version)

Contacting my institution support they told me that they are having problems
after that upgrade with client versions lower that 3.2 (I would not expect
3.2.0 to fail, but ...). 

¿Has your server been recently upgraded?

A colleage using Ubuntu installed last version (4.2.0) from owncloud.com
and claims that it made it work again. While there are Debian packages
there, I would prefer not to use them, but wait for 4.2.0 to be officially
packaged for Debian.

Regards,

PS: Having owncloud-client 4.2.0 in Debian would be nice ;-)

-- 
Agustin

Bug#1052166: mmm-mode: should avoid the conflict with xemacs21 by disabling the xemacs flavors

[Agustin Martin]

On Thu, Sep 21, 2023 at 01:06:58PM +0200, Agustin Martin wrote:
> On Mon, Sep 18, 2023 at 05:03:36PM +0200, Vincent Lefevre wrote:
> > Package: mmm-mode
> > Version: 0.5.9-2
> > Severity: important
> > Tags: patch
> > 
> > The conflict with xemacs21 is not acceptable as it prevents the
> > installation of mmm-mode on machines with both emacs-gtk and xemacs21
> > installed (typically multi-user machines).
> 
> Hi, Vincent.
> 
> Fully agree. I think this is something that should be quickly addressed.

Hi,

One more thing on this,

maxima-emacs used to rely on mmm-mode to have available cl-lib for XEmacs.
It now fails on postinst. I guess it should now have its own copy of
cl-lib.el or place one in a common site. 

By the way, tested that just shipping
/usr/share/xemacs21/site-lisp/mmm-mode/cl-lib.el (no need to byte.compile
it) is enough for this.

Regards,

-- 
Agustin

Bug#1052166: mmm-mode: should avoid the conflict with xemacs21 by disabling the xemacs flavors

[Agustin Martin]

On Mon, Sep 18, 2023 at 05:03:36PM +0200, Vincent Lefevre wrote:
> Package: mmm-mode
> Version: 0.5.9-2
> Severity: important
> Tags: patch
> 
> The conflict with xemacs21 is not acceptable as it prevents the
> installation of mmm-mode on machines with both emacs-gtk and xemacs21
> installed (typically multi-user machines).

Hi, Vincent.

Fully agree. I think this is something that should be quickly addressed.

> It appears that disabling the xemacs flavors avoids the installation
> failure (see attached patch, which removes the conflict and patches
> mmm-mode.emacsen-install to disable the xemacs flavors and do some
> cleanup); apel and flim do something similar:
> 
> case $FLAVOR in
> *xemacs*|emacs2[0-3]|emacs1?|mule2)
> exit 0
> ;;
> esac

Tested your patch and verified that works.

For the records, when triaging bug report I have been playing with
mmm-mode.emacsen-install to rewrite some parts to my taste. I am attaching
it in case maintainer finds something useful in it. It currently disables
XEmacs, but this can be easily modified in case it is supported again.
Instalation tested only for Emacs.

> and ditto for w3m-el:
> 
> case $FLAVOR in
> *xemacs*|emacs2[0-5]|emacs1?|mule2)
> exit 0
> ;;
> esac

I do not see problems with w3m-el.

> Note that mmm-mode.emacsen-remove still has a comment about xemacs,
> but I suppose that this doesn't matter.

I think this is OK in case XEmacs is supported again or for upgrades from
previous versions where XEmacs was supported.

Regards,

-- 
Agustin
#!/bin/sh -e

package=mmm-mode

# Common lisp files
FILES="mmm-auto.el mmm-class.el mmm-cmds.el mmm-compat.el mmm-cweb.el 
mmm-defaults.el mmm-erb.el mmm-mason.el mmm-mode.el mmm-myghty.el mmm-noweb.el 
mmm-region.el mmm-rpm.el mmm-sample.el mmm-univ.el mmm-utils.el mmm-vars.el"
# Flavour dependent lisp files
XFILES=""

FLAVOR="$1"

case "$FLAVOR" in
emacs)
SITEFLAG="--no-site-file"
;;
xemacs*)
# Temporarily disable XEmacs byte-compilation
echo "install/${package}: Skipping byte-compilation for $FLAVOR"
exit 0
SITEFLAG="-no-site-file"
XFILES="cl-lib.el"
;;
emacs*)
# Do not byte-compile for other emacsen flavors
echo "install/${package}: Skipping byte-compilation for $FLAVOR"
exit 0
;;
*)
echo install/${package}: Ignoring emacsen flavor [${FLAVOR}]
exit 0
;;
esac

echo "install/mmm-mode: byte-compiling for ${FLAVOR}"

# e25 makes things stale and unflavoured, just emacs and source dir == compile 
dir
# before that flavours emacs24, xemacs21 etc.
mkdir -p /usr/share/${FLAVOR}/site-lisp/mmm-mode

for i in $FILES; do
if [ ! -f /usr/share/${FLAVOR}/site-lisp/mmm-mode/$i ]; then
ln -s /usr/share/emacs/site-lisp/mmm-mode/$i 
/usr/share/${FLAVOR}/site-lisp/mmm-mode
fi
done

cd /usr/share/${FLAVOR}/site-lisp/mmm-mode
cat < path.el
(setq load-path (cons "." load-path) byte-compile-warnings nil)
EOF

${FLAVOR} -q ${SITEFLAG} -batch -l path.el -f batch-byte-compile $FILES 
${XFILES}
rm -f path.el

exit 0;

Bug#1051832: grub-efi-amd64: grub menu not shown on boot after upgrade to 2.12~rc1-9

[Agustin Martin]

Package: grub-efi-amd64
Version: 2.12~rc1-9
Severity: normal

Dear Maintainer,

After upgrade to 2.12~rc1-9 (from 2.06-13), grub menu is no longer shown during
boot. Pressing Shift key during boot does not help.

Browsing for some info I found

https://askubuntu.com/questions/182248/why-is-grub-menu-not-shown-when-starting-my-computer

where it is noted that sometines, auto loading of grub modules causes
race condition on slow PCs (this is a 10 years old box). To keep grub busy in
console and give enough time to load video modules, it is proposed to add 

# To resolve race condition when loading video drivers
videoinfo

at top of /boot/grub/grub.cfg. Did that, and menu is shown again in graphics
mode.

Adding GRUB_TERMINAL_OUTPUT=console to my /etc/default/grub.d/local-setings.cfg
and running update-grub also makes grub menu appear, now in text mode.

Downgrading to 2.06-13 also makes grub menu appear in graphics mode.

Thanks for your work.

Regards,

-- 
Agustin

Bug#1028408:

[Agustin Martin]

On 6/9/23 13:04, Agustin Martin wrote:
> On Tue, Jan 10, 2023 at 06:43:23PM +0100, olaf wrote:
>> Package: gnumeric
>> Version: 1.12.53-1.1+b1
>> Severity: normal
>>
>> With request to take note.
>>
>> Dear Maintainer,
>>
>> after updating to the current version, I am noticing discrepancies with my
>> entries in several documents. For example, sums like "9.95 €" are now
>> displayed as "9.9493" and "6.4" as "6.44"; simple
>> calculations like "=2.19/350"
>> now say "=2.1899/0.348", etc.
>
> Same problem here after creating spreadsheet and saving it in
> MS Excel 97/2000/XP format. Before saving it 3,5 and 4,7 are correctly
> represented. Saving and loading it again renders 4,7 as
> 4,7001776.
>
> The interesting thing is that if I create the same spreadshet in gnumeric
> format, save it and reload it (all in gnumeric format), problem does not
> appear. If I then save the file in above excel format and reload it,
> problem is back with the saved excel file.
>

Tested a bit more, trying to save in different formats from just
created gnumeric file with "3.5" and "4.7".

As said, "MS Excel 97/2000/XP" fails and renders 4.7 wrong as above
after reload.

However, following formats seem to work well:

* Gnumeric XMP (.gnumeric)
* ODF 1.2 strict and extended conformance (.ods)
* ECMA 376 first and second edition (*.xlsx)

Regards,

-- 
Agustin

Bug#1028408: gnumeric: Decimal places change by themselves.

[Agustin Martin]

On Tue, Jan 10, 2023 at 06:43:23PM +0100, olaf wrote:
> Package: gnumeric
> Version: 1.12.53-1.1+b1
> Severity: normal
> 
> With request to take note.
> 
> Dear Maintainer,
> 
> after updating to the current version, I am noticing discrepancies with my 
> entries in several documents. For example, sums like "9.95 €" are now 
> displayed as "9.9493" and "6.4" as "6.44"; simple 
> calculations like "=2.19/350" now say "=2.1899/0.348", 
> etc.

Same problem here after creating spreadsheet and saving it in
MS Excel 97/2000/XP format. Before saving it 3,5 and 4,7 are correctly
represented. Saving and loading it again renders 4,7 as
4,7001776.

The interesting thing is that if I create the same spreadshet in gnumeric
format, save it and reload it (all in gnumeric format), problem does not
appear. If I then save the file in above excel format and reload it,
problem is back with the saved excel file.

Regards,

-- 
Agustin

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Agustin Martin]

El mar, 5 sept 2023 a las 20:32, Agustin Martin
() escribió:
>
> If /boot/efi is not mounted I get for new versions
>
> $ LC_ALL=C sudo dpkg-reconfigure grub-efi-amd64
> Installing for x86_64-efi platform.
> grub-install: error: cannot find EFI directory.
> Failed: grub-install --target=x86_64-efi --force-extra-removable
> WARNING: Bootloader is not properly installed, system may not be bootable
> Generating grub configuration file ...

One thing I did not remark. After this error, configuration continues
and apt dist-upgrade finishes without leaving grub-efi-amd64
unconfigured. This makes harder to notice this problem until
standalone package configuration is retried when debugging the
problem.

Regards,

-- 
Agustin

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Agustin Martin]

> On Tue, Sep 05, 2023 at 07:34:13PM +0200, Julian Andres Klode wrote:
> I wrote
> > If /boot/efi is not mounted I get for new versions
>
> Well that's *your problem*, sorry. Mounting /boot/efi is mandatory,
> you can't just go unmount it. By the same argument unmounting /boot
> (if a separate partition) yields an unbootable system too (eventually
> once /boot on / becomes out of sync with actual boot partition grub
> uses).

Hi, Julian, thanks for your reply.

It was my understanding that grub-install did know how to find and use
the efi partition if not mounted, seems I was wrong. But for some
reason this problem did not show up in previous version, see below.

El mar, 5 sept 2023 a las 21:40, Julian Andres Klode
() escribió:
> I wrote
> > $ LC_ALL=C sudo dpkg-reconfigure grub-efi-amd64
> > Installing for x86_64-efi platform.
> > grub-install: error: cannot find EFI directory.
> > Failed: grub-install --target=x86_64-efi --force-extra-removable
> > WARNING: Bootloader is not properly installed, system may not be bootable
> > Generating grub configuration file ...
> >
> > (same without --force-extra-removable). No such error with previous version.
>
> Also, that's not true. grub-install for EFI of course always
> requires /boot/efi present, always has and always will*
>
> * on Ubuntu we mount to /var/lib/grub/esp if /boot/efi is not
>   mounted (or you have multiple ESPs configured), but the script
>   isn't in Debian yet, it's a bit hacky and duplicates lots of postinst
>   sightly different :(

I am rechecking 2.06-13 in a different efi box that was installed as
efi from the beginning (previous one was not). Although /boot/efi is
not mounted, error in grub-efi-amd64 configuration does not happen
(this does not mean that installation is fully OK, just that error
does not happen and grub is bootable). I do not remember to have
changed /etc/fstab to set noauto instead of defaults in that entry,
but this happened some years ago and sincerely, cannot be sure.

$ dpkg -l 'grub*' | grep ^i
ii  grub-common   2.06-13  amd64GRand Unified
Bootloader (common files)
ii  grub-efi-amd642.06-13  amd64GRand Unified
Bootloader, version 2 (EFI-AMD64 version)
ii  grub-efi-amd64-bin2.06-13  amd64GRand Unified
Bootloader, version 2 (EFI-AMD64 modules)
ii  grub-efi-amd64-signed 1+2.06+13amd64GRand Unified
Bootloader, version 2 (amd64 UEFI signed by Debian)
ii  grub2-common  2.06-13  amd64GRand Unified
Bootloader (common files for version 2)

$ grep /boot/efi /etc/fstab
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=5451-8D5D  /boot/efi   vfatumask=0077,noauto  0   1

$ mount | grep -i efi
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)

$ LC_ALL=C sudo apt-get install --reinstall grub-efi-amd64
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/45.7 kB of archives.
After this operation, 0 B of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 546089 files and directories currently installed.)
Preparing to unpack .../grub-efi-amd64_2.06-13_amd64.deb ...
Unpacking grub-efi-amd64 (2.06-13) over (2.06-13) ...
Setting up grub-efi-amd64 (2.06-13) ...
Generating grub configuration file ...
Found background image: .background_cache.png
Found linux image: /boot/vmlinuz-6.3.0-1-amd64
Found initrd image: /boot/initrd.img-6.3.0-1-amd64
Found linux image: /boot/vmlinuz-6.1.0-9-amd64
Found initrd image: /boot/initrd.img-6.1.0-9-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create
new boot entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/efi/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
Processing triggers for shim-signed:amd64 (1.39+15.7-1) ...

Regards,

-- 
Agustin

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Agustin Martin]

On Tue, Sep 05, 2023 at 07:34:13PM +0200, Julian Andres Klode wrote:
> On Tue, Sep 05, 2023 at 12:26:56PM -0400, M. Zhou wrote:
> > I am able to boot with 2.12~rc1-7 now. And my currrent status is
> >
> > grub-common/unstable,now 2.12~rc1-7 amd64 [installed]
> > grub-efi-amd64-bin/unstable,now 2.12~rc1-7 amd64 [installed,automatic]
> > grub-efi-amd64-signed/unstable,now 1+2.12~rc1+7 amd64
> > [installed,automatic]
> > grub-efi-amd64/unstable,now 2.12~rc1-7 amd64 [installed,automatic]
> > grub2-common/unstable,now 2.12~rc1-7 amd64 [installed,automatic]
> >
> > I reinstalled grub using 2.12~rc1-7.
> > But I still cannot guarantee it is safe to upgrade.
> >
> >
> > I believe the issue is the missing versioned dependency, which
> > allowed partial upgrade.
>
> Thanks for confirming this, this makes sense, if you boot without
> secure boot, the signed grub 2.06 could then try to upload
> incompatible modules from 2.12~rc1 and crash.

This may not be all the problem, I am still having problems with 2.12-rc1-7
and most recent packages installed with my old setup (/boot/efi not
mounted by default).

If /boot/efi is not mounted I get for new versions

$ LC_ALL=C sudo dpkg-reconfigure grub-efi-amd64
Installing for x86_64-efi platform.
grub-install: error: cannot find EFI directory.
Failed: grub-install --target=x86_64-efi --force-extra-removable
WARNING: Bootloader is not properly installed, system may not be bootable
Generating grub configuration file ...

(same without --force-extra-removable). No such error with previous version.

If I update everything with /boot/efi mounted and keep it mounted
afterwards, new grub versions are booting.

Regards,

-- 
Agustin

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Agustin Martin]

El mar, 5 sept 2023 a las 17:21, Agustin Martin
() escribió:
>
> On Tue, Sep 05, 2023 at 04:19:01PM +0200, Miguel A. Vallejo wrote:
> > Package: grub2
> > Version: 2.12~rc1-7
> > Severity: critical
> >
> > This morning I noticed an apt upgrade in Debian unstable/Sid upgraded
> > grub-common, grub2-common, grub-efi-amd64 and grub-efi-amd64-bin. The
> > upgrade went normally and no errors were shown. Then I turned the
> > computer off and after a few hours I tried to turn it on, but it
> > didn't boot, it tried to boot but finally showed the bios screen.
> >
> > After booting with a live USB and chroot into the hard drive, I
> > downgraded those four packages to version 2.06-3~deb11u5, and after
> > run install-grub, the computer booted normally.
> >
> > Anyone can confirm problems with version 2.12~rc1-7 and UEFI machines?
>
> Same problem here.

I can confirm that downgrading all above grub packages to 2.06-13,
reinstalling grub and updating grub.cfg works around this issue.

Did all together, only part of the above might be required. Previously
tried to change grub.cfg to an old version to check if I could reach
the grub menu, but no luck.

diffing old (the one generated by buggy grub) and new grub.cfg created
after downgrading I see a dis_ucode_ldr parameter as well as an 'UEFI
Firmware Settings' entry in old grub.cfg.

Hope this helps

-- 
Agustin

Bug#1051271: GRUB2 2.12~rc1-7 prevent machine to boot

[Agustin Martin]

On Tue, Sep 05, 2023 at 04:19:01PM +0200, Miguel A. Vallejo wrote:
> Package: grub2
> Version: 2.12~rc1-7
> Severity: critical
>
> This morning I noticed an apt upgrade in Debian unstable/Sid upgraded
> grub-common, grub2-common, grub-efi-amd64 and grub-efi-amd64-bin. The
> upgrade went normally and no errors were shown. Then I turned the
> computer off and after a few hours I tried to turn it on, but it
> didn't boot, it tried to boot but finally showed the bios screen.
>
> After booting with a live USB and chroot into the hard drive, I
> downgraded those four packages to version 2.06-3~deb11u5, and after
> run install-grub, the computer booted normally.
>
> Anyone can confirm problems with version 2.12~rc1-7 and UEFI machines?

Same problem here.

-- 
Agustin

Bug#1034744: Bug#1024695: also debian-ispell

[Agustin Martin]

Control: tags 1034744 + wontfix

El jue, 3 ago 2023 a las 19:58, Dan Jacobson () escribió:
> Hi 1034744 team: please see #1024695 as a bug that could get fixed at
> the same time...

#1034744 is not a  bug but a design choice inside  emacsen-common
policy, please look at the thread mentioned at #1034744.
emacsen-commmon must be configured before packages shipping elisp
snippets are configured, but if packages contain more than those
snippets they may be installed without Emacs ittself (emacsen-common
does not pull Emacs or XEmacs and is a very small package whose
installation without {X}Emacs causes no problemas at all). This
(wishlist) report is left open just to be a reference, but I am
tagging it wontfix to make more clear things about it.

Regards,

-- 
Agustin

Bug#1043809: br.ispell: Fails to build source after successful build

[Agustin Martin]

El dom, 13 ago 2023 a las 16:12, Eriberto Mota () escribió:
>
> Control: tags 1043809 patch
>
> On Sun, 13 Aug 2023 15:17:55 +0200
> Lucas Nussbaum  wrote:
> >
> > This package fails to build a source package after a successful build
> > (dpkg-buildpackage ; dpkg-buildpackage -S).
>
> Dear maintainer,
>
> The attached patch fixes this issue.

Thanks for the patch, Eriberto.

There is another issue I would like to handle with this upload, so I
will wait some days before actually uploading.

Old upstream location for this package
(https://www.ime.usp.br/~ueda/br.ispell/) seems gone, as well as
download location (http://www.ime.usp.br/~ueda/br.ispell/beta.html).
https://www.ime.usp.br seems to have changed their www page and old
personal stuff from Ricardo Ueda is no longer accesible. If I cannot
find a new project location I will change watch file by your "No-Site"
watch snippet.

Regards,

-- 
Agustin

Bug#1037642: encfs: ftbfs with GCC-13

[Agustin Martin]

> The package fails to build in a test rebuild on at least amd64 with 
> gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The severity of this 
> report will be raised before the trixie release.

> The full build log can be found at:
> http://qa-logs.debian.net/2023/05/22/logs/encfs_1.9.5-2_unstable_gccexp.log
> The last lines of the build log are at the end of this report.

> To build with GCC 13, either set CC=gcc-13 CXX=g++-13 explicitly, or install 
> the gcc, g++, gfortran, ... packages from experimental.

Hi, Mathias,

I have tried to triage this bug report by adding to debian/rules

export CC  = gcc-13
export CXX = g++-13

in a plain sid cowbuilder chroot and could not reproduce this problem
(log shows that g++-13 is indeed used).

I have also created a sid+experimental cowbuilder chroot and followed
guidelines, and also did not succeed (by the way, g++ in experimental
seems to have reached sid).

Regards,

-- 
Agustin

Bug#1034744: Please consider making emacs support optional

[Agustin Martin]

Control: reassign -1 emacsen-common,dictionaries-common

El mar, 25 abr 2023 a las 9:29, Agustin Martin () escribió:
>
> El dom, 23 abr 2023 a las 7:45, Josh Triplett
> () escribió:
> >
> > Package: dictionaries-common
> > Version: 1.29.5
> > Severity: wishlist
> > X-Debbugs-Cc: j...@joshtriplett.org
> >
> > As far as I can tell, the support provided by dictionaries-common makes
> > emacs better if installed, but isn't needed if an emacs isn't installed.
> > The maintainer scripts correctly check to see if the necessary binaries
> > are installed before invoking them. Would it be possible to change the
> > emacsen-common Depends to a Recommends?
>
> Hi, Josh,
>
> This is mandated by emacsen-common policy, point 5C
>
> /usr/share/doc/emacsen-common/debian-emacs-policy.gz

Reassigning this bug report to both emacsen-common and
dictionaries-common, as dictionaries-common just follows
emacsen-common policy.

Bug#1037060: run-with-aspell.1: Fix some formatting issues in the man page

[Agustin Martin]

Control: forwarded -1 https://github.com/GNUAspell/aspell/issues/636
Control: tags -1 + pending forwarded-upstream

El sáb, 3 jun 2023 a las 4:09, Bjarni Ingi Gislason
() escribió:
>
> Package: aspell
> Version: 0.60.8-4+b1
> Severity: minor
> Tags: patch
>
> Dear Maintainer,
>
> here are some fixes.

Thanks, forwarsed upstream and tagged as pending

Regards,

-- 
Agustin

Bug#1037059: aspell.1: fix some formatting issues in the man page

[Agustin Martin]

Control: forwarded -1 https://github.com/GNUAspell/aspell/issues/636
Control: tags -1 + pending forwarded-upstream

El sáb, 3 jun 2023 a las 3:45, Bjarni Ingi Gislason
() escribió:
>
> Package: aspell
> Version: 0.60.8-4+b1
> Severity: minor
> Tags: patch
>
> Dear Maintainer,
>
> here are some fixes.

Thanks, forwarded upstream and tagged as pending.

-- 
Agustin

Bug#1034744: Please consider making emacs support optional

[Agustin Martin]

El dom, 23 abr 2023 a las 7:45, Josh Triplett
() escribió:
>
> Package: dictionaries-common
> Version: 1.29.5
> Severity: wishlist
> X-Debbugs-Cc: j...@joshtriplett.org
>
> As far as I can tell, the support provided by dictionaries-common makes
> emacs better if installed, but isn't needed if an emacs isn't installed.
> The maintainer scripts correctly check to see if the necessary binaries
> are installed before invoking them. Would it be possible to change the
> emacsen-common Depends to a Recommends?

Hi, Josh,

This is mandated by emacsen-common policy, point 5C

/usr/share/doc/emacsen-common/debian-emacs-policy.gz

AFAIR, this is done to ensure that emacsen-common is configured before
add-on package is configured. This was discussed in a rather old
thread started by
https://lists.debian.org/debian-emacsen/2010/07/msg0.html

> dictionaries-common is the only thing on my system pulling in the
> emacsen-common machinery, and dictionaries-common is in turn a
> dependency of required packages for various other programs.

emacsen-common is a rather small package with no dependencies, should
not be a big problem, this was considered a reasonable compromise by
emacs maintainer.

Regards,


--
Agustin

Bug#1034362: [PATCH] sgmls: Avoid implicit ints/function declarations in configure

[Agustin Martin]

Control: tags -1 + fixed-upstream pending

El jue, 13 abr 2023 a las 18:27, Florian Weimer () escribió:
>
> Package: linuxdoc-tools
> Version:  0.9.82-1
> Tags: upstream patch
>
> These C features are no longer part of C99, and future compilers
> will no longer support them by default, causing the build to fail.
>
> The changes assume that the usual system headers (,
> ) are present, but that should not be a problem on current
> systems.

Thanks for the patch, committed upstream and bug report tagged accordingly.

Regards,

-- 
Agustin

Bug#1033281: unblock: dictionaries-common/1.29.5

[Agustin Martin]

El mar, 21 mar 2023 a las 9:40, Agustin Martin () escribió:
>
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: dictionaries-com...@packages.debian.org
> Control: affects -1 + src:dictionaries-common
>
> Please unblock package dictionaries-common
...
> While changes are not at all critical (things will keep working with
> old info, new location for bdic conversion tool is just a symlink tp
> old one) I would appreciate if last version reaches testing to avoid
> having different info in new_stable and sid (and to have my git
> history as clean as possible and avoid branches in case something
> really important deserves an upload).
>
> I am attaching a full debdiff with all changes from previous version
> and a "debdiff -w" file skipping whitespace changes.

debdiff -w output really attached. Sorry for the noise.
diff -Nru -w dictionaries-common-1.29.4/debian/changelog dictionaries-common-1.29.5/debian/changelog
--- dictionaries-common-1.29.4/debian/changelog	2023-01-25 23:07:33.0 +0100
+++ dictionaries-common-1.29.5/debian/changelog	2023-03-14 22:17:31.0 +0100
@@ -1,3 +1,15 @@
+dictionaries-common (1.29.5) unstable; urgency=medium
+
+  [ Soren Stoutner ]
+  * debian/copyright:  Update copyright dates to include 2023.
+  * policy/dsdt-policy.xml.in:  Update to reflect changes in the Qt
+packaging.
+
+  [ Agustin Martin Domingo ]
+  * installdeb-myspell: Add /usr/bin/convert-bdic as first option.
+
+ -- Agustin Martin Domingo   Tue, 14 Mar 2023 22:17:31 +0100
+
 dictionaries-common (1.29.4) unstable; urgency=medium
 
   * debian/po/ro.po: Romanian debconf templates translation-revision,
diff -Nru -w dictionaries-common-1.29.4/debian/copyright dictionaries-common-1.29.5/debian/copyright
--- dictionaries-common-1.29.4/debian/copyright	2022-12-06 22:57:10.0 +0100
+++ dictionaries-common-1.29.5/debian/copyright	2023-03-14 22:12:41.0 +0100
@@ -5,9 +5,9 @@
 
 Files: *
 Copyright: 1999-2008 Rafael Laboissiere 
-	   2001-2022 Agustín Martín Domingo 
+   2001-2023 Agustín Martín Domingo 
 	   2003-2016 René Engelhard 
-	   2022 Soren Stoutner 
+   2022-2023 Soren Stoutner 
 License: GPL-2+
 
 Files: support/emacsen/ispell.el
diff -Nru -w dictionaries-common-1.29.4/policy/dsdt-policy.xml.in dictionaries-common-1.29.5/policy/dsdt-policy.xml.in
--- dictionaries-common-1.29.4/policy/dsdt-policy.xml.in	2022-12-13 18:24:52.0 +0100
+++ dictionaries-common-1.29.5/policy/dsdt-policy.xml.in	2023-03-14 22:12:41.0 +0100
@@ -139,7 +139,7 @@
 
 
   
-	1999-2014,2022
+1999-2014,2022-2023
   
   
 	Rafael Laboissire, David Coe, Agustn
@@ -781,14 +781,10 @@
 	
 	
 	  
-	Hunspell dictionary packages should build-depend on
-	qt6-webengine-dev-tools or a superseding package
-	so that they can use qwebengine_convert_dict to
-	generate the binary .bdic dictionary files.
-	Although qwebengine_convert_dict is also
-	available in qtwebengine5-dev-tools (in a
-	different path) its use is discouraged as it will disappear
-	sooner.
+Hunspell dictionary packages should build-depend on the
+convert-bdic package so that they can use the
+convert-bdic command to generate the binary
+.bdic dictionary files.
 	For more information see .
 	  
 	
@@ -1374,24 +1370,30 @@
 	binary .bdic file.
 	Qt distributes a renamed version of this tool
 	called qwebengine_convert_dict that is
-	shipped in Debian as part of
+currently shipped in Debian as part of
 	the qt6-webengine-dev-tools package.
   
   
+Because the versions of Qt available in Debian change over time,
+the latest version of Qt that ships
+qwebengine_convert_dict will always provide a
+virtual package named convert-bdic which will
+install a symlink from /usr/bin/convert-bdic
+to the current versioned location of
+qwebengine_convert_dict.
+  
+  
 	Hunspell dictionaries should build-depend on
-	qt6-webengine-dev-tools or a newer package
-	that supersedes it.
-	During binary package creation they should compile the binary
-	dictionary by calling a command similar to the following
-	where xx_XX corresponds to the language of
-	the Hunspell dictionary.
-	The .dic needs to reside in the same
-	directory as the .aff during binary
-	compilation so that qwebengine_convert_dict
-	can locate it.
+convert-bdic. During binary package creation
+they should compile the binary dictionary by calling a command
+similar to the following where xx_XX
+corresponds to the language of the Hunspell dictionary.
+The .aff needs to reside in the same
+directory as the .dic during binary compilation so
+that convert-bdic can locate it.
   
   
-/usr/lib/qt6/libexec/qwebengine

Bug#1033281: unblock: dictionaries-common/1.29.5

[Agustin Martin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: dictionaries-com...@packages.debian.org
Control: affects -1 + src:dictionaries-common

Please unblock package dictionaries-common

Sorry I forgot about hard freeze starting 2023-03-12. Did not it
notice until 2023-03-16 message from the release team (Bits from the
Release Team: bookworm in hard freeze), but uploaded this version on
2023-03-14.

Changes are documentation changes in hunspell dictionaries policy to
adjust it to last changes in qt6-webengine-dev that reached testing on
2023-03-09 and a minor change in installdeb-myspell to look for bdic
conversion tool first in new location.

While changes are not at all critical (things will keep working with
old info, new location for bdic conversion tool is just a symlink tp
old one) I would appreciate if last version reaches testing to avoid
having different info in new_stable and sid (and to have my git
history as clean as possible and avoid branches in case something
really important deserves an upload).

I am attaching a full debdiff with all changes from previous version
and a "debdiff -w" file skipping whitespace changes.

Thanks for all and sorry for having missed this.

unblock dictionaries-common/1.29.5
diff -Nru dictionaries-common-1.29.4/debian/changelog dictionaries-common-1.29.5/debian/changelog
--- dictionaries-common-1.29.4/debian/changelog	2023-01-25 23:07:33.0 +0100
+++ dictionaries-common-1.29.5/debian/changelog	2023-03-14 22:17:31.0 +0100
@@ -1,3 +1,15 @@
+dictionaries-common (1.29.5) unstable; urgency=medium
+
+  [ Soren Stoutner ]
+  * debian/copyright:  Update copyright dates to include 2023.
+  * policy/dsdt-policy.xml.in:  Update to reflect changes in the Qt
+packaging.
+
+  [ Agustin Martin Domingo ]
+  * installdeb-myspell: Add /usr/bin/convert-bdic as first option.
+
+ -- Agustin Martin Domingo   Tue, 14 Mar 2023 22:17:31 +0100
+
 dictionaries-common (1.29.4) unstable; urgency=medium
 
   * debian/po/ro.po: Romanian debconf templates translation-revision,
diff -Nru dictionaries-common-1.29.4/debian/copyright dictionaries-common-1.29.5/debian/copyright
--- dictionaries-common-1.29.4/debian/copyright	2022-12-06 22:57:10.0 +0100
+++ dictionaries-common-1.29.5/debian/copyright	2023-03-14 22:12:41.0 +0100
@@ -5,9 +5,9 @@
 
 Files: *
 Copyright: 1999-2008 Rafael Laboissiere 
-	   2001-2022 Agustín Martín Domingo 
-	   2003-2016 René Engelhard 
-	   2022 Soren Stoutner 
+   2001-2023 Agustín Martín Domingo 
+   2003-2016 René Engelhard 
+   2022-2023 Soren Stoutner 
 License: GPL-2+
 
 Files: support/emacsen/ispell.el
diff -Nru dictionaries-common-1.29.4/policy/dsdt-policy.xml.in dictionaries-common-1.29.5/policy/dsdt-policy.xml.in
--- dictionaries-common-1.29.4/policy/dsdt-policy.xml.in	2022-12-13 18:24:52.0 +0100
+++ dictionaries-common-1.29.5/policy/dsdt-policy.xml.in	2023-03-14 22:12:41.0 +0100
@@ -139,7 +139,7 @@
 
 
   
-	1999-2014,2022
+1999-2014,2022-2023
   
   
 	Rafael Laboissire, David Coe, Agustn
@@ -779,19 +779,15 @@
 myspell dictionary package.
   
 	
-	
-	  
-	Hunspell dictionary packages should build-depend on
-	qt6-webengine-dev-tools or a superseding package
-	so that they can use qwebengine_convert_dict to
-	generate the binary .bdic dictionary files.
-	Although qwebengine_convert_dict is also
-	available in qtwebengine5-dev-tools (in a
-	different path) its use is discouraged as it will disappear
-	sooner.
-	For more information see .
-	  
-	
+
+  
+Hunspell dictionary packages should build-depend on the
+convert-bdic package so that they can use the
+convert-bdic command to generate the binary
+.bdic dictionary files.
+For more information see .
+  
+
   
 
 
@@ -1357,106 +1353,105 @@
   Hunspell Binary Dictionaries
   
   
-	Google's Chromium project developed a binary Hunspell file
-	format used for spell checking by their web engine.
-	The binary format combines the
-	text-based .dic
-	and .aff files into
-	one .bdic binary file.
-	Other web engines that are based on Chromium's code, like Qt
-	WebEngine included in KDE, can also use
-	these .bdic dictionaries.
-  
-  
-	Google created a tool called convert_dict
-	that takes the input from a pair of .dic
-	and .aff files and compiles them into a
-	binary .bdic file.
-	Qt distributes a renamed version of this tool
-	called qwebengine_convert_dict that is
-	shipped in Debian as part of
-	the qt6-webengine-dev-tools package.
-  
-  
-	Hunspell dictionaries should build-depend on
-	qt6-webengine-dev-tools or a newer package
-	that supersedes it.
-	During binary package creation they should compile the binary
-	dictionary by calling a command similar to the following
-	where xx_XX c

Bug#1033154: aspell-en: should not have /var/lib files in the package

[Agustin Martin]

El sáb, 18 mar 2023 a las 15:09, Russell Coker
() escribió:
>
> Package: aspell-en
> Version: 2020.12.07-0-1
> Severity: minor
>
> The FHS describes /var/lib as "State information. Persistent data modified by
> programs as they run (e.g., databases, packaging system metadata, etc.)."
>
> The files that are included in a package are expected not to change in normal
> operation and therefore aren't "modified by programs".  So /var/lib isn't the
> right place for this.  Maybe /usr/lib would be the right place.
>
> One reason that this matters is for security systems that treat /usr and /var
> differently.

Hi, Russell,

The origin of this was a wrong choice from dictionaries-common many
years ago. That dir contains info supplied by packages containing
dicts that is used to help different programs requiring spellchecking
to have the relevant info. So, this is not aspell-en specific.

Regards,

-- 
Agustin

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El sáb, 4 feb 2023 a las 20:20, Rene Engelhard () escribió:
>
> Hi,
>
> Am 04.02.23 um 19:14 schrieb Soren Stoutner:
> > Seeing as how .bdic files are not exclusive to Qt, qt-convert-dict is 
> > probably
> > not the most accurate name, but bdic-convert-dict would make sense.  Another
> > option would be to name it convert-bdic.  The Chromium upstream names the 
> > tool
> > convert_dict, but we aren’t beholden to follow their lead.
> >
> > I have updated the merge request to name the tool /usr/bin/convert-bdic,  
> > and
> > the virtual package to be convert-bdic, but can change it again if there is 
> > a
> > consensus in a different direction.
>
> convert-bdic is fine with me,  thanks :)

Also fine with me, thanks.

One question. Will old packages keep shipping conversion tool using
old name and location for a while? We would otherwise need to rebuild
dicts to use new dependency and avoid FTBFS. Once it is clear that
/usr/bin/convert-bdic is the new path I will add it as preferred path.

Regards,

-- 
Agustin

Bug#1028473: dictionaries-common: problem in russian dict. Word '��� ��' contains illegal characters.

[Agustin Martin]

Control: reassign -1 irussian
Control: tags -1 + patch pending

El sáb, 14 ene 2023 a las 15:39, Jason Lee Quinn
() escribió:
>
> Package: dictionaries-common
> Version: 1.29.3
> Followup-For: Bug #1028473
> X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com
>
> Thank you for the reply.
>
> If these dictionaries are installed,
> where are they located? I've searched
> /usr/lib/ispell and many other places can only find
> american and british dictionaries on my machine.

Hi,

You should find relevant files under different dirs. In one of my boxes

$ dir /usr/lib/ispell/ /usr/share/ispell/ /var/lib/ispell/
/var/lib/dictionaries-common/ispell/

/usr/lib/ispell/:
american.affcastellano.hash  english.affespanol.hash
spanish.hash
american.hashdefault.aff espa~nol.affREADME.select-ispell
castellano.affdefault.hash espa~nol.hashspanish.aff

/usr/share/ispell/:
american.med+.mwl.gz  american.mwl.gz  english.aff  espa~nol.mwl.gz

/var/lib/dictionaries-common/ispell/:
iamerican  ispanish

/var/lib/ispell/:
american.compat  american.hashamerican.remove  espa~nol.compat
espa~nol.hash  espa~nol.remove  README

If there is no trace of those dicts in your dirs, synaptic is
upgrading something else (A virtual machine?)

> Also where does the "contains illegal characters" message
> actually come from? Whatever the source of that messgae,
> I'm having trouble tracking it down. A techincal explaination
> about why the message is harmless would also be interesting
> for me. Perhaps the message itself and the logic that produces
> it could be improved to provide a nicer user experience.

Munched word in line 39 of original russian ispell dict contains
whitespace, which is allowed only as word separator, not in the middle
of a word. Then ispell (and aspell) complains about it and skips that
word, that is the message. This is harmless because its only result is
that word is skipped.

Attached patch should strip that word before package is built, thus
making the message go away. I am reassigning this bug report to
irussian (I am also uploader for it)  and will upload a package with
this fix unless maintainer disagree.

Thanks again for your feedback.

-- 
Agustin
diff --git a/debian/rules b/debian/rules
index 565a92f..2ce6cfc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -28,7 +28,7 @@ export LANG LC_ALL
 override_dh_auto_build:
 	# Generate ispell dictionary.
 	grep -h '[３]' $(DICTIONARIES) | tr '\243\263' '\305\345' > yo_subst.koi
-	cat $(DICTIONARIES) yo_subst.koi |./sortkoi8 | uniq > $(ILANGUAGE).dict
+	cat $(DICTIONARIES) yo_subst.koi |./sortkoi8 | uniq | LC_ALL=C grep -v ' ' > $(ILANGUAGE).dict
 	sed -e "s/^\#[ye]//;s/^\#koi/wordchars/" $(ILANGUAGE).aff.koi > $(ILANGUAGE).aff
 	# Generate traditional ispell hash needed by i2myspell.
 	buildhash $(ILANGUAGE).dict $(ILANGUAGE).aff $(ILANGUAGE).hash

Bug#1028473: dictionaries-common: problem in russian dict. Word '��� ��' contains illegal characters.

[Agustin Martin]

El mié, 11 ene 2023 a las 17:15, Jason Lee Quinn
() escribió:
>
> Package: dictionaries-common
> Version: 1.29.3
> Severity: minor
> X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com
>
> Dear Maintainer,
>
> About two weeks ago on a fresh install of Debian Bookworm
> from a daily installer build I
> came accross a dictionary error related to the
> installation of synaptic. The relavent output is
>
> 
>
> Setting up synaptic (0.91.2) ...
> Processing triggers for dictionaries-common (1.29.3) ...
> ispell-autobuildhash: Processing 'american' dict.
> ispell-autobuildhash: Processing 'brasilero' dict.
> ispell-autobuildhash: Processing 'british' dict.
> ispell-autobuildhash: Processing 'catala' dict.
> ispell-autobuildhash: Processing 'danish' dict.
> ispell-autobuildhash: Processing 'espa-nol' dict.
> ispell-autobuildhash: Processing 'lietuviu' dict.
> ispell-autobuildhash: Processing 'ngerman' dict.
> ispell-autobuildhash: Processing 'polish' dict.
> ispell-autobuildhash: Processing 'portugues' dict.
> ispell-autobuildhash: Processing 'russian' dict.
>
> Word '��� ��' contains illegal characters.
> ispell-autobuildhash: Processing 'swiss' dict.

HI,

This is a harmless message during hash creation for russian ispell
dict. Nothing to worry about.

> It looks to be an error in a dictionary file
> but I never selected any language except English so
> this is default behavior and as far as I can
> tell I do not even have the russian dictionary
> installed at all.

By the way, you have all those ispell dicts installed although you may
have not explicitly installed them.

Thanks for your contribution to Debian

-- 
Agustin

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El vie, 23 dic 2022 a las 17:21, Roland Rosenfeld
() escribió:
>
> Hi Agustin!
>
> > By the way, I have been playing with an old helper
> > (installdeb-myspell) shipped with dictionaries-common-dev to help with
> > these bdic files. First cut committed to salsa. Currently
> > installdeb-myspell will fail if no conversion tool is found.
>
> Just one question about this: Why did you add this code to
> installdeb-myspell and not to installdeb-hunspell?
> It's quite confusing that the .bdic file (used by hunspell) is
> generated by installdeb-myspell and not by installdeb-hunspell,
> especially since the former uses debian/info-myspell and the latter
> uses debian/info-hunspell (so I now need to have both of them...).

Hi, Roland,

I agree that this may sound strange and there is indeed no big reason
behind. Just did it because it was simpler and more straighforward to
reuse installdeb-myspell code and debian/info-myspell file format when
playing with this. Also, debian/info-hunspell is harder to handle from
e.g., lo-dicts while it should be easier to generate a temporary file
in debian/info-myspell file format from minimal info.

Regards

-- 
Agustin

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El mar, 13 dic 2022 a las 18:43, Soren Stoutner () escribió:
>
> Can one of the Debian Qt/KDE maintainers weigh in on the feasibility of 
> either creating a meta package that depends on the most recent package that 
> includes qwebengine_convert_dict or creating an unversioned package that 
> installs qwebengine_convert_dict?  Also, either having 
> qwebengine_convert_dict being installed in an unversioned location or having 
> a symlink that is unversioned?  That would make it easier for Hunspell 
> language packages to build-depend on qwebengine_convert_dict and wouldn’t 
> require reworking all of those packages’ build scripts every time the version 
> of Qt in Debian changes.

I modified installdeb-myspell to look for both, with qt6 version
preferred. In policy document, I commented about qt5 version
existence, but discouraging its use as it will disappear sooner. In
theory it could be useful for stable backports, but since .bdic sid
version should be usable unchanged in stable there is no real use for
it.

> Regarding qwebengine_convert_dict expecting the .dic as a file entry, I am 
> not certain I understand what you are referring to.  This is how it builds on 
> my Debian testing system.  The .dic file must be in the same directory as the 
> .aff, but it isn’t specified (or at least doesn’t need to be specified) as a 
> file entry.

$ /usr/lib/qt6/libexec/qwebengine_convert_dict
Usage: qwebengine_convert_dict  

Just put what usage note and associated example shows, it is supposed
to be more "stable". Noticed that qwebengine_convert_dict seems to
accept any of both (and look for the other). In theory, a dic file may
have no associated aff file (and be a plain wordlist), but just
checked that even that requires an empty aff file.

-- 
Agustin

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El mar, 6 dic 2022 a las 23:34, Agustin Martin
() escribió:
>
> El dom, 4 dic 2022 a las 4:54, Soren Stoutner () escribió:
> >
> > I created an MR:
> >
> > https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5
> >
> > Please review and make sure I haven’t missed anything or misrepresented the 
> > consensus.
>
> Merged.
>
> Will wait some days for possible new comments.

By the way, I have been playing with an old helper
(installdeb-myspell) shipped with dictionaries-common-dev to help with
these bdic files. First cut committed to salsa. Currently
installdeb-myspell will fail if no conversion tool is found.

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El dom, 4 dic 2022 a las 4:54, Soren Stoutner () escribió:
>
> I created an MR:
>
> https://salsa.debian.org/debian/dictionaries-common/-/merge_requests/5
>
> Please review and make sure I haven’t missed anything or misrepresented the 
> consensus.

Merged.

Will wait some days for possible new comments.

Bug#1025326: tigervnc-standalone-server: tigervnc-standalone-server: Upgrade of libgl1-mesa-dri to 22.3.0 breaks Xvnc

[Agustin Martin]

El lun, 5 dic 2022 a las 13:40, Agustin Martin () escribió:
>
> Hi,
>
> Looking at
>
> https://bugs.debian.org/1025312 [libgl1-mesa-dri: multiple packages
> FTBFS and have autopkgtest regressions running test programs under
> Xvfb] I noticed that this #1025326 bug report is mentioned as a
> possible duplicate of #1025312.

This should be fixed in libgl1-mesa-dri 22.3.0-2, already in sid. Please check.

Thanks,

-- 
Agustin

Bug#1025326: tigervnc-standalone-server: tigervnc-standalone-server: Upgrade of libgl1-mesa-dri to 22.3.0 breaks Xvnc

[Agustin Martin]

Hi,

Looking at

https://bugs.debian.org/1025312 [libgl1-mesa-dri: multiple packages
FTBFS and have autopkgtest regressions running test programs under
Xvfb] I noticed that this #1025326 bug report is mentioned as a
possible duplicate of #1025312.

Regards,

-- 
Agustin

Bug#1025324: libc6: Xserver with nouveau not workiing.

[Agustin Martin]

Hi all,

Also hit by this problem (intel i5 box).

Noticed that Xorg log showing the error is very similar to what is seen in

#1025312 [libgl1-mesa-dri: multiple packages FTBFS and have
autopkgtest regressions running test programs under Xvfb]

Regards,

-- 
Agustin

Bug#1023558: dictionaries-common: installation fails with emacs23

[Agustin Martin]

El dom, 13 nov 2022 a las 23:06, Tatsuya Kinoshita () escribió:
>
> On 2022-11-13 at 22:35 +0100, Agustin Martin wrote:
> > > Installing dictionaries-common with "emacs23" fails
> >
> > No problem to change that., but I am curious What errors are you
> > getting?
>
> emacs23 segfaults as follows.
>
> ```
> # sh -x /usr/lib/emacsen-common/packages/install/dictionaries-common emacs23
> ...
> + emacs23 --no-site-file -q -batch -l path.el -f batch-byte-compile 
> debian-ispell.el ispell.el flyspell.el
> Fatal error (11)Segmentation fault
> ```
>
> emacs24 and later are fine.  So skipping emacs23 is enough for me.

Thanks for the info,

This seems to be a bug in emacs23, although triggered by some function
inside one of debian-ispell.el ispell.el or flyspell.el. Had emacs23
be an active flavor I would have gone with some debugging (at least to
know which elisp file is triggering this problem). But emacs23 is not
an active flavor, so expect a new package soon.

Regards,

-- 
Agustin

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El jue, 3 nov 2022 a las 23:33, Soren Stoutner () escribió:
>
> On Friday, October 28, 2022 4:09:45 AM MST Agustin Martin wrote:
> > I am not particularly happy about this (see details below), but seems
> > we will have to package all these .bdic files because qtwebengine and
> > chromium use them. Since some .bdic may fail to build I would rather
> > prefer them to be generated during package creation, where it is
> > easier not to create them if required. If done during package install
> > I think everything should be handled from qtwebengine package. In this
> > case some fine tuning can be done to improve efficiency (handling
> > symlinks better, regenerate only when a new version of dict package is
> > installed or incompatibilities in qtwebengine hunspell appear, ...)
>
> I agree with you.  I am also unhappy that Chromium and QtWebEngine want to use
> a specialized file format instead of just using the standard Hunspell files.
> However, as much as I don’t like it, I also agree with you that the best thing
> Debian can do in the short term is to move forward with the packaging of these
> .bdic files while we wait to see if we can make any changes upstream.
>
> Given that nobody else responded to this question, I think there is a
> consensus that it is best to create the .bdic files during package creation.
>
> The next question that needs to be answered is if we should create new binary
> packages for the .bdic files or if we should ship them as part of the existing
> Hunspell language binary packages.  The opinions that have been expressed so
> far have run the gamut on both sides, but my sense is they lean a little
> towards shipping them in the existing Hunspell packages so as to not add 80+
> new packages to Debian that only contain a few files each.
>
> Is there anyone who feels strongly that they should not be shipped in the
> existing files?

Hi,

I am for the approach that causes as little annoyance as possible to
the Debian archive, and I think that is using current packages. This
way we do not bother ftpmasters with all these new packages that might
be temporary.

I would personally expect this to be temporary until someone with the
appropiate skills provides a patch to make qtwebengine use system
hunspell in Debian (as has already been done for other libs in Debian
qtwebengine). I looked at the embedded hunspell code, but I am far
from having those skills, so got no result.

Also note that https://github.com/sheremetyev/hunspell seems to be
based in a 10 years old fork of hunspell. I hope hunspell code in
chromium and qtwebengine is not 10 years old and hunspell upstream has
been tracked for updates (at least for security updates). I have done
a quick comparison and they are not exactly the same, and not only
cosmetically, but did not go further.

It is to note that even that 10 years code apparently has support for
the IGNORE flag, unsupported by the .bdic dicts. Fortunately, seems
that there are not many dicts using that flag in
libreoffice-dictionaries.

libreoffice-dictionaries-7.4.2$ grep -r IGNORE *
dictionaries/bo/bo.aff:IGNORE ༵༷
dictionaries/ar/ar.aff:IGNORE ًٌٍَُِّْـٰ
dictionaries/uk_UA/uk_UA.aff:IGNORE ́
dictionaries/ckb/dictionaries/ckb.aff:IGNORE ًٌٍَُِّْـٰ١٢٣٤۴٥۵٦۶٧٨٩٠
dictionaries/hu_HU/hu_HU.aff:IGNORE ()]

Bug#1023558: dictionaries-common: installation fails with emacs23

[Agustin Martin]

El dom, 6 nov 2022 a las 18:12, Tatsuya Kinoshita () escribió:
>
> Package: dictionaries-common
> Version: 1.28.18
> Severity: wishlist
> Tags: patch
>
> Please skip byte-compilation when emacs23.
>
> This bug is "wishlist", because current official GNU Emacs flavor
> is only "emacs".  However, I personally use unofficial flavors,
> "emacs-snapshot", "emacs28", "emacs24", "emacs23", and so on.
>
> Installing dictionaries-common with "emacs23" fails with this bug
> because of Emacs incompatibility.

Hi,

No problem to change that., but I am curious What errors are you
getting? Depending on the underlying problem I may even skip
byte-compilation for all emacs2* flavors.

Regards,

-- 
Agustin

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El mar, 25 oct 2022 a las 20:43, Soren Stoutner () escribió:
>
> While we wait for answers as to whether these dictionaries can be used by the
> Chromium package and how they might possibly be integrated with upstream
> Hunspell, I would recommend that we move forward with packaging them in /usr/
> share/hunspell-bdic.  This location provides flexibility for whatever ends up
> happening with upstream Hunspell and Chromium.
>
> The question at this point is if they should be generated at package creation
> or if they should be generated during install.  It appears that the majority
> leans towards generating them at package creation.  Is there anyone who feels
> strongly the other way?

Hi all,

I am not particularly happy about this (see details below), but seems
we will have to package all these .bdic files because qtwebengine and
chromium use them. Since some .bdic may fail to build I would rather
prefer them to be generated during package creation, where it is
easier not to create them if required. If done during package install
I think everything should be handled from qtwebengine package. In this
case some fine tuning can be done to improve efficiency (handling
symlinks better, regenerate only when a new version of dict package is
installed or incompatibilities in qtwebengine hunspell appear, ...)

Why I am not that happy about these .bdic files? Looking at
https://chromium.googlesource.com/chromium/deps/hunspell_dictionaries/+/refs/heads/main/README.chromium
and 
https://sites.google.com/a/chromium.org/dev/developers/how-tos/editing-the-spell-checking-dictionaries
the only reasons for this seem to be support for delta files, where
"The .dic_delta files are used to add words which are not there in the
.dic files" and having everything UTF-8. Correct me if I am wrong.

Packaging all possible hunspell dicts in .bdic format will in practice
not be useful to support delta files as originally intended, since
original hunspell dict will be used. Debian maintainer could use a
delta file for Debian changes in poorly maintained dicts, but I think
that in this case they should better patch original .dic file to make
the fix available to all hunspell users.

Another thing I do not like is to have three copies of hunspell flying
around, original hunspell lib and those embedded in chromium and
qtwebengine. This makes harder to keep everything synced.

I agree that that the best would to extend hunspell, but to support
.dic_delta files instead of changing it to use bdic format. Part of
the code may even be reusable to support something like aspell .multi
files.

Regards,

-- 
Agustin





https://github.com/sheremetyev/hunspell
>
> --
> Soren Stoutner
> so...@stoutner.com

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El jue, 22 sept 2022 a las 21:30, Soren Stoutner
() escribió:
>
> On Thursday, September 22, 2022 9:20:46 AM MST Agustin Martin wrote:
>
> > First of all, I am curious about the reasons behind this new format,
> > the problems it deals with and its advantages. I assume they are valid
> > enough, but they imply yet another spellchecking engine/format. We
> > currently have goog old ispell, aspell and hunspell. vim has its own
> > spellchecker engine using its own format, with dicts that can be
> > created from old myspell2 dicts. We did not add vim format dicts (from
> > aspell dicts sources) since there seems to be some work to make vim
> > use hunspell directly. And now these bdict dicts.
>
> The .bdic format is specified by the upstream Chromium project, and is 
> required by anything that is based off of Chromium's code, like Qt WebEngine. 
>  I do not know why they went with a proprietary binary format, but I would 
> assume that if they went to so much trouble to not use the standard Hunspell 
> format there must have been something to make it worthwhile, like some 
> performance improvement.  Perhaps I am giving Google too much credit for 
> having logical reasons instead of making arbitrary decisions.

Hi, Soren

It s a pity not to have more info about the reasons for this new
format. Even if using it is more effficient in terms of plain
performance, I do not think that is noticeable in stuff like chromium.

Another question is whether that bdic format is expected to change or
that is very unlikely.

Thinking about this, I have done some tests about these bdic files
being generated at postinst, like emacs byte-compiled files (although
my tests were  more rude), delegating everything to the qtwebengine
packages. . bdic generation is not very slow, but IMHO is not fast
enough to go this way (which woud require moving
qwebengine_convert_dic to Qt WebEngine runtime package and control
everything from it).

One noticeable thing is that bdic generation  failed for some hunspell
dicts I have installed

++ processing an_ES.aff
[1003/125813.760330:FATAL:aff_reader.cc(305)] Did not find a space in 'yi'.
Trace/breakpoint trap
++ processing ar.aff
[1003/125813.796753:FATAL:aff_reader.cc(123)] We don't support the
IGNORE command yet. This would change how we would insert things in
our lookup table.
++ processing gl_ES.aff
gl_ES.dic_delta not found.
Reading gl_ES.aff
Reading gl_ES.dic
Serializing...
Verifying...
Word does not match!
  Index:2126
  Expected: Abū po:antropónimo
is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_aṣ_Ṣabiʾ_al_Battānī
  Actual:   Abū po:antropónimo
is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_aṣ_Ṣabiʾ_al_Battā
ERROR converting, the dictionary does not check out OK.

Regards,

-- 
Agustin

Bug#1020829: aspell: html mode less than in script block causes misspellings to be missed

[Agustin Martin]

Control: forwarded -1 https://github.com/GNUAspell/aspell/issues/626

El mar, 27 sept 2022 a las 10:42, Andrew Courser () escribió:
>
> Package: aspell
> Version: 0.60.8-3
>
> HTML mode appears to be confused by less than symbols in script elements.

Hi, Andrew

Thanks for the info.

Forwarded upstream (https://github.com/GNUAspell/aspell/issues/626)

Regards,

-- 
Agustin

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Agustin Martin]

El mar, 20 sept 2022 a las 22:33, Soren Stoutner
() escribió:
>
> Package: dictionaries-common
> Version: 1.28.18
> Severity: wishlist
> Tags: l10n
>
> Qt WebEngine has the ability to use Hunspell dictionaries for spell checking 
> with the WebEngine, but for some reason they require that the dictionary 
> files be converted to a special binary format (.bdic).  This conversion can 
> be done using qwebengine_convert_dict from the qtwebengine5-dev-tools 
> package.  The upstream documentation regarding this is found on Qt's website:
>
> https://doc.qt.io/qt-5/qtwebengine-features.html#spellchecker
>
> Once these libraries are available they can be used by any program that 
> includes Qt WebEngine.
>
> The purpose of this bug report is to create a central location for discussion 
> about the best way to package these dictionaries.

Hi, Soren.

Sorry for the delay. For some reason your messages went to the spambox
and I am becoming aware of them just now (as well as about all this
issue). Here goes a quick reply.

First of all, I am curious about the reasons behind this new format,
the problems it deals with and its advantages. I assume they are valid
enough, but they imply yet another spellchecking engine/format. We
currently have goog old ispell, aspell and hunspell. vim has its own
spellchecker engine using its own format, with dicts that can be
created from old myspell2 dicts. We did not add vim format dicts (from
aspell dicts sources) since there seems to be some work to make vim
use hunspell directly. And now these bdict dicts.

Some other questions here,

>From your info and proposed locations seems that these dicts are
arch:all, ¿is that true?

Another question is what happens with affix files, which I see are
used at build time, ¿are they used (from their path) at runtime or is
all the info (dic+aff) bundled into the bdic file? If explicit affix
files are still required at runtime, both bdic and aff files should
probably be in the same dir. Otherwise I am more for a separate
location. In this case, since bdic dicts seem to be more generic than
just a qtwebengine issue and they are indeed created from hunspell
files I would go for a rather generic name (may be something like
/usr/share/hunspell-bdic or something without the hunspell name?)

Regarding the binary package that should contain them, I tested with
en_US files and bdic file is smaller that .dic file, but not very
much, so size seems not the main reason to go one way or another. Do
not know for other languages. While it is easier to handle
dependencies with separate packages, I admit  I do not have a strong
opinion here,

Regards,

--
Agustin

Bug#1017885: dictionaries-common: debian-ispell.el triggers warnings in Emacs

[Agustin Martin]

El mié, 24 ago 2022 a las 21:45, Vincent Lefevre
() escribió:

Hi, Vincent,

> It seems that Emacs caches results, so that once the cache is built,
> Emacs doesn't attempt to rebuild anything... until the cache gets
> obsolete or is removed:
>
>   rm -r .emacs.d/eln-cache
>
> Now I've seen earlier today that this was not working at all in
> firejail with some restrictive profiles because gcc could not be run.
> If I understand correctly, Emacs now wants to compile the .el files:
>
>   https://www.emacswiki.org/emacs/GccEmacs

Thanks, I was not aware of this change. I track the emacs mailing
list, but mostly for spellchecking related issues and did not notice
this change.

> > First two warnings should never happen, ‘really-hunspell’ is a local
> > variable inside a let statement, Other expect the variable or function
> > from outside the file. I could improve the use of
> > ‘ispell-base-dicts-override-alist’, but seems not a problem here.
>
> So this would be a bug in Emacs itself?

This seems caused by a typo in my definition, not a bug in Emacs. The
underlying reason for these warnings is that we use to  supress
warnings in normal byte-compilation, but this does not happen in this
async byte-compilalation.

I expect an upload with this problem fixed soon.

Thanks again for your info.

Regards,

-- 
Agustin

Bug#1017885: dictionaries-common: debian-ispell.el triggers warnings in Emacs

[Agustin Martin]

El lun, 22 ago 2022 a las 3:06, Vincent Lefevre () escribió:
>
> Package: dictionaries-common
> Version: 1.28.16
> Severity: important
>
> When running Emacs, its window is sometimes split to show warnings
> in the bottom part (this occurred twice in a few days, after the
> upgrade to Emacs 28.1):

Hi, Vincent, thanks for the info.

I am a bit confused by this problem and tend to think that is a side
effect of a problem somewhere else. First time I tried to reproduce
this problem I succedded, but all further atempts failed and no
warnings are shown at all. Not sure if the only time I could reproduce
the problem happened before fixing a problem with emacs-common
installation.
>
> Warning (comp): debian-ispell.el:229:17: Warning: assignment to free variable 
> ‘really-hunspell’ Disable showing Disable logging
> Warning (comp): debian-ispell.el:228:28: Warning: reference to free variable 
> ‘really-hunspell’ Disable showing Disable logging
> Warning (comp): debian-ispell.el:392:16: Warning: reference to free variable 
> ‘ispell-local-dictionary’ Disable showing Disable logging
> Warning (comp): debian-ispell.el:403:24: Warning: assignment to free variable 
> ‘ispell-base-dicts-override-alist’ Disable showing Disable logging
> Warning (comp): debian-ispell.el:403:20: Warning: reference to free variable 
> ‘ispell-base-dicts-override-alist’ Disable showing Disable logging
> Warning (comp): debian-ispell.el:489:15: Warning: the function 
> ‘ispell-set-spellchecker-params’ is not known to be defined. Disable showing 
> Disable logging

First two warnings should never happen, ‘really-hunspell’ is a local
variable inside a let statement, Other expect the variable or function
from outside the file. I could improve the use of
‘ispell-base-dicts-override-alist’, but seems not a problem here.

Can you please check that emacs (and emacs-common) versions are
1:28.1+1-2? Is this problem still happening?

In the meantime I will keep trying to reproduce  the problem.

Regards,

-- 
Agustin

Bug#1016731: dictionaries-common: Badly generated /var/cache/dictionaries-common/emacsen-ispell-dicts.el for Hebrew

[Agustin Martin]

El sáb, 6 ago 2022 a las 14:09, Itaï BEN YAACOV () escribió:
>
> Package: dictionaries-common
> Version: 1.28.15
> Severity: normal
>
> Dear Maintainer,
>
> With hunspell-he installed, starting emacs I get the following error message :
>
> Loading /var/cache/dictionaries-common/emacsen-ispell-dicts.el (source)...
> Error while loading 50dictionaries-common: Invalid read syntax: "] in a list"
>
> Without that package, no problem.
> The origin seems to be in the file 
> /var/cache/dictionaries-common/emacsen-ispell-dicts.el , that contains the 
> following lines :
>
> (add-to-list 'debian-hunspell-only-dictionary-alist
>   '("hebrew"
>  
> "[a-zA-Z\327\231\327\225\327\224\327\220\327\242\327\227\327\233\327\247\327\251\327\241\327\226\327\223\327\222\327\221\327\250\327\240\327\236\327\230\327\246\327\252\327\244\327\235\327\243\327\232\327\245\327\237\327\234]"
>  
> "[^a-zA-Z\327\231\327\225\327\224\327\220\327\242\327\227\327\233\327\247\327\251\327\241\327\226\327\223\327\222\327\221\327\250\327\240\327\236\327\230\327\246\327\252\327\244\327\235\327\243\327\232\327\245\327\237\327\234]"
>  "[אבגדהוזחטיכלמנסעפצקרשתםןךףץ'"]"
>  nil
>  ("-d" "he_IL")
>  nil
>  utf-8))
>
> You will notice the unescaped " in the fifth line, followed indeed by the  
> character ] ...
> Since the file is generated by perl (if I understand correctly, it is 
> generated by /usr/share/perl5/Debian/DictionariesCommon.pm), this is where I 
> stopped digging.
>
> Can that perl script be repaired so as to escape double quotes when 
> appropriate ?

Hi, thanks for the info.

It should not be hard to fix once I find some time for that. Will let you know.

Regards,

..
Agustin

Bug#655113: openoffice.org-dictionaries: Please make use of existing Debian infrastructure to make these appear under emacs, jed and mutt

[Agustin Martin]

Control: reassign -1 dictionaries-common,libreoffice-dictionaries

El dom, 19 dic 2021 a las 22:05, Agustin Martin
() escribió:
>
> If you consider that this is working well enough, I think this bug
> report can be closed.

Since there were no objections, I am reassigning this bug report to
both dictionaries-common and libreoffice-dictionaries and will mark it
as closed by dictionaries-common/1.28.14,

--
Agustin

Bug#1008653: backintime-qt broken in sid after python upgrade

[Agustin Martin]

El jue, 21 abr 2022 a las 23:47, Agustin Martin
() escribió:
> If a new upstream version contains many changes that maintainer wants
> to inspect closely, it is trivial to just include upstream fix for
> this issue. I am attaching a patch (with unclosed changelog formatted
> for NMU, modify as appropriate) that should deal with this problem,
> just adapting upstream commit to Debian patch system.

Really attaching patch, sorry for the noise.

--
Agustin
diff --git a/debian/changelog b/debian/changelog
index faed735..0e926fc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+backintime (1.2.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * 01_tools.py_fix-1008653.patch: Get upstream changes to fix "tests no
+longer work with Python 3.10" (Closes: #1008653).
+
+ --
+
 backintime (1.2.1-3) unstable; urgency=medium
 
   * Cherry-pick patch for #946349 from upstream Git repository
diff --git a/debian/patches/01_tools.py_fix-1008653.patch b/debian/patches/01_tools.py_fix-1008653.patch
new file mode 100644
index 000..0ffcbe2
--- /dev/null
+++ b/debian/patches/01_tools.py_fix-1008653.patch
@@ -0,0 +1,28 @@
+From e1ae23ddc0b4229053e3e9c6c61adcb7f3d8e9b3 Mon Sep 17 00:00:00 2001
+From: Germar Reitze 
+Date: Mon, 5 Jul 2021 19:11:58 +0200
+Subject: [PATCH] Tests no longer work with Python 3.10 (fixes: #1175)
+
+--- a/common/tools.py
 b/common/tools.py
+@@ -25,7 +25,10 @@
+ import errno
+ import gzip
+ import tempfile
+-import collections
++try:
++from collections.abc import MutableSet
++except ImportError:
++from collections import MutableSet
+ import hashlib
+ import ipaddress
+ import atexit
+@@ -1802,7 +1805,7 @@ def reset(self, path):
+ self.history = [path,]
+ self.index = 0
+ 
+-class OrderedSet(collections.MutableSet):
++class OrderedSet(MutableSet):
+ """
+ OrderedSet from Python recipe
+ http://code.activestate.com/recipes/576694/
diff --git a/debian/patches/series b/debian/patches/series
index 78aacb2..c486f48 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 00-fix-946349.patch
+01_tools.py_fix-1008653.patch

Bug#1008653: backintime-qt broken in sid after python upgrade

[Agustin Martin]

Control: tags -1 + patch fixed-upstream

On Wed, Apr 20, 2022 at 09:45:26AM +0200, Leonardo Canducci wrote:
> Package: backintime-qt
> Followup-For: Bug #1008653
>
> I've installed backintime-qt from github (it's pretty straightforward,
> just donwload the source and build two deb files with the provided
> makedeb.sh) and it works fine.
>
> Please update this package. I'm by no means a developer but it seems
> like a trivial fix.

Hi,

If a new upstream version contains many changes that maintainer wants
to inspect closely, it is trivial to just include upstream fix for
this issue. I am attaching a patch (with unclosed changelog formatted
for NMU, modify as appropriate) that should deal with this problem,
just adapting upstream commit to Debian patch system.

Regards,

-- 
Agustin

Bug#1008253: mmm-mode.emacsen-remove: Do not remove cl-lib.el when removing xemacs symlinks.

[Agustin Martin]

Package: mmm-mode
Version: 0.5.8-2
Severity: important
Tags: +patch

Dear Maintainer,

Code added to fix #985874 by removing symlinks under
/usr/share/xemacs21/site-lisp also removes shipped cl-lib.el.

This causes cl-lib to be removed if xemacs21-mule is updated and makes
byte compilation fail under xemacs. Other mmm-mode stuff byte
compilation also fail under xemacs.

# apt install --reinstall xemacs21-mule
...
Remove mmm-mode for xemacs21
install/mmm-mode: Handling removal of emacsen flavor xemacs21
install/mmm-mode: purging byte-compiled files for xemacs21
...
Install mmm-mode for xemacs21
install/mmm-mode: Handling install of emacsen flavor xemacs21
install/mmm-mode: byte-compiling for xemacs21
Compiling /usr/share/xemacs21/site-lisp/mmm-mode/cl-lib.el...
>>Error occurred processing cl-lib.el: Opening input file: No such file or 
>>directory, /usr/share/xemacs21/site-lisp
/mmm-mode/cl-lib.el
...
and failures for other mmm-stuff

Removal should be more selective, please consider attached patch,
whicn only removes mmm- prefixed stuff.

Regards,

-- 
Agustin
From 41dcab0f875b40b6c4bfd14d94c010bc9e6a3dd0 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 25 Mar 2022 12:14:06 +0100
Subject: [PATCH] mmm-mode.emacsen-remove: Do not remove cl-lib.el when
 removing xemacs symlinks.

Signed-off-by: Agustin Martin Domingo 
---
 debian/mmm-mode.emacsen-remove | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/mmm-mode.emacsen-remove b/debian/mmm-mode.emacsen-remove
index 6dac131..4f1b32a 100644
--- a/debian/mmm-mode.emacsen-remove
+++ b/debian/mmm-mode.emacsen-remove
@@ -9,7 +9,7 @@ rm -rf /usr/share/${FLAVOR}/site-lisp/mmm-mode/*.elc
 
 # xemacs has symlinks for the source files, which need to go
 if [ "$FLAVOR" != "emacs" ]; then
-rm -rf /usr/share/${FLAVOR}/site-lisp/mmm-mode/
+rm -f /usr/share/${FLAVOR}/site-lisp/mmm-mode/mmm-*.el
 fi
 
 exit 0;
-- 
2.35.1

Bug#1006132: ifrench-gut: please stop build-depending on myspell-tools

[Agustin Martin]

El dom, 27 feb 2022 a las 22:32, Agustin Martin
() escribió:
>
> Control: tags -1 +patch
>
> El vie, 25 feb 2022 a las 8:51, Lionel Élie Mamane
> () escribió:
> >
> > On Fri, Feb 25, 2022 at 12:51:32AM +0100, Agustin Martin wrote:
> > > El jue, 24 feb 2022 a las 16:09, Lionel Élie Mamane
> > > () escribió:
> >
> > > I have been looking at popcons and seems that regarding ispell dicts
> > > ifrench-gut is way more popular than ifrench, but on the hunspell side
> > > the winner is hunspell-fr (which pulls hunspell-fr-classical)
> >
> > > I do not know about the merits of the different ispell dicts, but
> > > keeping ifrench-gut ispell dict  seems reasonable. On the other hand,
> > > unless it provides something better, dropping myspell-fr-gut as a real
> > > dict seems also reasonable, but this really requires more feedback
> > > from french users.
> >
> > If the -gut variant has a "better" word list, then I expect it is
> > better for both ispell and myspell?
>
> Hi, Lionel,
>
> myspell is gone, only hunspell is available and supports old myspell
> dictionaries like this one.  Usually hunspell specific dicts are
> better than old myspell and ispell dicts, but sometimes they are just
> different and each one has its merits. Note that hunspell-fr-*dicts
> come from different source (https://grammalecte.net/home.php?prj=fr)
> than both ispell french dicts.
>
> If you think is useful to keep a myspell/hunspell version of gutenberg
> dict I am attaching a patch with a possible migration to
> ispellaff2myspell. In my limited tests it works better than old dict
> since it includes ' and - as wordchars. Whether to remove it or not in
> favour of hunspell-fr-* is something that can be decided later by
> french dicts maintainers (and will require some coordination). I have
> also noticed that while package contains a couple of patches with
> dpatch extension it does nor really use dpatch, so that would not be a
> problem, The mismatch in ispell hash format should be fixed by the new
> build (although I suggest to migrate to ispell-autobuildhash), so this
> patch should be enough if no side effects are found,

Hi, Lionel

Forgot to mention, but if you agree with the changes but are too busy
to prepare an upload I can prepare a NMU.

Regards,

-- 
Agustin

Bug#1006132: ifrench-gut: please stop build-depending on myspell-tools

[Agustin Martin]

Control: tags -1 +patch

El vie, 25 feb 2022 a las 8:51, Lionel Élie Mamane
() escribió:
>
> On Fri, Feb 25, 2022 at 12:51:32AM +0100, Agustin Martin wrote:
> > El jue, 24 feb 2022 a las 16:09, Lionel Élie Mamane
> > () escribió:
>
> > I have been looking at popcons and seems that regarding ispell dicts
> > ifrench-gut is way more popular than ifrench, but on the hunspell side
> > the winner is hunspell-fr (which pulls hunspell-fr-classical)
>
> > I do not know about the merits of the different ispell dicts, but
> > keeping ifrench-gut ispell dict  seems reasonable. On the other hand,
> > unless it provides something better, dropping myspell-fr-gut as a real
> > dict seems also reasonable, but this really requires more feedback
> > from french users.
>
> If the -gut variant has a "better" word list, then I expect it is
> better for both ispell and myspell?

Hi, Lionel,

myspell is gone, only hunspell is available and supports old myspell
dictionaries like this one.  Usually hunspell specific dicts are
better than old myspell and ispell dicts, but sometimes they are just
different and each one has its merits. Note that hunspell-fr-*dicts
come from different source (https://grammalecte.net/home.php?prj=fr)
than both ispell french dicts.

If you think is useful to keep a myspell/hunspell version of gutenberg
dict I am attaching a patch with a possible migration to
ispellaff2myspell. In my limited tests it works better than old dict
since it includes ' and - as wordchars. Whether to remove it or not in
favour of hunspell-fr-* is something that can be decided later by
french dicts maintainers (and will require some coordination). I have
also noticed that while package contains a couple of patches with
dpatch extension it does nor really use dpatch, so that would not be a
problem, The mismatch in ispell hash format should be fixed by the new
build (although I suggest to migrate to ispell-autobuildhash), so this
patch should be enough if no side effects are found,

I would also suggest some cleanup of ancient stuff and other
improvements, but what needs quick action is the myspell-tools
build-dep, which I think should be addressed by attached patch.

Regards,

-- 
Agustin
diff -u ifrench-gut-1.0/debian/changelog ifrench-gut-1.0/debian/changelog
diff -u ifrench-gut-1.0/debian/control ifrench-gut-1.0/debian/control
--- ifrench-gut-1.0/debian/control
+++ ifrench-gut-1.0/debian/control
@@ -3,7 +3,7 @@
 Section: text
 Priority: optional
 Standards-Version: 3.9.8
-Build-Depends: debhelper (>> 10), ispell (>= 3.3.02), dictionaries-common-dev (>= 1.10.5), myspell-tools
+Build-Depends: debhelper (>> 10), ispell (>= 3.3.02), dictionaries-common-dev (>= 1.10.5), hunspell-tools
 #Homepage: http://www.gutenberg.eu.org/distributions/rubrique9.html
 
 Package: ifrench-gut
diff -u ifrench-gut-1.0/debian/rules ifrench-gut-1.0/debian/rules
--- ifrench-gut-1.0/debian/rules
+++ ifrench-gut-1.0/debian/rules
@@ -25,10 +25,10 @@
 
 	# Add here commands to compile the package.
 	./makehash
-	is2my-spell.pl francais.aff > fr-pre.aff
-	LC_ALL=C sed	-e 's/^SET.*/SET ISO8859-15/;s/^TRY.*/TRY aeioàéèêîâsinrtlcdugmphbyfvkwôûëöïù½/' \
-			-e 's/^\([PS]FX[[:space:]]\+.[[:space:]]\+[^[:space:]]\+[[:space:]]\+[^[:space:]]\+[[:space:]]\+\)\([^[:space:]]\+\)$$/\1\2/' \
-			fr-pre.aff > fr.aff
+	ispellaff2myspell \
+		--charset=latin0 \
+		--myheader=debian/fr_FR@GUT.header \
+		francais.aff > fr.aff
 	wc -l < francais.dico > francais.dico.cnt
 	cat francais.dico.cnt francais.dico > fr.dic
 
only in patch2:
unchanged:
--- ifrench-gut-1.0.orig/debian/fr_FR@GUT.header
+++ ifrench-gut-1.0/debian/fr_FR@GUT.header
@@ -0,0 +1,19 @@
+# -*- coding: iso-8859-15 -*-
+# 
+# Converted from ifrench-gut francais.aff affix file by
+# ispellaff2myspell
+#
+# From ifrench-gut francais.aff affix file:
+#
+# Francais-GUTenberg v1.0
+# Fichier d'affixes pour le français
+# Copyright 1999, Christophe Pythoud et GUTenberg
+# -
+
+SET ISO8859-15
+
+TRY aeioàéèêîâsinrtlcdugmphbyfvkwôûëöïù½
+
+WORDCHARS -'
+
+# -

Bug#1006132: ifrench-gut: please stop build-depending on myspell-tools

[Agustin Martin]

El jue, 24 feb 2022 a las 16:09, Lionel Élie Mamane
() escribió:
>
> On Thu, Feb 24, 2022 at 01:51:58PM +0100, Agustin Martin wrote:
> > On Sat, Feb 19, 2022 at 05:39:28PM +0100, Mattia Rizzolo wrote:
>
> >> Source: ifrench-gut
>
> > * ispell dictionary hash seems to be in bad format,
> >   $ ispell -l -d francais /usr/share/doc/ifrench-gut/ALIRE
> >   Illegal format hash table /usr/lib/ispell/francais.hash - expected
> > magic2 0x9602, got 0x554f
>
> > I have also checked the gutenberg association home page and could
> > not find references to this dict, and upstream location in watch
> > file seems to no longer work. I wonder if this dict is it considered
> > obsolete.
>
> Back in 2002, I had to track down the author by phone (his previous
> employer gave me his contact info at his then-current employer), and I
> don't remember much came out of it. There was a mailing list, but I
> also don't have traces of much coming out of it. I see a single post
> from 2005 about using the dictionary.

Hi, Lionel, happy to read you

I have been looking at popcons and seems that regarding ispell dicts
ifrench-gut is way more popular than ifrench, but on the hunspell side
the winner is hunspell-fr (which pulls hunspell-fr-classical)

ifrench 168
myspell-fr 775

ifrench-gut 21419
myspell-fr-gut 375

hunspell-fr 11618
hunspell-fr-classical 11565

I do not know about the merits of the different ispell dicts, but
keeping ifrench-gut ispell dict  seems reasonable. On the other hand,
unless it provides something better, dropping myspell-fr-gut as a real
dict seems also reasonable, but this really requires more feedback
from french users.

Regards,

-- 
Agustin

Bug#1006132: ifrench-gut: please stop build-depending on myspell-tools

[Agustin Martin]

On Sat, Feb 19, 2022 at 05:39:28PM +0100, Mattia Rizzolo wrote:
> Source: ifrench-gut
> Version: 1:1.0-32.1
> Severity: serious
>
> Dear maintainer,
>
> we plan to remove src:myspell really soon, and together with it also
> the package "myspell-tools".
> Your package still depends on it.
>
> Please see whether you can move whatever the package is doing to
> hunspell-tools, or otherwise please tell us src:hunspell maintainers how
> that is not possible for you.
>
> Thank you for maintaining ifrench-gut.

Hi, Lionel and Mattia

If required I can try to migrate this package to use
ispellaff2myspell, but I see some other problems with it,

* Uses dpatch
* No debian/source/format defined (indeed is old 1.0)
* ispell dictionary hash seems to be in bad format,
  $ ispell -l -d francais /usr/share/doc/ifrench-gut/ALIRE
  Illegal format hash table /usr/lib/ispell/francais.hash - expected
magic2 0x9602, got 0x554f

I also wonder how relevant is myspell-fr-gut compared to
hunspell-fr-classical, hunspell-fr-comprehensive and
hunspell-fr-revised. If it is no longer needed it could be made a
transitional package to hunspell-fr making this particular problem
disappear (although not others).

I have also checked the gutenberg association home page and could not
find references to this dict, and upstream location in watch file
seems to no longer work. I wonder if this dict is it considered
obsolete.

Regards,

-- 
Agustin

Bug#1006131: rus-ispell: please stop build-depending on myspell-tools

[Agustin Martin]

Control: tags -1 +pending

El mar, 22 feb 2022 a las 8:05, Mikhail Gusarov
() escribió:
>
> Hello Agustin,
>
> On 21 Feb 2022, at 23:46, Agustin Martin wrote:
>
> >> Could you show me the difference?
>
> > Find attached diff. SInce flags are sorted differently by i2myspell
> > and ispellaff2myspell , I made some magic for easier check of result,
> > actually diffing sorted affix files. This is what leads to that file
>
> Thanks. Looks fine for me.
> Actually, new file has the Cyrillic letters sorted in the right order :)

Thanks a lot,

-- 
Agustin

Bug#1006131: rus-ispell: please stop build-depending on myspell-tools

[Agustin Martin]

El lun, 21 feb 2022 a las 23:26, Mikhail Gusarov
() escribió:
>
> Hello Agustin,
>
> On 21 Feb 2022, at 23:12, Agustin Martin wrote:
>
> I am thinking about using ispellaff2myspell --bylocale flag with
> russian koi8-r locale set. This should only require an extra¡
> build-dep on locales-all and change myspell-tools to hunspell-tools. I
> am checking the result and only have noticed some sorting differences
> in characters inside regexp groups, nothing that should be a problem.
>
> Could you show me the difference?

Hi, Mikhail, thanks for your help.

Find attached diff. SInce flags are sorted differently by i2myspell
and ispellaff2myspell , I made some magic for easier check of result,
actually diffing sorted affix files. This is what leads to that file

LC_ALL=ru_RU.KOI8-R sort /usr/lib/aspell/ru_affix.dat > ru_fromaspell.sorted
LC_ALL=ru_RU.KOI8-R ispellaff2myspell --bylocale
/usr/lib/ispell/russian.aff > ru_fromispell
LC_ALL=ru_RU.KOI8-R sort ru_fromispell > ru_fromispell.sorted
diff -uw ru_fromaspell.sorted ru_fromispell.sorted > aspell_vs_ispell.diff

/usr/lib/aspell/ru_affix.dat is original affix file created by
i2myspell (and shipped by aspell-ru).

Regards,

-- 
Agustin
--- ru_fromaspell.sorted	2022-02-21 23:32:23.980184050 +0100
+++ ru_fromispell.sorted	2022-02-21 23:32:24.020184326 +0100
@@ -23,7 +23,6 @@
 
 
 
-SET KOI8-R
 SFX A   0ав
 SFX A   0аин
 SFX A   0ов
@@ -48,20 +47,20 @@
 SFX A   еми   [иы]е
 SFX A   ем[иы]е
 SFX A   ех[иы]е
-SFX A   ий   ая   [гхк]ий
+SFX A   ийая  [гкх]ий
 SFX A   ий   ая   [жшщч]ий
-SFX A   ий   его  [енржшщч]ий
-SFX A   ий   ее   [енжшщч]ий
-SFX A   ий   ей   [енжшщч]ий
-SFX A   ий   ем   [енржшщч]ий
-SFX A   ий   ему  [енржшщч]ий
-SFX A   ий   ею   [енжшщч]ий
-SFX A   ий   ого  [гхк]ий
-SFX A   ий   ое   [гхк]ий
-SFX A   ий   ой   [гхк]ий
-SFX A   ий   ом   [гхк]ий
-SFX A   ий   ому  [гхк]ий
-SFX A   ий   ою   [гхк]ий
+SFX A   ийего [ежнршщч]ий
+SFX A   ийее  [ежншщч]ий
+SFX A   ийей  [ежншщч]ий
+SFX A   ийем  [ежнршщч]ий
+SFX A   ийему [ежнршщч]ий
+SFX A   ийею  [ежншщч]ий
+SFX A   ийого [гкх]ий
+SFX A   ийое  [гкх]ий
+SFX A   ийой  [гкх]ий
+SFX A   ийом  [гкх]ий
+SFX A   ийому [гкх]ий
+SFX A   ийою  [гкх]ий
 SFX A   ийся аяся [шщ]ийся
 SFX A   ийся егося[шщ]ийся
 SFX A   ийся ееся [шщ]ийся
@@ -74,37 +73,37 @@
 SFX A   ийся имся [шщ]ийся
 SFX A   ийся ихся [шщ]ийся
 SFX A   ийся уюся [шщ]ийся
-SFX A   ий   ую   [гхк]ий
+SFX A   ийую  [гкх]ий
 SFX A   ий   ую   [жшщч]ий
 SFX A   ий   юю   [ен]ий
 SFX A   ий   яя   [ен]ий
-SFX A   йе[гхк]ий
-SFX A   йе[енржшщч]ий
+SFX A   й е   [гкх]ий
+SFX A   й е   [ежнршщч]ий
 SFX A   йеый
-SFX A   йм[гхк]ий
-SFX A   йм[енржшщч]ий
-SFX A   йми   [гхк]ий
-SFX A   йми   [енржшщч]ий
+SFX A   й м   [гкх]ий
+SFX A   й м   [ежнршщч]ий
+SFX A   й ми  [гкх]ий
+SFX A   й ми  [ежнршщч]ий
 SFX A   йми   ый
 SFX A   ймый
-SFX A   йх[гхк]ий
-SFX A   йх[енржшщч]ий
+SFX A   й х   [гкх]ий
+SFX A   й х   [ежнршщч]ий
 SFX A   йхый
 SFX A   йюой
 SFX A   ой   ая   ой
-SFX A   ой   ие   [гхкжшщч]ой
-SFX A   ой   им   [гхкжшщч]ой
-SFX A   ой   ими  [гхкжшщч]ой
-SFX A   ой   их   [гхкжшщч]ой
+SFX A   ойие  [гжкхшщч]ой
+SFX A   ойим  [гжкхшщч]ой
+SFX A   ойими [гжкхшщч]ой
+SFX A   ойих  [гжкхшщч]ой
 SFX A   ой   ого  ой
 SFX A   ой   ое   ой
 SFX A   ой   ом   ой
 SFX A   ой   ому  ой
 SFX A   ой   ую   ой
-SFX A   ой   ые   [^гхкжшщч]ой
-SFX A   ой   ым   [^гхкжшщч]ой
-SFX A   ой   ыми  [^гхкжшщч]ой
-SFX A   ой   ых   [^гхкжшщч]ой
+SFX A   ойые  [^гжкхшщч]ой
+SFX A   ойым  [^гжкхшщч]ой
+SFX A   ойыми [^гжкхшщч]ой
+SFX A   ойых  [^гжкхшщч]ой
 SFX A   ый   ая   ый
 SFX A   ый   его  цый
 SFX A   ый   ее   цый
@@ -145,8 +144,8 @@
 SFX B   ыться ойтесь   ыться
 SFX B   ьеить
 SFX D Y 5
-SFX D   иться атся [жшщч]иться
-SFX D   иться ятся [^жшщч]иться
+SFX D   иться атся[жчшщ]иться
+SFX D   иться ятся[^жчшщ]иться
 SFX D   ться ется [ая]ться
 SFX D   ться ются [ая]ться
 SFX D   ься 

Bug#1006131: rus-ispell: please stop build-depending on myspell-tools

[Agustin Martin]

El sáb, 19 feb 2022 a las 17:39, Mattia Rizzolo () escribió:
>
> Source: rus-ispell
> Version: 0.99g5-27
> Severity: serious
>
> Dear maintainer,
>
> we plan to remove src:myspell really soon, and together with it also
> the package "myspell-tools".
> Your package still depends on it.

Hi, thanks for reminding,

I am thinking about using ispellaff2myspell --bylocale flag with
russian koi8-r locale set. This should only require an extra¡
build-dep on locales-all and change myspell-tools to hunspell-tools. I
am checking the result and only have noticed some sorting differences
in characters inside regexp groups, nothing that should be a problem.
Other approach would be to borrow i2myspell, which is unmaintained.

I do not speak russian, but I think this is nearly ready for release,
hope Mikhail does not find problems with this.

Unless problems appear, expect an upload soon.

Regards,

-- 
Agustin

Bug#655113: openoffice.org-dictionaries: Please make use of existing Debian infrastructure to make these appear under emacs, jed and mutt

[Agustin Martin]

El dom, 8 ene 2012 a las 18:00, Christoph Groth () escribió:
>
> Source: openoffice.org-dictionaries
> Severity: normal
>
> Dear Maintainer,
>
> the Debian package dictionaries-common makes installed dictionaries
> automatically known to programs like emacs, jed and mutt.  This is
> described under http://dict-common.alioth.debian.org/.
>
> The dictionary packages made from openoffice.org-dictionaries do not
> seem to provide any information under /var/lib/dictionaries-common/
> thus making them invisible for the users of the aforementioned
> programs (without manual reconfiguration).  For a dictionary package
> which does provide that information see for example myspell-pl.
>
> Could you please provide information for dictionaries-common?

Hi,

Since 1.28.10 dictionaries-common tries to extract useful info from
all hunspell dictionaries and use it if that info is not explicitly
provided. This can only contain info available in aff file, but should
at least help with Emacs (although is available to other programs,
mostly for testing purposes). Last issue was  fixed in 1.28.14,
already in testing.

I think this can be considered a reasonable fix for this problem.
Trying to manually maintain a database containing more accurate values
for all hunspell dicts provided by libreoffice-dictionaries would be a
nightmare.

If you consider that this is working well enough, I think this bug
report can be closed.

Regards,

-- 
Agustin

Bug#999626: [Maxima-discuss] maxima-emacs: fails to install with xemacs21

[Agustin Martin]

El mié, 1 dic 2021 a las 16:53, Camm Maguire
() escribió:
>
> Greetings!  Am uploading a fix for now.  cl-lib for xemacs21 can be
> found in the mmm-mode package.  Other change is that image-map needs to
> be nil if not bound.  Quite a few byte-compilation warnings in both
> flavors, suppressed on install, but maintainers might want to look at
> cleaning these up.

HI, Camm,

Thanks for taking care of this.

Note that for this to work well maxima-emacs must explicitly depend on
mmm-mode package. Dependency on emacs | mmm-mode will make xemacs
compilation fail (no cl-lib found) if Emacs and XEmacs are installed,
but not mmm-mode (possible with current dependencies).

Regards,

-- 
Agustin

Bug#999626: No need to conflict with xemacs21 here

[Agustin Martin]

On Thu, 25 Nov 2021 16:48:50 + Debian FTP Masters
 wrote:
> We believe that the bug you reported is fixed in the latest version of
> maxima, which is due to be installed in the Debian FTP archive.
...
>  maxima (5.45.1-6) unstable; urgency=medium
>  .
>* maxima-emacs conflicts with xemacs21
>* reverse earlier patch attempts
>* Bug fix: "fails to install with xemacs21", thanks to Andreas Beckmann
>  (Closes: #999626).

Hi, Camm,

I think that there is no need to make maxima-emacs conflict with
xemacs21, should just not be compiled for it. It is legitimate to have
xemacs21 installed for whatever reason, but use FSF Emacs for maxima
stuff.

While we are with this, I have noticed that maxima-emacs is not
bytecompiled for FSF Emacs because the emacsen-common files are
ancient and do not match current emacs handling.

Please consider attached patch, it has been minimally tested to make
maxima-emacs bytecompile for emacs but not for xemacs. It leaves the
door open to other flavors different from emacs, although I would not
expecl them  (there seems to be no further xemacs deveñopment)

When bytecompiling for emacs some apparently harmless warnings are shown.

---
Install maxima-emacs for emacs
install/maxima: Handling install for emacsen flavor emacs

In toplevel form:
imaxima.el:583:1:Warning: Unused lexical argument ‘process’
imaxima.el:696:1:Warning: Unused lexical variable ‘text-prop’
imaxima.el:696:1:Warning: Unused lexical variable ‘pos’
imaxima.el:696:1:Warning: Unused lexical variable ‘label’
imaxima.el:696:1:Warning: Unused lexical variable ‘pos2’
imaxima.el:862:1:Warning: Unused lexical variable ‘imaxima-error-3’
imaxima.el:862:1:Warning: Unused lexical variable ‘imaxima-error-2’
imaxima.el:1416:1:Warning: Unused lexical variable ‘err’
imaxima.el:1416:1:Warning: Unused lexical variable ‘err’
imaxima.el:1472:1:Warning: Unused lexical variable ‘err’
imaxima.el:1472:1:Warning: Unused lexical variable ‘err’
Install maxima-emacs for xemacs21
install/maxima: Skipping byte-compilation for xemacs21
---

Regards,

-- 
Agustin
From 18b14e632eb26cd469754a9a41b03f0e6e66832e Mon Sep 17 00:00:00 2001
From: Agustin Martin 
Date: Fri, 26 Nov 2021 16:17:23 +0100
Subject: [PATCH] Fix byte compilation with emacs and disable it for xemacs.

---
 debian/control  |  7 +++
 debian/maxima-emacs.emacsen-install | 30 ++---
 debian/maxima-emacs.emacsen-remove  | 18 +++--
 3 files changed, 38 insertions(+), 17 deletions(-)

diff --git a/debian/control b/debian/control
index dd74c39..eb58671 100644
--- a/debian/control
+++ b/debian/control
@@ -85,15 +85,14 @@ Description: Computer algebra system -- x interface
  quite reliable, and has good garbage collection, and no memory leaks.
  It comes with hundreds of self tests.
  .
- This package contains an X Windows interface using the tcl/tk 
- libraries. 
+ This package contains an X Windows interface using the tcl/tk
+ libraries.
 
 Package: maxima-emacs
 Depends:  maxima (>= ${binary:Version}), emacs-gtk | emacsen, emacsen-common (>= 1.4.14), texlive-base-bin, ${misc:Depends}, texlive-latex-recommended, maxima-doc (>= ${source:Version})
 Recommends: mime-support, postscript-viewer, pdf-viewer
 Architecture: all
 Replaces: maxima (<< ${binary:Version})
-Conflicts: xemacs21, xemacs
 Description: Computer algebra system -- emacs interface
  Maxima is a fully symbolic computation program.  It is full featured
  doing symbolic manipulation of polynomials, matrices, rational
@@ -122,5 +121,5 @@ Description: Computer algebra system -- extra code
  quite reliable, and has good garbage collection, and no memory leaks.
  It comes with hundreds of self tests.
  .
- This package contains a set of contributed routines and add-on 
+ This package contains a set of contributed routines and add-on
  packages.
diff --git a/debian/maxima-emacs.emacsen-install b/debian/maxima-emacs.emacsen-install
index 6bddd2f..04501a3 100644
--- a/debian/maxima-emacs.emacsen-install
+++ b/debian/maxima-emacs.emacsen-install
@@ -8,9 +8,24 @@
 FLAVOR=$1
 PACKAGE=maxima
 
-if [ ${FLAVOR} = emacs ]; then exit 0; fi
-
-echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
+case ${FLAVOR} in
+xemacs*)
+	# xemacs is not supported by current maxima-emacs
+	echo "install/${PACKAGE}: Skipping byte-compilation for ${FLAVOR}"
+exit 0
+;;
+emacs19|emacs20|emacs21|emacs22|emacs-snapshot*)
+# Do not byte-compile anything for above emacsen flavours
+	echo "install/${PACKAGE}: Skipping byte-compilation for ${FLAVOR}"
+exit 0
+	;;
+emacs*)
+	echo install/${PACKAGE}: Handling install for emacsen flavor ${FLAVOR}
+	;;
+*)
+echo install/${PACKAGE}: Ignoring emacsen flavour [${FLAVOR}]
+exit 0
+esac
 
 SITEFLAG="-no-site-file"
 FLAGS="${SITEFLAG} -q -batch -l path.el -f batch-byte-compile"
@@ 

Bug#999732: libreoffice-dictionaries: Please adopt hunspell-an

[Agustin Martin]

Source: libreoffice-dictionaries
Version: 1:7.1.0~rc3-3
Severity: important
X-Debbugs-Cc: dm...@hotmail.com

Dear Maintainer,

Please enable hunspell-an build from libreoffice-dictionaries sources.

This was originally requested by Dimitrij Mijoski in #991966 hunspell-an bug
report, I am copying his reasoning,

  Package: hunspell-an

  The current package shows a Firefox extension as Homepage (and probably
  upstream). This is not a very good upstream. The Aragonese dictionary is
  unmaintained (no updates since 2011) and it has no real upstream. It would
  be best to use https://cgit.freedesktop.org/libreoffice/dictionaries/
  as upstream and
  https://packages.debian.org/source/sid/libreoffice-dictionaries as source
  package.

  Why this should be done? Because there are certain bugs with the
  dictionary and the libreoffice repository is the only place where the bug
  can be fixed. I certanly can not fix it in the Firefox extension [1] or
  the Libreoffice extension [2].

  [1]: 
https://addons.mozilla.org/mk/firefox/addon/corrector-ortografico-aragones/
  [2]: 
https://extensions.libreoffice.org/en/extensions/show/corrector-ortografico-aragones

  The LibreOffice extension, the Firefox extension and  the Libreoffice
  collection all provide exactly the same files, no information will be lost
  with this transition.

I read the bug report too quickly and just changed upstream homepage, but
after reading it more carefully I agree with him.

Thanks,

-- 
Agustin

Bug#995685: dictionaries-common: Failed to upgrade from 1.28.7

[Agustin Martin]

El lun, 4 oct 2021 a las 13:09, Jochen Sprickerhof
() escribió:
>
> Control: tag -1 patch

Hi,

Thanks for your feedback.

Do not know why your mail took this long to reach the BTS. In the
meantime 1.28.11 was uploaded and I think should fix this problem.
Please check.

Regards,

---
Agustin

Bug#991949: xuxen-eu-spell: New upstream version 5.1

[Agustin Martin]

El mié, 11 ago 2021 a las 19:40, Agustin Martin
() escribió:
>
> El vie, 6 ago 2021 a las 16:30, Dimitrij Mijoski () 
> escribió:
> >
> > Source: xuxen-eu-spell
> > Version: 0.5.20151110-5
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > New uptream version is avaliable, see here http://xuxen.eus/eu/deskargatu .
> > Direct link: http://xuxen.eus/static/hunspell/xuxen_5.1_hunspell.zip
>
> Thanks for the info.
>
> I am splitting old myspell2 part, used only to create aspell dict, to
> a new separate xuxen-eu-myspell source package. Since it contains a
> new tarball it will stay some time in the NEW queue until accepted. I
> will then handle this new version of xuxen-eu-spell, to avoid aspell
> dict being missing from sid for some days.

Hi, Dimitrij,

This package has been waiting in the NEW queue for a long time. In the
meantime I changed my mind about how to handle this, it will be done
via a new hunspell-eu source package while old xuxen-eu-spell will
stay, temporarily, as is. I have uploaded this hunspell-eu package
(now is the one waiting in the NEW queue) and asked for rejection of
xuxen-eu-myspell, still unprocessed in the NEW queue.

I hope hunspell-eu will not wait this long in the NEW queue.

Regards,

-- 
Agustin

Bug#655113: openoffice.org-dictionaries: Please make use of existing Debian infrastructure to make these appear under emacs, jed and mutt

[Agustin Martin]

El dom, 8 ene 2012 a las 18:00, Christoph Groth () escribió:
>
> Source: openoffice.org-dictionaries
> Severity: normal
>
> Dear Maintainer,
>
> the Debian package dictionaries-common makes installed dictionaries
> automatically known to programs like emacs, jed and mutt.  This is
> described under http://dict-common.alioth.debian.org/.
>
> The dictionary packages made from openoffice.org-dictionaries do not
> seem to provide any information under /var/lib/dictionaries-common/
> thus making them invisible for the users of the aforementioned
> programs (without manual reconfiguration).  For a dictionary package
> which does provide that information see for example myspell-pl.
>
> Could you please provide information for dictionaries-common?

Hi all,

For the records, I am thinking about dictionaries-common parsing
/usr/share/hunspell and dicts there to extract some minimal
information, useful for above purpose at least for Emacs. If
everything works as expected, this would not require any changes in
libreoffice-dictionaries, everything would be done from
dictionaries-common. Will let you know.

Regards,

-- 
Agustin

Bug#991966: closed by Debian FTP Masters (reply to Agustin Martin Domingo )

[Agustin Martin]

On Mon, 16 Aug 2021 20:08:58 + Dimitrij Mijoski  wrote:
> I think it would be better to merge the source package with this one >  
> https://packages.debian.org/source/sid/libreoffice-dictionaries and remove 
> this source package. 
> 

Hi,

I personally do not object to that, What do you think, Jordi?

Note that this adoption would be done by
libreoffice-dictionaries-package, enabling build of hunspell-an
package from its sources.

Regards,

-- 
Agustin

Bug#991949: xuxen-eu-spell: New upstream version 5.1

[Agustin Martin]

El vie, 6 ago 2021 a las 16:30, Dimitrij Mijoski () escribió:
>
> Source: xuxen-eu-spell
> Version: 0.5.20151110-5
> Severity: normal
>
> Dear Maintainer,
>
> New uptream version is avaliable, see here http://xuxen.eus/eu/deskargatu .
> Direct link: http://xuxen.eus/static/hunspell/xuxen_5.1_hunspell.zip

Thanks for the info.

I am splitting old myspell2 part, used only to create aspell dict, to
a new separate xuxen-eu-myspell source package. Since it contains a
new tarball it will stay some time in the NEW queue until accepted. I
will then handle this new version of xuxen-eu-spell, to avoid aspell
dict being missing from sid for some days.

Regards,

-- 
Agustin

Bug#991550: lvm2: blk-availability.service sometimes causes early filesystem unmounts.

[Agustin Martin]

El mar, 27 jul 2021 a las 11:56, Agustin Martin
() escribió:
...
> In the problematic box I have temporatily added
> "After=blk-availability.service" and seems to work around this problem.
> Seems that is not causing other problems, but will keep my fingers crossed.

Just to clarify that this was added to my custom service. Fortunately
this problem seems to only affect custom services (do not know why)
and not always.

Regards,

-- 
Agustin

Bug#991550: lvm2: blk-availability.service sometimes causes early filesystem unmounts.

[Agustin Martin]

Package: lvm2
Version: 2.03.11-2.1
Severity: normal
Forwarded: https://github.com/lvmteam/lvm2/issues/18

Dear Maintainer,

Sometimes there is a weird behavior causing some filesystems to be unmounted
too early, when they are still needed. I have only found this problem in a
box with lvm on top of RAID, but not in other boxes using lvm. Seems that
this problem is related to lvm2.

>From redhat bug report (https://bugzilla.redhat.com/show_bug.cgi?id=1701234)

  The blk-availability.service unit is activated automatically when
  multipathd is enabled, even if multipathd is finally not used.
  This leads to the blk-availability service to unmount file systems
  too early, breaking unit ordering and leading to shutdown issues of
  custom services requiring some mount points.

This has been reported upstream as https://github.com/lvmteam/lvm2/issues/18
and also to Ubuntu launchpad as 
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1832859

In the problematic box I have temporatily added
"After=blk-availability.service" and seems to work around this problem.
Seems that is not causing other problems, but will keep my fingers crossed.

Regards,

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (200, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.175-2.1
ii  dmsetup   2:1.02.175-2.1
ii  init-system-helpers   1.60
ii  libaio1   0.3.112-9
ii  libblkid1 2.36.1-7
ii  libc6 2.31-13
ii  libdevmapper-event1.02.1  2:1.02.175-2.1
ii  libedit2  3.1-20191231-2+b1
ii  libselinux1   3.1-3
ii  libsystemd0   247.3-6
ii  libudev1  247.3-6
ii  lsb-base  11.1.0

Versions of packages lvm2 recommends:
pn  thin-provisioning-tools  

lvm2 suggests no packages.

-- no debconf information

-- 
Agustin

Bug#991346: unblock: aspell/0.60.8-3

[Agustin Martin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package aspell

This upload deals with CVE-2019-25051, fixing a buffer overflow. This has
been reported in Debian BTS as severity grave #991307, closed by this
upload. Package is already built for all arches.

000-objstack-assert-that-the-alloc-size-will-fit-within-.patch is borrowed
from upstream (attached along with the debdiff for easier inspection).

Pasting from #991307 for further info:

--- 8< --
The following vulnerability was published for aspell.

CVE-2019-25051[0]:
| objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in
| acommon::ObjStack::dup_top (called from acommon::StringMap::add and
| acommon::Config::lookup_list).

https://github.com/google/oss-fuzz-vulns/blob/main/vulns/aspell/OSV-2020-521.yaml
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18462

Patch:
https://github.com/gnuaspell/aspell/commit/0718b375425aad8e54e1150313b862e4c6fd324a

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-25051
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25051

Please adjust the affected versions in the BTS as needed.
--- 8< --

Regards,

unblock aspell/0.60.8-3
diff -Nru aspell-0.60.8/debian/changelog aspell-0.60.8/debian/changelog
--- aspell-0.60.8/debian/changelog	2020-12-28 15:24:45.0 +0100
+++ aspell-0.60.8/debian/changelog	2021-07-20 23:42:34.0 +0200
@@ -1,3 +1,11 @@
+aspell (0.60.8-3) unstable; urgency=medium
+
+  * 000-objstack-assert-that-the-alloc-size-will-fit-within-.patch:
+Fix CVE-2019-25051: objstack in GNU Aspell 0.60.8 has a heap-based
+buffer overflow (Closes: #991307).
+
+ -- Agustin Martin Domingo   Tue, 20 Jul 2021 23:42:34 +0200
+
 aspell (0.60.8-2) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch
--- aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch	1970-01-01 01:00:00.0 +0100
+++ aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch	2021-07-20 23:37:07.0 +0200
@@ -0,0 +1,102 @@
+From 0718b375425aad8e54e1150313b862e4c6fd324a Mon Sep 17 00:00:00 2001
+From: Kevin Atkinson 
+Date: Sat, 21 Dec 2019 20:32:47 +
+Bug-Debian: https://bugs.debian.org/991307
+Subject: [PATCH] objstack: assert that the alloc size will fit within a chunk
+ to prevent a buffer overflow
+
+Bug found using OSS-Fuze.
+-
+https://security-tracker.debian.org/tracker/CVE-2019-25051
+---
+ common/objstack.hpp | 18 ++
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/common/objstack.hpp b/common/objstack.hpp
+index 3997bf7..bd97ccd 100644
+--- a/common/objstack.hpp
 b/common/objstack.hpp
+@@ -5,6 +5,7 @@
+ #include "parm_string.hpp"
+ #include 
+ #include 
++#include 
+ 
+ namespace acommon {
+ 
+@@ -26,6 +27,12 @@ class ObjStack
+   byte * temp_end;
+   void setup_chunk();
+   void new_chunk();
++  bool will_overflow(size_t sz) const {
++return offsetof(Node,data) + sz > chunk_size;
++  }
++  void check_size(size_t sz) {
++assert(!will_overflow(sz));
++  }
+ 
+   ObjStack(const ObjStack &);
+   void operator=(const ObjStack &);
+@@ -56,7 +63,7 @@ public:
+   void * alloc_bottom(size_t size)  {
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); tmp = bottom; bottom += size;}
++if (bottom > top) {check_size(size); new_chunk(); tmp = bottom; bottom += size;}
+ return tmp;
+   }
+   // This alloc_bottom will insure that the object is aligned based on the
+@@ -66,7 +73,7 @@ public:
+ align_bottom(align);
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); goto loop;}
++if (bottom > top) {check_size(size); new_chunk(); goto loop;}
+ return tmp;
+   }
+   char * dup_bottom(ParmString str) {
+@@ -79,7 +86,7 @@ public:
+   // always be aligned as such.
+   void * alloc_top(size_t size) {
+ top -= size;
+-if (top < bottom) {new_chunk(); top -= size;}
++if (top < bottom) {check_size(size); new_chunk(); top -= size;}
+ return top;
+   }
+   // This alloc_top will insure that the object is aligned based on
+@@ -88,7 +95,7 @@ public:
+   {loop:
+ top -= size;
+ align_top(align);
+-if (top < bottom) {new_chunk(); goto loop;}
++if (top < bottom) {check_size(size); new_chunk(); goto loop;}
+ return top;
+   }
+   char * dup_top(ParmString st

Bug#991345: unblock: aspell/0.60.8-3

[Agustin Martin]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package aspell

This upload deals with CVE-2019-25051, fixing a buffer overflow. This has
been reported in Debian BTS as severity grave #991307, closed by this
upload. Package is already built for all arches.

000-objstack-assert-that-the-alloc-size-will-fit-within-.patch is borrowed
from upstream (attached along with the debdiff for easier inspection).

Pasting from #991307 for further info:

--- 8< --
The following vulnerability was published for aspell.

CVE-2019-25051[0]:
| objstack in GNU Aspell 0.60.8 has a heap-based buffer overflow in
| acommon::ObjStack::dup_top (called from acommon::StringMap::add and
| acommon::Config::lookup_list).

https://github.com/google/oss-fuzz-vulns/blob/main/vulns/aspell/OSV-2020-521.yaml
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=18462

Patch:
https://github.com/gnuaspell/aspell/commit/0718b375425aad8e54e1150313b862e4c6fd324a

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-25051
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-25051

Please adjust the affected versions in the BTS as needed.
--- 8< --

Regards,

unblock aspell/0.60.8-3
diff -Nru aspell-0.60.8/debian/changelog aspell-0.60.8/debian/changelog
--- aspell-0.60.8/debian/changelog	2020-12-28 15:24:45.0 +0100
+++ aspell-0.60.8/debian/changelog	2021-07-20 23:42:34.0 +0200
@@ -1,3 +1,11 @@
+aspell (0.60.8-3) unstable; urgency=medium
+
+  * 000-objstack-assert-that-the-alloc-size-will-fit-within-.patch:
+Fix CVE-2019-25051: objstack in GNU Aspell 0.60.8 has a heap-based
+buffer overflow (Closes: #991307).
+
+ -- Agustin Martin Domingo   Tue, 20 Jul 2021 23:42:34 +0200
+
 aspell (0.60.8-2) unstable; urgency=medium
 
   [ Debian Janitor ]
diff -Nru aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch
--- aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch	1970-01-01 01:00:00.0 +0100
+++ aspell-0.60.8/debian/patches/1000-objstack-assert-that-the-alloc-size-will-fit-within-.patch	2021-07-20 23:37:07.0 +0200
@@ -0,0 +1,102 @@
+From 0718b375425aad8e54e1150313b862e4c6fd324a Mon Sep 17 00:00:00 2001
+From: Kevin Atkinson 
+Date: Sat, 21 Dec 2019 20:32:47 +
+Bug-Debian: https://bugs.debian.org/991307
+Subject: [PATCH] objstack: assert that the alloc size will fit within a chunk
+ to prevent a buffer overflow
+
+Bug found using OSS-Fuze.
+-
+https://security-tracker.debian.org/tracker/CVE-2019-25051
+---
+ common/objstack.hpp | 18 ++
+ 1 file changed, 14 insertions(+), 4 deletions(-)
+
+diff --git a/common/objstack.hpp b/common/objstack.hpp
+index 3997bf7..bd97ccd 100644
+--- a/common/objstack.hpp
 b/common/objstack.hpp
+@@ -5,6 +5,7 @@
+ #include "parm_string.hpp"
+ #include 
+ #include 
++#include 
+ 
+ namespace acommon {
+ 
+@@ -26,6 +27,12 @@ class ObjStack
+   byte * temp_end;
+   void setup_chunk();
+   void new_chunk();
++  bool will_overflow(size_t sz) const {
++return offsetof(Node,data) + sz > chunk_size;
++  }
++  void check_size(size_t sz) {
++assert(!will_overflow(sz));
++  }
+ 
+   ObjStack(const ObjStack &);
+   void operator=(const ObjStack &);
+@@ -56,7 +63,7 @@ public:
+   void * alloc_bottom(size_t size)  {
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); tmp = bottom; bottom += size;}
++if (bottom > top) {check_size(size); new_chunk(); tmp = bottom; bottom += size;}
+ return tmp;
+   }
+   // This alloc_bottom will insure that the object is aligned based on the
+@@ -66,7 +73,7 @@ public:
+ align_bottom(align);
+ byte * tmp = bottom;
+ bottom += size;
+-if (bottom > top) {new_chunk(); goto loop;}
++if (bottom > top) {check_size(size); new_chunk(); goto loop;}
+ return tmp;
+   }
+   char * dup_bottom(ParmString str) {
+@@ -79,7 +86,7 @@ public:
+   // always be aligned as such.
+   void * alloc_top(size_t size) {
+ top -= size;
+-if (top < bottom) {new_chunk(); top -= size;}
++if (top < bottom) {check_size(size); new_chunk(); top -= size;}
+ return top;
+   }
+   // This alloc_top will insure that the object is aligned based on
+@@ -88,7 +95,7 @@ public:
+   {loop:
+ top -= size;
+ align_top(align);
+-if (top < bottom) {new_chunk(); goto loop;}
++if (top < bottom) {check_size(size); new_chunk(); goto loop;}
+ return top;
+   }
+   char * dup_top(ParmString st

Bug#990346: customization of ispell-dictionary in emacs: variable is void: default-dictionary

[Agustin Martin]

El sáb, 26 jun 2021 a las 14:39, Maxim Nikulin () escribió:
>
> Package: dictionaries-common
> Version: 1.28.4
> Severity: normal

Hi, Maxim, thanks for the info

> Debian stuff dealing with list of dictionaries available for Emacs
> sometimes causes problems.
>
> 3. Try to customize ispell-dictionary when ispell package is not loaded
> yet, e.g. (add HOME=... if necessary)
>
> emacs --eval "(customize-option 'ispell-dictionary)"
>
> 4. Set some string value, e.g "en_US" and try to save for future
> sessions.
>
> *Actual result*:
>
>  custom-push-theme: Symbol’s value as variable is void:
> default-dictionary

Confirmed

> Expected result: customization is saved to ~/.emacs
> (or ~/.emacs.d/init.el, etc.)
>
> Workaround for this case:
>
>  M-: (require 'ispell) RET
>
> and save for future sessions again.

ispell.el is loaded only after a spellchecking command is issued or
after request. This means that there is no problen once ispell.el is
loaded.  However, in Debian we would expect ispell-dictionary to be
customizable before  that, and use standard defaults if not, so this
is strange.

> I think, the issue is caused by line 442 in
> /usr/share/dictionaries-common/site-elisp/debian-ispell.el
>
>  (or (boundp 'ispell-dictionary)
>  (defcustom ispell-dictionary default-dictionary
...
> where default-dictionary is local to let*. Unsure if defvar will
> be better for this purpose.

The funny thing is that if I change default-dictionary to nil in that
line problem seems to still be present. Unless I am missing some side
effect assignation, seems that the problem is related to have that
defcustom inside a function, but I do not really know why that
happens.

The good thing is that moving that defcustom out of the function and
leaving inside just the code to assign a value if not previously set
seems to work. At least it seems so with attached patch. I will test
this a bit more, but even if everything works, do not expect an upload
until new Debian bullseye is released.

Thanks for your contribution to Debian.

Regards,

-- 
Agust
--- debian-ispell.el.orig	2021-06-26 21:35:17.993190868 +0200
+++ debian-ispell.el	2021-06-26 21:50:06.715333471 +0200
@@ -438,12 +438,8 @@
 
 ;; Set `ispell-dictionary' if still unbound. This will be done after
 ;; init files load, with real `ispell-program-name'
-(or (boundp 'ispell-dictionary)
-	(defcustom ispell-dictionary default-dictionary
-	  "Default dictionary to use if `ispell-local-dictionary' is nil."
-	  :type '(choice string
-			 (const :tag "default" nil))
-	  :group 'ispell))
+(or ispell-dictionary
+	(setq ispell-dictionary default-dictionary))
 
 ;; The debugging output if required
 (if debian-dict-common-debug
@@ -493,4 +489,11 @@
  (ispell-set-spellchecker-params)))
   :group 'ispell)
 
+
+(defcustom ispell-dictionary nil
+  "Default dictionary to use if `ispell-local-dictionary' is nil."
+  :type '(choice string
+		 (const :tag "default" nil))
+  :group 'ispell)
+
 ;;; ---

Bug#982884: marked as done (regina-rexx: Consider migration to debhelper)

[Agustin Martin]

El jue, 6 may 2021 a las 17:36, Debian Bug Tracking System
() escribió:
>
> Changes:
>  regina-rexx (3.6-2.3) unstable; urgency=medium
>  .
>* Non-maintainer upload with maintaner agreement.
>* Migrate to (still old-style) debhelper (Closes: #982884).
>  - Make package multiarch.
>  - Fix reproducibility problems (Closes: #854294).
>* Split original az-patch-01 patch into smaller _AZ_*.diff patches.
>* debian/control: Add "Rules-Requires-Root: no"

Hi, Alen,

Noticed a minor issue after this, libregina3 and libregina-dev were
not tagged as Multi-Arch: same. I am also proposing another couple of
minor issues, On the one hand, installing HACKERS.txt into -dev
package, on the other hand revert file ordering in HISTORY, so newer
changelogs are shown first. I am attaching three patches with the
proposed changes for your consideration in next upload.

Regards,

-- 
Agustin
From 57b7f0d23e878e87d57d29a7f9b3876f3363 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Mon, 10 May 2021 00:12:10 +0200
Subject: [PATCH 1/3] debian/control: Mark libregina3 and libregina-dev
 "Multi-Arch: same"

Signed-off-by: Agustin Martin Domingo 
---
 debian/control | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/control b/debian/control
index 14e0106..c81a5e3 100644
--- a/debian/control
+++ b/debian/control
@@ -16,6 +16,7 @@ Depends: ${shlibs:Depends},
 	 ${misc:Depends}
 Conflicts: regina3
 Replaces: regina3
+Multi-Arch: same
 Description: Regina REXX interpreter, run-time library
  Regina is an ANSI compliant REXX interpreter for multiple platforms.
  .
@@ -36,6 +37,7 @@ Conflicts: regina2-dev,
 	   regina3-dev
 Replaces: regina2-dev,
 	  regina3-dev
+Multi-Arch: same
 Description: Regina REXX interpreter, development files
  Regina is an ANSI compliant REXX interpreter for multiple platforms.
  .
-- 
2.31.1

From 514da86934a33579e9c5e5b60adef398573468d3 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 7 May 2021 17:16:35 +0200
Subject: [PATCH 2/3] debian/libregina3-dev.docs: Install HACKERS.txt.

Signed-off-by: Agustin Martin Domingo 
---
 debian/libregina3-dev.docs | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 debian/libregina3-dev.docs

diff --git a/debian/libregina3-dev.docs b/debian/libregina3-dev.docs
new file mode 100644
index 000..50ca005
--- /dev/null
+++ b/debian/libregina3-dev.docs
@@ -0,0 +1 @@
+HACKERS.txt
-- 
2.31.1

From 856566881972e2bfd04277f7152d1cb8d7fd0397 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 7 May 2021 19:21:04 +0200
Subject: [PATCH 3/3] debian/rules: Revert file ordering in HISTORY file. Newer
 first.

Signed-off-by: Agustin Martin Domingo 
---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 1d8b4cf..5bcb163 100755
--- a/debian/rules
+++ b/debian/rules
@@ -58,8 +58,8 @@ build-stamp: configure-stamp
 
 	# Add here commands to compile the package.
 	$(MAKE) CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
-	#docbook-to-man debian/pam-encfs.sgml > pam-encfs.1
-	cat README.0* README.2* README.3* > $(HISTORY)
+	# Bundle all READMEs into a single HISTORY file
+	cat $(shell echo  README.0* README.2* README.3* | tr -s ' ' '\n' | sort -r) > $(HISTORY)
 
 	touch build-stamp
 
-- 
2.31.1

Bug#982884: Bug#930005: regina-rexx: rexxutil error

[Agustin Martin]

El mar, 2 mar 2021 a las 0:28, Agustin Martin () escribió:
>
> I am attaching proposed patches for three additional changes on top of
> the previous debhelper ones. I do not know current build status for
> ia64 build, problematic CFLAFS should be added to
> DEB_CFLAGS_MAINT_STRIP inside the ifeq to make sure dpkg-buildflags
> does not include them for ia64.

Hi,

This was two months ago, ¿any news about this debhelper migration?

I have a regina-rexx package ready for upload, including debhelper
migration. I would like to upload it if needed.

I have been also playing with upgrades to more recent upstream
versions. I think I can also help here if needed.

Regards,

-- 
Agustin

Bug#987264: git-el: fails to install with xemacs21

[Agustin Martin]

On Sat, 24 Apr 2021 02:59:40 +0300 Adrian Bunk  wrote:
> On Tue, Apr 20, 2021 at 05:10:16PM +0200, Andreas Beckmann wrote:
> > Package: git-el
> > Version: 1:2.30.2-1
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> >
> > Hi,
> >
> > during a test with piuparts I noticed your package failed to install if
> > xemacs21 is already installed.
>
> Most relevant is that emacs-common is *not* installed
> and neither any other package that ships /usr/share/emacs/site-lisp/

IIRC emacs-common is only for FSF Emacs packages.

The quickest workaround would be to add a debian/git-el.dirs file
containing usr/share/emacs/site-lisp. I wonder if emacsen-common
package should provide that dir for all emacs flavours.

-- 
Agustin

Bug#981368: xserver-xorg-video-intel: Xserver becomes unresponsive with some worloads. maybe related to video rendering

[Agustin Martin]

Control: reassign -1 linux
Control: found -1 5.10.0-2
Control: affects -1 xserver-xorg-video-intel
Control: fixed -1 5.10.19-1
Control: close -1 5.10.19-1

On Tue, 23 Feb 2021 22:36:02 +0100 joerg.mechnich wrote:
> Looks like this was actually a bug in the i915 module:
>
> https://gitlab.freedesktop.org/drm/intel/-/issues/2905
>
> There is a linked issue #2923
> "deadlock in intel_atomic_cleanup_work (kernel 5.10.5)"
> that seems to fit the descriptions in this thread here.
>
> After upgrading to a custom 5.10.17 kernel, I don't seem to experience
> the same issue anymore while still using the intel Xorg driver.
>
> I agree that this report could be closed now.

Hi,

Since this seems to be a kernel bug, I am resssigning this bug report
to linux kernel and marking it as affecting xserver-xorg-video-intel.
Since linux 5.10.19 is already in sid I am marking this bug report as
fixed with that upload. Trying to do everything with this message, not
sure if it will work well.

> Cheers and thanks for keeping the intel driver alive, still performs
> significantly better on my particular system than the modesetting driver!

+1

Regards,

--
Agustin

Bug#982884: Bug#930005: regina-rexx: rexxutil error

[Agustin Martin]

El lun, 15 feb 2021 a las 22:17, Agustin Martin
() escribió:
>
> El lun, 15 feb 2021 a las 20:55, Agustin Martin
> () escribió:
> >
> Find attached proposed patch for regina-rexx wrapper under multiarch.
 regina-config
^^
Hi, Alen,

I am attaching proposed patches for three additional changes on top of
the previous debhelper ones. I do not know current build status for
ia64 build, problematic CFLAFS should be added to
DEB_CFLAGS_MAINT_STRIP inside the ifeq to make sure dpkg-buildflags
does not include them for ia64.

Regards,

-- 
Agustin
From 8d5b3a87178b5e300162ec6dec0cee8cd775575b Mon Sep 17 00:00:00 2001
From: Agustin Martin 
Date: Tue, 16 Feb 2021 12:10:01 +0100
Subject: [PATCH 1/3] Do not hardcode compile/link flags into Makefile.in

It is better to handle this from debian/rules and build chain.

Signed-off-by: Agustin Martin 
---
 ...000_Makefile.in_Do-not-hardcode-FLAGS.diff | 23 +++
 debian/patches/az-patch-01|  9 
 debian/patches/series |  1 +
 debian/rules  |  2 +-
 4 files changed, 25 insertions(+), 10 deletions(-)
 create mode 100644 debian/patches/2000_Makefile.in_Do-not-hardcode-FLAGS.diff

diff --git a/debian/patches/2000_Makefile.in_Do-not-hardcode-FLAGS.diff b/debian/patches/2000_Makefile.in_Do-not-hardcode-FLAGS.diff
new file mode 100644
index 000..5993b3c
--- /dev/null
+++ b/debian/patches/2000_Makefile.in_Do-not-hardcode-FLAGS.diff
@@ -0,0 +1,23 @@
+Description: Do not hardcode compile/link flags into Makefile.in
+Author: Agustin Martin 
+
+Index: regina-rexx/Makefile.in
+===
+--- regina-rexx.orig/Makefile.in	2021-02-12 12:21:43.598716459 +0100
 regina-rexx/Makefile.in	2021-02-12 12:48:55.833461248 +0100
+@@ -39,11 +39,11 @@
+ 
+ INSTALL  = $(srcdir)/install-sh
+ 
+-CC  = @CC@
+-RANLIB = @RANLIB@
++# CC  = @CC@
++# RANLIB = @RANLIB@
+ LN_S  = @LN_S@
+-CFLAGS = @CFLAGS@
+-LDFLAGS = @LDFLAGS@
++# CFLAGS = @CFLAGS@
++# LDFLAGS = @LDFLAGS@
+ 
+ RANLIB_DYNAMIC = @RANLIB_DYNAMIC@
+ CEXTRA = @CEXTRA@ @DLFCNINCDIR@ -DREGINA_SHARE_DIRECTORY=\"$(sharedir)\" @MH_UNSIGNED_CHAR_SWITCH@ -DREGINA_VERSION_DATE=\"@VER_DATE@\" -DREGINA_VERSION_MAJOR=\"@VER_MAJOR@\" -DREGINA_VERSION_MINOR=\"@VER_MINOR@\" -DREGINA_VERSION_SUPP=\"@VER_SUPP@\"
diff --git a/debian/patches/az-patch-01 b/debian/patches/az-patch-01
index 70e0b30..3bff999 100644
--- a/debian/patches/az-patch-01
+++ b/debian/patches/az-patch-01
@@ -12,15 +12,6 @@ Bug-Debian: http://bugs.debian.org/661883
 
 --- a/Makefile.in
 +++ b/Makefile.in
-@@ -41,7 +41,7 @@ INSTALL  = $(srcdir)/install-sh
- CC  = @CC@
- RANLIB = @RANLIB@
- LN_S  = @LN_S@
--CFLAGS = @CFLAGS@
-+CFLAGS = $(DEB_CFLAGS)
- LDFLAGS = @LDFLAGS@
- 
- RANLIB_DYNAMIC = @RANLIB_DYNAMIC@
 @@ -124,7 +124,7 @@ REGINAEXP = @REGINAEXP@
  RPMTOPDIR = @RPMTOPDIR@
  HAVE_GCI = @HAVE_GCI@
diff --git a/debian/patches/series b/debian/patches/series
index 39a24b0..ca3dfa7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@ az-patch-01
 _Makefile.in_libdir.diff
 _Makefile.in_sharedir.diff
 2000_regina-config_use-wrapper.diff
+2000_Makefile.in_Do-not-hardcode-FLAGS.diff
diff --git a/debian/rules b/debian/rules
index 159510e..5a2cde5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -50,7 +50,7 @@ build-stamp: configure-stamp
 	dh_testdir
 
 	# Add here commands to compile the package.
-	$(MAKE) DEB_CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
+	$(MAKE) CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
 	#docbook-to-man debian/pam-encfs.sgml > pam-encfs.1
 
 	touch build-stamp
-- 
2.30.1

From d26c89fd7d5c80818b85df69a4b11045a86adee0 Mon Sep 17 00:00:00 2001
From: Agustin Martin 
Date: Tue, 16 Feb 2021 13:03:27 +0100
Subject: [PATCH 2/3] debian/rules: Set hardening flags.

CFLAGS for ia64 will be adjusted later. Inside the ifeq
statement CFLAGS options not working for ia64 will be added to
DEB_CFLAGS_MAINT_STRIP as a space separated string to have it
stripped from resulting CFLAGS.

Signed-off-by: Agustin Martin 
---
 debian/patches/az-patch-01 | 67 +++---
 debian/rules   | 21 ++--
 2 files changed, 44 insertions(+), 44 deletions(-)

diff --git a/debian/patches/az-patch-01 b/debian/patches/az-patch-01
index 3bff999..3196c57 100644
--- a/debian/patches/az-patch-01
+++ b/debian/patches/az-patch-01
@@ -10,9 +10,11 @@ Author: Alen Zekulic 
 Forwarded: not-needed
 Bug-Debian: http://bugs.debian.org/661883
 
 a/Makefile.in
-+++ b/Makefile.in
-@@ -124,7 +124,7 @@ REGINAEXP = @REGINAEXP@
+Index: regina-rexx-debhelper/Makefile.in
+===
+--- regina-rex

Bug#982884: Bug#930005: regina-rexx: rexxutil error

[Agustin Martin]

El lun, 15 feb 2021 a las 20:55, Agustin Martin
() escribió:
>
>
> There is a pending thing about multiarch, the handling of
> regina-config is not yet multiarch friendly. An $arch version should
> be installed in an arch dependent dir and /usr/bin/regina-config be
> made a wrapper to it, considering the architecture for which the
> package is built (this is important e.g. when building for amd64/i386
> from the other arch). Once I have something ready I will submit an
> additional patch to this bug report, to be appplied after debhelper
> migration changes.
>

Find attached proposed patch for regina-rexx wrapper under multiarch.

-- 
Agustin
From af56bdfa735531a564be53dd436cd51988d34225 Mon Sep 17 00:00:00 2001
From: Agustin Martin 
Date: Mon, 15 Feb 2021 21:49:26 +0100
Subject: [PATCH] Handle multiarch with regina-config.

regina-config must be *exactly* the same across architectures.
Auto-generated regina-config may have different stuff like
libraries for some co-installable architectures.

Install arch dependent regina-config in libregina3 under arch
specific dir and a regina-config wrapper in libregina3-dev,
which will call arch specific regina-config.

Signed-off-by: Agustin Martin 
---
 debian/libregina3.install |   1 +
 .../2000_regina-config_use-wrapper.diff   |  22 
 debian/patches/series |   1 +
 debian/regina-config  | 112 +-
 4 files changed, 55 insertions(+), 81 deletions(-)
 create mode 100644 debian/patches/2000_regina-config_use-wrapper.diff

diff --git a/debian/libregina3.install b/debian/libregina3.install
index 6a3f187..463c2ef 100644
--- a/debian/libregina3.install
+++ b/debian/libregina3.install
@@ -1,2 +1,3 @@
 usr/lib/*/regina-rexx/*/*
 usr/lib/*/libregina.so.*
+usr/lib/*/regina-rexx/regina-config
diff --git a/debian/patches/2000_regina-config_use-wrapper.diff b/debian/patches/2000_regina-config_use-wrapper.diff
new file mode 100644
index 000..d16d3b7
--- /dev/null
+++ b/debian/patches/2000_regina-config_use-wrapper.diff
@@ -0,0 +1,22 @@
+Index: regina-rexx-debhelper/Makefile.in
+===
+--- regina-rexx-debhelper.orig/Makefile.in	2021-02-15 21:34:08.402245272 +0100
 regina-rexx-debhelper/Makefile.in	2021-02-15 21:34:29.202369805 +0100
+@@ -1206,6 +1206,9 @@
+ 	$(INSTALL) -m 644 -c $(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI) $(libdir)/$(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI)
+ 	$(LN_S) -f $(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI) $(libdir)/$(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI_MAJOR)
+ 	$(INSTALL) -m 644 -c $(SHLPRE)regutil$(MODPST) $(libdir)/regina-rexx/$(ABI)/$(SHLPRE)regutil$(MODPST)
++#	regina-config here is arch dependent.
++	$(INSTALL) -m 755 -d $(libdir)/regina-rexx/
++	$(INSTALL) -m 755 -c ./regina-config $(libdir)/regina-rexx/regina-config
+ 
+ install-dev: $(LIBPRE)$(LIBFILE)$(LIBPST)
+ # header file
+@@ -1216,7 +1219,6 @@
+ # libregina.so.x -> libregina.so
+ 	$(LN_S) -f $(SHLPRE)$(SHLFILE)$(SHLPST).$(ABI) $(libdir)/$(SHLPRE)$(SHLFILE)$(SHLPST)
+ # regina-config
+-	$(INSTALL) -m 755 -c ./regina-config $(prefix)/bin/regina-config
+ 	$(INSTALL) -c -m 644 $(srcdir)/regina-config.1 $(prefix)/share/man/man1/regina-config.1
+ 
+ install-rexx: rexx$(EXE) regina$(EXE)
diff --git a/debian/patches/series b/debian/patches/series
index d6565de..39a24b0 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ az-patch-01
 _Makefile.in_set-DESTDIR.diff
 _Makefile.in_libdir.diff
 _Makefile.in_sharedir.diff
+2000_regina-config_use-wrapper.diff
diff --git a/debian/regina-config b/debian/regina-config
index fe95aef..8f0791f 100644
--- a/debian/regina-config
+++ b/debian/regina-config
@@ -1,85 +1,35 @@
 #!/bin/sh
 #
-# The idea to this kind of setup info script was stolen from numerous
-# other packages, such as neon, libxml and gnome.
+# Generic multiarch wrapper for regina-config
 #
-prefix=/usr
-exec_prefix=${prefix}
-includedir=${prefix}/include
-libdir=${exec_prefix}/lib
-
-
-usage()
-{
-echo "Usage: regina-config [OPTION]"
-echo ""
-echo "Available values for OPTION include:"
-echo ""
-echo "  --help display this help and exit"
-echo "  --cflags   pre-processor and compiler flags"
-echo " [-I$includedir]"
-echo "  --multithread  yes; if thread-safe library is available; no otherwise"
-echo " [yes]"
-echo "  --libs library linking information"
-echo " [-lregina]"
-echo "  --libs_ts  library linking information for thread-safe library"
-echo " [-lregina]"
-echo "  --prefix   Regina install prefix"
-echo " [$prefix]"
-echo "  --version  output version informa

Bug#930005: regina-rexx: rexxutil error

[Agustin Martin]

Package: regina-rexx
Version: 3.6-2.2
Severity: wishlist

El lun, 15 feb 2021 a las 13:40, Alen Zekulic () escribió:
>
> On Mon, Feb 15, 2021 at 13:16:58 +0100, Agustin Martin wrote:
>
> > I think I have something close to be ready for migration to debhelper.
>
> Me too. :)
>
> > ¿What do you prefer, a commit to salsa or a patch in the BTS?
>
> For now I prefer a patch in the BTS.

FIne, Alen,

I am filing a new bug report about this with wishlist severity, and
attaching a git patch with my changes. This is only about migration to
old-style debhelper from 3.5-2.2. It includes the migration itself and
making most of the package multiarch ready. As a bonus this fixes the
timestamp issues in #854294.

There is a pending thing about multiarch, the handling of
regina-config is not yet multiarch friendly. An $arch version should
be installed in an arch dependent dir and /usr/bin/regina-config be
made a wrapper to it, considering the architecture for which the
package is built (this is important e.g. when building for amd64/i386
from the other arch). Once I have something ready I will submit an
additional patch to this bug report, to be appplied after debhelper
migration changes.

Regards,

-- 
Agustin
From 389c9685789a9799477c09285c378b784f87bd51 Mon Sep 17 00:00:00 2001
From: Agustin Martin 
Date: Mon, 15 Feb 2021 20:29:39 +0100
Subject: [PATCH] Migrate to old-style debhelper from regina-rexx 3.6-2.2

* Migration to old-style debhelper. This also includes:
  - Make package multiarch.
  - Fix the timestamp issues in #854294.
* Remove autotools-dev Build-Dep, it is pulled by debhelper.

Signed-off-by: Agustin Martin 
---
 debian/control|  20 +-
 debian/libregina3-dev.install |   5 +
 debian/libregina3-dev.manpages|   1 +
 debian/libregina3.install |   2 +
 debian/md5_sums   |  19 --
 debian/patches/_Makefile.in_libdir.diff   |  32 +++
 .../patches/_Makefile.in_set-DESTDIR.diff |  17 ++
 debian/patches/_Makefile.in_sharedir.diff |  25 +++
 debian/patches/az-patch-01|  18 --
 debian/patches/series |   4 +
 debian/postinst   |   8 -
 debian/postrm |   8 -
 debian/postrm-dev |   8 -
 debian/regina-rexx.examples   |   2 +
 debian/regina-rexx.install|   5 +
 debian/regina-rexx.links  |   1 +
 debian/regina-rexx.manpages   |   3 +
 debian/rules  | 190 +++---
 18 files changed, 186 insertions(+), 182 deletions(-)
 create mode 100644 debian/libregina3-dev.install
 create mode 100644 debian/libregina3-dev.manpages
 create mode 100644 debian/libregina3.install
 delete mode 100644 debian/md5_sums
 create mode 100644 debian/patches/_Makefile.in_libdir.diff
 create mode 100644 debian/patches/_Makefile.in_set-DESTDIR.diff
 create mode 100644 debian/patches/_Makefile.in_sharedir.diff
 delete mode 100644 debian/postinst
 delete mode 100644 debian/postrm
 delete mode 100644 debian/postrm-dev
 create mode 100644 debian/regina-rexx.examples
 create mode 100644 debian/regina-rexx.install
 create mode 100644 debian/regina-rexx.links
 create mode 100644 debian/regina-rexx.manpages

diff --git a/debian/control b/debian/control
index 0413a05..bc66464 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,8 @@ Source: regina-rexx
 Section: libs
 Priority: optional
 Maintainer: Alen Zekulic 
-Build-Depends: libncurses5-dev, autotools-dev
+Build-Depends: libncurses5-dev,
+	   debhelper-compat (=12)
 Standards-Version: 4.4.1
 Homepage: http://regina-rexx.sourceforge.net/
 Vcs-Git: https://salsa.debian.org/debian/regina-rexx.git
@@ -10,7 +11,8 @@ Vcs-Browser: https://salsa.debian.org/debian/regina-rexx
 
 Package: libregina3
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends},
+	 ${misc:Depends} 
 Conflicts: regina3
 Replaces: regina3
 Description: Regina REXX interpreter, run-time library
@@ -25,9 +27,14 @@ Description: Regina REXX interpreter, run-time library
 Package: libregina3-dev
 Section: libdevel
 Architecture: any
-Depends: ${regver:Depends}, libc6-dev, cpp
-Conflicts: regina2-dev, regina3-dev
-Replaces: regina2-dev, regina3-dev
+Depends: ${misc:Depends},
+	 libregina3 (= ${binary:Version}),
+	 libc6-dev,
+	 cpp
+Conflicts: regina2-dev,
+	   regina3-dev
+Replaces: regina2-dev,
+	  regina3-dev
 Description: Regina REXX interpreter, development files
  Regina is an ANSI compliant REXX interpreter for multiple platforms.
  .
@@ -41,7 +48,8 @@ Description: Regina REXX interpreter, development files
 Package: regina-rexx
 Section: interpreters
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends},
+	 ${misc:Depends} 
 Description: Regina REXX interpreter
  Regina i

Bug#930005: regina-rexx: rexxutil error

[Agustin Martin]

El lun, 15 feb 2021 a las 0:05, Agustin Martin () escribió:
>
> El vie, 12 feb 2021 a las 23:05, Alen Zekulic () 
> escribió:
> >
> > I agree, please go ahead!
>
> Uploaded.

Hi,

Seems this upload has been late for two days, so regina-rexx will not
hit bullseye because of soft freeze (see
https://release.debian.org/bullseye/freeze_policy.html#soft),

"Packages that are not in testing will not be allowed to migrate to
testing. This applies to new packages as well as to packages that were
removed from testing (either manually or by auto-removals). Packages
that are not in bullseye at the start of the soft freeze will not be
in the release."

> > I planed to migrate my debian/rules to debhelper too.
>
> When I was playing with this there were still some issues. Once I find
> time to continue and consider things in good shape, I will let you
> know. Another thing I think may be interesting is to split the a-z
> patch into smaller chunks for better handling.

I think I have something close to be ready for migration to debhelper.
¿What do you prefer, a commit to salsa or a patch in the BTS?

Regards,

-- 
Agustin

Bug#930005: regina-rexx: rexxutil error

[Agustin Martin]

El vie, 12 feb 2021 a las 23:05, Alen Zekulic () escribió:
>
> On Fri, Feb 12, 2021 at 13:25:23 +0100, Agustin Martin wrote:
>
> > Alen, I plan to upload a NMU with this changes and may be some minor
> > issues. Even if I have not written rexx for years I think it would be
> > a pity to have this package with this open bug.
>
> I agree, please go ahead!

Uploaded.

> > Also, one issue with this package is that Debian build system is
> > ancient, even pre-debhelper. This makes everything a nightmare. I
> > have been playing with a migration to traditional (no dh sequencer)
> > debhelper. This should fix another bug report about build
> > reproduciibility. I am aware that this is a rather invasive change,
> > but I think is required to make contributors life easier, let me know
> > your POV.
>
> I planed to migrate my debian/rules to debhelper too.

When I was playing with this there were still some issues. Once I find
time to continue and consider things in good shape, I will let you
know. Another thing I think may be interesting is to split the a-z
patch into smaller chunks for better handling.

> > Other thing I noticed is that this package has no repo under
> > salsa. I can prepare a git repo with regina history and put it under
> > salsa/debian group. Alen, please tell me if you object to this, I
> > consider it important and will proceed unless you object explicitly.
>
> Any help is greatly appreciated, I have no objection, quite the
> contrary!

When I was creating the repo I noticed that there was already a repo
created under debian salsa group by Boyuan Yang, with commits for a
NMU that was never uploaded, so I used it. Reverted one thing, no need
to B-D on debhelper just to pull autotools-dev, debhelper is currently
unused.

> > By the way, upstream is active and there are new versions available,
> > although I will focus on current upstream version in Debian.
>
> Mark and I are in contact. We plan to roll out the latest releases of
> Regina REXX (3.9.4) and The Hessling Editor (3.3) as soon as possible.

Nice to know,

Regards,

-- 
Agustin

Bug#930005: regina-rexx: rexxutil error

[Agustin Martin]

On Sun, 16 Jun 2019 23:26:45 +0200 Andreas Beckmann  wrote:
> Followup-For: Bug #930005
> Control: tag -1 patch
>
> The attached patch fixes the linking issue and thus the missing tgetent
> symbol. Thereafter the command
> regina /usr/share/doc/regina-rexx/examples/regutil.rexx
> works on i386, but segfaults on amd64.

Hi all,

I have been looking into this package. Seems the amd64 segfault
disappears when we make sure termcap.h is loaded from the right
regutils file. I am attaching two additional  patches for
debian/patches, one sets HAVE_TGETENT and the other makes sure
termcap.h is loaded if so.

Alen, I plan to upload a NMU with this changes and may be some minor
issues. Even if I have not written rexx for years I think it would be
a pity to have this package with this open bug.

Also, one issue with this package is that Debian build system is
ancient, even pre-debhelper. This makes everything a nightmare. I have
been playing with a migration to traditional (no dh sequencer)
debhelper. This should fix another bug report about build
reproduciibility. I am aware that this is a rather invasive change,
but I think is required to make contributors life easier, let me know
your POV.

Other thing I noticed is that this package has no repo under salsa. I
can prepare a git repo with regina history and put it under
salsa/debian group. Alen, please tell me if you object to this, I
consider it important and will proceed unless you object explicitly.

By the way, upstream is active and there are new versions available,
although I will focus on current upstream version in Debian.

Regards,

--
Agustin
Index: regina-rexx/regutil/regscreenux.c
===
--- regina-rexx.orig/regutil/regscreenux.c	2021-02-12 00:18:07.362794088 +0100
+++ regina-rexx/regutil/regscreenux.c	2021-02-12 00:22:30.733931644 +0100
@@ -34,6 +34,10 @@
 # include 
 #endif
 
+#ifdef HAVE_TGETENT
+#  include 
+#endif
+
 #if 0
 #ifdef USE_TERMCAP_DB
 # ifdef HAVE_TERM_H
Index: regina-rexx/configure.in
===
--- regina-rexx.orig/configure.in	2021-02-11 23:35:03.688015418 +0100
+++ regina-rexx/configure.in	2021-02-11 23:35:03.684015371 +0100
@@ -248,6 +248,9 @@
 if test "$REGUTIL_TERM_LIB" = "none required" -o "$REGUTIL_TERM_LIB" = "no"; then
   REGUTIL_TERM_LIB=""
 fi
+if test "x$REGUTIL_TERM_LIB" != "x"; then
+AC_DEFINE([HAVE_TGETENT],[1],[Define if tgetent exist])
+fi
 LIBS="$save_LIBS"
 AC_SUBST(REGUTIL_TERM_LIB)
 
Index: regina-rexx/configure
===
--- regina-rexx.orig/configure	2021-02-11 23:35:02.932006415 +0100
+++ regina-rexx/configure	2021-02-11 23:35:36.260403347 +0100
@@ -5259,8 +5259,14 @@
 if test "$REGUTIL_TERM_LIB" = "none required" -o "$REGUTIL_TERM_LIB" = "no"; then
   REGUTIL_TERM_LIB=""
 fi
+if test "x$REGUTIL_TERM_LIB" != "x"; then
+
+$as_echo "#define HAVE_TGETENT 1" >>confdefs.h
+
+fi
 LIBS="$save_LIBS"
 
+
 save_LIBS="$LIBS"
 { $as_echo "$as_me:${as_lineno-$LINENO}: checking for library containing crypt" >&5
 $as_echo_n "checking for library containing crypt... " >&6; }

Bug#980302: dictionaries-common-dev: vim dictionary support

[Agustin Martin]

El mar, 2 feb 2021 a las 3:45, James McCoy () escribió:

> Back when I last tried to maintain vim-spellfiles, most of the languages
> were reasonable to build.  There were just a couple which completely
> crippled my computer when building.

Thanks for the feedback, James,

I was having some fun with the espa~nol package, which still provides
a pure myspell-es dict (different and from different authors than
hunspell-es) to see how hard would be to generate a vim spellchecking
dict from it. For those curious I am attaching a diff with the used
changes, although I would prefer the libhunspell way. It took around
8s per dict, not a big problem. To properly build utf-8 part in a
pbuilder chroot I had to set LC_ALL instead of LANG. Another problem I
noticed is that vim expects those dicts in a versioned dir, so unless
somehing else is added to vim search path package will need to be
rebuilt everytime that version changes.

> Bram appears receptive to reviewing an fully fleshed out version of the
> libhunspell patch, so I'd prefer to focus efforts on cleaning that up
> and getting it upstreamed.  That would also avoid duplicating efforts on
> keeping multiple sources of dictionaries updated.

Agreed. Most myspell only dicts are somewhat old and most new hunspell
dicts will not work well with vim spellchecking engine. Hope someone
revitalizes the libunspell patch way.

Regards,

-- 
Agustin
diff --git a/debian/control b/debian/control
index 41cef1f..f540811 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,9 @@ Build-Depends: debhelper-compat (= 12),
 Build-Depends-Indep: ispell,
  aspell,
  dictionaries-common-dev (>= 1.23.2),
- hunspell-tools | myspell-tools | libmyspell-dev (>= 1:3.1-7)
+ hunspell-tools | myspell-tools | libmyspell-dev (>= 1:3.1-7),
+		 vim,
+		 locales-all
 Standards-Version: 4.1.4
 Vcs-Browser: https://salsa.debian.org/agmartin/espa-nol
 Vcs-Git: https://salsa.debian.org/agmartin/espa-nol.git
@@ -57,3 +59,13 @@ Description: Spanish dictionary for aspell
  This is the Spanish dictionary for use with the aspell spellchecker.
  It is based on ispell dictionary put together by
  Santiago Rodriguez and Jesus Carretero.
+
+Package: vim-spell-es
+Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends},
+	 vim
+Description: Spanish dictionary for vim spell
+ This is the Spanish dictionary for use with the vim spellchecker.
+ It is based on ispell dictionary put together by
+ Santiago Rodriguez and Jesus Carretero.
diff --git a/debian/es_ES.myheader b/debian/es_ES.myheader
index dda545d..7fc92c1 100644
--- a/debian/es_ES.myheader
+++ b/debian/es_ES.myheader
@@ -1,6 +1,14 @@
 SET ISO8859-1
 TRY aersoinltcdmubpágízfvhéjqóņxyúükCMAIESPGJBRFTDVHUOwLKNZÁYXÜÓÚÉŅQWÍ
 
+# For vim spellchecking
+FOL  ßāáâãäåæįčéęëėíîïðņōóôõöøųúûüýþĸ
+LOW  ßāáâãäåæįčéęëėíîïðņōóôõöøųúûüýþĸ
+UPP  ßĀÁÂÃÄÅÆĮČÉĘËĖÍÎÏÐŅŌÓÔÕÖØŲÚÛÜÝÞĸ
+
+SOFOFROM abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZāáâãäåæįčéęëėíîïðņōóôõöøųúûüýþßĸĀÁÂÃÄÅÆĮČÉĘËĖÍÎÏÐŅŌÓÔÕÖØŲÚÛÜÝÞŋ
+SOFOTO   ebctefghejklnnepkrstevvkesebctefghejklnnepkrstevvkeseeecdneeepscdneeep?
+
 # -
 # The affix file below is automatically generated from espa~nol.aff file by
 # means of ispellaff2myspell script. Original copyright applies:
diff --git a/debian/es_ES.replaces b/debian/es_ES.replaces
index bc1339c..f548a4e 100644
--- a/debian/es_ES.replaces
+++ b/debian/es_ES.replaces
@@ -51,3 +51,16 @@ REP g
 REP hue güe
 REP güi hui
 REP hui güi
+
+# map rules for vim use
+
+MAP 9
+MAP aāáâãäå
+MAP ečéęë
+MAP iėíîï
+MAP oōóôõö
+MAP uųúûü
+MAP nņ
+MAP cį
+MAP yĸý
+MAP sß
diff --git a/debian/rules b/debian/rules
index d150637..ecd8470 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,6 +20,9 @@ ISHAREDIR	=	$(CURDIR)/debian/ispanish/usr/share/ispell
 #
 OOOTMP  =   ooo-tmp
 #
+VIM =	vim
+VIMTMP  =   vim-tmp
+#
 ASPELL6BASENAME =   aspell6-es
 ASPELL6DIR  =   $(CURDIR)/debian/$(ASPELL6BASENAME)
 ASPELLPROC  =   /usr/share/aspell-lang/proc# Location of proc script
@@ -58,6 +61,12 @@ build-stamp: $(QUILT_STAMPFN)
 		--replacements=debian/es_ES.replaces \
 		--myheader=debian/es_ES.myheader $(AFFIXES).latin1 > es_ES.myaff
 
+# - Creating vim dict
+	mkdir -p $(VIMTMP)
+	cp es_ES.myaff  $(VIMTMP)/es_ES.aff
+	cp es_ES.mydict $(VIMTMP)/es_ES.dic
+	LC_ALL=es_ES.ISO8859-1 $(VIM) -u NONE -e -c "mkspell! $(VIMTMP)/es $(VIMTMP)/es_ES" -c q
+	LC_ALL=es_ES.UTF-8  $(VIM) -u NONE -e -c "mkspell! $(VIMTMP)/es $(VIMTMP)/es_ES" -c q
 # -
 
 #	cat $(LANGUAGE).allwords+.latin1 | ispell -d ./$(LANGUAGE) -e | \
@@ -92,7 +101,7 @@ clean-patched:
 #	rm -f $(LANGUAGE).wordlist
 	rm -f es_ES.mydict  es_ES.myaff $(LANGUAGE).mwl.gz
 	rm -f es_affix.dat $(ISOLANG).cwl.gz
-	rm -rf $(OOOTMP)
+	rm -rf $(OOOTMP) $(VIMTMP)
 
 	if [ -d 

Bug#980302: dictionaries-common-dev: vim dictionary support

[Agustin Martin]

Control: reassign -1 dictionaries-common-dev,vim

El lun, 18 ene 2021 a las 19:34, Agustin Martin
() escribió:
> El lun, 18 ene 2021 a las 13:54, Kurt Roeckx () escribió:
> > > > Vim has support for spellchecking using it's own spell check
> > > > files. It can be generated based on hunspell .aff/.dic files, or
> > > > based on a wordlist. Files currently need to be placed in
> > > > /usr/share/vim/vim82/spell/
...
> > > This was mentioned a while ago in #490987. It was closed because at
> > > that time building vim spell files creation seemed to be very memory
> > > intensive and using libhunspell via a redhat patch was under
> > > consideration. I have no idea about current status of spellchecking in
> > > vim and if those concerns were addressed.
...
> I do not object adding a vim section to policy if there is need to
> coordinate with packages outside the vim environment. However, from
> what I seem to understand, everything is inside vim ecosystem.
> spellchecker is part of vim, hunspell dicts need to be adapted for vim
> and this spellchecking facility seems not to be used outside vim.

Hi, Kurt and James,

I am temporarily reassigning this bug report to both vim and
dictionaries-common-dev, so vim maintaners are aware of it and can
share their POV. I will not go anywhere without their approval.

I have been looking at
https://github.com/vim/vim/tree/master/runtime/spell and
http://snapshot.debian.org/package/vim-spellfiles/ to have an idea
about this issue. Seems vim uses myspell dictionaries (or early
hunspell dicts). Current hunspell dicts normally use a number of
things that seem unsupported by vim spellchecker, so while using
recent hunspell dicts may appear to work, it will likely work worse
than old files.

I can think of two approaches, resurrecting vim-spellfiles package
and/or creating vim dicts from packages currently using a myspell dict
(normally as a source for aspell dict). Have to ellaborate a bit more.

James, ¿what do you think about this?

Regards,

-- 
Agustin

Bug#980302: dictionaries-common-dev: vim dictionary support

[Agustin Martin]

El lun, 18 ene 2021 a las 20:26, Kurt Roeckx () escribió:
>
> Vim has it's own file format and implementation that works totally
> different than hunspell, and so needs to convert it to it's own
> format.
>
> I have no idea what vim-spellfiles was, it only seems to have been
> in experimental.

It is still available from http://snapshot.debian.org/package/vim-spellfiles/

After a quick glance it seems to contain some diff and aap files,
probably like those in
https://github.com/vim/vim/tree/master/runtime/spell but even more
outdated and with a different structure. I wonder if some of the old
maintainers may still be interested in vim spellchecking, currently
there is a single vim uploader.

One thing, do you know if processed vim dictionaries are arch:all?

> There is documentation about it in:
> /usr/share/vim/vim82/doc/spell.txt
> Or online at: https://vimhelp.org/spell.txt.html

Thanks for the info. Have to look deeper, may be aff format supported
by vim is closer to an old hunspell format, hopefully the same subset
aspell supports. That could make things easier.

--
Agustin