Bug#1063999: libhdf4-0-alt: is not multi-arch compatible

[Yuriy M. Kaminskiy]

Package: libhdf4-0-alt
Version: 4.2.15-5
Severity: normal
Tags: patch
X-Debbugs-Cc: yumkam+deb...@gmail.com

Dear Maintainer,

libhdf4 is dependency of libgdal32 and indirect dependency of opencv.
Lack of Multi-Arch compatibility prevents co-installation of libraries
on M-A systems.
*-dev packages looks not M-A compatible due to include/hdf/h4config.h, and
was not priority for me.
Patch attached.

Disclaimer: I was able to co-install M-A-patched
libgdal32/libogdi4.1/libarmadillo11/libhdf4 libraries on stable/bookworm,
but have no way to verify if there are any problems with their use.

Patch for 4.2.16-3 is not tested at all.

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'proposed-updates')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-17-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libhdf4-0-alt depends on:
ii  libc62.36-9+deb12u4
ii  libjpeg62-turbo  1:2.1.5-2
ii  libtirpc31.3.3+ds-1
ii  zlib1g   1:1.2.13.dfsg-1

libhdf4-0-alt recommends no packages.

Versions of packages libhdf4-0-alt suggests:
pn  hdf4-tools   
pn  libhdf4-alt-dev  
pn  libhdf4-doc  

-- no debconf information
Note: debhelper bump required for substitutions in *.install

diff -Nru libhdf4-4.2.15/debian/changelog libhdf4-4.2.15/debian/changelog
--- libhdf4-4.2.15/debian/changelog 2022-12-01 13:28:15.0 +0300
+++ libhdf4-4.2.15/debian/changelog 2024-02-14 23:18:22.0 +0300
@@ -1,3 +1,11 @@
+libhdf4 (4.2.15-5.1~local1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix Multi-Arch.
+- Bump compat to 13.
+
+ -- Yuriy M. Kaminskiy   Wed, 14 Feb 2024 23:18:22 
+0300
+
 libhdf4 (4.2.15-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru libhdf4-4.2.15/debian/control libhdf4-4.2.15/debian/control
--- libhdf4-4.2.15/debian/control   2022-11-27 20:47:57.0 +0300
+++ libhdf4-4.2.15/debian/control   2024-02-14 23:18:22.0 +0300
@@ -4,7 +4,7 @@
Johan Van de Wauw 
 Section: graphics
 Priority: optional
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: debhelper-compat (= 13),
bison,
chrpath,
flex,
@@ -21,6 +21,7 @@
 
 Package: libhdf4-0
 Architecture: any
+Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
@@ -62,6 +63,7 @@
 
 Package: libhdf4-0-alt
 Architecture: any
+Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
@@ -128,6 +130,7 @@
 
 Package: hdf4-tools
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
diff -Nru libhdf4-4.2.15/debian/control.in libhdf4-4.2.15/debian/control.in
--- libhdf4-4.2.15/debian/control.in2022-11-27 20:48:02.0 +0300
+++ libhdf4-4.2.15/debian/control.in2024-02-14 23:18:22.0 +0300
@@ -4,7 +4,7 @@
Johan Van de Wauw 
 Section: graphics
 Priority: optional
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: debhelper-compat (= 13),
bison,
chrpath,
flex,
@@ -21,6 +21,7 @@
 
 Package: @PACKAGE@-@SOVER@
 Architecture: any
+Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
@@ -62,6 +63,7 @@
 
 Package: @PACKAGE@-@SOVER@-alt
 Architecture: any
+Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends}
@@ -128,6 +130,7 @@
 
 Package: hdf4-tools
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
diff -Nru libhdf4-4.2.15/debian/libhdf4-0-alt.install 
libhdf4-4.2.15/debian/libhdf4-0-alt.install
--- libhdf4-4.2.15/debian/libhdf4-0-alt.install 2021-09-14 18:02:36.0 
+0300
+++ libhdf4-4.2.15/debian/libhdf4-0-alt.install 2024-02-14 23:18:22.0 
+0300
@@ -1 +1 @@
-usr/lib-alt/lib*.so.0* usr/lib
+usr/lib-alt/${DEB_HOST_MULTIARCH}/lib*.so.0* usr/lib/${DEB_HOST_MULTIARCH}
diff -Nru libhdf4-4.2.15/debian/libhdf4-0.install 
libhdf4-4.2.15/debian/libhdf4-0.install
--- libhdf4-4.2.15/debian/libhdf4-0.install 2021-09-14 18:02:36.0 
+0300
+++ libhdf4-4.2.15/debian/libhdf4-0.install 2024-02-14 23:18:22.0 
+0300
@@ -1 +1 @@
-usr/lib/lib*.so.0*
+usr/lib/*/lib*.so.0*
diff -Nru libhdf4-4.2.15/debian/libhdf4-alt-dev.install 
libhdf4-4.2.15/debian/libhdf4-alt-dev.install
--- libhdf4-4.2.15/debian/libhdf4-alt-dev.install   2021-09-14 
18:02:36.0 +0300
+++ libhdf4-4.2.15/debian/libhdf4-alt-dev.install   2024-02-14 
23:18

Bug#1063996: libogdi4.1: is not multi-arch compatible

[Yuriy M. Kaminskiy]

Package: libogdi4.1
Version: 4.1.0+ds-6
Severity: normal
Tags: patch

Dear Maintainer,

libogdi4 is dependency of libgdal32 and indirect dependency of opencv.
Lack of multi-arch markup and compatibility prevents their
co-installation on multi-arch systems.

.pc moved from /usr/share/pkgconfig to /usr/lib/@DEB_HOST_MULTIARCH@/pkgconfig
debhelper bump required for use of substitutions in .install

Patch attached.

Disclaimer: I was able to co-install M-A-patched
libgdal32/libogdi4.1/libarmadillo11/libhdf4 libraries on stable/bookworm,
but have no way to verify if there are any problems with their use.

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'proposed-updates')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-17-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libogdi4.1 depends on:
ii  libc6  2.36-9+deb12u4
ii  libexpat1  2.5.0-1
ii  libtirpc3  1.3.3+ds-1
ii  zlib1g 1:1.2.13.dfsg-1

libogdi4.1 recommends no packages.

Versions of packages libogdi4.1 suggests:
ii  ogdi-bin  4.1.0+ds-6

-- no debconf information
Notes:
.pc moved from /usr/share/pkgconfig to /usr/lib/@DEB_HOST_MULTIARCH@/pkgconfig
debhelper bump required for substitutions in .install

diff -Nru ogdi-dfsg-4.1.0+ds/debian/changelog 
ogdi-dfsg-4.1.0+ds/debian/changelog
--- ogdi-dfsg-4.1.0+ds/debian/changelog 2022-12-01 15:52:30.0 +0300
+++ ogdi-dfsg-4.1.0+ds/debian/changelog 2024-02-14 23:56:13.0 +0300
@@ -1,3 +1,11 @@
+ogdi-dfsg (4.1.0+ds-6.1~local1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump debheler compat to 13.
+  * Fix Multi-Arch.
+
+ -- Yuriy M. Kaminskiy   Wed, 14 Feb 2024 23:56:13 
+0300
+
 ogdi-dfsg (4.1.0+ds-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru ogdi-dfsg-4.1.0+ds/debian/control ogdi-dfsg-4.1.0+ds/debian/control
--- ogdi-dfsg-4.1.0+ds/debian/control   2022-11-28 18:21:45.0 +0300
+++ ogdi-dfsg-4.1.0+ds/debian/control   2024-02-14 23:53:25.0 +0300
@@ -3,7 +3,7 @@
 Uploaders: Francesco Paolo Lovergine 
 Section: libs
 Priority: optional
-Build-Depends: debhelper-compat (= 12),
+Build-Depends: debhelper-compat (= 13),
libexpat1-dev,
pkg-config,
tcl-dev (>= 8.4),
@@ -36,6 +36,7 @@
 
 Package: libogdi4.1
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Suggests: ogdi-bin
@@ -52,6 +53,7 @@
 
 Package: ogdi-bin
 Architecture: any
+Multi-Arch: foreign
 Section: science
 Depends: ${shlibs:Depends},
  ${misc:Depends}
diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs 
ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs
--- ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs   2021-06-13 15:17:54.0 
+0300
+++ ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.dirs   2024-02-14 23:52:43.0 
+0300
@@ -1 +1 @@
-usr/lib/ogdi/4.1
+usr/lib/${DEB_HOST_MULTIARCH}/ogdi/4.1
diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install 
ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install
--- ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install2021-06-13 
15:12:37.0 +0300
+++ ogdi-dfsg-4.1.0+ds/debian/libogdi4.1.install2024-02-14 
23:50:26.0 +0300
@@ -1,3 +1,3 @@
-usr/lib/libogdi.so.*
-usr/lib/libvpf.so.*
-usr/lib/ogdi/*.so  usr/lib/ogdi/4.1
+usr/lib/*/libogdi.so.*
+usr/lib/*/libvpf.so.*
+usr/lib/${DEB_HOST_MULTIARCH}/ogdi/*.so
usr/lib/${DEB_HOST_MULTIARCH}/ogdi/4.1
diff -Nru ogdi-dfsg-4.1.0+ds/debian/libogdi-dev.install 
ogdi-dfsg-4.1.0+ds/debian/libogdi-dev.install
--- ogdi-dfsg-4.1.0+ds/debian/libogdi-dev.install   2020-11-12 
08:35:27.0 +0300
+++ ogdi-dfsg-4.1.0+ds/debian/libogdi-dev.install   2024-02-14 
23:51:03.0 +0300
@@ -1,5 +1,5 @@
-usr/lib/lib*.so
+usr/lib/*/lib*.so
 usr/include/ecs.h  usr/include/ogdi
 usr/include/ecs_util.h usr/include/ogdi
 ogdi-configusr/bin/
-ogdi.pcusr/share/pkgconfig/
+ogdi.pcusr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/
diff -Nru ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch 
ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch
--- ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch2021-06-13 
15:14:04.0 +0300
+++ ogdi-dfsg-4.1.0+ds/debian/patches/modules_path.patch2024-02-14 
23:54:36.0 +0300
@@ -9,7 +9,7 @@
$(EXPAT_INCLUDE)
  
 -CFLAGS= $(INCLUDES) $(COMMON_CFLAGS) 
-DMODULES_PATH="\"$(INST_LIB)/ogdi/\""
-+CFLAGS= $(INCLUDES) $(COMMON_CFLAGS) 
-DMODULES_PATH="\"/usr/lib/ogdi/4.1/\""
++CFLAGS= $(INCLUDES) $(COMMON_CFLAGS) 
-DMOD

Bug#1000718: Request: Enable cross-build Multi-Arch

[Yuriy M. Kaminskiy]

Package: libarmadillo11
Version: 1:11.4.2+dfsg-1
Tags: patch
Followup-For: Bug #1000718

Dear Maintainer,

libarmadillo11 is dependency of libgdal32 and indirectly dependency of
opencv, thus lack of M-A compatibility prevents co-installation.
This is not only [cross-]build problem, but affects normal users.
Patch attached.
Disclaimer: I was able to co-install M-A-patched
libgdal32/libogdi4.1/libarmadillo11/libhdf4 libraries on stable/bookworm,
but have no way to verify if there are any problems with their use.

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'proposed-updates')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-17-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libarmadillo11 depends on:
ii  libarpack2   3.8.0-3
ii  libblas3 [libblas.so.3]  3.11.0-2
ii  libc62.36-9+deb12u4
ii  libgcc-s112.2.0-14
ii  liblapack3 [liblapack.so.3]  3.11.0-2
ii  libstdc++6   12.2.0-14
ii  libsuperlu5  5.3.0+dfsg1-2+b1

libarmadillo11 recommends no packages.

libarmadillo11 suggests no packages.

-- no debconf information
Note: -dev is likely not multi-arch safe.

diff -Nru armadillo-11.4.2+dfsg/debian/changelog 
armadillo-11.4.2+dfsg/debian/changelog
--- armadillo-11.4.2+dfsg/debian/changelog  2022-10-29 17:12:52.0 
+0300
+++ armadillo-11.4.2+dfsg/debian/changelog  2024-02-14 23:06:47.0 
+0300
@@ -1,3 +1,10 @@
+armadillo (1:11.4.2+dfsg-1.1~local1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Multi-Arch.
+
+ -- Yuriy M. Kaminskiy   Wed, 14 Feb 2024 23:06:47 
+0300
+
 armadillo (1:11.4.2+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru armadillo-11.4.2+dfsg/debian/control 
armadillo-11.4.2+dfsg/debian/control
--- armadillo-11.4.2+dfsg/debian/control2022-10-29 17:11:49.0 
+0300
+++ armadillo-11.4.2+dfsg/debian/control2024-02-14 23:05:31.0 
+0300
@@ -28,6 +28,7 @@
 Package: libarmadillo11
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: streamlined C++ linear algebra library
  Armadillo is a streamlined C++ linear algebra library (matrix maths)
diff -Nru armadillo-11.4.2+dfsg/debian/libarmadillo11.install 
armadillo-11.4.2+dfsg/debian/libarmadillo11.install
--- armadillo-11.4.2+dfsg/debian/libarmadillo11.install 2022-10-29 
17:11:49.0 +0300
+++ armadillo-11.4.2+dfsg/debian/libarmadillo11.install 2024-02-14 
23:04:24.0 +0300
@@ -1 +1 @@
-usr/lib/*.so.* usr/lib
+usr/lib/*/*.so.*
diff -Nru armadillo-11.4.2+dfsg/debian/libarmadillo-dev.install 
armadillo-11.4.2+dfsg/debian/libarmadillo-dev.install
--- armadillo-11.4.2+dfsg/debian/libarmadillo-dev.install   2022-10-29 
17:11:49.0 +0300
+++ armadillo-11.4.2+dfsg/debian/libarmadillo-dev.install   2024-02-14 
23:06:47.0 +0300
@@ -1,3 +1,4 @@
 usr/include/* usr/include
-usr/lib/lib*.so usr/lib
+usr/lib/*/lib*.so
+usr/lib/*/pkgconfig/*
 usr/share/Armadillo/CMake/*.cmake usr/share/doc/libarmadillo-dev
diff -Nru armadillo-11.4.2+dfsg/debian/rules armadillo-11.4.2+dfsg/debian/rules
--- armadillo-11.4.2+dfsg/debian/rules  2022-10-29 17:11:49.0 +0300
+++ armadillo-11.4.2+dfsg/debian/rules  2024-02-14 23:06:47.0 +0300
@@ -13,7 +13,7 @@
 
 build-stamp:
dh_testdir
-   dh_auto_configure --buildsystem=cmake --builddirectory=. -- -D 
INSTALL_LIB_DIR=lib -D CMAKE_INpppSTALL_PREFIX_INITIALIZED_TO_DEFAULT:BOOL=ON  
. # specified to install to the debian/tmp directory.
+   dh_auto_configure --buildsystem=cmake --builddirectory=. -- -D 
INSTALL_LIB_DIR=lib/${DEB_HOST_MULTIARCH} -D 
CMAKE_INpppSTALL_PREFIX_INITIALIZED_TO_DEFAULT:BOOL=ON  . # specified to 
install to the debian/tmp directory.
$(MAKE)
touch $@
 
@@ -45,8 +45,6 @@
dh_installdocs -a
dh_installexamples -a
dh_install -a --sourcedir=debian/tmp
-   mkdir -p 
debian/libarmadillo-dev/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/
-   cp debian/tmp/usr/lib/pkgconfig/armadillo.pc 
debian/libarmadillo-dev/usr/lib/${DEB_HOST_MULTIARCH}/pkgconfig/
dh_installman -a
dh_link -a
dh_strip -a

Bug#1063994: libgdal32: library is not marked for multi-arch

[Yuriy M. Kaminskiy]

Package: libgdal32
Version: 3.6.2+dfsg-1
Severity: normal
Tags: patch

Dear Maintiner,
libgdal32 is installed in multi-arch compatible way, but not marked as
Multi-Arch. This prevents co-installing dependent libraries (notably,
OpenCV).
gdal-bin looks provied only CLI, thus should be matched as M-A: foreign.
gdal-plugins contain only some config in multi-arch compatible location,
so probably M-A: same
libgdal-dev package is definitely not multi-arch compatible (due to at least
bin/gdal-config and include/gdal/cpl_config.h)
Trivial patch attached.
Disclaimer: I was able to co-install M-A-patched
libgdal32/libogdi4.1/libarmadillo11/libhdf4 libraries on stable/bookworm,
but have no way to verify if there are any problems with their use.

-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'proposed-updates')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 6.1.0-17-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libgdal32 depends on:
ii  gdal-data3.6.2+dfsg-1.1~local1
ii  gdal-plugins 3.6.2+dfsg-1.1~local1
ii  libarmadillo11   1:11.4.2+dfsg-1.1~local1
ii  libblosc11.21.3+ds-1
ii  libc62.36-9+deb12u4
ii  libcfitsio10 4.2.0-3
ii  libcurl4 7.88.1-10+deb12u5
ii  libdeflate0  1.14-1
ii  libexpat12.5.0-1
ii  libfreexl1   1.0.6-2
ii  libfyba0 4.1.1-8
ii  libgcc-s112.2.0-14
ii  libgeos-c1v5 3.11.1-1
ii  libgeotiff5  1.7.1-2+b1
ii  libgif7  5.2.1-2.5
ii  libhdf4-0-alt4.2.15-5.1~local1
ii  libhdf5-103-11.10.8+repack1-1
ii  libheif1 1.15.1-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjson-c5   0.16-2
ii  libkmlbase1  1.3.0-10
ii  libkmldom1   1.3.0-10
ii  libkmlengine11.3.0-10
ii  liblz4-1 1.9.4-1
ii  liblzma5 5.4.1-0.2
ii  libmariadb3  1:10.11.6-0+deb12u1
ii  libnetcdf19  1:4.9.0-3+b1
ii  libodbc2 2.3.11-2+deb12u1
ii  libodbcinst2 2.3.11-2+deb12u1
ii  libogdi4.1   4.1.0+ds-6.1~local1
ii  libopenjp2-7 2.5.0-2
ii  libpcre2-8-0 10.42-1
ii  libpng16-16  1.6.39-2
ii  libpoppler12622.12.0-2+b1
ii  libpq5   15.6-0+deb12u1
ii  libproj259.1.1-1+b1
ii  libqhull-r8.02020.2-5
ii  libspatialite7   5.0.1-3
ii  libsqlite3-0 3.40.1-2
ii  libssl3  3.0.11-1~deb12u2
ii  libstdc++6   12.2.0-14
ii  libtiff6 4.5.0-6+deb12u1
ii  libwebp7 1.2.4-0.2+deb12u1
ii  libxerces-c3.2   3.2.4+debian-1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  libzstd1 1.5.4+dfsg2-5
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages libgdal32 recommends:
ii  proj-bin  9.1.1-1+b1

libgdal32 suggests no packages.

-- no debconf information
diff -Nru gdal-3.6.2+dfsg/debian/changelog gdal-3.6.2+dfsg/debian/changelog
--- gdal-3.6.2+dfsg/debian/changelog2023-01-05 11:20:25.0 +0300
+++ gdal-3.6.2+dfsg/debian/changelog2024-02-15 00:33:27.0 +0300
@@ -1,3 +1,10 @@
+gdal (3.6.2+dfsg-1.1~local1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark as Multi-Arch.
+
+ -- Yuriy M. Kaminskiy   Thu, 15 Feb 2024 00:33:27 
+0300
+
 gdal (3.6.2+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru gdal-3.6.2+dfsg/debian/control gdal-3.6.2+dfsg/debian/control
--- gdal-3.6.2+dfsg/debian/control  2023-01-05 10:58:52.0 +0300
+++ gdal-3.6.2+dfsg/debian/control  2024-02-15 00:33:27.0 +0300
@@ -67,6 +67,7 @@
 
 Package: libgdal32
 Architecture: any
+Multi-Arch: same
 Section: libs
 Depends: gdal-data (>= ${source:Version}),
  gdal-plugins (>= ${binary:Version}),
@@ -159,6 +160,7 @@
 
 Package: gdal-bin
 Architecture: any
+Multi-Arch: foreign
 Depends: python3-gdal (= ${binary:Version}),
  ${python3:Depends},
  ${shlibs:Depends},
@@ -213,6 +215,7 @@
 
 Package: gdal-plugins
 Architecture: any
+Multi-Arch: same
 Depends: ${misc:Depends}
 Description: Geospatial Data Abstraction Library - Plugins
  GDAL is a translator library for raster geospatial data formats.

Bug#981983: libnewlib-arm-none-eabi: CFLAGS used for host object instead of target objects

[Yuriy M. Kaminskiy]

Package: libnewlib-arm-none-eabi
Version: 3.3.0-1
Severity: normal

Dear Maintainer,

newlib is supposed to be built with `-f{data,function}-sections`, and
newlib-nano is supposed to be built with also `-Os -fshort-wchar`:

=== cut debian/rules ===
CFLAGS := CFLAGS="-g -O2 -ffunction-sections -fdata-sections"
CFLAGS_NANO := CFLAGS="-g -Os -ffunction-sections -fdata-sections -fshort-wchar"
=== cut ===

Unfortunately, this is cross-compilation, and those flags are used to compile 
only
*build host* objects, and not for *target* objects. So, all target libraries 
are built
with wrong cflags.

This is especially bad for newlib-nano, as `-fshort-wchar` is alters ABI
(and lack of `-f*-sections` prevents removing unused data/functions on link
time, which is important for ram/flash limited targets).

(actually, I'm not sure if `-fshort-wchar` was that much good idea: you either 
don't
use `wchar_t` at all, or you want "proper" 32-bit one; and given that 
`-fshort-wchar`
is not automatically passed by `-specs=nano.specs`, this requires non-trivial 
and flaky
auto-configuration from library users, e.g. 
https://github.com/RIOT-OS/RIOT/pull/5627 ).

Fix:
CFLAGS += CFLAGS_FOR_TARGET="-g -O2 -ffunction-sections -fdata-sections"
CFLAGS_NANO += CFLAGS_FOR_TARGET="-g -Os -ffunction-sections -fdata-sections 
-fshort-wchar"

Disclaimer: noticed while building local backport; verified with buildd's logs
  
https://buildd.debian.org/status/fetch.php?pkg=newlib=all=3.3.0-1=1583408649=1
and inspecting lib*.a from "official" packages from sid/bullseye, buster, 
stretch
(confirmed all was built without -f{funciton,data}-section). Bugreport metadata
altered to match sid version.

-- System Information:
Debian Release: 9.13
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 
'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-14-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnewlib-arm-none-eabi depends on:
ii  libnewlib-dev  3.3.0-1

Versions of packages libnewlib-arm-none-eabi recommends:
ii  gcc-arm-none-eabi   15:8-2019-q3-1
ii  libstdc++-arm-none-eabi-ne  15:8-2019-q3-1

Versions of packages libnewlib-arm-none-eabi suggests:
pn  libnewlib-doc  

-- no debconf information

Bug#956763: qemu-system-gui: incorrectly marked as Multi-Arch: foreign

[Yuriy M. Kaminskiy]

Package: qemu-system-gui
Version: 1:3.1+dfsg-8+deb10u4
Severity: normal

Dear Maintainer,

This package provides arch-dependent co-installable plugin-type shared 
libraries,
and thus should be marked as
Multi-Arch: same

-- System Information:
Debian Release: 9.12
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-11-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemu-system-gui depends on:
ii  libc6   2.24-11+deb9u4
ii  libcairo2   1.14.8-1
ii  libepoxy0   1.3.1-2
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2+deb9u2
ii  libgtk-3-0  3.22.11-1
ii  libpulse0   10.0-1+deb9u1
ii  libvte-2.91-0   0.46.1-1
ii  libx11-62:1.6.4-3+deb9u1

qemu-system-gui recommends no packages.

qemu-system-gui suggests no packages.

-- no debconf information

Bug#747537: wip patch (Re: mupdf: unable to enter non-ascii characters while searching)

[Yuriy M. Kaminskiy]

Control: tags -1 upstream patch
thanks

Incomplete patch for mupdf-x11 1.15 attached (works with utf-8 locales; there 
are display problems in some non-utf-8 locales - it is possible to input [ascii 
and non-ascii] symbols, but search string and prompt is invisible); XKB (tested 
with cyrillic keyboard layout) and IM input seems works (tested with 
LANG=ja_JP.UTF-8 and uim/anthy).
From: Yuriy M. Kaminskiy 
Date: Wed, 04 Jul 2018 22:19:10 +
Subject: X11: add basic support for i18n in search

Index: mupdf-1.15.0+ds1/platform/x11/x11_main.c
===
--- mupdf-1.15.0+ds1.orig/platform/x11/x11_main.c
+++ mupdf-1.15.0+ds1/platform/x11/x11_main.c
@@ -18,6 +18,10 @@
 #include 
 #include 
 
+#ifdef X_HAVE_UTF8_STRING
+#include 
+#endif
+
 #define mupdf_icon_bitmap_16_width 16
 #define mupdf_icon_bitmap_16_height 16
 static unsigned char mupdf_icon_bitmap_16_bits[] = {
@@ -69,6 +73,11 @@ void windrawstringxor(pdfapp_t *app, int
 void cleanup(pdfapp_t *app);
 
 static Display *xdpy;
+#ifdef X_HAVE_UTF8_STRING
+static XIM xim;
+static XIC xic;
+static XFontSet xfs;
+#endif
 static Atom XA_CLIPBOARD;
 static Atom XA_TARGETS;
 static Atom XA_TIMESTAMP;
@@ -202,6 +211,70 @@ static void winopen(void)
 	if (!xdpy)
 		fz_throw(gapp.ctx, FZ_ERROR_GENERIC, "cannot open display");
 
+#ifdef X_HAVE_UTF8_STRING
+	if (XSupportsLocale())
+   	{
+		char **missing_charset_list = NULL;
+		int missing_charset_count = 0;
+		char *def_string = NULL;
+		char *fontlist = NULL;
+		int i;
+
+		XSetLocaleModifiers("");
+		xim = XOpenIM(xdpy, NULL, "mupdf", "MuPDF");
+		if (!xim)
+		{
+			fprintf(stderr, "warning: unable to open IM, fallback to @im=none\n");
+			XSetLocaleModifiers("@im=none");
+			xim = XOpenIM(xdpy, NULL, "mupdf", "MuPDF");
+		}
+		if (!xim)
+		{
+			fprintf(stderr, "warning: unable to open IM\n");
+		}
+		if (fontlist == NULL)
+		{
+			fontlist =
+"-*-Fixed-Medium-R-Normal-*-13-*-*-*-*-*" ","
+"-*-*-Medium-R-*-*-13-*-*-*-*-*";
+		}
+		xfs = XCreateFontSet(xdpy, fontlist,
+_charset_list, _charset_count,
+			   	_string);
+		if (!xfs)
+		{
+			fprintf(stderr, "warning: unable to open fontset %s\n",
+	fontlist);
+		}
+#if 0 /* DEBUG */
+		else
+		{
+			XFontStruct **fonts = NULL;
+			char **fontNames = NULL;
+			int numFonts = XFontsOfFontSet(xfs, , );
+
+			fprintf(stderr, "base font: %s\n", XBaseFontNameListOfFontSet(xfs));
+			fprintf(stderr, "locale: %s\n", XLocaleOfFontSet(xfs));
+			for (i = 0; i < numFonts; i++)
+fprintf(stderr, "font%d: %s, asc: %d, desc: %d\n", i, fontNames[i], fonts[i]->ascent, fonts[i]->descent);
+		}
+		if (missing_charset_count)
+		{
+			for(i = 0; i < missing_charset_count; i++)
+fprintf(stderr, "warning: missing charset: %s\n",
+	   	missing_charset_list[i]);
+		}
+		if (def_string)
+			fprintf(stderr, "warning: missing characters will be replaced with '%s'\n", def_string);
+#endif
+		if (missing_charset_list)
+			XFreeStringList(missing_charset_list);
+	}
+   	else
+	{
+		fprintf(stderr, "warning: locale is not supported by X\n");
+	}
+#endif
 	XA_CLIPBOARD = XInternAtom(xdpy, "CLIPBOARD", False);
 	XA_TARGETS = XInternAtom(xdpy, "TARGETS", False);
 	XA_TIMESTAMP = XInternAtom(xdpy, "TIMESTAMP", False);
@@ -238,6 +311,17 @@ static void winopen(void)
 		fz_throw(gapp.ctx, FZ_ERROR_GENERIC, "cannot create window");
 
 	XSetWindowColormap(xdpy, xwin, ximage_get_colormap());
+#ifdef X_HAVE_UTF8_STRING
+	if (xim)
+   	{
+		xic = XCreateIC(xim, XNInputStyle,
+XIMPreeditNothing | XIMStatusNothing,
+XNClientWindow, xwin,
+XNFocusWindow, xwin,
+NULL );
+		XSetICFocus(xic);
+	}
+#endif
 	XSelectInput(xdpy, xwin,
 		StructureNotifyMask | ExposureMask | KeyPressMask |
 		PointerMotionMask | ButtonPressMask | ButtonReleaseMask);
@@ -362,6 +446,11 @@ void cleanup(pdfapp_t *app)
 
 	XFreeGC(xdpy, xgc);
 
+#ifdef X_HAVE_UTF8_STRING
+	if (xic) XDestroyIC(xic);
+	if (xim) XCloseIM(xim);
+	if (xfs) XFreeFontSet(xdpy, xfs);
+#endif
 	XCloseDisplay(xdpy);
 
 	fz_drop_context(ctx);
@@ -437,6 +526,10 @@ void winresize(pdfapp_t *app, int w, int
 		while (1)
 		{
 			XNextEvent(xdpy, );
+#ifdef X_HAVE_UTF8_STRING
+			if (XFilterEvent(, xwin))
+continue;
+#endif
 			if (xevt.type == ConfigureNotify)
 			{
 width = xevt.xconfigure.width;
@@ -624,6 +717,11 @@ void windrawstringxor(pdfapp_t *app, int
 
 	XSetForeground(xdpy, xgc, WhitePixel(xdpy, DefaultScreen(xdpy)));
 
+#ifdef X_HAVE_UTF8_STRING
+	if (xfs)
+		Xutf8DrawString(xdpy, xwin, xfs, xgc, x, y, s, strlen(s));
+	else
+#endif
 	XDrawString(xdpy, xwin, xgc, x, y, s, strlen(s));
 	XFlush(xdpy);
 
@@ -635,6 +733,11 @@ void windrawstringxor(pdfapp_t *app, int
 void windrawstring(pdfapp_t *app, in

Bug#936048: pinentry: please mark as Multi-Arch: foreign

[Yuriy M. Kaminskiy]

Source: pinentry
Version: 1.0.0-2
Severity: normal
Tags: patch

Dear Maintainer,

As pinentry-* packages provide arch-independent service (text protocol over
stdin/out), please mark them as Multi-Arch: foreign.
Trivial patch (against buster, applicable with fuzz to bullseye) attached.

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-10-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

diff -Nru pinentry-1.1.0/debian/control pinentry-1.1.0/debian/control
--- pinentry-1.1.0/debian/control   2019-04-17 21:38:06.0 +0300
+++ pinentry-1.1.0/debian/control   2019-08-29 15:00:02.0 +0300
@@ -28,6 +28,7 @@
 
 Package: pinentry-curses
 Architecture: any
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
@@ -56,6 +57,7 @@
 
 Package: pinentry-tty
 Architecture: any
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
@@ -84,6 +86,7 @@
 
 Package: pinentry-qt
 Architecture: any
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
@@ -108,6 +111,7 @@
 
 Package: pinentry-qt4
 Architecture: all
+Multi-Arch: foreign
 Depends:
  pinentry-qt (>= ${binary:Version}),
  ${misc:Depends},
@@ -148,6 +152,7 @@
 
 Package: pinentry-fltk
 Architecture: any
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
@@ -175,6 +180,7 @@
 
 Package: pinentry-gnome3
 Architecture: any
+Multi-Arch: foreign
 Depends:
  gcr,
  ${misc:Depends},
@@ -207,6 +213,7 @@
 Package: pinentry-doc
 Section: doc
 Architecture: all
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},

Bug#934480: lxc: please consider adding Multi-Arch marking

[Yuriy M. Kaminskiy]

Package: lxc
Version: 1:2.0.7-2+deb9u2
Severity: wishlist

Dear Maintainer,

Please add Multi-Arch marking to lxc binary packages:

liblxc1, libpam-cgfs[*] can be marked `Multi-Arch: same` without changes;

liblxc-dev probably can be marked `M-A: same` [not sure about /usr/include/*,
needs verification];

lxc likely can be marked `Multi-Arch: foreign`, as it provides
arch-independent services only (CLI/daemons) [needs verification].

(Note [*]: in multi-arch installations, if any foreign-arch tools uses
pam [e.g. sshd:amd64 on :i386 system], it is required to install same set
of libpam-* modules in all enabled arches)

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-10-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxc depends on:
ii  init-system-helpers  1.56~bpo9+1
ii  libapparmor1 2.11.0-3+deb9u2
ii  libc62.24-11+deb9u4
ii  libcap2  1:2.25-1
ii  libgnutls30  3.5.8-5+deb9u4
ii  liblxc1  1:2.0.7-2+deb9u2
ii  libseccomp2  2.3.1-2.1+deb9u1
ii  libselinux1  2.6-3+b3
ii  lsb-base 9.20161125
ii  python3  3.5.3-1
ii  python3-lxc  1:2.0.7-2+deb9u2

Versions of packages lxc recommends:
ii  bridge-utils  1.5-13+deb9u1
ii  debootstrap   1.0.89
ii  dirmngr   2.2.17-3~bpo9+1
ii  dnsmasq-base  2.76-5+deb9u2
ii  gnupg 2.2.17-3~bpo9+1
ii  iptables  1.6.0+snapshot20161117-6
ii  libpam-cgfs   2.0.8-1~bpo9+2~local1
ii  lxcfs 2.0.8-1~bpo9+2~local1
ii  openssl   1.1.0k-1~deb9u1
ii  rsync 3.1.2-1+deb9u2
ii  uidmap1:4.4-4.1

Versions of packages lxc suggests:
pn  apparmor 
pn  btrfs-tools  
ii  lvm2 2.02.168-2

-- no debconf information

Bug#934477: dnsmasq-base: please mark as Multi-Arch: foreign

[Yuriy M. Kaminskiy]

Package: dnsmasq-base
Version: 2.76-5+deb9u2
Severity: normal
Tags: patch

Dear Maintainer,

Please mark dnsmasq* packages as `Multi-Arch: foreign`, as they provide
arch-independent services (network or CLI).
(Untested) patch against testing/sid version attached.

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-10-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dnsmasq-base depends on:
ii  adduser  3.115
ii  libc62.24-11+deb9u4
ii  libdbus-1-3  1.10.28-0+deb9u1
ii  libgmp10 2:6.1.2+dfsg-1
ii  libhogweed4  3.3-1+b2
ii  libidn11 1.33-1
ii  libnetfilter-conntrack3  1.0.6-2
ii  libnettle6   3.3-1+b2
ii  libnfnetlink01.0.1-3

Versions of packages dnsmasq-base recommends:
ii  dns-root-data  2019031302~deb9u1

dnsmasq-base suggests no packages.

-- no debconf information

--- dnsmasq-2.80/debian/control
+++ dnsmasq-2.80/debian/control
@@ -11,6 +11,7 @@
 
 Package: dnsmasq
 Architecture: all
+Multi-Arch: foreign
 Depends: netbase, dnsmasq-base,
  init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6)
 Suggests: resolvconf
@@ -27,6 +28,7 @@
 
 Package: dnsmasq-base
 Architecture: any
+Multi-Arch: foreign
 Depends: adduser, ${shlibs:Depends}
 Breaks: dnsmasq (<< 2.63-1~)
 Replaces: dnsmasq (<< 2.63-1~), dnsmasq-base
@@ -40,6 +42,7 @@
 
 Package: dnsmasq-base-lua
 Architecture: any
+Multi-Arch: foreign
 Depends: adduser, ${shlibs:Depends}
 Breaks: dnsmasq (<< 2.63-1~)
 Replaces: dnsmasq (<< 2.63-1~), dnsmasq-base
@@ -54,6 +57,7 @@
  
 Package: dnsmasq-utils
 Architecture: linux-any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}
 Conflicts: dnsmasq (<<2.40)
 Description: Utilities for manipulating DHCP leases

Bug#934473: uidmap: please mark uidmap as Multi-Arch: foreign

[Yuriy M. Kaminskiy]

Package: uidmap
Version: 1:4.4-4.1
Severity: normal
Tags: patch

Dear Maintainer,

Please mark 'uidmap' package M-A: foreign, as it provides arch-independent
service (CLI) ('passwd' was already fixed by #614321). 
(Untested) patch against sid/bullseye attached (also marks 'login' for 
completeness).

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldstable-debug'), (500, 'oldstable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-10-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages uidmap depends on:
ii  libc62.24-11+deb9u4
ii  libselinux1  2.6-3+b3

uidmap recommends no packages.

uidmap suggests no packages.

-- no debconf information

--- shadow_4.7-2/debian/control.orig2019-07-16 19:48:12.0 +0300
+++ shadow_4.7-2/debian/control 2019-08-11 14:14:21.207388602 +0300
@@ -40,6 +40,7 @@
 
 Package: login
 Architecture: any
+Multi-Arch: foreign
 Essential: yes
 Pre-Depends: ${shlibs:Depends},
  ${misc:Depends},
@@ -69,6 +70,7 @@
 
 Package: uidmap
 Architecture: any
+Multi-Arch: foreign
 Priority: optional
 Depends: ${shlibs:Depends},
  ${misc:Depends}

Bug#925906: sqlite3: FTCBFS: configure fails to find readline.h

[Yuriy M. Kaminskiy]

Control: tag -1 - moreinfo

On 25.06.2019 07:03, Helmut Grohne wrote:

> On Thu, Mar 28, 2019 at 01:14:13PM +0300, Yuriy M. Kaminskiy wrote:
>> When cross-building sqlite3, it fails to detect readline: while
>> actual code wants only  (see src/shell.c.in),
>> but configure.ac checks for ;
> 
> I am unable to reproduce this issue. The public autobuilder cannot
> reproduce it either: http://crossqa.debian.net/src/sqlite3 This is using
> sbuild for performing the build. How does your build environment differ
> to make sqlite3 fail? Please remove the moreinfo tag when providing an
> answer.

I built for armhf on i386/stretch host with pbuilder.

Relevant lines from
http://crossqa.debian.net/build/sqlite3_3.27.2-3_armhf_20190622023957.log
(with mysteriously successful readline.h detection)

checking for library containing readline... no
checking for library containing tgetent... -lncurses
checking for readline in -lreadline... yes
checking for readline.h... (cached) yes

Relevant lines from my (with failing readline.h detection):

checking for library containing readline... no
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... yes
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no

I have no idea what triggers difference (why there are no "checking
readline.h (usability|presence)... " [that is expected to be emitted by 
AC_CHECK_HEADER] in autobuilder log? where that "(cached) yes" comes from?)

FWIW, here are relevant lines from stretch-backports buildd
https://buildd.debian.org/status/fetch.php?pkg=sqlite3=armhf=3.27.2-3%7Ebpo9%2B1=1560524760=0

(native build, *NOT* cross-compiled)

checking for library containing readline... no
checking for library containing tgetent... -ltermcap
checking for readline in -lreadline... yes
checking readline.h usability... no
checking readline.h presence... no
checking for readline.h... no
checking for /usr/include/readline.h... no
checking for /usr/include/readline/readline.h... yes

(Note: there are /(usability|presence)/ lines here; also note that it also 
fails to find readline.h, and fallbacks to below code [which is disabled for 
cross-builds])

>> @@ -548,12 +548,12 @@ if test x"$with_readline" != xno; then
>>  [with_readline_inc=$withval],
>>  [with_readline_inc="auto"])
>>  if test "x$with_readline_inc" = xauto; then
>> -AC_CHECK_HEADER(readline.h, [found="yes"], [
>> +AC_CHECK_HEADER(readline/readline.h, [found="yes"], [
>>  found="no"
>>  if test "$cross_compiling" != yes; then
> 
> From here it becomes irrelevant to cross building. The changed lines
> are not executed during a cross build.

They are still wrong/inconsistent: shell.c wants readline/readline.h,
while they looks for readline.h

>>  for dir in /usr /usr/local /usr/local/readline 
>> /usr/contrib /mingw; do
>> -for subdir in include include/readline; 
>> do
>> -
>> AC_CHECK_FILE($dir/$subdir/readline.h, found=yes)
>> +for subdir in include; do
>> +
>> AC_CHECK_FILE($dir/$subdir/readline/readline.h, found=yes)
>>  if test "$found" = "yes"; then
>>  
>> TARGET_READLINE_INC="-I$dir/$subdir"
>>  break
>>
> 
> Helmut
> 

Bug#925906: sqlite3: FTCBFS: configure fails to find readline.h

[Yuriy M. Kaminskiy]

Source: sqlite3
Version: 3.27.2-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

When cross-building sqlite3, it fails to detect readline: while
actual code wants only  (see src/shell.c.in),
but configure.ac checks for ;

When not cross-building, this mismatch is hidden by search for
readline.h in {various paths}/include/{,readline/}; it always finds
it in /usr/include/readline, adds (useless) -I/usr/include/readline
to cflags and enables readline support.

When cross-building, this search is disabled, thus sqlite3 shell is
(silently) built without readline support.

(For comparison, autoconf/configure.ac only checks for
readline/readline.h, as it should).

Trivial patch attached.

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Index: sqlite3-3.26.0+fossilbc891ac6b/configure.ac
===
--- sqlite3-3.26.0+fossilbc891ac6b.orig/configure.ac
+++ sqlite3-3.26.0+fossilbc891ac6b/configure.ac
@@ -62,7 +62,7 @@
 #
 #This variables define the directory that contain header
 #files for the readline library.  If the compiler is able 
-#to find  on its own, then this can be blank.
+#to find  on its own, then this can be blank.
 #
 #TARGET_EXEEXT
 #
@@ -548,12 +548,12 @@ if test x"$with_readline" != xno; then
[with_readline_inc=$withval],
[with_readline_inc="auto"])
if test "x$with_readline_inc" = xauto; then
-   AC_CHECK_HEADER(readline.h, [found="yes"], [
+   AC_CHECK_HEADER(readline/readline.h, [found="yes"], [
found="no"
if test "$cross_compiling" != yes; then
for dir in /usr /usr/local /usr/local/readline 
/usr/contrib /mingw; do
-   for subdir in include include/readline; 
do
-   
AC_CHECK_FILE($dir/$subdir/readline.h, found=yes)
+   for subdir in include; do
+   
AC_CHECK_FILE($dir/$subdir/readline/readline.h, found=yes)
if test "$found" = "yes"; then

TARGET_READLINE_INC="-I$dir/$subdir"
break

Bug#925880: libsqlite3-0: wrong compiler used for csv.so (potential FTCBFS)

[Yuriy M. Kaminskiy]

On 28.03.2019 12:40, László Böszörményi (GCS) wrote:
>> (It would trigger failure at dh_strip; and, of course, in anything that
>> would try to use this miscompiled csv.so; but currently it is only
>> compiled, but never used, so mistake never noticed).
> I think dh_strip works in normal library paths only (/usr/lib and
> /usr/lib/[multiarch] directories)

No, it strips everything, not only */lib/*. (I accidentally enabled
csv.so installation in locally-build/modified package, and it failed
on cross-build - that's how I discovered this bug).

Bug#925880: libsqlite3-0: wrong compiler used for csv.so (potential FTCBFS)

[Yuriy M. Kaminskiy]

Package: libsqlite3-0
Version: 3.27.2-1
Severity: minor
Tags: patch

Dear Maintainer,

If csv.so will be installed, sqlite3 will FTCBFS, as cvs.so is
compiled with "build" compiler instead of "host"/"target" compiler.

(It would trigger failure at dh_strip; and, of course, in anything that 
would try to use this miscompiled csv.so; but currently it is only 
compiled, but never used, so mistake never noticed).

Patch attached.

P.S. FTR, as of now (sqlite3 3.25.3 or 3.26.0+fossil), the bug on 
single-column csv files that was mentioned at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900277#17
seems fixed.

-- System Information:
Debian Release: 9.6
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsqlite3-0:i386 depends on:
ii  libc6  2.24-11+deb9u3

libsqlite3-0:i386 recommends no packages.

libsqlite3-0:i386 suggests no packages.

-- no debconf information


--- sqlite3-3.26.0+fossilbc891ac6b/debian/rules-dist2018-06-06 
00:47:02.0 +0300
+++ sqlite3-3.26.0+fossilbc891ac6b/debian/rules 2019-01-14 20:14:26.867517570 
+0300
@@ -30,6 +30,12 @@
   export CROSS_BUILDING=yes
 endif
 
+ifeq ($(origin CC),default)
+  HOST_CC ?= $(DEB_HOST_GNU_TYPE)-gcc
+else
+  HOST_CC ?= $(CC)
+endif
+
 export CFLAGS += -O2 -fno-strict-aliasing \
-DSQLITE_SECURE_DELETE -DSQLITE_ENABLE_COLUMN_METADATA \
-DSQLITE_ENABLE_FTS3 -DSQLITE_ENABLE_FTS3_PARENTHESIS \
@@ -80,7 +86,7 @@
 ifneq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
$(MAKE) lemon
 endif
-   cd ext/misc && $(CC) -g -fPIC -I../.. -shared csv.c -o csv.so
+   cd ext/misc && $(HOST_CC) $(LDFLAGS) $(CPPFLAGS) $(CFLAGS) -g -fPIC 
-I../.. -shared csv.c -o csv.so
 
touch $@
 

Bug#790325: libxaw7: obtaining textSink.textProperties by editres triggers sigsegv in application

[Yuriy M. Kaminskiy]

Control: tags -1 fixed-upstream

Almost 4 years later, this bug is still present in stretch and buster.

Similar patch was applied upstream (with minor changes) in 2016-01-01, more 
than three years ago,
commit 4a7626b5127c0eb597cd2b8d0ae3de0286b74d7c

I'd like to point out to commits
ba7321b6a52726cdb9964b82c5111518dc1f437d
and
f5699b698d512bb1060ef53704595d6accf7eb19
from upstream git that fixes other (unrelated) trivial crashing bugs and likely 
worth backporting.

Bug#921874: gf-complete: fix runtime cpu detection and compilation on i386/armhf

[Yuriy M. Kaminskiy]

On 10.02.2019 10:33, Yuriy M. Kaminskiy wrote:
> On 09.02.2019 20:48, Yuriy M. Kaminskiy wrote:
>> 2) it can expose bugs on some cpus, that are not caught by testsuite
>> (e.g. [previous version of] my _mm_extract_epi64 replacement was very
>> buggy - but it was not detected by debian's qemu test [as it only runs
>> only single unit test for gf64, but only gf128 was affected]);
> 
> Just in case, I (ab)used valgrind hook to run complete testsuite for all
> combination of flags for i386 and amd64, incremental debdiff attached (on the 
> top of above).
> 
> Known problems: takes a bit too long to run (2.5 hours for amd64, and even 
> more for i386).

Unfortunately, after playing a bit,
1) runtime cpu detection on i386 was not enabled in sources (so, [on i386] all 
simd code was
compiled, but not used); new patch added;
2) qemu-user in stretch does not parse -cpu in a way this test expect it to (so 
my tests was flawed); I added B-D on version in buster.
3) with (1) & (2) fixed, I found that i386 sse4/pclmul was broken - due to my 
mistake (_mm_extract_epi64 emulation was broken; caught by unit-test); patch 
0001* updated;
4) with (3) fixed, I discovered that my qemu-for-complete-testsuite patch was 
flawed - gf_method should run on same "cpu" as gf_unit (some tests are 
activated only on supporting cpu); see patch 0007* (not for upstream, too 
"hacky") and debian/rules update.

I rebuild and retested package on i386 and amd64, everything seems fine.

New cumulative debdiff attached.
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2018-05-22 
16:43:40.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2019-02-09 
13:29:51.0 +0300
@@ -1,3 +1,13 @@
+gf-complete (1.0.2+2017.04.10.git.ea75cdf-3~bpo9+1~local2) stretch-backports; 
urgency=medium
+
+  * Rebuild for stretch-backports.
+  * Fix i386 simd compilation.
+  * Fix runtime cpudetection.
+  * Fix neon for armhf.
+  * Run complete test suite under qemu.
+
+ -- Yuriy M. Kaminskiy   Sat, 09 Feb 2019 13:29:51 
+0300
+
 gf-complete (1.0.2+2017.04.10.git.ea75cdf-3) unstable; urgency=medium
 
   * remove patch: 0001-temporarily-disable-sse3-and-above.patch (Closes: 
#899296)
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/control 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/control
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/control 2018-05-22 
16:43:40.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/control 2019-02-09 
13:29:51.0 +0300
@@ -7,7 +7,7 @@
  Shengjing Zhu ,
 Build-Depends:
  debhelper (>= 10),
- qemu-user-static [amd64] ,
+ qemu-user-static (>= 1:3.1~) [i386 amd64 armhf] ,
 Standards-Version: 4.1.4
 Homepage: http://jerasure.org/
 Vcs-Git: https://salsa.debian.org/openstack-team/third-party/gf-complete.git
diff -Nru 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0001-Fix-compilation-on-i386.patch
 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0001-Fix-compilation-on-i386.patch
--- 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0001-Fix-compilation-on-i386.patch
  1970-01-01 03:00:00.0 +0300
+++ 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0001-Fix-compilation-on-i386.patch
  2019-02-09 13:29:51.0 +0300
@@ -0,0 +1,27 @@
+From d42fe7d12cdc5f14e1bd9fd13f5d56e2689793dd Mon Sep 17 00:00:00 2001
+From: "Yuriy M. Kaminskiy" 
+Date: Sat, 9 Feb 2019 12:55:11 +0300
+Subject: [PATCH 1/6] Fix compilation on i386
+
+---
+ include/gf_complete.h | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/include/gf_complete.h b/include/gf_complete.h
+index c4783e8..9436eb8 100644
+--- a/include/gf_complete.h
 b/include/gf_complete.h
+@@ -19,6 +19,10 @@
+   #ifdef __SSE4_1__
+ #include 
+   #endif
++  #ifdef __i386
++#define _mm_insert_epi64(A,B,C) 
_mm_insert_epi32(_mm_insert_epi32((A),(uint32_t)(B),(C)*2),(uint32_t)((uint64_t)(B)>>32),(C)*2+1)
++#define _mm_extract_epi64(A,C) 
uint64_t)_mm_extract_epi32((A),(C)*2+1))<<32)|(uint32_t)_mm_extract_epi32((A),(C)*2))
++  #endif
+ #endif
+ 
+ #ifdef INTEL_SSSE3
+-- 
+2.11.0
+
diff -Nru 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0002-Fix-runtime-cpudetection.patch
 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0002-Fix-runtime-cpudetection.patch
--- 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0002-Fix-runtime-cpudetection.patch
 1970-01-01 03:00:00.0 +0300
+++ 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0002-Fix-runtime-cpudetection.patch
 2019-02-09 13:29:51.0 +0300
@@ -0,0 +1,967 @@
+From b811ddd5cc50b7f3539d80419549f0712b5438a7 Mon Sep 17 00:00:00 2001
+From: "Yuriy M. Kaminskiy" 
+Date: Sat, 9 Feb 2019 13:28:43 +0300
+Subj

Bug#921916: gf-complete: please hide internal symbols

[Yuriy M. Kaminskiy]

Source: gf-complete
Version: 1.0.2+2017.04.10.git.ea75cdf-3
Severity: wishlist
Tags: upstream patch

Dear Maintainer,

libgf-complete1 exports a number of internal symbols that are not part of
API.
They vary depending on platform and optimization options, clutter public
namespace, worsen performance.

Attached debdiff fixes that (on the top of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921874
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=921874;filename=gf-complete-runtime-cpudetect.debdiff;msg=5
); passes (limited) testing; I've built jerasure
(locally backported 2.0.0+2017.04.10.git.de1739cc84-1) against resulting
library without problems, but have not checked any other (potential) users.

Known problems: hiding symbols (and removing them from .symbols) is
obviously risky operation; I consider risk to be low in this case, but
still.

-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2019-02-09 
13:29:51.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2019-02-09 
13:29:51.0 +0300
@@ -1,10 +1,11 @@
-gf-complete (1.0.2+2017.04.10.git.ea75cdf-3~bpo9+1~local2) stretch-backports; 
urgency=medium
+gf-complete (1.0.2+2017.04.10.git.ea75cdf-3~bpo9+1~local3) stretch-backports; 
urgency=medium
 
   * Rebuild for stretch-backports.
   * Fix i386 simd compilation.
   * Fix runtime cpudetection.
   * Fix neon for armhf.
   * Run complete test suite under qemu.
+  * Hide internal symbols.
 
  -- Yuriy M. Kaminskiy   Sat, 09 Feb 2019 13:29:51 
+0300
 
diff -Nru 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/libgf-complete1.symbols 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/libgf-complete1.symbols
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/libgf-complete1.symbols 
2018-05-22 16:43:40.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/libgf-complete1.symbols 
2019-02-09 13:29:51.0 +0300
@@ -6,26 +6,8 @@
  MOA_Random_W@Base 1.0.2
  MOA_Seed@Base 1.0.2
  _gf_errno@Base 1.0.2
- bits@Base 1.0.2
- bits_56@Base 1.0.2
- (arch=amd64)cpuid@Base 1.0.2+2017.04.10.git.ea75cdf
  create_gf_from_argv@Base 1.0.2
- (arch=arm64 armhf armel)get_hwcap@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_alignment_error@Base 1.0.2
- gf_bitmatrix_inverse@Base 1.0.2
- gf_composite_get_default_poly@Base 1.0.2
- gf_cpu_identified@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_cpu_identify@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_cpu_supports_arm_neon@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_cpu_supports_intel_pclmul@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_cpu_supports_intel_sse2@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_cpu_supports_intel_sse3@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_cpu_supports_intel_sse4@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_cpu_supports_intel_ssse3@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_do_final_region_alignment@Base 1.0.2
- gf_do_initial_region_alignment@Base 1.0.2
  gf_error@Base 1.0.2
- gf_error_check@Base 1.0.2
  gf_free@Base 1.0.2
  gf_general_add@Base 1.0.2
  gf_general_are_equal@Base 1.0.2
@@ -46,57 +28,12 @@
  gf_general_val_to_s@Base 1.0.2
  gf_init_easy@Base 1.0.2
  gf_init_hard@Base 1.0.2
- gf_multby_one@Base 1.0.2
- gf_multby_zero@Base 1.0.2
  gf_scratch_size@Base 1.0.2
- gf_set_region_data@Base 1.0.2
  gf_size@Base 1.0.2
- gf_two_byte_region_table_multiply@Base 1.0.2
- gf_w128_bytwo_b_multiply@Base 1.0.2
- gf_w128_bytwo_b_multiply_region@Base 1.0.2
- gf_w128_bytwo_p_multiply@Base 1.0.2
- (arch=amd64)gf_w128_clm_multiply@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_w128_divide_from_inverse@Base 1.0.2
- gf_w128_euclid@Base 1.0.2
- gf_w128_extract_word@Base 1.0.2
- gf_w128_group_multiply@Base 1.0.2
- gf_w128_init@Base 1.0.2
- gf_w128_inverse_from_divide@Base 1.0.2
- gf_w128_scratch_size@Base 1.0.2
- gf_w128_shift_multiply@Base 1.0.2
- (arch=amd64)gf_w128_sse_bytwo_b_multiply@Base 1.0.2+2017.04.10.git.ea75cdf
- (arch=amd64)gf_w128_sse_bytwo_p_multiply@Base 1.0.2+2017.04.10.git.ea75cdf
  gf_w16_get_div_alog_table@Base 1.0.2
  gf_w16_get_log_table@Base 1.0.2
  gf_w16_get_mult_alog_table@Base 1.0.2
- gf_w16_init@Base 1.0.2
- (arch=arm64)gf_w16_neon_split_init@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_w16_scratch_size@Base 1.0.2
- gf_w16_split_8_8_multiply@Base 1.0.2
- gf_w32_init@Base 1.0.2
- (arch=arm64)gf_w32_neon_split_init@Base 1.0.2+2017.04.10.git.ea75cdf
- gf_w32_scratch_size@Base 1.0.2
  gf_w4_get_div_table@Base 1.0.2

Bug#921874: gf-complete: fix runtime cpu detection and compilation on i386/armhf

[Yuriy M. Kaminskiy]

On 09.02.2019 20:48, Yuriy M. Kaminskiy wrote:
> 2) it can expose bugs on some cpus, that are not caught by testsuite
> (e.g. [previous version of] my _mm_extract_epi64 replacement was very
> buggy - but it was not detected by debian's qemu test [as it only runs
> only single unit test for gf64, but only gf128 was affected]);

Just in case, I (ab)used valgrind hook to run complete testsuite for all
combination of flags for i386 and amd64, incremental debdiff attached (on the 
top of above).

Known problems: takes a bit too long to run (2.5 hours for amd64, and even more 
for i386).
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2019-02-09 
13:29:51.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2019-02-09 
13:29:51.0 +0300
@@ -1,9 +1,10 @@
-gf-complete (1.0.2+2017.04.10.git.ea75cdf-3~bpo9+1~local1) stretch-backports; 
urgency=medium
+gf-complete (1.0.2+2017.04.10.git.ea75cdf-3~bpo9+1~local2) stretch-backports; 
urgency=medium
 
   * Rebuild for stretch-backports.
   * Fix i386 simd compilation.
   * Fix runtime cpudetection.
   * Fix neon for armhf.
+  * Run complete test suite under qemu.
 
  -- Yuriy M. Kaminskiy   Sat, 09 Feb 2019 13:29:51 
+0300
 
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/rules 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/rules
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/rules   2019-02-09 
13:29:51.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/rules   2019-02-09 
13:29:51.0 +0300
@@ -6,44 +6,43 @@
 
 GIT_TAG ?= $(shell echo '$(DEB_VERSION_UPSTREAM)' | sed -e 's/~/_/')
 
-%:
-   dh $@  --with autoreconf
-
 ifeq ($(DEB_HOST_ARCH), amd64)
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-override_dh_auto_test:
-   dh_auto_test
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,-sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,+ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,+ssse3,+sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,+ssse3,+sse4.1,+sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-x86_64-static -cpu 
qemu64,+sse3,+ssse3,+sse4.1,+sse4.2,+pclmulqdq ./test/gf_unit 64 A -1 -
-endif
+QEMU_ARCH=x86_64
+# omitted: sse2 (always on amd64), sse3 (not used)
+QEMU_CPUS=qemu64,-ssse3,-sse4.1,-sse4.2,-pclmulqdq
 endif
 
 ifeq ($(DEB_HOST_ARCH), i386)
+QEMU_ARCH=i386
+# omitted: sse3 (not used)
+QEMU_CPUS=qemu32,-sse2,-ssse3,-sse4.1,-sse4.2,-pclmulqdq
+endif
+
+ifeq ($(DEB_HOST_ARCH), armhf)
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-override_dh_auto_test:
-   dh_auto_test
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,-sse2,-sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,-ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,+ssse3,-sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,+ssse3,+sse4.1,-sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,-pclmulqdq ./test/gf_unit 64 A -1 -
-   ./libtool --mode=execute qemu-i386-static -cpu 
qemu32,+sse2,+sse3,+ssse3,+sse4.1,+sse4.2,+pclmulqdq ./test/gf_unit 64 A -1 -
+ifeq (neon,$(shell grep -o -w -h -m 1 neon /proc/cpuinfo 2>/dev/null))
+$(warning NEON detected on the build host, arm-without-neon configuration will 
not be tested)
+else
+QEMU_ARCH=arm
+QEMU_CPUS=cortex-a8
+endif
 endif
 endif
 
-ifeq ($(DEB_HOST_ARCH), armhf)
+%:
+   dh $@  --with autoreconf
+
+ifneq (,$(QEMU_ARCH))
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 override_dh_auto_test:
dh_auto_test
-# I have not found any way to disable NEON in emulated cpu
-#  ./libtool --mode=execute qemu-arm-static -cpu cortex-a8,-neon 
./test/gf_unit 64 A -1 -
-   set -ex; if grep -sw neon /proc/cpuinfo; then echo "WARNING: NEON 
detected on build host, arm-without-neon configuration is not tested"; fi
-   ./libtool --mode=execute qemu-arm-static -cpu cortex-a8 ./test/gf_unit 
64 A -1 -
+   set -ex; C=$(QEMU_ARCH); c=$(QEMU_CPUS); p=X; \
+   while test "$$p" !=

Bug#921874: gf-complete: fix runtime cpu detection and compilation on i386/armhf

[Yuriy M. Kaminskiy]

Source: gf-complete
Version: 1.0.2+2017.04.10.git.ea75cdf-3
Severity: normal
Tags: upstream patch

Dear Maintainer,

Attached patches properly fixes compilation for i386 with sse* and
runtime detection of SIMD extensions on i386/amd64/armhf/arm64.

Passed limited testing on i386 and x86-64 (on amd k8
[supports sse2, but not ssse3 or later; newly added qemu-user test
passes]), armhf [rapsberry pi 3B+, armv8a+crc/cortex a53 cpu with neon;
sadly, I have not found any way to coerce qemu-arm-static into
running tests with neon disabled and I don't have hardware - with
armhf-compatible cpu without neon - to test; given SIGILL builddd
failures on 1.0.2+2017.04.10.git.ea75cdf-1 - they should have some].

arm64/aarch64 untested (I believe +simd/NEON is considered mandatory
for debian's arm64?)

Known problems:
1) __attribute__((target)) is (not very) recent gcc extension; should
not be problem for debian (seems already present in jessie's gcc-4.9), no
idea about upstream;
2) it can expose bugs on some cpus, that are not caught by testsuite
(e.g. [previous version of] my _mm_extract_epi64 replacement was very
buggy - but it was not detected by debian's qemu test [as it only runs
only single unit test for gf64, but only gf128 was affected]);
3) I have not added new symbols to .symbols; by all and good, all of
them are internal symbols that should've been hidden with
__attribute__((visibility("hidden"))) or linker script, but this is
outside of the scope of this bug.

-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2018-05-22 
16:43:40.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/changelog   2019-02-09 
13:29:51.0 +0300
@@ -1,3 +1,12 @@
+gf-complete (1.0.2+2017.04.10.git.ea75cdf-3~bpo9+1~local1) stretch-backports; 
urgency=medium
+
+  * Rebuild for stretch-backports.
+  * Fix i386 simd compilation.
+  * Fix runtime cpudetection.
+  * Fix neon for armhf.
+
+ -- Yuriy M. Kaminskiy   Sat, 09 Feb 2019 13:29:51 
+0300
+
 gf-complete (1.0.2+2017.04.10.git.ea75cdf-3) unstable; urgency=medium
 
   * remove patch: 0001-temporarily-disable-sse3-and-above.patch (Closes: 
#899296)
diff -Nru gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/control 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/control
--- gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/control 2018-05-22 
16:43:40.0 +0300
+++ gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/control 2019-02-09 
13:29:51.0 +0300
@@ -7,7 +7,7 @@
  Shengjing Zhu ,
 Build-Depends:
  debhelper (>= 10),
- qemu-user-static [amd64] ,
+ qemu-user-static [i386 amd64 armhf] ,
 Standards-Version: 4.1.4
 Homepage: http://jerasure.org/
 Vcs-Git: https://salsa.debian.org/openstack-team/third-party/gf-complete.git
diff -Nru 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0001-Fix-compilation-on-i386.patch
 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0001-Fix-compilation-on-i386.patch
--- 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0001-Fix-compilation-on-i386.patch
  1970-01-01 03:00:00.0 +0300
+++ 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0001-Fix-compilation-on-i386.patch
  2019-02-09 13:29:51.0 +0300
@@ -0,0 +1,27 @@
+From 5e966de08b923851aa466b044ae379803f7dac5c Mon Sep 17 00:00:00 2001
+From: "Yuriy M. Kaminskiy" 
+Date: Sat, 9 Feb 2019 12:55:11 +0300
+Subject: [PATCH 1/3] Fix compilation on i386
+
+---
+ include/gf_complete.h | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/include/gf_complete.h b/include/gf_complete.h
+index c4783e8..1b4340f 100644
+--- a/include/gf_complete.h
 b/include/gf_complete.h
+@@ -19,6 +19,10 @@
+   #ifdef __SSE4_1__
+ #include 
+   #endif
++  #ifdef __i386
++#define _mm_insert_epi64(A,B,C) 
_mm_insert_epi32(_mm_insert_epi32((A),(uint32_t)(B),(C)*2),(uint32_t)((uint64_t)(B)>>32),(C)*2+1)
++#define _mm_extract_epi64(A,C) 
uint64_t)_mm_extract_epi32((A),(C)*2+1))<<32)|_mm_extract_epi32((A),(C)*2))
++  #endif
+ #endif
+ 
+ #ifdef INTEL_SSSE3
+-- 
+2.11.0
+
diff -Nru 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0002-Fix-runtime-cpudetection.patch
 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0002-Fix-runtime-cpudetection.patch
--- 
gf-complete-1.0.2+2017.04.10.git.ea75cdf/debian/patches/0002-Fix-runtime-cpudetection.patch
 1970-01-

Bug#920943: binutils: objdump -d incorrect disasembly for arm vmlal.u16 instruction in thumb mode

[Yuriy M. Kaminskiy]

Source: binutils
Version: 2.28-5
Severity: normal
File: /usr/bin/arm-linux-gnueabihf-objdump
Tags: upstream fixed-upstream patch

Dear Maintainer,

$  arm-linux-gnueabihf-as << EOF
.arch armv7-a
.text
.syntax unified
.thumb
.fpu neon
vmlal.u16 q8, d9, d24
vmlal.u16 q8, d2, d23
vmlal.u16 q8, d3, d22
vmlal.u16 q8, d4, d21
vmlal.u16 q8, d5, d20
vmlal.u16 q8, d30, d19
vmlal.u16 q8, d31, d28
EOF
$ arm-linux-gnueabihf-objdump -d a.out

a.out: file format elf32-littlearm

Disassembly of section .text:

 <.text>:
   0:   ffd9 0828   vcmla.f32   d16, d9, d24[0], #90
   4:   ffd2 0827   vcmla.f32   d16, d2, d23[0], #90
   8:   ffd3 0826   vcmla.f32   d16, d3, d22[0], #90
   c:   ffd4 0825   vcmla.f32   d16, d4, d21[0], #90
  10:   ffd5 0824   vcmla.f32   d16, d5, d20[0], #90
  14:   ffde 08a3   vcmla.f32   d16, d30, d19[0], #90
  18:   ffdf 08ac   vcmla.f32   d16, d31, d28[0], #90

Identical (incorrect) result with binutils-arm-linux-gnueabihf:i386, 
binutils-multiarch:i386 and with (on target host) binutils:armhf.


(Given that compiled code behaves correctly, assembler works correctly, 
only disassembler/objdump is broken)


Non-.thumb encoding is not affected, with .thumb directive removed
above:
   0:   f3d90828vmlal.u16   q8, d9, d24
   4:   f3d20827vmlal.u16   q8, d2, d23
...

It looks like fixed upstream by commit
c13a63b04677906020ee72a28d5869d979e36a6f
(at least, it works correctly with binary-patched libopcodes*.so; 
totally untested stripped-down version of patch attached);

claim about "currently undefined instruction" in commit description was
a bit too optimistic.
Buster's binutils-2.31 is likely not affected (but I have not verified).

gdb_7.12-6 in stretch seems embeds binutils version that predates vcmla 
support, so it is not affected (verified with gdb-multiarch); no idea 
about buster.


-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages binutils-multiarch depends on:
ii  binutils  2.28-5
ii  libc6 2.24-11+deb9u3
ii  zlib1g1:1.2.8.dfsg-5

binutils-multiarch recommends no packages.

binutils-multiarch suggests no packages.

-- no debconf information

>From c13a63b04677906020ee72a28d5869d979e36a6f Mon Sep 17 00:00:00 2001
From: Szabolcs Nagy 
Date: Wed, 18 Jan 2017 17:08:34 +
Subject: [PATCH] [ARM] Fix the decoding of indexed element VCMLA instruction

Bit 24 of the indexed element vcmla decode mask was incorrectly
left unset.  This could cause incorrect disassembly of some
currently undefined instructions as vcmla.

Rotatation immediates were not printed correctly in the disassembly
(could print 170 and 280 instead of 180 and 270).

opcodes/
* arm-dis.c (coprocessor_opcodes): Fix vcmla mask and disassembly.

gas/
* testsuite/gas/arm/armv8_3-a-simd.s: Add vcmla tests.
* testsuite/gas/arm/armv8_3-a-simd.d: Update.
---
 gas/ChangeLog  |  5 +
 gas/testsuite/gas/arm/armv8_3-a-simd.d | 12 
 gas/testsuite/gas/arm/armv8_3-a-simd.s | 14 ++
 opcodes/ChangeLog  |  4 
 opcodes/arm-dis.c  |  8 
 5 files changed, 39 insertions(+), 4 deletions(-)

[removed for backport] diff --git a/gas/ChangeLog b/gas/ChangeLog
[removed for backport] diff --git a/gas/testsuite/gas/arm/armv8_3-a-simd.d 
b/gas/testsuite/gas/arm/armv8_3-a-simd.d
[removed for backport] diff --git a/gas/testsuite/gas/arm/armv8_3-a-simd.s 
b/gas/testsuite/gas/arm/armv8_3-a-simd.s
[removed for backport] diff --git a/opcodes/ChangeLog b/opcodes/ChangeLog
diff --git a/opcodes/arm-dis.c b/opcodes/arm-dis.c
index 167c6685c..2987403fb 100644
--- a/opcodes/arm-dis.c
+++ b/opcodes/arm-dis.c
@@ -897,13 +897,13 @@ static const struct opcode32 coprocessor_opcodes[] =
   {ARM_FEATURE_CORE_HIGH (ARM_EXT2_V8_3A),
 0xfd300800, 0xff300f10, "vcmla%c.f32\t%12-15,22V, %16-19,7V, %0-3,5V, 
#%23?21%23?780"},
   {ARM_FEATURE_CORE_HIGH (ARM_EXT2_V8_3A),
-0xfe000800, 0xfea00f10, "vcmla%c.f16\t%12-15,22V, %16-19,7V, %0-3D[%5?10], 
#%20'90"},
+0xfe000800, 0xffa00f10, "vcmla%c.f16\t%12-15,22V, %16-19,7V, %0-3D[%5?10], 
#%20'90"},
   {ARM_FEATURE_CORE_HIGH (ARM_EXT2_V8_3A),
-0xfe200800, 0xfea00f10, "vcmla%c.f16\t%12-15,22V, %16-19,7V, %0-3D[%5?10], 
#%20?21%23?780"},
+0xfe200800, 0xffa00f10, "vcmla%c.f16\t%12-15,22V, %16-19,7V, %0-3D[%5?10], 
#%20?21%20?780"},
   {ARM_FEATURE_CORE_HIGH (ARM_EXT2_V8_3A),
-0xfe800800, 0xfea00f10, "vcmla%c.f32\t%12-15,22V, 

Bug#918314: gmp: please add NEON-optimized variant for armhf

[Yuriy M. Kaminskiy]

Source: gmp
Version: 2:6.1.2+dfsg-1
Severity: wishlist
Tags: patch

Dear Maintainer,

As --enable-fat works only on i386^1, on armhf neon-optimized code is 
never used, rendering gmp much slower than it can be.


As a workaround, I suggest to compile and install separate 
neon-optimized library in $(libdir)/neon/vfp and rely on ld.so for 
runtime-detection.


Debdiff attached, passed limited testing ([1] cross-compiled [implies 
nocheck] `pbuilder --host-arch=armhf --arch=i386`, installed on 
rpi3b+/raspbian-stretch, benchmarked; [2] native recompilation on 
rpi3b+/raspbian [passed regression tests], then installed and benchmarked);


No idea how well this would work on hurd, kfreebsd, etc.

I hardcoded armv7 for neon code: debian's armhf requires minimum armv7, 
so this should be acceptable; I have not tested, but this should not 
break "fake armhf" from raspbian (rpi1 is armv6 without neon, so new 
neon-optimized variant would not be picked; newer rpi are armv7+ and 
have neon).


Potential pitfalls: it enables previously untested (at least, by debian) 
code on affected platforms, some bugs can lurk there.


About expected user-visible effect, on Raspberry Pi 3B+ (BCM2837B0, 
4-core Cortex-A53 @1.4GHz), `gnutls-cli --benchmark-tls-kx`:


Before:
Testing key exchanges (RSA/DH bits: 3072, EC bits: 256)
(TLS1.2)-(DHE-RSA-3072)-(AES-128-CBC)-(SHA1)  5.50 transactions/sec
   (avg. handshake time: 181.71 ms, sample variance: 0.43)
(TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)  12.08 transactions/sec
   (avg. handshake time: 82.77 ms, sample variance: 0.18)
(TLS1.2)-(ECDHE-RSA-X25519)-(AES-128-CBC)-(SHA1)  12.32 transactions/sec
   (avg. handshake time: 81.03 ms, sample variance: 0.03)
(TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-128-CBC)-(SHA1)  77.88 
transactions/sec

   (avg. handshake time: 12.73 ms, sample variance: 0.20)
(TLS1.2)-(ECDHE-ECDSA-X25519)-(AES-128-CBC)-(SHA1)  88.98 transactions/sec
   (avg. handshake time: 11.13 ms, sample variance: 0.11)
   (TLS1.2)-(RSA)-(AES-128-CBC)-(SHA1)  13.15 transactions/sec
   (avg. handshake time: 75.86 ms, sample variance: 0.12)

After:
Testing key exchanges (RSA/DH bits: 3072, EC bits: 256)
(TLS1.2)-(DHE-RSA-3072)-(AES-128-CBC)-(SHA1)  8.40 transactions/sec
   (avg. handshake time: 118.98 ms, sample variance: 0.27)
(TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)  18.42 transactions/sec
   (avg. handshake time: 54.23 ms, sample variance: 0.18)
(TLS1.2)-(ECDHE-RSA-X25519)-(AES-128-CBC)-(SHA1)  18.88 transactions/sec
   (avg. handshake time: 52.82 ms, sample variance: 0.15)
(TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-128-CBC)-(SHA1)  93.89 
transactions/sec

   (avg. handshake time: 10.54 ms, sample variance: 0.25)
(TLS1.2)-(ECDHE-ECDSA-X25519)-(AES-128-CBC)-(SHA1)  106.83 transactions/sec
   (avg. handshake time: 9.25 ms, sample variance: 0.19)
   (TLS1.2)-(RSA)-(AES-128-CBC)-(SHA1)  20.46 transactions/sec
   (avg. handshake time: 48.78 ms, sample variance: 0.18)

That is, 20% to 50% speedup.

^1 --enable-fat works on amd64 too - but debian disables it; maybe, it's 
time to reconsider? some related bugs was fixed upstream since last 
attempt (which resulted in #671866); that said, on my cpu amd64+fat is 
slower than current debian-packaged "fat-free" code, so I'm not very 
much interested.


-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

diff -Nru gmp-6.1.2+dfsg/debian/rules gmp-6.1.2+dfsg/debian/rules
--- gmp-6.1.2+dfsg/debian/rules 2016-12-21 08:38:23.0 +0300
+++ gmp-6.1.2+dfsg/debian/rules 2019-01-02 22:52:33.0 +0300
@@ -68,9 +68,20 @@
 
 confflags_ma = $(confflags) $(confflags_build) 
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
 
+FLAVORS = main
+LIBDIR_main =
+
 CC   = $(DEB_HOST_GNU_TYPE)-gcc
 CXX   = $(DEB_HOST_GNU_TYPE)-g++
 
+ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))
+FLAVORS += neon
+
+LIBDIR_neon = neon/vfp
+neon_host_type = $(patsubst 
arm-%,armcortexa7neon-unknown-%,$(DEB_HOST_GNU_TYPE))
+confflags_neon = --host=$(neon_host_type) --target=$(neon_host_type) 
--libdir=/usr/lib/$(DEB_HOST_MULTIARCH)/$(LIBDIR_neon)
+CFLAGS_neon = -march=armv7-a -mfpu=neon
+endif
 
 get-orig-source: gmp-$(ORIG_SRC_VERSION).tar.xz
tar --xz -xf $<
@@ -88,25 +99,34 @@
 gmp-$(ORIG_SRC_VERSION).tar.xz:
wget https://gmplib.org/download/gmp/$@
 
-configure: configure-stamp
-configure-stamp:
-   mkdir -p build
-   cd build && ../configure $(confflags_ma) \
-   AR=$(AR) CC="$(CC)" 

Bug#917616: openssl: `openssl speed foobar` segfaults

[Yuriy M. Kaminskiy]

Package: openssl
Version: 1.1.0j-1~deb9u1
Severity: minor
Tags: patch stretch upstream

Dear Maintainer,

   * What led up to the situation?

Invoking `openssl speed` with unrecognized/unsupported algorithm, e.g.
  openssl speed foobar
or even
  openssl speed help

   * What was the outcome of this action?

openssl segfaults.

   * What outcome did you expect instead?

Error message/list of supported algorithms/etc

gdb backtrace:
(gdb) bt
#0  __strcmp_ia32 () at ../sysdeps/i386/i686/multiarch/../strcmp.S:34
#1  0x566a488e in opt_found (nbelem=, 
pairs=0x566ddc28 , result=, 
name=) at ../apps/speed.c:298

#2  speed_main (argc=1, argv=0xff8b192c) at ../apps/speed.c:1515
#3  0x56667615 in do_cmd (prog=0x584b4c20, argc=2, argv=0xff8b1928)
at ../apps/openssl.c:476
#4  0x56667d19 in main (argc=2, argv=0xff8b1928) at ../apps/openssl.c:181

This bug apparently was introduced in
commit 4e07941373ac17086ab4e601950c4ca148e8bb31
due to mismerge of cherry-picked commit 
5c6a69f539a5eb66a1afa4e2904d8a27e9b534c3


I have not run-tested, but from looking at sources, it should not be 
present in openssl-1.1.1 or master (so only stretch is affected).


(Untested) patch attached.

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openssl depends on:
ii  libc6  2.24-11+deb9u3
ii  libssl1.1  1.1.0j-1~deb9u1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20161130+nmu1+deb9u1

-- no debconf information

diff --git a/apps/speed.c b/apps/speed.c
index 6672fe606a..4595cc602c 100644
--- a/apps/speed.c
+++ b/apps/speed.c
@@ -537,7 +537,6 @@ static const OPT_PAIR ecdh_choices[] = {
 {"ecdhb409", R_EC_B409},
 {"ecdhb571", R_EC_B571},
 {"ecdhx25519", R_EC_X25519},
-{NULL}
 };
 # define EC_NUM   OSSL_NELEM(ecdh_choices)
 

Bug#917158: qemubuilder mishandles multiple entries in OTHERMIRROR

[Yuriy M. Kaminskiy]

On 23.12.2018 15:00, Debian Bug Tracking System wrote:

Trivial patch attached.


... unfortunately, it is not sufficient. sanitize_mirror() function also 
requires adjustments (I'm tempted to move it into shell/sed code, but 
that will cause regressions in the corner cases).

Bug#917158: qemubuilder mishandles multiple entries in OTHERMIRROR

[Yuriy M. Kaminskiy]

Package: qemubuilder
Version: 0.87
Severity: normal
Tags: patch

Dear Maintainer,

When OTHERMIRROR contains multiple entries, separated by | character (as
documented in pbuilderrc(5)), qemubuilder fails to handle them and
produces incorrect /etc/apt/sources.list.d/other.list file, resulting in

E: Malformed entry 1 in list file /etc/apt/sources.list.d/other.list
(absolute Suite Component).

on `qemubuilder create`. Trivial patch attached.

-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qemubuilder depends on:
ii  debootstrap  1.0.89
ii  e2fsprogs1.43.4-2
ii  libc62.24-11+deb9u3
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libtinfo56.0+20161126-1+deb9u2
ii  pbuilder 0.228.7
ii  qemu-system  1:2.8+dfsg-6+deb9u5

qemubuilder recommends no packages.

qemubuilder suggests no packages.

-- no debconf information

diff -Nru cowdancer-0.87~bpo9+1/qemubuilder.c 
cowdancer-0.87~bpo9+1.1~local1/qemubuilder.c
--- cowdancer-0.87~bpo9+1/qemubuilder.c 2017-01-18 21:46:49.0 +0300
+++ cowdancer-0.87~bpo9+1.1~local1/qemubuilder.c2018-12-23 
00:44:42.0 +0300
@@ -1185,7 +1185,7 @@
"$BUILDDIR/input/run-copyfiles\n"
"hostname pbuilder-$(cat /etc/hostname)\n"
//TODO: installaptlines
-   "echo '%s' > /etc/apt/sources.list.d/other.list\n"
+   "echo '%s' | tr '|' '\\n' > 
/etc/apt/sources.list.d/other.list\n"
EXECUTE_HOOKS("G")
"apt-get update || exit_from_qemu 1\n"
//TODO: "dpkg --purge $REMOVEPACKAGES\n"

Bug#855444: (likely) fixed upstream

[Yuriy M. Kaminskiy]

This looks like was triggered by upstream bug 3437, fixed in 
1:4.2.8p11+dfsg-1 (aside of selinux noise, it triggered series of 
modprobe requests for net-pf-0 every few minutes).

Bug#566326: duplicate of #551968 (fixed as of 3.6.19-2)

[Yuriy M. Kaminskiy]

This seems to be duplicate of 551968 (which was "fixed"^[] as of 
3.6.19-2, somewhere before wheezy), so I guess this bug should be 
merged/closed.



^[] which annoyed me to no end, as this option provides only snake oil 
privacy [(1) it is useless on SSD; (2) it does nothing about leaking 
data in swap and temporary files; (3) and it is useless on 
(fully-)journaling, deduplicating or compressing FS, as they are likely 
to relocate zeroed-out blocks instead of rewriting physical storage] - 
so if you /really/ care about [offline] safety of your data, you 
should've beeh used full disk encryption; and by then, this option is 
just useless waste of cpu cycles and I/O bandwidth.


Besides, as this option is available as runtime tuneable `pragma 
secure_delete`, there are no good reason to twiddle it system-wide.

Bug#904848: apulse: please add Multi-Arch support

[Yuriy M. Kaminskiy]

Package: apulse
Version: 0.1.12-1
Severity: normal
Tags: patch

Dear Maintainer,

Please add support for co-installation of apulse package for multi-arch
systems. Patch attached; I've briefly tested without any apparent 
problems (in self-compiled backport on stretch system).


-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

diff -Nru apulse-0.1.12/debian/control apulse-0.1.12/debian/control
--- apulse-0.1.12/debian/control2018-05-19 20:39:22.0 +0300
+++ apulse-0.1.12/debian/control2018-07-28 23:43:20.0 +0300
@@ -10,6 +10,7 @@
 
 Package: apulse
 Architecture: linux-any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: PulseAudio emulation for ALSA
  The program provides an alternative partial implementation of the PulseAudio
diff -Nru apulse-0.1.12/debian/patches/multi-arch.patch 
apulse-0.1.12/debian/patches/multi-arch.patch
--- apulse-0.1.12/debian/patches/multi-arch.patch   1970-01-01 
03:00:00.0 +0300
+++ apulse-0.1.12/debian/patches/multi-arch.patch   2018-07-28 
23:43:20.0 +0300
@@ -0,0 +1,33 @@
+Index: apulse-0.1.12/CMakeLists.txt
+===
+--- apulse-0.1.12.orig/CMakeLists.txt
 apulse-0.1.12/CMakeLists.txt
+@@ -1,6 +1,8 @@
+ project(apulse)
+ cmake_minimum_required (VERSION 2.8)
+ 
++include(GNUInstallDirs)
++
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu99 -Wall -fPIC 
-fvisibility=hidden")
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Werror=implicit-function-declaration")
+ set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -pthread")
+@@ -72,7 +74,7 @@ target_link_libraries(pulse-simple ${SYM
+ 
+ add_subdirectory(tests)
+ 
+-set(APULSEPATH "${CMAKE_INSTALL_PREFIX}/lib/apulse" CACHE PATH "library 
installation directory")
++set(APULSEPATH "${CMAKE_INSTALL_LIBDIR}/apulse" CACHE PATH "library 
installation directory")
+ set(APULSE_SEARCH_PATHS "${APULSEPATH}" CACHE PATH "directory list for 
LD_LIBRARY_PATH")
+ configure_file("${CMAKE_CURRENT_SOURCE_DIR}/src/apulse.template"
+"${CMAKE_CURRENT_BINARY_DIR}/apulse" @ONLY)
+Index: apulse-0.1.12/src/apulse.template
+===
+--- apulse-0.1.12.orig/src/apulse.template
 apulse-0.1.12/src/apulse.template
+@@ -1,5 +1,5 @@
+ #!/bin/sh
+ 
+-APULSEPATH="@APULSE_SEARCH_PATHS@"
++APULSEPATH='/usr/$LIB/apulse'
+ 
+ LD_LIBRARY_PATH=$APULSEPATH${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} exec "$@"
diff -Nru apulse-0.1.12/debian/patches/series 
apulse-0.1.12/debian/patches/series
--- apulse-0.1.12/debian/patches/series 1970-01-01 03:00:00.0 +0300
+++ apulse-0.1.12/debian/patches/series 2018-07-28 23:43:20.0 +0300
@@ -0,0 +1 @@
+multi-arch.patch

Bug#904433: tesseract-ocr: please mark as Multi-Arch: foreign

[Yuriy M. Kaminskiy]

Package: tesseract-ocr
Version: 4.00~git2481-555f6ffc-1
Severity: normal
Tags: patch

Dear Maintainer,

tesseract-ocr package provides arch-independent service (cli), please
mark it as Multi-Arch: foreign; (trivial) patch attached.

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages tesseract-ocr depends on:
ii  libc62.24-11+deb9u3
ii  libcairo21.14.8-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libgomp1 6.3.0-18+deb9u1
ii  libicu57 57.1-6+deb9u2
ii  liblept5 1.74.1-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpangoft2-1.0-01.40.5-1
ii  libstdc++6   6.3.0-18+deb9u1
ii  libtesseract44.00~git2439-c3ed6f03-1~bpo9+1
ii  tesseract-ocr-eng4.00~git28-f7a4c12-1~bpo9+1
ii  tesseract-ocr-osd4.00~git28-f7a4c12-1~bpo9+1

tesseract-ocr recommends no packages.

tesseract-ocr suggests no packages.

-- no debconf information

--- tesseract_4.00~git2481-555f6ffc-1.debian/debian/control.orig
2018-05-22 07:30:43.0 +0300
+++ tesseract_4.00~git2481-555f6ffc-1.debian/debian/control 2018-07-24 
12:01:39.965380307 +0300
@@ -13,6 +13,7 @@
 
 Package: tesseract-ocr
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends},
  tesseract-ocr-eng (>= 4.00~), tesseract-ocr-osd (>= 4.00~), libtesseract4 (>= 
4.00~)
 Replaces: tesseract-ocr-data
@@ -87,6 +88,7 @@
 
 Package: tesseract-ocr-all
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, tesseract-ocr,
 tesseract-ocr-bul, tesseract-ocr-cat, tesseract-ocr-ces, 
tesseract-ocr-dan,
 tesseract-ocr-deu, tesseract-ocr-ell, tesseract-ocr-eng, 
tesseract-ocr-fin,

Bug#901095: patch

[Yuriy M. Kaminskiy]

Control: tags -1 patch

Attached debdiff should implement it (in a bit hackish way, but I much 
prefer to ship tcl script as tcl script over exactly same tcl script, 
but embedded in ELF executable).


(I've used this patch for some time in [locally-built] sqlite3 backports).
diff -Nru sqlite3-3.24.0/debian/changelog sqlite3-3.24.0/debian/changelog
--- sqlite3-3.24.0/debian/changelog 2018-06-06 00:47:02.0 +0300
+++ sqlite3-3.24.0/debian/changelog 2018-07-22 20:05:56.0 +0300
@@ -1,3 +1,10 @@
+sqlite3 (3.24.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add sqlite3-analyzer package. (Closes: #901095)
+
+ -- Yuriy M. Kaminskiy   Sun, 22 Jul 2018 20:05:56 
+0300
+
 sqlite3 (3.24.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru sqlite3-3.24.0/debian/control sqlite3-3.24.0/debian/control
--- sqlite3-3.24.0/debian/control   2018-06-06 00:47:02.0 +0300
+++ sqlite3-3.24.0/debian/control   2018-07-22 19:48:54.0 +0300
@@ -80,3 +80,17 @@
  access without running a separate RDBMS process.
  .
  This package contains the Tcl bindings.
+
+Package: sqlite3-analyzer
+Section: database
+Architecture: all
+Priority: extra
+Depends: ${shlibs:Depends}, ${misc:Depends}, libsqlite3-tcl, tcl8.6, sqlite3 
(= ${binary:Version})
+Suggests: sqlite3-doc, sqlite3
+Multi-Arch: foreign
+Description: An database files analysis program for SQLite 3
+ SQLite is a C library that implements an SQL database engine. 
+ Programs that link with the SQLite library can have SQL database 
+ access without running a separate RDBMS process.
+ .
+ This package contains sqlite3_analyzer program.
diff -Nru sqlite3-3.24.0/debian/rules sqlite3-3.24.0/debian/rules
--- sqlite3-3.24.0/debian/rules 2018-06-06 00:47:02.0 +0300
+++ sqlite3-3.24.0/debian/rules 2018-07-22 20:05:56.0 +0300
@@ -81,12 +81,22 @@
$(MAKE) lemon
 endif
cd ext/misc && $(CC) -g -fPIC -I../.. -shared csv.c -o csv.so
+   {   set -ex; \
+   echo '#!/bin/sh'; \
+   echo '# -*- tcl -*-'; \
+   echo '# The next line is executed by /bin/sh, but not tcl \\'; \
+   echo 'exec tclsh8.6 "$$0" $${1+"$$@"}'; \
+   echo ''; \
+   echo 'package require sqlite3'; \
+   grep -v register_dbstat_vtab tool/spaceanal.tcl; \
+   } > sqlite3_analyzer.tcl
 
touch $@
 
 clean:
dh_testdir
dh_testroot
+   rm -f sqlite3_analyzer.tcl
rm -f configure-stamp build-stamp
rm -f config.log config.h pkgIndex.tcl configure
[ ! -f Makefile ] || $(MAKE) distclean
@@ -110,6 +120,7 @@
install -d $(DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/sqlite/
install -m 0775 ext/misc/csv.so \
$(DESTDIR)/usr/lib/$(DEB_HOST_MULTIARCH)/sqlite/
+   install -m 0775 sqlite3_analyzer.tcl $(DESTDIR)/usr/bin/sqlite3_analyzer
 
# Remove *.la files per policy 3.9.1.0
sed -i "/dependency_libs/ s/'.*'/''/" `find $(DESTDIR) -name '*.la'`
@@ -132,6 +143,7 @@
dh_testroot
 
dh_install -i --sourcedir=$(DESTDIR)
+   dh_installman -i
dh_installdocs -i
dh_installchangelogs -i www/changes.html
dh_compress -i
diff -Nru sqlite3-3.24.0/debian/sqlite3_analyzer.1 
sqlite3-3.24.0/debian/sqlite3_analyzer.1
--- sqlite3-3.24.0/debian/sqlite3_analyzer.11970-01-01 03:00:00.0 
+0300
+++ sqlite3-3.24.0/debian/sqlite3_analyzer.12018-07-22 20:05:56.0 
+0300
@@ -0,0 +1,39 @@
+.Dd 2018-07-22
+.Dt SQLITE3_ANALYZER 1
+.Os "Debian GNU/Linux"
+.Sh NAME
+.Nm sqlite3_analyzer
+.Nd SQLite3 database space usage analyzis tool
+.Sh SYNOPSIS
+.Nm
+.Op Fl -pageinfo
+.Op Fl -stats
+.Op Fl -tclsh
+.Op Fl -version
+.Ar database.sqlite
+.Sh DESCRIPTION
+.Nm
+program analyze an SQLite database file and
+output a report detailing size and storage efficiency
+information for the database and its constituent tables and indexes.
+.Pp
+.Sh OPTIONS
+.Bl -tag -width indent
+.It Fl -pageinfo
+Show how each page of the database-file is used
+.It Fl -stats
+Output SQL text that creates a new database containing
+statistics about the database that was analyzed
+.It Fl -tclsh
+Run the built-in TCL interpreter interactively (for debugging)
+.It Fl -version
+Show the version number of SQLite
+.El
+.Sh AUTHOR
+.Nm
+has been written by
+.An D. Richard Hipp Aq d...@hwaci.com .
+.Pp
+This manual page was written by
+.An Yuriy M. Kaminskiy Aq yumkam+deb...@gmail.com
+for the Debian GNU/Linux system.
diff -Nru sqlite3-3.24.0/debian/sqlite3-analyzer.install 
sqlite3-3.24.0/debian/sqlite3-analyzer.install
--- sqlite3-3.24.0/debian/sqlite3-analyzer.install  1970-01-01 
03:00:00.0 +0300
+++ sqlite3-3.24.0/debian/sqlite3-analyzer.install  2018-07-22 
19:48:54.0 +0300
@@ -0,0 +1 @@
+usr/bin/sqlite3_analyzer
diff -Nru sqlite3-3.24.0/debian/sqlite3-analyzer.manpag

Bug#676653: Patch attached

[Yuriy M. Kaminskiy]

Control: tags -1 patch

Now that tor uses automatic -dbgsym, too weak dependency is not even tor 
maintainer issue (FWIW, I opened https://bugs.debian.org/903158 with 
solution).
If you install dbgsym for mismatching arch, it is useless, but don't 
break anything.
On other hand, lack of proper M-A directives really breaks things (with 
tor:amd64 on mainly-:i386 system I cannot install any of tor reverse 
dependencies, including tor-geoipdb).

Please fix this bug on tor (packaging) side.

diff -u tor-0.3.3.7/debian/control tor-0.3.3.7/debian/control
--- tor-0.3.3.7/debian/control
+++ tor-0.3.3.7/debian/control
@@ -11,6 +11,7 @@
 
 Package: tor
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, adduser, ${misc:Depends}, lsb-base
 Pre-Depends: ${misc:Pre-Depends}
 Conflicts: libssl0.9.8 (<< 0.9.8g-9)
@@ -49,6 +50,7 @@
 
 Package: tor-geoipdb
 Architecture: all
+Multi-Arch: foreign
 Priority: extra
 Depends: tor (>= ${source:Version}), ${misc:Depends}
 Replaces: tor (<< 0.2.4.8)

Bug#332578: Fixed as of less release 487

[Yuriy M. Kaminskiy]

After 13 years, less bug 273 marked as fixed in (beta?) version 485, and 
it seems everything works as of debian package version 487-0.1 (in 
ja_JP.UTF-8 locale; in non-utf-8 locales - e.g. ja_JP.EUC-JP or 
ja_JP.SJIS - it seems still broken, but debian consider them deprecated 
anyway).

Bug#903158: Multi-Arch: foreign and -dbgsym: too weak dependency

[Yuriy M. Kaminskiy]

Package: debhelper
Version: 10.2.5
Severity: minor
Tags: patch

Dear Maintainer,

On Multi-Arch i386+amd64 system, when I have foo:amd64 (Multi-Arch:
foreign), I can install useless foo-dbgsym:i386 (and reverse).

I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all)
packages should have explicit parent package arch dependency
  Depend: foo:${Arch} (=${binary:Version})
instead of
  Depend: foo (=${binary:Version})
Untested patch against debhelper 11.3.5 attached (please review 
carefully, I'm neither M-A nor debhelper expert).


References:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678896
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676653

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.28-5
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg 1.18.25
ii  dpkg-dev 1.18.25
ii  file 1:5.30-1+deb9u2
ii  libdpkg-perl 1.18.25
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-3+deb9u4
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information

--- debhelper/dh_gencontrol.org 2018-06-30 14:01:59.0 +0300
+++ debhelper/dh_gencontrol 2018-07-07 11:19:18.556510173 +0300
@@ -110,6 +110,10 @@
if ( -d $dbgsym_tmp) {
my $multiarch = package_multiarch($package);
my $section = package_section($package);
+   my $package_arch = $package;
+   if ($multiarch eq 'foreign' and package_arch($package) 
ne 'all') {
+   $package_arch .= ':${Arch}';
+   }
my $replaces = read_dbgsym_migration($dbgsym_info_dir);
my $component = '';
if ($section =~ m{^(.*)/[^/]+$}) {
@@ -126,7 +130,7 @@

-DAuto-Built-Package=debug-symbols
),
"-DPackage=${package}-dbgsym",
-   "-DDepends=${package} (= \${binary:Version})",
+   "-DDepends=${package_arch} (= 
\${binary:Version})",
"-DDescription=debug symbols for ${package}",
"-DBuild-Ids=${build_ids}",
"-DSection=${component}debug",

Bug#902792: torsocks: does not support and fails catastrophically with muliarch

[Yuriy M. Kaminskiy]

Package: torsocks
Version: 2.2.0-1+deb9u1
Severity: important
Tags: patch

Dear Maintainer,

On multi-arch systems, torsocks fails catastrophically with
other-arch binaries.

E.g. with torsocks:i386 and wget:amd64,

   torsocks wget https://check.torproject.org

just spits

ERROR: ld.so: object '/usr/lib/i386-linux-gnu/torsocks/libtorsocks.so'
from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32):
ignored.

and happily continue connecting bypassing tor.

   * What outcome did you expect instead?

It should be possible to co-install torsocks:i386 and torsocks:amd64,
and then it should work with both :amd64 and :i386 binaries.
(I'd like to point out to glibc ld.so feature to replace '$LIB' in
LD_PRELOAD and LD_LIBRARY_PATH with path to multi-arched /lib/ directory).
Some (very rough) patch attached (warning: only checked on linux; I have 
no idea if this will work on hurd or kfreebsd).


-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 'stable')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.9.0-6-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R), 
LANGUAGE=ru_RU.KOI8-R (charmap=KOI8-R)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages torsocks depends on:
ii  libc6  2.24-11+deb9u3

Versions of packages torsocks recommends:
ii  tor  0.3.3.7-1~bpo9+1

torsocks suggests no packages.

-- no debconf information

diff -Nru torsocks-2.2.0/debian/control torsocks-2.2.0/debian/control
--- torsocks-2.2.0/debian/control   2017-08-04 22:09:04.0 +0300
+++ torsocks-2.2.0/debian/control   2018-06-30 23:50:37.0 +0300
@@ -15,6 +15,8 @@
 
 Package: torsocks
 Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends},
  ${misc:Depends}
 Recommends: tor
@@ -22,3 +24,7 @@
  Torsocks allows you to use most SOCKS-friendly applications in a safe way with
  Tor. It ensures that DNS requests are handled safely and explicitly rejects
  UDP traffic from the application you're using.
+ .
+ WARNING: on multi-arch systems, this package should be installed in all
+ enabled architectures.
+ 
diff -Nru torsocks-2.2.0/debian/patches/remove-M-A-conflicting-check.patch 
torsocks-2.2.0/debian/patches/remove-M-A-conflicting-check.patch
--- torsocks-2.2.0/debian/patches/remove-M-A-conflicting-check.patch
1970-01-01 03:00:00.0 +0300
+++ torsocks-2.2.0/debian/patches/remove-M-A-conflicting-check.patch
2018-06-30 23:52:29.0 +0300
@@ -0,0 +1,17 @@
+Index: torsocks-2.2.0/src/bin/torsocks.in
+===
+--- torsocks-2.2.0.orig/src/bin/torsocks.in
 torsocks-2.2.0/src/bin/torsocks.in
+@@ -219,10 +219,12 @@ if [ $# -eq 0 ] ; then
+ fi
+ 
+ # Ensure libtorsocks exists,
++if false; then
+ if [ ! -f $SHLIB ]; then
+echo "$0: $SHLIB does not exist! Try re-installing torsocks."
+exit
+ fi
++fi
+ 
+ while true;
+ do
diff -Nru torsocks-2.2.0/debian/patches/series 
torsocks-2.2.0/debian/patches/series
--- torsocks-2.2.0/debian/patches/series2017-08-04 22:09:04.0 
+0300
+++ torsocks-2.2.0/debian/patches/series2018-06-30 23:52:29.0 
+0300
@@ -1,2 +1,3 @@
 Fix-check_addr-to-return-either-0-or-1.patch
 exclude_test_requiring_network.patch
+remove-M-A-conflicting-check.patch
diff -Nru torsocks-2.2.0/debian/rules torsocks-2.2.0/debian/rules
--- torsocks-2.2.0/debian/rules 2017-08-04 22:09:04.0 +0300
+++ torsocks-2.2.0/debian/rules 2018-06-30 23:52:29.0 +0300
@@ -14,6 +14,7 @@
 
 override_dh_auto_install:
dh_auto_install
+   sed -i 's,lib/$(DEB_HOST_MULTIARCH),\\$$LIB,' 
$(DESTDIR)/usr/bin/$(PACKAGE)
dh_bash-completion
rm $(DESTDIR)/usr/share/doc/torsocks/DEBUG
rm $(DESTDIR)/usr/share/doc/torsocks/socks-extensions.txt

Bug#609427: FYI: race condition

[Yuriy M. Kaminskiy]

I'd like to note that `mount -obind --make-private` is not atomic and 
implemented internally as

  mount -o bind $src $target # 1
  mount --make-private $target # 2
So, if two mounts are executed in parallel, there are (much smaller) 
racing window between them.


(FWIW, I just run pbuilders inside mount/uts/ipc/pid namespace, so that 
they cannot affect each other or host system)

Bug#829527: youtube-dl: don't "call home" by default

[Yuriy M. Kaminskiy]

> Can you please clarify your question? When does it "phone home"?

(Not original bug reporter), out of curiosity, I looked at sources (as 
of version 2018.01.27),


1) this option seems off by default;

2) it only affects running in verbose (debug) mode,

3) when it is on, it fetches
"https://yt-dl.org/ip; to determine ip address and 
"https://yt-dl.org/latest/version; to check for latest version.


4) it seems, no debug information (like requested URL or stacktrace) is 
transmitted.


5) and I have not found anything interesting in git history either since 
this option introduction (in version 2015.01.10.2)


So, I guess it is safe and nothing needs to be done here on debian side.

Bug#869924: irqbalance: would it be reasonable to make irqbalance Multi-Arch:foreign ?

[Yuriy M. Kaminskiy]

Disclaimer: I'm not (this or any package) maintainer, TMMV.

There are a number of architecture-dependent #ifdef's in the code 
(AARCH64 in 1.1.0, __i386__ || __amd64__ in git master), so I think that 
running foreign-arch irqbalance can be unsafe (well, I guess only 
practical case when someone would want to run foreign-arch irqbalance is 
amd64/i386/x32, and /this/ combination seems not affected; 
unfortunately, as there are no way "partially enable m-a foreign on 
subset of architectures", it is still no go).

Bug#865651: par2 is not multi-arch compatible

[Yuriy M. Kaminskiy]

Package: par2
Version: 0.6.11-1
Severity: normal
Tags: patch

Dear Maintainer,

Please mark par2 package as
   Multi-Arch: foreign
so that it can satisfy different-arch packages dependency (as it only 
provides arch-independent interface [cli]).


-- System Information:
Debian Release: 8.8
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable'), (100, 
'oldstable-proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages par2 depends on:
ii  libc6   2.19-18+deb8u10
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

par2 recommends no packages.

par2 suggests no packages.

-- no debconf information

--- par2cmdline_0.7.2-1.debian/debian/control.orig	2017-01-11 19:19:27.0 +0300
+++ par2cmdline_0.7.2-1.debian/debian/control	2017-06-23 16:38:22.0 +0300
@@ -11,6 +11,7 @@
 
 Package: par2
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: PAR 2.0 compatible file verification and repair tool
  par2cmdline is a command line utility for creating and using PAR2 files

Bug#863664: uim-gtk2.0: gtk{2,3}/qt/qt5 IM plugins are not multi-arch co-installable

[Yuriy M. Kaminskiy]

On 21.06.2017 17:24, d...@debian.org wrote:
> Thank you for your detailed reporting!
> 
> On Mon, May 29, 2017 at 11:27:23PM +0300, Yuriy M. Kaminskiy wrote:
>> gtk{2,3}, qt and qt5 IM plugins
>> /usr/lib/$ARCH/gtk-2.0/2.10.0/immodules/im-uim.so
>> /usr/lib/$ARCH/gtk-3.0/3.0.0/immodules/im-uim.so
>> /usr/lib/$ARCH/qt4/plugins/inputmethods/libuiminputcontextplugin.so
>> /usr/lib/$ARCH/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so
>> are supposed to be used and installed for all enabled architectures, but
>> shipped in non-multi-arched packages uim-{gtk2.0,gtk3,qt,qt5}. I guess, they
>> should be splitted off to separate packages with Multi-Arch: same; also
>> uim-{gtk2.0,gtk3,qt,qt5} should
>> be marked as Multi-Arch: foreign, as (with exception of those gtk/qt
>> plugins) they contain non-arch-specific tools, that can be called by
>> different-arch programs.
> 
> help wanted, sorry for my no time.

Patch (against uim 1:1.8.6+gh20161003.0.d63dadd-2 plus 4dfc83ef204364,
bdb381c7d99f, 63777be6d8a applied) attached, compile-tested only (in
jessie+backports pbuilder, with gnome applet disabled).

With all patches applied (and changelog version bumped to *-3.1~local,
to satisfy added Replaces/Breaks), aptitude seems happy about
co-installation of uim-*-immodule for :i386 and :amd64 (but I nave not
tried to install them yet).

Unfortunately, uim depends on backends, and most of them are non
multi-arch-compatible:
*) uim-anthy depends on anthy, and anthy package is not multi-arch
(shared library and anthy-common are properly marked as m-a:
same/foreign, but anthy package [which is/was required for binary
dictionary generation] is not; same in stretch/buster/sid).
In experimental (anthy >= 1:0.2), it seems anthy packages was
reshuffled, and uim-anthy need not depend on anthy package (automatic
shared library dependency is sufficient).
*) same with uim-skk (none of *skk* dependencies are marked as
multi-arch; I think, all of them should be marked as Multi-Arch: foreign).
Note: I don't use *skk*, so not in good position to fill bugs on them.
*) uim-m17n should be co-installable in stretch (but not in jessie [and
I'm on jessie, so cannot test]).
*) uim-mozc seems (almost) co-installable (except for broken indirect
Recommends: on non-co-installable mozc-utils-gui [it should've been
marked m-a: foreign]).
Note: I don't use mozc, so cannot/should not fill bugs on it.

>> (TBD: why /usr/lib/i386-linux-gnu/uim/uim-candwin-{*gtk{,3},qt[45]} are in
>> architecture-specific locations? (they either should be moved together with
>> gtk/qt plugins, or moved to non-arch-specific directories, have not checked
>> code yet).)
> 
> They are invoked by /usr/lib/$ARCH/{gtk-[23].0/*/immodules/im-uim.so,
> qt[45]/plugins/*/*.so} with hardcoded /usr/lib/$ARCH/ path, I think.

So far, in above patch I /assume/ they are not arch-specific (it /looks/
like they use arch-independent text-based protocol) and can be moved to
arch-independent location (--libexec=/usr/lib/uim) and Multi-Arch:
foreign packages.

And same with uim-utils (/usr/lib/*/uim/uim-helper-server; this one is
*critical* for multi-arching the rest).

>> Also, I think uim-skk, uim-anthy, uim-m17nlib should be marked Multi-Arch:
>> same, as they are also should be used by each arch plugin (and, obviously,
>> co-installable).
> 
> fixed in git.debian.org.
> 
> https://anonscm.debian.org/cgit/collab-maint/uim.git/commit/?id=bdb381c7d99fa677315c26011f291786cb48fa34
> 
>> And almost all remaining non-marked utilities/plugins packages
>> (especially Arch:all) should be marked Multi-Arch: foreign (otherwise they
>> are satisfied as dependency only for primary architecture).
> 
> fixed in git.debian.org
> 
> https://anonscm.debian.org/cgit/collab-maint/uim.git/commit/?id=4dfc83ef204364c94bff8b164bd8759f1c6fce70

thanks;

P.S. while rebuilding package, I noticed some noise about
`dpkg-shlibdeps: warning: package could avoid a useless dependency
if...` and `dpkg-shlibdeps: warning: [...] contains an unresolvable
reference to symbol [...]: it's probably a plugin`. Second attached
patch fixes them, compile-tested only too.
--- 
uim_1.8.6+gh20161003.0.d63dadd-2.debian/debian/uim-applet-gnome.install.orig
2016-06-22 08:06:35.0 +0300
+++ uim_1.8.6+gh20161003.0.d63dadd-2.debian/debian/uim-applet-gnome.install 
2017-06-21 22:40:53.562099505 +0300
@@ -1,4 +1,4 @@
-usr/lib/*/uim/uim-toolbar-applet-gnome3
+usr/lib/uim/uim-toolbar-applet-gnome3
 usr/share/dbus-1/services/org.gnome.panel.applet.UimAppletFactory.service
 usr/share/gnome-panel/5.0/applets/UimApplet.panel-applet
 usr/share/uim/ui/uim-applet-menu.xml
--- uim_1.8.6+gh20161003.0.d63dadd-2.debian/debian/uim-utils.install.orig   
2016-06-22 08:06:35.0 +0300
+++ uim_1.8.6+gh20161003.0.d63dadd-2.debia

Bug#864185: sqlite3 built without fts5 support (upstream bug)

[Yuriy M. Kaminskiy]

Package: sqlite3
Version: 3.19.2-1
Severity: normal
Tags: upstream fixed-upstream patch

Dear Maintainer,

I noticed that libsqlite3_3.19.2-1 is accidentally built without fts4 
and fts5 support due to broken handling of --enable-* flags in 
configure.ac (already fixed upstream,

https://www.sqlite3.org/info/43ce3bd3
) [and that's why symbol sqlite3_fts5_may_be_corrupt@Base disappeared; 
it should be reinstated in .symbols].

This bug is only present in experimental;
jessie{,-backports}/stretch/sid are not affected.

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sqlite3 depends on:
ii  libc6 2.19-18+deb8u9
ii  libreadline6  6.3-8+b3
ii  libsqlite3-0  3.16.2-3~bpo8+1

sqlite3 recommends no packages.

Versions of packages sqlite3 suggests:
ii  sqlite3-doc  3.16.2-3~bpo8+1

-- no debconf information

--- sqlite3-3.19.2/configure.ac.orig	2017-06-02 12:59:06.0 +0300
+++ sqlite3-3.19.2/configure.ac	2017-06-02 13:56:39.0 +0300
@@ -628,7 +628,7 @@
   [enable_memsys5=yes],[enable_memsys5=no])
 AC_MSG_CHECKING([whether to support MEMSYS5])
 if test "${enable_memsys5}" = "yes"; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_MEMSYS5"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_MEMSYS5"
   AC_MSG_RESULT([yes])
 else
   AC_MSG_RESULT([no])
@@ -638,7 +638,7 @@
   [enable_memsys3=yes],[enable_memsys3=no])
 AC_MSG_CHECKING([whether to support MEMSYS3])
 if test "${enable_memsys3}" = "yes" -a "${enable_memsys5}" = "no"; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_MEMSYS3"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_MEMSYS3"
   AC_MSG_RESULT([yes])
 else
   AC_MSG_RESULT([no])
@@ -650,20 +650,20 @@
   [Enable the FTS3 extension]),
   [enable_fts3=yes],[enable_fts3=no])
 if test "${enable_fts3}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_FTS3"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_FTS3"
 fi
 AC_ARG_ENABLE(fts4, AC_HELP_STRING([--enable-fts4],
   [Enable the FTS4 extension]),
   [enable_fts4=yes],[enable_fts4=no])
 if test "${enable_fts4}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_FTS4"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_FTS4"
   AC_SEARCH_LIBS([log],[m])
 fi
 AC_ARG_ENABLE(fts5, AC_HELP_STRING([--enable-fts5],
   [Enable the FTS5 extension]),
   [enable_fts5=yes],[enable_fts5=no])
 if test "${enable_fts5}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_FTS5"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_FTS5"
   AC_SEARCH_LIBS([log],[m])
 fi
 
@@ -673,7 +673,7 @@
   [Enable the JSON1 extension]),
   [enable_json1=yes],[enable_json1=no])
 if test "${enable_json1}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_JSON1"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_JSON1"
 fi
 
 #
@@ -682,7 +682,7 @@
   [Enable the RTREE extension]),
   [enable_rtree=yes],[enable_rtree=no])
 if test "${enable_rtree}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_RTREE"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_RTREE"
 fi
 
 #
@@ -691,12 +691,12 @@
   [Enable the SESSION extension]),
   [enable_session=yes],[enable_session=no])
 if test "${enable_session}" = "yes" ; then
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_SESSION"
-  OPT_FEATURE_FLAGS="$(OPT_FEATURE_FLAGS) -DSQLITE_ENABLE_PREUPDATE_HOOK"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_SESSION"
+  OPT_FEATURE_FLAGS="${OPT_FEATURE_FLAGS} -DSQLITE_ENABLE_PREUPDATE_HOOK"
 fi
 
 #
-# attempt to duplicate any OMITS and ENABLES into the $(OPT_FEATURE_FLAGS) parameter
+# attempt to duplicate any OMITS and ENABLES into the ${OPT_FEATURE_FLAGS} parameter
 for option in $CFLAGS $CPPFLAGS
 do
   case $option in
@@ -707,7 +707,7 @@
 AC_SUBST(OPT_FEATURE_FLAGS)
 
 
-# attempt to remove any OMITS and ENABLES from the $(CFLAGS) parameter
+# attempt to remove any OMITS and ENABLES from the ${CFLAGS} parameter
 ac_temp_CFLAGS=""
 for option in $CFLAGS
 do
@@ -720,7 +720,7 @@
 CFLAGS=$ac_temp_CFLAGS
 
 
-# attempt to remove any OMITS and ENABLES from the $(CPPFLAGS) parameter
+# attempt to remove any OMITS and ENABLES from the ${CPPFLAGS} parameter
 ac_temp_CPPFLAGS=""
 for option in $CPPFLAGS
 do
@@ -733,7 +733,7 @@
 CPPFLAGS=$ac_temp_CPPFLAGS
 
 
-# attempt to remove any OMITS and ENABLES from the $(BUILD_CFLAGS) parameter
+# attempt to remove any OMITS and ENABLES from the ${BUILD_CFLAGS} parameter
 

Bug#863984: mc: "gzip: No such file or directory" when compressing from menu

[Yuriy M. Kaminskiy]

Package: mc
Version: 3:4.8.18-1
Severity: normal
Tags: upstream patch

Dear Maintainer,

When compressing file from menu (F2)->y (Gzip or gunzip current file),
there are message
gzip: No such file or directory
This is due to inadequate shell quoting in menu:
=== cut /etc/mc/mc.menu ===
y   Gzip or gunzip current file
unset DECOMP
case %f in
*.gz|*.[zZ]) DECOMP=-d;;
esac
gzip "$DECOMP" -v %f
#^---^
+ t t
=== cut ===
When file is not compressed and DECOMP is empty, it should be replaced 
by *nothing*, not an empty argument.

This is regression from jessie (it was correct back then).
Patch attached.

Note: version edited, I use self-backported 3:4.8.18-1 on jessie.

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mc depends on:
ii  libc6 2.19-18+deb8u9
ii  libglib2.0-0  2.42.1-1+b1
ii  libgpm2   1.20.4-6.1+b2
ii  libslang2 2.3.0-2
ii  libssh2-1 1.4.3-4.1+deb8u1
ii  mc-data   3:4.8.18-1

Versions of packages mc recommends:
ii  mime-support  3.58
ii  perl  5.20.2-3+deb8u6
ii  unzip 6.0-16+deb8u3

Versions of packages mc suggests:
pn  arj  
ii  bzip21.0.6-7+b3
pn  dbview   
ii  djvulibre-bin3.5.25.4-4+b1
ii  evince-gtk [pdf-viewer]  3.14.1-2+deb8u1
ii  file 1:5.22+15-2+deb8u3
ii  genisoimage  9:1.1.11-3
ii  gv [pdf-viewer]  1:3.7.4-1
ii  imagemagick  8:6.8.9.9-5+deb8u9
pn  libaspell-dev
ii  mupdf [pdf-viewer]   1.5-1+deb8u2
ii  odt2txt  0.4+git20140608-1
ii  poppler-utils0.26.5-2+deb8u1
ii  python   2.7.9-1
pn  python-boto  
pn  python-tz
ii  texlive-binaries 2014.20140926.35254-6
ii  w3m  0.5.3-19+deb8u1
ii  xpdf [pdf-viewer]3.03-17+b1
ii  zip  3.0-8

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/lib/mc/ext.d/archive.sh (from mc package)
debsums: changed file /usr/lib/mc/ext.d/image.sh (from mc package)
debsums: changed file /usr/lib/mc/ext.d/misc.sh (from mc package)
debsums: changed file /usr/lib/mc/extfs.d/urar (from mc package)

Index: mc-4.8.18/misc/mc.menu.in
===
--- mc-4.8.18.orig/misc/mc.menu.in
+++ mc-4.8.18/misc/mc.menu.in
@@ -241,7 +241,8 @@ y   Gzip or gunzip current file
 case %f in
 *.gz|*.[zZ]) DECOMP=-d;;
 esac
-gzip "$DECOMP" -v %f
+# do *not* add quotes around $DECOMP!
+gzip $DECOMP -v %f
 
 + t t
 Y   Gzip or gunzip tagged files
@@ -250,7 +251,7 @@ Y   Gzip or gunzip tagged files
 case "$i" in
 *.gz|*.[zZ]) DECOMP=-d;;
 esac
-gzip "$DECOMP" -v "$i"
+gzip $DECOMP -v "$i"
 done
 
 + ! t t
@@ -259,7 +260,7 @@ b   Bzip2 or bunzip2 current file
 case %f in
 *.bz2) DECOMP=-d;;
 esac
-bzip2 "$DECOMP" -v %f
+bzip2 $DECOMP -v %f
 
 + t t
 B   Bzip2 or bunzip2 tagged files
@@ -268,7 +269,7 @@ B   Bzip2 or bunzip2 tagged files
 case "$i" in
 *.bz2) DECOMP=-d;;
 esac
-bzip2 "$DECOMP" -v "$i"
+bzip2 $DECOMP -v "$i"
 done
 
 + f \.tar.gz$ | f \.tgz$ | f \.tpz$ | f \.tar.Z$ | f \.tar.z$ | f \.tar.bz2$ | f \.tar.F$ & t r & ! t t

Bug#863818: nocache is not multi-arch co-installable

[Yuriy M. Kaminskiy]

Package: nocache
Version: 1.0-1
Severity: normal
Tags: patch

Dear Maintainer,

To be effective for all enabled arches (e.g. with i386 cp and amd64 
lrzip, `nocache lrzip foo; nocache cp foo.lrz /path/to/`, nocache must 
be multi-arch co-installable. It is currently not (either you have it 
for i386 [and it is of no use for amd64], or you have it amd64 [and it 
is of no use for i386]).


Attached (somewhat hackish) patch fixes this (splits nocache to `M-A: 
foreign` main package containing binaries and wrapper script, and `M-A: 
same` libnocache package [supposed to be co-installed for all enabled 
architectures];
Alternative layout can be main `M-A: same` package containing 
/usr/bin/nocache and /usr/lib/*/nocache/*, and split off /usr/bin/cache* 
binaries to separate `M-A: foreign` package.


FIXME: only checked on linux; no idea if hurd/kfreebsd ld.so also
supports $LIB (and multi-arch).

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nocache depends on:
ii  libc6  2.19-18+deb8u9
ii  multiarch-support  2.19-18+deb8u9

nocache recommends no packages.

nocache suggests no packages.

-- no debconf information

diff -Nru nocache-1.0/debian/changelog nocache-1.0/debian/changelog
--- nocache-1.0/debian/changelog	2016-05-21 07:18:22.0 +0300
+++ nocache-1.0/debian/changelog	2017-05-31 16:27:47.0 +0300
@@ -1,3 +1,10 @@
+nocache (1.0-1.1) UNRELEASED; urgency=medium
+
+  * Add Multi-Arch support.
+
+ -- Yuriy M. Kaminskiy <yumkam+deb...@gmail.com>  Wed, 31 May 2017 15:23:17 +0300
+
 nocache (1.0-1) unstable; urgency=medium
 
   * New upstream release [May 2016].
diff -Nru nocache-1.0/debian/control nocache-1.0/debian/control
--- nocache-1.0/debian/control	2016-05-21 07:10:04.0 +0300
+++ nocache-1.0/debian/control	2017-05-31 16:30:36.0 +0300
@@ -12,7 +12,8 @@
 
 Package: nocache
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Multi-Arch: foreign
+Depends: ${misc:Depends}, ${shlibs:Depends}, libnocache (= ${binary:Version})
 Description: bypass/minimize file system caching for a program
  `nocache` tries to minimize the effect an application has on the Linux
  file system cache.
@@ -23,3 +24,18 @@
  Also this package provides the following utilities:
  * `cachedel`   : clear page cache for a file.
  * `cachestats` : print number of cached vs. not-cached pages for a file
+
+Package: libnocache
+Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: bypass/minimize file system caching for a program - library
+ `nocache` tries to minimize the effect an application has on the Linux
+ file system cache.
+ .
+ Use case: backup processes that should not interfere with the present
+ state of the cache.
+ .
+ This package contains (multi-arch) shared library for nocache (should
+ be installed in all enabled architectures).
diff -Nru nocache-1.0/debian/libnocache.install nocache-1.0/debian/libnocache.install
--- nocache-1.0/debian/libnocache.install	1970-01-01 03:00:00.0 +0300
+++ nocache-1.0/debian/libnocache.install	2017-05-31 16:25:42.0 +0300
@@ -0,0 +1 @@
+usr/lib/*/nocache/*.so
diff -Nru nocache-1.0/debian/manpages nocache-1.0/debian/manpages
--- nocache-1.0/debian/manpages	2013-05-02 05:49:40.0 +0400
+++ nocache-1.0/debian/manpages	1970-01-01 03:00:00.0 +0300
@@ -1 +0,0 @@
-man/*.1
diff -Nru nocache-1.0/debian/nocache.install nocache-1.0/debian/nocache.install
--- nocache-1.0/debian/nocache.install	1970-01-01 03:00:00.0 +0300
+++ nocache-1.0/debian/nocache.install	2017-05-31 16:25:58.0 +0300
@@ -0,0 +1 @@
+usr/bin/*
diff -Nru nocache-1.0/debian/nocache.manpages nocache-1.0/debian/nocache.manpages
--- nocache-1.0/debian/nocache.manpages	1970-01-01 03:00:00.0 +0300
+++ nocache-1.0/debian/nocache.manpages	2013-05-02 05:49:40.0 +0400
@@ -0,0 +1 @@
+man/*.1
diff -Nru nocache-1.0/debian/rules nocache-1.0/debian/rules
--- nocache-1.0/debian/rules	2016-05-21 07:16:55.0 +0300
+++ nocache-1.0/debian/rules	2017-05-31 16:27:30.0 +0300
@@ -4,14 +4,17 @@
 #export DH_VERBOSE=1
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
 %:
 	dh $@
 
 override_dh_auto_install:
-	dh_auto_install -v -- PREFIX=/usr LIBDIR=/lib/$(PKG)
+	dh_auto_install -v -- PREFIX=/usr LIBDIR=/lib/$(DEB_HOST_MULTIARCH)/$(PKG)
+	# make script multi-arch co-installable, see man ld.so(8) /Rpath token expansion
+	sed -i 's,lib/$(DEB_HOST_MULTIARCH)/,\\$$LIB/,' $(CURDIR)/debian/tmp/usr/bin/$(PKG)
 	#

Bug#863664: uim-gtk2.0: gtk{2,3}/qt/qt5 IM plugins are not multi-arch co-installable

[Yuriy M. Kaminskiy]

Package: uim-gtk2.0
Version: 1:1.8.6-8
Severity: important

Dear Maintainer,

gtk{2,3}, qt and qt5 IM plugins
/usr/lib/$ARCH/gtk-2.0/2.10.0/immodules/im-uim.so
/usr/lib/$ARCH/gtk-3.0/3.0.0/immodules/im-uim.so
/usr/lib/$ARCH/qt4/plugins/inputmethods/libuiminputcontextplugin.so
/usr/lib/$ARCH/qt5/plugins/platforminputcontexts/libuimplatforminputcontextplugin.so
are supposed to be used and installed for all enabled architectures, but 
shipped in non-multi-arched packages uim-{gtk2.0,gtk3,qt,qt5}. I guess, 
they should be splitted off to separate packages with Multi-Arch: same; 
also uim-{gtk2.0,gtk3,qt,qt5} should
be marked as Multi-Arch: foreign, as (with exception of those gtk/qt 
plugins) they contain non-arch-specific tools, that can be called by 
different-arch programs.


(TBD: why /usr/lib/i386-linux-gnu/uim/uim-candwin-{*gtk{,3},qt[45]} are 
in architecture-specific locations? (they either should be moved 
together with gtk/qt plugins, or moved to non-arch-specific directories, 
have not checked code yet).)


Also, I think uim-skk, uim-anthy, uim-m17nlib should be marked 
Multi-Arch: same, as they are also should be used by each arch plugin 
(and, obviously, co-installable).


And almost all remaining non-marked utilities/plugins packages
(especially Arch:all) should be marked Multi-Arch: foreign (otherwise 
they are satisfied as dependency only for primary architecture).


(I'm on jessie, but I checked packaging and file lists of
uim 1:1.8.6+gh20161003.0.d63dadd-2 from stretch/sid, it seems to be
affected too).

-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages uim-gtk2.0 depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u7
ii  libcairo21.14.0-2.1+deb8u2
ii  libfontconfig1   2.11.0-6.3+deb8u1
ii  libfreetype6 2.5.2-3+deb8u2
ii  libgcroots0  0.8.5-4.1
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libuim-custom2   1:1.8.6-8
ii  libuim-data  1:1.8.6-8
ii  libuim-scm0  1:1.8.6-8
ii  libuim8  1:1.8.6-8
ii  libx11-6 2:1.6.2-3
ii  uim-common   1:1.8.6-8
ii  uim-utils1:1.8.6-8

uim-gtk2.0 recommends no packages.

Versions of packages uim-gtk2.0 suggests:
ii  uim-dict-gtk  1:1.8.6-8

-- no debconf information

Bug#862338: libsmbclient is not multi-arch co-installable due to samba-libs->python-talloc

[Yuriy M. Kaminskiy]

Package: libsmbclient
Version: 2:4.2.14+dfsg-0+deb8u5
Severity: normal

Dear Maintainer,

I tried to install both `libsmbclient:i386` and `libsmbclient:amd64` and
failed, as `libsmbclient` (m-a: same) depends on `samba-libs` (m-a: 
same), and `samba-libs` depends on `python-talloc` (*not* multi-arch 
[and while it technically can be marked as m-a:same {it contains no 
conflicting files between arches}, but it depends on `python` package, 
which certainly cannot be co-installable, so it won't solve anything]).


(I have not verified on stretch/sid, but according to dependencies shown 
on `packages.debian.org/`, this problem is not fixed there too).


-- System Information:
Debian Release: 8.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsmbclient depends on:
ii  dpkg   1.17.27
ii  libbsd00.7.0-2
ii  libc6  2.19-18+deb8u7
ii  libtalloc2 2.1.2-0+deb8u1
ii  multiarch-support  2.19-18+deb8u7
ii  samba-libs 2:4.2.14+dfsg-0+deb8u5

libsmbclient recommends no packages.

libsmbclient suggests no packages.

-- no debconf information

Bug#831467: This "fix" is totally bogus and should be reverted ASAP

[Yuriy M. Kaminskiy]

As noted in (forwarded) github issue, this "fix" is totally bogus and 
(likely) breaks things.


ExecStop command is expected to kill daemon (in a friendly way), while 
(default handler for) kill(SIGSTOP) pauses/freezes/suspends process 
execution (and transmission-daemon does not override default SIGSTOP 
handler).


If ExecStop is not specified, systemd sends SIGTERM (which is handled by 
transmission-daemon, and should do right thing), and then (if process is 
still alive) SIGKILL.


If ExecStop is specified, but does not actually finish process (and kill 
-STOP does NOT finish transmission-daemon process), systemd waits for 
TimeoutStopSec, then sends SIGTERM (but as kill -STOP just suspended 
process, it will NOT be handled by transmission-daemon), and then (as 
process is still alive) sends SIGKILL.


So, as a result of this patch, transmission-daemon is killed in VERY 
unfriendly way (and very *slowly* - after waiting for 2*TimeoutStopSec).


As pointed in github issue, original poster log indicates that 
transmission-daemon dies by SIGSEGV, which is NOT signal that was 
(possibly) sent by systemd. That is, it is some transmission-daemon bug 
that was just triggered during "clean" process termination, and NOT 
systemd interaction issue.
Obviously, when daemon is hard-killed, this SIGSEGV is not (immediately) 
triggered, but it does not really fix issue, only hides it.


P.S. from first look at sources, transmission-daemon handles termination 
signals synchronously, so this is (probably) not 
async-signal-unsafe-function-in-signal-handler kind of bug.

Bug#843762: rcs: SIGSEGV on rcs -u1.2 -l1.1 foo

[Yuriy M. Kaminskiy]

Control: tag -1 patch
thanks

On 09.11.2016 13:31, Yuriy M. Kaminskiy wrote:

Program received signal SIGSEGV, Segmentation fault.
0x565629a2 in extend (tp=0x0, x=0xd8a2, to=0x565a00b0) at b-esds.c:39
39  EXTEND_BODY (link);


I looked a bit more at EXTEND_BODY macro and *extend functions, they do 
something *very* strange and confusing.

Assuming I got it right, attached patch should fix the issue.


(gdb) bt full
#0  0x565629a2 in extend (tp=0x0, x=0xd8a2, to=0x565a00b0) at
b-esds.c:39
 pair = 0x565b6218
rmnewlocklst is supposed to return pointer to last list element, but actually always return NULL;
tplock is expected to be pointer to last list element, or dummy head.

Index: rcs-5.9.4/src/rcs.c
===
--- rcs-5.9.4.orig/src/rcs.c
+++ rcs-5.9.4/src/rcs.c
@@ -383,14 +383,19 @@ rmnewlocklst (struct adminstuff *dc, cha
 /* Remove lock to revision ‘which’ from ‘dc->newlocks’.  */
 {
   struct link *pt, **pre;
+  struct link *ret;
 
   pre = >newlocks;
+  ret = NULL;
   while ((pt = *pre))
 if (STR_DIFF (pt->entry, which))
   pre = >next;
 else
+{
+  ret = pt;
   *pre = pt->next;
-  return *pre;
+}
+  return ret;
 }
 
 static bool
@@ -1210,6 +1215,7 @@ rcs_main (const char *cmd, int argc, cha
   tprm = extend (tprm, a, PLEXUS);
   dc.newlocks = boxlock.next;
   tplock = rmnewlocklst (, a);
+  if (tplock == NULL) tplock = 
   break;
 
 case 'L':

Bug#841935: pbuilder: incorrect permissions on /dev/ptmx breaks openpty()

[Yuriy M. Kaminskiy]

On 06.11.2016 23:41, James Clarke wrote:

On 6 Nov 2016, at 20:34, Yuriy M. Kaminskiy <yum...@gmail.com> wrote:

Andreas Henriksson <andr...@fatal.se> writes:


It seems /dev/ptmx has incorrect permissions in a pbuilder chroot:

# ls -l /dev/ptmx
lrwxrwxrwx 1 root root 8 Oct  4 06:43 /dev/ptmx -> pts/ptmx
# ls -l /dev/pts/ptmx
c- 1 root root 5, 2 Oct 24 14:46 /dev/pts/ptmx

Please compare to what's stated in
https://www.kernel.org/doc/Documentation/filesystems/devpts.txt

For comparison this is from my regular system:
$ ls -l /dev/ptmx /dev/pts/ptmx
crw-rw-rw- 1 root tty  5, 2 okt 24 17:03 /dev/ptmx
c- 1 root root 5, 2 okt 11 12:35 /dev/pts/ptmx

I've hacked up my pbuilder installation and confirmed that appending
",ptmxmode=0666" to the /dev/pts mount flags fixes the issue.


IIRC, it would also need `,newinstance` option by then (otherwise
it will clobber "host system" devpts options).


newinstance seems to be a world of pain, as then it can’t access the TTY
for std{in,out,err}. I tried many months ago and couldn’t get it to work,
but would love to be proved wrong.


Then, probably, it should `mount --bind` "host system" /dev/pts and 
/dev/ptmx? (as mounting devpts again with different options has 
undesirable side effects)

Bug#841935: pbuilder: incorrect permissions on /dev/ptmx breaks openpty()

[Yuriy M. Kaminskiy]

Andreas Henriksson  writes:


It seems /dev/ptmx has incorrect permissions in a pbuilder chroot:

# ls -l /dev/ptmx
lrwxrwxrwx 1 root root 8 Oct  4 06:43 /dev/ptmx -> pts/ptmx
# ls -l /dev/pts/ptmx
c- 1 root root 5, 2 Oct 24 14:46 /dev/pts/ptmx

Please compare to what's stated in
https://www.kernel.org/doc/Documentation/filesystems/devpts.txt

For comparison this is from my regular system:
$ ls -l /dev/ptmx /dev/pts/ptmx
crw-rw-rw- 1 root tty  5, 2 okt 24 17:03 /dev/ptmx
c- 1 root root 5, 2 okt 11 12:35 /dev/pts/ptmx

I've hacked up my pbuilder installation and confirmed that appending
",ptmxmode=0666" to the /dev/pts mount flags fixes the issue.


IIRC, it would also need `,newinstance` option by then (otherwise
it will clobber "host system" devpts options).


This issue was detected while building the util-linux package where
the testsuite now has started to fail (specifically the
tests/ts/script/buffering-race test, since 'script' uses openpty).

See attached patch.

Bug#843176: libgtk-3-0: "Invalid column number ... added to iter" in GTK+ Inspector

[Yuriy M. Kaminskiy]

Package: libgtk-3-0
Version: 3.14.5-1+deb8u1
Severity: normal
Tags: upstream jessie patch fixed-upstream

Dear Maintainer,

While running wireshark from jessie-backports with GTK+ Inspector 
enabled (`GTK_DEBUG=interactive wireshark-gtk`) I got large number of


(wireshark-gtk:3784): Gtk-WARNING **:
/build/gtk+3.0-b165l9/gtk+3.0-3.14.5/./gtk/gtktreestore.c:1042: Invalid
column number -150702538 added to iter (remember to end your list of
columns with a -1)

GDB backtrace from g_log attached.
This seems comes from type mismatch in 
gtk/inspector/recource-list.{c,ui}: resource-list.ui declares last 
column as guint64,

but resource-list.c uses gsize (32-bit on 32-bit architectures).
This results in above warning, out-of-buffer stack read inside 
gtk_tree_model_set (likely harmless except for leaking 4 bytes from 
stack on little-endian, but up to crash/DoS on big-endian), and 
out-of-buffer stack write in gtk_tree_model_get.


I doubt it is practically exploitable, but you can never be sure.

See upstream patch "inspector: be careful about gsize vs guint64" 
(extracted from

https://mail.gnome.org/archives/commits-list/2015-January/msg02295.html
and attached below; it seems it was already included in stretch/sid version)
This patch seems also was included in gtk+-3.14.7 (btw, WTF upstream 
*stable* patches are not *automatically* shipped with [at least] point 
releases??? many crash bugs are potential security issues (even if not 
explicitly marked as such by upstream devs), and it is extremely 
annoying to debug issue only to discover it was already fixed in 
upstream *stable* branch years ago :-\).


-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgtk-3-0 depends on:
ii  libatk-bridge2.0-0   2.14.0-2
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u6
ii  libcairo-gobject21.14.0-2.1+deb8u1
ii  libcairo21.14.0-2.1+deb8u1
ii  libcolord2   1.2.1-1+b2
ii  libcups2 1.7.5-11+deb8u1
ii  libfontconfig1   2.11.0-6.3+deb8u1
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk-3-common  3.14.5-1+deb8u1
ii  libjson-glib-1.0-0   1.0.2-1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  librest-0.7-00.7.92-3
ii  libsoup2.4-1 2.48.0-1
ii  libwayland-client0   1.6.0-2
ii  libwayland-cursor0   1.6.0-2
ii  libx11-6 2:1.6.2-3
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.1-2+b2
ii  libxi6   2:1.7.4-1+b2
ii  libxinerama1 2:1.1.3-1+b1
ii  libxkbcommon00.4.3-2
ii  libxml2  2.9.1+dfsg1-5+deb8u3
ii  libxrandr2   2:1.4.2-1+b1
ii  multiarch-support2.19-18+deb8u6
ii  shared-mime-info 1.3-1

Versions of packages libgtk-3-0 recommends:
ii  hicolor-icon-theme  0.13-1
ii  libgtk-3-bin3.14.5-1+deb8u1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.22.2-1
ii  librsvg2-common  2.40.5-1+deb8u2

-- no debconf information

(gdb) bt
#0  g_log (log_domain=0xf7b89263 "Gtk", log_level=G_LOG_LEVEL_WARNING, 
format=0xf7bc84bc "%s: Invalid column number %d added to iter (remember to 
end your list of columns with a -1)")
at /build/glib2.0-3vWc1h/glib2.0-2.42.1/./glib/gmessages.c:1075
#1  0xf7afefa7 in gtk_tree_store_set_valist_internal (
tree_store=tree_store@entry=0x56a1d300, iter=iter@entry=0xcc7c, 
emit_signal=0xcbd4, maybe_need_sort=0xcbd8, 
var_args=0xcc40 
"ÐۉV|ÍÿÿÐۉV|Ìÿÿè1±VüÌÿÿà\030ˆVôÌÿÿøÌÿÿxÌÿÿtÌÿÿ\030g°V°™®V\001") at 
/build/gtk+3.0-b165l9/gtk+3.0-3.14.5/./gtk/gtktreestore.c:1042
#2  0xf7b006ca in gtk_tree_store_set_valist (tree_store=0x56a1d300, 
iter=0xcc7c, var_args=0xcc28 "\002")
at /build/gtk+3.0-b165l9/gtk+3.0-3.14.5/./gtk/gtktreestore.c:1144
#3  0xf7b00754 in gtk_tree_store_set (tree_store=0x56a1d300, iter=0xcc7c)
at /build/gtk+3.0-b165l9/gtk+3.0-3.14.5/./gtk/gtktreestore.c:1186
#4  0xf7b84bbe in load_resources_recurse (sl=sl@entry=0x569e8428, 
parent=parent@entry=0xccfc, path=0x568818e0 "/org/wireshark/image/", 
count_out=0xccf4, size_out=0xccf8)
at /build/gtk+3.0-b165l9/gtk+3.0-3.14.5/./gtk/inspector/resource-list.c:100
#5  0xf7b84b99 in load_resources_recurse (sl=sl@entry=0x569e8428, 
parent=parent@entry=0xcd7c, path=0x56afb9b0 "/org/wireshark/", 
count_out=0xcd74, size_out=0xcd78)
at 

Bug#840510: geoip-generator-asn: broken ASN due to csv misparsing

[Yuriy M. Kaminskiy]

On 12.10.2016 13:58, Yuriy M. Kaminskiy wrote:

P.S. ASN/ipv6 change in patch is completely untested (it seems produces
mangled database [as before]).


oops, above ipv6 issue was my patch fault, patch v2 attached, now

$ wget -q 
http://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum2v6.zip 
&& unzip -q GeoIPASNum2v6.zip

$ geoip-generator-asn -6 -o GeoIPASNumv6.dat GeoIPASNum2v6.csv
$ geoiplookup6 -f GeoIPASNumv6.dat www.google.com
GeoIP ASNum V6 Edition: AS15169 Google Inc.
$ geoiplookup6 -f GeoIPASNumv6.dat 2001:67c:1270::
GeoIP ASNum V6 Edition: AS20712

(note: maxmind's original binary GeoIPASNumv6.dat also contains aliases 
for various mapped ipv4; above generated GeoIPASNumv6.dat contains only 
native ipv6 addresses)
--- geoip_1.6.7-2~bpo8+1/debian/src/geoip-asn-csv-to-dat.cpp.orig	2016-10-12 12:17:11.0 +0300
+++ geoip_1.6.7-2~bpo8+1/debian/src/geoip-asn-csv-to-dat.cpp	2016-10-12 15:41:31.0 +0300
@@ -478,9 +478,12 @@
 		for(int i = 0; i<2;++i) {
 			fs = buf.find(delim);
 			fields.push_back(buf.substr(0,fs));
-			buf.erase(0,fs + 1);
+			buf.erase(0,fs + delim.length());
 		}
+		if (buf[0] == '"' || buf[0] == '\'')
 		fields.push_back(buf.substr(1, buf.length() - 2));
+		else
+			fields.push_back(buf);
 	}
 
 	void
@@ -489,13 +492,16 @@
 		std::vector & fields)
 	{
 		std::string buf(line);
-		std::string delim = ", ";
+		std::string delim = ",";
 		std::size_t fs;
 		for(int i = 0; i<3;++i) {
 			fs = buf.rfind(delim);
-			fields.push_back(buf.substr(fs+2, buf.length()));
+			fields.push_back(buf.substr(fs+delim.length(), buf.length()));
 			buf.erase(fs,buf.length());
 		}
+		if (buf[0] == '"' || buf[0] == '\'')
+			fields.push_back(buf.substr(1, buf.length() - 2));
+		else
 		fields.push_back(buf.substr(0, buf.length()));
 	}
 
@@ -602,7 +608,7 @@
 		  "Cannot parse maximum address: %s",
 		  csv_fields[V6_CSV_FIELD_MAX_TEXT].c_str());
 }
-trie.set_range(minaddr.inetbytes, maxaddr.inetbytes,
+trie.set_range(minaddr.inet6.s6_addr, maxaddr.inet6.s6_addr,
 	   128, leaf);
 break;
 

Bug#840510: geoip-generator-asn: broken ASN due to csv misparsing

[Yuriy M. Kaminskiy]

Package: geoip-bin
Version: 1.6.2-4
Severity: normal
Tags: patch

Dear Maintainer,

I noticed that some ASN looks mangled (first and last character cut off,
e.g. `geopiplookup 163.172.217.0|tail -1` -> 'GeoIP ASNum Edition: 
S1287' [it should've been 'GeoIP ASNum Edition: AS12876'])

and discovered that geoip-generator-asn misparses unquoted CSV fields.

This bug also affects geoip-database-extra in jessie-backports (and 
likely jessie too).


Patch attached (note: I only made minimal effort to make things work, 
this "CSV parser" is still incomplete and fails to handle full CSV syntax).


P.S. ASN/v6 change in patch is completely untested (it seems produces
mangled database [as before]).

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages geoip-bin depends on:
ii  libc6   2.19-18+deb8u6
ii  libgcc1 1:4.9.2-10
ii  libgeoip1   1.6.2-4
ii  libstdc++6  4.9.2-10

geoip-bin recommends no packages.

geoip-bin suggests no packages.

-- no debconf information

--- geoip_1.6.7-2~bpo8+1/debian/src/geoip-asn-csv-to-dat.cpp.orig	2016-10-12 12:17:11.0 +0300
+++ geoip_1.6.7-2~bpo8+1/debian/src/geoip-asn-csv-to-dat.cpp	2016-10-12 12:28:38.0 +0300
@@ -480,7 +480,10 @@
 			fields.push_back(buf.substr(0,fs));
 			buf.erase(0,fs + 1);
 		}
+		if (buf[0] == '"' || buf[0] == '\'')
 		fields.push_back(buf.substr(1, buf.length() - 2));
+		else
+			fields.push_back(buf);
 	}
 
 	void
@@ -489,13 +492,16 @@
 		std::vector & fields)
 	{
 		std::string buf(line);
-		std::string delim = ", ";
+		std::string delim = ",";
 		std::size_t fs;
 		for(int i = 0; i<3;++i) {
 			fs = buf.rfind(delim);
 			fields.push_back(buf.substr(fs+2, buf.length()));
 			buf.erase(fs,buf.length());
 		}
+		if (buf[0] == '"' || buf[0] == '\'')
+			fields.push_back(buf.substr(1, buf.length() - 2));
+		else
 		fields.push_back(buf.substr(0, buf.length()));
 	}
 

Bug#838420: gifsicle: incorrect escape for 8-bit characters on platforms with signed char

[Yuriy M. Kaminskiy]

Package: gifsicle
Version: 1.86-1
Severity: minor
Tags: upstream patch

Dear Maintainer,

When showing comment containing non-ASCII characters, `gifsicle -I` 
shows incorrect escape code (\364 instead of \364) on platforms 
with signed char (e.g. x86{,_64}).

Patches against 1.86 and 1.88 attached.

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gifsicle depends on:
ii  libc6 2.19-18+deb8u4
ii  libice6   2:1.0.9-1+b1
ii  libsm62:1.2.2-1+b1
ii  libx11-6  2:1.6.2-3

gifsicle recommends no packages.

gifsicle suggests no packages.

-- no debconf information

Index: gifsicle-1.86/src/support.c
===
--- gifsicle-1.86.orig/src/support.c
+++ gifsicle-1.86/src/support.c
@@ -310,7 +310,7 @@ safe_puts(const char *s, uint32_t len, F
case '\v': fputs("\\v", f); break;
case '\\': fputs("", f); break;
case 0:	  if (len > 1) fputs("\\000", f); break;
-   default:	  fprintf(f, "\\%03o", *s); break;
+   default:	  fprintf(f, "\\%03o", *s & 0xFF); break;
   }
 }
   if (last_safe != s) {

Index: gifsicle-1.88/src/support.c
===
--- gifsicle-1.88.orig/src/support.c
+++ gifsicle-1.88/src/support.c
@@ -311,7 +311,7 @@ safe_puts(const char *s, uint32_t len, F
case '\v': fputs("\\v", f); break;
case '\\': fputs("", f); break;
case 0:if (len > 1) fputs("\\000", f); break;
-   default:   fprintf(f, "\\%03o", *s); break;
+   default:   fprintf(f, "\\%03o", *s & 0xFF); break;
   }
 }
   if (last_safe != s) {

Bug#825378: perl: freeze on parsing (broken) code

[Yuriy M. Kaminskiy]

Control: tags -1 patch
thanks

On 28.05.2016 17:50, Dominic Hargreaves wrote:

On Thu, May 26, 2016 at 04:47:07PM +0100, Dominic Hargreaves wrote:

On Thu, May 26, 2016 at 04:22:45PM +0300, Yuriy M. Kaminskiy wrote:

Dear Maintainer,

I've made typo in code, and found that it freezes perl on attempt to parse:
 perl -ce 's{foo}{$h->X({->aaa=>"b"},$d)}ge'
( it was meant to be 's{foo}{$h->X({-aaa=>"b"},$d)}ge' )


Thanks for the report!

[snip backtrace]


(Theoretically, this can be called "potential DoS on parsing untrusted
code", but I'm pretty sure parsing untrusted perl code is not safe anyway).

It seems only jessie version affected, perl binaries extracted from
perl-base packages from wheezy and squeeze seems correctly report error:


Just to note that I can confirm that it we get a syntax error on
wheezy (so this is a regression for jessie).


$ ./perl5.22.2 -ce 's{foo}{$h->X({->aaa=>"b"},$d)}ge'
syntax error at -e line 1, near "{->aaa"
syntax error at -e line 1, near ")}"
-e had compilation errors.

It seems no changes in 5.20.2-3+deb8u5 (from jessie-proposed-updates) (also
freezes).


Thanks for the report!

I bisected this using something like:

cat ../test_prog.sh
#!/bin/sh

./perl -e 's{foo}{$h->X({->aaa=>"b"},$d)}ge;'

if [ $? = 255 ]; then
 exit 0
fi

../perl/Porting/bisect.pl --expect-fail --start v5.20.0 --end v5.22.0 --timeout 
2 -- ../test_prog.sh

This was fixed upstream by f8a7ccebba5637bf0cf5a23cea563b2ccd62312d[1],
which as you observed was first included in 5.22.0. It may be a candidate
for backporting to jessie / maint-5.20 upstream, but the patch doesn't
apply as-is.


Just to add to this: since perl 5.20 is out of support upstream, and
this isn't a critical issue, I suspect not much more will happen on
this bug from me. If someone else wants to backport the patch, I'd
happily consider it for inclusion in a future stable update.


Something like attached? (only complication: lack of op_sibling_splice 
in 5.20).
Compiled with pbuilder (BTW, needed USENETWORK=yes; otherwise it failed 
two tests for IO::Socket::IP; looks like #759799?), minimally tested, 
seems work.

Disclaimer: use with care/review carefully/IANAPH.
diff -Nru perl-5.20.2/debian/changelog perl-5.20.2/debian/changelog
--- perl-5.20.2/debian/changelog2016-05-24 01:42:25.0 +0300
+++ perl-5.20.2/debian/changelog2016-05-28 18:04:59.0 +0300
@@ -1,3 +1,10 @@
+perl (5.20.2-3+deb8u5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Backported fix for freeze on parsing invalid code (Closes: #825378)
+
+ -- Yuriy M. Kaminskiy <yumkam+deb...@gmail.com>  Sat, 28 May 2016 18:04:02 
+0300
+
 perl (5.20.2-3+deb8u5) jessie; urgency=medium
 
   * Apply patch from Niko Tyni fixing debugperl crashes with XS
diff -Nru 
perl-5.20.2/debian/patches/fixes/perl.git-f8a7ccebba5637bf0cf5a23cea563b2ccd62312d.patch
 
perl-5.20.2/debian/patches/fixes/perl.git-f8a7ccebba5637bf0cf5a23cea563b2ccd62312d.patch
--- 
perl-5.20.2/debian/patches/fixes/perl.git-f8a7ccebba5637bf0cf5a23cea563b2ccd62312d.patch
1970-01-01 03:00:00.0 +0300
+++ 
perl-5.20.2/debian/patches/fixes/perl.git-f8a7ccebba5637bf0cf5a23cea563b2ccd62312d.patch
2016-05-28 18:33:37.0 +0300
@@ -0,0 +1,70 @@
+From f8a7ccebba5637bf0cf5a23cea563b2ccd62312d Mon Sep 17 00:00:00 2001
+From: Father Chrysostomos <spr...@cpan.org>
+Date: Fri, 3 Oct 2014 22:40:36 -0700
+Subject: [PATCH] Fix assertion failure/hang with / (?{(^{})/
+MIME-Version: 1.0
+Content-Type: text/plain; charset=utf8
+Content-Transfer-Encoding: 8bit
+
+When this invalid construct is parsed, the resulting op tree for the
+pattern has a code block with no constant item following it, breaking
+the assumptions made by pmruntime.
+
+Fixing this was not so easy.
+
+You can’t just adjust the assertions, because the hang that non-debug-
+ging builds exhibited is still there.
+
+You can’t just return NULL from pmruntime when encounting the bad op
+tree, because the parser will crash on the null pointer.
+
+You can’t just return the empty pmop, because the wrong pad is
+active, and other functions in op.c will try to access nonexistent
+pad entries.
+
+You can’t just LEAVE_SCOPE and return the pmop, because then PL_parser
+will be null in yyerror.  Changing yyerror to account is not suffi-
+cient, because then you get double-freed SVs.  At that point I gave up
+with that approach.
+
+The easiest solution turned out to be to fake up the op that we were
+expecting to see.
+---
+ op.c  | 10 +-
+ t/re/re_tests |  1 +
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+
+Bug-Debian: https://bugs.debian.org/825378
+
+Index: perl-5.20.2/op.c
+===
+--- perl-5.20.2.orig/op.c
 perl-5.20.2/op.c
+@@ -4846,7 +4846,14 @@ Perl_pmruntime(pTHX_ OP *o, OP *expr, bo
+ 

Bug#825378: perl: freeze on parsing (broken) code

[Yuriy M. Kaminskiy]

Package: perl
Version: 5.20.2-3+deb8u4
Severity: normal
Tags: jessie

Dear Maintainer,

I've made typo in code, and found that it freezes perl on attempt to parse:
perl -ce 's{foo}{$h->X({->aaa=>"b"},$d)}ge'
( it was meant to be 's{foo}{$h->X({-aaa=>"b"},$d)}ge' )

gdb backtrace (manually interrupted with ^C):
Program received signal SIGINT, Interrupt.
0x0806c60a in Perl_rpeep (my_perl=0x8215008, o=0x8238074) at op.c:11333
11333   op.c: No such file or directory.
(gdb) bt
#0  0x0806c60a in Perl_rpeep (my_perl=0x8215008, o=0x8238074) at op.c:11333
#1  0x08073509 in Perl_pmruntime (my_perl=0x8215008, o=0x82380f4, 
expr=0x8238474, isreg=true, floor=0) at op.c:4903

#2  0x080a3ae8 in Perl_yyparse (my_perl=0x8215008, gramtype=1536)
at perly.y:1385
#3  0x0807e836 in S_parse_body (xsinit=, env=out>, my_perl=) at perl.c:2298
#4  perl_parse (my_perl=0x8215008, xsinit=0x805ef80 , 
argc=136400904, argv=0x8215008, env=0x0) at perl.c:1607

#5  0x0805ede8 in main (argc=3, argv=0xd674, env=0xd684)
at perlmain.c:112

(Theoretically, this can be called "potential DoS on parsing untrusted 
code", but I'm pretty sure parsing untrusted perl code is not safe anyway).


It seems only jessie version affected, perl binaries extracted from 
perl-base packages from wheezy and squeeze seems correctly report error:

$ ./perl5.22.2 -ce 's{foo}{$h->X({->aaa=>"b"},$d)}ge'
syntax error at -e line 1, near "{->aaa"
syntax error at -e line 1, near ")}"
-e had compilation errors.

It seems no changes in 5.20.2-3+deb8u5 (from jessie-proposed-updates) 
(also freezes).


-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages perl depends on:
ii  dpkg  1.17.26
ii  libbz2-1.01.0.6-7+b3
ii  libc6 2.19-18+deb8u4
ii  libdb5.3  5.3.28-9
ii  libgdbm3  1.8.3-13.1
ii  perl-base 5.20.2-3+deb8u4
ii  perl-modules  5.20.2-3+deb8u4
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages perl recommends:
ii  netbase  5.3
ii  rename   0.20-3

Versions of packages perl suggests:
ii  libterm-readline-gnu-perl   1.24-2+b1
ii  libterm-readline-perl-perl  1.0303-1
ii  make4.0-8.1
ii  perl-doc5.20.2-3+deb8u4

-- no debconf information

Bug#824963: systemd-fsck run fsck for same disk in parallel

[Yuriy M. Kaminskiy]

Package: systemd
Version: 215-17+deb8u4
Severity: wishlist
Tags: jessie patch fixed-upstream

Dear Maintainer,

When mounting several filesystems, systemd runs all fsck in parallel. 
This is very unoptimal when filesystems shares same (rotational) 
physical disk.

systemd-fsck had provision to run fsck with -l option, but it was
temporarily disabled due to locking conflict between fsck and udev.
This conflict was fixed in util-linux-2.25, and "fsck -l" option 
re-enabled in systemd-217.
As jessie already has fixed version of util-linux (2.25.2), please 
consider cherry-pick commit v216-652-g48d3e8d (and maybe bump Depends on 
util-linux to 2.25 to reflect this) for next jessie point release.

(Debdiff attached).

-- Package-specific info:

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u4
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2+deb8u1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1+deb8u1
ii  libselinux1 2.3-2
ii  libsystemd0 215-17+deb8u4
ii  mount   2.25.2-6
ii  sysv-rc 2.88dsf-59
ii  udev215-17+deb8u4
ii  util-linux  2.25.2-6

Versions of packages systemd recommends:
ii  dbus1.8.20-0+deb8u1
ii  libpam-systemd  215-17+deb8u4

Versions of packages systemd suggests:
ii  systemd-ui  3-2

-- no debconf information

diff -Nru systemd-215/debian/control systemd-215/debian/control
--- systemd-215/debian/control	2015-11-16 20:08:49.0 +0300
+++ systemd-215/debian/control	2016-03-26 01:01:40.0 +0300
@@ -51,7 +51,7 @@
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  libsystemd0 (= ${binary:Version}),
- util-linux (>= 2.19.1-2),
+ util-linux (>= 2.25),
  mount (>= 2.21),
  initscripts (>= 2.88dsf-53.2),
  sysv-rc,
diff -Nru systemd-215/debian/patches/fsck-re-enable-fsck-l.patch systemd-215/debian/patches/fsck-re-enable-fsck-l.patch
--- systemd-215/debian/patches/fsck-re-enable-fsck-l.patch	1970-01-01 03:00:00.0 +0300
+++ systemd-215/debian/patches/fsck-re-enable-fsck-l.patch	2016-03-26 01:02:22.0 +0300
@@ -0,0 +1,57 @@
+From 48d3e8d07f2978f001cc85b2dddb7f8ec9d07006 Mon Sep 17 00:00:00 2001
+From: Karel Zak 
+Date: Wed, 22 Oct 2014 10:28:42 +0200
+Subject: [PATCH] fsck: re-enable fsck -l
+
+The -l (lock) has been temporary disabled due to conflict with
+udev (https://bugs.freedesktop.org/show_bug.cgi?id=79576)
+
+The problem is fixed since util-linux v2.25 (Jul 2014).
+---
+ README  |  3 ++-
+ src/fsck/fsck.c | 13 -
+ 2 files changed, 6 insertions(+), 10 deletions(-)
+
+diff --git a/README b/README
+index e0edd41..8f7a96e 100644
+--- a/README
 b/README
+@@ -129,8 +129,9 @@ REQUIREMENTS:
+ During runtime, you need the following additional
+ dependencies:
+ 
+-util-linux >= v2.19 (requires fsck -l, agetty -s),
++util-linux >= v2.19 required for agetty -s
+   v2.21 required for tests in test/
++  v2.25 required for fsck -l
+ dbus >= 1.4.0 (strictly speaking optional, but recommended)
+ sulogin (from util-linux >= 2.22 or sysvinit-tools, optional but recommended,
+  required for tests in test/)
+diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
+index dfe97bc..70a5918 100644
+--- a/src/fsck/fsck.c
 b/src/fsck/fsck.c
+@@ -320,16 +320,11 @@ int main(int argc, char *argv[]) {
+ cmdline[i++] = "-T";
+ 
+ /*
+- * Disable locking which conflict with udev's event
+- * ownershipi, until util-linux moves the flock
+- * synchronization file which prevents multiple fsck running
+- * on the same rotationg media, from the disk device
+- * node to a privately owned regular file.
+- *
+- * https://bugs.freedesktop.org/show_bug.cgi?id=79576#c5
+- *
+- * cmdline[i++] = "-l";
++ * Since util-linux v2.25 fsck uses /run/fsck/.lock files.
++ * The previous versions use flock for the device and conflict with
++ * udevd, see https://bugs.freedesktop.org/show_bug.cgi?id=79576#c5
+  */
++cmdline[i++] = "-l";
+ 
+ if (!root_directory)
+ cmdline[i++] = "-M";
+-- 
+2.1.4
+
diff -Nru 

Bug#799916: libjbig2dec0 is not Multi-Arch compatible

[Yuriy M. Kaminskiy]

On 16.05.2016 19:24, Jonas Smedegaard wrote:

Hi Yuriy,

Quoting Yuriy M. Kaminskiy (2016-05-16 17:17:04)

Patch (against 0.13-1) attached.


I believe your patch is flawed, however: the arch-specific jbig2dec
package should not be marked "foreign" as it is unusable by foreign
architectures.


It *is* usable, of course. It is multi-arch, not crossbuild-arch (or 
something), user is supposed to be able to run foreign arch binary on 
their system (either natively, or via qemu-user).
E.g. I can use jbig2dec:amd64 on primary-arch i386 (or reverse) 
perfectly fine. And if other package depends on jbig2dec binary, it can 
use native or (any of) foreign binary equally fine.

See https://wiki.debian.org/Multiarch/Implementation

Bug#824483: libjbig2dec0: unused and unrelated Memento memory debugging code

[Yuriy M. Kaminskiy]

Package: libjbig2dec0
Version: 0.13-1
Severity: normal
Tags: patch

Dear Maintainer,

I noticed that since ~0.12 libjbig2dec0.{a,so*} library includes
unused (and impossible to enable by library users) and unrelated Memento
memory debugging code.
Patch (against 0.13-1) attached.

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libjbig2dec0 depends on:
ii  libc6   2.19-18+deb8u4
ii  libpng12-0  1.2.50-2+deb8u2
ii  zlib1g  1:1.2.8.dfsg-2+b1

libjbig2dec0 recommends no packages.

libjbig2dec0 suggests no packages.

-- no debconf information

diff -Nru jbig2dec-0.13/debian/changelog jbig2dec-0.13/debian/changelog
--- jbig2dec-0.13/debian/changelog	2016-05-10 17:52:00.0 +0300
+++ jbig2dec-0.13/debian/changelog	2016-05-16 17:59:32.0 +0300
@@ -1,3 +1,10 @@
+jbig2dec (0.13-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't compile unrelated and unusable Memento memory debugging code.
+
+ -- Yuriy M. Kaminskiy <yumkam+deb...@gmail.com>  Mon, 16 May 2016 17:58:34 +0300
+
 jbig2dec (0.13-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru jbig2dec-0.13/debian/libjbig2dec0.symbols jbig2dec-0.13/debian/libjbig2dec0.symbols
--- jbig2dec-0.13/debian/libjbig2dec0.symbols	2016-05-10 17:40:23.0 +0300
+++ jbig2dec-0.13/debian/libjbig2dec0.symbols	2016-05-16 17:57:50.0 +0300
@@ -1,25 +1,4 @@
 libjbig2dec.so.0 libjbig2dec0 #MINVER#
- Memento_breakAt@Base 0.12
- Memento_breakOnFree@Base 0.12
- Memento_breakOnRealloc@Base 0.12
- Memento_breakpoint@Base 0.12
- Memento_calloc@Base 0.12
- Memento_check@Base 0.12
- Memento_checkAllMemory@Base 0.12
- Memento_checkBlock@Base 0.12
- Memento_failAt@Base 0.12
- Memento_find@Base 0.12
- Memento_free@Base 0.12
- Memento_getBlockNum@Base 0.12
- Memento_label@Base 0.12
- Memento_listBlocks@Base 0.12
- Memento_listNewBlocks@Base 0.12
- Memento_malloc@Base 0.12
- Memento_paranoidAt@Base 0.12
- Memento_realloc@Base 0.12
- Memento_setMax@Base 0.12
- Memento_setParanoia@Base 0.12
- Memento_stats@Base 0.12
  jbig2_alloc@Base 0.11
  jbig2_arith_Qe@Base 0.11
  jbig2_arith_decode@Base 0.11
diff -Nru jbig2dec-0.13/debian/patches/2001_disable_memento.patch jbig2dec-0.13/debian/patches/2001_disable_memento.patch
--- jbig2dec-0.13/debian/patches/2001_disable_memento.patch	1970-01-01 03:00:00.0 +0300
+++ jbig2dec-0.13/debian/patches/2001_disable_memento.patch	2016-05-16 17:58:29.0 +0300
@@ -0,0 +1,22 @@
+Index: jbig2dec-0.13/Makefile.am
+===
+--- jbig2dec-0.13.orig/Makefile.am
 jbig2dec-0.13/Makefile.am
+@@ -21,7 +21,7 @@ libjbig2dec_la_SOURCES = jbig2.c \
+ 	jbig2_arith.h jbig2_arith_iaid.h jbig2_arith_int.h \
+ 	jbig2_huffman.h jbig2_hufftab.h jbig2_mmr.h \
+ 	jbig2_generic.h jbig2_symbol_dict.h jbig2_text.h \
+-	jbig2_metadata.c jbig2_metadata.h memento.c memento.h
++	jbig2_metadata.c jbig2_metadata.h
+ 
+ bin_PROGRAMS = jbig2dec
+ noinst_PROGRAMS = test_sha1 test_huffman test_arith
+@@ -35,6 +35,8 @@ dist_man_MANS = jbig2dec.1
+ 
+ EXTRA_DIST = test_jbig2dec.py msvc.mak LICENSE CHANGES
+ 
++EXTRA_SOURCES = memento.c memento.h
++
+ MAINTAINERCLEANFILES = config_types.h.in
+ 
+ TESTS = test_sha1 test_jbig2dec.py test_huffman test_arith
diff -Nru jbig2dec-0.13/debian/patches/series jbig2dec-0.13/debian/patches/series
--- jbig2dec-0.13/debian/patches/series	2016-05-10 15:13:31.0 +0300
+++ jbig2dec-0.13/debian/patches/series	2016-05-16 17:55:49.0 +0300
@@ -1,2 +1,3 @@
 1001_ignore_python_test.patch
 1004_extract_infile_from_autogen-sh.patch
+2001_disable_memento.patch

Bug#799916: libjbig2dec0 is not Multi-Arch compatible

[Yuriy M. Kaminskiy]

Control: tags -1 patch
thanks

Patch (against 0.13-1) attached.
diff -Nru jbig2dec-0.13/debian/control jbig2dec-0.13/debian/control
--- jbig2dec-0.13/debian/control2016-05-10 17:52:21.0 +0300
+++ jbig2dec-0.13/debian/control2016-05-16 18:05:53.0 +0300
@@ -24,6 +24,7 @@
 Provides: libjbig2dec-dev
 Conflicts: libjbig2dec-dev
 Architecture: any
+Multi-arch: same
 Description: JBIG2 decoder library - development files
  jbig2dec is a decoder library and example utility implementing the JBIG2
  bi-level image compression spec. Also known as ITU T.88 and ISO IEC
@@ -36,6 +37,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Architecture: any
+Multi-arch: same
 Description: JBIG2 decoder library - shared libraries
  jbig2dec is a decoder library and example utility implementing the JBIG2
  bi-level image compression spec. Also known as ITU T.88 and ISO IEC
@@ -47,6 +49,7 @@
 Section: graphics
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Architecture: any
+Multi-arch: foreign
 Description: JBIG2 decoder library - tools
  jbig2dec is a decoder library and example utility implementing the JBIG2
  bi-level image compression spec. Also known as ITU T.88 and ISO IEC
diff -Nru jbig2dec-0.13/debian/control.in jbig2dec-0.13/debian/control.in
--- jbig2dec-0.13/debian/control.in 2016-05-10 14:06:28.0 +0300
+++ jbig2dec-0.13/debian/control.in 2016-05-16 18:06:19.0 +0300
@@ -15,6 +15,7 @@
 Provides: libjbig2dec-dev
 Conflicts: libjbig2dec-dev
 Architecture: any
+Multi-arch: same
 Description: JBIG2 decoder library - development files
  jbig2dec is a decoder library and example utility implementing the JBIG2
  bi-level image compression spec. Also known as ITU T.88 and ISO IEC
@@ -27,6 +28,7 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Architecture: any
+Multi-arch: same
 Description: JBIG2 decoder library - shared libraries
  jbig2dec is a decoder library and example utility implementing the JBIG2
  bi-level image compression spec. Also known as ITU T.88 and ISO IEC
@@ -38,6 +40,7 @@
 Section: graphics
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Architecture: any
+Multi-arch: foreign
 Description: JBIG2 decoder library - tools
  jbig2dec is a decoder library and example utility implementing the JBIG2
  bi-level image compression spec. Also known as ITU T.88 and ISO IEC

Bug#824160: p7zip: CVE-2016-2334 CVE-2016-2335

[Yuriy M. Kaminskiy]

> Can you check it actually affects [...]

According to http://www.talosintel.com/reports/* (as linked from 
tracker), CVE-2016-2334  affects HFS+ parser and CVE-2016-2335 UDF parser.
Both are *not* part of platform specific code and thus should be part of 
p7zip.
According to upstream changelog, both UDF and HFS+ parsers was added 
before version 9.20.1 (in jessie and wheezy).

Bug#822998: squid3: warning: package could avoid a useless dependency [...]

[Yuriy M. Kaminskiy]

Source: squid3
Version: 3.5.17-1
Severity: minor
Tags: patch

Dear Maintainer,

While rebuilding squid package, I noticed some warnings:

...
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/squidclient/usr/bin/squidclient was not linked against
libnettle.so.* (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/squidclient/usr/bin/squidclient was not linked against
libnetfilter_conntrack.so.* (it uses none of the library's symbols)
...
dpkg-shlibdeps: warning: package could avoid a useless dependency if
debian/squid-cgi/usr/lib/cgi-bin/cachemgr.cgi was not linked against
libnetfilter_conntrack.so.* (it uses none of the library's symbols)
...

Attached patch fixes them (however, obviously, overall positive effect
is very minor; squid{client,-cgi} are likely only installed together
with main squid package, and its dependencies remains mostly unchanged).

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

diff -Nru squid3-3.5.17/debian/rules squid3-3.5.17/debian/rules
--- squid3-3.5.17/debian/rules	2016-04-03 20:57:40.0 +0300
+++ squid3-3.5.17/debian/rules	2016-04-15 21:47:32.0 +0300
@@ -2,6 +2,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = -Wall
+export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 include /usr/share/dpkg/buildflags.mk
 
 include /usr/share/cdbs/1/rules/debhelper.mk

Bug#822992: squid3: please avoid installing pinger with suid-root when possible

[Yuriy M. Kaminskiy]

Package: squid3
Version: 3.5.16-1
Severity: normal
Tags: patch

Dear Maintainer,

Since squid 3.5.16, squid properly handles when pinger helper is 
installed with raised capabilities instead of setuid-root. Please avoid 
installing pinger as suid root when possible, patch attached.


diff -Nru squid3-3.5.16/debian/control squid3-3.5.16/debian/control
--- squid3-3.5.16/debian/control	2016-04-03 20:57:40.0 +0300
+++ squid3-3.5.16/debian/control	2016-04-13 23:02:24.0 +0300
@@ -23,6 +23,7 @@
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, netbase, adduser, logrotate (>= 3.5.4-1), squid-common (= ${source:Version}), lsb-base, libdbi-perl
 Suggests: squidclient, squid-cgi, squid-purge, resolvconf (>= 0.40), smbclient, ufw, winbindd
+Recommends: libcap2-bin [linux-any]
 Conflicts: squid3 (<< ${binary:Version})
 Replaces: squid3
 Description: Full featured Web Proxy cache (HTTP proxy)
diff -Nru squid3-3.5.16/debian/rules squid3-3.5.16/debian/rules
--- squid3-3.5.16/debian/rules	2016-04-03 20:57:40.0 +0300
+++ squid3-3.5.16/debian/rules	2016-04-15 21:47:32.0 +0300
@@ -62,8 +62,6 @@
 
 DEB_MAKE_CLEAN_TARGET = distclean
 
-DEB_FIXPERMS_EXCLUDE = /usr/lib/squid/pinger
-
 install/squid::
 	install -m 755 -g root -d $(INSTALLDIR)/usr/lib/cgi-bin
 	mv $(INSTALLDIR)/etc/squid/squid.conf.documented $(INSTALLDIR)/etc/squid/squid.conf
@@ -85,7 +84,6 @@
 	install -m 755 -g root -d $(INSTALLDIR)/usr/share/man/man1
 	mv $(INSTALLDIR)/usr/bin/purge $(INSTALLDIR)/usr/bin/squid-purge
 	install -m 644 -g root debian/squid-purge.8  $(INSTALLDIR)/usr/share/man/man8
-	chmod 4755 $(INSTALLDIR)/usr/lib/squid/pinger
 
 clean::
 	# nothing to do
diff -Nru squid3-3.5.16/debian/squid.postinst squid3-3.5.16/debian/squid.postinst
--- squid3-3.5.16/debian/squid.postinst	2016-04-03 20:57:40.0 +0300
+++ squid3-3.5.16/debian/squid.postinst	2016-04-13 23:13:13.0 +0300
@@ -73,6 +73,22 @@
 		  		chown -R $usr:$grp $log_dir
 			fi
 		fi
+		
+		# If we have setcap is installed, try setting cap_net_raw+ep,
+		# which allows us to install our binaries without the setuid
+		# bit.
+		PINGER=/usr/lib/squid/pinger
+		if command -v setcap > /dev/null; then
+			if setcap cap_net_raw+ep $PINGER; then
+echo "Setcap worked! $PINGER is not suid!"
+			else
+echo "Setcap failed on $PINGER, falling back to setuid" >&2
+chmod u+s $PINGER
+			fi
+		else
+			echo "Setcap is not installed, falling back to setuid" >&2
+			chmod u+s $PINGER
+		fi
 		;;
 	abort-upgrade|abort-remove|abort-deconfigure)
 		;;

Bug#822740: ceph: please use Multi-Arch for libraries

[Yuriy M. Kaminskiy]

Package: librados2
Version: 0.80.7-2+deb8u1
Severity: normal
Tags: patch

Dear Maintainer,

Please enable multi-arch for libraries (they are already installed in 
multi-arch locations, but not marked as multi-arch same).
Patch attached (only shared libraries and respective dbg[*] packages are 
changed; I have not investigated if dev/jni/python packages can be 
multiarched).

[*] all dbg are multi-arch friendly since debhelper/compat 9

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages librados2 depends on:
ii  libboost-system1.55.0  1.55.0+dfsg-3
ii  libboost-thread1.55.0  1.55.0+dfsg-3
ii  libc6  2.19-18+deb8u4
ii  libgcc11:4.9.2-10
ii  libnspr4   2:4.10.7-1+deb8u1
ii  libnss32:3.19.2.4-1~bpo8+1~local1
ii  libstdc++6 4.9.2-10
ii  libuuid1   2.25.2-6
ii  multiarch-support  2.19-18+deb8u4

librados2 recommends no packages.

librados2 suggests no packages.

-- no debconf information

diff -Nru ceph-0.80.11/debian/control ceph-0.80.11/debian/control
--- ceph-0.80.11/debian/control	2016-01-18 00:50:43.0 +0300
+++ ceph-0.80.11/debian/control	2016-04-27 03:00:45.0 +0300
@@ -235,6 +235,7 @@
 
 Package: librados2
 Architecture: linux-any
+Multi-Arch: same
 Section: libs
 Conflicts: libcrush, libcrush1, librados, librados1
 Replaces: libcrush, libcrush1, librados, librados1
@@ -248,6 +249,7 @@
 
 Package: librados2-dbg
 Architecture: linux-any
+Multi-Arch: same
 Section: debug
 Priority: extra
 Conflicts: libcrush1-dbg, librados1-dbg
@@ -278,6 +280,7 @@
 
 Package: librbd1
 Architecture: linux-any
+Multi-Arch: same
 Section: libs
 Depends: librados2 (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -289,6 +292,7 @@
 
 Package: librbd1-dbg
 Architecture: linux-any
+Multi-Arch: same
 Section: debug
 Priority: extra
 Depends: librbd1 (= ${binary:Version}), ${misc:Depends}
@@ -317,6 +321,7 @@
 
 Package: libcephfs1
 Architecture: linux-any
+Multi-Arch: same
 Section: libs
 Conflicts: libceph, libceph1, libcephfs
 Replaces: libceph, libceph1, libcephfs
@@ -330,6 +335,7 @@
 
 Package: libcephfs1-dbg
 Architecture: linux-any
+Multi-Arch: same
 Section: debug
 Priority: extra
 Depends: libcephfs1 (= ${binary:Version}), ${misc:Depends}

Bug#650458: rsvg-convert: Error parsing option -b

[Yuriy M. Kaminskiy]

This seems was fixed somewhere between wheezy (2.36, only checked 
sources, likely broken) and jessie (2.40.5, tested, seems fixed):
as of jessie `rsvg-convert -b white` works as expected, and there are no 
traces of base-uri options in sources anymore (by NEWS, probably in 
2.39.0, when loading resources from the net was removed?).

Bug#378779: xmessage -default ignores -print

[Yuriy M. Kaminskiy]

Control: tags -1 patch
Control: found -1 x11-utils/7.7+2
thanks

Still present in jessie. Attached patch should fix it.
>From f4ef2e191e39c7a2de5902d761e4103dfa571074 Mon Sep 17 00:00:00 2001
From: "Yuriy M. Kaminskiy" <yum...@gmail.com>
Date: Wed, 20 Apr 2016 03:51:46 +0300
Subject: [PATCH] xmessage: -default ignores -print

Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378779
---
 xmessage.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/xmessage.c b/xmessage.c
index 6f31007..d7ff0f9 100644
--- a/xmessage.c
+++ b/xmessage.c
@@ -150,7 +150,11 @@ default_exit_action(Widget w, XEvent *event, String *params,
 Cardinal *num_params)
 {
 if (default_exitstatus >= 0)
+  {
+if (qres.default_button != NULL && qres.print_value)
+  puts(qres.default_button);
 	exit(default_exitstatus);
+  }
 }
 
 /* Convert tabs to spaces in *messagep,*lengthp, copying to a new block of
-- 
2.1.4

Bug#505893: x11-utils: xmessage ignores locale encoding

[Yuriy M. Kaminskiy]

Control: found -1 x11-utils/7.7+2
Control: tags -1 patch
thanks

For the record:
1) xmessage 1.0.4 was included in 7.7+1
2) ...however, as of jessie, xmessage seems still broken;
3) I've found workaround:

  python -c 'print u"aix\xf2".encode("utf-8")' | \
 xmessage -xrm '*international:true' -file -

(assuming LANG=en_US.UTF-8 or other utf-8 locale).

(No idea why/how it worked for James Cloos; I don't see any relevant 
change in upstream xmessage repo, and there are no patches or 
customizations in gentoo xmessage package either; maybe something sets 
this xresource system-wide? or some libxaw change affects this?).


Patch attached.
--- x11-utils-7.7+3/xmessage/app-defaults/Xmessage.orig	2013-07-09 19:03:18.0 +0400
+++ x11-utils-7.7+3/xmessage/app-defaults/Xmessage	2016-04-20 02:43:33.0 +0300
@@ -4,3 +4,4 @@
 *message.scrollHorizontal:	Never
 *Command.shapeStyle:		oval
 *Command.highlightThickness:	1
+*international: true

Bug#765828: x11-utils: xprop -spy leaks memory

[Yuriy M. Kaminskiy]

Control: tags -1 fixed-upstream
thanks

This bug should be fixed upstream by commits from
4f748e3d2b1368ec0590a413ba5f7addc5e3344f
to
fa732adbbf5e29f4bb230e9b7c0c91ccb4b5af7e
(not yet in any released version, AFAIK).

Bug#820947: Probable culprit (Re: smbclient: [regression] pulls the server package "samba" via samba-libs since 2:4.2.10+dfsg-0+deb8u1 (DSA 3548-1))

[Yuriy M. Kaminskiy]

Disclaimer: totally untested

I think this is fallout from commit

http://anonscm.debian.org/cgit/pkg-samba/samba.git/patch/?id=86c240fa29936a5fe0472c906dce487855c52d70

that was fixed by

http://anonscm.debian.org/cgit/pkg-samba/samba.git/patch/?id=e66461c503009af5e63cbb9b428

and

http://anonscm.debian.org/cgit/pkg-samba/samba.git/patch/?id=592a5befc91d2ba917061ad092d

in stretch/sid samba 4.3.* package

(compare [sorted] samba{,-libs}.install in sid 4.3 and jessie-security 
4.2 packages; if you have spare cpu cycles for test, rebuild 4.2 with 
*process-model**.so* and *libsmbd-base.so* lines moved back from 
samba.install to samba-libs.install)

Bug#820565: nspr: bump minimum PR_*printf version in .symbols to 4.10.9

[Yuriy M. Kaminskiy]

Source: nspr
Version: 2:4.10.9-1
Severity: wishlist
Tags: patch

Dear Maintainer,

In nspr 4.10.9 [1], PR_*printf (and, implictly, LogPrint) functions was
improved to support 'z' (size_t) format modifier. As program that was 
built with newer version may assume this feature is supported, and there 
are no way to distinguish incompatible uses, I think minimum version for 
those functions should be bumped to 2:4.10.9~. Patch attached.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1088790

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

--- debian/libnspr4.symbols.orig	2016-03-09 03:28:18.0 +0300
+++ debian/libnspr4.symbols	2016-04-10 00:16:22.0 +0300
@@ -237,7 +237,7 @@
  PR_LockFile@Base 1.8.0.10
  PR_LockOrderedLock@Base 1.8.0.10
  PR_LogFlush@Base 1.8.0.10
- PR_LogPrint@Base 1.8.0.10
+ PR_LogPrint@Base 2:4.10.9~ 1
  PR_MakeDir@Base 1.8.0.10
  PR_Malloc@Base 1.8.0.10
  PR_MemMap@Base 1.8.0.10
@@ -374,25 +374,25 @@
  PR_Yield@Base 1.8.0.10
  PR_cnvtf@Base 1.8.0.10
  PR_dtoa@Base 1.8.0.10
- PR_fprintf@Base 1.8.0.10
+ PR_fprintf@Base 2:4.10.9~ 1
  PR_htonl@Base 1.8.0.10
  PR_htonll@Base 1.8.0.10
  PR_htons@Base 1.8.0.10
  PR_ntohl@Base 1.8.0.10
  PR_ntohll@Base 1.8.0.10
  PR_ntohs@Base 1.8.0.10
- PR_smprintf@Base 1.8.0.10
- PR_smprintf_free@Base 1.8.0.10
- PR_snprintf@Base 1.8.0.10
- PR_sprintf_append@Base 1.8.0.10
+ PR_smprintf@Base 2:4.10.9~ 1
+ PR_smprintf_free@Base 2:4.10.9~ 1
+ PR_snprintf@Base 2:4.10.9~ 1
+ PR_sprintf_append@Base 2:4.10.9~ 1
  PR_sscanf@Base 1.8.0.10
  PR_strtod@Base 1.8.0.10
- PR_sxprintf@Base 1.8.0.10
- PR_vfprintf@Base 1.8.0.10
- PR_vsmprintf@Base 1.8.0.10
- PR_vsnprintf@Base 1.8.0.10
- PR_vsprintf_append@Base 1.8.0.10
- PR_vsxprintf@Base 1.8.0.10
+ PR_sxprintf@Base 2:4.10.9~ 1
+ PR_vfprintf@Base 2:4.10.9~ 1
+ PR_vsmprintf@Base 2:4.10.9~ 1
+ PR_vsnprintf@Base 2:4.10.9~ 1
+ PR_vsprintf_append@Base 2:4.10.9~ 1
+ PR_vsxprintf@Base 2:4.10.9~ 1
  PT_FPrintStats@Base 1.8.0.10
  SetExecutionEnvironment@Base 1.8.0.10
  (arch=ia64)_PR_ia64_AtomicAdd@Base 1.8.0.10

Bug#820206: imlib2: potentially exploitable integer overflows

[Yuriy M. Kaminskiy]

Source: imlib2
Version: 1.4.6-2+deb8u1
Severity: important
Tags: security jessie upstream fixed-upstream patch

Dear Maintainer,

imlib2 commit v1.4.6-19-g143f299 fixes potentially exploitable
integer overflow.

https://git.enlightenment.org/legacy/imlib2.git/commit/?id=143f299

Please apply this patch to jessie (it is already in 1.4.7 in stretch/sid).

-- System Information:
Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

>From 143f2993d7ccb73b26bb83abac6fa86f443981f9 Mon Sep 17 00:00:00 2001
From: Fabian Keil 
Date: Wed, 3 Dec 2014 15:00:48 +0100
Subject: [PATCH] Make IMAGE_DIMENSIONS_OK() more restrictive

Prevents invalid reads and unreasonably large memory allocations
with input/queue/id:000210,src:000114,op:int32,pos:3,val:be:+32,+cov:

==20321== Invalid read of size 1
==20321==at 0x1FCDB16: __imlib_ScaleAARGB (scale.c:1043)
==20321==by 0x1F9BF81: __imlib_RenderImage (rend.c:409)
==20321==by 0x1F0F82C: imlib_render_image_part_on_drawable_at_size (api.c:1886)
==20321==by 0x40CD75: gib_imlib_render_image_part_on_drawable_at_size (gib_imlib.c:231)
==20321==by 0x42C732: winwidget_render_image (winwidget.c:576)
==20321==by 0x417ACA: feh_event_handle_keypress (keyevents.c:598)
==20321==by 0x4190DE: feh_main_iteration (main.c:119)
==20321==by 0x418F45: main (main.c:82)
==20321==  Address 0x3a12e034 is 12 bytes before a block of size 1,965,846,976 alloc'd
==20321==at 0x103D293: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==20321==by 0x5B3D1F1: load (loader_pnm.c:149)
==20321==by 0x1F7D70F: __imlib_LoadImage (image.c:1041)
==20321==by 0x1F090E4: imlib_load_image_with_error_return (api.c:1299)
==20321==by 0x40F47B: feh_load_image (imlib.c:252)
==20321==by 0x42CA0E: winwidget_loadimage (winwidget.c:753)
==20321==by 0x42C918: winwidget_create_from_file (winwidget.c:126)
==20321==by 0x421869: init_slideshow_mode (slideshow.c:62)
==20321==by 0x418F13: main (main.c:78)
---
 src/lib/image.h | 7 +--
 src/lib/rend.c  | 4 
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/src/lib/image.h b/src/lib/image.h
index da82576..0175e94 100644
--- a/src/lib/image.h
+++ b/src/lib/image.h
@@ -184,8 +184,11 @@ __hidden void  __imlib_SaveImage(ImlibImage *im, const char *file,
 #define SET_FLAG(flags, f) ((flags) |= (f))
 #define UNSET_FLAG(flags, f) ((flags) &= (~f))
 
+/* The maximum pixmap dimension is 65535. */
+/* However, for now, use 46340 (46340^2 < 2^31) to avoid buffer overflow issues. */
+# define X_MAX_DIM 46340
+
 #define IMAGE_DIMENSIONS_OK(w, h) \
-   ( ((w) > 0) && ((h) > 0) && \
- ((unsigned long long)(w) * (unsigned long long)(h) <= (1ULL << 29) - 1) )
+   ( ((w) > 0) && ((h) > 0) && ((w) < X_MAX_DIM) && ((h) < X_MAX_DIM) )
 
 #endif
diff --git a/src/lib/rend.c b/src/lib/rend.c
index 2d7934b..44be783 100644
--- a/src/lib/rend.c
+++ b/src/lib/rend.c
@@ -16,10 +16,6 @@
 #include "scale.h"
 #include "ximage.h"
 
-/* The maximum pixmap dimension is 65535. */
-/* However, for now, use 46340 (46340^2 < 2^31) to avoid buffer overflow issues. */
-#define X_MAX_DIM 46340
-
 /* size of the lines per segment we scale / render at a time */
 #define LINESIZE 16
 
-- 
2.1.4

Bug#814768: libsqlite3-0: Wrong handle of relative symbolic links

[Yuriy M. Kaminskiy]

As sqlite needs to create -journal or -wal/-shm files in same directory 
as database, if you symlink, hardlink, (and any possible variation, like 
mount --bind, overlayfs, fuse, network mounts, 9p, etc) database to 
different names, and attempt to access them at once, things will break. 
In a hard way.

This is *documented* to *not* work.
See /usr/share/doc/sqlite3-doc/howtocorrupt.html, "Multiple links to the 
same file".
In the best case, sqlite will warn you and won't work. But more often 
you should expect silent database corruption.

Disclaimer: not a maintainer.

Bug#819818: libimlib2: off-by-one OOB read in __imlib_MergeUpdate

[Yuriy M. Kaminskiy]

Package: libimlib2
Version: 1.4.6-2+deb8u1
Severity: normal
Tags: upstream patch

Dear Maintainer,

1) I re-compiled imlib2 package with debug information,
2) compiled and installed tests (data, src/bin),
3) run `valgrind imlib2_test`,
4) moved mouse to right lower corner of window;

==16086== Invalid read of size 1
==16086==at 0x4E79C4E: __imlib_MergeUpdate (in 
/usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6)

==16086==by 0x401773: main (in /usr/bin/imlib2_test)
==16086==  Address 0x9d20360 is 0 bytes after a block of size 1,200
alloc'd
==16086==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==16086==by 0x4E798E3: __imlib_MergeUpdate (in 
/usr/lib/x86_64-linux-gnu/libImlib2.so.1.4.6)

==16086==by 0x401773: main (in /usr/bin/imlib2_test)

In gdb, it points to src/lib/updates.c:

   | for (xx = x + 1, ww = 1; |
  >|  (T(xx, y).used & T_USED) && (xx < tw); xx++,|
   | for (yy = y + 1, hh = 1, ok = 1; |

xx is 20 and tw is 20, so T(xx, y) addresses one byte out of buffer.

Pretty obvious, off-by-one error due to swapped condition order.
In unlucky case, this can result in application crash.
Security implications: very minor, DoS at most, only for application 
drawing images using coordinates from untrusted source ("drawing images 
from untrusted sources" by itself is safe).

Two *alternative* patches attached (apply only *one* of them).
TODO: I have not tried to search for similar pattern over codebase yet.

Note: there are no changes affecting this code in 1.4.7 (sid) or 1.4.8 
(upstream).


-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libimlib2:amd64 depends on:
ii  libbz2-1.0 1.0.6-7+b3
ii  libc6  2.19-18+deb8u4
ii  libfreetype6   2.5.2-3+deb8u1
ii  libgif44.1.6-11+deb8u1
ii  libid3tag0 0.15.1b-11.1~local1
ii  libjpeg62-turbo1:1.3.1-12
ii  libpng12-0 1.2.50-2+deb8u2
ii  libtiff5   4.0.3-12.3+deb8u1
ii  libx11-6   2:1.6.2-3
ii  libxext6   2:1.3.3-1
ii  multiarch-support  2.19-18+deb8u4
ii  zlib1g 1:1.2.8.dfsg-2+b1

libimlib2:amd64 recommends no packages.

libimlib2:amd64 suggests no packages.

-- no debconf information

Description: off-by-one out-of-bound read due to reversed condtion
Author: Yuriy M. Kaminksiy 

Note: you need *either* off-by-one-alternative.patch, *or* this patch;
DO NOT APPLY BOTH! (it won't break, but would unnecessarily clutter code)

Index: imlib2-1.4.6/src/lib/updates.c
===
--- imlib2-1.4.6.orig/src/lib/updates.c
+++ imlib2-1.4.6/src/lib/updates.c
@@ -111,7 +111,7 @@ __imlib_MergeUpdate(ImlibUpdate * u, int
   int xx, yy, ww, hh, ok;
 
   for (xx = x + 1, ww = 1;
-   (T(xx, y).used & T_USED) && (xx < tw); xx++, ww++);
+   (xx < tw) && (T(xx, y).used & T_USED); xx++, ww++);
   for (yy = y + 1, hh = 1, ok = 1;
(yy < th) && (ok); yy++, hh++)
 {

Description: off-by-one out-of-bound read due to reversed condtion, alternative solution (allocates one more guard cell).
Author: Yuriy M. Kaminksiy 

Note: you need *either* off-by-one-reversed-condition.patch, *or* this patch;
DO NOT APPLY BOTH! (it won't break, but would unnecessarily clutter code)

Index: imlib2-1.4.6/src/lib/updates.c
===
--- imlib2-1.4.6.orig/src/lib/updates.c
+++ imlib2-1.4.6/src/lib/updates.c
@@ -34,13 +34,14 @@ __imlib_MergeUpdate(ImlibUpdate * u, int
th = h >> TB;
if (h & TM)
   th++;
-   t = malloc(tw * th * sizeof(struct _tile));
+   t = malloc((tw * th + 1) * sizeof(struct _tile));
/* fill in tiles to be all not used */
for (i = 0, y = 0; y < th; y++)
  {
 for (x = 0; x < tw; x++)
t[i++].used = T_UNUSED;
  }
+   t[i].used = T_UNUSED; /* guard OOB */
/* fill in all tiles */
for (uu = u; uu; uu = uu->next)
  {

Bug#799959: /usr/bin/transmission-daemon: segfaults shortly after hibernate/resume

[Yuriy M. Kaminskiy]

My 5 cents after quick look at backtrace and transmission sources:
It could be totally wrong (if you still have core file around, please 
show results from

  info reg all
  disas $pc-40,$pc+40
  up 2
  p *server
in gdb), but my current pet theory:
0) There are clearly nonsense in iovec; this could be 
debugging/optimizing artefact, but let's suppose it is true; how this 
could've happen?
1) For whatever reason^2, there are 165 threads running (most for curl 
asynchronous DNS lookups ^1), with default stack size 8M, it is 1.3G of 
address space for thread stacks alone;
2) This is 32-bit process, so it could've run out of address space as a 
result (note that most pages in those stacks are never touched, so 
actual memory usage/RSS is much lower);
3) evbuffer_reserve_space() could've returned error, and left junk in 
iovec; transmission ignores all errors, tries to memcpy into junk, and 
segfaults.
There are one fact that does NOT fit with this theory: it should've 
called deflate() with same nonsense, why it has not triggered SIGSEGV?


Either way, you can try limiting default stack size for transmission, 
something like:

   ulimit -s 512
in /etc/init/transmission script or
   [Service]
   LimitSTACK=524288
in systemd's /etc/systemd/system/transmission.service.d/limits.conf

^1 on a side note, it is really pity curl-with-cares is still too 
problematic to be used in distro builds; threaded asynchronous dns 
lookup can be really wasteful in some cases;


^2 probably, this was triggered by suspend/resume: after resume all 
scrape/announce timers fired at once?

Bug#819693: iptables-persistent: [systemd] netfilter is loaded concurrently with ifupdown

[Yuriy M. Kaminskiy]

Source: iptables-persistent
Version: 1.0.3+deb8u1
Severity: normal

Dear Maintainer,

I noticed that netfilter-persistent is started concurrently with
bringing interface up; as my ifupdown pre/post-up scripts
referenced/tuned chains that was created by netfilter-persistent,
they was (partially!) broken.

=== https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
* network.target has very little meaning during start-up.
...
  It's primary purpose is for ordering things properly at shutdown:
  since the shutdown ordering of units in systemd is the reverse of the
  startup ordering, any unit that is ordered After=network.target can be
  sure that it is stopped before the network is shut down if the system
  is powered off.
* network-pre.target is a target that may be used to order
  services before any network interface is configured. It's primary
  purpose is for usage with firewall services that want to establish
  a firewall before any network interface is up.
...
  Services that want to be run before the network is configured should
  place Before=network-pre.target and also set Wants=network-pre.target
  to pull it in.
=== cut ===
So, netfilter-persistent.service should be ordered *Before*
network-pre.target (instead of network.target), and should also *Wants*
it.
Attached patch (against git master) fixes this.
Note: I verified that ifupdown's networking.service (both generated in
jessie and shipped in sid) has proper dependency around
network-pre.target.

P.S. Not sure if it really required, but usually, services with
DefaultDependencies=no has Conflicts= and Before=shutdown.target (not 
included in patch).


-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- debconf information:
* iptables-persistent/autosave_v6: true
* iptables-persistent/autosave_v4: true

>From 82dc31e1af9e9eede0959e8ce02e5335482031d2 Mon Sep 17 00:00:00 2001
From: "Yuriy M. Kaminskiy" <yum...@gmail.com>
Date: Tue, 29 Mar 2016 07:41:14 +0300
Subject: [PATCH] Fix systemd service dependency

As a "firewall service", it should be ordered Before network-pre.target

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
---
 systemd/netfilter-persistent.service | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/systemd/netfilter-persistent.service b/systemd/netfilter-persistent.service
index bcbdedc..dc48484 100644
--- a/systemd/netfilter-persistent.service
+++ b/systemd/netfilter-persistent.service
@@ -1,8 +1,8 @@
 [Unit]
 Description=netfilter persistent configuration
 DefaultDependencies=no
-Before=network.target
-Wants=systemd-modules-load.service local-fs.target
+Before=network-pre.target
+Wants=systemd-modules-load.service local-fs.target network-pre.target
 After=systemd-modules-load.service local-fs.target
 
 [Service]
-- 
2.1.4

Bug#639414: libimlib2: divide-by-zero on 2x1 ellipse

[Yuriy M. Kaminskiy]

control tags -1 patch upstream security
thanks

I tested against current jessie/sid versions, they are still affected.
Attached patch plugs SIGFPE, but probably produces incorrect images.
I'd like to note that this bug has minor security implications (DoS for 
applications that issue draw command based on untrusted input).


Description: fix divide-by-zero on drawing 2x1 ellipse
Author: Yuriy M. Kaminskiy <yumkam+deb...@gmail.com>
Note: resulting images are probably incorrect; but SIGFPE is certainly worse.

Index: imlib2-1.4.6/src/lib/ellipse.c
===
--- imlib2-1.4.6.orig/src/lib/ellipse.c
+++ imlib2-1.4.6/src/lib/ellipse.c
@@ -54,6 +54,7 @@ __imlib_Ellipse_DrawToData(int xc, int y
   {
  prev_y = y;
  dx -= a2;
+ if (dx == 0) break; /* FIXME likely incorrect */
  ty++;
  by--;
  tp += dstw;
@@ -95,6 +96,9 @@ __imlib_Ellipse_DrawToData(int xc, int y
tp += dstw;
bp -= dstw;
 
+   if (dy == 0) /* FIXME likely incorrect */
+  return;
+
while (ty < yc)
  {
 int len;
@@ -185,6 +189,7 @@ __imlib_Ellipse_DrawToData_AA(int xc, in
   {
  prev_y = y;
  dx -= a2;
+ if (dx == 0) break; /* FIXME likely incorrect */
  ty++;
  by--;
  tp += dstw;
@@ -247,6 +252,9 @@ __imlib_Ellipse_DrawToData_AA(int xc, in
tp += dstw;
bp -= dstw;
 
+   if (dy == 0) /* FIXME likely incorrect */
+  return;
+
while (ty < yc)
  {
 int len;
@@ -360,6 +368,7 @@ __imlib_Ellipse_FillToData(int xc, int y
   {
  prev_y = y;
  dx -= a2;
+ if (dx == 0) break; /* FIXME likely incorrect */
  ty++;
  by--;
  tp += dstw;
@@ -417,6 +426,9 @@ __imlib_Ellipse_FillToData(int xc, int y
tp += dstw;
bp -= dstw;
 
+   if (dy == 0) /* FIXME likely incorrect */
+  return;
+
while (ty < yc)
  {
 int len;
@@ -517,6 +529,7 @@ __imlib_Ellipse_FillToData_AA(int xc, in
   {
  prev_y = y;
  dx -= a2;
+ if (dx == 0) break; /* FIXME likely incorrect */
  ty++;
  by--;
  tp += dstw;
@@ -579,6 +592,9 @@ __imlib_Ellipse_FillToData_AA(int xc, in
tp += dstw;
bp -= dstw;
 
+   if (dy == 0) /* FIXME likely incorrect */
+  return;
+
while (ty < yc)
  {
 int len;

Bug#785369: [SECURITY] libimlib2: GIF loader: out-of-bounds read

[Yuriy M. Kaminskiy]

control tags -1 security patch upstream
severity -1 important
thanks

Ping.
I'd like to stress out this bug has security implications (DoS and 
potential host memory exposure).

Debdiffs against jessie and sid versions attached.
diff -Nru imlib2-1.4.6/debian/changelog imlib2-1.4.6/debian/changelog
--- imlib2-1.4.6/debian/changelog   2016-03-29 19:55:12.0 +0300
+++ imlib2-1.4.6/debian/changelog   2016-03-31 18:30:21.0 +0300
@@ -1,3 +1,12 @@
+imlib2 (1.4.6-2+deb8u1.1) UNRELEASED; urgency=high
+
+  * Non-maintainer upload.
+  * Drop 02_fix-gif-with-no-cmap.patch (redundant with CVE-2014-9762.patch).
+  * Fix out-of-bound read from colormap. (Closes: #785369)
+  * Drop now-redundant CVE-2014-9762.patch.
+
+ -- Yuriy M. Kaminskiy <yumkam+deb...@gmail.com>  Thu, 31 Mar 2016 17:53:34 
+0300
+
 imlib2 (1.4.6-2+deb8u1) jessie-security; urgency=high
 
   * Non-maintainer upload.
diff -Nru imlib2-1.4.6/debian/patches/02_fix-gif-with-no-cmap.patch 
imlib2-1.4.6/debian/patches/02_fix-gif-with-no-cmap.patch
--- imlib2-1.4.6/debian/patches/02_fix-gif-with-no-cmap.patch   2016-03-29 
19:55:12.0 +0300
+++ imlib2-1.4.6/debian/patches/02_fix-gif-with-no-cmap.patch   1970-01-01 
03:00:00.0 +0300
@@ -1,32 +0,0 @@
-Description: Do not segfault when loading gif without color map
-Origin: vendor
-Bug-Debian: http://bugs.debian.org/697143
-Forwarded: no
-Author: Samuel Thibault <sthiba...@debian.org>
-Reviewed-by: Alessandro Ghedini <gh...@debian.org>
-Last-Update: 2013-10-06
-
 a/src/modules/loaders/loader_gif.c
-+++ b/src/modules/loaders/loader_gif.c
-@@ -162,10 +162,17 @@
-{
-   if (rows[i][j] == transp)
- {
--   r = cmap->Colors[bg].Red;
--   g = cmap->Colors[bg].Green;
--   b = cmap->Colors[bg].Blue;
--   *ptr++ = 0x00ff & ((r << 16) | (g << 8) | b);
-+   if (cmap)
-+ {
-+r = cmap->Colors[bg].Red;
-+g = cmap->Colors[bg].Green;
-+b = cmap->Colors[bg].Blue;
-+*ptr++ = 0x00ff & ((r << 16) | (g << 8) | b);
-+ }
-+   else
-+ {
-+*ptr++ = 0;
-+ }
- }
-   else
- {
diff -Nru imlib2-1.4.6/debian/patches/CVE-2014-9762.patch 
imlib2-1.4.6/debian/patches/CVE-2014-9762.patch
--- imlib2-1.4.6/debian/patches/CVE-2014-9762.patch 2016-03-29 
19:55:12.0 +0300
+++ imlib2-1.4.6/debian/patches/CVE-2014-9762.patch 1970-01-01 
03:00:00.0 +0300
@@ -1,35 +0,0 @@
-From: Markus Koschany <a...@debian.org>
-Date: Mon, 21 Mar 2016 22:40:04 +0100
-Subject: CVE-2014-9762
-
-Fix segmentation fault on images without colormap.
-
-Origin: 
https://git.enlightenment.org/legacy/imlib2.git/commit/?h=v1.4.7=39641e74a560982fbf93f29bf96b37d27803cb56

- src/modules/loaders/loader_gif.c | 13 +
- 1 file changed, 13 insertions(+)
-
-diff --git a/src/modules/loaders/loader_gif.c 
b/src/modules/loaders/loader_gif.c
-index 45ff0b9..ff78d22 100644
 a/src/modules/loaders/loader_gif.c
-+++ b/src/modules/loaders/loader_gif.c
-@@ -154,6 +154,19 @@ load(ImlibImage * im, ImlibProgressFunction progress, 
char progress_granularity,
-  free(rows);
-  return 0;
-   }
-+if (!cmap)
-+  {
-+ /* No colormap? Now what?? Let's clear the image (and not segv) 
*/
-+ memset(im->data, 0, sizeof(DATA32) * w * h);
-+ DGifCloseFile(gif);
-+ for (i = 0; i < h; i++)
-+   {
-+  free(rows[i]);
-+   }
-+   free(rows);
-+   return 1;
-+  }
-+
- ptr = im->data;
- per_inc = 100.0 / (((float)w) * h);
- for (i = 0; i < h; i++)
diff -Nru imlib2-1.4.6/debian/patches/fix-bug-785369.patch 
imlib2-1.4.6/debian/patches/fix-bug-785369.patch
--- imlib2-1.4.6/debian/patches/fix-bug-785369.patch1970-01-01 
03:00:00.0 +0300
+++ imlib2-1.4.6/debian/patches/fix-bug-785369.patch2016-03-31 
18:28:58.0 +0300
@@ -0,0 +1,59 @@
+Description: Fixes out-of-bound reads from colormap
+Bug-Debian: http://bugs.debian.org/785369
+Note: removes all special-casing from the inner loop, optimize for common case.
+Author: Yuriy M. Kaminskiy <yumkam+deb...@gmail.com>
+Reported-By: Jakub Wilk <jw...@debian.org>
+
+Thanks to Bernhard U:belacker <bernha...@vr-web.de> for analysis.
+
+Index: imlib2-1.4.6/src/modules/loaders/loader_gif.c
+===
+--- imlib2-1.4.6.orig/src/modules/loaders/loader_gif.c
 imli

Bug#813879: systemd: Assertion 's->exec_command[SERVICE_EXEC_START]' failed service_enter_start()

[Yuriy M. Kaminskiy]

On 08.02.2016 18:18, Yuriy M. Kaminskiy wrote:

On 08.02.2016 02:15, Yuriy M. Kaminskiy wrote:

Package: systemd
Version: 215-17+deb8u3
Severity: important


Probably related:
cron-update.service is triggered by some /etc/cron* directories 
change and invokes `systemctl daemon-reload` and `systemctl 
try-restart cron.target`. Maybe there are some racing when it is 
triggered right when cron.target is being stopped?


Probably related upstream commit: 
96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1
(aka v216-30-g96fb824), however, it likely fixes symptoms [assert() 
and abort], but not underlying issue [racing or whatever].


I've looked at core file, after musing a bit upon sources, I don't 
think this commit will fix/hide issue.


Backtrace:

#6  0x7f08e081124f in service_enter_start (s=s@entry=0x7f08e21c7a10)
at ../src/core/service.c:1312
#7  0x7f08e0813341 in service_sigchld_event.lto_priv.377 
(u=0x7f08e21c7a10,

pid=, code=, status=0)
at ../src/core/service.c:2338
#8  0x7f08e084b887 in manager_dispatch_sigchld (m=0x7f08e20fc350)
at ../src/core/manager.c:1639

(gdb) p s->type
$14 = _SERVICE_TYPE_INVALID
(gdb) p s->state
$15 = SERVICE_START_PRE
(gdb)  p s->meta.load_state
$16 = UNIT_NOT_FOUND
(gdb) p s->exec_command
$18 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}

Problem is, we started executing unit, spawned StartPre command, then 
unit file was removed, systemctl daemon-reload was issued, unit 
structure become half-ghost, then we got SIGCHLD for that StartPre 
command from the already-removed unit. Oops.


With 96fb824 applied, end result would be same:

@@ -1332,6 +1345,12 @@ static void service_enter_start(Service *s) {
 c = s->main_command = 
s->exec_command[SERVICE_EXEC_START];

 }

+if (!c) {
+assert(s->type == SERVICE_ONESHOT);
+service_enter_start_post(s);
+return;
+}
+

c is NULL, s->type here is _SERVICE_TYPE_INVALID, so we'll die in 
assert anyway :-\


It is possible that upstream systemd version is still affected, you 
may want to try install jessie's systemd-cron 1.3.* into sid and play 
with install/removal in a loop.
Completely untested patches for systemd master and backport to v215 is 
attached.


FWIW, patch from previous message is runtime-tested in very minimal 
qemu/kvm guest and works to some extent (i.e. prevent crash, leaves 
expected error message about sigchld-to-ghost-unit; but likely there are 
some issues remaining, as ghost of "cron-update.service" remain 
lingering around, even after apt-get purge systemd-cron and systemctl 
daemon-re{load,exec}; but at least, it does not crash systemd anymore).

Bug#819290: Stack trace with symbols

[Yuriy M. Kaminskiy]

On 27.03.2016 05:01, Yuriy M. Kaminskiy wrote:

On 27.03.2016 03:36, Kingsley G. Morse Jr. wrote:

Hi Yuriy,

OK, that all makes sense.

Here's the full trace with symbols:

#8  0x8017f167 in path_compare (a=, b=0x0) at 
../src/basic/path-util.c:390

 d = 
 __PRETTY_FUNCTION__ = "path_compare"


so, it assert() as `b == NULL`

#9  0x8017f308 in path_equal () at ../src/basic/path-util.c:433
No locals.
#10 0x8010c661 in device_setup_unit (m=m@entry=0x81f377f8, 
dev=dev@entry=0x0, path=path@entry=0x82005aa8 "/dev/sde1", 
main=false) at ../src/core/device.c:324

 e = 0x82006760 "dev-sde1.device"
 sysfs = 
 u = 0x8200bad0
 delete = 
 r = 
 __PRETTY_FUNCTION__ = "device_setup_unit"
 __func__ = "device_setup_unit"


and here argument `b` is sysfs, so sysfs was NULL;
and it is NULL as dev was NULL.

#11 0x8010fbf3 in device_found_node (m=m@entry=0x81f377f8, 
node=0x82005aa8 "/dev/sde1", add=add@entry=true, 
found=DEVICE_FOUND_MOUNT, now=true) at ../src/core/device.c:830

 dev = 0x0
 st = {st_dev = 53688455864, __pad1 = 0, __st_ino = 7, 
st_mode = 2149927392, st_nlink = 2149927392, st_uid = 2149927392, 
st_gid = 3219526928, st_rdev = 13827762142796840961,
   __pad2 = 5223, st_size = -5234089312160518424, st_blksize 
= -1218656384, st_blocks = -5234089864091353088, st_atim = {tv_sec = 
224449792, tv_nsec = -2113906008}, st_mtim = {
 tv_sec = -2113877109, tv_nsec = -2146119061}, st_ctim = 
{tv_sec = -2145039904, tv_nsec = -2113876944}, st_ino = 
13827762864351346689}

 __PRETTY_FUNCTION__ = "device_found_node"
 __func__ = "device_found_node"


and here dev could be NULL only if stat() returned error, and that 
error was ENOENT (see line 822).


Regression by commit v228-745-gac9d396. Before that commit, 
device_setup_unit checked that sysfs is not NULL before calling 
path_equals().

I'd guess this commit should be just reverted.


See also upstream commit 5e1558f4a09e596561c9168384f2258e7c0718a1

P.S. asserts, asserts, asserts everywhere. /me hates.

[...]



I hope that helps,
Kingsley

Bug#819290: Stack trace with symbols

[Yuriy M. Kaminskiy]

On 27.03.2016 03:36, Kingsley G. Morse Jr. wrote:

Hi Yuriy,

OK, that all makes sense.

Here's the full trace with symbols:

#8  0x8017f167 in path_compare (a=, b=0x0) at 
../src/basic/path-util.c:390
 d = 
 __PRETTY_FUNCTION__ = "path_compare"


so, it assert() as `b == NULL`

#9  0x8017f308 in path_equal () at ../src/basic/path-util.c:433
No locals.
#10 0x8010c661 in device_setup_unit (m=m@entry=0x81f377f8, dev=dev@entry=0x0, 
path=path@entry=0x82005aa8 "/dev/sde1", main=false) at ../src/core/device.c:324
 e = 0x82006760 "dev-sde1.device"
 sysfs = 
 u = 0x8200bad0
 delete = 
 r = 
 __PRETTY_FUNCTION__ = "device_setup_unit"
 __func__ = "device_setup_unit"


and here argument `b` is sysfs, so sysfs was NULL;
and it is NULL as dev was NULL.


#11 0x8010fbf3 in device_found_node (m=m@entry=0x81f377f8, node=0x82005aa8 
"/dev/sde1", add=add@entry=true, found=DEVICE_FOUND_MOUNT, now=true) at 
../src/core/device.c:830
 dev = 0x0
 st = {st_dev = 53688455864, __pad1 = 0, __st_ino = 7, st_mode = 
2149927392, st_nlink = 2149927392, st_uid = 2149927392, st_gid = 3219526928, 
st_rdev = 13827762142796840961,
   __pad2 = 5223, st_size = -5234089312160518424, st_blksize = 
-1218656384, st_blocks = -5234089864091353088, st_atim = {tv_sec = 224449792, 
tv_nsec = -2113906008}, st_mtim = {
 tv_sec = -2113877109, tv_nsec = -2146119061}, st_ctim = {tv_sec = 
-2145039904, tv_nsec = -2113876944}, st_ino = 13827762864351346689}
 __PRETTY_FUNCTION__ = "device_found_node"
 __func__ = "device_found_node"


and here dev could be NULL only if stat() returned error, and that error 
was ENOENT (see line 822).


Regression by commit v228-745-gac9d396. Before that commit, 
device_setup_unit checked that sysfs is not NULL before calling 
path_equals().

I'd guess this commit should be just reverted.


#12 0x8010fe6c in mount_load_proc_self_mountinfo.lto_priv.530 (m=0x81f377f8, 
set_flags=true) at ../src/core/mount.c:1537
 device = 0x8200ccc8 "/dev/sde1"
 k = 
 path = 0x8200cc30 "/media/usb1"
 options = 0x8200cd40 
"rw,nodev,noexec,noatime,nodiratime,sync,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro"
 fstype = 0x8200ccb8 "vfat"
 d = 0x82005aa8 "/dev/sde1"
 p = 0x8200eee8 "/media/usb1"
 fs = 0x8200cb98
 t = 0x81fe0e90
 i = 0x81fee988
 r = 0
 __PRETTY_FUNCTION__ = "mount_load_proc_self_mountinfo"
 __func__ = "mount_load_proc_self_mountinfo"
#13 0x8011776c in mount_dispatch_io (source=0x81f3f848, fd=9, revents=1, 
userdata=0x81f377f8) at ../src/core/mount.c:1669
 around = 0x0
 gone = 0x0
 m = 0x81f377f8
 what = 0xbfe615b0 ""
 i = {idx = 0, next_key = 0x8018481d }
 u = 
 r = 
 __PRETTY_FUNCTION__ = "mount_dispatch_io"
 __func__ = "mount_dispatch_io"
#14 0x8011f650 in source_dispatch.lto_priv.983 (s=0x81f3f848) at 
../src/libsystemd/sd-event/sd-event.c:2273
 r = 
 __PRETTY_FUNCTION__ = "source_dispatch"
 __func__ = "source_dispatch"
#15 0x801a83ac in sd_event_dispatch (e=0x81f37b20) at 
../src/libsystemd/sd-event/sd-event.c:2625
 p = 
 r = 
#16 sd_event_run (timeout=, e=0x81f37b20) at 
../src/libsystemd/sd-event/sd-event.c:2684
 r = 
#17 manager_loop (m=0x81f377f8) at ../src/core/manager.c:2051
 wait_usec = 
 r = 
 rl = {interval = 100, begin = 141532531177, burst = 5, num = 1}
 __PRETTY_FUNCTION__ = "manager_loop"
 __func__ = "manager_loop"
#18 0x800f7626 in main (argc=1, argv=0xbfe620c4) at ../src/core/main.c:1827
 m = 0x81f377f8
 r = 
 retval = 1
 before_startup = 
 after_startup = 
 timespan = 
"\000\000\000\000\002\216:V\000\000\000\000\000\320x\267R\231w\267\302x4\267\376\245v\267\000\320x\267\034\231w\267\000\320x\267\302x4\267<\325x\267$\031w\267\000}A\267xyA\267\001\000\000"
 fds = 0x0
 reexecute = false
 shutdown_verb = 0x0
 initrd_timestamp = 
 userspace_timestamp = {realtime = 1458797412056566, monotonic = 
67928234}
 kernel_timestamp = {realtime = , monotonic = 0}
 security_start_timestamp = {realtime = 1458797412107590, monotonic = 
67979258}
 security_finish_timestamp = {realtime = 1458797412125352, monotonic = 
67997020}
 systemd = "systemd"
 skip_setup = 
 j = 
 loaded_policy = false
 arm_reboot_watchdog = false
 queue_default_job = 
 empty_etc = 
 switch_root_dir = 0x0
 switch_root_init = 0x0
 saved_rlimit_nofile = {rlim_cur = 1024, rlim_max = 4096}
 error_message = 0x0
 __func__ = "main"
 __PRETTY_FUNCTION__ = "main"

I hope that helps,
Kingsley

Bug#819290: systemd[1]: Caught , dumped core ...

[Yuriy M. Kaminskiy]

Disclaimer: not a systemd maintainer.
> 2.) A.)
Unfortunately, backtrace without symbol information is not exactly 
useful, especially since introduction of ASLR. If you kept core, please 
install systemd-dbg/-dbgsym package and redo gdb backtrace.


> If I understand correctly Lennart might look into this when version 
4.5 of the kernel is out[1].


Unless you use systemd.unified_cgroup_hierarchy=1, this is *NOT* your 
issue (some symptoms maybe /looks/ similar, but effects in 2.B.,.C,.D,.E 
are exactly same in about /any/ systemd crash), and Lennart note about 
4.5 kernel does not apply to you.


P.S. I might note that the way systemd handles crashes is not quite 
suitable for any production system :-|
Considering complexity (and likelihood of bugs), it should do something 
less drastic.

Bug#818131: curl: broken as-needed workaround (warning: package could avoid a useless dependency)

[Yuriy M. Kaminskiy]

Source: curl
Version: 7.38.0-4+deb8u3
Severity: normal
Tags: patch

Dear Maintainer,

While rebuilding (jessie) curl package in pbuilder, I noticed some
warning: package could avoid a useless dependency [...]
(fragment of log attached).

curl package is built with -Wl,--as-needed linker flag, and contains 
libtool workaround[*], but it seems ineffective.


And, judging by presence of unnecessary dependencies from
libk5crypto3 libkrb5-3 libcomerr2 in jessie/stretch/sid binary packages,
it is not my local issue.

However, workaround apparently worked as expected in wheezy (no
extra dependencies).

Not sure if this is correct, but attached debdiff fixed this problem for me.

PS same workaround patch is used by dh-autoreconf; is it broken in curl
only (why?), or dh-autoreconf is also affected?

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

/bin/bash ../libtool  --tag=CC   --mode=link gcc   -g -O2 -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security -Wno-system-headers 
-pthread   -version-info 7:0:3   -Wl,--version-script=libcurl.vers -fPIE -pie 
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -lidn -lrtmp -lssh2 -lssl -lcrypto 
-lssl -lcrypto -L/usr/lib/i386-linux-gnu/mit-krb5 -Wl,-z,relro -lgssapi_krb5 
-lkrb5 -lk5crypto -lcom_err -llber -llber -lldap -lz -fPIE -pie -Wl,-z,relro 
-Wl,-z,now -Wl,--as-needed -o libcurl.la -rpath /usr/lib/i386-linux-gnu 
libcurl_la-file.lo libcurl_la-timeval.lo libcurl_la-base64.lo 
libcurl_la-hostip.lo libcurl_la-progress.lo libcurl_la-formdata.lo 
libcurl_la-cookie.lo libcurl_la-http.lo libcurl_la-sendf.lo libcurl_la-ftp.lo 
libcurl_la-url.lo libcurl_la-dict.lo libcurl_la-if2ip.lo 
libcurl_la-speedcheck.lo libcurl_la-ldap.lo libcurl_la-version.lo 
libcurl_la-getenv.lo libcurl_la-escape.lo libcurl_la-mprintf.lo 
libcurl_la-telnet.lo libcurl_la-netrc.lo libcurl_la-getinfo.lo 
libcurl_la-transfer.lo libcurl_la-strequal.lo libcurl_la-easy.lo 
libcurl_la-security.lo libcurl_la-curl_fnmatch.lo libcurl_la-fileinfo.lo 
libcurl_la-ftplistparser.lo libcurl_la-wildcard.lo libcurl_la-krb5.lo 
libcurl_la-memdebug.lo libcurl_la-http_chunks.lo libcurl_la-strtok.lo 
libcurl_la-connect.lo libcurl_la-llist.lo libcurl_la-hash.lo 
libcurl_la-multi.lo libcurl_la-content_encoding.lo libcurl_la-share.lo 
libcurl_la-http_digest.lo libcurl_la-md4.lo libcurl_la-md5.lo 
libcurl_la-http_negotiate.lo libcurl_la-inet_pton.lo libcurl_la-strtoofft.lo 
libcurl_la-strerror.lo libcurl_la-amigaos.lo libcurl_la-hostasyn.lo 
libcurl_la-hostip4.lo libcurl_la-hostip6.lo libcurl_la-hostsyn.lo 
libcurl_la-inet_ntop.lo libcurl_la-parsedate.lo libcurl_la-select.lo 
libcurl_la-tftp.lo libcurl_la-splay.lo libcurl_la-strdup.lo libcurl_la-socks.lo 
libcurl_la-ssh.lo libcurl_la-rawstr.lo libcurl_la-curl_addrinfo.lo 
libcurl_la-socks_gssapi.lo libcurl_la-socks_sspi.lo libcurl_la-curl_sspi.lo 
libcurl_la-slist.lo libcurl_la-nonblock.lo libcurl_la-curl_memrchr.lo 
libcurl_la-imap.lo libcurl_la-pop3.lo libcurl_la-smtp.lo libcurl_la-pingpong.lo 
libcurl_la-rtsp.lo libcurl_la-curl_threads.lo libcurl_la-warnless.lo 
libcurl_la-hmac.lo libcurl_la-curl_rtmp.lo libcurl_la-openldap.lo 
libcurl_la-curl_gethostname.lo libcurl_la-gopher.lo libcurl_la-idn_win32.lo 
libcurl_la-http_negotiate_sspi.lo libcurl_la-http_proxy.lo 
libcurl_la-non-ascii.lo libcurl_la-asyn-ares.lo libcurl_la-asyn-thread.lo 
libcurl_la-curl_gssapi.lo libcurl_la-curl_ntlm.lo libcurl_la-curl_ntlm_wb.lo 
libcurl_la-curl_ntlm_core.lo libcurl_la-curl_ntlm_msgs.lo 
libcurl_la-curl_sasl.lo libcurl_la-curl_multibyte.lo libcurl_la-hostcheck.lo 
libcurl_la-bundles.lo libcurl_la-conncache.lo libcurl_la-pipeline.lo 
libcurl_la-dotdot.lo libcurl_la-x509asn1.lo libcurl_la-http2.lo 
libcurl_la-curl_sasl_sspi.lo vtls/libcurl_la-openssl.lo vtls/libcurl_la-gtls.lo 
vtls/libcurl_la-vtls.lo vtls/libcurl_la-nss.lo vtls/libcurl_la-qssl.lo 
vtls/libcurl_la-polarssl.lo vtls/libcurl_la-polarssl_threadlock.lo 
vtls/libcurl_la-axtls.lo vtls/libcurl_la-cyassl.lo 
vtls/libcurl_la-curl_schannel.lo vtls/libcurl_la-curl_darwinssl.lo 
vtls/libcurl_la-gskit.lo
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libcurl_la-file.o 
.libs/libcurl_la-timeval.o .libs/libcurl_la-base64.o .libs/libcurl_la-hostip.o 
.libs/libcurl_la-progress.o .libs/libcurl_la-formdata.o 
.libs/libcurl_la-cookie.o .libs/libcurl_la-http.o .libs/libcurl_la-sendf.o 
.libs/libcurl_la-ftp.o .libs/libcurl_la-url.o .libs/libcurl_la-dict.o 
.libs/libcurl_la-if2ip.o .libs/libcurl_la-speedcheck.o .libs/libcurl_la-ldap.o 
.libs/libcurl_la-version.o .libs/libcurl_la-getenv.o .libs/libcurl_la-escape.o 
.libs/libcurl_la-mprintf.o 

Bug#721321: [libgnutls26] Breaks SSL tracker support in Transmission

[Yuriy M. Kaminskiy]

1) There are no ssl-specific code in transmission, it is dealt with in 
curl. So, if any, it is a *curl* bug that affects transmission;


2) curl bug was supposed to be fixed and reappeared several times, last 
reincarnation is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818126 
(affects jessie, supposed to be fixed in stretch/sid).

Bug#818126: libcurl3-gnutls: https connection is broken by (harmless) TLS Alert messages

[Yuriy M. Kaminskiy]

Package: libcurl3-gnutls
Version: 7.38.0-4+deb8u3
Severity: normal
Tags: upstream patch jessie

Dear Maintainer,

TLS Alert processing in curl gnutls backend is broken and return error
when server sends (non-fatal) TLS Alert message (e.g. due to
unrecognized SNI name).

You can test it with slightly modified doc/examples/https.c (I only
replaced www.example.com to random host taken from another bugreport 
that trigger this bug; attached).


$ gcc -o https https.c /usr/lib/*/libcurl-gnutls.so.3
$ ./https >/dev/null
curl_easy_perform() failed: SSL peer certificate or SSH remote key was 
not OK


This bug is already fixed upstream in commit
d5aab55b3353bec1d34a2e1434399d23db79b254 (between 7.42 and 7.43, so 
stretch/sid should be fine [but I have not tried to check]),
however jessie version is still broken. This commit can be cleanly 
cherry-picked to 7.38 and fixes the problem (verified).


-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libcurl3-gnutls depends on:
ii  libc6  2.19-18
ii  libcomerr2 1.42.12-1.1
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  libgssapi-krb5-2   1.12.1+dfsg-19
ii  libidn11   1.29-1+b2
ii  libk5crypto3   1.12.1+dfsg-19
ii  libkrb5-3  1.12.1+dfsg-19
ii  libldap-2.4-2  2.4.40+dfsg-1+deb8u1
ii  libnettle4 2.7.1-5
ii  librtmp1   2.4+20150115.gita107cef-1
ii  libssh2-1  1.4.3-4.1+deb8u1
ii  multiarch-support  2.19-18
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages libcurl3-gnutls recommends:
ii  ca-certificates  20141019+deb8u1

libcurl3-gnutls suggests no packages.

-- no debconf information

/***
 *  _   _   _
 *  Project ___| | | |  _ \| |
 * / __| | | | |_) | |
 *| (__| |_| |  _ <| |___
 * \___|\___/|_| \_\_|
 *
 * Copyright (C) 1998 - 2012, Daniel Stenberg, , et al.
 *
 * This software is licensed as described in the file COPYING, which
 * you should have received as part of this distribution. The terms
 * are also available at http://curl.haxx.se/docs/copyright.html.
 *
 * You may opt to use, copy, modify, merge, publish, distribute and/or sell
 * copies of the Software, and permit persons to whom the Software is
 * furnished to do so, under the terms of the COPYING file.
 *
 * This software is distributed on an "AS IS" basis, WITHOUT WARRANTY OF ANY
 * KIND, either express or implied.
 *
 ***/
#include 
#include 

int main(void)
{
  CURL *curl;
  CURLcode res;

  curl_global_init(CURL_GLOBAL_DEFAULT);

  curl = curl_easy_init();
  if(curl) {
curl_easy_setopt(curl, CURLOPT_URL, "https://stech.muecke.pw/;);

#ifdef SKIP_PEER_VERIFICATION
/*
 * If you want to connect to a site who isn't using a certificate that is
 * signed by one of the certs in the CA bundle you have, you can skip the
 * verification of the server's certificate. This makes the connection
 * A LOT LESS SECURE.
 *
 * If you have a CA cert for the server stored someplace else than in the
 * default bundle, then the CURLOPT_CAPATH option might come handy for
 * you.
 */
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0L);
#endif

#ifdef SKIP_HOSTNAME_VERIFICATION
/*
 * If the site you're connecting to uses a different host name that what
 * they have mentioned in their server certificate's commonName (or
 * subjectAltName) fields, libcurl will refuse to connect. You can skip
 * this check, but this will make the connection less secure.
 */
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0L);
#endif

/* Perform the request, res will get the return code */
res = curl_easy_perform(curl);
/* Check for errors */
if(res != CURLE_OK)
  fprintf(stderr, "curl_easy_perform() failed: %s\n",
  curl_easy_strerror(res));

/* always cleanup */
curl_easy_cleanup(curl);
  }

  curl_global_cleanup();

  return 0;
}

>From 6e0ff31d469ec6690b85e2bd19052ae1a66f98fa Mon Sep 17 00:00:00 2001
From: Dmitry Eremin-Solenikov 
Date: Wed, 20 May 2015 22:50:55 +0300
Subject: [PATCH] gtls: don't fail on non-fatal alerts during handshake

Stop curl from failing when non-fatal alert is received during
handshake.  This e.g. fixes lots of problems when working with https
sites through proxies.

(cherry picked from commit d5aab55b3353bec1d34a2e1434399d23db79b254)
---
 

Bug#817210: systemd-resolve: segfaults upon domain name resolution

[Yuriy M. Kaminskiy]

On 03/09/16, Rostislav Pehlivanov wrote:
> Upgrading to the latest libnss3 (3.23) fixes the problem.

libnss3 is crypto library by mozilla, it is not related anyhow to name 
resolution and glibc nss subsystem, it is not used by systemd, and very 
unlikely to affect this bug anyhow. So, if this problem was fixed, it 
was something else.


P.S. if problem will reappear, to debug daemons that cannot be launched 
from gdb, you can either attach to them in gdb alive (gdb 
/path/to/daemon `pidof daemon`) or enable coredumps (take a look at 
systemd-coredump) and do post-mortem examination (gdb /path/to/daemon 
/path/to/core).

Bug#817247: fatrace: sigsegv on -p option

[Yuriy M. Kaminskiy]

Package: fatrace
Version: 0.11-1
Severity: normal
Tags: patch upstream

Dear Maintainer,

`fatrace -p 1234` dies with SIGSEGV on line 311, as short-option 'p' is 
labeled as flag (instead of option-with-argument), so optarg is NULL. 
Attached trivial patch fixes it.


P.S. this regression was introduced in in 0.10 (rev62), in jessie's 0.9 
it was correct.


-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fatrace depends on:
ii  libc6  2.19-18

Versions of packages fatrace recommends:
ii  powertop  2.6.1-1
ii  python3   3.4.2-2

fatrace suggests no packages.

-- no debconf information

Index: fatrace-0.11/fatrace.c
===
--- fatrace-0.11.orig/fatrace.c
+++ fatrace-0.11/fatrace.c
@@ -254,7 +254,7 @@ parse_args (int argc, char** argv)
 };
 
 while (1) {
-c = getopt_long (argc, argv, "C:co:s:tpf:h", long_options, NULL);
+c = getopt_long (argc, argv, "C:co:s:tp:f:h", long_options, NULL);
 
 if (c == -1)
 break;

Bug#815016: iceweasel: Crashes randomly when playing videos on YouTube

[Yuriy M. Kaminskiy]

Backtrace looks similar to (unresolved)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799632

Bug#814239: gcc-4.9: debian/patches/ada-symbolic-tracebacks.diff use snprintf return value without check

[Yuriy M. Kaminskiy]

Package: gcc-4.9
Version: 4.9.2-10
Severity: normal
Tags: security

During code search, I found potentially problematic code in 
debian/patches/ada-symbolic-tracebacks.diff: it uses snprintf() results 
without checking its range, like this:


+else {
+  *len += snprintf(s, (max_len - (*len)), "%p at 
%s",addrs[i], line);

+}
+s = buf + (*len);

When formatted string would overflow supplied buffer or other error 
happens, snprintf returns value larger than buffer size or -1. In both 
cases, if you directly add it to the pointer, like in the above code, 
bad things will happen.


(Same patch seems used with other versions of gcc-* packages.)

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-4.9 depends on:
ii  binutils2.25-5
ii  cpp-4.9 4.9.2-10
ii  gcc-4.9-base4.9.2-10
ii  libc6   2.19-18
ii  libcloog-isl4   0.18.2-1+b2
ii  libgcc-4.9-dev  4.9.2-10
ii  libgmp102:6.0.0+dfsg-6
ii  libisl100.12.2-2
ii  libmpc3 1.0.2-1
ii  libmpfr43.1.2-2
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages gcc-4.9 recommends:
ii  libc6-dev  2.19-18

Versions of packages gcc-4.9 suggests:
ii  gcc-4.9-doc   4.9.1-3
pn  gcc-4.9-locales   
ii  gcc-4.9-multilib  4.9.2-10
pn  libasan1-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#813879: systemd: Assertion 's->exec_command[SERVICE_EXEC_START]' failed service_enter_start()

[Yuriy M. Kaminskiy]

On 08.02.2016 02:15, Yuriy M. Kaminskiy wrote:

Package: systemd
Version: 215-17+deb8u3
Severity: important


Probably related:
cron-update.service is triggered by some /etc/cron* directories change 
and invokes `systemctl daemon-reload` and `systemctl try-restart 
cron.target`. Maybe there are some racing when it is triggered right 
when cron.target is being stopped?


Probably related upstream commit: 
96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1
(aka v216-30-g96fb824), however, it likely fixes symptoms [assert() 
and abort], but not underlying issue [racing or whatever].


I've looked at core file, after musing a bit upon sources, I don't think 
this commit will fix/hide issue.


Backtrace:

#6  0x7f08e081124f in service_enter_start (s=s@entry=0x7f08e21c7a10)
at ../src/core/service.c:1312
#7  0x7f08e0813341 in service_sigchld_event.lto_priv.377 
(u=0x7f08e21c7a10,

pid=, code=, status=0)
at ../src/core/service.c:2338
#8  0x7f08e084b887 in manager_dispatch_sigchld (m=0x7f08e20fc350)
at ../src/core/manager.c:1639

(gdb) p s->type
$14 = _SERVICE_TYPE_INVALID
(gdb) p s->state
$15 = SERVICE_START_PRE
(gdb)  p s->meta.load_state
$16 = UNIT_NOT_FOUND
(gdb) p s->exec_command
$18 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0}

Problem is, we started executing unit, spawned StartPre command, then 
unit file was removed, systemctl daemon-reload was issued, unit 
structure become half-ghost, then we got SIGCHLD for that StartPre 
command from the already-removed unit. Oops.


With 96fb824 applied, end result would be same:

@@ -1332,6 +1345,12 @@ static void service_enter_start(Service *s) {
 c = s->main_command = s->exec_command[SERVICE_EXEC_START];
 }

+if (!c) {
+assert(s->type == SERVICE_ONESHOT);
+service_enter_start_post(s);
+return;
+}
+

c is NULL, s->type here is _SERVICE_TYPE_INVALID, so we'll die in assert 
anyway :-\


It is possible that upstream systemd version is still affected, you may 
want to try install jessie's systemd-cron 1.3.* into sid and play with 
install/removal in a loop.
Completely untested patches for systemd master and backport to v215 is 
attached.
>From c4def2806f6e8f7cf9c8087e0e994db8122e272f Mon Sep 17 00:00:00 2001
From: "Yuriy M. Kaminskiy" <yum...@gmail.com>
Date: Mon, 8 Feb 2016 18:00:48 +0300
Subject: [PATCH] Fix sigchld handling for invalid unit

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813879
---
 src/core/service.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/core/service.c b/src/core/service.c
index 02ce1a5..32741ae 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -2747,6 +2747,12 @@ static void service_sigchld_event(Unit *u, pid_t pid, int code, int status) {
 
 log_unit_debug(u, "Got final SIGCHLD for state %s.", service_state_to_string(s->state));
 
+if (s->type == _SERVICE_TYPE_INVALID) {
+log_unit_error(u,
+"is invalid, but got final SIGCHLD for state %s",
+service_state_to_string(s->state));
+// XXX is there anything else to do?
+} else
 switch (s->state) {
 
 case SERVICE_START_PRE:
-- 
2.1.4

>From b666cd926f8c437d12d1ad6a0d6c29a4595db6f7 Mon Sep 17 00:00:00 2001
From: "Yuriy M. Kaminskiy" <yum...@gmail.com>
Date: Mon, 8 Feb 2016 18:00:48 +0300
Subject: [PATCH] [backport-v215] Fix sigchld handling for invalid unit

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813879
---
 src/core/service.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/core/service.c b/src/core/service.c
index 3c4dfa1..c08d536 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -2347,6 +2347,12 @@ static void service_sigchld_event(Unit *u, pid_t pid, int code, int status) {
"%s got final SIGCHLD for state %s",
u->id, service_state_to_string(s->state));
 
+if (s->type == _SERVICE_TYPE_INVALID) {
+log_error_unit(u->id,
+"%s got final SIGCHLD for state %s in invalid state",
+u->id, service_state_to_string(s->state));
+// XXX is there anything else to do?
+} else
 switch (s->state) {
 
 case SERVICE_START_PRE:
-- 
2.1.4

Bug#813879: systemd: Assertion 's->exec_command[SERVICE_EXEC_START]' failed service_enter_start()

[Yuriy M. Kaminskiy]

Package: systemd
Version: 215-17+deb8u3
Severity: important

Dear Maintainer,

systemd crash badly while removing systemd-cron and installing cron. It does
not respond anymore and reboot is not working.

Installing systemd-cron

Feb 05 20:45:48 debir systemd[1]: Reloading.
Feb 05 20:45:49 debir systemd[1]: Reloading.
Feb 05 20:45:49 debir systemd[1]: Starting [Cron] "0 * * * * root if [ -x 
/usr/sbin/backupninja ]; then /usr/sbin/backupninja; fi".
Feb 05 20:45:49 debir systemd[1]: Started [Cron] "0 * * * * root if [ -x 
/usr/sbin/backupninja ]; then /usr/sbin/backupninja; fi".
Feb 05 20:45:49 debir systemd[1]: Starting [Cron] "14 04 * * * root 
/usr/local/sbin/skcbackup 4".
Feb 05 20:45:49 debir systemd[1]: Started [Cron] "14 04 * * * root 
/usr/local/sbin/skcbackup 4".
Feb 05 20:45:49 debir systemd[1]: Starting systemd-cron path monitor.
Feb 05 20:45:49 debir systemd[1]: Started systemd-cron path monitor.
Feb 05 20:45:49 debir systemd[1]: Starting systemd-cron monthly timer.
Feb 05 20:45:49 debir systemd[1]: Started systemd-cron monthly timer.
Feb 05 20:45:49 debir systemd[1]: Starting systemd-cron weekly timer.
Feb 05 20:45:49 debir systemd[1]: Started systemd-cron weekly timer.
Feb 05 20:45:49 debir systemd[1]: Starting systemd-cron daily timer.
Feb 05 20:45:49 debir systemd[1]: Started systemd-cron daily timer.
Feb 05 20:45:49 debir systemd[1]: Starting systemd-cron hourly timer.
Feb 05 20:45:49 debir systemd[1]: Started systemd-cron hourly timer.
Feb 05 20:45:49 debir systemd[1]: Starting systemd-cron.
Feb 05 20:45:49 debir systemd[1]: Reached target systemd-cron.

Removing systemd-cron, installing cron

Feb 05 20:51:02 debir systemd[1]: Stopping systemd-cron.
Feb 05 20:51:02 debir systemd[1]: Stopped target systemd-cron.
Feb 05 20:51:02 debir systemd[1]: Stopping systemd-cron hourly timer.
Feb 05 20:51:02 debir systemd[1]: Stopped systemd-cron hourly timer.
Feb 05 20:51:02 debir systemd[1]: Stopping systemd-cron daily timer.
Feb 05 20:51:02 debir systemd[1]: Stopped systemd-cron daily timer.
Feb 05 20:51:02 debir systemd[1]: Stopping systemd-cron weekly timer.
Feb 05 20:51:02 debir systemd[1]: Stopped systemd-cron weekly timer.
Feb 05 20:51:02 debir systemd[1]: Stopping systemd-cron monthly timer.
Feb 05 20:51:02 debir systemd[1]: Stopped systemd-cron monthly timer.
Feb 05 20:51:02 debir systemd[1]: Stopping [Cron] "14 04 * * * root 
/usr/local/sbin/skcbackup 4".
Feb 05 20:51:02 debir systemd[1]: Stopped [Cron] "14 04 * * * root 
/usr/local/sbin/skcbackup 4".
Feb 05 20:51:03 debir systemd[1]: Starting systemd-cron update units...
Feb 05 20:51:03 debir systemd[1]: Reloading.
Feb 05 20:51:03 debir systemd[1]: Assertion 
's->exec_command[SERVICE_EXEC_START]' failed at ../src/core/service.c:1312, 
function service_enter_start(). Aborting.
Feb 05 20:51:03 debir systemd[1]: Caught , dumped core as pid 30693.
Feb 05 20:51:03 debir systemd[1]: Freezing execution.


Probably related:
systemd-cron contains cron.target
cron contains cron.service
Maybe systemd somehow mixes the two during reload? (Unlikely)

Probably related:
cron-update.service is triggered by some /etc/cron* directories change 
and invokes `systemctl daemon-reload` and `systemctl try-restart 
cron.target`. Maybe there are some racing when it is triggered right 
when cron.target is being stopped?


Probably related upstream commit: 96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1
(aka v216-30-g96fb824), however, it likely fixes symptoms [assert() and 
abort], but not underlying issue [racing or whatever].


[...]

Errors were encountered while processing:
 cron
 apticron
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@debir:~#

Can not reboot the system anymore:

root@debir:~# reboot
Failed to start reboot.target: Connection timed out
Failed to open initctl FIFO: No such device or address
Failed to talk to init daemon.
root@debir:~#


Disclaimer: not an expert/maintainer/whatever, largely untested, feel 
free to correct.


Only 'init' process can reboot system normally, and after receiving any
fatal signal (SEGV, FPE, ABRT, etc), systemd switches to 'freezing'
state (for(;;) pause();), and then refuse to do anything.

Probably, only way out -
try to stop anything important by hand,
try to `umount ...` or `mount -o remount -r ...` all filesystems likely
not in use, then:
Ctrl-Alt-F1 (switch to console)
Alt-SysRq-e (this will kill all remaining processes with SIGTERM)
[wait a bit for everything to settle]
Alt-SysRq-i (SIGKILL remaining processes)
Alt-SysRq-s (sync filesystems)
Alt-SysRq-u (forcibly remount all filesystems readonly)
Alt-SysRq-b (reboot)

(see /usr/share/doc/linux-doc-3.16/Documentation/sysrq.txt.gz on details)

P.S. I wished there were backported systemd or something. There are a
lot of such issues silently fixed in upstream, that nearly 
impossible/impractical to backport into stable version :-\ (then again, 
there are a lot of incompatibilities with other packages, that would 
require more and more backports, to extent 

Bug#774012: Still is not fixed for jessie (Re: systemd: Program terminated with signal SIGFPE, Arithmetic exception)

[Yuriy M. Kaminskiy]

On 28.12.2015 16:15, Michael Biebl wrote:

Am 28.12.2015 um 13:33 schrieb Yuriy M. Kaminskiy:

This bug is still present in jessie's systemd 215-17+deb8u1 (backtrace
is same).

If someone, who is able to reproduce the issue, is willing to backport
the necessary changes to v215, I'd be willing to merge this patch for
stable, assuming the change is not too invasive.

This issue was claimed to be "probably fixed" by commit 
9c3349e23b14db27e7ba45f82cf647899c563ea9.
I've cherry-picked that commit to v215, fixed conflicts, stripped out 
cosmetic changes (and removed one chunk that was later reverted 
upstream), see attached.
Unfortunately, I have no idea how to reliable reproduce this issue (and 
have no spare machine for tests), so it is completely untested.
Given it is not clear if this issue is completely fixed, I'd rather 
replace "assert()" with "return"; maybe, n_running_jobs==0 will break 
something somewhere else, but at least it should not outright kill 
systemd process with SIGFPE (or assert), see second patch.
>From 82612551e5c5acf64eab66ec6d43d5380e84acf2 Mon Sep 17 00:00:00 2001
From: Lennart Poettering <lenn...@poettering.net>
Date: Mon, 5 Jan 2015 17:22:10 +0100
Subject: [PATCH] core: rework counting of running jobs

Let's unify the code that counts the running jobs a bit, in order to
make sure we are less likely to miss one.

This is related to this bug:

https://bugs.freedesktop.org/show_bug.cgi?id=87349

However, it probably won't fix it fully, and I cannot reproduce the issue.

The change also adds an explicit assert change when the counter is off.

(cherry picked from commit 9c3349e23b14db27e7ba45f82cf647899c563ea9)
(and squashed partial revert from commit d6483ba7834b9e63caee929c9d6373b796be1b21)

Conflicts:
	src/core/job.c
	src/core/manager.c
---
 src/core/job.c | 61 +++---
 src/core/manager.c |  8 ++-
 src/core/unit.c| 11 +-
 3 files changed, 52 insertions(+), 28 deletions(-)

diff --git a/src/core/job.c b/src/core/job.c
index dc4f441..cfc63cf 100644
--- a/src/core/job.c
+++ b/src/core/job.c
@@ -96,11 +96,39 @@ void job_free(Job *j) {
 free(j);
 }
 
+static void job_set_state(Job *j, JobState state) {
+assert(j);
+assert(state >= 0);
+assert(state < _JOB_STATE_MAX);
+
+if (j->state == state)
+return;
+
+j->state = state;
+
+if (!j->installed)
+return;
+
+if (j->state == JOB_RUNNING)
+j->unit->manager->n_running_jobs++;
+else {
+assert(j->state == JOB_WAITING);
+assert(j->unit->manager->n_running_jobs > 0);
+
+j->unit->manager->n_running_jobs--;
+
+if (j->unit->manager->n_running_jobs <= 0)
+j->unit->manager->jobs_in_progress_event_source = sd_event_source_unref(j->unit->manager->jobs_in_progress_event_source);
+}
+}
+
 void job_uninstall(Job *j) {
 Job **pj;
 
 assert(j->installed);
 
+job_set_state(j, JOB_WAITING);
+
 pj = (j->type == JOB_NOP) ? >unit->nop_job : >unit->job;
 assert(*pj == j);
 
@@ -155,6 +183,7 @@ Job* job_install(Job *j) {
 
 assert(!j->installed);
 assert(j->type < _JOB_TYPE_MAX_IN_TRANSACTION);
+assert(j->state == JOB_WAITING);
 
 pj = (j->type == JOB_NOP) ? >unit->nop_job : >unit->job;
 uj = *pj;
@@ -181,8 +210,8 @@ Job* job_install(Job *j) {
 log_debug_unit(uj->unit->id,
"Merged into running job, re-running: %s/%s as %u",
uj->unit->id, job_type_to_string(uj->type), (unsigned) uj->id);
-uj->state = JOB_WAITING;
-uj->manager->n_running_jobs--;
+
+job_set_state(uj, JOB_WAITING);
 return uj;
 }
 }
@@ -209,5 +239,9 @@ int job_install_deserialized(Job *j) {
 *pj = j;
 j->installed = true;
+
+if (j->state == JOB_RUNNING)
+j->unit->manager->n_running_jobs++;
+
 log_debug_unit(j->unit->id,
"Reinstalled deserialized job %s/%s as %u",
j->unit->id, job_type_to_string(j->type), (unsigned) j->id);
@@ -481,8 +513,7 @@ int job_run_and_invalidate(Job *j) {
 if (!job_is_runnable(j))
 return -EAGAIN;
 
-j->state = JOB_RUNNING;
-m->n_running_jobs++;
+job_set_state(j, JOB_RUNNING);
 job_add_to_dbus_queue(j);
 
 /* While we ex

Bug#774012: Still is not fixed for jessie (Re: systemd: Program terminated with signal SIGFPE, Arithmetic exception)

[Yuriy M. Kaminskiy]

This bug is still present in jessie's systemd 215-17+deb8u1 (backtrace 
is same).

Bug#808333: transmission-daemon: SIGSEGV due to racing in list node allocation

[Yuriy M. Kaminskiy]

Package: transmission-daemon
Version: 2.84-0.2
Severity: normal
Tags: patch upstream fixed-upstream

Dear Maintainer,

transmission-daemon died on SIGSEGV (probably triggered by starting 
torrent with webseed), backtrace seems same as in upstream ticket

https://trac.transmissionbt.com/ticket/5735
and it was fixed in upstream/trunk:
https://trac.transmissionbt.com/changeset/14319
I guess, it will be included in yet-to-be-released 2.90, upstream patch 
attached.
Ticket suggests this bug affects other variants of transmission as well 
(gtk and qt).


I don't see serious security implications (DoS at worst); but crashes 
are annoying and fix is trivial, so maybe it worth fixing for next 
jessie point release.


-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages transmission-daemon depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18
ii  libcurl3-gnutls  7.38.0-4+deb8u2
ii  libevent-2.0-5   2.0.21-stable-2
ii  libminiupnpc10   1.9.20140610-2
ii  libnatpmp1   20110808-3
ii  libssl1.0.0  1.0.1k-3+deb8u1
ii  libsystemd0  215-17+deb8u1
ii  lsb-base 4.1+Debian13+nmu1
ii  transmission-common  2.84-0.2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages transmission-daemon recommends:
ii  transmission-cli  2.84-0.2

transmission-daemon suggests no packages.

-- Configuration Files:
/etc/transmission-daemon/settings.json [Errno 13] Permission denied: 
u'/etc/transmission-daemon/settings.json'


-- no debconf information

(gdb) bt
#0  node_alloc () at list.c:43
#1  0xf7788d5d in tr_list_append (list=0xf77ea7a4 , 
data=0xf3894a18) at list.c:99
#2  0xf777b337 in writeFunc (ptr=0xf38f9208, size=1, nmemb=16384, 
vtask=0xf6359e00)
at web.c:127
#3  0xf763a943 in ?? () from /usr/lib/i386-linux-gnu/libcurl-gnutls.so.4
#4  0xf764fc01 in curl_easy_pause () from 
/usr/lib/i386-linux-gnu/libcurl-gnutls.so.4
#5  0xf777b80b in tr_webThreadFunc (vsession=0xf8f8ae80) at web.c:448
#6  0xf775fac9 in ThreadFunc (_t=0xf6316218) at platform.c:105
#7  0xf73ffefb in start_thread (arg=0xf62ffb40) at pthread_create.c:309
#8  0xf733862e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
(gdb) p ret  
$1 = (tr_list *) 0x0
(gdb) p recycled_nodes 
$2 = (tr_list *) 0x0 

--- a/libtransmission/list.c	(revision 14318)
+++ b/libtransmission/list.c	(revision 14319)
@@ -30,20 +30,24 @@
 static tr_list*
 node_alloc (void)
 {
-  tr_list * ret;
+  tr_list * ret = NULL;
+  tr_lock * lock = getRecycledNodesLock ();
 
-  if (recycled_nodes == NULL)
+  tr_lockLock (lock);
+
+  if (recycled_nodes != NULL)
 {
-  ret = tr_new (tr_list, 1);
-}
-  else
-{
-  tr_lockLock (getRecycledNodesLock ());
   ret = recycled_nodes;
   recycled_nodes = recycled_nodes->next;
-  tr_lockUnlock (getRecycledNodesLock ());
 }
 
+  tr_lockUnlock (lock);
+
+  if (ret == NULL)
+{
+  ret = tr_new (tr_list, 1);
+}
+
   *ret = TR_LIST_CLEAR;
   return ret;
 }
@@ -51,13 +55,15 @@
 static void
 node_free (tr_list* node)
 {
+  tr_lock * lock = getRecycledNodesLock ();
+
   if (node != NULL)
 {
   *node = TR_LIST_CLEAR;
-  tr_lockLock (getRecycledNodesLock ());
+  tr_lockLock (lock);
   node->next = recycled_nodes;
   recycled_nodes = node;
-  tr_lockUnlock (getRecycledNodesLock ());
+  tr_lockUnlock (lock);
 }
 }
 

Bug#794798: libnspr4-dev: pthread missing from pkg-config lib deps

[Yuriy M. Kaminskiy]

Mike Hommey wrote:

On Thu, Aug 06, 2015 at 04:37:06PM -0500, D. Jared Dominguez wrote:

On Thu, Aug 06, 2015 at 03:46:39PM -0500, Mike Hommey wrote:
On Thu, Aug 06, 2015 at 01:42:55PM -0500, Daniel Jared Dominguez wrote:
Package: libnspr4-dev
Version: 2:4.10.8-2
Severity: important

pkg-config --libs nspr returns:
-lplds4 -lplc4 -lnspr4

However, at least pthread is missing, which causes building with nspr4 and
using pkg-config not to work right.

You don't need to link against pthread to link against nspr.

Well, it's what's causing this: http://paste.debian.net/289831/

Particularly,

/usr/bin/gcc -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security  -Wall -Wsign-compare -Wno-unused-result
-Wno-unused-function -std=gnu11 -fshort-wchar -fPIC -flto
-fno-strict-aliasing -fno-merge-constants -D_GNU_SOURCE -DCONFIG_x86_64
-I/«PKGBUILDDIR»/include -I/usr/include/efivar -I/usr/include/nss
-I/usr/include/nspr   -Wl,-z,relro-D_FORTIFY_SOURCE=2 -o pesigcheck
pesigcheck.o pesigcheck_context.o certdb.o cms_common.o content_info.o oid.o
password.o signed_data.o signer_info.o wincert.o ucs2.o
/«PKGBUILDDIR»/libdpe/libdpe.a  -lefivar -lnss3 -lnssutil3 -lsmime3 -lssl3
-lplds4 -lplc4 -lnspr4 -lpopt /usr/bin/ld: /tmp/ccSnL8H8.ltrans1.ltrans.o:
undefined reference to symbol 'pthread_rwlock_wrlock@@GLIBC_2.2.5'
//lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from 
command line
collect2: error: ld returned 1 exit status


I see that this is what Fedora is doing:
http://pkgs.fedoraproject.org/cgit/nspr.git/tree/nspr-config-pc.patch

Also,
$ ldd /usr/lib/x86_64-linux-gnu/libnspr4.so | grep pthread
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f3111be4000)

To me, that seems to be a pretty good indication that pthread is needed to link
against nspr.


To me, that seems to be a pretty good indication that one of those
object files is using pthread_rwlock_wrlock.

The only reference to pthread_rwlock_wrlock in the nspr code base is in
a .c file, which means there is no way something #including nspr header
can inadvertently have a dependency on that symbol.


-lpthread -lrt -ldl (@OS_LIBS@) is certainly required for static linking 
(and there are static libraries in libnspr-dev).


(However, I think the linked above fedora patch is also slightly wrong, 
@OS_LIBS@ should be in Libs.private, not in Libs).


But I don't see -static in failed command above, so not sure why it 
fails and if this is a same problem.



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

Bug#793642: sidplay-libs: please add Multi-Arch support

[Yuriy M. Kaminskiy]

Package: libsidplay2
Version: 2.1.1-14
Severity: wishlist
Tags: patch

Dear Maintainer,

It would be nice if sidplay-libs was converted to multiarch.

Attached debdiff upgrade debhelper to 9 and adds multi-arch support;

Out of BD, I've successfully rebuilt mpd against patched package (but
have not checked other packages);

Known limitation: /usr/include/sidplay/sidconfig.h is autoconf-generated 
and not co-installable (rendering libsidplay2-dev non-multi-arch in 
attached debdiff) [note that sidint.h is also autogenerated, but likely 
sameco-installable on most/all platforms];


Disclaimer: I have very limited experience with debian packaging, please
review and test debdiff carefully.

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsidplay2 depends on:
ii  libc6   2.19-18
ii  libgcc1 1:4.9.2-10
ii  libstdc++6  4.9.2-10

libsidplay2 recommends no packages.

libsidplay2 suggests no packages.

-- no debconf information

diff -Nru sidplay-libs-2.1.1/debian/autoreconf sidplay-libs-2.1.1/debian/autoreconf
--- sidplay-libs-2.1.1/debian/autoreconf	1970-01-01 03:00:00.0 +0300
+++ sidplay-libs-2.1.1/debian/autoreconf	2015-07-24 17:05:33.0 +0300
@@ -0,0 +1,6 @@
+.
+libsidplay
+libsidutils
+resid
+builders/hardsid-builder
+builders/resid-builder
diff -Nru sidplay-libs-2.1.1/debian/changelog sidplay-libs-2.1.1/debian/changelog
--- sidplay-libs-2.1.1/debian/changelog	2013-02-25 21:53:56.0 +0400
+++ sidplay-libs-2.1.1/debian/changelog	2015-07-24 16:52:13.0 +0300
@@ -1,3 +1,11 @@
+sidplay-libs (2.1.1-14+1~local1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Updated to debhelper 9.
+  * Added Multi-Arch support.
+
+ -- Yuriy M. Kaminskiy yumkam+deb...@gmail.com  Fri, 24 Jul 2015 16:51:42 +0300
+
 sidplay-libs (2.1.1-14) unstable; urgency=low
 
   [ Sebastian Ramacher sramac...@debian.org ]
diff -Nru sidplay-libs-2.1.1/debian/compat sidplay-libs-2.1.1/debian/compat
--- sidplay-libs-2.1.1/debian/compat	2012-02-07 02:37:26.0 +0400
+++ sidplay-libs-2.1.1/debian/compat	2015-07-24 16:55:43.0 +0300
@@ -1 +1 @@
-6
+9
diff -Nru sidplay-libs-2.1.1/debian/control sidplay-libs-2.1.1/debian/control
--- sidplay-libs-2.1.1/debian/control	2012-02-07 02:37:26.0 +0400
+++ sidplay-libs-2.1.1/debian/control	2015-07-24 17:28:57.0 +0300
@@ -2,12 +2,13 @@
 Section: sound
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) g...@debian.hu
-Build-Depends: debhelper (= 6), autoconf, automake, libtool
+Build-Depends: debhelper (= 9), dh-autoreconf
 Standards-Version: 3.9.2
 
 Package: libsidplay2-dev
 Section: libdevel
 Architecture: any
+#Multi-Arch: same # XXX /usr/include/sidplay/sidconfig.h is not co-installable!
 Depends: libsidplay2 (= ${binary:Version}), ${misc:Depends}
 Description: SID (MOS 6581) emulation library
  This is a (shared) library that implements the emulation of the C64's
@@ -24,6 +25,8 @@
 Package: libsidplay2
 Section: libs
 Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Replaces: libsidplay2-1, libsidplay2-1c102 (= 2.1.1-2)
 Conflicts: libsidplay2-1, libsidplay2-1c102 (= 2.1.1-2)
@@ -42,6 +45,7 @@
 Package: libsidutils-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: libsidutils0 (= ${binary:Version}), ${misc:Depends}
 Description: utility functions for SID players
  This library contains various things deemed useful to all SID players
@@ -64,6 +68,8 @@
 Package: libsidutils0
 Section: libs
 Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: utility functions for SID players
  This library contains various things deemed useful to all SID players
@@ -86,6 +92,7 @@
 Package: libresid-builder-dev
 Section: libdevel
 Architecture: any
+Multi-Arch: same
 Depends: libresid-builder0c2a (= ${binary:Version}), ${misc:Depends}
 Replaces: libresid-dev (= 2.1.0)
 Conflicts: libresid-dev (= 2.1.0)
@@ -97,6 +104,8 @@
 Package: libresid-builder0c2a
 Section: libs
 Architecture: any
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Replaces: libresid2c102 (= 2.1.1-2), libresid-builder0
 Conflicts: libresid2c102 (= 2.1.1-2), libresid-builder0
diff -Nru sidplay-libs-2.1.1/debian/libresid-builder0c2a.dirs sidplay-libs-2.1.1/debian/libresid-builder0c2a.dirs
--- sidplay-libs-2.1.1/debian/libresid-builder0c2a.dirs	2012-02-07 02:37:26.0 +0400
+++ sidplay-libs-2.1.1/debian/libresid-builder0c2a.dirs	1970-01-01 03:00:00.0 +0300
@@ -1 +0,0 @@
-usr/lib
diff -Nru sidplay-libs-2.1.1

Bug#792827: geoip-bin: geoip-generator-asn produces malformed database

[Yuriy M. Kaminskiy]

Package: geoip-bin
Version: 1.6.2-4
Severity: normal

Dear Maintainer,

E.g., with geoip-database-extra_20150317-1
$ geoiplookup -i 37.229.162.60
GeoIP Country Edition: UA, Ukraine
...
GeoIP ASNum Edition: AS714 Apple Inc.
Error Traversing Database for ipnum = 635806267 - Perhaps database is
corrupt?
Error Traversing Database for ipnum = 635806271 - Perhaps database is
corrupt?
  ipaddr: 37.229.162.60
  range_by_ip:  37.229.162.60 - 37.229.162.62
  network:  37.229.162.60 - 37.229.162.61 ::31
  ipnum: 635806268
  range_by_num: 635806268 - 635806270
  network num:  635806268 - 635806269 ::31

With binary database from
http://download.maxmind.com/download/geoip/database/asnum/GeoIPASNum.dat.gz
it correctly shows:
$ geoiplookup -i -d . 37.229.162.60
GeoIP ASNum Edition: AS15895 Kyivstar PJSC
  ipaddr: 37.229.162.60
  range_by_ip:  37.229.0.0 - 37.229.255.255
  network:  37.229.0.0 - 37.229.255.255 ::16
  ipnum: 635806268
  range_by_num: 635764736 - 635830271
  network num:  635764736 - 635830271 ::16

I've tried with (self-compiled) geoip_1.6.5-2 libraries/generator and
geoip-database-extra_20150512-1 from sid, it seems problem persists.

PS With geoip-database-extra from jessie-backports (20150710-1~bpo8+1):
GeoIP ASNum Edition: AS32656 Nuveen Investments, LLC
Error Traversing Database for ipnum = 635806267 - Perhaps database is
corrupt?
  ipaddr: 37.229.162.60
  range_by_ip:  37.229.162.60 - 37.229.162.61
  network:  37.229.162.60 - 37.229.162.61 ::31
  ipnum: 635806268
  range_by_num: 635806268 - 635806269
  network num:  635806268 - 635806269 ::31
(i.e. still broken)

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages geoip-bin depends on:
ii  libc6   2.19-18
ii  libgcc1 1:4.9.2-10
ii  libgeoip1   1.6.2-4
ii  libstdc++6  4.9.2-10

geoip-bin recommends no packages.

geoip-bin suggests no packages.

-- no debconf information


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

Bug#792515: sqlite3: dpkg-shlibdeps: warning: package could avoid a useless dependency

[Yuriy M. Kaminskiy]

Package: sqlite3
Version: 3.8.7.1-1+deb8u1
Severity: wishlist
Tags: patch

Dear Maintainer,

When rebuilding package, I noticed dpkg-shlibdeps warnings about 
unnecessary dependencies on libncurses5, libtinfo5 in sqlite3 package, 
which could be avoided with --as-needed linker option, see attached debdiff.


-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sqlite3 depends on:
ii  libc6 2.19-18
ii  libreadline6  6.3-8+b3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libtinfo5 5.9+20140913-1+b1

sqlite3 recommends no packages.

Versions of packages sqlite3 suggests:
ii  sqlite3-doc  3.8.7.1-1+deb8u1

-- no debconf information

diff -Nru sqlite3-3.8.10.2/debian/rules sqlite3-3.8.10.2/debian/rules
--- sqlite3-3.8.10.2/debian/rules	2015-05-13 00:13:35.0 +0300
+++ sqlite3-3.8.10.2/debian/rules	2015-07-13 14:41:20.0 +0300
@@ -20,11 +20,13 @@
 export DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
+export LDFLAGS += -Wl,--as-needed
 ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
   confflags += --build $(DEB_HOST_GNU_TYPE) --with-tcl=/usr/lib/$(DEB_HOST_MULTIARCH)/tcl8.6
   export CROSS_BUILDING=no
 else
-  confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) --with-tcl=/usr/lib/$(DEB_HOST_MULTIARCH)/tcl8.6 LDFLAGS=-L/usr/lib/$(DEB_HOST_MULTIARCH)
+  confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) --with-tcl=/usr/lib/$(DEB_HOST_MULTIARCH)/tcl8.6
+  LDFLAGS += -L/usr/lib/$(DEB_HOST_MULTIARCH)
   export CROSS_BUILDING=yes
 endif
 
@@ -37,7 +39,7 @@
 configure: configure-stamp
 configure-stamp:
 	dh_testdir
-	dh_autoreconf
+	dh_autoreconf --as-needed
 	dh_autotools-dev_updateconfig
 	./configure --prefix=/usr --mandir=/usr/share/man \
 	  $(confflags) --enable-threadsafe \

Bug#638974: libsqlite3-dev: A call to sqlite3_open() gives a SIGSEGV

[Yuriy M. Kaminskiy]

On 14.07.2015 11:23, László Böszörményi (GCS) wrote:

Hi,

On Tue, Jul 14, 2015 at 2:58 AM, Yuriy M. Kaminskiy yum...@gmail.com wrote:

Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #638974

1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and valgrind
report attached);

  Your issue is quite different from the one you sent this followup
for. The gdb report is missing, but it would be useful for upstream,
not me. :(


Oops, sorry, I somehow mixed numbers, that should have been sent as 
followup to #736463 :-( #638974 is, indeed, unrelated.



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

Bug#736463: libsqlite3-0: UNIQUE PRIMARY KEY + WITHOUT ROWID = segfault

[Yuriy M. Kaminskiy]

Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #736463

(was sent to unrelated bug, resenting, sorry)
1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and 
valgrind report attached);
2) I was *NOT* able to reproduce it in (self-backported) sid's 
3.8.10.2-1 (and running under valgrind does not show any problem).
[fwiw, test.db created by sid {totally expectdly} kills jessie's sqlite3 
on attempt to open it].
However, I have not found respective entry in changelogs (or upstream 
commit), so this could be false positive.


-- System Information:
Debian Release: 8.1
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsqlite3-dev depends on:
ii  libc6-dev 2.19-18
ii  libsqlite3-0  3.8.7.1-1+deb8u1

libsqlite3-dev recommends no packages.

Versions of packages libsqlite3-dev suggests:
ii  sqlite3-doc  3.8.7.1-1+deb8u1

-- no debconf information

$ valgrind sqlite3 test.db CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID;
==7586== Memcheck, a memory error detector
==7586== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7586== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==7586== Command: sqlite3 test.db CREATE\ TABLE\ t\ (\ x\ UNIQUE\ PRIMARY\ KEY\ )\ WITHOUT\ ROWID;
==7586== 
==7586== Invalid read of size 1
==7586==at 0x48E8AF9: sqlite3EndTable (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CAAF7: sqlite3Parser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CE7BB: sqlite3RunParser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CEE64: sqlite3Prepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CF224: sqlite3LockAndPrepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x10E603: shell_exec.constprop.10 (in /usr/bin/sqlite3)
==7586==by 0x10A78E: main (in /usr/bin/sqlite3)
==7586==  Address 0x37 is not stack'd, malloc'd or (recently) free'd
==7586== 
==7586== 
==7586== Process terminating with default action of signal 11 (SIGSEGV)
==7586==  Access not within mapped region at address 0x37
==7586==at 0x48E8AF9: sqlite3EndTable (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CAAF7: sqlite3Parser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CE7BB: sqlite3RunParser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CEE64: sqlite3Prepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CF224: sqlite3LockAndPrepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x10E603: shell_exec.constprop.10 (in /usr/bin/sqlite3)
==7586==by 0x10A78E: main (in /usr/bin/sqlite3)
==7586==  If you believe this happened as a result of a stack
==7586==  overflow in your program's main thread (unlikely but
==7586==  possible), you can try to increase the size of the
==7586==  main thread stack using the --main-stacksize= flag.
==7586==  The main thread stack size used in this run was 8388608.
==7586== 
==7586== HEAP SUMMARY:
==7586== in use at exit: 75,860 bytes in 101 blocks
==7586==   total heap usage: 262 allocs, 161 frees, 101,111 bytes allocated
==7586== 
==7586== LEAK SUMMARY:
==7586==definitely lost: 0 bytes in 0 blocks
==7586==indirectly lost: 0 bytes in 0 blocks
==7586==  possibly lost: 75,848 bytes in 100 blocks
==7586==still reachable: 12 bytes in 1 blocks
==7586== suppressed: 0 bytes in 0 blocks
==7586== Rerun with --leak-check=full to see details of leaked memory
==7586== 
==7586== For counts of detected and suppressed errors, rerun with: -v
==7586== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

(gdb) run
Starting program: /usr/bin/sqlite3 test.db CREATE\ TABLE\ t\ \(\ x\ UNIQUE\ PRIMARY\ KEY\ \)\ WITHOUT\ ROWID\;
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1.

Program received signal SIGSEGV, Segmentation fault.
convertToWithoutRowidTable (pTab=0x5657b7c0, pParse=0x5657aa78)
at sqlite3.c:90230
90230	sqlite3.c: No such file or directory.
(gdb) bt full
#0  convertToWithoutRowidTable (pTab=0x5657b7c0, pParse=0x5657aa78)
at sqlite3.c:90230
pPk = 0x0
nPk = optimized out
i = optimized out
db = 0x56568010
pIdx = optimized out
j = optimized out
v = optimized out
#1  sqlite3EndTable (pParse=0x5657aa78, pCons=0x5657ad00, pEnd=0x5657ad10, 
tabOpts=32 ' ', pSelect=0x0) at sqlite3.c:24813
p = 0x5657b7c0
db = 0x56568010
pIdx = optimized out
#2  0xf7f46af8 in yy_reduce (yyruleno=optimized out, 

Bug#736463: libsqlite3-0: UNIQUE PRIMARY KEY + WITHOUT ROWID = segfault

[Yuriy M. Kaminskiy]

On 14.07.2015 14:36, László Böszörményi (GCS) wrote:

On Tue, Jul 14, 2015 at 11:41 AM, Yuriy M. Kaminskiy yum...@gmail.com wrote:

Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #736463

(was sent to unrelated bug, resenting, sorry)
1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and valgrind
report attached);
2) I was *NOT* able to reproduce it in (self-backported) sid's 3.8.10.2-1
(and running under valgrind does not show any problem).
[fwiw, test.db created by sid {totally expectdly} kills jessie's sqlite3 on 
attempt to open it].
However, I have not found respective entry in changelogs (or upstream
commit), so this could be false positive.

  I can only repeat that the quick solution to remove UNIQUE, the
PRIMARY KEY itself guarantee that the specified column will be unique.


:shrug:
There should be no problem with attempt to open a database file obtained 
from untrusted source, right? It's just data, no executable code[*], 
etc, right?

Then try to open attached database with jessie's sqlite3.
Or feed it to mozilla (IIRC, there are javascript binding?)
That is, this is a security problem.

(The fact that UNIQUE constraint is redundant with PRIMARY KEY is 
completely irrelevant here; e.g. it can be autogenerated code, database 
should handle that gracefully anyway).


[*] well, almost; there are triggers, but their side effects are limited 
to altering the database.


test.db
Description: Binary data

Bug#736463: libsqlite3-0: UNIQUE PRIMARY KEY + WITHOUT ROWID = segfault

[Yuriy M. Kaminskiy]

control: tag -1 patch
thanks

On 14.07.2015 15:34, Yuriy M. Kaminskiy wrote:

On 14.07.2015 14:36, László Böszörményi (GCS) wrote:
On Tue, Jul 14, 2015 at 11:41 AM, Yuriy M. Kaminskiy 
yum...@gmail.com wrote:

Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #736463

(was sent to unrelated bug, resenting, sorry)
1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and 
valgrind

report attached);
2) I was *NOT* able to reproduce it in (self-backported) sid's 
3.8.10.2-1

(and running under valgrind does not show any problem).
[fwiw, test.db created by sid {totally expectdly} kills jessie's 
sqlite3 on attempt to open it].

However, I have not found respective entry in changelogs (or upstream
commit), so this could be false positive.

  I can only repeat that the quick solution to remove UNIQUE, the
PRIMARY KEY itself guarantee that the specified column will be unique.


:shrug:
There should be no problem with attempt to open a database file 
obtained from untrusted source, right? It's just data, no executable 
code[*], etc, right?

Then try to open attached database with jessie's sqlite3.
Or feed it to mozilla (IIRC, there are javascript binding?)
That is, this is a security problem.

(The fact that UNIQUE constraint is redundant with PRIMARY KEY is 
completely irrelevant here; e.g. it can be autogenerated code, 
database should handle that gracefully anyway).


[*] well, almost; there are triggers, but their side effects are 
limited to altering the database.


Apparently, this commit: http://www.sqlite.org/src/info/d871a7921722bb0f 
(included in 3.8.9) plugged SIGSEGV.
However, this commit (not yet in any released version): 
http://www.sqlite.org/src/info/3b936913f3dc2cae
suggest that d871a probably was insufficient/broken in some subtle way 
(and, indeed, I see corruption in patched 3.8.7.1 and [unpatched] 
3.8.10.2, triggered by sql code from 3b936 test suite).
That said, I think d871a792 is probably sufficient for stable (sigsegv 
plugged, rest is outside of stable scope).
Upstream: http://www.sqlite.org/src/info/d871a7921722bb0f
Closes: #736463

Index: sqlite3-3.8.7.1/src/build.c
===
--- sqlite3-3.8.7.1.orig/src/build.c
+++ sqlite3-3.8.7.1/src/build.c
@@ -3168,6 +3168,7 @@ Index *sqlite3CreateIndex(
 pIdx-onError = pIndex-onError;
   }
 }
+pRet = pIdx;
 goto exit_create_index;
   }
 }

Bug#638974: libsqlite3-dev: A call to sqlite3_open() gives a SIGSEGV

[Yuriy M. Kaminskiy]

Package: libsqlite3-dev
Version: 3.8.7.1-1+deb8u1
Followup-For: Bug #638974

FYI:
1) I was able to reproduce this bug in jessie's 3.8.7.1 (gdb and 
valgrind report attached);
2) I was *NOT* able to reproduce it in (self-backported) sid's 
3.8.10.2-1 (and running under valgrind does not show any problem).

[fwiw, test.db created sid {totally expectdly} kills jessie's on attempt
to open it].
However, I have not found respective entry in changelogs (or upstream 
commit), so this could be false positive.


-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libsqlite3-dev depends on:
ii  libc6-dev 2.19-18
ii  libsqlite3-0  3.8.7.1-1+deb8u1

libsqlite3-dev recommends no packages.

Versions of packages libsqlite3-dev suggests:
ii  sqlite3-doc  3.8.7.1-1+deb8u1

-- no debconf information
$ valgrind sqlite3 test.db CREATE TABLE t ( x UNIQUE PRIMARY KEY ) WITHOUT ROWID;
==7586== Memcheck, a memory error detector
==7586== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7586== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==7586== Command: sqlite3 test.db CREATE\ TABLE\ t\ (\ x\ UNIQUE\ PRIMARY\ KEY\ )\ WITHOUT\ ROWID;
==7586== 
==7586== Invalid read of size 1
==7586==at 0x48E8AF9: sqlite3EndTable (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CAAF7: sqlite3Parser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CE7BB: sqlite3RunParser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CEE64: sqlite3Prepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CF224: sqlite3LockAndPrepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x10E603: shell_exec.constprop.10 (in /usr/bin/sqlite3)
==7586==by 0x10A78E: main (in /usr/bin/sqlite3)
==7586==  Address 0x37 is not stack'd, malloc'd or (recently) free'd
==7586== 
==7586== 
==7586== Process terminating with default action of signal 11 (SIGSEGV)
==7586==  Access not within mapped region at address 0x37
==7586==at 0x48E8AF9: sqlite3EndTable (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CAAF7: sqlite3Parser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CE7BB: sqlite3RunParser (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CEE64: sqlite3Prepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x48CF224: sqlite3LockAndPrepare (in /usr/lib/i386-linux-gnu/libsqlite3.so.0.8.6)
==7586==by 0x10E603: shell_exec.constprop.10 (in /usr/bin/sqlite3)
==7586==by 0x10A78E: main (in /usr/bin/sqlite3)
==7586==  If you believe this happened as a result of a stack
==7586==  overflow in your program's main thread (unlikely but
==7586==  possible), you can try to increase the size of the
==7586==  main thread stack using the --main-stacksize= flag.
==7586==  The main thread stack size used in this run was 8388608.
==7586== 
==7586== HEAP SUMMARY:
==7586== in use at exit: 75,860 bytes in 101 blocks
==7586==   total heap usage: 262 allocs, 161 frees, 101,111 bytes allocated
==7586== 
==7586== LEAK SUMMARY:
==7586==definitely lost: 0 bytes in 0 blocks
==7586==indirectly lost: 0 bytes in 0 blocks
==7586==  possibly lost: 75,848 bytes in 100 blocks
==7586==still reachable: 12 bytes in 1 blocks
==7586== suppressed: 0 bytes in 0 blocks
==7586== Rerun with --leak-check=full to see details of leaked memory
==7586== 
==7586== For counts of detected and suppressed errors, rerun with: -v
==7586== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

(gdb) run
Starting program: /usr/bin/sqlite3 test.db CREATE\ TABLE\ t\ \(\ x\ UNIQUE\ PRIMARY\ KEY\ \)\ WITHOUT\ ROWID\;
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/i386-linux-gnu/i686/cmov/libthread_db.so.1.

Program received signal SIGSEGV, Segmentation fault.
convertToWithoutRowidTable (pTab=0x5657b7c0, pParse=0x5657aa78)
at sqlite3.c:90230
90230	sqlite3.c: No such file or directory.
(gdb) bt full
#0  convertToWithoutRowidTable (pTab=0x5657b7c0, pParse=0x5657aa78)
at sqlite3.c:90230
pPk = 0x0
nPk = optimized out
i = optimized out
db = 0x56568010
pIdx = optimized out
j = optimized out
v = optimized out
#1  sqlite3EndTable (pParse=0x5657aa78, pCons=0x5657ad00, pEnd=0x5657ad10, 
tabOpts=32 ' ', pSelect=0x0) at sqlite3.c:24813
p = 0x5657b7c0
db = 0x56568010
pIdx = optimized out
#2  0xf7f46af8 in yy_reduce (yyruleno=optimized out, 
yypParser=optimized out) at sqlite3.c:122341