Bug#1061241: endless-sky: debian/copyright incomplete

[Damyan Ivanov]

Package: endless-sky
Version: 0.10.4-1
Severity: serious
Justification: Policy 2.3, 12.5

The upgrade to 0.10.4 missed the changes in upstream licensing and 
copyright notices.

The changes in the summary, as supplied by upstream, can be seen at
https://salsa.debian.org/games-team/endless-sky/-/commit/d7fef4cf2282a3ab364133093e5f156bc5f1d790#521307ddb67a4abc14248801dae5e5989aca76c1

Note that this 'copyright' file looks much like Debian's 
'debian/copyright' but fails some expectations like listing general 
Files: patterns before more specific ones so it can't be used verbatim.


-- Damyan


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

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

Versions of packages endless-sky depends on:
ii  endless-sky-data  0.10.4-1
ii  libc6 2.37-13
ii  libgcc-s1 13.2.0-10
ii  libglew2.22.2.0-4+b1
ii  libglx0   1.7.0-1
ii  libjpeg62-turbo   1:2.1.5-2+b2
ii  libmad0   0.15.1b-10.1+b1
ii  libopenal11:1.23.1-4
ii  libopengl01.7.0-1
ii  libpng16-16   1.6.40-3
ii  libsdl2-2.0-0 2.28.5+dfsg-3
ii  libstdc++613.2.0-10
ii  libuuid1  2.39.3-6

endless-sky recommends no packages.

endless-sky suggests no packages.

-- no debconf information

Bug#1058690: marked as pending in liblatex-tounicode-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #1058690 in liblatex-tounicode-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/liblatex-tounicode-perl/-/commit/808faa5812566085b701bf764752e08177ebe4c1


add Breaks/Replaces texlive-bibtex-extra (<< 2023.20231207-2)

Closes: #1058690


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1058690

Bug#1056143: marked as pending in libeval-context-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #1056143 in libeval-context-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libeval-context-perl/-/commit/af2880f401309126fdbb5e624525a1cda88cb6fa


add a patch fixing test suite with libdata-treedumper-perl 0.41

Also bump the build-dependency

Closes: #1056143


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1056143

Bug#1054654: marked as pending in liblwp-protocol-http-socketunix-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #1054654 in liblwp-protocol-http-socketunix-perl reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/liblwp-protocol-http-socketunix-perl/-/commit/d4f3898333e178f0d20fb0745a20dbe4585648b8


patch in explicit loading of LWP::Debug

Closes: #1054654


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1054654

Bug#1050451: marked as pending in libperl-languageserver-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #1050451 in libperl-languageserver-perl reported by you has been fixed in 
the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libperl-languageserver-perl/-/commit/3c59be99c41e4f397602bdd6ebfce81eb13666c7


patch away given/when/smartmatch usage; deprecated in perl 5.38

Closes: #1050451


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1050451

Bug#1030658: More info needed on the RC bug you opened

[Damyan Ivanov]

-=| Martin Quinson, 22.02.2023 08:58:42 +0100 |=-
> tag 1030658 +moreinfo
> thanks
> 
> Hello Damyan,
> 
> sorry for not noticing this bug before, I thought I was subscribed to the
> package.

No problem.

Today, however, everything works again. I tried on two systems 
tracking sid, including the one I used to report the issue. Strange.

> It looks like a missing dependency to me. Could you please give me 
> the output
> of `ldd /usr/bin/zeal` ?

linux-vdso.so.1 (0x7fff9f3be000)
libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 
(0x7fa243c0)
libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 
(0x7fa24360)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fa2434a1000)
libQt5Concurrent.so.5 => /lib/x86_64-linux-gnu/libQt5Concurrent.so.5 
(0x7fa2443a)
libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 
(0x7fa242c0)
libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 
(0x7fa2432f7000)
libQt5WebEngineWidgets.so.5 => 
/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5 (0x7fa244352000)
libQt5WebEngineCore.so.5 => 
/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 (0x7fa23aa0)
libQt5WebChannel.so.5 => /lib/x86_64-linux-gnu/libQt5WebChannel.so.5 
(0x7fa24432c000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7fa242abe000)
libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 
(0x7fa244325000)
libxcb-keysyms.so.1 => /lib/x86_64-linux-gnu/libxcb-keysyms.so.1 
(0x7fa23a60)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x7fa2442f9000)
libarchive.so.13 => /lib/x86_64-linux-gnu/libarchive.so.13 
(0x7fa23a938000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fa23a20)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fa2442d9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa23a41f000)
/lib64/ld-linux-x86-64.so.2 (0x7fa24451f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa23a859000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fa2442b8000)
libdouble-conversion.so.3 => 
/lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x7fa243beb000)
libicui18n.so.72 => /lib/x86_64-linux-gnu/libicui18n.so.72 
(0x7fa239e0)
libicuuc.so.72 => /lib/x86_64-linux-gnu/libicuuc.so.72 
(0x7fa239c02000)
libpcre2-16.so.0 => /lib/x86_64-linux-gnu/libpcre2-16.so.0 
(0x7fa243b5d000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fa23a144000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 
(0x7fa239aca000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7fa239a43000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 
(0x7fa242a88000)
libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 
(0x7fa23993f000)
libmd4c.so.0 => /lib/x86_64-linux-gnu/libmd4c.so.0 (0x7fa2432e5000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7fa23a807000)
libQt5Quick.so.5 => /lib/x86_64-linux-gnu/libQt5Quick.so.5 
(0x7fa23920)
libQt5PrintSupport.so.5 => 
/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x7fa2398cb000)
libQt5QuickWidgets.so.5 => 
/lib/x86_64-linux-gnu/libQt5QuickWidgets.so.5 (0x7fa2432d)
libQt5Qml.so.5 => /lib/x86_64-linux-gnu/libQt5Qml.so.5 
(0x7fa238c0)
libQt5Positioning.so.5 => /lib/x86_64-linux-gnu/libQt5Positioning.so.5 
(0x7fa23983d000)
libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x7fa2390a7000)
libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so 
(0x7fa23980b000)
libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x7fa2397c9000)
libevent-2.1.so.7 => /lib/x86_64-linux-gnu/libevent-2.1.so.7 
(0x7fa239772000)
libjpeg.so.62 => /lib/x86_64-linux-gnu/libjpeg.so.62 
(0x7fa238b6d000)
libopus.so.0 => /lib/x86_64-linux-gnu/libopus.so.0 (0x7fa238b0f000)
libvpx.so.7 => /lib/x86_64-linux-gnu/libvpx.so.7 (0x7fa23880)
libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 
(0x7fa2442ab000)
libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 
(0x7fa243b58000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x7fa242a73000)
libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 
(0x7fa242a6b000)
libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 
(0x7fa23a137000)
libXtst.so.6 => /lib/x86_64-linux-gnu/libXtst.so.6 (0x7fa242a63000)
libwebpmux.so.3 => /lib/x86_64-linux-gnu/libwebpmux.so.3 
(0x7fa23a12b000)
libwebpdemux.so.2 => /lib/x86_64-linux-gnu/libwebpdemux.so.2 
(0x7fa23976c000)
libwebp.so.7 => 

Bug#1030697: libjs-bootstrap5: not co-installable with libjs-bootstrap4

[Damyan Ivanov]

Package: libjs-bootstrap5
Version: 5.2.3+dfsg-7
Followup-For: Bug #1030697

Control: found -1 5.2.3+dfsg-7

Still can't install the package with libjs-bootstrap4 installed:

 Preparing to unpack .../libjs-bootstrap5_5.2.3+dfsg-7_all.deb ...
 Unpacking libjs-bootstrap5 (5.2.3+dfsg-7) ...
 dpkg: error processing archive 
/var/cache/apt/archives/libjs-bootstrap5_5.2.3+dfsg-7_all.deb (--unpack):
  trying to overwrite '/usr/share/nodejs/bootstrap/package.json', which is also 
in package libjs-bootstrap4 4.6.1+dfsg1-4
 Errors were encountered while processing:
  /var/cache/apt/archives/libjs-bootstrap5_5.2.3+dfsg-7_all.deb


-- Damyan

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages libjs-bootstrap5 depends on:
ii  libjs-popper.js  1.16.1+ds-6

libjs-bootstrap5 recommends no packages.

Versions of packages libjs-bootstrap5 suggests:
ii  bootstrap-icons   1.10.3+dfsg-1
ii  libjs-bootstrap5-doc  5.2.3+dfsg-7

Bug#1030658: fail to retrieve docset info: TLS initialization failed (caused by unresolved OpenSSL symbols)

[Damyan Ivanov]

Package: zeal
Version: 1:0.6.1+git20220714+6fee23-2
Severity: grave

This problem makes it impossible to download docsets and start using Zeal, thus 
the severity.

I observe this error since months, so it is not related to a recent change in 
some other package. Sorry for not reporting it earlier.

Trying to retrieve docsets fails with:

Download failed!

Error: TLS initialization failed
URL: https://api.zealdocs.org/v1/docsets

[Cancel][Retry]

The console contains the following:
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_ssl
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_init_crypto
qt.network.ssl: QSslSocket: cannot resolve ASN1_STRING_get0_data
qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_reset
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_up_ref
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_CTX_new
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_param_check
qt.network.ssl: QSslSocket: cannot resolve EVP_PKEY_CTX_free
qt.network.ssl: QSslSocket: cannot resolve RSA_bits
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_new_null
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_push
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_free
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_num
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_pop_free
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_sk_value
qt.network.ssl: QSslSocket: cannot resolve DH_get0_pqg
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_options
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_get_security_level
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_security_level
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_ciphersuites
qt.network.ssl: QSslSocket: cannot resolve SSL_set_psk_use_session_callback
qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_is_resumable
qt.network.ssl: QSslSocket: cannot resolve SSL_get_client_random
qt.network.ssl: QSslSocket: cannot resolve SSL_SESSION_get_master_key
qt.network.ssl: QSslSocket: cannot resolve SSL_session_reused
qt.network.ssl: QSslSocket: cannot resolve SSL_set_options
qt.network.ssl: QSslSocket: cannot resolve TLS_method
qt.network.ssl: QSslSocket: cannot resolve TLS_client_method
qt.network.ssl: QSslSocket: cannot resolve TLS_server_method
qt.network.ssl: QSslSocket: cannot resolve X509_up_ref
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get0_chain
qt.network.ssl: QSslSocket: cannot resolve X509_getm_notBefore
qt.network.ssl: QSslSocket: cannot resolve X509_getm_notAfter
qt.network.ssl: QSslSocket: cannot resolve X509_get_version
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_set_verify_cb
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_set_ex_data
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_get_ex_data
qt.network.ssl: QSslSocket: cannot resolve OpenSSL_version_num
qt.network.ssl: QSslSocket: cannot resolve OpenSSL_version
qt.network.ssl: Incompatible version of OpenSSL
qt.network.ssl: QSslSocket: cannot call unresolved function d2i_X509
(repeats numerous times)
qt.network.ssl: QSslSocket::connectToHostEncrypted: TLS initialization failed

Rebuilding the package using current unstable didn't help.


-- Damyan


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages zeal depends on:
ii  libarchive13 3.6.2-1
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libqt5concurrent55.15.8+dfsg-2
ii  libqt5core5a 5.15.8+dfsg-2
ii  libqt5gui5   5.15.8+dfsg-2
ii  libqt5network5   5.15.8+dfsg-2
ii  libqt5sql5-sqlite5.15.8+dfsg-2
ii  libqt5webchannel55.15.8-2
ii  libqt5webenginecore5 5.15.12+dfsg-3
ii  libqt5webenginewidgets5  5.15.12+dfsg-3
ii  libqt5widgets5   5.15.8+dfsg-2
ii  libqt5x11extras5 5.15.8-2
ii  libsqlite3-0 3.40.1-1
ii  libstdc++6   12.2.0-14
ii  libx11-6 2:1.8.3-3
ii  libxcb-keysyms1  0.4.0-1+b2
ii  libxcb1  1.15-1

zeal recommends no packages.

zeal suggests no packages.

-- no debconf information

Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705

[Damyan Ivanov]

-=| Jose M Calhariz, 02.02.2023 19:20:23 + |=-
> This is my first security update, can I ask what is the procedure or 
> where is documented?

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security-building

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#bug-security


-- Damyan


> On January 28, 2023 12:59:09 PM GMT+00:00, Salvatore Bonaccorso
>  wrote:
> 
> Source: amanda
> Version: 1:3.5.1-9
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerabilities were published for amanda.
> 
> CVE-2022-37704[0], CVE-2022-37705[1].
> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2022-37704
> https://www.cve.org/CVERecord?id=CVE-2022-37704
> [1] https://security-tracker.debian.org/tracker/CVE-2022-37705
> https://www.cve.org/CVERecord?id=CVE-2022-37705
> [2] https://github.com/zmanda/amanda/issues/192
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore
> 

Bug#1021817: firebird3.0: undistributable source files

[Damyan Ivanov]

Source: firebird3.0
Version: 3.0.1.32609.ds4-14
Severity: serious
Tags: upstream
Justification: Policy 2.1 (DFSG)
Forwarded: https://github.com/FirebirdSQL/firebird/issues/7349

Four files in src/intl/ contain contradictory statements from Unicode Inc, 
claiming that the file cannot be redistributed, and from Inprise Corporation, 
claiming it is licensed under the Interbase Public License (which allows 
redistribution; it is an MPL-like license).

src/intl/charsets/cs_big5.h
src/intl/charsets/cs_jis_0208_1990.h
src/intl/charsets/cs_next.h
src/intl/charsets/cs_sjis.h

Hopefully this can be resolved upstream. Otherwise the four files above would 
need to be excluded from the sources used by the Debian package and therefore 
lose support for the corresponding national character sets.

-- Damyan

Bug#1017375: marked as pending in liblexical-accessor-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #1017375 in liblexical-accessor-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/liblexical-accessor-perl/-/commit/5a60e0b880a38a2bade2d052b3941178bd56d254


bump (build-) dependency on libsub-handlesvia-perl to 0.035 fixing FTBFS

Closes: #1017375


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1017375

Bug#1017375: liblexical-accessor-perl: test failure with Sub::HandlesVia 0.034

[Damyan Ivanov]

-=| gregor herrmann, 17.08.2022 17:59:41 +0200 |=-
> This should be fixed with libsub-handlesvia-perl 0.035, judging from
> the following upstream commit:
> …
> Also Changes say:
>  - Sub::HandlesVia::CodeGenerator method_installer is now a rw attribute as
>Sub::Accessor::Small was relying on that.
> 
> 
> I'm going to upload libsub-handlesvia-perl now, then we can depend on
> the fixed version to close this bug, I guess?

build-time and run-time dependency version bumped, all tests pass, so 
uploaded.

Thank you for the investigation.


-- Damyan

Bug#1017528: aborts at startup: Using libsoup2 and libsoup3 in the same process is not supported

[Damyan Ivanov]

Package: gtranslator
Version: 42.0-1
Severity: grave

On an up to date unstable, gtranslator aborts at startup:

(gtranslator:58389): libsoup-ERROR **: 13:25:11.006: libsoup3 symbols 
detected. Using libsoup2 and libsoup3 in the same process is not supported.
zsh: trace trap (core dumped)  gtranslator bg.po

Surprisingly, ldd doesn't show libsoup2 in the linked libraries:

$ ldd /usr/bin/gtranslator|grep soup
libsoup-3.0.so.0 => /usr/lib/x86_64-linux-gnu/libsoup-3.0.so.0 
(0x7fb803048000)


-- Damyan


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gtranslator depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gsettings-desktop-schemas42.0-1
ii  iso-codes4.11.0-1
ii  libatk1.0-0  2.38.0-1
ii  libc62.34-4
ii  libcairo21.16.0-6
ii  libgda-5.0-4 5.2.10-2
ii  libgettextpo00.21-8
ii  libglib2.0-0 2.72.3-1+b1
ii  libgspell-1-21.11.1-1
ii  libgtk-3-0   3.24.34-1
ii  libgtksourceview-4-0 4.8.3-1
ii  libhandy-1-0 1.7.90-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpango-1.0-0   1.50.9+ds-1
ii  libsoup-3.0-03.1.3-1
ii  libxml2  2.9.14+dfsg-1+b1

gtranslator recommends no packages.

Versions of packages gtranslator suggests:
pn  libpeas-1.0-python2loader  

-- debconf-show failed

Bug#1017375: liblexical-accessor-perl: test failure with Sub::HandlesVia 0.034

[Damyan Ivanov]

Package: liblexical-accessor-perl
Version: 0.014-1
Severity: serious
Tags: upstream ftbfs
Justification: fails to build from source (but built successfully in the past)

t/30shv.t fails with:

Usage: Sub::HandlesVia::CodeGenerator::method_installer(self) at 
.../lib/Sub/HandlesVia/Toolkit/SubAccessorSmall.pm line 58.

In version 0.034, Sub::HandlesVia::CodeGenerator's method_installer field 
is read-only and the above line tries to modify it:

$gen->method_installer( sub {
my ( $method_name, $coderef ) = @_;
my $real_destination = $handles_map->{$method_name};
$realattr->install_coderef( $real_destination, $coderef );
} );



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#1016369: IO::Handle ->error does not work, always saying "fine"

[Damyan Ivanov]

-=| Ian Jackson, 30.07.2022 13:42:05 +0100 |=-
> Package: perl
> Version: 5.34.0-4
> Severity: grave
> 
> To reproduce
> 
> perl -MIO::Handle -e 'open X, "<", "." or die $!; $_ = ; printf "%s %s 
> %s\n", X->error(), $!;'
> perl -MIO::Handle -e 'open X, ">", "/dev/full" or die $!; print X 1; 
> flush X; printf "%s %s %s\n", X->error(), $!; close X'
> 
> Expected output
> 
> -1 Bad file descriptor
> -1 No space left on device
> 
> Actual output
> 
> 0 Bad file descriptor
> 0 No space left on device

Thanks for the reproducer. I have converted it to a test file and have 
run that on all perl versions from blead back to 5.6.2, thanks to 
perlbrew.

Here's the test file:
===
$ cat 1016369.t
use Test::More;

plan skip_all => "IO::Handle not available" unless eval 'use IO::Handle; 1';

open(X, "<", ".") or die $!;
ok(!defined(), 'failed reading from ".", as expected');
ok(X->error,  'X->error is TRUE after reading from "."');
close X;

SKIP: {
skip "/dev/full not available", 3 unless -w '/dev/full';

open X, '>', '/dev/full' or die $!;
ok((print X "1"), "successful write to /dev/full");
ok(!X->flush, "flush after writing to /dev/full fails");
ok(X->error,  "X->error is TRUE after flushing /dev/full");
close X;
}

done_testing;
==

Digested results of `prove 1016369.t`:

'X->error is TRUE after reading from "."': all versions fail

'X->error is TRUE after flushing /dev/full': blead, 5.36.0, 5.34.3 and 
5.6.2 pass, 5.32.1 through 5.8.9 fail

> This is quite alarming.  I think it makes it in fact impossible to
> read files fully reliably in Perl.

On the other hand, it went unnoticed for many years, so it can't be 
that bad.

Note that the recommended way to read files line by line is (perldoc 
-f readline):

while ( ! eof($fh) ) {
defined( $_ = readline $fh ) or die "readline failed: $!";
...
}

This may explain why the X->error misbehaviour wasn't detected for so 
long.

> "use autodie" does not seem to help.

I think this is expected. autodie replaces the functional interface, 
lexically, not the OO one provided by IO::Handle.

> And scripts might reasonably have expected that they could defer 
> error handling by testing error() rather than each call (as one can 
> in C).

Here I concur. The behaviour of X->error is wrong and needs fixing.

> I think this used to work, but, evidently, only in the distant past,
> since my jessie chroot doesn't get this right either.

This part was what inspired my archaeological tests above. 5.6.2 was 
indeed far in the past.

> Justification for the severity:
> 
> Can cause data loss: if a file is opened but unreadable for any
> reason, the program will process the part (if any) that will is
> readable and then 

I'd use 'important' to signal that it would be nice to get this fixed 
in stable and that the package is still quite useful, but this is for 
Niko and Dominic to decide. Perhaps it doesn't matter so much in the 
end, since perl is Essential:yes.


-- Damyan

Bug#1013526: libtickit-widget-scrollbox-perl: FTBFS: dh_auto_test: error: /usr/bin/perl Build test --verbose 1 returned exit code 255

[Damyan Ivanov]

Control: retitle -1 libtickit-widget-scrollbox-perl: intermittent memory 
corruption in t/02input-key.t and t/03input-mouse.t

I can reproduce this when running 02input-key.t and 03input-key.t in 
a loop. The symptom is the same - "malloc_consolidate(): unaligned 
fastbin chunk detected" error message and the tests exits with Wstat 
134 after saying "All 14 subtests passed".

Wstat 134 is SIGABRT. Looks like a memory corruption of some sort.

After enabling core dumps, the following backtrace is observed:

(gdb) thread apply all bt

Thread 1 (Thread 0x7fbd5e0622c0 (LWP 401521)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x7fbd5e0c0546 in __GI_abort () at abort.c:79
#2  0x7fbd5e117eb8 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7fbd5e235a78 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7fbd5e11f91a in malloc_printerr (str=str@entry=0x7fbd5e237de8 
"malloc_consolidate(): unaligned fastbin chunk detected") at malloc.c:5628
#4  0x7fbd5e1209c4 in malloc_consolidate (av=av@entry=0x7fbd5e26cba0 
) at malloc.c:4709
#5  0x7fbd5e1211d0 in _int_free (av=0x7fbd5e26cba0 , 
p=0x5573c9773940, have_lock=) at malloc.c:4633
#6  0x7fbd5e1249b4 in __GI___libc_free (mem=) at 
malloc.c:3309
#7  0x5573c74b3bdf in Perl_hv_undef_flags 
(my_perl=my_perl@entry=0x5573c8b762a0, hv=hv@entry=0x5573c91ea6a0, 
flags=flags@entry=2) at ./build-static/hv.c:2115
#8  0x5573c74c5620 in Perl_sv_clear (my_perl=my_perl@entry=0x5573c8b762a0, 
orig_sv=orig_sv@entry=0x5573c91ea6a0) at ./build-static/sv.c:6864
#9  0x5573c74c4411 in Perl_sv_free2 (my_perl=my_perl@entry=0x5573c8b762a0, 
sv=0x5573c91ea6a0, rc=) at ./build-static/sv.c:7088
#10 0x5573c74c5248 in Perl_SvREFCNT_dec_NN (sv=, 
my_perl=0x5573c8b762a0) at ./build-static/inline.h:314
#11 do_clean_objs (ref=0x5573c91fb800, my_perl=0x5573c8b762a0) at 
./build-static/sv.c:533
#12 S_visit (mask=2048, flags=2048, f=, my_perl=0x5573c8b762a0) 
at ./build-static/sv.c:476
#13 Perl_sv_clean_objs (my_perl=my_perl@entry=0x5573c8b762a0) at 
./build-static/sv.c:627
#14 0x5573c741de2b in perl_destruct (my_perl=0x5573c8b762a0) at 
./build-static/perl.c:893
#15 0x5573c73f649c in main (argc=, argv=, 
env=) at ./build-static/perlmain.c:121


I've filed a wishlist #1013740 for upgrading libtickit to 0.4.2a, 
which would allow upgrading libtickit-perl to the latest upstream, 
either of which may help.

Bug#994736: marked as pending in libmath-gsl-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #994736 in libmath-gsl-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libmath-gsl-perl/-/commit/a39ecf1dea34463c9a336a52239abea7248579bd


exclude all symbols that are missing on arm64

assuming the other failing architectures fail for the same reazon

Closes: #994736


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/994736

Bug#993323: marked as pending in libmath-gsl-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #993323 in libmath-gsl-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libmath-gsl-perl/-/commit/00e4d353ab3dc20e577086c6a88e9dc488297b7d


patch version detection to treat all 2.7.x versions as 2.7

Closes: #993323


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/993323

Bug#1011725: marked as pending in libio-async-ssl-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #1011725 in libio-async-ssl-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libio-async-ssl-perl/-/commit/0c0624cca94a8c6df7bee294fef81594a83666f4


add a patch to adapt error message matching to openssl 3

Closes: #1011725


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1011725

Bug#995402: marked as pending in libclass-dbi-sweet-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #995402 in libclass-dbi-sweet-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libclass-dbi-sweet-perl/-/commit/f70f8715314be5cc428366b938badc7d92e2ed9f


patch usage of SQL::Abstract and replace it with SQL::Abstract::Classic

Closes: #995402 -- FTBFS with SQL::Abstract 2.0


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/995402

Bug#995402: libclass-dbi-sweet-perl: FTBFS: test failure

[Damyan Ivanov]

Just a recording of a failed attempt to figure out what is wrong.

The problem seems to be with an internal SQL::Abstract method that is 
used by Class::DBI::Sweet (_recurse_where), which is reworked in the 
2.0 release, so a two-level join isn't handled.

It is not clear to me whether SQL:A is to blame or C:DBI:S. Should be 
the later, since SQL:A can't actually know which class/table 
corresponds to the joined alias or how to construct the join 
expression.

Anyway, If I had to decide today what happens with the package, I'd 
consider two options: removal of the package, and removal of the 
two-level join from documentation/tests.


-- Damyan

Bug#1006658: libobject-pad-perl breaks libtickit-widget-scrollbox-perl autopkgtest: malloc_consolidate(): unaligned fastbin chunk detected

[Damyan Ivanov]

Control: notfound 1006658 libtickit-widget-scrollbox-perl/0.11-1
Control: fixed 1006658 0.65-1

> With a recent upload of libobject-pad-perl the autopkgtest of
> libtickit-widget-scrollbox-perl fails in testing when that autopkgtest is
> run with the binary packages of libobject-pad-perl from unstable. It passes
> when run with only packages from testing. In tabular form:
> 
>passfail
> libobject-pad-perl from testing0.61-1
> libtickit-widget-scrollbox-perl from testing0.11-1
> all others from testingfrom testing

This seems to have fixed by itself at some point. The same version of 
libtickit-widget-scrollbox-perl now builds/tests fine with object-pad 
0.65, so marking the bug as fixed in that version.


-- Damyan

Bug#1005016: libobject-pad-slotattr-final-perl: Object::Pad::SlotAttr::Final is replaced by Object::Pad::FieldAttr::Final

[Damyan Ivanov]

-=| gregor herrmann, 09.02.2022 21:18:13 +0100 |=-
> > % apt-cache --names-only search libobject-pad-slot | grep -v 
> > dbgsym
> > libobject-pad-slotattr-final-perl - declare Object::Pad slots readonly 
> > after construction
> > libobject-pad-slotattr-isa-perl - apply class type constraints to 
> > Object::Pad slots
> > libobject-pad-slotattr-lazyinit-perl - lazily initialise Object::Pad slots 
> > at first read
> > libobject-pad-slotattr-trigger-perl - invoke an instance method after a 
> > :writer accessor
> 
> Alright, making this a bit more formal:
> - cloning the bug for the 3 other affected packages
> - marking them as serious as they currently block the perl 5.34
>   transition (by way of blocking the rebuilt arch:any libobject-pad-perl
>   as it breaks the 4 autopkgtests); this could be ignored, but the
>   4 packages are doomed anyway, so an RC bug makes removal from
>   testing more transparent.

I have just uploaded libobject-pad-fieldattr-final-perl to NEW. The 
others will follow.

I guess the deprecated packages should go the RM route? Perhaps after 
the new ones are accepted?

Not sure whether the waiting for the replacements to enter unstable is 
strictly necessary. To me it just feels polite to possible users

-- Damyan

Bug#961147: libcolor-calc-perl: broken by new libgraphics-colornames-perl

[Damyan Ivanov]

-=| intrigeri, 22.05.2020 08:47:25 +0200 |=-
> Hi,
> 
> Niko Tyni (2020-05-21):
> > So IMO we should either to package Graphics::ColorNames::HTML even though
> > it's deprecated, or drop Color::Calc from Debian.
> 
> > libcolor-calc-perl has just one reverse dependency AFAICS:
> > libcgi-application-plugin-authentication-perl.
> 
> I took a quick look.

Me too, a longer one :)

I just pushed a patch in Git that makes Color::Calc use '::WWW' 
instead of '::HTML', sorting hash keys so that color names are 
enumerated in a deterministic order and adapted almost all of the 
tests (mainly "gray"→"grey" and "aqua"→"cyan").

There is one test still failing, about "safe" colors.

Then I read your comments about removal :)

Uncertain what to do with the "safe" color conversion, looking at the 
aged upstream release, I decided to stop here. Maybe someone some day 
will find the patch useful.

--dam

Bug#965613: konwert: diff for NMU version 1.8-13.2

[Damyan Ivanov]

Control: tags 965613 + patch
Control: tags 965613 + pending

Dear maintainer,

I've prepared an NMU for konwert (versioned as 1.8-13.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer or speed it up.

Regards,
dam
diff -Nru konwert-1.8/debian/changelog konwert-1.8/debian/changelog
--- konwert-1.8/debian/changelog	2020-12-27 17:28:47.0 +0200
+++ konwert-1.8/debian/changelog	2022-01-11 22:13:21.0 +0200
@@ -1,3 +1,11 @@
+konwert (1.8-13.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump debhelper compatibility level from 5 to 7
+Closes: 965613 - removal of compatibility levels 5 and 6
+
+ -- Damyan Ivanov   Tue, 11 Jan 2022 20:13:21 +
+
 konwert (1.8-13.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru konwert-1.8/debian/compat konwert-1.8/debian/compat
--- konwert-1.8/debian/compat	2014-06-23 00:00:29.0 +0300
+++ konwert-1.8/debian/compat	2022-01-11 22:10:09.0 +0200
@@ -1 +1 @@
-5
+7
diff -Nru konwert-1.8/debian/control konwert-1.8/debian/control
--- konwert-1.8/debian/control	2016-08-15 12:03:45.0 +0300
+++ konwert-1.8/debian/control	2022-01-11 22:12:22.0 +0200
@@ -5,7 +5,7 @@
 Standards-Version: 3.6.2
 Vcs-Git: git://anonscm.debian.org/collab-maint/konwert.git
 Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/konwert.git
-Build-Depends: debhelper (>> 5), dh-buildinfo, bash-completion
+Build-Depends: debhelper (>= 7), dh-buildinfo, bash-completion
 
 Package: konwert
 Architecture: any

Bug#965662: marked as pending in libmp3-info-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #965662 in libmp3-info-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libmp3-info-perl/-/commit/0fd4fa610e25b3860e775b26101ab000e2b1f4b6


bump debhelper compatibility level to 13

Closes: #965662


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/965662

Bug#999279: swish-e: diff for NMU version 2.4.7-6.1

[Damyan Ivanov]

-=| Ludovic Drolez, 17.12.2021 16:20:53 +0100 |=-
> On Thu, Dec 16, 2021 at 07:56:50AM +0000, Damyan Ivanov wrote:
> > I've prepared an NMU for swish-e (versioned as 2.4.7-6.1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
> > 
> 
> That's perfect, thanks for your help!

Glad to be of service. Upload rescheduled to DELAYED/0 and should 
enter the archive within a day.

Cheers!
dam

Bug#999216: lpr: diff for NMU version 1:2008.05.17.3+nmu1

[Damyan Ivanov]

-=| Adam Majer, 16.12.2021 18:16:23 +0100 |=-
> On 12/16/21 9:37 AM, Damyan Ivanov wrote:
> > Dear maintainer,
> > 
> > I've prepared an NMU for lpr (versioned as 1:2008.05.17.3+nmu1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> > should delay it longer.
> > 
> > Regards.
> > 
> 
> Thank you! The upload is appreciated.

Great! Upload re-scheduled to DELAYED/0 and should enter the archive 
within a day.

-- dam

Bug#999291: xfsdump: diff for NMU version 3.1.9+0+nmu1

[Damyan Ivanov]

Control: tags 999291 + patch
Control: tags 999291 + pending

Dear maintainer,

I've prepared an NMU for xfsdump (versioned as 3.1.9+0+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru xfsdump-3.1.9+0/debian/changelog xfsdump-3.1.9+0+nmu1/debian/changelog
--- xfsdump-3.1.9+0/debian/changelog	2020-07-11 03:48:32.0 +0300
+++ xfsdump-3.1.9+0+nmu1/debian/changelog	2021-12-16 10:44:12.0 +0200
@@ -1,3 +1,11 @@
+xfsdump (3.1.9+0+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add build-arch and build-indep targets to debian/rules
+Closes: #999291
+
+ -- Damyan Ivanov   Thu, 16 Dec 2021 08:44:12 +
+
 xfsdump (3.1.9+0) unstable; urgency=medium
 
   * In postinst, create as needed the xfsdump and xfsrestore symlinks
diff -Nru xfsdump-3.1.9+0/debian/rules xfsdump-3.1.9+0+nmu1/debian/rules
--- xfsdump-3.1.9+0/debian/rules	2020-01-31 19:30:58.0 +0200
+++ xfsdump-3.1.9+0+nmu1/debian/rules	2021-12-16 10:43:03.0 +0200
@@ -12,12 +12,16 @@
 	  INSTALL_USER=root INSTALL_GROUP=root ;
 checkdir = test -f debian/rules
 
-build: built
+build: build-arch build-indep
+
+build-arch: built
 built: config
 	@echo "== dpkg-buildpackage: build" 1>&2
 	$(MAKE) default
 	touch built
 
+build-indep:
+
 config: .census
 .census:
 	@echo "== dpkg-buildpackage: configure" 1>&2

Bug#999216: lpr: diff for NMU version 1:2008.05.17.3+nmu1

[Damyan Ivanov]

Control: tags 999216 + patch
Control: tags 999216 + pending

Dear maintainer,

I've prepared an NMU for lpr (versioned as 1:2008.05.17.3+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru lpr-2008.05.17.3/debian/changelog lpr-2008.05.17.3+nmu1/debian/changelog
--- lpr-2008.05.17.3/debian/changelog	2019-01-11 22:06:54.0 +0200
+++ lpr-2008.05.17.3+nmu1/debian/changelog	2021-12-16 10:35:18.0 +0200
@@ -1,3 +1,11 @@
+lpr (1:2008.05.17.3+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add build-arch and build-indep targets to debian/rules
+(Closes: #999216)
+
+ -- Damyan Ivanov   Thu, 16 Dec 2021 08:35:18 +
+
 lpr (1:2008.05.17.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lpr-2008.05.17.3/debian/rules lpr-2008.05.17.3+nmu1/debian/rules
--- lpr-2008.05.17.3/debian/rules	2019-01-11 22:06:54.0 +0200
+++ lpr-2008.05.17.3+nmu1/debian/rules	2021-12-16 10:33:03.0 +0200
@@ -9,20 +9,24 @@
 CPPFLAGS = -Wall -g -O2 -D_GNU_SOURCE -D__KAME__ -I../common_source
 # -D_BSD_SOURCE
 
-build: build-stamp
-build-stamp:
+build: build-arch build-indep
+build-arch: build-arch-stamp
+build-arch-stamp:
 	dh_testdir
 	make -W CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)"
-	touch build-stamp
+	touch $@
+
+build-indep:
+# nothing to do here
 
 clean: 
 	dh_testdir
 	dh_testroot
-	rm -f build-stamp install-stamp
+	rm -f build-arch-stamp install-stamp
 	-make clean
 	dh_clean
 
-install: build-stamp
+install: build
 	dh_testdir
 	dh_testroot
 	dh_clean -k
@@ -69,4 +73,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#999279: swish-e: diff for NMU version 2.4.7-6.1

[Damyan Ivanov]

Control: tags 999279 + patch
Control: tags 999279 + pending

Dear maintainer,

I've prepared an NMU for swish-e (versioned as 2.4.7-6.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u swish-e-2.4.7/debian/changelog swish-e-2.4.7/debian/changelog
--- swish-e-2.4.7/debian/changelog
+++ swish-e-2.4.7/debian/changelog
@@ -1,3 +1,10 @@
+swish-e (2.4.7-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * add build-arch and build-inde targets to debian/rules (Closes: #999279)
+
+ -- Damyan Ivanov   Thu, 16 Dec 2021 07:52:44 +
+
 swish-e (2.4.7-6) unstable; urgency=medium
 
   * Fixed the zlib related build problem. Closes: #869860
diff -u swish-e-2.4.7/debian/rules swish-e-2.4.7/debian/rules
--- swish-e-2.4.7/debian/rules
+++ swish-e-2.4.7/debian/rules
@@ -26,6 +26,11 @@
 	rm -f html/search.cgi debian/files
 	rm -f SWISH-Stemmer-0.05.tar.gz
 
+build-indep:
+	# nothing
+
+build-arch: build
+
 build: build.stamp
 build.stamp:
 	dh_testdir
@@ -89,4 +94,4 @@
 
 binary-indep: build
 
-.PHONY: clean build binary binary-arch binary-indep
+.PHONY: clean build build-arch build-indep binary binary-arch binary-indep

Bug#999021: libexpect-perl: diff for NMU version 1.21-1.2

[Damyan Ivanov]

Control: tags 999021 + patch
Control: tags 999021 + pending

Dear maintainer,

I've prepared an NMU for libexpect-perl (versioned as 1.21-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.


Regards,
dam
diff -u libexpect-perl-1.21/debian/changelog libexpect-perl-1.21/debian/changelog
--- libexpect-perl-1.21/debian/changelog
+++ libexpect-perl-1.21/debian/changelog
@@ -1,3 +1,11 @@
+libexpect-perl (1.21-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Provide 'build-arch' and 'build-indep' targets in debian/rules
+Closes: #999021
+
+ -- Damyan Ivanov   Wed, 15 Dec 2021 19:58:42 +
+
 libexpect-perl (1.21-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u libexpect-perl-1.21/debian/rules libexpect-perl-1.21/debian/rules
--- libexpect-perl-1.21/debian/rules
+++ libexpect-perl-1.21/debian/rules
@@ -7,21 +7,26 @@
 TMP	=`pwd`/debian/$(PACKAGE)
 
 
-build: build-stamp
-build-stamp:
+build: build-arch build-indep
+
+build-indep: build-indep-stamp
+build-indep-stamp:
 	dh_testdir
 
 	perl Makefile.PL INSTALLDIRS=vendor
 	$(MAKE) OPTIMIZE="-O2 -g -Wall"
 
-	touch build-stamp
+	touch $@
+
+build-arch:
+	# nothing to do here
 
 realclean: clean
 
 clean:
 	dh_testdir
 	dh_testroot
-	rm -f build-stamp
+	rm -f build-indep-stamp
 
 	[ ! -f Makefile ] || $(MAKE) distclean
 
@@ -60,4 +65,4 @@
 	dh_builddeb
 
 binary: binary-indep binary-arch
-.PHONY: build clean binary-indep binary-arch binary install
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install

Bug#999127: marked as pending in libpoe-component-client-ident-perl

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #999127 in libpoe-component-client-ident-perl reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libpoe-component-client-ident-perl/-/commit/190f70d6901c1489947d7499599b3347437ff145


use debhelper 13 sequencer, wrap-and-sort, add b-d for Module-Install

Closes: #999127 -- missing build-arch and build-indep targets in
debian/rules


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/999127

Bug#986565: unusable with current git

[Damyan Ivanov]

Package: git-flow
Version: 1.12.3-2
Followup-For: Bug #986565

Control: reopen -1 1.12.3-2

Sigh. Now git reverted to using /usr/lib again, and git-flow is broken.

Reverting the changes in 1.12.3-2 would fix it.

Reading https://bugs.debian.org/985416 (the bug report in git about changing 
the path), I am left with the impression that the proper fix is to ship 
/usr/bin/git-flow. Perhaps the other scripts need to be in /usr/bin too.


HTH,
Damyan


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

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

Versions of packages git-flow depends on:
ii  git [git-core]  1:2.31.1-1
ii  git-core1:2.15.0~rc0-1

git-flow recommends no packages.

git-flow suggests no packages.

-- no debconf information

Bug#986565: unusable with current git

[Damyan Ivanov]

Package: git-flow
Version: 1.12.3-1
Severity: grave
Tags: patch

Today 'flow' is not a supported git command:

 $git flow
 git: 'flow' is not a git command. See 'git --help'.
 
 The most similar commands are
reflog
show

Running it under strace reveals that git looks for commands under 
/usr/libexec/git-core, while git-flow installs things under /usr/lib/git-core

Perhaps this is caused by a change in the search path in git and git-flow needs 
to adapt.

Replacing /usr/lib/git-core with /usr/libexec/git-core in debian/install.mk 
seems to fix the problem.


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

Kernel: Linux 5.10.0-5-amd64
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git-flow depends on:
ii  git [git-core]  1:2.31.0-1
ii  git-core1:2.15.0~rc0-1

git-flow recommends no packages.

git-flow suggests no packages.

-- debconf-show failed

Bug#975747: android/libbacktrace.so.0: undefined reference to `unwindstack::RemoteMaps::GetMapsFile[abi:cxx11]() const'

[Damyan Ivanov]

Package: android-libbacktrace
Version: 1:10.0.0+r36-1~stage1.3
Followup-For: Bug #975747

Control: affects -1 zipalign

This seems to render zipalign unusable:

 $ zipalign
 zipalign: symbol lookup error: 
 /usr/lib/x86_64-linux-gnu/android/libbacktrace.so.0: undefined symbol: 
 _ZN11unwindstack12ElfInterfaceD2Ev



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages android-libbacktrace depends on:
ii  android-libbase1:10.0.0+r36-1~stage1.3
ii  android-libcutils  1:10.0.0+r36-1~stage1.3
ii  android-liblog 1:10.0.0+r36-1~stage1.3
ii  android-libunwind  10.0.0+r36-4
ii  libc6  2.31-6
ii  libgcc-s1  10.2.1-3
ii  liblzma5   5.2.4-1+b1
ii  libstdc++6 10.2.1-3

android-libbacktrace recommends no packages.

android-libbacktrace suggests no packages.

-- no debconf information

Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

[Damyan Ivanov]

-=| Damyan Ivanov, 23.11.2020 22:16:43 +0200 |=-
> -=| Sam Hartman, 23.11.2020 10:02:34 -0500 |=-
> > Here's a patch that I believe will get libapache-mod-auth-kerb 
> > working with the latest krb5.  I'll go upload a krb5 that fixes the 
> > breaks relationship.
> > 
> > I'd appreciate it if someone who actually uses 
> > libapache-mod-auth-kerb will test this patch.
> > If it gets tested, I'll NMU.  If not, I'll ask the release team to
> > remove libapache-mod-auth-kerb from testing.
> 
> I'll try to find time to test the patch tomorrow (UTC+02).

A bit late, but I succeeded in testing the patch. Upgrading libkrb5-3 
and its dependencies to 1.18.3-4 doesn't break apache2 with 
mod-auth-kerb anymore. Moreover, the basic functionality (user 
authentication against a domain controller) works as before.

I am attaching a minimal patch, with the following changes compared to 
Sam's patch:

 - removed another instance of 'have_rcache_type' usage
 - removed all but the changes in debian/changelog, 
   debian/patches/serries and the real patch to mod_auth_kerb.c that 
   lives under debian/patches/.

I think this patch can be used for a clean NMU.

Cheers,
Damyan
diff --git a/debian/changelog b/debian/changelog
index b04ca6a..f621e17 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libapache-mod-auth-kerb (5.4-2.5) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Always assume none replay cache type is present, Closes: #975344
+
+ -- Sam Hartman   Mon, 23 Nov 2020 09:34:53 -0500
+
 libapache-mod-auth-kerb (5.4-2.4) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/0011-Always-use-NONE-replay-cache-type.patch b/debian/patches/0011-Always-use-NONE-replay-cache-type.patch
new file mode 100644
index 000..71aaf40
--- /dev/null
+++ b/debian/patches/0011-Always-use-NONE-replay-cache-type.patch
@@ -0,0 +1,73 @@
+From: Sam Hartman 
+Date: Mon, 23 Nov 2020 09:30:22 -0500
+Subject: Always use NONE replay cache type
+
+It's 2020.  Any MIT Kerberos in the wild supports the none replay
+cache type.  The previous code used an internal function to detect
+that replay cache type; that function is no longer available.
+Instead, assume it is present.
+
+An alternative would be to enable the default replay cache.  It was
+originally disabled because of problems between Microsoft
+authenticators and 2004-era MIT Kerberos 1.3.  That's probably a good
+idea.  It probably closes off security attacks, although analyzing the
+impact of replays in cases where neither channel binding nor
+per-message services are used is difficult.  I believe that a replay
+cache is not strictly necessary in the common configuration where
+mod-auth-kerb is used over a TLS-protected connection where the client
+properly verifies the TLS certificate presented by the server prior to
+sending a GSS token.
+
+I have elected not to enable replay cache to affect a minimal change.
+---
+ src/mod_auth_kerb.c | 23 +--
+ 1 file changed, 1 insertion(+), 22 deletions(-)
+
+--- a/src/mod_auth_kerb.c
 b/src/mod_auth_kerb.c
+@@ -2057,27 +2057,6 @@ kerb_authenticate_user(request_rec *r)
+return ret;
+ }
+ 
+-static int
+-have_rcache_type(const char *type)
+-{
+-   krb5_error_code ret;
+-   krb5_context context;
+-   krb5_rcache id = NULL;
+-   int found;
+-
+-   ret = krb5_init_context();
+-   if (ret)
+-  return 0;
+-
+-   ret = krb5_rc_resolve_full(context, , "none:");
+-   found = (ret == 0);
+-
+-   if (ret == 0)
+-  krb5_rc_destroy(context, id);
+-   krb5_free_context(context);
+-
+-   return found;
+-}
+ 
+ /*** 
+  Module Setup/Configuration
+@@ -2139,7 +2118,7 @@ kerb_module_init(server_rec *dummy, pool
+ #ifndef HEIMDAL
+/* Suppress the MIT replay cache.  Requires MIT Kerberos 1.4.0 or later.
+   1.3.x are covered by the hack overiding the replay calls */
+-   if (getenv("KRB5RCACHETYPE") == NULL && have_rcache_type("none"))
++   if (getenv("KRB5RCACHETYPE") == NULL )
+   putenv(strdup("KRB5RCACHETYPE=none"));
+ #endif
+ }
+@@ -2181,7 +2160,7 @@ kerb_init_handler(apr_pool_t *p, apr_poo
+ #ifndef HEIMDAL
+/* Suppress the MIT replay cache.  Requires MIT Kerberos 1.4.0 or later.
+   1.3.x are covered by the hack overiding the replay calls */
+-   if (getenv("KRB5RCACHETYPE") == NULL && have_rcache_type("none"))
++   if (getenv("KRB5RCACHETYPE") == NULL)
+   putenv(strdup("KRB5RCACHETYPE=none"));
+ #endif
+ #ifdef STANDARD20_MODULE_STUFF
diff --git a/debian/patches/series b/debian/patches/series
index d2c7173..9848ef3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -9,3 +9,4 @@ remove_bashism.patch
 gssapi_delegation.patch
 apache24.patch
 mod_auth_kerb-krb5_kt_close.patch
+0011-Always-use-NONE-replay-cache-type.patch

Bug#975344: libapache-mod-auth-kerb: Uses Internal Krb5 APIs [test this patch please]

[Damyan Ivanov]

-=| Sam Hartman, 23.11.2020 10:02:34 -0500 |=-
> Here's a patch that I believe will get libapache-mod-auth-kerb 
> working with the latest krb5.  I'll go upload a krb5 that fixes the 
> breaks relationship.

Thank you, Sam.

> I'd appreciate it if someone who actually uses 
> libapache-mod-auth-kerb will test this patch.
> If it gets tested, I'll NMU.  If not, I'll ask the release team to
> remove libapache-mod-auth-kerb from testing.

I'll try to find time to test the patch tomorrow (UTC+02).

About removing auth-kerb from testing, this may be not so bad. I see 
Fedora have removed it, with auth-gssapi as a functional replacement. 
I plan to test that too at some point.


-- Damyan

Bug#975344: libkrb5-3: ABI breakage in 1.18: krb5_rc_resolve_full missing

[Damyan Ivanov]

Package: libkrb5-3
Version: 1.18.2-1
Severity: serious
Justification: Policy 8.6.2

Hi,

libkrb5-3 version 1.18.2-1 breaks apache2 when the kerberos authentication 
module is enabled. The error message is:

 apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error 
 on line 1 of /etc/apache2/mods-enabled/auth_kerb.load: Cannot load 
 /usr/lib/apache2/modules/mod_auth_kerb.so into server: 
 /usr/lib/apache2/modules/mod_auth_kerb.so: undefined symbol: 
 krb5_rc_resolve_full, version krb5_3_MIT

The error is gone when libkrb5-3 (along with dependencies) is downgraded to 
1.17-10.

Listing symbols with nm confirms the missing symbol.

1.17-10:
 $ nm -D  /usr/lib/x86_64-linux-gnu/libkrb5.so.3   | grep krb5_rc_resolve_full
 0006a410 T krb5_rc_resolve_full@@krb5_3_MIT
 $

1.18.2-1:
 $ nm -D  /usr/lib/x86_64-linux-gnu/libkrb5.so.3   | grep krb5_rc_resolve_full
 $

I think this is the reason for the failing CI runs on ppc64el for squid¹ and 
bind9². The other architecture strangely don't fail -- probably because the 
test sets are different -- there is no 'apache2' in the passing logs.

 ¹ https://ci.debian.net/data/autopkgtest/testing/ppc64el/s/squid/8297228/log.gz
 ² https://ci.debian.net/data/autopkgtest/testing/ppc64el/b/bind9/8297196/log.gz

Removing a symbol deserves a soname bump, per Policy 8.6.2, thus the severity.

Looking at 88f4594e6a34c7b88bcd06ab06be2738113c226b in the packaging repository 
I see a lot of removed symbols.

krb5_rc_resolve_full disappears upstream with 
dcb853ac32779b173f39e19c0f24b0087de85771. I assume dependencies like 
libapache2-mod-auth-kerb will need to adapt to the changes.


Cheers,
Damyan

Bug#973118: kgb-bot: FTBFS: dh_auto_test: error: perl Build test --verbose 1 returned exit code 255

[Damyan Ivanov]

-=| Lucas Nussbaum, 27.10.2020 18:05:31 +0100 |=-
> Source: kgb-bot
> Version: 1.57-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201027 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> > …
> > #   Failed test at t/52-client-git.t line 399.
> > #  got: 'Merge branch 'allnew''
> > # expected: 'Merge branch 'allnew' into master'
> > # stopping test bot, pid 29366
> > # Removing directory /<>/t/bot
> > …

This looks like a re-occurrence of #965350 when we had:

| #   Failed test at t/52-client-git.t line 393.
| #  got: 'Merge branch 'allnew' into master'
| # expected: 'Merge branch 'allnew''

Perhaps the change in the output was reverted.

I think the idea from Jonathan to make the test more generic still 
holds. I am thinking about extending t/TestBot.pm to allow usage of 
regular expressions. The hard part would be to do this safely.

Another option would be to detect the commit message format and use 
that information in the test.

I'll look into this before 9 November (i.e. please feel free to act 
before that :) )


-- dam

Bug#971087: gnome-shell-extension-dash-to-panel: not compatible with gnome-shell 3.38

[Damyan Ivanov]

Package: gnome-shell-extension-dash-to-panel
Version: 39-1
Severity: grave
Tags: upstream patch
Justification: renders package unusable

Control: forwarded -1 
https://github.com/home-sweet-gnome/dash-to-panel/issues/1034

Hi,

With gnome-shell 3.38 entering ustable, dash-to-panel no longer loads.

This is because its metadata.json doesn't declare compatibility with shell 
3.38, but even after manually adding 3.38 to the list of supported shell 
versions, the extension fails to load with an exception:

 gnome-shell[3480]: JS ERROR: Extension dash-to-pa...@jderose9.github.com: 
TypeError: Main.overview.viewSelector.appDisplay._views is undefined
   
_init@/usr/share/gnome-shell/extensions/dash-to-pa...@jderose9.github.com/panelManager.js:67:9
   
C@/usr/share/gnome-shell/extensions/dash-to-pa...@jderose9.github.com/utils.js 
line 83 > eval:1:46
   
_enable@/usr/share/gnome-shell/extensions/dash-to-pa...@jderose9.github.com/extension.js:95:20
   
enable@/usr/share/gnome-shell/extensions/dash-to-pa...@jderose9.github.com/extension.js:65:5
   
_callExtensionEnable@resource:///org/gnome/shell/ui/extensionSystem.js:167:32
   
loadExtension@resource:///org/gnome/shell/ui/extensionSystem.js:348:26
   
_loadExtensions/<@resource:///org/gnome/shell/ui/extensionSystem.js:586:18
   
collectFromDatadirs@resource:///org/gnome/shell/misc/fileUtils.js:27:28
   
_loadExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:565:19
   
_enableAllExtensions@resource:///org/gnome/shell/ui/extensionSystem.js:595:18
   
_sessionUpdated@resource:///org/gnome/shell/ui/extensionSystem.js:626:18
   init@resource:///org/gnome/shell/ui/extensionSystem.js:56:14
   _initializeUI@resource:///org/gnome/shell/ui/main.js:269:22
   start@resource:///org/gnome/shell/ui/main.js:159:5
   @:1:47

This is reported upstream as 
https://github.com/home-sweet-gnome/dash-to-panel/issues/1034 and comments 
there claim that the master branch is fixed.


Thank you for making this lovely extension available to Debian users!

-- dam

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

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell-extension-dash-to-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gnome-shell  3.38.0-2
ii  gnome-shell-extension-prefs  3.38.0-2

gnome-shell-extension-dash-to-panel recommends no packages.

gnome-shell-extension-dash-to-panel suggests no packages.

-- no debconf information

Bug#947479: antimony: fails to start due to broken library dependency

[Damyan Ivanov]

Package: antimony
Version: 0.9.3-1+b1
Severity: grave
Justification: renders package unusable

Attempting to start antimony fails with:

$ antimony
antimony: error while loading shared libraries: libboost_python36.so.1.67.0: 
cannot open shared object file: No such file or directory


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

Versions of packages antimony depends on:
ii  libboost-python1.67.0  1.67.0-16
ii  libc6  2.29-6
ii  libgcc11:9.2.1-21
ii  libpng16-161.6.37-1
ii  libpython3.7   3.7.6-1
ii  libqt5concurrent5  5.12.5+dfsg-4
ii  libqt5core5a   5.12.5+dfsg-4
ii  libqt5gui5 5.12.5+dfsg-4
ii  libqt5network5 5.12.5+dfsg-4
ii  libqt5opengl5  5.12.5+dfsg-4
ii  libqt5widgets5 5.12.5+dfsg-4
ii  libstdc++6 9.2.1-21
ii  python33.7.5-3
ii  zlib1g 1:1.2.11.dfsg-1+b1

antimony recommends no packages.

antimony suggests no packages.

-- no debconf information

Bug#941915: FTBFS: expected '{' before 'void' in 'struct void *curlm;'

[Damyan Ivanov]

Package: libwww-curl-perl
Version: 4.17-5
Severity: serious
Tags: upstream patch ftbfs
Justification: fails to build from source (but built successfully in the past)

As seen on [1], libwww-curl-perl fails to build in current unstable. Currently 
this impedes the perl transition to 5.30.

x86_64-linux-gnu-gcc -c  -I/usr/include/x86_64-linux-gnu -D_REENTRANT 
-D_GNU_SOURCE -DDEBIAN -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include 
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   -DVERSION=\"4.17\" 
-DXS_VERSION=\"4.17\" -fPIC "-I/usr/lib/x86_64-linux-gnu/perl/5.30/CORE"   
Curl.c
Curl.xs:76:12: error: expected ‘{’ before ‘void’
   76 | struct void *curlm;
  |^~~~

The reasons seems to be that 'CURL' is defined as 'void' and 'struct CURL' is 
no longer a valid type.

The patch below seems to fix the build.

I won't be able to upload a fixed package until tomorrow, so if somebody else 
from the group has the time - please go ahead.


--- a/Curl.xs
+++ b/Curl.xs
@@ -47,7 +47,7 @@ typedef enum {
 
 typedef struct {
 /* The main curl handle */
-struct CURL *curl;
+CURL *curl;
 I32 *y;
 /* Lists that can be set via curl_easy_setopt() */
 struct curl_slist *slist[SLIST_LAST];
@@ -73,7 +73,7 @@ typedef struct {
 #ifdef __CURL_MULTI_H
 struct CURLM *curlm;
 #else
-struct void *curlm;
+void *curlm;
 #endif
 } perl_curl_multi;
 


[1] 
https://buildd.debian.org/status/fetch.php?pkg=libwww-curl-perl=amd64=4.17-5%2Bb1=1570325845=0

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), 
LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libwww-curl-perl depends on:
ii  libc6   2.29-2
ii  libcurl3-gnutls 7.66.0-1
ii  perl5.30.0-5
ii  perl-base [perlapi-5.30.0]  5.30.0-5

libwww-curl-perl recommends no packages.

Versions of packages libwww-curl-perl suggests:
pn  libcurl4-gnutls-dev  

-- debconf-show failed

Bug#912247: Bug #912247 in starman marked as pending

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #912247 in starman reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/starman/commit/8b7c67b63ea4c55cb21ad61342ee5b6fc7884d85


replace test certificates with 2048-bit ones

Closes: #912247 - FTBFS with openssl 1.1.1



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/912247

Bug#908766: Bug #908766 in liblog-dispatch-message-passing-perl marked as pending

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #908766 in liblog-dispatch-message-passing-perl reported by you has been 
fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/liblog-dispatch-message-passing-perl/commit/0ee95a4538a3fd4d77b7a092b160a23208f7ebc2


add patch adapting to the changes in Log::Dispatch 2.68

Fixes test failures and Closes: #908766



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/908766

Bug#909244: kobodeluxe not playable - immediately pauses and can't be resumed

[Damyan Ivanov]

Package: kobodeluxe
Version: 0.5.1-9
Severity: grave
Justification: renders package unusable

Trying to start a game in kobodeluxe results in a "PAUSED" game, with no 
possibility to resume it. The only way out is to press Esc and exit the game.

Steps to reproduce:
  - start kobodl
  - press shift or space three times

I tried this under gdm3/gnome3/wayland, lightdm/xfce4/Xorg and 
lightdb/openbox/Xorg so it seems to be independent of the graphical 
environment.

Also tried with a new user account without success and after removing apparmor 
and rebooting.


-- dam

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8), 
LANGUAGE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kobodeluxe depends on:
ii  kobodeluxe-data  0.5.1-9
ii  libc62.27-6
ii  libgcc1  1:8.2.0-7
ii  libsdl-image1.2  1.2.12-8
ii  libsdl1.2debian  1.2.15+dfsg2-2
ii  libstdc++6   8.2.0-7

kobodeluxe recommends no packages.

kobodeluxe suggests no packages.

-- no debconf information

Bug#908824: Bug #908824 in libnet-server-mail-perl marked as pending

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #908824 in libnet-server-mail-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libnet-server-mail-perl/commit/de7a5559c393f4df0db31990161ea8ffa8094f11


patch test certificate to use 4096-bit RSA key

Fixes tests with openssl 1.1.1 and Closes: #908824



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/908824

Bug#908824: libnet-server-mail-perl FTBFS: t/starttls.t failure

[Damyan Ivanov]

-=| Damyan Ivanov, 19.09.2018 04:55:54 + |=-
> -=| Xavier, 18.09.2018 22:58:48 +0200 |=-
> > [1]
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libnet-server-mail-perl.html)
> > [2] 
> > https://buildd.debian.org/status/package.php?p=libnet-server-mail-perl
> 
> The buildd used libio-socket-ssl-perl 2.059-1, which misses a lot of 
> openssl 1.1.1 fixes.
> 
> Perhaps bumping the (build) dependency to version 2.060-3 would help?
> 
> Hmm, the reproducible-builds log also shows 2.059-1, but I guess 
> bumping the version is still worth a try -- may be the failure is 
> hard to trigger.

That didn't work, and now I am able to make the test fail with 
a slightly different error:

t/starttls.t .. 
ok 1 - Accepted client for Test01: STARTTLS support
ok 2 - Accepted client for Test02: STARTTLS invalid parameters
ok 3 - Accepted client for Test03: STARTTLS handshake
# Error: TLS handshake failed SSL connect attempt failed error:1408F10B:SSL 
routines:ssl3_get_record:wrong version number at t/starttls.t line 117.
# kill 9, 24096 (server)
All 3 subtests passed 

Test Summary Report
---
t/starttls.t (Wstat: 9 Tests: 3 Failed: 0)
  Non-zero wait status: 9
  Parse errors: No plan found in TAP output

Looking at the test certificate, it has a 1024-bit key, which may be 
the root reason, although the error message above doesn't confirm 
that.

... and a minute later the test succeeds, after replacing 
t/certs/server-{cert,key}.pem with a senf-signed 4096-bit certificate


Will prepare a proper patch, forward it upstream and upload.


-- dam

Bug#908824: Bug #908824 in libnet-server-mail-perl marked as pending

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #908824 in libnet-server-mail-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libnet-server-mail-perl/commit/d06354cbe487096a0adf6adb5539dc044936b831


tighten libio-socket-ssl-perl (build) dependency to >= 2.060-3~

in an attempt to fix build failures

hopefully Closes: #908824



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/908824

Bug#908824: libnet-server-mail-perl FTBFS: t/starttls.t failure

[Damyan Ivanov]

-=| Xavier, 18.09.2018 22:58:48 +0200 |=-
> Le 15/09/2018 à 17:42, Damyan Ivanov a écrit :
> > Adding
> > $SIG{PIPE} = 'IGNORE';
> > at the start of the test seems to make it pass all the time.
> > 
> > I wonder if this is the correct fix.
> > 
> > -- Damyan
> 
> Hello,
> 
> I added this hook without success. "reproducible" builds well [1] but
> not buildd [2]
> 
> [1]
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libnet-server-mail-perl.html)
> [2] 
> https://buildd.debian.org/status/package.php?p=libnet-server-mail-perl

The buildd used libio-socket-ssl-perl 2.059-1, which misses a lot of 
openssl 1.1.1 fixes.

Perhaps bumping the (build) dependency to version 2.060-3 would help?

Hmm, the reproducible-builds log also shows 2.059-1, but I guess 
bumping the version is still worth a try -- may be the failure is hard 
to trigger.


-- dam

Bug#908942: libio-socket-ssl-perl: FTBFS: Connection refused at t/verify_fingerprint.t line 49 and tests hang

[Damyan Ivanov]

-=| Damyan Ivanov, 17.09.2018 05:09:09 + |=-
> -=| gregor herrmann, 17.09.2018 00:18:35 +0200 |=-
> > On Sun, 16 Sep 2018 14:42:05 +0000, Damyan Ivanov wrote:
> > 
> > > The test passes a thousand runs if the server child ignores SIGPIPE, 
> > > so this looks like the TLSv1.3 shutdown problem when the client makes 
> > > a fast SSL shutdown without waiting for the confirmation from the 
> > > server, then exits, then exits and the server sending its confirmation 
> > > gets SIGPIPEd.
> > 
> > 
> > https://rt.cpan.org/Ticket/Display.html?id=126899 also talks about
> > issues around SIGPIPE.
> > And there's a new 2.060, maybe we should try and check from there.
> 
> Oh, nice. Thanks for that notification. I was delving in internals 
> trying to avoid ignoring SIGPIPE.
> 
> Upstream seems to have gone the other way, ignoring SIGPIPE and 
> documenting the situation. It it suits them, I think it is alright :)
> 
> I'll run the test suite a hundred times and upload the new upstream 
> release.

No luck. The tests passed locally a hundred times, but two of them 
failed on the buildd 
(https://buildd.debian.org/status/fetch.php?pkg=libio-socket-ssl-perl=all=2.060-1=1537167776=0).

Wstat: 13 seems like the process was killed by SIGPIPE :(

I can reproduce this looping over the two tests for a thousand times.

I'd patch the two failing tests to ignore SIGPIPE, but I wonder if it 
would be even better to patch all the tests like that, to avoid the 
whack-a-mole game with the buildds.

-- dam

Bug#908942: libio-socket-ssl-perl: FTBFS: Connection refused at t/verify_fingerprint.t line 49 and tests hang

[Damyan Ivanov]

-=| gregor herrmann, 17.09.2018 00:18:35 +0200 |=-
> On Sun, 16 Sep 2018 14:42:05 +0000, Damyan Ivanov wrote:
> 
> > The test passes a thousand runs if the server child ignores SIGPIPE, 
> > so this looks like the TLSv1.3 shutdown problem when the client makes 
> > a fast SSL shutdown without waiting for the confirmation from the 
> > server, then exits, then exits and the server sending its confirmation 
> > gets SIGPIPEd.
> 
> 
> https://rt.cpan.org/Ticket/Display.html?id=126899 also talks about
> issues around SIGPIPE.
> And there's a new 2.060, maybe we should try and check from there.

Oh, nice. Thanks for that notification. I was delving in internals 
trying to avoid ignoring SIGPIPE.

Upstream seems to have gone the other way, ignoring SIGPIPE and 
documenting the situation. It it suits them, I think it is alright :)

I'll run the test suite a hundred times and upload the new upstream 
release.

-- dam

Bug#908942: libio-socket-ssl-perl: FTBFS: Connection refused at t/verify_fingerprint.t line 49 and tests hang

[Damyan Ivanov]

-=| Damyan Ivanov, 16.09.2018 11:44:59 + |=-
> Package: src:libio-socket-ssl-perl
> Version: 2.059-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> https://buildd.debian.org/status/fetch.php?pkg=libio-socket-ssl-perl=all=2.059-3=1537087640=0
> 
> I am able to reproduce this if I run `prove -lb 
> t/verify_fingerprint.t` several 

The test passes a thousand runs if the server child ignores SIGPIPE, 
so this looks like the TLSv1.3 shutdown problem when the client makes 
a fast SSL shutdown without waiting for the confirmation from the 
server, then exits, then exits and the server sending its confirmation 
gets SIGPIPEd.

Similar problem exhibits in t/public_suffix_ssl.t and if I add there 
an explicit ->close(SSL_fast_shutdown=>0) the test survives a thousand 
runs.

I think that when using TLS 1.3, there should be no "fast" shutdown 
and the client should always wait for the server response. Either 
that, or all the server code should ignore SIGPIPE during shutdown, 
which seems like a hard goal.


-- dam

Bug#908942: libio-socket-ssl-perl: FTBFS: Connection refused at t/verify_fingerprint.t line 49 and tests hang

[Damyan Ivanov]

Package: src:libio-socket-ssl-perl
Version: 2.059-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=libio-socket-ssl-perl=all=2.059-3=1537087640=0

I am able to reproduce this if I run `prove -lb t/verify_fingerprint.t` several 
hundred times in a row, but I can't figure out what could be wrong.

Some times the test hangs, with parent calling wait(-1) and child doing 
accept(). Some times the test fails without hanging.

The test spawns two child processes, each one listening on a random port 
(chosen by the OS). The listen() call happens before the fork(), so it seems to 
me that a later connection attempt from the parent cannot fail.

The listen queue is set to 10, and each of the children is being connected less 
than 10 times.

The child processes are designed to exit when they are connected and 
disconnected without any data being sent. Perhaps this causes one of them to 
exit before the parent does its tests, but what other process makes that 
connection is a mistery.

I'll try adding some debugging output to the children and see if this "foreigh" 
connection attempt is the reason.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU cores)
Locale: clean
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#908824: libnet-server-mail-perl FTBFS: t/starttls.t failure

[Damyan Ivanov]

-=| gregor herrmann, 14.09.2018 16:08:50 +0200 |=-
> Control: tag -1 + unreproducible
> 
> On Fri, 14 Sep 2018 16:52:38 +0300, Adrian Bunk wrote:
> 
> > Source: libnet-server-mail-perl
> > Version: 0.25-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > https://buildd.debian.org/status/fetch.php?pkg=libnet-server-mail-perl=all=0.25-1=1536904015=0
> 
> Thanks for the bug report.
>  
> > ...
> > Test Summary Report
> > ---
> > t/starttls.t (Wstat: 9 Tests: 3 Failed: 0)
> >   Non-zero wait status: 9
> >   Parse errors: No plan found in TAP output
> > Files=4, Tests=33,  2 wallclock secs ( 0.05 usr  0.04 sys +  0.67 cusr  
> > 0.20 csys =  0.96 CPU)
> > Result: FAIL
> > Failed 1/4 test programs. 0/33 subtests failed.
> > make[1]: *** [Makefile:861: test_dynamic] Error 255
> 
> Hm, the package builds for me.
> 
> 
> The buildd failure is:
> 
> # Error: TLS handshake failed SSL connect attempt failed at t/starttls.t line 
> 116.
> # kill 9, 17145 (server)
> t/starttls.t .. 
> ok 1 - Accepted client for Test01: STARTTLS support
> ok 2 - Accepted client for Test02: STARTTLS invalid parameters
> ok 3 - Accepted client for Test03: STARTTLS handshake
> All 3 subtests passed 
> 
> 
> Line 116 in the test is:
> 
>112my $rv =
>113  IO::Socket::SSL->start_SSL( $s,
>114SSL_verify_mode => 
> IO::Socket::SSL::SSL_VERIFY_NONE, );
>115
>116( defined $rv && ref $rv eq 'IO::Socket::SSL' )
>117  or die "TLS handshake failed >" . 
> IO::Socket::SSL::errstr();


Building the package several times (sbuild) passes here most of the 
time and then:

# Error: Can't call method "peerhost" on an undefined value at t/starttls.t line
 131.
# kill 9, 28330 (server)
t/starttls.t .. 
ok 1 - Accepted client for Test01: STARTTLS support
ok 2 - Accepted client for Test02: STARTTLS invalid parameters
ok 3 - Accepted client for Test03: STARTTLS handshake
All 3 subtests passed 

Adding
$SIG{PIPE} = 'IGNORE';
at the start of the test seems to make it pass all the time.

I wonder if this is the correct fix.

-- Damyan

Bug#907612: firefox: FTBFS with iso-codes 4.0-1: No such file or directory: '/usr/share/xml/iso-codes/iso_639_3.xml'

[Damyan Ivanov]

Package: src:firefox
Version: 61.0.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

Same as firefox-esr, firefox fails to build in current sid with iso-codes 
4.0-1. The failing part is:

--
debian/rules debian/control TESTDIR=
make[2]: Entering directory '/<>'
python -B debian/l10n/gen ach af an ar as ast az be bg bn-BD bn-IN br bs ca cak 
cs cy da de dsb el en-GB en-ZA eo es-AR es-CL es-ES es-MX et eu fa ff fi fr fy-N
L ga-IE gd gl gn gu-IN he hi-IN hr hsb hu hy-AM ia id is it ja ka kab kk km kn k
o lij lt lv mai mk ml mr ms my nb-NO ne-NP nl nn-NO oc or pa-IN pl pt-BR pt-PT r
m ro ru si sk sl son sq sr sv-SE ta te th tr uk ur uz vi xh zh-CN zh-TW > debian
/l10n/browser-l10n.control
Traceback (most recent call last):
  File "debian/l10n/gen", line 34, in 
parser.parse('/usr/share/xml/iso-codes/iso_639_3.xml')
  File "/usr/lib/python2.7/xml/sax/expatreader.py", line 105, in parse
source = saxutils.prepare_input_source(source)
  File "/usr/lib/python2.7/xml/sax/saxutils.py", line 349, in prepare_input_sour
ce
f = urllib.urlopen(source.getSystemId())
  File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
return opener.open(url)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 469, in open_file
return self.open_local_file(url)
  File "/usr/lib/python2.7/urllib.py", line 483, in open_local_file
raise IOError(e.errno, e.strerror, e.filename)
IOError: [Errno 2] No such file or directory: '/usr/share/xml/iso-codes/iso_639_
3.xml'
make[2]: *** [debian/rules:148: debian/l10n/browser-l10n.control] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:255: override_dh_auto_clean] Error 2
--

Фром iso-codes changelog:

* New upstream version 4.0
- This new release does no longer include the XML data files.
  Please use the JSON data files from now on.

Full build log attached. Reproducible builds also fail in sid: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/firefox.html

-- dam


firefox_amd64-2018-08-30T05:48:51Z.build.xz
Description: application/xz

Bug#907611: firefox-esr: FTBFS with iso-codes 4.0-1: No such file or directory: '/usr/share/xml/iso-codes/iso_639_3.xml'

[Damyan Ivanov]

Package: src:firefox-esr
Version: 60.1.0esr-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

As can be seen on the reproducibile builds¹, firefox-esr fails to build with 
iso-codes 4.0-1. Relevant change seems to be:

  * New upstream version 4.0
- This new release does no longer include the XML data files.
  Please use the JSON data files from now on.

The failing part is:

---
debian/rules debian/control TESTDIR=
make[2]: Entering directory '/<>'
python -B debian/l10n/gen ach af an ar as ast az be bg bn-BD bn-IN br bs ca cak
cs cy da de dsb el en-GB en-ZA eo es-AR es-CL es-ES es-MX et eu fa ff fi fr fy-N
L ga-IE gd gl gn gu-IN he hi-IN hr hsb hu hy-AM ia id is it ja ka kab kk km kn k
o lij lt lv mai mk ml mr ms my nb-NO ne-NP nl nn-NO oc or pa-IN pl pt-BR pt-PT 
rm ro ru si sk sl son sq sr sv-SE ta te th tr uk ur uz vi xh zh-CN zh-TW > 
debian/l10n/browser-l10n.control
Traceback (most recent call last):
  File "debian/l10n/gen", line 34, in 
parser.parse('/usr/share/xml/iso-codes/iso_639_3.xml')
  File "/usr/lib/python2.7/xml/sax/expatreader.py", line 105, in parse
source = saxutils.prepare_input_source(source)
  File "/usr/lib/python2.7/xml/sax/saxutils.py", line 349, in 
prepare_input_source
f = urllib.urlopen(source.getSystemId())
  File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
return opener.open(url)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 469, in open_file
return self.open_local_file(url)
  File "/usr/lib/python2.7/urllib.py", line 483, in open_local_file
raise IOError(e.errno, e.strerror, e.filename)
IOError: [Errno 2] No such file or directory: 
'/usr/share/xml/iso-codes/iso_639_3.xml'
make[2]: *** [debian/rules:150: debian/l10n/browser-l10n.control] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [debian/rules:257: override_dh_auto_clean] Error 2
---

Full build log attached.

-- dam

¹ 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/firefox-esr.html


firefox-esr_amd64-2018-08-30T05:53:32Z.build.xz
Description: application/xz

Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1

[Damyan Ivanov]

-=| Kurt Roeckx, 24.08.2018 18:52:57 +0200 |=-
> On Fri, Aug 24, 2018 at 10:27:16AM +0000, Damyan Ivanov wrote:
> > -=| Kurt Roeckx, 23.08.2018 22:32:13 +0200 |=-
> > > Note that the SIGPIPE issue is probably a known upstream issue
> > > that still needs to be fixed, we're at least still working on a
> > > SIGPIPE issue.
> > > 
> > > But that does not mean that the other issues in libnet-ssleay-perl
> > > should not get fixed.
> > 
> > I tried applying all the patches from the fedora package of 
> > Net-SSLeay, and it didn't help much.
> > 
> > It was mentioned in the upstream ticket that an additional fix is 
> > needed on libssl side, see 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1615098
> > 
> > The reproducer from there fails with 1.1.1~~pre9-1 from unstable.
> > 
> > Does this seem like something that needs to be fixed on the openssl 
> > side?
> 
> This is something that should get fixed in whatever calls
> TLSv1_method(). You should never call that function. It's also
> been deprecated.
> 
> The problem is that TLSv1_method() only supports TLS 1.0, and the
> default config now says that TLS 1.2 is the minimum verison. You
> should either use SSLv23_method() or TLS_method(), which support all
> protocol versions that are enabled.

I worked around this in Net::SSLeay by patching the routine that sets 
certificate and key to return an error condition only if any of the 
underlying routines return an error condition 
(https://salsa.debian.org/perl-team/modules/packages/libnet-ssleay-perl/blob/master/debian/patches/ok-result-is-no-error.patch).
Previously it would check the error stack and ignore the return codes.

On a more general note, the package seems ready for unstable to me. 
Reviews are welcome. If no obstacles appear, I plan to upload on late 
Sunday.


-- dam

Bug#907392: firebird3.0-utils: tables with varchar attributes with big size cannot be backed up with gbak on armel

[Damyan Ivanov]

Control: severity -1 important
Control: tags -1 upstream confirmed
Control: subject -1 firebird3.0-utils: [armel] varchar(32765) cannot be backed 
up or restored with gbak

-=| Pablo Sánchez[gmail], 27.08.2018 10:06:49 -0300 |=-
> Package: firebird3.0-utils
> Version: 3.0.3.32900.ds4-4
> Severity: grave
> Justification: renders package unusable (kind of)

Severity descriptions:

 * grave
   makes the package in question unusable or mostly so, or causes data 
   loss, or introduces a security hole allowing access to the accounts 
   of users who use the package.
 * important
   a bug which has a major effect on the usability of a package, 
   without rendering it completely unusable to everyone.

I don't think that gbak problems on armel fall in the first category.

> 1- create database, and insert on column (using raspbian)
> 
> SQL> create database '/srv/data/debian-test.fdb'
> CON> user 'SYSDBA'
> CON> password 'masterkey'
> CON> page_size 8192
> CON> default character set iso8859_1;
> SQL> commit ;
> SQL> exit ;
> 
> 2- create a table with a big size varchar and insert data into it .
> CREATE TABLE TEST
> (
>   ID INTEGER,
>   VC VARCHAR(32765)
> );
> 
> INSERT INTO TABLE1 (ID, TEXT) VALUES ('1', 'abcdef123456');
> 
> 3- backup database
> 
> root@raspberrypi:/srv/data# gbak -b -v  -user SYSDBA -password masterkey
> /srv/data/debian-test.fdb /srv/data/debian-test.fbk
> gbak:readied database /srv/data/debian-test.fdb for backup
> gbak:creating file /srv/data/debian-test.fbk
> gbak:starting transaction
> ...
> gbak:writing packages
> gbak:writing data for table TABLE1
> gbak: ERROR:message length error (encountered -32758, expected 32778)
> gbak: ERROR:gds_$receive failed
> gbak:Exiting before completion due to errors
> 
> Note that if I create db on amd64 and restore on raspberrypi, I get the
> same error .
> But if create db on amd64 and restore on amd64 there is no error and data
> is there.
> I use buster now, but on v2.5 on stretch had the same problem. After
> posting on
> firebrid-support , I was suggested to post here.

For reference, this is the thread: 
https://groups.yahoo.com/neo/groups/firebird-support/conversations/topics/132945

I can reproduce the issue on abel.debian.org (armel/buster).

No idea yet what could be the cause.


-- dam

Bug#895959: libnet-ssleay-perl: FTBFS with openssl 1.1.1

[Damyan Ivanov]

-=| Kurt Roeckx, 23.08.2018 22:32:13 +0200 |=-
> Note that the SIGPIPE issue is probably a known upstream issue
> that still needs to be fixed, we're at least still working on a
> SIGPIPE issue.
> 
> But that does not mean that the other issues in libnet-ssleay-perl
> should not get fixed.

I tried applying all the patches from the fedora package of 
Net-SSLeay, and it didn't help much.

It was mentioned in the upstream ticket that an additional fix is 
needed on libssl side, see 
https://bugzilla.redhat.com/show_bug.cgi?id=1615098

The reproducer from there fails with 1.1.1~~pre9-1 from unstable.

Does this seem like something that needs to be fixed on the openssl 
side?


-- dam

Bug#868253: Bug #868253 in libpoe-component-client-mpd-perl marked as pending

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #868253 in libpoe-component-client-mpd-perl reported by you has been fixed 
in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libpoe-component-client-mpd-perl/commit/eb6c23d030051254063baaa955244ccf3c655ce9


add patch accounting for a change in MPD protocol ('time' -> 'duration')

Closes: #868253



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/868253

Bug#906525: obexpushd: FTBFS: src/net/irobex.c:9:10: fatal error: linux/irda.h: No such file or directory

[Damyan Ivanov]

Package: obexpushd
Version: 0.11.2-1.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

obexpushd fails to build in a current amd64 sid chroot. Same can be seen in the 
reproducible-builds logs: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/obexpushd.html

  [ 80%] Building C object src/CMakeFiles/obexpushd.dir/net/irobex.c.o
  cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/cc -DDEFINITIONS 
-DHAVE_SDPLIB -DOPENOBEX_TCPOBEX=1 -DUSB_GADGET_SUPPORT -DUSE_THREADS 
-D_GNU_SOURCE -I/<>/src 
-I/<>/obj-x86_64-linux-gnu/src -I/usr/include/libusb-1.0  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c99 -O3 -DNDEBUG 
-std=c99   -o CMakeFiles/obexpushd.dir/net/irobex.c.o   -c 
/<>/src/net/irobex.c
  /<>/src/net/irobex.c:9:10: fatal error: linux/irda.h: No such 
file or directory
   #include 
^~
  compilation terminated.
  make[3]: *** [src/CMakeFiles/obexpushd.dir/build.make:339: 
src/CMakeFiles/obexpushd.dir/net/irobex.c.o] Error 1


Full build log attached.

-- dam


obexpushd_amd64-2018-08-17T11:17:49Z.build.xz
Description: application/xz

Bug#906378: Bug #906378 in libredis-perl marked as pending

[Damyan Ivanov]

Control: tag -1 pending

Hello,

Bug #906378 in libredis-perl reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:

https://salsa.debian.org/perl-team/modules/packages/libredis-perl/commit/d7b4427c5b70f574a4b6b18e345541f367e6c19e


patch t/04-pipeline.t, adapting to redis 4.0.11

Closes: #906378



(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/906378

Bug#906433: icecast2: FTBFS: aclocal-1.15: not found

[Damyan Ivanov]

Package: icecast2
Version: 2.4.3-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

Building icecast2 in a current sid chroot/amd64 fails with:

libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.in,
libtoolize: and rerunning libtoolize and aclocal.
cd . &&   aclocal-1.15 -Im4 --install --force
/bin/sh: 1: aclocal-1.15: not found
make: *** [/usr/share/cdbs/1/class/autotools-files.mk:70: 
debian/stamp-autotools-files] Error 127
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Also on reproducible-builds infrastructure: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/icecast2.html

Complete build log attached.

-- dam


icecast2_amd64-2018-08-17T14:46:42Z.build.xz
Description: application/xz

Bug#906431: haskell-stack: FTBFS: Duplicate instance declarations

[Damyan Ivanov]

Package: haskell-stack
Version: 1.6.5-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

Building haskell-stack in a current sid chroot/amd64 fails several errors like 
this:

src/test/Stack/StoreSpec.hs:54:3: error:
Duplicate instance declarations:
  instance Monad m => Serial m Int64
-- Defined at src/test/Stack/StoreSpec.hs:54:3
  instance [overlap ok] Monad m => Serial m Int64
-- Defined in `Test.SmallCheck.Series'
   |
54 | $(do let ns = [ ''Int64, ''Word64, ''Word8
   |   ...
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1

reproducible-builds also show this: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/haskell-stack.html

Complete build log attached.

-- dam


haskell-stack_amd64-2018-08-17T14:35:39Z.build.xz
Description: application/xz

Bug#906427: duplicity: FTBFS: test failure (gpg failed)

[Damyan Ivanov]

Package: duplicity
Version: 0.7.17-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

Building duplicity in a current sid/amd64 chroot fails with:

==
ERROR: test_sigchain_fileobj (testing.unit.test_collections.CollectionTest)
Test getting signature chain fileobjs from archive_dir
--
Traceback (most recent call last):
  File "/<>/testing/unit/test_collections.py", line 188, in 
test_sigchain_fileobj
self.sigchain_fileobj_check_list(self.sigchain_fileobj_get(None))
  File "/<>/testing/unit/test_collections.py", line 180, in 
sigchain_fileobj_check_list
test_fileobj(0, "Hello, world!")
  File "/<>/testing/unit/test_collections.py", line 177, in 
test_fileobj
fileobjlist[i].close()
  File "/<>/duplicity/dup_temp.py", line 227, in close
assert not self.fileobj.close()
  File "/<>/duplicity/gpg.py", line 304, in close
self.gpg_failed()
  File "/<>/duplicity/gpg.py", line 271, in gpg_failed
raise GPGError(msg)
GPGError: GPG Failed, see log below:
= Begin GnuPG log =
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
gpg: Hint: If this message was created before the year 2003 it is
likely that this message is legitimate.  This is because back
then integrity protection was not widely used.
gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
gpg: decryption forced to fail!
gpg: WARNING: unsafe permissions on homedir '/<>/testing/gnupg'
= End GnuPG log =


--
Ran 418 tests in 987.770s

FAILED (errors=1, skipped=9)
Test failed: 
error: Test failed: 
make[1]: *** [debian/rules:11: override_dh_auto_test] Error 1
==

Same is observed by reproducible builds: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/duplicity.html

Complete build log attached.


-- dam


duplicity_amd64-2018-08-17T10:52:37Z.build.xz
Description: application/xz

Bug#906426: gnuchess: FTBFS: makeinfo: command not found (missing build-dependency on texinfo)

[Damyan Ivanov]

Package: gnuchess
Version: 6.2.5-1
Severity: serious
Tags: ftbfs, patch
Justification: fails to build from source (but built successfully in the past)

Hi,

Building gnuchess in a current sid chroot fails with:


Making check in doc
make[2]: Entering directory '/<>/doc'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd . && \
rm -rf $backupdir && mkdir $backupdir && \
if (/bin/bash /<>/missing makeinfo --version) >/dev/null 2>&1; 
then \
  for f in gnuchess.info gnuchess.info-[0-9] gnuchess.info-[0-9][0-9] gnuchess.i
[0-9] gnuchess.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
cd "$am__cwd"; \
if /bin/bash /<>/missing makeinfo   -I . \
 -o gnuchess.info gnuchess.texi; \
then \
  rc=0; \
  CDPATH="${ZSH_VERSION+.}:" && cd .; \
else \
  rc=$?; \
  CDPATH="${ZSH_VERSION+.}:" && cd . && \
  $restore $backupdir/* `echo "./gnuchess.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
/<>/missing: line 81: makeinfo: command not found
WARNING: 'makeinfo' is missing on your system.
 You should only need it if you modified a '.texi' file, or
 any other file indirectly affecting the aspect of the manual.
 You might want to install the Texinfo package:
 
 The spurious makeinfo call might also be the consequence of
 using a buggy 'make' (AIX, DU, IRIX), in which case you might
 want to install GNU make:
 
make[2]: *** [Makefile:382: gnuchess.info] Error 127


Same is observed on 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gnuchess.html

Adding 'texinfo' to the build dependencies fixes the problem.

Complete build log attached.


-- dam


gnuchess_amd64-2018-08-17T10:32:23Z.build.xz
Description: application/xz

Bug#906423: parser-mysql: FTBFS: aclocal-1.15: command not found

[Damyan Ivanov]

Source: parser-mysql
Version: 10.7-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

Attempts to build parser-mysql in a current sid chroot fail:

 dh_auto_build
  make -j1
  make[1]: Entering directory '/<>'
  make  all-recursive
  make[2]: Entering directory '/<>'
  Making all in libltdl
  make[3]: Entering directory '/<>/libltdl'
  CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /<>/missing 
aclocal-1.15 -I m4
  /<>/missing: line 81: aclocal-1.15: command not found
  WARNING: 'aclocal-1.15' is missing on your system.
   You should only need it if you modified 'acinclude.m4' or
   'configure.ac' or m4 files included by 'configure.ac'.
   The 'aclocal' program is part of the GNU Automake package:
   
   It also requires GNU Autoconf, GNU m4 and Perl in order to run:
   
   
   
  make[3]: *** [Makefile:540: aclocal.m4] Error 127


Complete build log attached.


-- dam


parser-mysql_amd64-2018-08-17T12:36:39Z.build.xz
Description: application/xz

Bug#906419: lmfit-py: FTBFS: test failure

[Damyan Ivanov]

Source: lmfit-py
Version: 0.9.7+dfsg-1
Severity: serious
Justification: fails to build from source

Hi,

lmfit-py fails to build in a current sid/amd64 chroot:

==
ERROR: test_itercb.test_itercb
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/<>/.pybuild/cpython2_2.7_lmfit/build/tests/test_itercb.py", line 
24, in test_itercb
out = mod.fit(y, pars, x=x, iter_cb=per_iteration)
  File "lmfit/model.py", line 736, in fit
output.fit(data=data, weights=weights)
  File "lmfit/model.py", line 951, in fit
_ret = self.minimize(method=self.method)
  File "lmfit/minimizer.py", line 1649, in minimize
return function(**kwargs)
  File "lmfit/minimizer.py", line 1302, in leastsq
lsout = scipy_leastsq(self.__residual, vars, **lskws)
  File "/usr/lib/python2.7/dist-packages/scipy/optimize/minpack.py", line 394, 
in leastsq
gtol, maxfev, epsfcn, factor, diag)
ValueError: The array returned by a function changed size between calls

--
Ran 207 tests in 13.039s

FAILED (SKIP=2, errors=1)
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython2_2.7_lmfit/build; python2.7 -m nose tests
dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7 returned 
exit code 13

This can be also observed on reproducible-builds pages: 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lmfit-py.html


Full build log attached.

-- dam


lmfit-py_amd64-2018-08-17T08:48:30Z.build.gz
Description: application/gzip

Bug#906321: mk-configure FTBFS: bmake[3]: don't know how to make w

[Damyan Ivanov]

Package: mk-configure
Version: 0.29.1-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

mk-configure fails to build in current sid using schroot-based sbuild:

  bmake cleandir-presentation
  bmake[3]: bmake[3]: don't know how to make w. Stop

  bmake[3]: stopped in /<>
  *** [w] Error code 2

  bmake[2]: stopped in /<>
  1 error

  bmake[2]: stopped in /<>
  make[1]: *** [debian/rules:13: override_dh_auto_clean] Error 2

Full build log attached.

-- dam


mk-configure_amd64-2018-08-17T00:03:39Z.build.gz
Description: application/gzip

Bug#906320: texext: FTBFS: test failures

[Damyan Ivanov]

Source: texext
Version: 0.6-2
Severity: serious
Justification: fails to build from source

As seen on 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/texext.html
texext fails to build from source on current sid/amd64:

 15 passed, 1 warnings, 2 error in 3.88 seconds 
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython2_2.7_te
xext/build; python2.7 -m pytest
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 2.7 returned 
exit code 13
make: *** [debian/rules:5: build] Error 25

Build log attached.

-- dam


texext_amd64-2018-08-17T04:38:32Z.build.gz
Description: application/gzip

Bug#906253: linpsn: FTBFS: invalid use of incomplete type 'class QButtonGroup'

[Damyan Ivanov]

Package: src:linpsk
Version: 1.3.5-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

Taken from the attached build log:

-
g++ -c -pipe -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -D_REEN
TRANT -Wall -W -fPIC -DQT_NO_DEBUG -DWITH_HAMLIB -DQT_NO_DEBUG -DQT_WIDGETS_LIB 
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -I. -Isrc -Igui -isystem /u
sr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include
/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -isystem /usr/include/libdrm -I. 
-I/usr/lib/x86_64-linux-gnu/qt5/mksp
ecs/linux-g++ -o modemenu.o gui/modemenu.cpp
gui/modemenu.cpp: In constructor 'ModeMenu::ModeMenu(QStringList, QWidget*, 
Qt::WindowFlags)':
gui/modemenu.cpp:37:31: error: invalid use of incomplete type 'class 
QButtonGroup'
 Stopbits=new QButtonGroup(this);
   ^
In file included from 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qpushbutton.h:44,
 from /usr/include/x86_64-linux-gnu/qt5/QtWidgets/QPushButton:1,
 from ./ui_modemenu.h:18,
 from gui/modemenu.h:26,
 from gui/modemenu.cpp:22:
/usr/include/x86_64-linux-gnu/qt5/QtWidgets/qabstractbutton.h:53:7: note: 
forward declaration of 'class QButtonGroup'
 class QButtonGroup;
   ^~~~
gui/modemenu.cpp:38:9: error: invalid use of incomplete type 'class 
QButtonGroup'
 Stopbits->addButton(One,0);
 ^~
-

-- dam
sbuild (Debian sbuild) 0.77.0 (06 July 2018) on pc1.creditreform.bg

+==+
| linpsk (amd64)   Thu, 16 Aug 2018 05:30:24 + |
+==+

Package: linpsk
Distribution: sid
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid-b53f9505-1f87-44a4-90e1-7aef5fb1dc55' with 
'<>'
I: NOTICE: Log filtering will replace 'build/linpsk-BQpjkA/resolver-V4KMFF' 
with '<>'

+--+
| Update chroot|
+--+

Get:1 http://proxy:/debian sid InRelease [233 kB]
Get:2 http://proxy:/debian sid/main Sources.diff/Index [27.9 kB]
Get:3 http://proxy:/debian sid/main amd64 Packages.diff/Index [27.9 kB]
Get:4 http://proxy:/debian sid/main Sources 2018-08-15-2015.35.pdiff [6423 
B]
Get:4 http://proxy:/debian sid/main Sources 2018-08-15-2015.35.pdiff [6423 
B]
Get:5 http://proxy:/debian sid/main amd64 Packages 2018-08-15-2015.35.pdiff 
[54.5 kB]
Get:5 http://proxy:/debian sid/main amd64 Packages 2018-08-15-2015.35.pdiff 
[54.5 kB]
Fetched 349 kB in 1s (314 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Check APT
-

Checking available source versions...

Download source files with APT
--

Reading package lists...
NOTICE: 'linpsk' packaging is maintained in the 'Git' version control system at:
https://anonscm.debian.org/git/pkg-hamradio/linpsk.git
Please use:
git clone https://anonscm.debian.org/git/pkg-hamradio/linpsk.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 129 kB of source archives.
Get:1 http://proxy:/debian sid/main linpsk 1.3.5-1 (dsc) [1630 B]
Get:2 http://proxy:/debian sid/main linpsk 1.3.5-1 (tar) [122 kB]
Get:3 http://proxy:/debian sid/main linpsk 1.3.5-1 (diff) [5168 B]
Fetched 129 kB in 0s (0 B/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 'build/linpsk-BQpjkA/linpsk-1.3.5' with 
'<>'
I: NOTICE: Log filtering will replace 'build/linpsk-BQpjkA' with '<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper (>> 9), qtbase5-dev, libasound2-dev, 
libcsnd-dev, libfftw3-dev, libhamlib-dev, pkg-config, 

Bug#905761: backuppc: FTBFS with merged /usr

[Damyan Ivanov]

Package: backuppc
Version: 3.3.1-5
Severity: serious

Hi,

backuppc fails to build with merged /usr in a sbuild chroot, created with 
current debootstrap. Debootstrap enabled merged /usr since version 1.0.85, see 
https://bugs.debian.org/839046

The build fails when a patch is applied to the generated config.pl file. Since 
the path to cat is now /usr/bin/cat instead of /bin/cat, the patch fails to 
apply.

Here's the failing part of the patch:
-
@@ -224,7 +227,7 @@
 # Full path to various commands for archiving
 #
 $Conf{SplitPath} = '/usr/bin/split';
-$Conf{ParPath}   = '/usr/bin/par2';
+$Conf{ParPath}   = '/usr/bin/par2' if -x '/usr/bin/par2';
 $Conf{CatPath}   = '/bin/cat';
 $Conf{GzipPath}  = '/bin/gzip';
 $Conf{Bzip2Path} = '/bin/bzip2';
-

And here's the failing part of the build log:
--
install --mode=644 debian/apache.conf debian/backuppc/etc/backuppc
rmdir debian/backuppc/var/lib/backuppc/conf/
rmdir: failed to remove 'debian/backuppc/var/lib/backuppc/conf/': No such file o
r directory
make: [debian/rules:67: install] Error 1 (ignored)
(cd debian/backuppc/usr/share/backuppc/cgi-bin; ln -s ../image; ln -s /usr/lib/b
ackuppc/cgi-bin/index.cgi )
patch --no-backup-if-mismatch -p0 < debian/config.pl.diff
patching file debian/backuppc/etc/backuppc/config.pl
Hunk #2 FAILED at 227.
Hunk #4 succeeded at 1021 (offset -3 lines).
1 out of 7 hunks FAILED -- saving rejects to file debian/backuppc/etc/backuppc/c
onfig.pl.rej
make: *** [debian/rules:69: install] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit
status 2
-

Full build log attached.

Apparently, the official builds' chroots didn't use merged /usr when the 
package was last built (February 2018), but at some point some of them will, 
leading to inability to build backuppc on official infrastructure.

IMO, adapting the patch to the merged /usr would not work, since then the patch 
will fail on systems without merged /usr.


-- dam
sbuild (Debian sbuild) 0.77.0 (06 July 2018) on pc1.creditreform.bg

+==+
| backuppc 3.3.1-5 (amd64) Wed, 08 Aug 2018 14:22:31 + |
+==+

Package: backuppc
Version: 3.3.1-5
Source Version: 3.3.1-5
Distribution: sid
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid+exp-perl-amd64-b67b90b7-ae44-4d20-b602-62f9cb7b4d9a' 
with '<>'
I: NOTICE: Log filtering will replace 'build/backuppc-t497R0/resolver-4nL5LG' 
with '<>'

+--+
| Update chroot|
+--+

Get:1 http://proxy:/debian sid InRelease [233 kB]
Get:2 http://proxy:/debian experimental InRelease [101 kB]
Get:3 http://perl.debian.net/test-repo perl-5.28 InRelease [2871 B]
Get:4 http://proxy:/debian sid/main amd64 Packages.diff/Index [27.9 kB]
Get:5 http://proxy:/debian sid/main amd64 Packages 2018-08-04-0814.44.pdiff 
[20.5 kB]
Get:6 http://proxy:/debian sid/main amd64 Packages 2018-08-04-1411.17.pdiff 
[9739 B]
Get:7 http://proxy:/debian sid/main amd64 Packages 2018-08-04-2013.33.pdiff 
[17.8 kB]
Get:8 http://proxy:/debian sid/main amd64 Packages 2018-08-05-0209.24.pdiff 
[15.5 kB]
Get:9 http://proxy:/debian sid/main amd64 Packages 2018-08-05-0806.31.pdiff 
[2966 B]
Get:10 http://proxy:/debian sid/main amd64 Packages 
2018-08-05-1409.33.pdiff [18.0 kB]
Get:11 http://proxy:/debian sid/main amd64 Packages 
2018-08-05-2014.01.pdiff [9558 B]
Get:12 http://proxy:/debian sid/main amd64 Packages 
2018-08-06-0208.11.pdiff [4773 B]
Get:13 http://proxy:/debian sid/main amd64 Packages 
2018-08-06-0809.42.pdiff [5408 B]
Get:14 http://proxy:/debian sid/main amd64 Packages 
2018-08-06-1412.59.pdiff [16.0 kB]
Get:15 http://proxy:/debian sid/main amd64 Packages 
2018-08-06-2047.08.pdiff [31.4 kB]
Get:16 http://proxy:/debian sid/main amd64 Packages 
2018-08-07-0215.15.pdiff [9234 B]
Get:17 http://proxy:/debian sid/main amd64 Packages 
2018-08-07-0814.06.pdiff [5576 B]
Get:18 http://proxy:/debian sid/main amd64 Packages 
2018-08-07-1417.50.pdiff [17.6 kB]
Get:19 http://proxy:/debian sid/main amd64 Packages 
2018-08-07-2009.40.pdiff [13.1 kB]
Get:20 http://proxy:/debian sid/main amd64 Packages 
2018-08-08-0208.47.pdiff [4775 B]
Get:21 http://proxy:/debian sid/main amd64 Packages 
2018-08-08-0809.52.pdiff [7784 B]
Get:21 http://proxy:/debian sid/main amd64 Packages 
2018-08-08-0809.52.pdiff [7784 B]
Get:22 

Bug#905616: FTBFS: ariba/ext/minimap_ariba.cpp:15:10: fatal error: Python.h: No such file or directory

[Damyan Ivanov]

Package: src:ariba
Version: 2.12.1+ds-1
Severity: serious

ariba fails to build in a clean amd64 sid chroot:

---
building 'minimap_ariba' extension
creating build
creating build/temp.linux-amd64-3.7
creating build/temp.linux-amd64-3.7/ariba
creating build/temp.linux-amd64-3.7/ariba/ext
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
-I/usr/include/minimap -I/usr/include/python3.7m -c ariba/ext/minimap_ariba.cpp 
-o build/temp.linux-amd64-3.7/ariba/ext/minimap_ariba.o
ariba/ext/minimap_ariba.cpp:15:10: fatal error: Python.h: No such file or 
directory
 #include "Python.h"
  ^~
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
E: pybuild pybuild:338: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3.7 setup.py build
dh_auto_build: pybuild --build --test-nose -i python{version} -p "3.7 3.6" 
returned exit code 13
make: *** [debian/rules:10: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2


Full build log attached.

-- dam
sbuild (Debian sbuild) 0.77.0 (06 July 2018) on pc1.creditreform.bg

+==+
| ariba 2.12.1+ds-1 (amd64)Tue, 07 Aug 2018 08:12:52 + |
+==+

Package: ariba
Version: 2.12.1+ds-1
Source Version: 2.12.1+ds-1
Distribution: sid
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/sid-fa0d2234-8ccc-4429-af64-e6dcf305c240' with 
'<>'
I: NOTICE: Log filtering will replace 'build/ariba-HGdlhW/resolver-UgWMEb' with 
'<>'

+--+
| Update chroot|
+--+

Hit:1 http://pc1.modsoftsys.net/public sid InRelease
Get:2 http://proxy:/debian sid InRelease [233 kB]
Get:3 http://proxy:/debian sid/main amd64 Packages.diff/Index [27.9 kB]
Ign:3 http://proxy:/debian sid/main amd64 Packages.diff/Index
Get:3 http://proxy:/debian sid/main amd64 Packages.diff/Index [27.9 kB]
Ign:3 http://proxy:/debian sid/main amd64 Packages.diff/Index
Get:4 http://proxy:/debian sid/main amd64 Packages [8191 kB]
Fetched 8452 kB in 2s (5227 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages will be upgraded:
  bsdutils fdisk gcc-8-base gzip libblkid1 libfdisk1 libgcc1 libmount1
  libpcre3 libsmartcols1 libstdc++6 libuuid1 make mount patch util-linux
16 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 3814 kB of archives.
After this operation, 8192 B of additional disk space will be used.
Get:1 http://proxy:/debian sid/main amd64 bsdutils amd64 1:2.32-0.4 [117 kB]
Get:2 http://proxy:/debian sid/main amd64 gzip amd64 1.9-2 [119 kB]
Get:3 http://proxy:/debian sid/main amd64 libuuid1 amd64 2.32-0.4 [77.6 kB]
Get:4 http://proxy:/debian sid/main amd64 libblkid1 amd64 2.32-0.4 [190 kB]
Get:5 http://proxy:/debian sid/main amd64 libfdisk1 amd64 2.32-0.4 [229 kB]
Get:6 http://proxy:/debian sid/main amd64 libmount1 amd64 2.32-0.4 [201 kB]
Get:7 http://proxy:/debian sid/main amd64 libsmartcols1 amd64 2.32-0.4 [146 
kB]
Get:8 http://proxy:/debian sid/main amd64 fdisk amd64 2.32-0.4 [168 kB]
Get:9 http://proxy:/debian sid/main amd64 util-linux amd64 2.32-0.4 [974 kB]
Get:10 http://proxy:/debian sid/main amd64 mount amd64 2.32-0.4 [164 kB]
Get:11 http://proxy:/debian sid/main amd64 gcc-8-base amd64 8.2.0-3 [186 kB]
Get:12 http://proxy:/debian sid/main amd64 libstdc++6 amd64 8.2.0-3 [393 kB]
Get:13 http://proxy:/debian sid/main amd64 libgcc1 amd64 1:8.2.0-3 [40.7 kB]
Get:14 http://proxy:/debian sid/main amd64 libpcre3 amd64 2:8.39-11 [341 kB]
Get:15 http://proxy:/debian sid/main amd64 make amd64 4.2.1-1.2 [341 kB]
Get:16 http://proxy:/debian sid/main amd64 patch amd64 2.7.6-3 [126 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 3814 kB in 0s (42.6 MB/s)
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading 

Bug#905614: FTBFS: Failed test 'no warnings' with libsoftware-license-perl 0.103013-2

[Damyan Ivanov]

Package: license-reconcile
Version: 0.15
Severity: serious

license-reconcile fails to build with libsoftware-license-perl 0.103013-2 or 
later because of failing tests:

#   Failed test 'no warnings'
#   at /usr/share/perl/5.28/Test/Builder.pm line 158.
# There were 12 warning(s)
#   Previous test 0 ''
#   debian_text method is deprecated. Please use summary_or_text methodfrom 
Software::LicenseMoreUtils at t/08-licensecheck.t line 57.
#  at /usr/share/perl5/Software/License.pm line 96,  line 6.
#   
Software::License::debian_text(Software::License::Apache_2_0=HASH(0x55ba508b14c0))
 called at t/08-licensecheck.t line 57
#
...

This seems to be caused by the add-debian-text-method patch, part of 
libsoftware-license-perl since 0.103013-2.

Full build logs can be seen on 
https://ci.debian.net/packages/l/license-reconcile/


-- dam

Bug#862373: Bug#862475: The State of the YAML

[Damyan Ivanov]

-=| gregor herrmann, 18.05.2018 11:09:23 +0200 |=-
> Quick status update on the perl YAML modules and the problem of
> instantiating objects:
> 
> * libyaml-syck-perl has $YAML::LoadBlessed since a long time
> * libyaml-libyaml-perl since 0.69 and libyaml-perl since 1.25 have
>   added $YAML::LoadBlessed as well
> * all three by default set it to 1 
> 
> (and YAML::Tiny is not affected as far as I know)
> 
> So I guess we have to consider if we're happy with the ability to
> turn off loading objects and recommend it to consumers and close the
> bugs; or if we want to change the defaults, which means setting
> $YAML::LoadBlessed to 0 in all three packages.

FWIW I'd go with the second option, with a note in debian/NEWS.

For me the cost of the possible breakage (easily fixed) is less than 
the gain of protecting everyone else.

(I don't use the object instantiation functionality)


-- dam

Bug#851506: cpanminus embeds other modules in fatpacked library

[Damyan Ivanov]

-=| gregor herrmann, 09.12.2017 19:55:02 +0100 |=-
> Right, fatpacked and minimized modules are most probably a serious
> bug, and going the github-route seems sensible.
> 
> So I've done this now and pushed some rather drastic changes to our
> repo on Alioth.

Thanks!

> Please review/improve/revert before I upload.

The result is pretty impressive, eliminating both fatpacked bundled 
libraries from the cpanm script as installed by the binary package.

I just added a short note to d/watch trying to explain why the 
downloading is dome from github instead of cpan.


Cheers,
dam

Bug#883183: libdbd-firebird-perl FTBFS on i386: t/embed-rt110979.t failure

[Damyan Ivanov]

Control: tags -1 confirmed

-=| Adrian Bunk, 30.11.2017 14:06:34 +0200 |=-
> Source: libdbd-firebird-perl
> Version: 1.26-1
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=libdbd-firebird-perl=i386=1.26-1=1511985831=0

I am able to reproduce this in a (freshly created) i386 sbuild chroot.

Not really sure what is going on, the upstream changes since 1.25 
don't seem relevant.

Ah, trying 1.25-1 builds OK, but most of the tests aren't run, because 
libfbembed is not found. The "detect Firebird API version even when 
patch are supplied via environment" is relevant, because API version 
30+ is used to check whether libfbclient2 can be used in embedded 
mode.

So it seems the root bug was there with 1.25-1 too, just not triggered 
because the embedded tests weren't run.

> DBD::FirebirdEmbedded::st finish failed: Firebird error
> -invalid database handle (no active connection) at t/embed-rt110979.t line 68.
> # Tests were run but no plan was declared and done_testing() was not seen.
> # Looks like your test exited with 255 just after 7.
> t/embed-rt110979.t .. 
> ok 1 - Connected to the database
> ok 2 - Table is 'TESTAA'
> ok 3 - CREATE TABLE 'TESTAA'
> ok 4 - create generator gen_TESTAA
> ok 5 - create trigger TESTAA_bi
> ok 6 - Insert worked
> ok 7 - Autoinc PK retrieved
> Dubious, test returned 255 (wstat 65280, 0xff00)
> All 7 subtests passed 

Bug#785553: Processed: severity of 785553 is serious, tagging 785553

[Damyan Ivanov]

[added maintainer of gscan2pdf to CC. gscan2pdf is the only reverse 
dependency of libgoo-canvas-perl]

goocanvas is deprecated & replaced by goocanvas-2.0. gscan2pdf depends 
on libgoo-canvas-perl, which uses goocanvas.

Are there any plans to migrate gscanpdf away from 
libgoocanvas-perl/goocanvas to goocanvas-2.0?


-=| Debian Bug Tracking System, 26.11.2017 14:09:08 + |=-
> > severity 785553 serious
> > tags 785553 + buster sid

I tried to convince Goo::Canvas to build with libgoocanvas-2.0-dev by 
patching the search for 'goocanvas' in pkg_config to 'goocanvas-2.0' 
and adjusting the build dependency of 'libgoocanvas-dev' to 
'libgoocanvas-2.0-dev', but this fails with:

In file included from 
/usr/lib/x86_64-linux-gnu/perl5/5.26/Gtk2/Install/gtk2perl.h:45:0,
 from ./goocanvas-perl.h:8,
 from xs/goocanvas.xs:1:
/usr/lib/x86_64-linux-gnu/perl5/5.26/Gtk2/Install/gtk2perl-autogen.h:2308:11: 
error: unknown type name 'GdkRegion'
   typedef GdkRegion GdkRegion_ornull;
   ^
/usr/lib/x86_64-linux-gnu/perl5/5.26/Gtk2/Install/gtk2perl-autogen.h:2311:11: 
error: unknown type name 'GdkRegion'
   typedef GdkRegion GdkRegion_own;
   ^
/usr/lib/x86_64-linux-gnu/perl5/5.26/Gtk2/Install/gtk2perl-autogen.h:2312:11: 
error: unknown type name 'GdkRegion'
   typedef GdkRegion GdkRegion_copy;
   ^
/usr/lib/x86_64-linux-gnu/perl5/5.26/Gtk2/Install/gtk2perl-autogen.h:2313:11: 
error: unknown type name 'GdkRegion'
   typedef GdkRegion GdkRegion_own_ornull;
   ^

... and many more.

So to me trying to convert Goo::Canvas to work with goocanvas-2.0 is a dead-end.

Looking at CPAN, there is GooCanvas2, which is supposed to work with 
Gtk3 and goocanvas-2.0.

Some facts about libgoo-canvas-perl:

 Popcon: 6000 installs, 380 votes
 One reverse-dependency: gscan2pdf (1900 installs, 360 votes)


-- Damyan

Bug#881291: libdbd-sqlite3-perl FTBFS with libsqlite3-dev 3.21.0-1

[Damyan Ivanov]

Control: tag -1 confirmed upstream

-=| Adrian Bunk, 09.11.2017 20:25:17 +0200 |=-
> Source: libdbd-sqlite3-perl
> Version: 1.54-2
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libdbd-sqlite3-perl.html
> 
> ...
> Test Summary Report
> ---
> t/virtual_table/rt_99748.t  (Wstat: 512 Tests: 24 
> Failed: 1)
>   Failed test:  24
>   Non-zero exit status: 2
>   Parse errors: Bad plan.  You planned 52 tests but ran 24.
> Files=105, Tests=3555, 22 wallclock secs ( 0.81 usr  0.26 sys + 12.46 cusr  
> 1.88 csys = 15.41 CPU)
> Result: FAIL
> Failed 1/105 test programs. 1/3555 subtests failed.
> Makefile:1078: recipe for target 'test_dynamic' failed

This also falils in a current sbuild chroot:

#   Failed test 'no warnings'
#   at /usr/share/perl/5.26/Test/Builder.pm line 135.
# There were 2 warning(s)
#   Previous test 23 'SELECT rowid FROM vtb WHERE c = 'six''
#   Use of uninitialized value $op in pattern match (m//) at 
/<>/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm line 104.
#  at /<>/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm line 104.
#   
DBD::SQLite::VirtualTable::PerlData::BEST_INDEX(DBD::SQLite::VirtualTable::PerlData=HASH(0x55efd272a948),
 ARRAY(0x55efd2757f10), ARRAY(0x55efd26e8c98)) called at 
/<>/blib/lib/DBD/SQLite.pm line 202
#   DBD::SQLite::db::prepare(DBI::db=HASH(0x55efd26dc460), "SELECT a FROM 
vtb WHERE b IS NULL ORDER BY a", undef) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/DBI.pm line 1690
#   DBD::_::db::selectcol_arrayref(DBI::db=HASH(0x55efd26dc460), "SELECT a 
FROMvtb WHERE b IS NULL ORDER BY a") called at t/virtual_table/rt_99748.t line 
80
#   main::test_table(DBI::db=HASH(0x55efd26dc508), "vtb") called at 
t/virtual_table/rt_99748.t line 57
#
# --
#   Previous test 23 'SELECT rowid FROM vtb WHERE c = 'six''
#   Use of uninitialized value $op in concatenation (.) or string at 
/<>/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm line 108.
#  at /<>/blib/lib/DBD/SQLite/VirtualTable/PerlData.pm line 108.
#   
DBD::SQLite::VirtualTable::PerlData::BEST_INDEX(DBD::SQLite::VirtualTable::PerlData=HASH(0x55efd272a948),
 ARRAY(0x55efd2757f10), ARRAY(0x55efd26e8c98)) called at 
/<>/blib/lib/DBD/SQLite.pm line 202
#   DBD::SQLite::db::prepare(DBI::db=HASH(0x55efd26dc460), "SELECT a FROM 
vtb WHERE b IS NULL ORDER BY a", undef) called at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/DBI.pm line 1690
#   DBD::_::db::selectcol_arrayref(DBI::db=HASH(0x55efd26dc460), "SELECT a 
FROM vtb WHERE b IS NULL ORDER BY a") called at t/virtual_table/rt_99748.t line 
80
#   main::test_table(DBI::db=HASH(0x55efd26dc508), "vtb") called at 
t/virtual_table/rt_99748.t line 57

Some observations:

 - no similar bug report exists upstream 
   (https://rt.cpan.org/Dist/Display.html?Queue=DBD-SQLite)
 - disabling the use_system_sqlite patch works around the failure
 - applying the patch from 
   https://rt.cpan.org/Ticket/Display.html?id=114138 for guaranteed 
   usage of system sqlite3.h does not help.
 - removing the upstream sqlite3.h from debian/rules also does not 
   help

So this seems like a genuine problem with newer sqlite. Upstream's 
sqlite3.h is 3.13.0, while Debian/unstable now has 3.21.0.

-- dam

Bug#879734: deprecated upstream; drop-in replacement exists

[Damyan Ivanov]

Package: libemail-sender-transport-smtps-perl
Version: 0.03-1
Severity: serious
Tags: upstream

Email::Sender::Transport::SMTPS is deprecated upstream¹. 
Email::Sender::Transport::SMTP (part of libemail-sender-perl) can work with and 
without SSL/TLS and is a drop-in replacement.

I think we should remove libemail-sender-transport-smtps-perl from Debian.

Popcon:
  inst: 32
  vote: 6
  old: 21
  recent: 5
  no files: 0

DAK:
  coccia:~$ dak rm -n -R -s sid -m 'ROM; deprecated upstream; drop-in 
replacement exists' libemail-sender-transport-smtps-perl
  Will remove the following packages from sid:

  libemail-sender-transport-smtps-perl | 0.03-1 | source, all

  Maintainer: Debian Perl Group 

  --- Reason ---
  ROM; deprecated upstream; drop-in replacement exists
  --

  Checking reverse dependencies...
  No dependency problem found.

Filing a serious bug for now. I plan to request removal in no less than two
weeks time if no one objects.


-- dam

Bug#879733: Deprecated upstream; Email::Sender::Transport::SMTP is a replacement

[Damyan Ivanov]

Package: libemail-sender-transport-smtp-tls-perl
Version: 0.15-1
Severity: serious
Tags: upstream

Email::Sender::Transport::SMTP::TLS is deprecated upstream since 2013. 
Email::Sender::Transport::SMTP (part of libemail-sender-perl) works with and 
without SSL/TLS and is a drop-in replacement.

I think we should remove libemail-sender-transport-smtp-tls-perl from Debian.

Popcon:
 inst: 59
 vote: 18
 old: 39
 recent: 2
 no files: 0

dak:
 coccia:~$ dak rm -n -R -s sid -m 'ROM; deprecated upstream; drop-in 
replacement exists' libemail-sender-transport-smtp-tls-perl
 Will remove the following packages from sid:

 libemail-sender-transport-smtp-tls-perl | 0.15-1 | source, all

 Maintainer: Debian Perl Group 

 --- Reason ---
 ROM; deprecated upstream; drop-in replacement exists
 --

 Checking reverse dependencies...
 No dependency problem found.

Filing a serious bug for now. If no one objects, I'll request removal in no 
less than two weeks time.


-- dam

Bug#878901: dh-make-perl: FTBFS with dpkg >= 1.19: "Insecure dependency in eval while running with -T switch"

[Damyan Ivanov]

-=| Damyan Ivanov, 18.10.2017 20:20:16 + |=-
> During discussion, Matt S. Trout suggested on IRC that the check for 
> a valid package name is better written as $input =~ 
> /\A([A-Za-z]\w*(?:::\w+)*)\Z/. If no hierarchy is possible, then 
> /\A([A-Za-z]\w*/ would be enough.

I forgot an additional suggestion from Matt for replacing a big string 
eval with a much smaller one.

Here it is:

## old code
eval qq{
pop \@INC if \$INC[-1] eq '.';
require Dpkg::Vendor::$name;
\$obj = Dpkg::Vendor::$name->new();
};
unless ($@) {
$OBJECT_CACHE{$vendor} = $obj;
return $obj;
}

## new code
pop @INC if $INC[-1] eq '.';
(my $path = my $class = "Dpkg::Vendor::${name}") =~ s/\::/\//g
my $obj = eval { require "${path}.pm"; $class->new };
return $OBJECT_CACHE{$vendor} = $obj if $obj;


Cheers,
dam

Bug#878901: dh-make-perl: FTBFS with dpkg >= 1.19: "Insecure dependency in eval while running with -T switch"

[Damyan Ivanov]

-=| Guillem Jover, 17.10.2017 22:16:31 +0200 |=-
> On Tue, 2017-10-17 at 19:48:07 +0300, Niko Tyni wrote:
> > It looks like Dpkg::Vendor::get_vendor_info() contents have become
> > tainted, probably due to changes in Dpkg::Control::HashCore. It used to
> > dig the values out with regexp captures but now uses split.
> > 
> >  
> > https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?h=sid=9e5e03e9a6ddf74bb22ffc5ea8794a14a592d6b6
> > 
> > A test case is
> > 
> >   perl -T -MDpkg::Vendor=get_vendor_info -MScalar::Util=tainted -e 'die if 
> > tainted get_vendor_info()->{Vendor}'
> > 
> > which dies on libdpkg-perl 1.19.0.1 but not 1.18.24.
> > 
> > I don't know if the earlier untainting was accidental or intended.
> > Copying the dpkg maintainers.
> 
> TBH, I was not aware that anyone was running Dpkg modules in taint
> mode. And I don't think anyone has writen code for the modules with
> that in mind. I'm not sure either how much of it is taint clean, for
> example.
> 
> If people are really running this code in taint mode, I'm willing to
> discuss which parts of the API would make sense to cover or not, and
> what tradeoffs related to performance to take, etc.

I think that using taint mode wasn't justified in that one case, so 
imposing that on Dpkg::* would not be necessary.

During discussion, Matt S. Trout suggested on IRC that the check for 
a valid package name is better written as $input =~ 
/\A([A-Za-z]\w*(?:::\w+)*)\Z/. If no hierarchy is possible, then 
/\A([A-Za-z]\w*/ would be enough.

(Perhaps this belongs to the place where $name is interpreted as 
a module name, not when parsing generic label:value lines).

That may be considered nitpicking, especially without a view on the 
big picture, but I'd rather mention it here in case it is useful.

-- dam

Bug#877720: libdbd-firebird-perl: bad conversion of numerics between -1 and 0

[Damyan Ivanov]

Package: libdbd-firebird-perl
Version: 0.50
Severity: grave
Tags: upstream patch fixed-upstream
Justification: causes non-serious data loss

When fetching numeric data bwtween -1 and 0, DBD::Firebird messes with 
the conversion from the format the firebird uses to the string that is 
passed to upper layers causing data loss.

This was fixed upstream in 
https://github.com/mariuz/perl-dbd-firebird/commit/b4fad5d264abafeb26e1333b74f6a5c2f75f4869

It seems to me the non-working code was first released in version 0.50 
upstream, so every Debian release is affected.

An updated test at 
https://github.com/mariuz/perl-dbd-firebird/blob/master/t/92-bigdecimal_read.t 
demonstrates the issue.

I plan to fix this in unstable by upgrading the package to the newest 
upstream release, and probably stable by backporting the fix.


Cheers,
dam

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

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

Versions of packages libdbd-firebird-perl depends on:
ii  libc6 2.24-17
ii  libdbi-perl [perl-dbdabi-94]  1.637-1
ii  libfbclient2  3.0.2.32703.ds4-11
ii  perl  5.26.0-8
ii  perl-base [perlapi-5.26.0]5.26.0-8

libdbd-firebird-perl recommends no packages.

libdbd-firebird-perl suggests no packages.

-- no debconf information

Bug#830844: closed by Damyan Ivanov <d...@debian.org> (Bug#830844: fixed in libauthen-krb5-perl 1.9-5)

[Damyan Ivanov]

-=| Adrian Bunk, 14.05.2017 21:42:59 +0300 |=-
> On Tue, Jul 12, 2016 at 10:00:21AM +, Debian Bug Tracking System wrote:
> >...
> >[ Damyan Ivanov ]
> >* add patch removing references to obsolete krb5_{get,free}_krbhst.
> >  Thanks to Sergio Gelato. Closes: #830844
> >...
> 
> Hi Damyan,
> 
> thanks a lot for fixing this bug for stretch.
> 
> It is still present in jessie, could you also fix it there?
> Alternatively, I can fix it for jessie if you don't object.

You are more than welcome to do so.


Cheers,
dam


signature.asc
Description: PGP signature

Bug#858644: [pkg-firebird-general] Bug#858644: CVE-2017-6369: authenticated remote execution in firebird 2.5 before version 3.0.2

[Damyan Ivanov]

-=| Damyan Ivanov, 24.03.2017 19:22:53 + |=-
> Relevant upstream commits for 3.0:
>  - 
> https://github.com/FirebirdSQL/firebird/commit/8b2a9cb44bf6055e15f016d70a6842b8ada60375

Correction: the commit for 3.0 (branch B3_0_Release) is 
https://github.com/FirebirdSQL/firebird/commit/56e9a73c16803c3544076edb2d6c4ca25815e541

8b2a9cb4 is the commit in the master branch.


-- dam


signature.asc
Description: Digital signature

Bug#858644: CVE-2017-6369: authenticated remote execution in firebird 2.5 before version 3.0.2

[Damyan Ivanov]

Package: firebird3.0-server-core
Version: 3.0.1.32609.ds4-13
Severity: grave
Tags: patch upstream security
Justification: user security hole

Forwarded: http://tracker.firebirdsql.org/browse/CORE-5474

Authenticated Firebird users are allowed to declare UDFs (user-defined
functions). The default config allows using all entry points from the standard
UDF library, which is dynamically linked with libc, with its symbols
re-exported, including system().

Relevant upstream commits for 3.0:
 - 
https://github.com/FirebirdSQL/firebird/commit/8b2a9cb44bf6055e15f016d70a6842b8ada60375

Bug#858641: CVE-2017-6369: authenticated remote execution in firebird 2.5 before version 2.5.7

[Damyan Ivanov]

Package: firebird2.5-classic-common,firebird2.5-super
Version: 2.5.2.26540.ds4
Severity: grave
Tags: patch security upstream
Justification: user security hole
Forwarded: http://tracker.firebirdsql.org/browse/CORE-5474

Authenticated Firebird users are allowed to declare UDFs (user-defined 
functions). The default config allows using all entry points from the standard 
UDF library, which is dynamically linked with libc, with its symbols 
re-exported, including system().

Relevant upstream commits for 2.5:
 - 
https://github.com/FirebirdSQL/firebird/commit/9d9b9e0c94e201da489d1da81f858c570d3ca6ef
 - 
https://github.com/FirebirdSQL/firebird/commit/a802126cd501f641f00d6cda12d5d9ee3ecda6f5

Bug#856925: systray-mdstat: fails to start: Icon harddriveok.png not found at /usr/bin/systray-mdstat line 156.

[Damyan Ivanov]

Package: systray-mdstat
Version: 1.0.0-1
Severity: grave
Tags: patch

Trying to start systray-mdstat fails with:

 % systray-mdstat
 Icon harddriveok.png not found at /usr/bin/systray-mdstat line 156.

strace shows three failed attempts to open the file:

 % strace -e trace=file systray-mdstat 2>&1 |grep harddrive
 stat("share/harddriveok.png", 0x5627a78cc298) = -1 ENOENT (No such file or 
directory)
 stat("/usr/local/share/systray-mdstat/harddriveok.png", 0x5627a78cc298) = -1 
ENOENT (No such file or directory)
 stat("/usr/share/systray-mdstat/harddriveok.png", 0x5627a78cc298) = -1 ENOENT 
(No such file or directory)
 Icon harddriveok.png not found at /usr/bin/systray-mdstat line 156.

while the file is at 
/usr/share/perl5/auto/share/dist/systray-mdstat/harddriveok.png

The following patch fixes that:

---
diff --git a/bin/systray-mdstat b/bin/systray-mdstat
index e45e403..39a7428 100755
--- a/bin/systray-mdstat
+++ b/bin/systray-mdstat
@@ -90,8 +90,8 @@ my @icon_dirs = qw(
 # Unfortunately File::ShareDir functions die instead of returning
 # undef if they can't find an according directory.
 try {
-push(@icon_dirs, dist_dir('App-Systray-Mdstat'));
-}
+push(@icon_dirs, dist_dir('systray-mdstat'));
+};
 
 
 check_mdstat();
---

It does two things:
 - adds the missing semicolon after the try {} block;
 - changes the dist name from 'App-Systray-Mdstat' to 'systray-mdstat' to match 
   the location of the images as shipped in the Debian package.

Cheers,
dam


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages systray-mdstat depends on:
ii  libfile-sharedir-perl  1.102-1
ii  libgtk3-perl   0.030-1
ii  libtry-tiny-perl   0.28-1
pn  perl:any   

systray-mdstat recommends no packages.

Versions of packages systray-mdstat suggests:
ii  libgtk2-traymanager-perl  0.05-3+b3
ii  perlpanel 1:0.9.1+cvs20051225-2.1
pn  smart-notifier
ii  trayer1.1.5-1
ii  xfce4-panel   4.12.1-2

-- no debconf information

Bug#799097: mrtg-rrd: Regression after the fix for bug #787608.

[Damyan Ivanov]

-=| Adrian Bunk, 13.01.2017 17:01:15 +0200 |=-
> Damyan, can you take care of this?

Probably, but I can't do it promptly. I don't agree with the statement 
that

   defined %{$hash{key}}

is better to be replaced with

   exists $hash{key}

than with

   %{$hash{key}}

(same for defined @{$hash{key}})

I'd need to investigate what breaks, which would need time.

Perhaps somebody from the perl group (CC-ed) can take a look?

-- dam

> On Tue, Sep 15, 2015 at 11:08:53PM +0300, Vladimir Panov wrote:
> > Package: mrtg-rrd
> > Version: 0.7-5.1
> > Severity: grave
> > Tags: patch
> > Justification: renders package unusable
> > 
> > Dear Maintainer,
> > 
> > The fix for bug #787608 has left the package in an unusable state (the 
> > result of the execution of mrtg-rrd.cgi is a blank page).
> > The cause is the blind removal of the defined function. At least in 3 of 
> > the 4 instances it should be replaced with exists. I don't know about the 
> > fourth instance since I am not a Perl expert.
> > 
> > Please, see the proposed patch below. It should be applied instead of 
> > no-defined-hash-array.patch, i.e. against the original source.
> > 
> > 
> > --- a/mrtg-rrd.cgi
> > +++ b/mrtg-rrd.cgi
> > @@ -496,7 +496,7 @@ sub common_args($$$)
> >  {
> > my ($name, $target, $q) = @_;
> > 
> > -   return @{$target->{args}} if defined @{$target->{args}};
> > +   return @{$target->{args}} if exists $target->{args};
> > 
> > my $noi = 1 if $target->{options}{noi};
> > my $noo = 1 if $target->{options}{noo};
> > @@ -521,7 +521,7 @@ sub common_args($$$)
> > $target->{rrd} = $dir . '/' . $tdir . $name . '.rrd';
> > 
> > %{$target->{options}} = ()
> > -   unless defined %{$target->{options}};
> > +   unless %{$target->{options}};
> > 
> > $dir = $cfg->{workdir};
> > $dir = $cfg->{imagedir}
> > @@ -908,7 +908,7 @@ EOF
> > print $directories{$dir}{bodytag};
> > 
> > my $subdirs_printed;
> > -   if (defined @{$directories{$dir}{subdir}}) {
> > +   if (exists $directories{$dir}{subdir}) {
> > $subdirs_printed = 1;
> > print < >  MRTG subdirectories in the directory $dir1
> > @@ -921,7 +921,7 @@ EOF
> > 
> > print "\n";
> > }
> > -   if (defined @{$directories{$dir}{target}}) {
> > +   if (exists $directories{$dir}{target}) {
> > print "\n" if defined $subdirs_printed;
> > print < >  MRTG graphs in the directory $dir1
> 
> 


signature.asc
Description: Digital signature

Bug#846025: FTBFS randomly (segfaults during build)

[Damyan Ivanov]

Control: clone -1 -2
Control: retitle -2 random crashes when browsing employee.fdb during build
Control: severity -2 important
Control: close -1 3.0.1.32609.ds4-11

-=| Santiago Vila, 28.11.2016 16:11:28 +0100 |=-
> retitle 846025 firebird3.0: FTBFS randomly (segfaults during build)
> thanks
> 
> On Mon, Nov 28, 2016 at 01:50:42PM +0000, Damyan Ivanov wrote:
> 
> > Santiago, can you still reproduce the crash on current stretch?
> 
> Yes (see attach).
> 
> The failure happens randomly. I said it in the previous email but I
> forgot to put it clearly in the subject. Retitling accordingly.
> 
> If you are trying to reproduce this yourself, please try to build it a
> lot of times.

Did that for two days. One in a stretch VM (~200 attempts), the other 
in a stretch sbuild chroot on a jessie VM (~60 attempts) -- all 
successful.

Regardless, I will just make that part non fatal in -11 via ||true 
since I believe it is not indicative of a real problem.

Cloning a severity:important bug for future reference.

-- Damyan


signature.asc
Description: Digital signature

Bug#846025: firebird3.0: FTBFS (segfaults during build)

[Damyan Ivanov]

Control: tabs -1 -confirmed +moreinfo +unreproducible

-=| Damyan Ivanov, 28.11.2016 07:23:00 + |=-
> Control: tags -1 confirmed
> > tables=$( echo "show tables;" | FIREBIRD_BOOT_BUILD=true 
> > FIREBIRD=debian/firebird-image 
> > LD_LIBRARY_PATH=debian/firebird-image/lib 
> > FIREBIRD_MSG=debian/firebird-image debian/firebird-image/bin/isql 
> > -user SYSDBA debian/firebird-image/examples/empbuild/employee.fdb 
> > ) && \
> > for table in $tables; do \
> > echo "select * from $table;" | FIREBIRD_BOOT_BUILD=true 
> > FIREBIRD=debian/firebird-image 
> > LD_LIBRARY_PATH=debian/firebird-image/lib 
> > FIREBIRD_MSG=debian/firebird-image 
> > debian/firebird-image/bin/isql -user SYSDBA -e 
> > debian/firebird-image/examples/empbuild/employee.fdb ; \
> > done
> > Segmentation fault
> > debian/rules:166: recipe for target 'build-firebird-stamp' failed
> 
> Thanks. I am able to reproduce this in a stretch virtual machine.

And suddenly I am no longer able to reproduce it.

It crashed several times, then I upgraded libc libc6-bin from 2.24-5 
(stretch) to 2.24-7 (sid), which seemed to fix the crash, but 
downgrading it again didn't make the crash reappear.

So I discarded the VM and created it anew. Still, build goes on fine 
without crashes. Maybe some of the latest testing migrations (can't 
find a list) fixed it.

Santiago, can you still reproduce the crash on current stretch?


-- Damyan


signature.asc
Description: Digital signature

Bug#846025: firebird3.0: FTBFS (segfaults during build)

[Damyan Ivanov]

Control: tags -1 confirmed

-=| Santiago Vila, 27.11.2016 23:02:25 +0100 |=-
> Package: src:firebird3.0
> Version: 3.0.1.32609.ds4-10
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
> 
> tables=$( echo "show tables;" | FIREBIRD_BOOT_BUILD=true 
> FIREBIRD=debian/firebird-image 
> LD_LIBRARY_PATH=debian/firebird-image/lib 
> FIREBIRD_MSG=debian/firebird-image debian/firebird-image/bin/isql 
> -user SYSDBA debian/firebird-image/examples/empbuild/employee.fdb 
> ) && \
> for table in $tables; do \
>   echo "select * from $table;" | FIREBIRD_BOOT_BUILD=true 
> FIREBIRD=debian/firebird-image LD_LIBRARY_PATH=debian/firebird-image/lib 
> FIREBIRD_MSG=debian/firebird-image debian/firebird-image/bin/isql -user 
> SYSDBA -e debian/firebird-image/examples/empbuild/employee.fdb ; \
> done
> Segmentation fault
> debian/rules:166: recipe for target 'build-firebird-stamp' failed

Thanks. I am able to reproduce this in a stretch virtual machine.

Building in stretch chroot on sid machine passes (as well as on sid 
chroot with sid kernel -- that explains the all-green autobuilders in 
sid), so I guess the kernel version is involved in the breakage.

Next thing to try is building with upgraded build-deps from sid hoping 
that a simple bump of the build-dep will solve this. Fiddling with 
compiler flags will follow.

--
  Damyan


signature.asc
Description: Digital signature

Bug#841569: python-kinterbasdb: FTBFS: 'isc_info_db_SQL_dialect' undeclared

[Damyan Ivanov]

Control: retitle -1 python-kinterbasdb: FTBFS: 'isc_info_db_SQL_dialect' 
undeclared
Control: tags -1 +patch

> Source: python-kinterbasdb
> Version: 3.3.0-4
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161021 qa-ftbfs
> Justification: FTBFS on amd64
> …
> > In file included from _kinterbasdb.c:842:0:
> > _kinterbasdb_constants.c: In function 
> > '_init_kidb_ibase_header_constants_database_info':
> > _kinterbasdb_constants.c:267:7: error: 'isc_info_db_SQL_dialect' undeclared 
> > (first use in this function)
> >SIC(isc_info_db_SQL_dialect);

This is caused by the upgrade of firebird-dev from 2.5 to 3.0.

In 2.5, ibase.h defines both isc_info_db_SQL_dialect and 
isc_info_db_sql_dialect (with the same value of 63). In 3.0 the _SQL_ 
definition is dropped.

The fix is to replace isc_info_db_SQL_dialect with 
isc_info_db_sql_dialect in the sources of python-kinterbasdb.


-- dam


signature.asc
Description: Digital signature

Bug#840666: firebird3.0: FTBFS on powerpc, segfaults during build

[Damyan Ivanov]

-=| John Paul Adrian Glaubitz, 13.10.2016 21:30:14 +0200 |=-
> On 10/13/2016 09:29 PM, John Paul Adrian Glaubitz wrote:
> > It has to be added to the script template in build/posix/vers.sh.in. I'm
> > attaching a complete debdiff which fixes the issue for me in powerpc. I
> > have also opened two PRs upstream, these also include patches for m68k
> > and an additional patch.

Great. Thanks!

> PS: If you agree, I can NMU the fixed package using the patch I just 
> posted right away to fix the bug :).

I'll upload soon (hours) anyway because of a fix for kfreebsd.

-- Damyan


signature.asc
Description: Digital signature

Bug#840666: firebird3.0: FTBFS on powerpc, segfaults during build

[Damyan Ivanov]

-=| John Paul Adrian Glaubitz, 13.10.2016 18:35:31 +0200 |=-
> Source: firebird3.0
> Version: 3.0.1.32609.ds4-6
> Severity: serious

Shouldn't this be important instead? According to 
https://release.debian.org/stretch/arch_qualify.html powerpc is not 
a release candidate.

Of course, I am eager to find solution to the crash regardless, just 
arguing about it affecting the potential migration of firebird3.0 to 
testing.

> Tags: upstream
> Justification: fails to build from source
> User: debian-powe...@lists.debian.org
> Usertags: powerpc
> 
> firebird3.0 currently fails to build from source since the gpre
> command segfaults during build:
> 
> sh -x -c "lockfile -1 /«PKGBUILDDIR»/gen/Release/firebird/bin/build-db.lock 
> && /«PKGBUILDDIR»/gen/Release/firebird/bin/gpre_current -m -z -n 
> /«PKGBUILDDIR»/src/yvalve/blob.epp 
> /«PKGBUILDDIR»/temp/Release/yvalve/blob.cpp; res=\$?; rm -f 
> /«PKGBUILDDIR»/gen/Release/firebird/bin/build-db.lock; exit \$res"
> + lockfile -1 /«PKGBUILDDIR»/gen/Release/firebird/bin/build-db.lock
> + /«PKGBUILDDIR»/gen/Release/firebird/bin/gpre_current -m -z -n 
> /«PKGBUILDDIR»/src/yvalve/blob.epp /«PKGBUILDDIR»/temp/Release/yvalve/blob.cpp
> gpre version LI-V3.0.1.32609 Firebird 3.0
> Segmentation fault
> + res=139
> + rm -f /«PKGBUILDDIR»/gen/Release/firebird/bin/build-db.lock
> + exit 139

Hmm. I have seen this on amd64 when gcc switched to version 6. Getting 
it built required adding -std=gnu++98 -fno-lifetime-dse 
-fno-delete-null-pointer-checks -fno-strict-aliasing to the compiler 
flags. Probably unrelated.

> I have done some debugging and from the backtrace it's obvious that
> the crash occurs in glibc:
> 
> (sid_powerpc-dchroot)glaubitz@partch:~/firebird3.0-3.0.1.32609.ds4$ gdb 
> /home/glaubitz/firebird3.0-3.0.1.32609.ds4/gen/Release/firebird/bin/gpre_boot
> GNU gdb (Debian 7.11.1-2) 7.11.1
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from 
> /home/glaubitz/firebird3.0-3.0.1.32609.ds4/gen/Release/firebird/bin/gpre_boot...done.
> (gdb) run
> Starting program: 
> /home/glaubitz/firebird3.0-3.0.1.32609.ds4/gen/Release/firebird/bin/gpre_boot
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library 
> "/lib/powerpc-linux-gnu/libthread_db.so.1".
> gpre:  no source file named.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0fa79960 in _IO_wsetb () from /lib/powerpc-linux-gnu/libc.so.6
> (gdb) bt
> #0  0x0fa79960 in _IO_wsetb () from /lib/powerpc-linux-gnu/libc.so.6
> #1  0x0fa88dac in ?? () from /lib/powerpc-linux-gnu/libc.so.6
> #2  0x0fa3cd58 in ?? () from /lib/powerpc-linux-gnu/libc.so.6
> #3  0x0fa3ce30 in exit () from /lib/powerpc-linux-gnu/libc.so.6
> #4  0x10027f28 in CPR_exit (stat=263831632) at ./src/gpre/gpre.cpp:978
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)
> 
> This looks similar to the FTBFS of lua5.3 on powerpc [1] which is
> triggered by the use of a version script for the linker and, in
> fact, firebird3.0 is using such scripts. Now, this actually reminded
> me of another similar problem we had on sparc back then [2] which
> is the missing _IO_stdin_used symbol in the version script. lua5.2
> was affected by that problem as well and Aurelien Jarno fixed that
> by adding that symbol to the version script [3].

This is interesting. I was trying to debug a similar issue today on 
the mips64el porterbox. One of the command-line utilities of firebird 
produces garbage upon exit breaking a database verification at the end 
of the build process. (Build log: 
https://buildd.debian.org/status/fetch.php?pkg=firebird3.0=mips64el=3.0.1.32609.ds4-6=1476281685)
There is random garbage emitted by the firebird source preprocessor 
(gpre) which is visible earlier in the build log.
Alpha is also affected.

> I tried the fix from [3] in firebird3.0, but unfortunately it
> doesn't help. Currently, I'm out of ideas but it would be great
> to see this fixed as this also affects m68k for which I have
> added platform support to firebird upstream [4,5].

Where did you add that _IO_stdin_used entry? There are several *.vers 
files in the source. I'll try with all of them and also 
_IO_std{err,out}_used.

(15 minutes later) Oh, it helps! The invocations of gpre no longer 
dump sources. Let's see how far this goes.

-- Damyan

> > 

Bug#830844: Pending fixes for bugs in the libauthen-krb5-perl package

[Damyan Ivanov]

-=| Sergio Gelato, 12.07.2016 11:51:20 +0200 |=-
> > https://anonscm.debian.org/cgit/pkg-perl/packages/libauthen-krb5-perl.git/commit/?id=3558a41
> 
> You may have missed a documentation reference in Krb5.pm:
> ---
> =item get_krbhst(realm)
> 
> Returns a list of the Kerberos servers from the specified realm.

Oh, I missed the "PREFIX = krb5_" thing in MODULE description and 
looked only for "krb5_get_krbhst".

> ---
> which raises the issue of how much Perl code out there may call
> Authen::Krb5::get_krbhst($realm) .

None in Debian: 
https://codesearch.debian.net/search?q=get_krbhst=1

And whoever used that method in some non-packaged stuff would have 
seen the undefined symbol error already.

> As far as my own needs are concerned it's OK to drop this function,
> but it is an API change and may deserve a bump in the module's version number.
> 
> Alternatively, one could lift the implementation of krb5_get_krbhst (in terms
> of profile_get_values, which is a public interface) from older libkrb5, or
> provide a new one if there are licensing issues. Of course this is more
> work and best left to upstream.
> 
> As a stop-gap, maybe one could keep Authen::Krb5::get_krbhst but with a
> dummy implementation that always returns undef?

Latest upstream release is from 2010 and RT at 
https://rt.cpan.org/Public/Dist/Display.html?Name=Krb5 seems like it 
was never touched.

I am inclined to drop get_krbhst from the POD and move on. Yes, that 
would be API breakage, but that part of the API was already broken, 
and the patch fixes the PERL_DL_NONLAZY=1 use case so it seems like an 
improvement to me.

If an implementation using public Kerberos API appears later, amending 
would be easy. I myself don't feel qualified to write such 
implementation.

Better approaches welcome, of course. I won't rush with the POD 
removal.

Bug#789093: FTBFS: test failures

[Damyan Ivanov]

Package: libapache2-authcookie-perl
Version: 3.22-1
Severity: serious

libapache2-authcookie-perl fails to build from source in an up to date 
pbuilder:

Test Summary Report
---
t/real.t (Wstat: 10240 Tests: 49 Failed: 40)
  Failed tests:  3-26, 28-34, 39, 41-44, 46-49
  Non-zero exit status: 40
Files=3, Tests=57,  7 wallclock secs ( 0.08 usr  0.00 sys +  0.42 cusr  0.09 
csys =  0.59 CPU)
Result: FAIL
Failed 1/3 test programs. 40/57 subtests failed.


-- dam

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

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

Versions of packages libapache2-authcookie-perl depends on:
ii  libapache2-mod-perl2  2.0.9~rc2-1
ii  libautobox-perl   2.82-1+b1
ii  libclass-load-perl0.22-1
ii  perl  5.20.2-6

libapache2-authcookie-perl recommends no packages.

libapache2-authcookie-perl suggests no packages.


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

Bug#788350: FTBFS - proxy tests

[Damyan Ivanov]

Package: libfurl-perl
Version: 3.06-1
Severity: serious

libfurl fails to build in an up to date pbuilder chroot, with test failures:

...
#   Failed test at t/100_low/08_proxy.t line 42.
#  got: '1.0 pc1:51242 (HTTP::Proxy/0.303)'
# expected: '1.0 VIA!VIA!VIA!'

#   Failed test at t/100_low/08_proxy.t line 42.
#  got: '1.0 pc1:51242 (HTTP::Proxy/0.303)'
# expected: '1.0 VIA!VIA!VIA!'

#   Failed test at t/100_low/08_proxy.t line 42.
#  got: '1.0 pc1:51242 (HTTP::Proxy/0.303)'
# expected: '1.0 VIA!VIA!VIA!'
[Test::TCP] Child process does not block(PID: 21363, PPID: 21361) at 
/usr/share/perl5/Test/TCP.pm line 94.
# Looks like you failed 3 tests of 21.
...
#   Failed test at t/100_low/32_proxy_auth.t line 43.
#  got: '1.0 pc1:50219 (HTTP::Proxy/0.303)'
# expected: '1.0 VIA!VIA!VIA!'

#   Failed test at t/100_low/32_proxy_auth.t line 43.
#  got: '1.0 pc1:50219 (HTTP::Proxy/0.303)'
# expected: '1.0 VIA!VIA!VIA!'

#   Failed test at t/100_low/32_proxy_auth.t line 43.
#  got: '1.0 pc1:50219 (HTTP::Proxy/0.303)'
# expected: '1.0 VIA!VIA!VIA!'
[Test::TCP] Child process does not block(PID: 25401, PPID: 25400) at 
/usr/share/perl5/Test/TCP.pm line 94.
# Looks like you failed 3 tests of 21.
...
Test Summary Report
---
t/100_low/08_proxy.t  (Wstat: 768 Tests: 21 Failed: 3)
  Failed tests:  6, 13, 20
  Non-zero exit status: 3
t/100_low/32_proxy_auth.t (Wstat: 768 Tests: 21 Failed: 3)
  Failed tests:  6, 13, 20
  Non-zero exit status: 3
Files=49, Tests=898, 59 wallclock secs ( 0.39 usr  0.09 sys +  6.84 cusr  0.98 
csys =  8.30 CPU)
Result: FAIL
Failed 2/49 test programs. 6/898 subtests failed.
/usr/share/cdbs/1/class/perl-build.mk:70: recipe for target 
'debian/stamp-perl-check' failed


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

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


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