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#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#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#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#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#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#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#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#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#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#979575: ispell 3.4.01 breaks affix files of igerman98 and hkgerman

[Agustin Martin]

reassign 979694 ispell 3.4.01-1
reassign 979746 ispell 3.4.01-1
forcemerge 979575 979694 979746
affects 979575 ispanish
thanks

El dom, 10 ene 2021 a las 23:02, Agustin Martin
() escribió:
>
> El dom, 10 ene 2021 a las 22:39, Robert Luberda () 
> escribió:
> >
> > reassign 979549 ispell 3.4.01-1
> > reassign 979565 ispell 3.4.01-1
> > forcemerge 979575 979549 979565
> > affects 979575 ingerman iogerman ifrench iesperanto iswiss
> > tags 979575 pending fixed-upstream
> > thanks
> >
> >
> > Roland Rosenfeld pisze:
> > >
> > > In the meantime upstream maintainer released a version 3.4.02 on
> >
> > Yes, I've noticed it this morning, and it looks like upgrading to that
> > version fixes the issue.
>
> This may also be causing #979694.

Confirmed, ispell 3.4.02 fixes this problem.

Reassigning and forcemerging #979575 and #979746 with this bug report,
so everything is marked as fixed.

Regards,

-- 
Agustin

Bug#979575: ispell 3.4.01 breaks affix files of igerman98 and hkgerman

[Agustin Martin]

El dom, 10 ene 2021 a las 22:39, Robert Luberda () escribió:
>
> reassign 979549 ispell 3.4.01-1
> reassign 979565 ispell 3.4.01-1
> forcemerge 979575 979549 979565
> affects 979575 ingerman iogerman ifrench iesperanto iswiss
> tags 979575 pending fixed-upstream
> thanks
>
>
> Roland Rosenfeld pisze:
> >
> > In the meantime upstream maintainer released a version 3.4.02 on
>
> Yes, I've noticed it this morning, and it looks like upgrading to that
> version fixes the issue.

This may also be causing #979694.

Regards,

Bug#964678: dictionaries-common: FTBFS: Can't locate TheWML/Backends/Slice/Main.pm in @INC

[Agustin Martin]

control: reassign -1 slice
control: found -1 2.28.0~ds1-1
control: retitle -1 wml/slice must depend on wml package

El jue., 9 jul. 2020 a las 13:36, Lucas Nussbaum () escribió:
>
> Source: dictionaries-common
> Version: 1.28.1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200709 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This seems due to new slice package built from wml missing a
dependency on wml. Reassigning

> Relevant part (hopefully):
> > make[1]: Entering directory '/<>'
> > slice -oUNDEF+I+IW+IA-A-H-W-AH:scripts/maintainer/config-ispell 
> > scripts/maintainer/config.in
> > Can't locate TheWML/Backends/Slice/Main.pm in @INC (you may need to install 
> > the TheWML::Backends::Slice::Main module) (@INC contains: /usr/share/wml 
> > /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.30.3 
> > /usr/local/share/perl/5.30.3 /usr/lib/x86_64-linux-gnu/perl5/5.30 
> > /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
> > /usr/lib/x86_64-linux-gnu/perl/5.30 /usr/share/perl/5.30 
> > /usr/local/lib/site_perl) at /usr/bin/slice line 10.
> > BEGIN failed--compilation aborted at /usr/bin/slice line 10.
> > make[1]: *** [Makefile:147: scripts/maintainer/config-ispell] Error 2
>
> The full build log is available from:
>
> http://qa-logs.debian.net/2020/07/09/dictionaries-common_1.28.1_unstable.log
>
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
>
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

Bug#952426: digikam: digkam experimental not correctly instalable

[Agustin Martin]

On Mon, Feb 24, 2020 at 01:07:40PM +0100, Eric Valette wrote:
> On 24/02/2020 12:57, Agustin Martin wrote:
> 
> > Hi,
> > 
> > According to https://packages.debian.org/source/experimental/hdf5 there is a
> > new "libhdf5-hl-100" package in experimental. Looking into it, seems that
> > libhdf5_serial_hl.so.100 has been moved there, so installing that new 
> > package
> > should help in experimental. I still wonder what is pulling it during build.
> 
> 
> Except that if you llok at the beginning of the bug report it cannot be
> installed in conjunction with digikam. That why I opened this new bug.

Sorry, I missed that,

I may be wrong, but after a quick glance, that problem in experimental
seems likely related to the hdf5 transition to the new schema, not to
digikam itself.

IMHO libhdf5-103 should not have been dropped in experimental. It should
have instead become a transitional package depending on packages with its
previous contents, those having properly versioned breaks. That would make
the system work and allow dependencies to be upgraded later (although this
last should not be done in experimental). This addresses your 2) and 3)
points in your reply to Steve,

> As other have pointed out, it works but remains
> ...
>   2) If I do and experimental update it start failing again,
>   3) as soon as libhdf-103 hits unstable, the problem will reappear,

There is still the problem of the undeclared digikam dependency on the
hdf5 stuff.

Regards,

-- 
Agustin

Bug#952360: [xml/sgml-pkgs] Bug#952360: linuxdoc-tools: FTBFS: fmt_latex2e::postASP: LaTeX first run problem. Aborting ...

[Agustin Martin]

Control: affects 952460 -1
Control: tags -1 +pending

On Sun, Feb 23, 2020 at 02:47:12PM +0100, Lucas Nussbaum wrote:
> Source: linuxdoc-tools
> Version: 0.9.73-2
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> Relevant part (hopefully):
> > make[2]: Entering directory '/<>/doc'
> > - Building txt docs
> > /tmp/ldt.p976T7wYPZ/linuxdoc --backend=txt --filter --blanks=1 guide.sgml
> > Processing file guide.sgml
> > troff: :2261: warning [p 1, 226.0i]: can't break line
> > - Building pdf docs
> > /tmp/ldt.p976T7wYPZ/linuxdoc --backend=latex \
> > --output=pdf \
> > --pass="\usepackage{times}" guide.sgml
> > Processing file guide.sgml
> > fmt_latex2e::postASP: LaTeX first run problem. Aborting ...
> > make[2]: *** [Makefile:9: guide.pdf] Error 1

Hi, Lucas,

Thanks for pointing out this problem.

This is caused by a rearrangement in contents of texlive packages. This
results in missing "letltxmacro.sty", which triggers the error. Missing
style now lives in "texlive-latex-extra", but is required by "hyperref.sty",
a style in "texlive-latex-base" which should not, IMHO, require styles
outside "texlive-latex-base".

I have filed #952460 against texlive-latex-base to make this known to
texlive maintainers. Depending on their reply this will be fixed either in
texlive with a new relocation or in linuxdoc-tools (by means of an additional
Build-Depends on texlive-latex-extra, now has only texlive-latex-recommended).

In the meantime I am marking this bug as pending.

Regards,

-- 
Agustin

Bug#952426: digikam: digkam experimental not correctly instalable

[Agustin Martin]

On Mon, Feb 24, 2020 at 11:38:40AM +0100, Eric Valette wrote:
> On 24/02/2020 10:50, Simon Frei wrote:
> 
> > The error message you quote refers to so-version 100, while the required
> > one is 103. That suggests you aren't running the digikam binary from the
> > package, but something else (maybe you self-compiled at some point?).
> > Check the output of which digikam.
>
> Did you just test your packages before uploading?
> 
>  ldd /usr/bin/digikam  | grep libhd
> libhdf5_serial.so.103 =>
> /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x7fd2c60f2000)
> libhdf5_serial_hl.so.100 => not found

Hi,

I think this should have triggered an error at build time. So digikam
probably built and installed well at that time.

> This bug has already been reported by me and fixed for 6.4

To be honest, it just disappeared for 6.4, bit I could not find an action
leading to that. According to "ldd -v /usr/bin/digikam" output digikam 5.9.0
had a dependency on libhdf5_serial_hl.so.100, but 6.4.0 does not. I may have
missed it, but I do not see any change on debian/control leading to this
change. Not to mention that it seems present again in experimental 7.0.

My guess is that digikam is being affected by some obscure dependency
changes in the build chain about the libhdf5 stuff and what is pulling it.
digikam seems to use this hdf5 stuff if present and not use it otherwise.
I wonder what is the benefit of using it, 6.4.0 works without it.

Regards,

PS: Like Simon, I am just tring to help triaging bug reports and make
maintenance easier for real maintainers.

-- 
Agustin

Bug#952426: digikam: digkam experimental not correctly instalable

[Agustin Martin]

On Mon, Feb 24, 2020 at 12:09:58PM +0100, Simon Frei wrote:
> On 24/02/2020 11:38, Eric Valette wrote:
> > On 24/02/2020 10:50, Simon Frei wrote:
> >
> >> one is 103. That suggests you aren't running the digikam binary from the
> >> package, but something else (maybe you self-compiled at some point?).
> >> Check the output of which digikam.
> >
> >
> > Did you just test your packages before uploading?
> >
> >  ldd /usr/bin/digikam  | grep libhd
> >     libhdf5_serial.so.103 =>
> > /usr/lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x7fd2c60f2000)
> >     libhdf5_serial_hl.so.100 => not found
> >
> Firstly: I don't upload digikam to debian. I am just a user interested
> in having it packaged and very occasional contributor upstream. By
> helping to triage and clarify bugs I hope to remove some workload from
> Steve (uploader), which hopefully makes it more likely to keep getting
> packages from him (thanks a lot for that!).
> 
> And my bad, apparently libhdf5-103 still ships the .100 lib:
> 
>     libhdf5-103: /usr/lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100
> 
> At least it does in testing. I now upgraded libhdf5-103 to experimental
> and I do get the same error you do. Maybe at the time the experimental
> build was done the old version of hdf5 was still in experimental. Anyway
> the fix for you is to downgrade libhdf5-103 to unstable and for the
> package probably as simple as a rebuild (which in my opinion isn't
> really necessary unless there's another change, e.g. beta3).

Hi,

According to https://packages.debian.org/source/experimental/hdf5 there is a
new "libhdf5-hl-100" package in experimental. Looking into it, seems that
libhdf5_serial_hl.so.100 has been moved there, so installing that new package
should help in experimental. I still wonder what is pulling it during build.

Regards,

-- 
Agustin

Bug#922574: digiKam FTBFS with OpenCV 4

[Agustin Martin]

On Fri, Jan 17, 2020 at 04:35:04PM +0100, Agustin Martin wrote:
> On Tue, Dec 10, 2019 at 01:55:50PM -0500, John Scott wrote:
> > Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=401306
> > 
> > This appears to have been fixed upstream. There are a couple patches there.
> 
> Hi all,
> 
> I have been playing with this problem and with changes in upstream bug
> report and I was finally able to make digikam 5.9.0 build in sid. 

Hi, Steve,

Thanks a lot for uploading digikam 6.4.0. Since this #922574 bug report was
not closed with it, I guess you want to give this upload an extended time
before testing migration.

Minimally tested but it is apparently fixing #918478 too.

Some other bug reports were filed for older digikam versions and may no
longer apply. Do you mind if I mail submitters to double check that before
closing those bug reports?

Thanks for your work in digikam.

Regards,

-- 
Agustin

Bug#922574: digiKam FTBFS with OpenCV 4

[Agustin Martin]

On Tue, Dec 10, 2019 at 01:55:50PM -0500, John Scott wrote:
> Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=401306
> 
> This appears to have been fixed upstream. There are a couple patches there.

Hi all,

I have been playing with this problem and with changes in upstream bug
report and I was finally able to make digikam 5.9.0 build in sid. 

I have prepared a personal build with those changes (it is minimally
tested, so is initially intended for my personal use), and I am attaching a
debdiff with the changes as well as individual patches under debian/patches
for clarity.

That personal build is apparently working for my preliminary tests and
is intended to fix both
  
  #922574 digikam: FTBFS against opencv 4
  #918478 digikam: ImageEditor window is blank when opened a second time

as well as a problem with libkf5calendar.

Steve, feel free to use these changes at your convenience. If needed I can
prepare a NMU, but I would appreciate some additional testing first.

Summary of the patches under debian/patches follow:

 * 0010_libopencv.h_update-for-opencv4-remove-obsolete-stuff.diff:
   Update libopencv.h.cmake.in for opencv4 and remove obsolete stuff.
   Based on upstream changes in https://bugs.kde.org/show_bug.cgi?id=401306.

 * 0011_facesengine_fix-openCV4-compilation.diff:
   Update for opencv4 (and some opencv3).
   Original patch by Gilles Caulier modified to deal with buster opencv
   (seems that it also needs to use cv::IMREAD_GRAYSCALE). Version should
   be fine tuned, but seems to work with both buster and sid.

 * 0020_calsettings.cpp_Fix-for-recent-libkf5calendarcore.diff:
   Fix calsettings.cpp for libkf5calendarcore-dev_4%3a19.08.3
   KCalCore namespace has been renamed to KCalendarCore. Just set a
   namespace alias to work around this.

   This will not work for buster libkf5calendarcore-dev_4%3a18.08.3.
   Comment that alias if a backport is needed.

 * 0030_fix-blank-imageeditor.patch:
   Fix ImageEditor window is blank when opened a second time (#918478)
   Changes borrowed from http://bugs.debian.org/918478

Please find attached above patches and the debdiff for my personal build.

Hope this helps

-- 
Agustin
From: Aguatin Martin 
Date: 20200117
Subject: Update libopencv.h.cmake.in for opencv4 and remove obsolete stuff

Based on changes by Gilles Caulier for recent digikam.

--- a/core/app/utils/libopencv.h.cmake.in
+++ b/core/app/utils/libopencv.h.cmake.in
@@ -49,35 +49,26 @@
 #define OPENCV_VERSION OPENCV_MAKE_VERSION(CV_MAJOR_VERSION,CV_MINOR_VERSION,CV_SUBMINOR_VERSION)
 #define OPENCV_TEST_VERSION(major,minor,patch) ( OPENCV_VERSION < OPENCV_MAKE_VERSION(major,minor,patch) )
 
-#if OPENCV_TEST_VERSION(2,5,0)
-#   include 
-#   include 
-#   include 
-#   include 
-#else
-#   include 
-#   include 
-#   include 
-#   include 
-#endif
+// Core module headers
 
-#if OPENCV_TEST_VERSION(3,0,0)
-#   include 
-#   include 
-#   include 
-#else
-#   include 
 #   include 
 #   include 
 #   include 
+#include 
+#include 
+
+// Object detection module headers
+
+#include 
+
+// Image codecs module headers
+
 #   include 
-#   include 
-#endif
 
-// for old-style code
-#if OPENCV_VERSION <= OPENCV_MAKE_VERSION(2,4,99)
-#   include 
-#endif
+// Image processing module headers
+
+#include 
+#include 
 
 // Restore warnings
 #if !defined(__APPLE__) && defined(__GNUC__)
>From 7a5af66d8fc7ab8e78f05016eaf3e94de66951b3 Mon Sep 17 00:00:00 2001
From: Gilles Caulier 
Date: Fri, 15 Mar 2019 17:16:06 +0100
Subject: fix broken compilation with OpenCV4 in Test::FaceEngine CCBUGS:
 401306

Modified by Agustin martin to lower version in OPENCV test to (2,99,0)
Was (3,99,0), but buster opencv version is lower and already needs
this change.

---
 core/tests/facesengine/preprocess.cpp | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/core/tests/facesengine/preprocess.cpp
+++ b/core/tests/facesengine/preprocess.cpp
@@ -63,7 +63,13 @@ QList toImages(const QStringLis
 foreach (const QString& path, paths)
 {
 QByteArray s = path.toLocal8Bit();
-images << cv::imread(std::string(s.data()), CV_LOAD_IMAGE_GRAYSCALE);
+images << cv::imread(std::string(s.data()),
+#if OPENCV_TEST_VERSION(2,99,0)
+CV_LOAD_IMAGE_GRAYSCALE
+#else
+cv::IMREAD_GRAYSCALE
+#endif
+);
 }
 
 return images;
--- a/core/libs/facesengine/detection/opencvfacedetector.cpp
+++ b/core/libs/facesengine/detection/opencvfacedetector.cpp
@@ -366,7 +366,7 @@ void OpenCVFaceDetector::updateParameter
  * unless in we want very high sensitivity at low speed
  */
 if (d->sensitivityVsSpecificity > 0.1 || d->speedVsAccuracy < 0.9)
-d->primaryParams.flags = CV_HAAR_DO_CANNY_PRUNING;
+d->primaryParams.flags = cv::CASCADE_DO_CANNY_PRUNING;
     else
 d->primaryParams.flags = 0;
 
From: Agustin Martin 
Date: 20200117
Subject: Fix c

Bug#944249: [Pkg-emacsen-addons] Bug#944249: gnuplot-mode does not work with emacs26

[Agustin Martin]

On Mon, Nov 18, 2019 at 07:28:45AM -0400, David Bremner wrote:
> Dima Kogan  writes:
> 
> > Thanks for the patches, Agustin. I just tried it out. Works for the most
> > part. One thing that doesn't work for me is (gnuplot-mode) being
> > executed when opening a .gp file. You added this to the package, and the
> > dh-elpa machinery is creating the appropriate file:
> >
> >   /etc/emacs/site-start.d/50elpa-gnuplot-mode.el
> >
> > I don't think this is being evaluated, however. Is it working for you?
> 
> That's not loaded by elpa packages.
> 
> The general approach is to add an autoload cookie to set
> auto-mode-alist. See "HINTS" in dh_elpa(1). Of course the usual cautions
> about auto-mode-alist apply, in particular there's no nice way to resolve
> conflicts with other packages (e.g. pari-gp) that might want to use the
> same suffix.

Hi,

I have been thinking about this and I see a problem with the elpa way of
handling prefix auto-mode-alist associations. They go to a file that is not
a conffile. So, if that kind of conflicts appear it is not as easy to
handle as just editing one of the conffiles and commenting the undesired
association.

Regards,

-- 
Agustin

Bug#944249: [Pkg-emacsen-addons] Bug#944249: gnuplot-mode does not work with emacs26

[Agustin Martin]

On Mon, Nov 18, 2019 at 08:30:46AM -0400, David Bremner wrote:
> Agustin Martin  writes:
> 
> > Hi, David,
> >
> >> That's not loaded by elpa packages.
> >
> > But AFAIK it should be loaded by Emacs,
> 
> Perhaps. Team packages don't use these startup files anymore. Most of
> the content (updating load paths in particular) is handled more reliably
> by package.el generated autoload files.
> 
> >> The general approach is to add an autoload cookie to set
> >> auto-mode-alist. See "HINTS" in dh_elpa(1). 
> >
> > I was looking at it and noticed the autoloads part, but nothing about
> > `auto-mode-alist'. Where is it?
> >
> 
> See "Other customizations"

Thanks for insisting, it was not clear to me after a quick read.

I am attaching a patch to replace

[0003-elpa-gnuplot-mode.emacsen-startup-Add-auto-mode-alis.patch]

doing things the elpa way.

-- 
Agustin
>From 74c09c964923c9119546aba0cd59cd56b40acb76 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Mon, 18 Nov 2019 16:07:16 +0100
Subject: [PATCH] debian/debian-autoloads.el: Handle auto-mode-alist stuff the
 elpa way.

---
 debian/debian-autoloads.el| 2 ++
 debian/elpa-gnuplot-mode.elpa | 1 +
 2 files changed, 3 insertions(+)
 create mode 100644 debian/debian-autoloads.el

diff --git a/debian/debian-autoloads.el b/debian/debian-autoloads.el
new file mode 100644
index 000..e2c1d6d
--- /dev/null
+++ b/debian/debian-autoloads.el
@@ -0,0 +1,2 @@
+;;;###autoload
+(setq auto-mode-alist (append '(("\\.gp\\'" . gnuplot-mode)) auto-mode-alist))
diff --git a/debian/elpa-gnuplot-mode.elpa b/debian/elpa-gnuplot-mode.elpa
index cd726c7..3e61da9 100644
--- a/debian/elpa-gnuplot-mode.elpa
+++ b/debian/elpa-gnuplot-mode.elpa
@@ -2,3 +2,4 @@ gnuplot.el
 gnuplot-gui.el
 gnuplot-context.el
 debian/gnuplot-mode-pkg.el
+debian/debian-autoloads.el
-- 
2.24.0

Bug#944249: [Pkg-emacsen-addons] Bug#944249: gnuplot-mode does not work with emacs26

[Agustin Martin]

On Mon, Nov 18, 2019 at 07:28:45AM -0400, David Bremner wrote:
> Dima Kogan  writes:
> 
> > Thanks for the patches, Agustin. I just tried it out. Works for the most
> > part. One thing that doesn't work for me is (gnuplot-mode) being
> > executed when opening a .gp file. You added this to the package, and the
> > dh-elpa machinery is creating the appropriate file:
> >
> >   /etc/emacs/site-start.d/50elpa-gnuplot-mode.el
> >
> > I don't think this is being evaluated, however. Is it working for you?
> 

Hi, David,

> That's not loaded by elpa packages.

But AFAIK it should be loaded by Emacs,

> The general approach is to add an autoload cookie to set
> auto-mode-alist. See "HINTS" in dh_elpa(1). 

I was looking at it and noticed the autoloads part, but nothing about
`auto-mode-alist'. Where is it?

> Of course the usual cautions
> about auto-mode-alist apply, in particular there's no nice way to resolve
> conflicts with other packages (e.g. pari-gp) that might want to use the
> same suffix.

By the way, previous emacsen-startup file also used the .gnuplot extension.

Regards,

-- 
Agustin

Bug#944249: gnuplot-mode does not work with emacs26

[Agustin Martin]

On Sun, Nov 17, 2019 at 10:52:47PM -0800, Dima Kogan wrote:
> Thanks for the patches, Agustin. I just tried it out. Works for the most
> part. One thing that doesn't work for me is (gnuplot-mode) being
> executed when opening a .gp file. You added this to the package, and the
> dh-elpa machinery is creating the appropriate file:
> 
>   /etc/emacs/site-start.d/50elpa-gnuplot-mode.el
> 
> I don't think this is being evaluated, however. Is it working for you?

Hello, thanks for looking at this.

It is working for me. I reviewed again my ~/.emacs file and did not see
anything active that may mess up with this.

> Do you know at which point in the emacs startup sequence this is
> sourced? 

In my box, Emacs messages buffer shows

...
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50elpa-gnuplot-mode.el (source)...done
Loading /etc/emacs/site-start.d/50flim.el (source)...done
...

> Is it always supposed to be sourced? What about 'emacs -q'? Or
> 'emacs -Q'?

That snippet will not always be sourced,

It will not be sourced with "emacs -Q" or "emacs --no-site-file"

It will be sourced with "emacs --q", but I get an error here

...
Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)...done
Loading /etc/emacs/site-start.d/50elpa-gnuplot-mode.el (source)...done
Loading /etc/emacs/site-start.d/50flim.el (source)...done
...
File mode specification error: (void-function gnuplot-mode)
...

Another thing. It is probably too late for this, but I tried gnuplot-mode
for XEmacs (unsupported by elpa). Just needed to add a couple of lines with
a compatibility function

  (eval-and-compile ;; Protect against declare-function undefined in XEmacs
(unless (fboundp 'declare-function) (defmacro declare-function ( r

and load .el files manually to have it working. No apparent problems in my
quick test (plotting sin(x)). I wonder if gnuplot-mode should have
preserved XEmacs compatibility and thus not migrate to elpa. Anyhow, seems
that nobody complained and even I had to install XEmacs just for this check,
so this seems no longer an issue.

Regards,

-- 
Agustin

Bug#944249: gnuplot-mode does not work with emacs26

[Agustin Martin]

El jue., 7 nov. 2019 a las 2:57, Nicholas D Steeves
() escribió:
>
> Hi Olaf and Dima,
>
> Dima, if it's alright with you can I please take care of this bug?
> I've head I need an RC Bug NMU process for the "demonstrates skills
> and knowledge of process" section of my eventual DD application.

Sorry, I missed above part of your mesage. Just read the part below

> If Dima give the go-ahead I'll investigate if this would be approved
> for a stable update.  It seems like it would be, because RC bugs like
> this aren't supposed to be solved using backports.

and thought you were someone helping the ftpmaster team and knowing
about their procedures.

Since I already sent some patches, they can be a starting point for
your work. Feel free to modify them at your convenience.

Regards,

-- 
Agustin

Bug#944249: gnuplot-mode does not work with emacs26

[Agustin Martin]

On Wed, Nov 06, 2019 at 09:44:59PM -0800, Dima Kogan wrote:
> Hi.
> 
> It looks like the elpa-gnuplot-mode package is missing some of the
> debiany emacs machinery: the files in
> 
>   /usr/lib/emacsen-common/packages/...
> 
> Somebody should look at the packaging, and figure out what we're missing
> and add it. Likely it's just a line or two somewhere.

Hi,

Having played with gnuplot-mode before (but not with elpa) I have been
digging into this problem, which is not Emacs26 related.

Original problem seems to be a bogus hyphen in debian/rules that completely
disables the elpa machinery, so problem went undetected. It really took me
a while to spot this problem.

I also added a debian/gnuplot-mode-pkg.el file and fine tuned
elpa-gnuplot-mode.elpa to include it and be more selective regarding files
to install.

Once this is done I noticed that package did not pass the tests because
gnuplot package was missing at that time, so I added it to Build-Deps.

I finally added elpa-gnuplot-mode.emacsen-startup to keep the .gp -> gnuplot
mode association in Emacs auto-mode-alist.

I am attaching three git patches dealing with the above.

Hope they help

-- 
Agustin
>From 1c6e992136fb5c33f28ee74e6992387a9bfa91d0 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 8 Nov 2019 17:09:19 +0100
Subject: [PATCH 1/3] Modify to work better with elpa.

* debian/rules: Remove bogus hyphen
* debian/gnuplot-mode-pkg.el: Create
* debian/elpa-gnuplot-mode.elpa: Rename from gnuplot-mode.elpa and modify
  to include install contents and gnuplot-mode-pkg.el.
* debian/install: Remove. No longer needed.
---
 debian/elpa-gnuplot-mode.elpa | 4 
 debian/gnuplot-mode-pkg.el| 5 +
 debian/gnuplot-mode.elpa  | 1 -
 debian/install| 3 ---
 debian/rules  | 2 +-
 5 files changed, 10 insertions(+), 5 deletions(-)
 create mode 100644 debian/elpa-gnuplot-mode.elpa
 create mode 100644 debian/gnuplot-mode-pkg.el
 delete mode 100644 debian/gnuplot-mode.elpa
 delete mode 100644 debian/install

diff --git a/debian/elpa-gnuplot-mode.elpa b/debian/elpa-gnuplot-mode.elpa
new file mode 100644
index 000..cd726c7
--- /dev/null
+++ b/debian/elpa-gnuplot-mode.elpa
@@ -0,0 +1,4 @@
+gnuplot.el
+gnuplot-gui.el
+gnuplot-context.el
+debian/gnuplot-mode-pkg.el
diff --git a/debian/gnuplot-mode-pkg.el b/debian/gnuplot-mode-pkg.el
new file mode 100644
index 000..8b98b6e
--- /dev/null
+++ b/debian/gnuplot-mode-pkg.el
@@ -0,0 +1,5 @@
+(define-package
+  "gnuplot-mode"
+  "50"
+  "Emacs gnuplot mode"
+  nil)
diff --git a/debian/gnuplot-mode.elpa b/debian/gnuplot-mode.elpa
deleted file mode 100644
index abf136d..000
--- a/debian/gnuplot-mode.elpa
+++ /dev/null
@@ -1 +0,0 @@
-*.el
diff --git a/debian/install b/debian/install
deleted file mode 100644
index 4463e0a..000
--- a/debian/install
+++ /dev/null
@@ -1,3 +0,0 @@
-gnuplot.el usr/share/emacs/site-lisp/gnuplot-mode
-gnuplot-gui.el usr/share/emacs/site-lisp/gnuplot-mode
-gnuplot-context.el usr/share/emacs/site-lisp/gnuplot-mode
diff --git a/debian/rules b/debian/rules
index ffea5e3..bb43d84 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 %:
-	dh $@ --with-elpa
+	dh $@ --with elpa
 
 override_dh_auto_build:
 	$(if $(filter nodoc,$(DEB_BUILD_OPTIONS)),true,make -f Makefile.dst gpelcard.pdf)
-- 
2.24.0.rc1

>From a019516e49055cc424a624bf076874e2e3ee9e48 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 8 Nov 2019 17:26:14 +0100
Subject: [PATCH 2/3] debian/control: Build depend on gnuplot, to allow tests
 being actually passed.

---
 debian/control | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 8d96b1f..29411f8 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,11 @@ Section: lisp
 Priority: optional
 Maintainer: Debian Emacs addons team 
 Uploaders: Dima Kogan 
-Build-Depends: debhelper (>= 10), dh-elpa (>= 0.0.17), texlive-latex-base, texlive-latex-recommended
+Build-Depends: debhelper (>= 10),
+	   dh-elpa (>= 0.0.17),
+	   texlive-latex-base,
+	   texlive-latex-recommended,
+	   gnuplot
 Standards-Version: 4.3.0
 Vcs-Git: https://salsa.debian.org/debian/gnuplot-mode.git
 Vcs-Browser: https://salsa.debian.org/debian/gnuplot-mode
-- 
2.24.0.rc1

>From 0b7604f0e336f69f9b9bcb08a2e66dbf408b5dc3 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Fri, 8 Nov 2019 17:41:06 +0100
Subject: [PATCH 3/3] elpa-gnuplot-mode.emacsen-startup: Add auto-mode-alist
 entry for .gp->gnuplot-mode association.

Based on old one, but with path and autoload handling removed.
---
 debian/elpa-gnuplot-mode.emacsen-startup | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 debian/elpa-gnuplot-mode.emacsen-startup

diff --git a/debian/elpa-gnuplot-mode.emacsen-startup b/debian/elpa-gnuplot-mode.emacsen-startup

Bug#866472: Playing with a different approach for the color profiles

[Agustin Martin]

On Thu, Jul 11, 2019 at 06:26:49PM +0200, Xavi Drudis Ferran wrote:
> 
> that was the intention of this code in my debian/rules (probably misplaced) 
> 
>   python src/uc2/utils/rcc2py/rcc2py.py 
> /usr/share/color/icc/ghostscript/default_cmyk.icc 
> src/uc2/cms/cmyk_profile_rc.py
>   python src/uc2/utils/rcc2py/rcc2py.py /usr/share/color/icc/Gray.icc 
> src/uc2/cms/gray_profile_rc.py
>   python src/uc2/utils/rcc2py/rcc2py.py /usr/share/color/icc/sRGB.icc 
> src/uc2/cms/srgb_profile_rc.py
> # python src/uc2/utils/rcc2py/rcc2py.py ? 
> src/uc2/cms/display_profile_rc.py
>   python src/uc2/utils/rcc2py/rcc2py.py 
> /usr/share/color/icc/ghostscript/lab.icc src/uc2/cms/lab_profile_rc.py

Hi, Xavi,

Missed how important were these lines, sorry.

I finally had time to look again at this. I am beginning to think that
keeping color profiles obfuscated and turning them available on first
use is not the most convenient thing, so I played with other approach.

I have been playing with using built-in_%s.icm under ~/.config/uc2/profiles
if available, but global profiles otherwise. To make things simpler, I 
set symlinks with similar names from /usr/share/uniconvertor/profiles to
some of the profiles in libgs9-common, and modified code to use them, so the
*_profile_rc.py files could be removed from sources. I am not fluent with
color profiles, and for simplicity I used everything from a single package,
libgs9-common. Regarding display profile, people claim that it depends on
monitor and graphics card, so I simply set it to the RGB profile.

I am attaching a couple of files with current state of my experiments. I am
also not fluent with python (that is why I did not adopt or sponsored this
or any other python package), so my changes would definitely need review, if
considered.

A DEP5 copyright with file exclusion line is included, which should make
easier to create a DFSG free tarball.

Regards,

-- 
Agustin
Format: 3.0 (quilt)
Source: python-uniconvertor
Binary: python-uniconvertor
Architecture: any
Version: 2.0~rc4-1~amd1
Maintainer: Debian QA Group 
Homepage: https://sk1project.net/modules.php?name=Products=uniconvertor
Standards-Version: 4.4.0
Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1.1), dh-python, 
python-dev, python-cairo-dev, libcairo2-dev, liblcms2-dev, libpango1.0-dev, 
libmagickwand-6.q16-dev
Package-List:
 python-uniconvertor deb python optional arch=any
Checksums-Sha1:
 4ec122e9d066b339ab3aa4d745fb45505cf76ce8 1088298 
python-uniconvertor_2.0~rc4.orig.tar.gz
 fbb8eec9a014ebe1a7dd4009f27e7b8084a40d5b 7616 
python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz
Checksums-Sha256:
 98c32fa7255825cb5a395346f77bafa256d78a7b06093dbbb5f612e46371f045 1088298 
python-uniconvertor_2.0~rc4.orig.tar.gz
 a8460afa2cc4c56d10a032ef8f9699bcd8684e051f3a9df96d52dfebf907ab1b 7616 
python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz
Files:
 84efd5fa55ec8ebea0caaef4f3e0c5a3 1088298 
python-uniconvertor_2.0~rc4.orig.tar.gz
 0f786da922842c0ffad7a953a685025d 7616 
python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz


python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz
Description: application/xz


signature.asc
Description: PGP signature

Bug#866472: copyright extract script

[Agustin Martin]

On Thu, Jul 11, 2019 at 04:17:30PM +0200, Agustin Martin wrote:
> On Thu, Jul 11, 2019 at 04:02:13PM +0200, Xavi Drudis Ferran wrote:
> > 
> > I attach the script. It prints some (c) info on the *_rc.py files. 
> > You might need to change the uniconvertor directory in the script. 
> > And you may not really find it too enlightening...
> 
> Thanks a lot,
> 
> I was already looking at the files generated under
> ~/.config/uc2/profiles/ where those strings can also be guessed. I will look
> more carefully, but at least one of the color profiles seems non free (the
> HP one).

Hi again, Xavi

I was looking at the color profiles. Here goes a summary of what I found:

  * cmyk_profile_rc.py -> built-in_CMYK.icm

(Fogra27L.icc) Fogra27L CMYK Coated Press
(C) Richard Hughes 
Public Domain

  * display_profile_rc.py -> built-in_Display.icm

Contains this string:
No copyright. Created with dispcalGUI 1.1.2.9 and Argyll CMS 1.4.0 -M P244W 
-A Acer Technologies

Could get no more info about this profile

  * gray_profile_rc.py -> built-in_Grayscale.icm

This is the same as /usr/share/color/icc/Gray.icc, shipped in
icc-profiles-free package
 
Copyright (C) 2005-2008 Kai-Uwe Behrmann 
License: zlib/libpng License

  * lab_profile_rc.py -> built-in_LAB.icm

Seems similar (but not exact) to /usr/share/color/icc/LCMSXYZI.ICM,
shipped in icc-profiles-free package

Copyright (C) Marti Maria Saguer 1999
License: zlib/libpng License

  * srgb_profile_rc.py -> built-in_RGB.icm

Copyright (c) 1998 Hewlett-Packard Company

$ md5sum built-in_RGB.icm 
1d3fda2edb4a89ab60a23c5f7c7d81dd  built-in_RGB.icm

If you look at https://bugs.debian.org/699301 this is exactly the same
file that was reported as non-free. It is shipped as 
/usr/share/color/icc/sRGB.icm in non-free icc-profiles package.

Some Debian packages are currently shipping free color profiles, at least

icc-profiles-free
colord-data
libgs9-common

I wonder if some profile in those packages could help. I have no idea about
color profiles and such.

Regards,

-- 
Agustin

Bug#866472: copyright extract script

[Agustin Martin]

On Thu, Jul 11, 2019 at 04:02:13PM +0200, Xavi Drudis Ferran wrote:
> 
> I attach the script. It prints some (c) info on the *_rc.py files. 
> You might need to change the uniconvertor directory in the script. 
> And you may not really find it too enlightening...

Thanks a lot,

I was already looking at the files generated under
~/.config/uc2/profiles/ where those strings can also be guessed. I will look
more carefully, but at least one of the color profiles seems non free (the
HP one).

Regards,

-- 
Agustin

Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs

[Agustin Martin]

On Fri, Jul 05, 2019 at 10:50:08PM +0200, Xavi Drudis Ferran wrote:
> Well, for what is worth here're the files for a package that builds
> and install on buster for uniconvertor-2.0rc4. But I haven't
> tested. Only did a sg to pdf conversion once. I may have done
> lots of things wrong, of course.
> 
> So far it does no seem to require sk1libs. 

Hi, Xavi,

Thanks for your work.

I was doing some work in parallel about how to build uniconvertor 2.0rc4
and learn something about packaging python stuff. I am attaching the
current status of what I did. Note that I changed upstream version to
2.0~rc4 to keep proper version sorting in Debian.

I only needed to use your reportlab patch.

I am trying to guess if there is some license info about the color profiles.
Will let you know.

Regards,

-- 
Agustin


python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz
Description: application/xz
Format: 3.0 (quilt)
Source: python-uniconvertor
Binary: python-uniconvertor
Architecture: any
Version: 2.0~rc4-1~amd1
Maintainer: Debian QA Group 
Homepage: https://sk1project.net/modules.php?name=Products=uniconvertor
Standards-Version: 4.3.0
Build-Depends: debhelper (>= 11), dpkg-dev (>= 1.16.1.1), dh-python, 
python-dev, python-cairo-dev, libcairo2-dev, liblcms2-dev, libpango1.0-dev, 
libmagickwand-6.q16-dev
Package-List:
 python-uniconvertor deb python optional arch=any
Checksums-Sha1:
 4ec122e9d066b339ab3aa4d745fb45505cf76ce8 1088298 
python-uniconvertor_2.0~rc4.orig.tar.gz
 ede0259f13ddc37f4032770fc83682b6cacdb078 5976 
python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz
Checksums-Sha256:
 98c32fa7255825cb5a395346f77bafa256d78a7b06093dbbb5f612e46371f045 1088298 
python-uniconvertor_2.0~rc4.orig.tar.gz
 50f5d7b21f472d374073bff6750f2a60c61a08aa7a35be0eb385e2634c5c804f 5976 
python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz
Files:
 84efd5fa55ec8ebea0caaef4f3e0c5a3 1088298 
python-uniconvertor_2.0~rc4.orig.tar.gz
 db098ede59dea3a284fc9239d3271cb6 5976 
python-uniconvertor_2.0~rc4-1~amd1.debian.tar.xz

Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs

[Agustin Martin]

On Thu, Jun 27, 2019 at 04:07:53PM +0200, Agustin Martin wrote:
> On Fri, Jun 21, 2019 at 07:24:15AM +0200, Xavi Drudis Ferran wrote:
> > 
> > Hello. Maybe you know already (because the problem seems to be lack of 
> > maintainer). But there is a python-uniconvertor 2.0 that no longer depends 
> > on python-imaging but on python-pil (python2, I believe)
> > 
> > https://sk1project.net/modules.php?name=Products=uniconvertor=download
> 
> Hi,
> 
> Even if that dependency is declared, python-uniconvertor in Debian does
> not really depend on python-imaging, but on a copy of it embedded as
> sk1libs.imaging in sk1libs, which is not in Debian.
> 
> The biggest problem is the lack of sk1libs, because there are some other
> functions that are required by uniconvertor as soon as you try to go
> beyond the usage message (See https://bugs.debian.org/820748).

By the way, some years ago I was playing with an old sk1libs version. 

Since I am not fluent with python I did not dare to prepare a real package
for Debian, but made available what I did. It is still in

  https://salsa.debian.org/agmartin/python-sk1libs

Some time ago it was cloned by someone from the Debian python team,

  https://salsa.debian.org/python-team/modules/python-sk1libs

but did not see much work apart from some cosmetic commits.

It no longer builds, but may be useful to someone working on it.

Regards,

-- 
Agustin

Bug#866472: Uniconvertor 2.0 upstream depends on python-pil and has some .debs

[Agustin Martin]

On Fri, Jun 21, 2019 at 07:24:15AM +0200, Xavi Drudis Ferran wrote:
> 
> Hello. Maybe you know already (because the problem seems to be lack of 
> maintainer). But there is a python-uniconvertor 2.0 that no longer depends on 
> python-imaging but on python-pil (python2, I believe)
> 
> https://sk1project.net/modules.php?name=Products=uniconvertor=download

Hi,

Even if that dependency is declared, python-uniconvertor in Debian does
not really depend on python-imaging, but on a copy of it embedded as
sk1libs.imaging in sk1libs, which is not in Debian.

The biggest problem is the lack of sk1libs, because there are some other
functions that are required by uniconvertor as soon as you try to go
beyond the usage message (See https://bugs.debian.org/820748).

I am not a python expert, but for the imaging part I would expect something
similar to attached patch to work. It changes dependency to python-pil and
tries to change calls to sk1libs.imaging stuff to the equivalent PIL calls.

Regards,

-- 
Agustin
>From eaac5ce28edcab4d022956f8a5eda171de521100 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo 
Date: Thu, 27 Jun 2019 15:51:09 +0200
Subject: [PATCH] Depend on python-pil instead of (fake) python-imaging.

 This package had a dependency on python-imaging but its real dependency
 was on sk1project sk1libs.imaging, a python-imaging copy embedded in
 sk1libs.

 This patch tries to change sk1libs.imaging calls to PIL, so dependency
 can be set to PIL.
---
 debian/changelog   |  8 +++
 debian/control |  2 +-
 debian/patches/05_sklibs.imaging2PIL.patch | 59 ++
 debian/patches/series  |  1 +
 4 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/05_sklibs.imaging2PIL.patch

diff --git a/debian/changelog b/debian/changelog
index 594905a..15be5f8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+python-uniconvertor (1.1.5-5) unstable; urgency=medium
+
+  * QA upload.
+  * Depend on python-pil instead of python-imaging (Really was on
+sk2libs.imaging) (Closes: #866472).
+
+ -- Agustin Martin Domingo   Thu, 27 Jun 2019 11:51:10 +0200
+
 python-uniconvertor (1.1.5-4) unstable; urgency=medium
 
   * QA upload.
diff --git a/debian/control b/debian/control
index c4e845c..f3703df 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Standards-Version: 3.9.8
 Package: python-uniconvertor
 Architecture: any
 Depends:
- python-imaging,
+ python-pil,
  python-reportlab,
  ${misc:Depends},
  ${python:Depends},
diff --git a/debian/patches/05_sklibs.imaging2PIL.patch b/debian/patches/05_sklibs.imaging2PIL.patch
new file mode 100644
index 000..9fa6921
--- /dev/null
+++ b/debian/patches/05_sklibs.imaging2PIL.patch
@@ -0,0 +1,59 @@
+Author: Agustin Martin Domingo 
+Description: Try using python-pil instead of python-imaging copy embedded in sk1libs.
+
+
+diff --git a/src/app/Graphics/eps.py b/src/app/Graphics/eps.py
+index e587323..bbd4103 100755
+--- a/src/app/Graphics/eps.py
 b/src/app/Graphics/eps.py
+@@ -21,7 +21,7 @@
+ 
+ import os, math
+ 
+-from sk1libs.imaging import Image
++from PIL import Image
+ 
+ from app.Lib import dscparser
+ from sk1libs import utils
+diff --git a/src/app/Graphics/graphics.py b/src/app/Graphics/graphics.py
+index 420f7d4..0f85051 100755
+--- a/src/app/Graphics/graphics.py
 b/src/app/Graphics/graphics.py
+@@ -29,7 +29,7 @@ from types import TupleType
+ import operator, string
+ from math import atan2, hypot, pi, sin, cos
+ 
+-from sk1libs import imaging
++import PIL as imaging
+ 
+ #from app.X11 import X
+ from app.conf import const
+diff --git a/src/app/Graphics/image.py b/src/app/Graphics/image.py
+index bcb7c05..dbfb518 100755
+--- a/src/app/Graphics/image.py
 b/src/app/Graphics/image.py
+@@ -24,8 +24,8 @@
+ import os, app
+ from types import StringType
+ 
+-from sk1libs.imaging import ImageChops
+-from sk1libs import imaging
++import PIL as imaging
++from imaging import ImageChops
+ 
+ from app import _, RegisterCommands, colormanager
+ #from app.UI.command import AddCmd
+diff --git a/src/app/scripts/export_raster.py b/src/app/scripts/export_raster.py
+index e548c6c..a92a51d 100755
+--- a/src/app/scripts/export_raster.py
 b/src/app/scripts/export_raster.py
+@@ -37,7 +37,8 @@
+ 
+ import os, tempfile
+ 
+-from sk1libs import imaging.Image, imaging.ImageChops
++from PIL import Image as imaging.Image
++from PIL import ImageChops as imaging.ImageChops
+ 
+ import app.Scripting
+ from app import _, PostScriptDevice
diff --git a/debian/patches/series b/debian/patches/series
index bb5d10b..33e36f8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 02_fake_fallback_font.patch
 03_fontwarning.patch
+05_sklibs.imaging2PIL.patch
-- 
2.20.1

Bug#908681: libsane1: nothing provides libsane so xsane uninstallable

[Agustin Martin]

On Wed, Oct 03, 2018 at 10:25:31AM +1300, Ben Caradoc-Davies wrote:
> The removal of "Provides: libsane" in libsane1 1.0.27-2 makes xsane
> uninstallable because nothing provides libsane.

Hi all,

I am aware that keeping "libsane" name with "Provides: libsane1" is under
consideration. 

In case that is not finally decided and current status is preserved, should
not sane-backends provide a libsane transitional package? Something like

Package: libsane
Section: oldlibs
Priority: extra
Architecture: all
Depends:
 libsane1,
 ${misc:Depends}
Description: Transitional package for easier upgrade to libsane1
 This is a dummy transitional package to smooth upgrade to libsane1.
 .
 It can be safely removed afterwards.

Regards,

-- 
Agustin

Bug#908081: auctex: no longer autoloads with emacs >= 1:25.2+1-11

[Agustin Martin]

On Mon, Sep 17, 2018 at 05:06:33PM +0300, Adrian Bunk wrote:
> Control: severity -1 serious
> 
> On Mon, Sep 10, 2018 at 05:54:07PM +0200, Agustin Martin wrote:
> > On Wed, Sep 05, 2018 at 11:13:29PM +0100, Julian Gilbey wrote:
> > > Package: auctex
> > > Version: 11.91-1
> > > Severity: important
> > > Tags: patch
> > > 
> > > With the recent upgrade of emacs to the non-numbered package names,
> > > emacs25 is now just a transitional package.  As a result, the
> > > debian-emacs-flavor is just "emacs", so the test on line 7 of
> > > /etc/emacs/site-start.d/50auctex.el fails and the package is not
> > > autoloaded.
> > > 
> > > Patch: add "emacs" to this list, so that it reads:
> > > 
> > > (if (member debian-emacs-flavor '(emacs24 emacs25 emacs-snapshot emacs))
> 
> IMHO this is release critical, feel free to downgrade again if you 
> disagree.
> 
> >...
> > If you want auctex to be installable only in unversioned Emacs, things are
> > simple, just remove all the symlinks stuff and leave emacs as the only
> > option in /etc/emacs/site-start.d/50auctex.el and the install/remove
> > scripts. 

Hi all,

Forgot that you may still need to keep symlinks to .el files under the style
dir.
 
> > If you want it to work for older releases you will need to be more careful,
> > since for unversioned Emacs sources and byte-compile dirs are the same, and
> > symlinks will fail. You will need to add some checks to prevent this. 
> >...
> 
> Is this actually required?

No, this would only be usefull for backports, it is probably an overkill.

Regards,

-- 
Agustin

Bug#872712: [Parl-devel] Bug#872712: debian-parl: please remove transitional packages myspell-{af, en-gb, en-za, it, ky, sl, sw, th} and use hunspell-* instead

[Agustin Martin]

On Mon, Sep 25, 2017 at 06:20:02PM +0200, Agustin Martin wrote:
> On Mon, Aug 21, 2017 at 10:04:03AM +0200, Mattia Rizzolo wrote:
> > On Mon, Aug 21, 2017 at 02:33:02AM +0200, Jonas Smedegaard wrote:
> > > I will address this, but it may take time before I come around to it.
> > > 
> > > Please do go ahead with removal of the reverse dependency (at least from 
> > > testing): debian-parl is currently kicked from testing for other 
> > > reasons.
> > 
> > Ok, we will go ahead and remove them at the first occasion breaking
> > debian-parl.
> 
> Hi,
> 
> Just to note that myspell-ca dependency should also be changed to
> hunspell-ca. Andreas already changed bug title about this.

Hi, Jonas,

This part is still pending. 

> hunspell-ca package without myspell-ca has already been uploaded. However
> it cannot migrate to testing because of debian-parl dependency on
> myspell-ca (See #876732, myspell-ca cannot be removed from sid). 

Thanks in advance,

-- 
Agustin

Bug#872712: [Parl-devel] Bug#872712: debian-parl: please remove transitional packages myspell-{af, en-gb, en-za, it, ky, sl, sw, th} and use hunspell-* instead

[Agustin Martin]

On Mon, Aug 21, 2017 at 10:04:03AM +0200, Mattia Rizzolo wrote:
> On Mon, Aug 21, 2017 at 02:33:02AM +0200, Jonas Smedegaard wrote:
> > I will address this, but it may take time before I come around to it.
> > 
> > Please do go ahead with removal of the reverse dependency (at least from 
> > testing): debian-parl is currently kicked from testing for other 
> > reasons.
> 
> Ok, we will go ahead and remove them at the first occasion breaking
> debian-parl.

Hi,

Just to note that myspell-ca dependency should also be changed to
hunspell-ca. Andreas already changed bug title about this.

hunspell-ca package without myspell-ca has already been uploaded. However
it cannot migrate to testing because of debian-parl dependency on
myspell-ca (See #876732, myspell-ca cannot be removed from sid). 

Mattia, until debian-parl is fixed you may have the same problem with
the othet dicts from libreoffice-dictionaries, (unfortunately, I did
not test in advance for this side effect of myspell-ca removal).

Regards,

-- 
Agustin

Bug#853320: fix GCC7 build failure

[Agustin Martin]

Control: tags -1 + pending

On Sat, Aug 12, 2017 at 07:13:50PM -0400, Matthias Klose wrote:
> Control: tags -1 + patch
> 
> patch at
> http://launchpadlibrarian.net/333055957/aspell_0.60.7~20110707-3build2_0.60.7~20110707-3ubuntu1.diff.gz

Thanks for the pointer. Will care of this.

-- 
Agustin

Bug#860893: src:softcatala-spell should stop building myspell-ca

[Agustin Martin]

Control: tag -1 + pending

On Fri, Apr 21, 2017 at 04:00:58PM +0300, Adrian Bunk wrote:
> Source: softcatala-spell
> Version: 0.20111230b-9
> Severity: important
> 
> Holger Levsen noticed:
> myspell-ca | 0.20111230b-9   | unstable| all
> myspell-ca | 3.0.1+repack1-3 | testing | all
> myspell-ca | 3.0.1+repack1-3 | unstable| all
> 
> myspell-ca is now a transitional package in src:hunspell-ca,
> and should therefore no longer be built by src:softcatala-spell.

Hi, Adrian

Thanks for reminding. Some time ago we were in contact with ooo-dictionaries
maintainer about this. Since this is indeed harmless, although undesirable,
we did not give it a high priority. And time passed ...

> After discussing with the release team increasing severity to serious, 
> since this would result in stable updates of src:softcatala-spell to
> be rejected.

I was about to ask why this harmless thing could be serious, but if the
release team considers that it could cause any kind of problem I am fine
with it.

Jordi, I have started to drop myspell-ca from softcatala-spell and I think
work is mostly done. If you don't object, I will care of this.

I would have also liked to update vcs url and Standards-Version, but
considering the freeze I will leave this for later.

Regards,

-- 
Agustin

Bug#853916: encfs '-S' vulnerability

[Agustin Martin]

On Wed, Feb 01, 2017 at 09:36:47PM -0500, David Steele wrote:
> Package: encfs
> Version: 1.9.1-3
> Severity: serious
> thanks
> 
> 
> Recently, a change in Encfs was found to have broken cryptkeeper, causing it
> to use the password 'p' for all operations, regardless of user input 
> (#852751)[3].
> The bug was closed by removing cryptkeeper from Debian.
> 
> The issue, however, remains. Sirikali, which manages multiple userspace
> filesystems including Encfs, suffers from the same failure (#853874).
> An upstream Encfs representative has indicated that the problem will be fixed
> there [1], though no change has been pushed to date [2].

Seems that change has been pushed,

[Revert "-S" ABI change #282]
https://github.com/vgough/encfs/pull/282

including

[Revert "Fix a segfault when password is zero length.]
https://github.com/vgough/encfs/pull/282/commits/e9592fade4a452b189ffe10cc980f82115c75313

and

[Exit with a fatal error on empty password ]
https://github.com/vgough/encfs/pull/282/commits/5994b28542e7f551b71ac471ff9aacf6dcd5a3b0

-- 
Agustin

Bug#828293: encfs: FTBFS with openssl 1.1.0

[Agustin Martin]

On Sun, Jun 26, 2016 at 12:21:34PM +0200, Kurt Roeckx wrote:
> Source: encfs
> Version: 1.8.1-3
> Severity: important
> Control: block 827061 by -1
> 
> Hi,
> 
> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/encfs_1.8.1-3_amd64-20160529-1416
> 
> On https://wiki.openssl.org/index.php/1.1_API_Changes you can see various of 
> the
> reasons why it might fail.  There are also updated man pages at
> https://www.openssl.org/docs/manmaster/ that should contain useful 
> information.
> 
> There is a libssl-dev package available in experimental that contains a recent
> snapshot, I suggest you try building against that to see if everything works.
> 
> If you have problems making things work, feel free to contact us.

For the records, Debian package (1.8.1) is behind upstream (1.9.1),

  https://github.com/vgough/encfs/releases

This problem about building with OpenSSL 1.1.0 seems to have been
addressed upstream 11 days ago,

  https://github.com/vgough/encfs/pull/230

although apparently based on encfs 1.9.1, which has also been migrated
to cmake.

I have tried a build with new encfs 1.9.1, the two patches about openssl
1.1.0 applied, old patches disabled, cmake added to build-deps and
attached simplified debian/rules. At least it builds here with openssl
1.1.0, but it should really be looked carefully by maintainer, in case
something is wrong.

Hope this helps,

-- 
Agustin
#!/usr/bin/make -f

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk
include /usr/share/dpkg/architecture.mk

%:
dh $@

ifneq ($(DOENCFSTESTS),FORCE)
# needs configured fuse -> ignore
override_dh_auto_test:
true
endif

Bug#821995: ispell-czech: Build arch:all+arch:any but is missing build-{arch,indep} targets

[Agustin Martin]

Control: tag -1 + pending

On Mon, Jul 11, 2016 at 04:11:43PM +0200, Agustin Martin wrote:
> 
> On Wed, Apr 20, 2016 at 10:54:45PM +0200, ni...@thykier.net wrote:
> > Package: ispell-czech
> > Severity: normal
> > Usertags: arch-all-and-any-missing-targets

> Proposed patch attached. It is formatted as a NMU, as will soon be
> uploaded to the delayed queue if maintainer does not complain.

Uploaded to DELAYED/4. Please let me know if you want a longer delay.

Regards,

-- 
Agustin

Bug#821995: ispell-czech: Build arch:all+arch:any but is missing build-{arch,indep} targets

[Agustin Martin]

Control: tag -1 +patch

On Wed, Apr 20, 2016 at 10:54:45PM +0200, ni...@thykier.net wrote:
> Package: ispell-czech
> Severity: normal
> Usertags: arch-all-and-any-missing-targets
> 
> Hi,
> 
> The package ispell-czech builds an architecture independent *and* an
> architecture dependent package, but does not have the (now mandatory)
> "build-arch" and "build-indep" targets in debian/rules.
> 
> We would like to phase out the hacks in dpkg, which are currently
> needed to ensure that ispell-czech builds despite its lack of these
> targets.
> 
>  * Please add build-arch and build-indep targets to ispell-czech at
>your earliest convenience.
>- This can also be solved by using e.g. the "dh"-style rules.
> 
>  * The work around will be removed in the first dpkg upload after
>the 1st of June.  After that upload, ispell-czech will FTBFS if
>this bug has not been fixed before then.

Hi,

Proposed patch attached. It is formatted as a NMU, as will soon be
uploaded to the delayed queue if maintainer does not complain.

Regards,

-- 
Agustin
diff --git a/debian/changelog b/debian/changelog
index 6d670e1..acf6584 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ispell-czech (20040229-5.2) unstable; urgency=medium
+
+  * Non-Maintainer upload.
+  * Add missing build-{arch,indep} targets (Closes: #821995).
+
+ -- Agustin Martin Domingo <agmar...@debian.org>  Mon, 11 Jul 2016 15:36:58 +0200
+
 ispell-czech (20040229-5.1) unstable; urgency=low
 
   * Non-Maintainer upload.
diff --git a/debian/rules b/debian/rules
index 767d2f8..ad5d333 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,8 +5,11 @@
 
 package=iczech
 
-build:
-	dh_testdir
+build: build-arch build-indep
+build-arch: build-stamp
+build-indep: build-stamp
+build-stamp:
+	dh_testdir
 	make
 	(wc -l < czech.a-z; cat czech.a-z) > cs_CZ.mydic
 	ispellaff2myspell --charset=latin2 --myheader=debian/cs_CZ.myheader czech.aff > cs_CZ.myaff

Bug#814539: bzrtools: Uninstallable with current sid bzr and python-bzrlib (2.7.0-2)

[Agustin Martin]

Package: bzrtools
Version: 2.6.0-2
Severity: serious
Justification: uninstallable in sid

Dear Maintainer,

Seems that bzrtools needs upgrading for newer bzr package (2.7.0-2),

# LC_ALL=C apt-get install bzr python-bzrlib bzrtools
 ...
 bzrtools is already the newest version (2.6.0-2).
 ...
 The following packages have unmet dependencies:
  bzrtools : Depends: bzr (< 2.7.0) but 2.7.0-2 is to be installed

# dpkg-query -W bzr python-bzrlib
bzr 2.7.0~bzr6614-1
python-bzrlib   2.7.0~bzr6614-1


Regards,


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bzrtools depends on:
pn  bzrWrong: Really: 2.7.0~bzr6614-1, see above
ii  patch   2.7.5-1
ii  python  2.7.11-1

Versions of packages bzrtools recommends:
ii  rsync  3.1.1-3

Versions of packages bzrtools suggests:
ii  graphviz  2.38.0-12+b1
ii  librsvg2-bin  2.40.13-2

-- no debconf information

-- 
Agustin

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Agustin Martin]

Hi, Norbert,

On Fri, Jan 15, 2016 at 11:28:05PM +0900, Norbert Preining wrote:

> sorry for the late reply, and thanks for all your testing.
> 
> >  * debian/README.source: It is still about old dpatch.
> 
> removed.
> 
> >  * debian/gbp.conf: Should it be in the sources?
> 
> added.

Sorry, I did not explain myself well. I wondered if this should be something
associated to the local git repo or something to be committed to the public
git repo and put in debian xindy_2.5.1.20160104-1.debian.tar.xz sources. I
usually keep these files local inside .git, but others (teams ?) want that
in the git repo, so all commits from a cloned repo are consistent. Since you
are the maintainer, do as you prefer, I only wanted to warn in case it was
unintentional.

> > Did not find other issues, your xindy package really seems ready for
> > upload when you want. 
> 
> I have prepared a package ready to upload. Can you give it a last look,
> same location as before:
>   deb http://www.preining.info/debian/ xindy main
>   deb-src http://www.preining.info/debian/ xindy main
> version 2.5.1.20160104-1

Tested and working as well as previous version.

Just noticed yet another minor issue, Vcs-Git and Vcs-Browser still point to
Joerg Sommer's old git repo. This should probably point to new git repo
under Debian TeX maintainers control.

> I still hope that MIA which I have contacted quite some time ago
> will answer, but it is now quite some time, and no answer, so
> I will just upload, I guess, if you are fine.

Agreed. This way real life test starts sooner.

Thanks for caring about xindy.

-- 
Agustin

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Agustin Martin]

Hi, Norbert,

On Mon, Jan 04, 2016 at 01:35:22PM +0900, Norbert Preining wrote:
> 
> For those who are interested, here are preliminary packages
> of xindy 2.5.1 from TeX Live sources 20150104 (today):
> 
> deb http://www.preining.info/debian/ xindy main
> deb-src http://www.preining.info/debian/ xindy main
> 
> (amd64)
> 
> If someone can give it some tests that would be great.

Tested with one of my usual .idx and my usual style file. Seems to work
pretty well. 

Furthermore, with recent changes seems I no longer reproduce
http://sourceforge.net/p/xindy/bugs/57/. Not sure how, but seems that
recent texlive changes made this problem disappear.

Just a couple of minor issues,

 * debian/README.source: It is still about old dpatch.
 * debian/gbp.conf: Should it be in the sources?

Did not find other issues, your xindy package really seems ready for
upload when you want. 

Thanks a lot for your work and for caring about xindy.

Regards,

-- 
Agustin

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Agustin Martin]

On Wed, Jan 06, 2016 at 10:25:34PM +0100, Agustin Martin wrote:
> No. Just googled a bit and just found a message in the xindy-dev list
> commenting that it might require some work, but without reply from
> Joachim Schrod. Someone fluent with clisp and sbcl might however find
> it easier. I vaguely remember something about xindy needing ffi, but I
> think recent sbcl has it.

Going back into time, IIRC this was only for ancient xindy, using an
external non lisp regexp library. I think this is no longer needed since
clisp started shipping its own REGEXP module.

Not sure how many clisp'isms are still present.

Regards,

-- 
Agustin

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Agustin Martin]

2016-01-06 22:25 GMT+01:00 Agustin Martin <agmar...@debian.org>:
> 2016-01-04 0:43 GMT+01:00 Norbert Preining <prein...@logic.at>:
>
>> For those who are interested, here are preliminary packages
>> of xindy 2.5.1 from TeX Live sources 20150104 (today):
>>
>> deb http://www.preining.info/debian/ xindy main
>> deb-src http://www.preining.info/debian/ xindy main
>>
>> (amd64)
>>
>> If someone can give it some tests that would be great.
>
> Nice, will try to look at it once I find some time.

Quickly looking through the sources. I see that you already use
2.5.1+texlive. Great, thanks for the work. And just noticing that it
was my NMU what added the CPPFLAGS quoting problem :-(.

I  do not have tex related stuff in this box, so did not test in
depth, just looked at the sources. The only thing I noticed is that
http://sourceforge.net/p/xindy/bugs/57/ seems still present, but now
that sources are the texlive repo, it is probably better to fix it
there.

Will let you know once I test it better, although looking at the
sources things are apparently OK.

Regards,

-- 
Agustin

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Agustin Martin]

2016-01-04 0:43 GMT+01:00 Norbert Preining :
> Hi Agustin,
>
>> For the records, this summer (30/7/15) I also mailed Joerg about
>> current xindy status, but got no reply. My message might have been
>> unnoticed and I have been rather busy lately, so I did not retry.
>
> I did contact m...@debian.org for a take over of the xindy package.
> We can put it into collab-maint or into debian-tex, I don't mind
> any of it.

Hi, Norbert, do as you prefer.

By the way, when I prepared my two NMU I used a local git repo with
some local commits. May be those commits can be of interest to
preserve the history.

>> I also reminded him about xindy still using dpatch and about the
>> existence of newer upstream versions (up to 2.5.1).
>
> I first wanted to fix the current problems, then I will upgrade
> to last version.

FIne, I got newer versions from
http://mirrors.ctan.org/indexing/xindy/base/, sf seems outdated. I
first made the dpath->quilt migration and then upgraded first to 2.5.0
and then to 2.5.1. This is an extra work, but I wanted to preserve
versions history. Later noticed some extra commits in texlive svn
repo, but did not track them closely.

Newer xindy versions made some changes in build system. I have to find
my old git repo and make it available somewhere, at least to save some
extra work.

> Have you investigated whether using sbcl instead of clisp would work?
> clisp is dead, and sbcl is much more reliable and portable.

No. Just googled a bit and just found a message in the xindy-dev list
commenting that it might require some work, but without reply from
Joachim Schrod. Someone fluent with clisp and sbcl might however find
it easier. I vaguely remember something about xindy needing ffi, but I
think recent sbcl has it.

> For those who are interested, here are preliminary packages
> of xindy 2.5.1 from TeX Live sources 20150104 (today):
>
> deb http://www.preining.info/debian/ xindy main
> deb-src http://www.preining.info/debian/ xindy main
>
> (amd64)
>
> If someone can give it some tests that would be great.

Nice, will try to look at it once I find some time.

Regards,

-- 
Agustin

Bug#809053: xindy FTBFS due to CPPFLAGS containing spaces

[Agustin Martin]

2016-01-01 15:34 GMT+01:00 Norbert Preining :
> Dear Mattia,
>
>> debian/rules:33: recipe for target 'config.status-with-latex' failed
>
> Indeed, the last NMU has introduced a rather stupid bug.
>
> I have contacted the maintainer for a take over of xindy into the
> Debian TeX Team and have prepared already a new version with
> several other fixes, too.
>
> I am waiting for Jörg's answer before taking any action.

Hi, Norbert, Mattia and Joerg,

For the records, this summer (30/7/15) I also mailed Joerg about
current xindy status, but got no reply. My message might have been
unnoticed and I have been rather busy lately, so I did not retry.

I asked Joerg about current xindy status and suggested him to move
xindy git repo to collab-maint, so others can contribute better.

I also reminded him about xindy still using dpatch and about the
existence of newer upstream versions (up to 2.5.1).

I also had been playing a bit with xindy dpatch->quilt migration and
with upgrades to newer upstream versions (including a fix for a
problem still unaddressed by upstream,
http://sourceforge.net/p/xindy/bugs/57/). As a matter of fact I had
then a fully migrated and upgraded package nearly ready waiting for
Joerg reply.

I would be very happy to help with this all this migration and upgrade
if needed. I am aware that xindy main problem is current clisp status
(not sure if because of clisp itself or because of libsigsegv2), but
apart from fixing this FTBFS, kepping xindy up-to-date, even if only
possible for some arches, would be a good thing.

I have done some things with Emacs lisp, but never worked with clisp
nor common-lisp (apart from xindy styles), so I do not intend to adopt
xindy, at least as single maintainer, although I would not mind as a
co-maintainer, as I use xindy regularly and wrote some of the initial
spanish stuff. I could also help with the perl part if needed.

Best regards,

-- 
Agustin

Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer

[Agustin Martin]

On Thu, Nov 26, 2015 at 09:00:22AM +0530, Sebastian Dröge wrote:
> On Sa, 2015-11-21 at 17:06 +0100, Agustin Martin wrote:
> > 2015-11-14 15:25 GMT+01:00 Soeren D. Schulze <soeren.d.schu...@gmx.de
> > >:
> > > I am not sure about those SIGPIPEs.  They occured to me, too, but I
> > > could
> > > just press 'c' in gdb and continue using iceweasel until the
> > > SIGSEGV.  On
> > > the other hand, they are apparently gone now in stretch.
> > > 
> > > Could you press 'c' next time it happens, and wait for a SIGSEGV to
> > > occur?
> > 
> > Hi,
> > 
> > This time a SIGSEV did occur, please find attached backtrace
> 
> Hi,
> 
> this is a completely different crash than the one related to faad that
> was fixed in sid. 

Hi, thanks, for the info

I am remembering more about the original faad issue and failure was indeed
really inmediate when entering some pages. Not what is hapening in this
box.

> Do you have a way to reproduce the crash you're
> observing here?

Unfortunately not, I could not find a reproducible path to the problem,
once happened with facebook (at that time it looked reproducible, but when
looking next day at the entries apparently problmatic, everything went
fine), sometimes happens when accesing online journals, but is by far not
as inmediate as it happened with the faad issue. When this problem happens
I am already browsing the page after entering it. 

I will open a new bug report if I can find a reproducibility path. In the
mean time I think original gstreamer1.0-plugins-bad can be left for natural
archiving.

Regards, amd thaks again for all the feedback.

-- 
Agustin

Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer

[Agustin Martin]

2015-11-14 15:25 GMT+01:00 Soeren D. Schulze :
> I am not sure about those SIGPIPEs.  They occured to me, too, but I could
> just press 'c' in gdb and continue using iceweasel until the SIGSEGV.  On
> the other hand, they are apparently gone now in stretch.
>
> Could you press 'c' next time it happens, and wait for a SIGSEGV to occur?

Hi,

This time a SIGSEV did occur, please find attached backtrace
$ gdb --args iceweasel
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from iceweasel...Reading symbols from 
/usr/lib/debug//usr/lib/iceweasel/iceweasel...done.
done.
(gdb) set pagination off
(gdb) run
Starting program: /usr/bin/iceweasel 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe900a700 (LWP 4545)]
[Thread 0x7fffe900a700 (LWP 4545) exited]

(process:4541): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size 
== 0' failed
[New Thread 0x7fffe900a700 (LWP 4547)]
[New Thread 0x7fffe0eff700 (LWP 4548)]
[New Thread 0x7fffe06fe700 (LWP 4549)]
[New Thread 0x77f76700 (LWP 4550)]
[New Thread 0x77ef5700 (LWP 4551)]
[New Thread 0x76def700 (LWP 4552)]
[New Thread 0x7fffdfefd700 (LWP 4553)]
[New Thread 0x7fffdfaf3700 (LWP 4554)]
[New Thread 0x7fffde9ff700 (LWP 4555)]
[New Thread 0x7fffddd44700 (LWP 4556)]
[New Thread 0x7fffdd543700 (LWP 4557)]
[New Thread 0x7fffdfe6c700 (LWP 4558)]
[New Thread 0x7fffdc5ff700 (LWP 4559)]
[New Thread 0x7fffdb8ff700 (LWP 4560)]
[New Thread 0x7fffdb0fe700 (LWP 4561)]
[New Thread 0x7fffd9a41700 (LWP 4562)]
[New Thread 0x7fffd85ff700 (LWP 4563)]
[New Thread 0x7fffd7dfe700 (LWP 4564)]
[New Thread 0x7fffd6fff700 (LWP 4565)]
[New Thread 0x7fffd6bff700 (LWP 4566)]
[New Thread 0x7fffd61ff700 (LWP 4567)]
[Thread 0x7fffd6bff700 (LWP 4566) exited]
[New Thread 0x7fffd59fe700 (LWP 4568)]
[New Thread 0x7fffd6bff700 (LWP 4569)]
[New Thread 0x7fffd4eff700 (LWP 4570)]
console.error: 
  [CustomizableUI]
  Custom widget with id loop-button does not return a valid node
[New Thread 0x7fffd35ff700 (LWP 4571)]
console.error: 
  [CustomizableUI]
  Custom widget with id loop-button does not return a valid node
[New Thread 0x7fffd28ff700 (LWP 4572)]
[New Thread 0x7fffd20fe700 (LWP 4573)]
[New Thread 0x7fffd15ff700 (LWP 4574)]
[New Thread 0x7fffd0bff700 (LWP 4575)]
[New Thread 0x7fffd03fe700 (LWP 4576)]
[New Thread 0x7fffcfbfd700 (LWP 4577)]
[New Thread 0x7fffcf0ff700 (LWP 4578)]
[New Thread 0x7fffceefe700 (LWP 4579)]
[New Thread 0x7fffd6d48700 (LWP 4580)]
[New Thread 0x7fffcc988700 (LWP 4581)]
[New Thread 0x7fffcc187700 (LWP 4582)]
[New Thread 0x7fffcb6ff700 (LWP 4583)]
[New Thread 0x7fffca7ff700 (LWP 4584)]
[New Thread 0x7fffc9df1700 (LWP 4585)]
[New Thread 0x7fffc95f0700 (LWP 4586)]
[New Thread 0x7fffc8def700 (LWP 4587)]
[New Thread 0x7fffc81ff700 (LWP 4588)]
[New Thread 0x7fffc79fe700 (LWP 4589)]
[New Thread 0x7fffc6fff700 (LWP 4590)]
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[New Thread 0x7fffbdfff700 (LWP 4591)]
[New Thread 0x7fffb99ff700 (LWP 4592)]
[New Thread 0x7fffb82ff700 (LWP 4593)]
[New Thread 0x7fffb7afe700 (LWP 4594)]
[Thread 0x7fffb82ff700 (LWP 4593) exited]
[New Thread 0x7fffc7143700 (LWP 4595)]
[New Thread 0x7fffc6754700 (LWP 4596)]
[New Thread 0x7fffbd7fe700 (LWP 4597)]
[New Thread 0x7fffb82ff700 (LWP 4598)]
[New Thread 0x7fffb3c1c700 (LWP 4599)]
[New Thread 0x7fffaf1ff700 (LWP 4600)]
[New Thread 0x7fffad6e3700 (LWP 4601)]
[New Thread 0x7fffac6a9700 (LWP 4602)]
[New Thread 0x7fffbd79d700 (LWP 4603)]
[New Thread 0x7fffbd75c700 (LWP 4604)]
[New Thread 0x7fffaa7ff700 (LWP 4605)]
[New Thread 0x7fffb7269700 (LWP 4606)]
[New Thread 0x7fffa9ffe700 (LWP 4607)]
[New Thread 0x7fffa97fd700 (LWP 4608)]
[New Thread 0x7fffa8ffc700 (LWP 4609)]
[New Thread 0x7fffa87fb700 (LWP 4610)]
[New Thread 0x7fffa7ffa700 (LWP 4611)]
[New Thread 0x7fffabe78700 (LWP 4612)]
[New Thread 0x7fffa6eff700 (LWP 4613)]
[New Thread 0x7fffa4f46700 (LWP 4614)]
[Thread 0x7fffa4f46700 (LWP 4614) exited]
[New Thread 0x7fffa77f9700 (LWP 4616)]
[New Thread 0x7fffa4f46700 (LWP 4617)]
[New Thread 0x7fffa3fe7700 (LWP 4618)]
[New Thread 0x7fffa37e6700 (LWP 4619)]
[New Thread 0x7fffa2fe5700 (LWP 4620)]
[New Thread 0x7fffa27e4700 (LWP 4621)]
[New Thread 0x7fffa1fe3700 (LWP 4622)]

Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer

[Agustin Martin]

On Sat, Nov 14, 2015 at 03:25:49PM +0100, Soeren D. Schulze wrote:
> I am not sure about those SIGPIPEs.  They occured to me, too, but I could
> just press 'c' in gdb and continue using iceweasel until the SIGSEGV.  On
> the other hand, they are apparently gone now in stretch.
> 
> Could you press 'c' next time it happens, and wait for a SIGSEGV to occur?

Thanks for the info,

This was the first time I got a backtrace, so I naively stopped at
SIGPIPE.

Tried again, pressing 'c' after each SIGPIPE. That way I got a lot of
SIGPIPEs in a single debugging session, but no SIGSEGV happened.

Will try again next time I have access to that box, in case I am lucky.

-- 
Agustin

Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer

[Agustin Martin]

2015-11-12 16:13 GMT+01:00 Sebastian Dröge :
> On Do, 2015-11-12 at 15:35 +0100, Soeren D. Schulze wrote:
>> Am 12.11.2015 um 15:02 schrieb Sebastian Dröge:
>> > On Do, 2015-11-12 at 14:41 +0100, Soeren D. Schulze wrote:
>> > > Hello,
>> > >
>> > > the problem does not seem to occur any more with
>> > > gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr-1.
>> > >
>> > > Do you have any specific packages for me to test?
>> >
>> > Just a normal jessie installation without installing things from
>> > other
>> > sources, including sid :) It is definitely fixed since gst-plugins-
>> > bad
>> > 1.5.X, it's just not clear if the actual bug also exists in jessie
>> > or
>> > not (and if it doesn't, the fix will also have no effect for people
>> > who
>> > mix their packages with ones from other sources).
>>
>> I believe so.  I have had symptomatically similar crashes on two
>> different jessie systems, but I had not installed debugging symbols,
>> and it's hard to reproduce those crashes at command.
>
> It should crash always more or less immediately when you visit a
> website with AAC audio. Vimeo for example :)

I  am again in the problematic box and tried today with
http://www.vimeo.com. No failure, so I am a bit confused. Last weekend
I had a systematic failure when browsing facebook, but today it seems
to work well.

As a side note, this box has an onboard nvidia GeForce 6150SE graphics
engine, known to have serious problems with jessie's kernel, including
system freezes (see e.g. #758460), with some apparent connection with
iceweasel. As a matter of fact I am running sid kernel here to
mitigate that.

This means that there is a good alternative candidate for my iceweasel
failures. I still wonder why after installing plugins-bad with that
change the iceweasel+facebook crash disappeared, but since after
reverting gstreamer-plugins-bad packages to those shipped with jessie
the problem was still gone, I do not think gstreamer-plugins-bad
packages can be clearly blamed for my iceweasel crashes.

I will keep an eye on this and try to get a backtrace if crashes
reappear, but for now I think this
#788708 bug report can be allowed to be archived once the two
iceweasel asociated bug reports (#797385  and #799632) are reassigned
and closed/forcemerged properly.

Thanks a lot for your feedback,

-- 
Agustin

Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer

[Agustin Martin]

2015-11-14 12:22 GMT+01:00 Agustin Martin <agmar...@debian.org>:
> 2015-11-12 16:13 GMT+01:00 Sebastian Dröge <sl...@coaxion.net>:
>> On Do, 2015-11-12 at 15:35 +0100, Soeren D. Schulze wrote:
>>> Am 12.11.2015 um 15:02 schrieb Sebastian Dröge:
>>> > On Do, 2015-11-12 at 14:41 +0100, Soeren D. Schulze wrote:
>>> > > Hello,
>>> > >
>>> > > the problem does not seem to occur any more with
>>> > > gstreamer1.0-plugins-bad 1.6.1-1+b1 and iceweasel 38.4.0esr-1.
>>> > >
>>> > > Do you have any specific packages for me to test?
>>> >
>>> > Just a normal jessie installation without installing things from
>>> > other
>>> > sources, including sid :) It is definitely fixed since gst-plugins-
>>> > bad
>>> > 1.5.X, it's just not clear if the actual bug also exists in jessie
>>> > or
>>> > not (and if it doesn't, the fix will also have no effect for people
>>> > who
>>> > mix their packages with ones from other sources).
>>>
>>> I believe so.  I have had symptomatically similar crashes on two
>>> different jessie systems, but I had not installed debugging symbols,
>>> and it's hard to reproduce those crashes at command.
>>
>> It should crash always more or less immediately when you visit a
>> website with AAC audio. Vimeo for example :)
[...]
> As a side note, this box has an onboard nvidia GeForce 6150SE graphics
> engine, known to have serious problems with jessie's kernel, including
> system freezes (see e.g. #758460), with some apparent connection with
> iceweasel. As a matter of fact I am running sid kernel here to
> mitigate that.
[...]
> I will keep an eye on this and try to get a backtrace if crashes
> reappear,

I finally reproduced the iceweasel jessie crash and could get a
backtrace (attached). I do not have any experience at looking at
backtraces but it seems like an iceweasel threads issue. Tried again
with patched gstreamer-plugins-bad packages to see if problem is gone,
even if as an obscure side effect, but this time I got the crash even
with the patched packages.

Please find backtraces attached, both in iceweasel's normal and safe modes.

--
Agustin
$ gdb --args iceweasel
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from iceweasel...Reading symbols from 
/usr/lib/debug//usr/lib/iceweasel/iceweasel...done.
done.
(gdb) set pagination off
(gdb) run
Starting program: /usr/bin/iceweasel 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe900a700 (LWP 10491)]
[Thread 0x7fffe900a700 (LWP 10491) exited]

(process:10487): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size 
== 0' failed
[New Thread 0x7fffe900a700 (LWP 10493)]
[New Thread 0x7fffe0eff700 (LWP 10494)]
[New Thread 0x7fffe06fe700 (LWP 10495)]
[New Thread 0x77f76700 (LWP 10496)]
[New Thread 0x77ef5700 (LWP 10497)]
[New Thread 0x76def700 (LWP 10498)]
[New Thread 0x7fffdfefd700 (LWP 10499)]
[New Thread 0x7fffdfaf3700 (LWP 10500)]
[New Thread 0x7fffde9ff700 (LWP 10501)]
[New Thread 0x7fffddeff700 (LWP 10502)]
[New Thread 0x7fffdd6fe700 (LWP 10503)]
[New Thread 0x7fffdc7ff700 (LWP 10504)]
[New Thread 0x7fffdbcff700 (LWP 10505)]
[New Thread 0x7fffdfe2a700 (LWP 10506)]
[New Thread 0x7fffda288700 (LWP 10507)]
[New Thread 0x7fffd9a87700 (LWP 10508)]
[New Thread 0x7fffd8eff700 (LWP 10509)]
[New Thread 0x7fffd86fe700 (LWP 10510)]
[New Thread 0x7fffd6e41700 (LWP 10511)]
[New Thread 0x7fffd60ff700 (LWP 10512)]
[New Thread 0x7fffd4fff700 (LWP 10513)]
[New Thread 0x7fffd47fe700 (LWP 10514)]
[New Thread 0x7fffd45fd700 (LWP 10515)]
[New Thread 0x7fffd3bff700 (LWP 10516)]
[New Thread 0x7fffd39fe700 (LWP 10517)]
[New Thread 0x7fffd2cff700 (LWP 10518)]
[Thread 0x7fffd86fe700 (LWP 10510) exited]
[New Thread 0x7fffd22ff700 (LWP 10519)]
[New Thread 0x7fffd86fe700 (LWP 10520)]
[New Thread 0x7fffd16ff700 (LWP 10521)]
[New Thread 0x7fffd04f2700 (LWP 10522)]
[

Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer

[Agustin Martin]

On Wed, Nov 11, 2015 at 02:37:16PM +0100, Sebastian Dröge wrote:
> On Di, 2015-11-10 at 20:31 +0100, Agustin Martin wrote:
> > On Mon, Sep 21, 2015 at 03:55:16AM +0200, Soeren D. Schulze wrote:
> > > Package: iceweasel
> > > Version: 38.2.1esr-1~deb8u1
> > > Severity: important
> > > 
> > > Approximately once every 10 hours of use, I experience a crash of
> > > Iceweasel.
> > > It seems to be correlated with playing videos via gstreamer with
> > > the
> > > libav/ffmpeg backend, but I have not yet found any reliable way to
> > > reproduce
> > > it.
> > > 
> > > I have observed similar crashes like this on other Debian systems
> > > with
> > > earlier versions of Iceweasel, but I cannot tell if it is the same
> > > bug
> > > because I did not have a debugger running.
> > > 
> > > Please see the full backtrace below.  At a first glance, the
> > > problem seems
> > > to be in the GST_VIDEO_FRAME_COMP_DATA macro which ultimately calls
> > > GST_VIDEO_FORMAT_INFO_DATA (defined in the gstreamer headers),
> > > which in turn
> > > dereferences frame->info->finfo.  According to #1 in the backtrace,
> > > finfo is
> > > NULL, so I think this is what causes the crash.
> > ...
> > 
> > > {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype
> > > = 0}}}
> > > not_first_call = 
> > > pagesize_m1 = 
> > > sp = 
> > > freesize = 
> > > __PRETTY_FUNCTION__ = "start_thread"
> > > #16 0x7707c06d in clone () at
> > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> > > No locals.
> > > (gdb)
> > 
> > This seems to be similar to the backtrace reported in
> > https://bugs.debian.org/797227, caused by the same problem
> > as https://bugs.debian.org/788708 (cc'ed).
> > 
> > Is this problem still hapenning with gstreamer1.0-plugins-bad 1.4.5-3 
> > or higher?
> 
> If someone can confirm that, I'll prepare a gst-plugins-bad1.0 update
> for jessie with that patch. Just let me know :)

Hi,

In this case, it seems to be a mixed testing+jessie box, not pure jessie,
so I would not yet consider it a reason for a backport.

I am looking at other iceweasel bugs that may be related to this. Will ask
for feedback and cc this bug report as gstreamer1.0-plugins-bad reference
(should have indeed used #797227), so at least they can be reassigned and
closed if needed.

Regards,

-- 
Agustin

Bug#788708: Bug#797385: iceweasel crash loading a youtube page.

[Agustin Martin]

On Tue, Sep 01, 2015 at 10:08:49AM +, Adrin wrote:
> On Tue, 1 Sep 2015 at 01:30 Mike Hommey  wrote:
> 
> > On Sun, Aug 30, 2015 at 11:12:52AM +, Adrin wrote:
> > > Program received signal SIG38, Real-time event 38.
> > > 0x74546e23 in js::Shape::search (cx=cx@entry=0x76b5c990,
> > start=0x7fffd07576f0, id=..., pentry=pentry@entry=0x7fff6f00,
> > adding=adding@entry=false) at
> > /tmp/buildd/iceweasel-38.2.1esr/js/src/vm/Shape-inl.h:82
> > > 82/tmp/buildd/iceweasel-38.2.1esr/js/src/vm/Shape-inl.h: No such
> > file or directory.
> >
> > SIG38 is not a crash. Try to "continue" until you get an actual crash.
> >
> > Mike
> >
> 
> Ok. Here's another try. This time I get the seg fault.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 
> Adrin.

> $ MOZILLA_DISABLE_PLUGINS=1 gdb --args iceweasel
[...]
> #16 0x77bc70a4 in start_thread (arg=0x7fffa2afe700) at 
> pthread_create.c:309
> __res = 
> pd = 0x7fffa2afe700
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735922824960, 
> -8431668617060337543, 0, 140737354125408, 140737193347328, 140735922824960, 
> 8431854847888668793, 8431685629440768121}, mask_was_saved = 0}}, priv = {pad 
> = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
> not_first_call = 
> pagesize_m1 = 
> sp = 
> freesize = 
> __PRETTY_FUNCTION__ = "start_thread"
> #17 0x7707c07d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> 

Hi, Adrin and Sebastian, yet another candidate for bug merging and closing,

#797385: iceweasel crash loading a youtube page.

As already pointed out by Mike Hommey this seems very close to #797227.

Last part of your backtrace seems similar to the backtrace reported
in https://bugs.debian.org/797227, caused by the same problem
as https://bugs.debian.org/788708 (cc'ed) in gstreamer1.0-plugins-bad
package and already fixed in testing/sid with gstreamer1.0-plugins-bad
1.4.5-3 or higher.

Which Debian suite (jesie/testing/sid) is running the system showing the
problem? Does it mix suites?

Is the problem still reproducible? Which gstreamer1.0-plugins-bad version is
installed?

Thanks in advance,

Regards,

-- 
Agustin

Bug#788708: Bug#797385: iceweasel crash loading a youtube page.

[Agustin Martin]

On Thu, Nov 12, 2015 at 05:11:56PM +, Adrin wrote:
> Hi,
> 
> It's been long fixed for me. I haven't had this problem for quite some time
> now.

Thanks for the quick reply,

One more thing to make sure it is the same problem, are you running stable
(jessie), testing or sid in the box where the problem appeared?

Regards,

-- 
Agustin

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Agustin Martin]

On Mon, Nov 09, 2015 at 09:32:58PM +0100, Sebastian Dröge wrote:
> On Mo, 2015-11-09 at 18:45 +0100, Agustin Martin wrote:
> > Hi, gstreamer plugins maintainers
> > 
> > I have unarchived this bug report to add more info on it. Not yet
> > reopened it for jessie because I am not fully sure that is is the one
> > to blame.
> > 
> > I  am having some problems in jessie similar to those reported in
> > this
> > bug report, although they are not yet as reproducible.
> > 
> > Using iceweasel=38.4.0esr-1~deb8u1 and
> > gstreamer1.0-plugins-bad+libgstreamer-plugins-bad1.0-0=1.4.4-
> > 2.1+b1  I have been finding some problems about iceweasel sudden
> > closure. I have build a personal gstreamer1.0-plugins-bad=1.4.4-
> > 2.1.0.0+amd1 package including the patch that fixed this problem and
> > it seemed to disappear. The reason why I am not yet reopening this
> > bug report for jessie is that after reverting to current jessie
> > versions (1.4.4-2.1(+b1)) I am not reproducing it, so I cannot
> > discard that there is something else involved.
> 
> That seems weird. Do you happen to have a backtrace of one of these
> crashes still, ideally with debug symbols?

Hi,

It happened in a box where I do not have regular access. May be able to
try again next weekend if I can still reproduce it.

PS: I also unarchived this bug report because of other iceweasel bug report
that seems to be exactly the same (should have really unarchived #797227).
Just about to mail #799632 submitter cc'ing this unarchived bug report.

Regards,

-- 
Agustin

Bug#788708: Bug#799632: iceweasel: SIGSEGV when playing videos via gstreamer

[Agustin Martin]

On Mon, Sep 21, 2015 at 03:55:16AM +0200, Soeren D. Schulze wrote:
> Package: iceweasel
> Version: 38.2.1esr-1~deb8u1
> Severity: important
> 
> Approximately once every 10 hours of use, I experience a crash of Iceweasel.
> It seems to be correlated with playing videos via gstreamer with the
> libav/ffmpeg backend, but I have not yet found any reliable way to reproduce
> it.
> 
> I have observed similar crashes like this on other Debian systems with
> earlier versions of Iceweasel, but I cannot tell if it is the same bug
> because I did not have a debugger running.
> 
> Please see the full backtrace below.  At a first glance, the problem seems
> to be in the GST_VIDEO_FRAME_COMP_DATA macro which ultimately calls
> GST_VIDEO_FORMAT_INFO_DATA (defined in the gstreamer headers), which in turn
> dereferences frame->info->finfo.  According to #1 in the backtrace, finfo is
> NULL, so I think this is what causes the crash.
...

> {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
> not_first_call = 
> pagesize_m1 = 
> sp = 
> freesize = 
> __PRETTY_FUNCTION__ = "start_thread"
> #16 0x7707c06d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
> No locals.
> (gdb)

This seems to be similar to the backtrace reported in
https://bugs.debian.org/797227, caused by the same problem
as https://bugs.debian.org/788708 (cc'ed).

Is this problem still hapenning with gstreamer1.0-plugins-bad 1.4.5-3 or
higher?

Regards,

-- 
Agustin

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Agustin Martin]

Hi, gstreamer plugins maintainers

I have unarchived this bug report to add more info on it. Not yet
reopened it for jessie because I am not fully sure that is is the one
to blame.

I  am having some problems in jessie similar to those reported in this
bug report, although they are not yet as reproducible.

Using iceweasel=38.4.0esr-1~deb8u1 and
gstreamer1.0-plugins-bad+libgstreamer-plugins-bad1.0-0=1.4.4-2.1+b1  I
have been finding some problems about iceweasel sudden closure. I have
build a personal gstreamer1.0-plugins-bad=1.4.4-2.1.0.0+amd1 package
including the patch that fixed this problem and it seemed to
disappear. The reason why I am not yet reopening this bug report for
jessie is that after reverting to current jessie versions
(1.4.4-2.1(+b1)) I am not reproducing it, so I cannot discard that
there is something else involved.

Adding this info here in case anyone else is finding this problem in
jessie. If so, a jessie point upload may be be useful.

Regards,

-- 
Agustin

Bug#799845: myspell-en-gb, hunspell-en-gb: *another* file conflict

[Agustin Martin]

On Wed, Sep 23, 2015 at 11:00:57AM +0200, Thorsten Glaser wrote:
> Package: hunspell-en-gb
> Version: 1:5.0.1+dfsg-3
> Severity: serious
> Justification: Policy 7.4
> 
> Today, my dist-upgrade broke:
> 
> 
> The following NEW packages will be installed:
>   hunspell-en-gb
...
> Trying to install hunspell-en-gb (1:5.0.1+dfsg-3) once the upgrade
> to myspell-en-gb (1:5.0.1+dfsg-3) is finished works, so hunspell-en-gb
> is the one which requires a versioned conflict.

Hi, Mattia,

Seems to break a not recent enough version of the package

Package: hunspell-en-gb
Breaks: myspell-en-gb (<= 1:3.3.0~rc10-4)

But apt-cache policy myspell-en-gb shows 1:3.3.0-4 as previous version. As a
result, hunspell-en-gb may be (and is) unpacked before myspell-en-gb.

Preparing to unpack .../hunspell-en-gb_1%3a5.0.1+dfsg-3_all.deb ...
Unpacking hunspell-en-gb (1:5.0.1+dfsg-3) ...
dpkg: error processing archive
/var/cache/apt/archives/hunspell-en-gb_1%3a5.0.1+dfsg-3_all.deb (--unpack):
 trying to overwrite '/usr/share/hunspell/en_GB.aff', which is also in
/package myspell-en-gb 1:3.3.0-4
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Preparing to unpack .../myspell-en-gb_1%3a5.0.1+dfsg-3_all.deb ...
Unpacking myspell-en-gb (1:5.0.1+dfsg-3) over (1:3.3.0-4) ...
Errors were encountered while processing:
 /var/cache/apt/archives/hunspell-en-gb_1%3a5.0.1+dfsg-3_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Same may apply to other breaks/replaces from the same version (all but
hunspell-sl),

Regards,

-- 
Agustin

Bug#799440: myspell-* and hunspell-*: error when trying to install together

[Agustin Martin]

On Sat, Sep 19, 2015 at 01:40:52PM +, Mattia Rizzolo wrote:
> On Sat, Sep 19, 2015 at 10:45:04AM +0200, Ralf Treinen wrote:
> > this concerns a whole list of myspell-X and hunspell-X packages, but I am
> > filing this bug only against hunspell-af. Here is the complete list:
> 
> I was kinda looking for this bug, actually.  It's somewhat difficult to
> find out everything when you have a so large number of packages.
> Anyway, I truly expected some less...
> 
> 
> [re-sorting the list]
> > hunspell-af_myspell-af
> > hunspell-en-gb_myspell-en-gb
> > hunspell-en-za_myspell-en-za
> > hunspell-it_myspell-it
> > hunspell-sw_myspell-sw
> > hunspell-th_myspell-th
> 
> These come from src:openoffice.org-dictionaries, which I want to somehow
> remove, so I added transitive packages + breaks/replaces for them.
> 
> > hunspell-sl_myspell-sl
> 
> This one is orphaned, and the source contains only the hunspell
> patterns.  So, I decided to take it over.
> Added a transitional package and breaks/replaces here too.

Note that both contain the same patterns and words. No upstream watch, so
better tracked from libreoffice.
 
> > hunspell-hrr_myspell-hr
> 
> Here there is a typo: hrr → hr.  I corrected it, but I'll just ignore
> the conseguences since this package existed only for one day...
> (it fits in the section below)

These also contain the same patterns and words. Seems OK to disable it in
lo-dicts.

> > hunspell-el_myspell-el-gr

Same aff file in current versions, so it is indeed a myspell dict. dic
files are different, but I cannot really compare. lo dict seems however,
based in an old 0.7 version, while myspell-el-gr contains 0.8 (and there is
a 0.9 upstream version waiting). Seems OK to disable it in lo-dicts.

> > hunspell-et_myspell-et.

Same contents in both. OK to disable it in lo-dicts.

> > hunspell-pt_myspell-pt-br

BTW, shouldn't hunspell-pt be hunspell-pt-br?

Both hunspell-pt and myspell-pt-br contain exactly the same dictionary (just
version string in aff file is changed). I am adding a break in myspell-pt-br
against any hunspell-pt-br (not yet hunspell-pt), but I think it is OK to
disable hunspell-pt for now.

> > hunspell-pt-pt_myspell-pt-pt

hunspell-pt-pt dictionary here is an hunspell-only dictionary, so it
deserves it's own package. I will add a break against hunspell-pt-pt in
myspell-pt-pt 20091013-10, but I think hunspell-pt-pt should stay, but
conflicting with myspell-pt-pt (<=20091013-10) and replacing it. Once it
is minimaly tested in Debian I can make myspell-pt-pt a transitional
package to ensure a smooth transition to hunspell-pt-pt.

Regards,

-- 
Agustin

Bug#799440: myspell-* and hunspell-*: error when trying to install together

[Agustin Martin]

On Mon, Sep 21, 2015 at 03:33:16PM +, Mattia Rizzolo wrote:
> On Mon, Sep 21, 2015 at 01:23:39PM +0200, Agustin Martin wrote:
> 
> Thanks for your email here!
> Given that you are involved with several packages with dicts you find
> your input here important and valuable :)
> 
> > On Sat, Sep 19, 2015 at 01:40:52PM +, Mattia Rizzolo wrote:
> After my email Rene suggested me to add Conflicts in most of the cases,
> instead of dropping every problematic binary, and a package with them
> has already been uploaded, currently in NEW.

Hi, Mattia

I also think that is a better approach.

In the meantime I have also uploaded some of the dicts I'm involved with,
including additional Breaks even if hunspell package is not yet available,

myspell-da: Breaks hunspell-da
myspell-eo: Breaks hunspell-eo
myspell-es: Breaks hunspell-es
myspell-et: Breaks hunspell-et and hyphen-et
myspell-fo: Breaks hunspell-fo
myspell-lv: Breaks hunspell-lv and hyphen-lv
myspell-tl: Breaks hunspell-tl

> > > On Sat, Sep 19, 2015 at 10:45:04AM +0200, Ralf Treinen wrote:
> > > > hunspell-hrr_myspell-hr
> > > 
> > > Here there is a typo: hrr → hr.  I corrected it, but I'll just ignore
> > > the conseguences since this package existed only for one day...
> > > (it fits in the section below)
> > 
> > These also contain the same patterns and words. Seems OK to disable it in
> > lo-dicts.
> 
> I disabled hyphen-hr, but kept hunspell-hr, conflicting with myspell-hr.
> The last maintainer upload was in 2009, with 3 (the number 2 seems to
> have been lost somewhere...) different, quite large NMUs and a really
> simple bug is sitting in the BTS.
> I'd rather just take over everything, tbh.

Fine, just do not forget to try contacting maintainer first,
 
> > > > hunspell-el_myspell-el-gr
> > 
> > Same aff file in current versions, so it is indeed a myspell dict. dic
> > files are different, but I cannot really compare. lo dict seems however,
> > based in an old 0.7 version, while myspell-el-gr contains 0.8 (and there is
> > a 0.9 upstream version waiting). Seems OK to disable it in lo-dicts.
> 
> Oh, this one was last uploaded in 2012, the maintainer is not gone at
> least (I see an upload from him in 2014-10), the 0.9 seems to be from
> 2015-03-14. I opened a bug at TDF [0] to update the dictionaries there.
> Anyway, there is a Conflicts: in place there too.
> 
> [0] https://bugs.documentfoundation.org/show_bug.cgi?id=94415

> > > > hunspell-et_myspell-et.
> > 
> > Same contents in both. OK to disable it in lo-dicts.
> 
> This one is really up-to-date and maintained, and actually it Provides:
> hunspell-et.
> I think it's sane/wise to disable it in our part (done in git)

Thanks, fine. As written above, I also made myspell-et break hunspell-et
and hyphen-et.

> > > > hunspell-pt_myspell-pt-br
> > 
> > BTW, shouldn't hunspell-pt be hunspell-pt-br?
> 
> Itt should.  The very same way pt-pt is named pt-pt (annoying, this
> means another NEW trip...)

> > Both hunspell-pt and myspell-pt-br contain exactly the same dictionary (just
> > version string in aff file is changed). I am adding a break in myspell-pt-br
> > against any hunspell-pt-br (not yet hunspell-pt), but I think it is OK to
> > disable hunspell-pt for now.
> 
> would you add a Provides: hunspell-pt at least?

In the meantime, I am adding that dependency. However, note that this is
handled differently for aspell and old myspell.

For myspell, myspell-pt is a dependency package that will pull both
myspell-pt-br and myspell-pt-pt. Similar thing for aspell. I wonder if
something like this may be useful for hunspell-pt.

Where those transitional packages appear is a bit chaotic, for aspell there
is an standalone aspell-pt source package that will pull both and for
myspell it ts in myspell.pt sources (European portuguese).

> > > > hunspell-pt-pt_myspell-pt-pt
> > 
> > hunspell-pt-pt dictionary here is an hunspell-only dictionary, so it
> > deserves it's own package. I will add a break against hunspell-pt-pt in
> > myspell-pt-pt 20091013-10, but I think hunspell-pt-pt should stay, but
> > conflicting with myspell-pt-pt (<=20091013-10) and replacing it. Once it
> > is minimaly tested in Debian I can make myspell-pt-pt a transitional
> > package to ensure a smooth transition to hunspell-pt-pt.
> 
> nice!
> Currently there is naked "Conflicts: myspell-pt-pt" (i.e. unversioned).
> Though your paragraph here sounds awkward: does myspell-pt-pt deserve or
> not its own package? :) (I belive you missed a "don't" in the second
> line).

It is OK, is hunspell-pt-pt the one that deserves its own package. In this
case, ups

Bug#799440: myspell-* and hunspell-*: error when trying to install together

[Agustin Martin]

On Mon, Sep 21, 2015 at 05:44:36PM +, Mattia Rizzolo wrote:
> On Mon, Sep 21, 2015 at 06:41:16PM +0200, Agustin Martin wrote:
> > On Mon, Sep 21, 2015 at 03:33:16PM +, Mattia Rizzolo wrote:
> > > On Mon, Sep 21, 2015 at 01:23:39PM +0200, Agustin Martin wrote:
> > > > On Sat, Sep 19, 2015 at 01:40:52PM +, Mattia Rizzolo wrote:
> > > After my email Rene suggested me to add Conflicts in most of the cases,
> > > instead of dropping every problematic binary, and a package with them
> > > has already been uploaded, currently in NEW.
> > 
> > I also think that is a better approach.
> > 
> > In the meantime I have also uploaded some of the dicts I'm involved with,
> > including additional Breaks even if hunspell package is not yet available,
> 
> umh, isn't Conflicts needed in this case.  They are just plain
> incompatible in the current state of affairs.

Err, yes, thanks for pointing this out.

Although at least with dpkg no unexpected error seems to happen,

dpkg -i myspell-et_20030606-26_all.deb
dpkg: regarding myspell-et_20030606-26_all.deb containing myspell-et:
 myspell-et breaks hunspell-et
  hunspell-et (version 1:5.0.1+dfsg-1) is present and installed.

dpkg: error processing archive myspell-et_20030606-26_all.deb (--install):
 installing myspell-et would break hunspell-et, and
 deconfiguration is not permitted (--auto-deconfigure might help)
Errors were encountered while processing:
 myspell-et_20030606-26_all.deb

Will try tomorrow with apt to check a bit more in real situation. I am
afraid I'll need yet another bunch of uploads to change it back to conflicts.

> > > > > > hunspell-pt_myspell-pt-br
> > > > 
> > > > Both hunspell-pt and myspell-pt-br contain exactly the same dictionary 
> > > > (just
> > > > version string in aff file is changed). I am adding a break in 
> > > > myspell-pt-br
> > > > against any hunspell-pt-br (not yet hunspell-pt), but I think it is OK 
> > > > to
> > > > disable hunspell-pt for now.
> > > 
> > > would you add a Provides: hunspell-pt at least?
> > 
> > In the meantime, I am adding that dependency. However, note that this is
> > handled differently for aspell and old myspell.
> > 
> > For myspell, myspell-pt is a dependency package that will pull both
> > myspell-pt-br and myspell-pt-pt. Similar thing for aspell. I wonder if
> > something like this may be useful for hunspell-pt.
> 
> wooops, I meant a Provides: hunspell-pt-br ...
> I do think a hunspell-pt package pulling hunspell-pt-pt and
> hunspell-pt-br makes sense.
> If you think the best place to hold such a metapackage is lo-dicts just
> shut (=open a new bug) and I'd be happy to add it; it's cheap when you
> have ~100 binaries anyway… ;)

Up to you. just let me know, I already added hunspell-pt to provides. Other
thing I considered at some time is a spellcheck-dependencies-pt source
package containing just dependency packages. But I never did it, so is now
your choice for hunspell-pt. 

> > It is OK, is hunspell-pt-pt the one that deserves its own package. In this
> > case, upstream is the same for both myspell-pt-pt and hunspell-pt-pt, so
> > I'd expect the change to be smooth and something we can do soon. Just allow
> > a minimal testing of hunspell-pt-pt in real life.
> 
> umh, do you mean it's own *source* package here?
> so, what do you suggest now that there is a hunspell-pt-pt in lo-dicts?

No, I meant binary package under lo-dicts umbrella.

> > In other cases like myspell-es vs hunspell-es, upstreams are different and
> > in the meantime, I'd prefer to wait a bit more having two conflicting
> > alternatives available.
> 
> wait wat?

Wait to know what people think about both in real usage, that is, have them
both simultaneously in the archive, until one clearly wins. This way we do
not opt by one upstream or another, but users do.

> > Did not check, but you may also need to add some links in migrations,
> 
> ok, but to me it seems nothing in debian currently requires myspell, and
> everything (within our archive) migrated to hunspell.  What more is
> holding us on just blinding stop providing myspell dictionaries (read it
> as: dictionaries in the myspell directory?

There should be no dictionaries in the myspell directory, using or not
advanced hunspell-only features, all should go in the hunspell directory.

> Also, most of the myspell-* packages I saw where shipping files in the
> hunspell directory, and the others were just symlink them to the myspell
> dir.

Those are buggy, using /usr/share/myspell is deprecated since years ago.
hunspell still looks there also, but that location is more than obsolete.
 
> Wh

Bug#797227: segfault - gst_memory_unmap, libgstreamer

[Agustin Martin]

On Wed, Sep 02, 2015 at 12:18:28PM +0300, Sebastian Dröge wrote:
> On Mi, 2015-09-02 at 17:32 +0900, Changwoo Ryu wrote:
> > Yes, I just have tested the patch on faad plugin at the GNOME 
> > bugzilla 748571. And it fixes the problem.
> 
> Thanks for testing, 

Hi,

Also tested here with a personal package rebuild including that fix.
Problem seems fixed with it.

> question is if I should upload a new package with
> the fix to unstable or we just wait until 1.6.0 is released... which
> should happen in the next week or two.

I'd upload a new package with the fix. Even if upstream releases soon, new
package may need some extra work and delay the fix even more.

By the way, iceweasel's http://bugs.debian.org/788708 seems to be the same
problem.

Regards,

-- 
Agustin

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Agustin Martin]

On Mon, Aug 31, 2015 at 08:29:19AM -0700, Josh Triplett wrote:
> On Fri, 21 Aug 2015 10:43:56 +0100 Tim-Philipp =?ISO-8859-1?Q?M=FCller?= 
>  wrote:
> > This looks at first glance like some GStreamer element(s) could not be
> > created, such as appsink, maybe others too; possibly because the
> > required GStreamer plugins are not installed. Combined with insufficient
> > error handling.
> > 
> > I note that this bug was reported against an iceweasel version that uses
> > the old and unmaintained GStreamer 0.10.x.
> > 
> > The current iceweasel version uses GStreamer 1.x, and I can't reproduce
> > this problem with 38.2.0esr-1 either.
> 
> I can reproduce this problem with 38.2.1esr-1 in unstable as well as
> 40.0.3-1 in experimental.  Vising any page embedding video (including
> YouTube or Twitter) crashes Iceweasel as soon as the video would start
> to play.
> 
> I have gstreamer1.0-plugins-base 1.4.5-2,
> gstreamer1.0-plugins-{good,bad,ugly} 1.4.5-2+b2, and gstreamer1.0-libav
> 1.4.5-3.

Hi,

This may well be the same gstreamer1.0-plugins-bad problem reported in
http://bugs.debian.org/797227.

-- 
Agustin

Bug#789098: FTBFS: ./conjugue fails with internal error: afligir e arg�ir colidem em FV

[Agustin Martin]

tag 789098 +pending
tag 789099 +pending

On Wed, Jun 17, 2015 at 08:30:23PM +, Chris West (Faux) wrote:
 Source: br.ispell
 Version: 3.0~beta4
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 Dear Maintainer,
 
 The package fails to build for me, although it appears to build sometimes on 
 our Jenkins.
 I suspect something to do with locales or locale variation, but I'm unable to 
 confirm:
 dh_testdir
 # Build everything besides aspell
 /usr/bin/make AWK=/usr/bin/gawk \
   formas br.aff br.base br.ispell
 make[1]: Entering directory '/home/faux/br.ispell-3.0~beta4'
 /usr/bin/gawk -f ./conjugue -v BANCO=verbos -v FORMATO=aa -v CMD=T v.rules
 Falha interna: afligir e arg�ir colidem em FV
 Makefile:107: recipe for target 'br.aff' failed
 make[1]: *** [br.aff] Error 1
 
 I believe that the pair of words that are failing are the first words 
 evaluated.
 
 My build environment is normal: LANG=en_GB.UTF-8, LC_ALL and other 
 variables not explicitly set.
 Jenkins is supposed to be set up the same way, and succeeds the build, but 
 fails in the build that specifies LC_ALL.

On Wed, Jun 17, 2015 at 08:49:13PM +, Chris West (Faux) wrote:
 Source: eo-spell
 Version: 2.1.2000.02.25
 Severity: serious
 Justification: fails to build from source
 
 Dear Maintainer,
 
 The package fails to build from source:
 
 cp eo.aff ooo-tmp/esperanto.aff
 # Create ispell latin3 munched wordlist and affix file
 sed -f debian/cx2latin3.sed kune.txt  ooo-tmp/eo.wl
 sed: file debian/cx2latin3.sed line 1: unterminated `s' command
 debian/rules:50: recipe for target 'build-stamp' failed
 make: *** [build-stamp] Error 1
 
 Looks like it could be a locale problem, I'm running LANG=en_GB.UTF-8 LC_ALL 
 unset:
 root@sid:~/eo-spell-2.1.2000.02.25# cat debian/cx2latin3.sed | head -n1 | xxd
 : 732f 6378 2fe6 2f67 0a   s/cx/./g.

Thanks for the info, replying to both #789098 and #789099.

I guess it would work with LC_ALL=C, but fails when iso-8859-1 files are
used under UTF-8 locale. Should be fixed by forcing LC_ALL=C in debian/rules.

Regards,

-- 
Agustin


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

Bug#752726: Bug #752726: Unable to reproduce

[Agustin Martin]

On Sun, Dec 21, 2014 at 08:11:24PM +0100, Thomas Vincent wrote:
 Hello,
 
 Damien 'drazzib' Raude-Morvan and I tried to reproduce this bug in
 chroots (with sbuild) in both jessie and sid:
 
 * using the current stumpwm package from sid and setting clisp as the
compiler
 * creating a complete chroot from snapshot.debian.org (20140625)
corresponding to the date this bug report was filled
 
 We were in each case unable to reproduce this bug both about the build
 and the command given in message #21.

I also tried unsuccessfully to reproduce this problem with procedure
described in #21 by Michael. Using an amd64 sid chroot and stumpwm
modified to use clisp for build and run, no luck.

Also, it must be noted that stumpwm has switched from clisp to sbcl in
stumpwm:2:0.9.8-7, already in testing. For this reason this problem
no longer affects stumpwm for jessie.

Regards,

-- 
Agustin


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

Bug#775267: ERROR: dictionaries-common is broken - called emacs-package-remove as a new-style add-on, but has no compat file.

[Agustin Martin]

Control: reassign -1 emacsen-common
Control: forcemerge 736062 775267

On Tue, Jan 13, 2015 at 12:49:37PM +0100, Andreas Beckmann wrote:
 Package: dictionaries-common
 Version: 1.23.17
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: piuparts
 
 Hi,
 
 noticed this during a piuparts test (wheezy2jessie-rcmd, gnumed-client):
 
   Preparing to replace dictionaries-common 1.12.11 (using 
 .../dictionaries-common_1.23.17_all.deb) ...
   ERROR: dictionaries-common is broken - called emacs-package-remove as a 
 new-style add-on, but has no compat file.
   Leaving 'diversion of /usr/share/dict/words to 
 /usr/share/dict/words.pre-dictionaries-common by dictionaries-common'
   Unpacking replacement dictionaries-common ...
 
 It does not fail (in d-c) but this sounds scary.

Hi, Andreas,

Do not worry, this is emacsen-common testing things in the wrong place and
issuing a far too scary message. See

[emacsen-common: emacs-package-install --preinst displays incorrect error 
message]
https://bugs.debian.org/736062

Old emacs-package-install tests for a compat file during its invocation
from dictionaries-common preinst, when the updated add-on is not yet
unpacked. And at that time fixed emacsen-common (2.0.8) seems not yet
installed, so old script is used. Normal dependencies will only help
sorting configure stage.

Note that you might see this message in other emacsen add-ons.

Reassigning to emacsen-common (Hi, Rob) and forcemerging with closed #736062.

Regards,

-- 
Agustin


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

Bug#775149: dictionaries-common: fails to install: update-default-wordlist: Question empty but elements installed for class wordlist

[Agustin Martin]

Control: affects -1 education-desktop-lxde
Control: tag -1 + wheezy

On Mon, Jan 12, 2015 at 12:18:11PM +0100, Andreas Beckmann wrote:
 Control: severity -1 serious
 
 On 2015-01-12 12:00, Agustin Martin wrote:
  I asked release team to allow incorporation of changes in 1.23.6 (See
  #761662), but had no reply. This is probably meaningless with jessie release
  approaching.
 
 Raising severity since it happens in a fresh install.
 And yes, apt-utils is not installed in this case ...

I guess it is installed in the same run as dictionaries-common, so is not
available in the configure stage for that run. This error should not happen
if apt-utils is not to be installed nor if it is already installed when
dictionaries-common is configured.

 I'll check whether your proposed patch fixes my bug, but it may take a
 few days.

The best workaround is IMHO to make sure that apt-utils is installed before
dictionaries-common is configured.

Changes in 1.23.6 will only avoid the error, trying harder to set a default
even if no debconf info is yet parsed. In systems with many candidates this
can lead to a wrong choice. I proposed those minimal changes to have a
small diff as candidate for a point release. Better fix goes through use of
no-await triggers, as I wrote.

I am re-adding education-desktop-lxde affects and tagging this bug report
as wheezy. Since fixed version is present, it should be clear that this
does not affect jessie. This also does not affect upgrades to jessie.

Regards,

-- 
Agustin


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

Bug#775149: dictionaries-common: fails to install: update-default-wordlist: Question empty but elements installed for class wordlist

[Agustin Martin]

Control: forcemerge 751367 775149

On Mon, Jan 12, 2015 at 12:46:57AM +0100, Andreas Beckmann wrote:
 Package: dictionaries-common
 Version: 1.12.11
 Severity: serious
 User: debian...@lists.debian.org
 Usertags: piuparts
 Control: affects -1 education-desktop-lxde
 
 Hi,
 
 during a test with piuparts I noticed your package failed to install. As
 per definition of the release team this makes the package too buggy for
 a release, thus the severity.
 
 This happens under these circumstances:
 
 * distribution: wheezy
 * --install-recommends is enabled
 * education-desktop-lxde is being installed which brings a lot of
   dependencies and recommends
 
 From the attached log (scroll to the bottom...):
 
 
   Setting up dictionaries-common (1.12.11) ...
   update-default-wordlist: Question empty but elements installed for class 
 wordlist
 dictionaries-common/default-wordlist: return code: 0, value: 
 Choices: , Manual symlink setting
 shared/packages-wordlist: return code: 10 owners/error: 
 shared/packages-wordlist doesn't exist
 Installed elements: english (Webster's Second International English 
 wordlist)
   
 Please see /usr/share/doc/dictionaries-common/README.problems, section
 Debconf database corruption for recovery info.
   
   update-default-wordlist: Selected wordlist  
   does not correspond to any installed package in the system
   and no alternative wordlist could be selected.
   dpkg: error processing dictionaries-common (--configure):
subprocess installed post-installation script returned error exit status 
 255
   dpkg: dependency problems prevent configuration of aspell:
aspell depends on dictionaries-common ( 0.40); however:
 Package dictionaries-common is not configured yet.
 
 
 Whatever is going on here, this shouldn't happen on initial install
 in a fresh system. DEBIAN_FRONTEND=noninteractive is being used.
 It's very unlikely that the 25GB tmpfs that is used by piuparts
 ran out of space ... to cause the classical debconf corruption
 described in README.problems.

Hi, Andreas,

This is another incarnation of #751367. Although it can be caused by debconf
database corruption, in a fresh install it can also be caused by apt-utils
not installed initially (See #751367). It has been dealt with more
gracefully in 1.23.6 and fixed in 1.23.12 by using no-await triggers.

I asked release team to allow incorporation of changes in 1.23.6 (See
#761662), but had no reply. This is probably meaningless with jessie release
approaching.

I am forcemerging this bug report with #751367.

Regards,

-- 
Agustin


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

Bug#769552: ipolish: package fails to upgrade properly from wheezy

[Agustin Martin]

On Sat, Nov 15, 2014 at 11:21:33AM +0100, Jakub Wilk wrote:
 * Lucas Nussbaum lu...@lucas-nussbaum.net, 2014-11-14, 13:31:
 update-default-ispell:
 Could not make the default symlink to /usr/lib/ispell/polish.hash.
 This may be a temporary problem due to installation ordering. If that
 file is not present after installation, please file a bugreport
 against ispell dictionary package owning that file.
 
 This looks like an insufficient dependency on dictionaries-common.

Thanks for pointing out this,

Seems I did not check the use of jessie dicts in wheezy.

 Given that the binary package was mostly generated automatically by
 installdeb-ispell(1), the dependencies should be be generated automatically,
 too. There is ${ispell:Depends} that can be used for this purpose, although
 it's very poorly documented.

I mailed the info about this change to the dict-common.dev mailing list

http://lists.alioth.debian.org/pipermail/dict-common-dev/2014-June/thread.html

but did not make clear that dictionaries relying on symlink creation by
installdeb- scripts must bump its dependency on dictionaries-common. That
symlinks are now created by the autobuildhash script.

Just sent a clarification to the list, bcc'ed to the packages address for
those ispell or aspell dictionaries not having a bumped dependency. Sorry,
Robert, for being late.

I have also modified the installdeb-{a,i}spell man pages to add info about
the substvars and to fix info about this no longer available feature (it
was still marked as available). Opened #770484 to track this. Since it is
only a dodumentation fix, I hope to get a freeze exception from the release
team.

 The attached patch should fix the bug. After rebuilding with this patch, the
 binary package has:
 
 Depends: dictionaries-common (= 1.23~)
 
 instead of
 
 Depends: dictionaries-common (= 1.10.6~)
 
 But I fear that there are many other ispell dictionaries with the same
 problem. Some of them might not have any symptoms now (because they were
 built with old dictionaries-common), but they'd break after a rebuild.

I went through the list of sid ispell or aspell dictionaries and
fortunately, they are in one of these cases: were built some time ago, when
that feature was available, have updated dependency, set symlinks explicitly
during build process or are binary:arch packages where no symlinks are
needed. Hope not to have missed anyone.

Thank you very much for the info,

-- 
Agustin


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

Bug#767940: dictionaries-common: upgrade failure: Undefined subroutine main::subst called at /usr/sbin/aspell-autobuildhash line 54.

[Agustin Martin]

On Mon, Nov 03, 2014 at 10:53:17PM +0800, Paul Wise wrote:
 Package: dictionaries-common
 Version: 1.23.14
 Severity: serious
 
 When upgrading from 1.23.12 to 1.23.14 I get this error message:
 
 Setting up dictionaries-common (1.23.14) ...
 Processing triggers for dictionaries-common (1.23.14) ...
 aspell-autobuildhash: processing: es [es].
 Undefined subroutine main::subst called at /usr/sbin/aspell-autobuildhash 
 line 54.
 dpkg: error processing package dictionaries-common (--configure):
  subprocess installed post-installation script returned error exit status 2
 Errors were encountered while processing:
  dictionaries-common

Hi Paul, thanks for the info.

This seems to be problem introduced in 1.23.0, more than six months ago,
and only appears when there is an accompanying error (is located in the
function used to warn about errors in aspell dictionaries). For this
reason it has been unnoticed for this long time.

The reason is that I missed to re-enable some things after they were
disabled for easier command-line testing in --dry-run mode.

Expect a fix really shortly.

Regards,

--
Agustin


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

Bug#767940: dictionaries-common: upgrade failure: Undefined subroutine main::subst called at /usr/sbin/aspell-autobuildhash line 54.

[Agustin Martin]

reopen 767940
thanks

On Mon, Nov 03, 2014 at 06:54:11PM +0100, Agustin Martin wrote:
 On Mon, Nov 03, 2014 at 10:53:17PM +0800, Paul Wise wrote:
  Package: dictionaries-common
  Version: 1.23.14
  Severity: serious
  
  When upgrading from 1.23.12 to 1.23.14 I get this error message:
  
  Setting up dictionaries-common (1.23.14) ...
  Processing triggers for dictionaries-common (1.23.14) ...
  aspell-autobuildhash: processing: es [es].
  Undefined subroutine main::subst called at /usr/sbin/aspell-autobuildhash 
  line 54.
  dpkg: error processing package dictionaries-common (--configure):
   subprocess installed post-installation script returned error exit status 2
  Errors were encountered while processing:
   dictionaries-common
 
 Hi Paul, thanks for the info.
 
 This seems to be problem introduced in 1.23.0, more than six months ago,
 and only appears when there is an accompanying error (is located in the
 function used to warn about errors in aspell dictionaries). For this
 reason it has been unnoticed for this long time.
 
 The reason is that I missed to re-enable some things after they were
 disabled for easier command-line testing in --dry-run mode.
 
 Expect a fix really shortly.

Reopening, there is another issue when showing errors.

-- 
Agustin


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

Bug#767940: dictionaries-common: upgrade failure: Undefined subroutine main::subst called at /usr/sbin/aspell-autobuildhash line 54.

[Agustin Martin]

clone 767940
retitle -1 dictionaries-common::aspell-autobuildhash: Installation fails 
because of bad return code on error.
submitter -1 !
close 767940
fixed 767940 dictionaries-common/1.23.15
thanks

On Mon, Nov 03, 2014 at 08:05:03PM +0100, Agustin Martin wrote:

  The reason is that I missed to re-enable some things after they were
  disabled for easier command-line testing in --dry-run mode.
  
  Expect a fix really shortly.
 
 Reopening, there is another issue when showing errors.

Sorry for being so terse, should have added more details.

The additional problem is that the return code on autobuild error is wrong,
thus causing also installation errors, apart from the problem you reported. 

Can't use string (0) as a HASH ref while strict refs in use at 
/usr/sbin/aspell-autobuildhash line 240, STDIN line 8.
dpkg: error processing package dictionaries-common (--configure):
 subprocess installed post-installation script returned error exit status 2
Errors were encountered while processing:
 dictionaries-common
E: Sub-process /usr/bin/dpkg returned an error code (1)

I am cloning your bug report for better tracking of the problem and set
myself as submittter of the cloned bug.

I am closing your bug report since it is different to this new one and will
use the new one for this new problem.

Sorry for the extra noise and thanks for your info.

-- 
Agustin


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

Bug#764189: Must break old pre-multiarch arch:any aspell dictionaries

[Agustin Martin]

Package: aspell
Version: 0.60.7~20110707-1.2
Severity: serious

0.60.7~20110707-1.2 included a partial multiarch implementation, where
aspell hashes can be shared between 32/64 bit architectures with the same
endianness (but not with different endiannesses) by always using 32bit
numbers.

Transition was automatic for arch:all aspell-dictionaries using
aspell-autobuildhash (the preferred method for packaging aspell
dictionaries), but there are still some arch:any aspell dictionaries.
Hashes shipped by those arch:any aspell dictionary packages for 64 bit
architectures will no longer work with new aspell, that always use 32
bit numbers, and need to be rebuilt against last aspell.

aspell must then declare a break against the old non fixed aspell
dictionaries. Not doing that is against policy.

Since I NMU'ed 0.60.7~20110707-1.2 I will prepare a 0-day NMU for this.

Regards,

-- 
Agustin


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

Bug#736066: Allow encfs into jessie?

[Agustin Martin]

On Thu, Sep 11, 2014 at 04:06:06PM -0400, Harlan Lieberman-Berg wrote:
 On Thu, 2014-09-11 at 19:33 +0200, Eduard Bloch wrote:
  I though Jan has just described one. For example, taking a 10 year old
  CD with backups from your safe and trying to get the data back.
 
 Another option would be to take the same approach that TrueCrypt did
 under (potentially) the same circumstances, and allow encfs into jessie
 - but only for read-only containers.  That way, people can recover their
 data easily, but there's no risk of perpetuating a completely broken
 encryption layer.
 
 That'd be the best of both worlds, in my opinion.

Note that some people have encfs encrypted HOME dirs by means of things like
libpam-encfs. I do not think they will enjoy having their HOME partition
suddenly become RO, even if can be recovered with the new package. They
should of course be warned loudly that an old encryption layer is in use,
with some potential risks.

Another option would be a jessie encfs-ro package conflicting with encfs,
but neither providing nor replacing it, so no new volumes are created. 
encfs would be kept out of jessie and once fixed it would manage to replace
encfs-ro. However, the drawback is that the old encryption layer would
still be present in upgraded systems until fix happens and reaches a stable
release. 

I do not have a clear opinion about what is better.

Regards,

-- 
Agustin


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

Bug#699301: Bug#644559: O: python-uniconvertor -- Universal vector graphics translator

[Agustin Martin]

On Mon, Sep 01, 2014 at 08:39:12AM -0700, Javi Merino wrote:
 Hi Agustin,
 
 On Mon, 22 Jul 2013 18:11:57 +0200 Agustin Martin agmar...@debian.org wrote:
  
  The short story, I have been playing on building a 1.1.5 python-uniconvertor
  package together with a new package python-sk1libs, the new dependency.
  I did a minimal testing and resulting package seems to work, but this is my
  first approach to python and everything I did needs extensive reviewing by
  someone fluent with python, long story in above bug reports.
  
  I do not intend to adopt this package, so you may be interested in my
  changes in
  
  http://anonscm.debian.org/gitweb/?p=users/agmartin/TMP/python-sk1libs.git;a=summary
  http://anonscm.debian.org/gitweb/?p=users/agmartin/TMP/python-uniconvertor.git;a=summary
  
  Note that python-modules team seems to have SVN as preferred VCS (fix me if 
  this is no longer true)
 
 I'm looking into importing your packaging of python-sk1libs and
 python-uniconvertor into the Python Modules team and fixing #699301 at
 last.  In your email you state that you don't want to adopt the
 package but python-sk1libs/debian/control shows you as maintainer.
 Are you ok with me changing that to the Debian Python Modules team?

Hi, Javi,

I am very happy to see someone fluent with python working with this. Please
feel free to change maintainer to the Debian Python Modules team and do all
the changes you consider convenient. I am not really fluent with python,
but I hope my changes in above repos are useful.

Note that some time ago, Barry deFreese tried to do a sk1libs QA upload to
NEW that was rejected, Please see thread starting at

https://lists.debian.org/debian-qa-packages/2013/09/threads.html#4

and rejection message

https://lists.debian.org/debian-qa-packages/2013/09/msg00039.html

I think I already fixed in my git repo most if not all the concerns raised
there (apart from being a QA upload to NEW), but double checking might
worth.

I tried to contact Barry about his changes, but got no reply or I missed
it. Barry seemed not particularly interested in the sk1libs package, just
in fixing #699301. I am cc'ing him in case he wants to add something from
his experience with that upload.

Thanks a lot for caring about python-uniconvertor and sk1libs.

Regards,

-- 
Agustin


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

Bug#746825: Already fixed upstream

[Agustin Martin]

tag 746825 + fixed-upstream
affects 746825 ivtools
thanks

On Fri, May 30, 2014 at 05:51:23PM +0200, Johnny Willemsen wrote:
 Hi,
 
 This is already fixed upstream, an export is lacking

Hi, Johnny, thanks for the upstream help.

Is that fix included in latest 6.2.0 ACE upstream release? 

Unfortunately seems that Debian ACE is way behind upstream (6.0.3 vs 6.2.0).
I am neither ACE maintaner not fluent with C++, I am interested in this
because ivtools, which I use, depends on ACE, so I'd like this bug report
being fixed. I'd also like Debian ACE being in sync with upstream, but that
is way beyond my kills.

Can you please point us to the ACE commit that fixed this problem? Until
someone does the real sync with upstream this may be the simplest approach.

Regards,

-- 
Agustin


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

Bug#742292: marked as done (xindy: FTBFS on kfreebsd)

[Agustin Martin]

On Wed, Jun 04, 2014 at 08:39:10PM +, Debian Bug Tracking System wrote:

 From: Ivo De Decker 
 package: xindy
 version: 2.4-1.3
 severity: serious
 
 
 Hi,
 
 It seems xindy 2.4-1.3 doesn't build on kfreebsd, preventing migration to
 testing:
 
 https://buildd.debian.org/status/package.php?p=xindy
 
 Date: Wed, 4 Jun 2014 22:36:52 +0200
 From: Ivo De Decker 
 
 The new clips fixed the xiny build on kfreebsd. Closing.

libsigsegv seems the one to blame

https://bugs.debian.org/740487

-- 
Agustin


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

Bug#750069: ingerman, iswiss: fail to upgrade from wheezy

[Agustin Martin]

reassign   750540 ingerman,iswiss
forcemerge 750069 750540
tag750069 + patch
tag750067 + patch
thanks

[#750069] On Sun, Jun 01, 2014 at 11:54:13AM +0200, Holger Levsen wrote:
 Package: ingerman, iswiss
 Version: 20131206-4
 Severity: serious
 
 during a test with piuparts I noticed your packages fail to upgrade from
 wheezy. They installed fine in wheezy, then the upgrade to jessie fails.
 
 From the attached logs (scroll to the bottom...):
 
   Unpacking ingerman (20131206-4) over (20120607-1) ...
 [...]
   Setting up ingerman (20131206-4) ...
   /var/lib/dpkg/info/ingerman.postinst: 23: 
 /var/lib/dpkg/info/ingerman.postinst: cannot create 
 /var/lib/ispell/ngerman.compat: Directory nonexistent

[#750540] On Mi, 04 iun 14, 11:41:11, Matthias Urlichs wrote:

 ingerman (20131206-4) wird eingerichtet ...
 /var/lib/dpkg/info/ingerman.postinst: 23: 
 /var/lib/dpkg/info/ingerman.postinst: cannot create 
 /var/lib/ispell/ngerman.compat: Directory nonexistent

[#750067] On Sun, Jun 01, 2014 at 11:48:55AM +0200, Holger Levsen wrote:
   Setting up aspell-de (20131206-4) ...
   touch: cannot touch '/var/lib/aspell/dontremove': No such file or directory

Hi, Roland and submitters,

I am replying to these three bugs together because they are tightly related
(#750069 and #750540 are indeed the same, merging).

#750069 and #750540: They are fixed by upgrading build-depends to
  dictionaries-common-dev (= 1.23.3) to force up to date debhelper snippets
  dealing harder with /var/lib/ispell availability in upgrades. See attached 

  0001-control-Build-Depend-on-dictionaries-common-dev-1.23.patch

#750067: aspell-de 20131206-4 uses a workaround to deal with the problem
 behind #750069 and #750540 for aspell-de (see #748253), but when it tries
 to write /var/lib/aspell it may have already been removed, leading to
 #750067.

 If above 0001-control-Build-Depend-on-dictionaries-common-dev-1.23.patch
 patch is applied the dontremove hack becomes meaningless and should be
 removed, see attached

 0002-aspell-de.postinst-No-longer-use-dontremove-hack-Clo.patch

Regards,

-- 
Agustin


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

Bug#750067: Bug#750069: ingerman, iswiss: fail to upgrade from wheezy

[Agustin Martin]

reassign   750540 ingerman, iswiss
forcemerge 750069 750540
tag750069 + patch
tag750067 + patch
thanks

[#750069] On Sun, Jun 01, 2014 at 11:54:13AM +0200, Holger Levsen wrote:
 Package: ingerman, iswiss
 Version: 20131206-4
 Severity: serious
 
 during a test with piuparts I noticed your packages fail to upgrade from
 wheezy. They installed fine in wheezy, then the upgrade to jessie fails.
 
 From the attached logs (scroll to the bottom...):
 
   Unpacking ingerman (20131206-4) over (20120607-1) ...
 [...]
   Setting up ingerman (20131206-4) ...
   /var/lib/dpkg/info/ingerman.postinst: 23: 
 /var/lib/dpkg/info/ingerman.postinst: cannot create 
 /var/lib/ispell/ngerman.compat: Directory nonexistent

[#750540] On Mi, 04 iun 14, 11:41:11, Matthias Urlichs wrote:

 ingerman (20131206-4) wird eingerichtet ...
 /var/lib/dpkg/info/ingerman.postinst: 23: 
 /var/lib/dpkg/info/ingerman.postinst: cannot create 
 /var/lib/ispell/ngerman.compat: Directory nonexistent

[#750067] On Sun, Jun 01, 2014 at 11:48:55AM +0200, Holger Levsen wrote:
   Setting up aspell-de (20131206-4) ...
   touch: cannot touch '/var/lib/aspell/dontremove': No such file or directory

Hi, Roland and submitters,

I am replying to these three bugs together because they are tightly related
(#750069 and #750540 are indeed the same, merging).

#750069 and #750540: They are fixed by upgrading build-depends to
  dictionaries-common-dev (= 1.23.3) to force up to date debhelper snippets
  dealing harder with /var/lib/ispell availability in upgrades. See attached 

  0001-control-Build-Depend-on-dictionaries-common-dev-1.23.patch

#750067: aspell-de 20131206-4 uses a workaround to deal with the problem
 behind #750069 and #750540 for aspell-de (see #748253), but when it tries
 to write /var/lib/aspell it may have already been removed, leading to
 #750067.

 If above 0001-control-Build-Depend-on-dictionaries-common-dev-1.23.patch
 patch is applied the dontremove hack becomes meaningless and should be
 removed, see attached

 0002-aspell-de.postinst-No-longer-use-dontremove-hack-Clo.patch

Regards,

-- 
Agustin


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

Bug#750067: Bug#750069: ingerman, iswiss: fail to upgrade from wheezy

[Agustin Martin]

On Thu, Jun 05, 2014 at 06:55:41PM +0200, Agustin Martin wrote:
 [#750069] On Sun, Jun 01, 2014 at 11:54:13AM +0200, Holger Levsen wrote:
  Package: ingerman, iswiss
  Version: 20131206-4
  Severity: serious
  
  during a test with piuparts I noticed your packages fail to upgrade from
  wheezy. They installed fine in wheezy, then the upgrade to jessie fails.
  
  From the attached logs (scroll to the bottom...):
  
Unpacking ingerman (20131206-4) over (20120607-1) ...
  [...]
Setting up ingerman (20131206-4) ...
/var/lib/dpkg/info/ingerman.postinst: 23: 
  /var/lib/dpkg/info/ingerman.postinst: cannot create 
  /var/lib/ispell/ngerman.compat: Directory nonexistent
 
 [#750540] On Mi, 04 iun 14, 11:41:11, Matthias Urlichs wrote:
 
  ingerman (20131206-4) wird eingerichtet ...
  /var/lib/dpkg/info/ingerman.postinst: 23: 
  /var/lib/dpkg/info/ingerman.postinst: cannot create 
  /var/lib/ispell/ngerman.compat: Directory nonexistent
 
 [#750067] On Sun, Jun 01, 2014 at 11:48:55AM +0200, Holger Levsen wrote:
Setting up aspell-de (20131206-4) ...
touch: cannot touch '/var/lib/aspell/dontremove': No such file or 
  directory
 
 Hi, Roland and submitters,
 
 I am replying to these three bugs together because they are tightly related
 (#750069 and #750540 are indeed the same, merging).

 
 #750069 and #750540: They are fixed by upgrading build-depends to
   dictionaries-common-dev (= 1.23.3) to force up to date debhelper snippets
   dealing harder with /var/lib/ispell availability in upgrades. See attached 
 
   0001-control-Build-Depend-on-dictionaries-common-dev-1.23.patch
 
 #750067: aspell-de 20131206-4 uses a workaround to deal with the problem
  behind #750069 and #750540 for aspell-de (see #748253), but when it tries
  to write /var/lib/aspell it may have already been removed, leading to
  #750067.
 
  If above 0001-control-Build-Depend-on-dictionaries-common-dev-1.23.patch
  patch is applied the dontremove hack becomes meaningless and should be
  removed, see attached
 
  0002-aspell-de.postinst-No-longer-use-dontremove-hack-Clo.patch

Really adding patches also for this bug report. Sorry for the noise, Roland.

-- 
Agustin
From 294c948cb51fe6606e4f86adbd7e6334434349d6 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo agmar...@debian.org
Date: Thu, 5 Jun 2014 17:30:13 +0200
Subject: [PATCH 1/2] control: Build-Depend on dictionaries-common-dev (=
 1.23.3) (Closes: #750069, #750540).

This will force up to date debhelper snippets dealing harder with
/var/lib/$class availability.

Suggested changelog entry:

* debian/control: Build-Depend on dictionaries-common-dev (= 1.23.3) to
  force up to date debhelper snippets dealing harder with
  /var/lib/$class availability (Closes: #750069, #750540).
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 0e2ed24..cfe486d 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Roland Rosenfeld rol...@debian.org
 Uploaders: Rene Engelhard r...@debian.org
 Standards-Version: 3.9.5
 Build-Depends-Indep: ispell (= 3.1.20-12.1), hunspell, aspell (= 0.60.5-2),
- dictionaries-common-dev (= 1.23.2)
+ dictionaries-common-dev (= 1.23.3)
 Build-Depends: debhelper (= 9)
 Homepage: https://www.j3e.de/ispell/igerman98/
 
-- 
2.0.0

From 225cf4cb7caa2ec9deb9a69da33cb1becd3d31dd Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo agmar...@debian.org
Date: Thu, 5 Jun 2014 17:34:40 +0200
Subject: [PATCH 2/2] aspell-de.postinst: No longer use dontremove hack
 (Closes: #750067).

dontremove hack tries to avoid /var/lib/$class deletion by writing a
flag in it, but that dir may have already been removed on upgrades.
Also, if dictionaries-common-dev build-depends is changed to
(= 1.23.3) the hack is no longer meaningful.

Suggested changelog entry:

* aspell-de.postinst: No longer need to use the dontremove hack as we
  also create /var/lib/$class from postinst if needed and it may fail
  for some upgrades (Closes: #750067).
---
 debian/aspell-de.postinst | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/debian/aspell-de.postinst b/debian/aspell-de.postinst
index bb28889..e487876 100644
--- a/debian/aspell-de.postinst
+++ b/debian/aspell-de.postinst
@@ -33,18 +33,11 @@ case $1 in
 ;;
 esac
 
-# Workaround for upgrading from older versions that contained
-# /var/lib/aspell and remove it on upgrade:
-touch /var/lib/aspell/dontremove
-
 # dh_installdeb will replace this with shell code automatically
 # generated by other debhelper scripts.
 
 #DEBHELPER#
 
-# And undo the workaround again:
-rm -f /var/lib/aspell/dontremove
-
 exit 0
 
 # vim:sw=4:
-- 
2.0.0

Bug#750069: ingerman, iswiss: fail to upgrade from wheezy

[Agustin Martin]

On Thu, Jun 05, 2014 at 06:55:41PM +0200, Agustin Martin wrote:
 [#750069] On Sun, Jun 01, 2014 at 11:54:13AM +0200, Holger Levsen wrote:
  Package: ingerman, iswiss
  Version: 20131206-4
  Severity: serious
  
  during a test with piuparts I noticed your packages fail to upgrade from
  wheezy. They installed fine in wheezy, then the upgrade to jessie fails.
  
  From the attached logs (scroll to the bottom...):
  
Unpacking ingerman (20131206-4) over (20120607-1) ...
  [...]
Setting up ingerman (20131206-4) ...
/var/lib/dpkg/info/ingerman.postinst: 23: 
  /var/lib/dpkg/info/ingerman.postinst: cannot create 
  /var/lib/ispell/ngerman.compat: Directory nonexistent
 
 [#750540] On Mi, 04 iun 14, 11:41:11, Matthias Urlichs wrote:
 
  ingerman (20131206-4) wird eingerichtet ...
  /var/lib/dpkg/info/ingerman.postinst: 23: 
  /var/lib/dpkg/info/ingerman.postinst: cannot create 
  /var/lib/ispell/ngerman.compat: Directory nonexistent
 
 [#750067] On Sun, Jun 01, 2014 at 11:48:55AM +0200, Holger Levsen wrote:
Setting up aspell-de (20131206-4) ...
touch: cannot touch '/var/lib/aspell/dontremove': No such file or 
  directory
 
 Hi, Roland and submitters,
 
 I am replying to these three bugs together because they are tightly related
 (#750069 and #750540 are indeed the same, merging).

 
 #750069 and #750540: They are fixed by upgrading build-depends to
   dictionaries-common-dev (= 1.23.3) to force up to date debhelper snippets
   dealing harder with /var/lib/ispell availability in upgrades. See attached 
 
   0001-control-Build-Depend-on-dictionaries-common-dev-1.23.patch
 
 #750067: aspell-de 20131206-4 uses a workaround to deal with the problem
  behind #750069 and #750540 for aspell-de (see #748253), but when it tries
  to write /var/lib/aspell it may have already been removed, leading to
  #750067.
 
  If above 0001-control-Build-Depend-on-dictionaries-common-dev-1.23.patch
  patch is applied the dontremove hack becomes meaningless and should be
  removed, see attached
 
  0002-aspell-de.postinst-No-longer-use-dontremove-hack-Clo.patch

Really adding patches also for this bug report. Sorry for the noise, Roland.

-- 
Agustin
From 294c948cb51fe6606e4f86adbd7e6334434349d6 Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo agmar...@debian.org
Date: Thu, 5 Jun 2014 17:30:13 +0200
Subject: [PATCH 1/2] control: Build-Depend on dictionaries-common-dev (=
 1.23.3) (Closes: #750069, #750540).

This will force up to date debhelper snippets dealing harder with
/var/lib/$class availability.

Suggested changelog entry:

* debian/control: Build-Depend on dictionaries-common-dev (= 1.23.3) to
  force up to date debhelper snippets dealing harder with
  /var/lib/$class availability (Closes: #750069, #750540).
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 0e2ed24..cfe486d 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Roland Rosenfeld rol...@debian.org
 Uploaders: Rene Engelhard r...@debian.org
 Standards-Version: 3.9.5
 Build-Depends-Indep: ispell (= 3.1.20-12.1), hunspell, aspell (= 0.60.5-2),
- dictionaries-common-dev (= 1.23.2)
+ dictionaries-common-dev (= 1.23.3)
 Build-Depends: debhelper (= 9)
 Homepage: https://www.j3e.de/ispell/igerman98/
 
-- 
2.0.0

From 225cf4cb7caa2ec9deb9a69da33cb1becd3d31dd Mon Sep 17 00:00:00 2001
From: Agustin Martin Domingo agmar...@debian.org
Date: Thu, 5 Jun 2014 17:34:40 +0200
Subject: [PATCH 2/2] aspell-de.postinst: No longer use dontremove hack
 (Closes: #750067).

dontremove hack tries to avoid /var/lib/$class deletion by writing a
flag in it, but that dir may have already been removed on upgrades.
Also, if dictionaries-common-dev build-depends is changed to
(= 1.23.3) the hack is no longer meaningful.

Suggested changelog entry:

* aspell-de.postinst: No longer need to use the dontremove hack as we
  also create /var/lib/$class from postinst if needed and it may fail
  for some upgrades (Closes: #750067).
---
 debian/aspell-de.postinst | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/debian/aspell-de.postinst b/debian/aspell-de.postinst
index bb28889..e487876 100644
--- a/debian/aspell-de.postinst
+++ b/debian/aspell-de.postinst
@@ -33,18 +33,11 @@ case $1 in
 ;;
 esac
 
-# Workaround for upgrading from older versions that contained
-# /var/lib/aspell and remove it on upgrade:
-touch /var/lib/aspell/dontremove
-
 # dh_installdeb will replace this with shell code automatically
 # generated by other debhelper scripts.
 
 #DEBHELPER#
 
-# And undo the workaround again:
-rm -f /var/lib/aspell/dontremove
-
 exit 0
 
 # vim:sw=4:
-- 
2.0.0