Bug#1006610:

[Yuta Hayashibe]

Hello,

With libwebkit2gtk-4.0-37=2.34.6-1~deb11u1, they worked fine.

Yuta Hayashibe

Bug#1007172: r-cran-pki incompatible with OpenSSL 3

[Andreas Tille]

Control: forwarded -1 Simon Urbanek 
Control: tags -1 pending

Hi Simon,

I'll upload the attached patch which also applies to the new upstream
version 0.1-10.

Kind regards

 Andreas.

Am Sat, Mar 12, 2022 at 10:37:24AM -0800 schrieb Steve Langasek:
> Package: r-cran-pki
> Version: 0.1-9-1
> Severity: serious
> Tags: patch experimental
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch
> 
> Hi Andreas,
> 
> r-cran-pki is incompatible with OpenSSL 3, which is currently in
> experimental.  This shows up as an autopkgtest failure:
> 
> [...]
> >  -- Ciphers
> info("Ciphers")
> > skey <- PKI.random(256)
> > for (cipher in c("aes256ecb", "aes256ofb", "bfcbc", "bfecb", "bfofb", 
> > "bfcfb"))
> + assert(cipher, all(PKI.decrypt(PKI.encrypt(charToRaw("foo!"), skey, 
> cipher), skey, cipher)[1:4] == charToRaw("foo!")))
>.  aes256ecb 
>.  aes256ofb 
>.  bfcbc 
> Error in PKI.encrypt(charToRaw("foo!"), skey, cipher) : 
>   error:0308010C:digital envelope routines::unsupported
> Calls: assert -> stopifnot -> PKI.decrypt -> PKI.encrypt
> Execution halted
> autopkgtest [09:48:31]: test run-unit-test: ---]
> [...]
> 
>   
> (https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/r-cran-pki/20220223_094913_a5969@/log.gz)
> 
> The issue is that r-cran-pki exposes use of various older, insecure
> algorithms which are no longer available in the default crypto provider in
> openssl, so additional steps are required in the code in order to enable use
> of these algorithms.
> 
> I've prepared the attached patch which fixes the issue, and have uploaded it
> to Ubuntu, since we are shipping OpenSSL 3 for the upcoming release.  Please
> consider including it in Debian as well (and forwarding upstream).
> 
> -- 
> Steve Langasek   Give me a lever long enough and a Free OS
> Debian Developer   to set it on, and I can move the world.
> Ubuntu Developer   https://www.debian.org/
> slanga...@ubuntu.com vor...@debian.org

> diff -Nru r-cran-pki-0.1-9/debian/patches/openssl3-compat.patch 
> r-cran-pki-0.1-9/debian/patches/openssl3-compat.patch
> --- r-cran-pki-0.1-9/debian/patches/openssl3-compat.patch 1969-12-31 
> 16:00:00.0 -0800
> +++ r-cran-pki-0.1-9/debian/patches/openssl3-compat.patch 2022-03-12 
> 00:09:19.0 -0800
> @@ -0,0 +1,85 @@
> +Description: Fix compatibility with OpenSSL 3
> + Some algorithms exposed by PKI are now 'legacy' in OpenSSL and require
> + explicit enablement.
> +Author: Steve Langasek 
> +Last-Update: 2022-03-12
> +Forwarded: no
> +
> +Index: r-cran-pki-0.1-9/src/pki.h
> +===
> +--- r-cran-pki-0.1-9.orig/src/pki.h
>  r-cran-pki-0.1-9/src/pki.h
> +@@ -20,6 +20,10 @@
> + #include 
> + #include 
> + 
> ++#if OPENSSL_VERSION_NUMBER >= 0x3000L
> ++#include 
> ++#endif
> ++
> + #if __APPLE__
> + #if defined MAC_OS_X_VERSION_10_7 && MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
> + /* use accelerated crypto on OS X instead of OpenSSL crypto */
> +Index: r-cran-pki-0.1-9/src/pki-x509.c
> +===
> +--- r-cran-pki-0.1-9.orig/src/pki-x509.c
>  r-cran-pki-0.1-9/src/pki-x509.c
> +@@ -225,6 +225,28 @@
> + static EVP_CIPHER_CTX *get_cipher(SEXP sKey, SEXP sCipher, int enc, int 
> *transient, SEXP sIV) {
> + EVP_CIPHER_CTX *ctx;
> + PKI_init();
> ++
> ++#if OPENSSL_VERSION_NUMBER >= 0x3000L
> ++static OSSL_PROVIDER *legacy_provider = NULL;
> ++static OSSL_PROVIDER *default_provider = NULL;
> ++static OSSL_LIB_CTX *ossl_ctx = NULL;
> ++
> ++if (!ossl_ctx)
> ++ossl_ctx = OSSL_LIB_CTX_new();
> ++if (!ossl_ctx)
> ++Rf_error("OSSL_LIB_CTX_new failed\n");
> ++
> ++if (!legacy_provider)
> ++legacy_provider = OSSL_PROVIDER_load(ossl_ctx, "legacy");
> ++if (!legacy_provider)
> ++Rf_error("OSSL_PROVIDER_load(legacy) failed\n");
> ++
> ++if (!default_provider)
> ++default_provider = OSSL_PROVIDER_load(ossl_ctx, "default");
> ++if (!default_provider)
> ++Rf_error("OSSL_PROVIDER_load(default) failed\n");
> ++#endif
> ++
> + if (inherits(sKey, "symmeric.cipher")) {
> + if (transient) transient[0] = 0;
> + return (EVP_CIPHER_CTX*) R_ExternalPtrAddr(sCipher);
> +@@ -265,13 +287,29 @@
> + else if (!strcmp(cipher, "aes256ofb"))
> + type = EVP_aes_256_ofb();
> + else if (!strcmp(cipher, "blowfish") || !strcmp(cipher, "bfcbc"))
> ++#if OPENSSL_VERSION_NUMBER >= 0x3000L
> ++type = EVP_CIPHER_fetch(ossl_ctx, "BF-CBC", NULL);
> ++#else
> + type = EVP_bf_cbc();
> ++#endif
> + else if (!strcmp(cipher, "bfecb"))
> ++#if OPENSSL_VERSION_NUMBER >= 0x3000L
> ++type = EVP_CIPHER_fetch(ossl_ctx, "BF-ECB", NULL);
> ++#else
> + type = EVP_bf_ecb();
> ++#endif
> + else if 

Bug#1007194: vlc: Audio Visualizations do not work.

[Andrew DeMarsh]

Please close this bug, Somehow during one of the last updates
vlc-plugin-visualization was uninstalled and I did not notice as the menu
interface doesn't grey out or disappear when the package is not availiable.

On Sun, Mar 13, 2022 at 1:57 AM Andrew DeMarsh 
wrote:

> Package: vlc
> Version: 3.0.17-1
> Severity: normal
> X-Debbugs-Cc: andrew.d...@gmail.com
>
> Dear Maintainer,
>
> When attempting to enable any of the visualizations while playing an audio
> file
> (play audio select audio menu item select visualizations and select any of
> the
> visualization options) the application stutters then does not change or
> show a
> visualization.
>
> I am not sure if this is due to a missing dependancy or a bug.
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.16.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE
> not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages vlc depends on:
> ii  vlc-bin  3.0.17-1
> ii  vlc-plugin-base  3.0.17-1
> ii  vlc-plugin-qt3.0.17-1
> ii  vlc-plugin-video-output  3.0.17-1
>
> Versions of packages vlc recommends:
> ii  vlc-l10n   3.0.17-1
> pn  vlc-plugin-access-extra
> pn  vlc-plugin-notify  
> pn  vlc-plugin-samba   
> ii  vlc-plugin-skins2  3.0.17-1
> ii  vlc-plugin-video-splitter  3.0.17-1
> pn  vlc-plugin-visualization   
>
> Versions of packages vlc suggests:
> pn  vlc-plugin-fluidsynth  
> pn  vlc-plugin-jack
> pn  vlc-plugin-svg 
>
> Versions of packages libvlc-bin depends on:
> ii  libc62.33-7
> ii  libvlc5  3.0.17-1
>
> Versions of packages libvlc5 depends on:
> ii  libc62.33-7
> ii  libvlccore9  3.0.17-1
>
> Versions of packages libvlc5 recommends:
> ii  libvlc-bin  3.0.17-1
>
> Versions of packages vlc-bin depends on:
> ii  libc6   2.33-7
> ii  libvlc-bin  3.0.17-1
> ii  libvlc5 3.0.17-1
>
> Versions of packages vlc-plugin-base depends on:
> ii  liba52-0.7.4 0.7.4-20
> ii  libarchive13 3.5.2-1
> ii  libaribb24-0 1.0.3-2
> ii  libasound2   1.2.6.1-2
> ii  libass9  1:0.15.2-1
> ii  libavahi-client3 0.8-5
> ii  libavahi-common3 0.8-5
> ii  libavc1394-0 0.5.4-5
> ii  libavcodec58 7:4.4.1-3+b2
> ii  libavformat587:4.4.1-3+b2
> ii  libavutil56  7:4.4.1-3+b2
> ii  libbluray2   1:1.3.1-1
> ii  libc62.33-7
> ii  libcairo21.16.0-5
> ii  libcddb2 1.3.2-7
> ii  libchromaprint1  1.5.1-2
> ii  libdav1d50.9.2-1+b1
> ii  libdbus-1-3  1.14.0-1
> ii  libdc1394-25 2.2.6-4
> ii  libdca0  0.0.7-2
> ii  libdvbpsi10  1.3.3-1
> ii  libdvdnav4   6.1.1-1
> ii  libdvdread8  6.1.2-1
> ii  libebml5 1.4.2-2
> ii  libfaad2 2.10.0-2
> ii  libflac8 1.3.4-1
> ii  libfontconfig1   2.13.1-4.4
> ii  libfreetype6 2.11.1+dfsg-1
> ii  libfribidi0  1.0.8-2
> ii  libgcc-s112-20220302-1
> ii  libgcrypt20  1.9.4-5
> ii  libglib2.0-0 2.70.4-1
> ii  libgnutls30  3.7.3-4+b1
> ii  libgpg-error01.43-3
> ii  libharfbuzz0b2.7.4-1
> ii  libixml101:1.8.4-2
> ii  libjpeg62-turbo  1:2.1.2-1
> ii  libkate1 0.4.1-11
> ii  liblirc-client0  0.10.1-6.3
> ii  liblua5.2-0  5.2.4-2
> ii  libmad0  0.15.1b-10
> ii  libmatroska7 1.6.3-2
> ii  libmpcdec6   2:0.1~r495-2
> ii  libmpeg2-4   0.5.1-9
> ii  libmpg123-0  1.29.3-1
> ii  libmtp9  1.1.19-1
> ii  libncursesw6 6.3-2
> ii  libnfs13 4.0.0-1
> ii  libogg0  1.3.4-0.1
> ii  libopenmpt-modplug1  0.8.9.0-openmpt1-2
> ii  libopus0 1.3.1-0.1
> ii  libpng16-16  1.6.37-3
> ii  

Bug#1005715: dahdi-linux: autopkgtest suggests breakage due to new linux kernel

[Tzafrir Cohen]

See patch in https://issues.asterisk.org/jira/browse/DAHLIN-397

-- 
mail / xmpp / matrix: tzaf...@cohens.org.il

Bug#1006333: biboumi: fail to start after libexpat1 update

[Diane Trout]

FWIW I saw a more complex patch for this issue posted here

https://lab.louiz.org/louiz/biboumi/-/commit/0061298dd0945f7f67e7fa340c6649b179c804d5

from the Biboumi XMPP muc.

I added the patch to 9.0-4 and compiled it for bullseye, and it seems
to work.

I tried connecting to oftc.net and tried using the ad-hoc commands to
try to configure some irc settings.

Bug#1007194: vlc: Audio Visualizations do not work.

[Andrew DeMarsh]

Package: vlc
Version: 3.0.17-1
Severity: normal
X-Debbugs-Cc: andrew.d...@gmail.com

Dear Maintainer,

When attempting to enable any of the visualizations while playing an audio file
(play audio select audio menu item select visualizations and select any of the
visualization options) the application stutters then does not change or show a
visualization.

I am not sure if this is due to a missing dependancy or a bug.


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

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

Versions of packages vlc depends on:
ii  vlc-bin  3.0.17-1
ii  vlc-plugin-base  3.0.17-1
ii  vlc-plugin-qt3.0.17-1
ii  vlc-plugin-video-output  3.0.17-1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.17-1
pn  vlc-plugin-access-extra
pn  vlc-plugin-notify  
pn  vlc-plugin-samba   
ii  vlc-plugin-skins2  3.0.17-1
ii  vlc-plugin-video-splitter  3.0.17-1
pn  vlc-plugin-visualization   

Versions of packages vlc suggests:
pn  vlc-plugin-fluidsynth  
pn  vlc-plugin-jack
pn  vlc-plugin-svg 

Versions of packages libvlc-bin depends on:
ii  libc62.33-7
ii  libvlc5  3.0.17-1

Versions of packages libvlc5 depends on:
ii  libc62.33-7
ii  libvlccore9  3.0.17-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.17-1

Versions of packages vlc-bin depends on:
ii  libc6   2.33-7
ii  libvlc-bin  3.0.17-1
ii  libvlc5 3.0.17-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-20
ii  libarchive13 3.5.2-1
ii  libaribb24-0 1.0.3-2
ii  libasound2   1.2.6.1-2
ii  libass9  1:0.15.2-1
ii  libavahi-client3 0.8-5
ii  libavahi-common3 0.8-5
ii  libavc1394-0 0.5.4-5
ii  libavcodec58 7:4.4.1-3+b2
ii  libavformat587:4.4.1-3+b2
ii  libavutil56  7:4.4.1-3+b2
ii  libbluray2   1:1.3.1-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libcddb2 1.3.2-7
ii  libchromaprint1  1.5.1-2
ii  libdav1d50.9.2-1+b1
ii  libdbus-1-3  1.14.0-1
ii  libdc1394-25 2.2.6-4
ii  libdca0  0.0.7-2
ii  libdvbpsi10  1.3.3-1
ii  libdvdnav4   6.1.1-1
ii  libdvdread8  6.1.2-1
ii  libebml5 1.4.2-2
ii  libfaad2 2.10.0-2
ii  libflac8 1.3.4-1
ii  libfontconfig1   2.13.1-4.4
ii  libfreetype6 2.11.1+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgcc-s112-20220302-1
ii  libgcrypt20  1.9.4-5
ii  libglib2.0-0 2.70.4-1
ii  libgnutls30  3.7.3-4+b1
ii  libgpg-error01.43-3
ii  libharfbuzz0b2.7.4-1
ii  libixml101:1.8.4-2
ii  libjpeg62-turbo  1:2.1.2-1
ii  libkate1 0.4.1-11
ii  liblirc-client0  0.10.1-6.3
ii  liblua5.2-0  5.2.4-2
ii  libmad0  0.15.1b-10
ii  libmatroska7 1.6.3-2
ii  libmpcdec6   2:0.1~r495-2
ii  libmpeg2-4   0.5.1-9
ii  libmpg123-0  1.29.3-1
ii  libmtp9  1.1.19-1
ii  libncursesw6 6.3-2
ii  libnfs13 4.0.0-1
ii  libogg0  1.3.4-0.1
ii  libopenmpt-modplug1  0.8.9.0-openmpt1-2
ii  libopus0 1.3.1-0.1
ii  libpng16-16  1.6.37-3
ii  libpostproc557:4.4.1-3+b2
ii  libprotobuf-lite23   3.12.4-1+b3
ii  libpulse015.0+dfsg1-4
ii  libraw1394-112.1.2-2
ii  libresid-builder0c2a 2.1.1-15+b1
ii  librsvg2-2   2.52.5+dfsg-3+b1
ii  libsamplerate0   0.2.2-1
ii  libsdl-image1.2  1.2.12-13+b1
ii  libsdl1.2debian  1.2.15+dfsg2-6
ii  libsecret-1-0   

Bug#1006009: fixed in libwebp 1.2.2-1

[Jeremy Bicha]

Please set the urgency to high when you do the upload to fix the new
regression. That will automatically reduce the time to migrate to testing
to 2 days since this transition has been open for several weeks now.

Thank you,
Jeremy Bicha

Bug#1007193: ganglia-webfrontend: obsolete "a2enmod php7.0" in postinst

[Jochen Kellner]

Package: ganglia-webfrontend
Version: 3.7.5+debian-3
Severity: minor

Dear Maintainer,

I've just had a look at the postinst script.

We don't have php7.0 any longer, don't we?

 23 # Auto-configure module dependencies
 24 a2enmod php7.0 || true

Thanks for your work on ganglia,
Jochen

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages ganglia-webfrontend depends on:
ii  apache2 [httpd-cgi] 2.4.52-1~deb11u2
ii  debconf [debconf-2.0]   1.5.77
ii  libapache2-mod-php  2:8.1+92+0~20220117.43+debian11~1.gbpe0d14e
ii  libapache2-mod-php7.4 [libapac  7.4.28-1+deb11u1
ii  libapache2-mod-php8.1 [libapac  8.1.3-1+0~20220223.13+debian11~1.gbp7757b9
ii  libjs-chosen1.8.7+dfsg-2
ii  libjs-d33.5.17-4
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-cookie 12-3
ii  libjs-jquery-flot   4.2.1+dfsg-5
ii  libjs-jquery-jstree 3.3.11+dfsg1-1
ii  libjs-jquery-mobile 1.4.5+dfsg-1
ii  libjs-jquery-scrollto   2.1.2+dfsg-6
ii  libjs-jquery-ui 1.12.1+dfsg-8+deb11u1
ii  libjs-jstimezonedetect  1.0.6-5
ii  libjs-moment2.29.1+ds-2
ii  libjs-moment-timezone   0.5.32+dfsg1-2+2021a
ii  libjs-rickshaw  1.5.1.dfsg-4
ii  libjs-select2.js4.0.13+dfsg1-4
ii  php 2:8.1+92+0~20220117.43+debian11~1.gbpe0d14e
ii  php-xml 2:8.1+92+0~20220117.43+debian11~1.gbpe0d14e
ii  php7.4 [php]7.4.28-1+deb11u1
ii  php7.4-xml [php-xml]7.4.28-1+deb11u1
ii  php8.1 [php]8.1.3-1+0~20220223.13+debian11~1.gbp7757b9
ii  php8.1-xml [php-xml]8.1.3-1+0~20220223.13+debian11~1.gbp7757b9
ii  rrdtool 1.7.2-3+b7

Versions of packages ganglia-webfrontend recommends:
ii  gmetad  3.7.2-4
ii  php-gd  2:8.1+92+0~20220117.43+debian11~1.gbpe0d14e
ii  php7.4-gd [php-gd]  7.4.28-1+deb11u1
ii  php8.1-gd [php-gd]  8.1.3-1+0~20220223.13+debian11~1.gbp7757b9

ganglia-webfrontend suggests no packages.

-- debconf information:
* ganglia-webfrontend/webserver: false
* ganglia-webfrontend/restart: false

Bug#1007191: featherpad hangs when opening specific file

[Killian Long]

Package: featherpad
Version: 1.0.1-0.1
Severity: normal

Dear Maintainer,

When opening a specific generated cmake file, featherpad hangs instantly in a
busy loop. The window is not redrawn when obscured. It continues to hang for up
to several minutes and must be killed with SIGKILL as it does not respond to a
normal kill.

This bug affects version 0.17.1-1 (current in Bullseye). It is resolved in
version 1.0.1-0.1 (in Testing).

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

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

Versions of packages featherpad depends on:
ii  libc62.31-13+deb11u2
ii  libgcc-s110.2.1-6
ii  libhunspell-1.7-01.7.0-3
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5printsupport5  5.15.2+dfsg-9
ii  libqt5svg5   5.15.2-3
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libqt5x11extras5 5.15.2-2
ii  libstdc++6   10.2.1-6
ii  libx11-6 2:1.7.2-1

Versions of packages featherpad recommends:
ii  featherpad-l10n  1.0.1-0.1
ii  libglib2.0-bin   2.66.8-1

featherpad suggests no packages.
# The MIT License (MIT)

# Copyright (c) 2018 JFrog

# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:

# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.

# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.



# This file comes from: https://github.com/conan-io/cmake-conan. Please refer
# to this repository for issues and documentation.

# Its purpose is to wrap and launch Conan C/C++ Package Manager when cmake is 
called.
# It will take CMake current settings (os, compiler, compiler version, 
architecture)
# and translate them to conan settings for installing and retrieving 
dependencies.

# It is intended to facilitate developers building projects that have conan 
dependencies,
# but it is only necessary on the end-user side. It is not necessary to create 
conan
# packages, in fact it shouldn't be use for that. Check the project 
documentation.

# version: 0.17.0

include(CMakeParseArguments)

function(_get_msvc_ide_version result)
set(${result} "" PARENT_SCOPE)
if(NOT MSVC_VERSION VERSION_LESS 1400 AND MSVC_VERSION VERSION_LESS 1500)
set(${result} 8 PARENT_SCOPE)
elseif(NOT MSVC_VERSION VERSION_LESS 1500 AND MSVC_VERSION VERSION_LESS 
1600)
set(${result} 9 PARENT_SCOPE)
elseif(NOT MSVC_VERSION VERSION_LESS 1600 AND MSVC_VERSION VERSION_LESS 
1700)
set(${result} 10 PARENT_SCOPE)
elseif(NOT MSVC_VERSION VERSION_LESS 1700 AND MSVC_VERSION VERSION_LESS 
1800)
set(${result} 11 PARENT_SCOPE)
elseif(NOT MSVC_VERSION VERSION_LESS 1800 AND MSVC_VERSION VERSION_LESS 
1900)
set(${result} 12 PARENT_SCOPE)
elseif(NOT MSVC_VERSION VERSION_LESS 1900 AND MSVC_VERSION VERSION_LESS 
1910)
set(${result} 14 PARENT_SCOPE)
elseif(NOT MSVC_VERSION VERSION_LESS 1910 AND MSVC_VERSION VERSION_LESS 
1920)
set(${result} 15 PARENT_SCOPE)
elseif(NOT MSVC_VERSION VERSION_LESS 1920 AND MSVC_VERSION VERSION_LESS 
1930)
set(${result} 16 PARENT_SCOPE)
elseif(NOT MSVC_VERSION VERSION_LESS 1930 AND MSVC_VERSION VERSION_LESS 
1940)
set(${result} 17 PARENT_SCOPE)
else()
message(FATAL_ERROR "Conan: Unknown MSVC compiler version 
[${MSVC_VERSION}]")
endif()
endfunction()

macro(_conan_detect_build_type)
conan_parse_arguments(${ARGV})

if(ARGUMENTS_BUILD_TYPE)
set(_CONAN_SETTING_BUILD_TYPE ${ARGUMENTS_BUILD_TYPE})
elseif(CMAKE_BUILD_TYPE)
set(_CONAN_SETTING_BUILD_TYPE ${CMAKE_BUILD_TYPE})
else()
message(FATAL_ERROR "Please specify in command line 

Bug#1007190: pulseaudio-module-gsettings: Add pipewire-pulse as alternative dependency to pulseaudio

[chris]

Package: pulseaudio-module-gsettings
Version: 15.0+dfsg1-4
Severity: normal
X-Debbugs-Cc: inkbottle...@gmail.com

Dear Maintainer,

pulseaudio-module-gsettings depends on pulseaudio and therefore conflicts with 
pipewire / wireplumber, which I use.

It seems pipewire-pulse can be used as a drop-in replacement for pulseaudio, so 
maybe the dependency on pulseaudion could be extended to pipewire-pulse.

Really I'm mimicking the following bugreport here, which looks like a similar 
issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993389

Thanks,
Chris

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

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

Versions of packages pulseaudio-module-gsettings depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.33-7
ii  libglib2.0-0 2.70.4-1
ii  libpulse015.0+dfsg1-4
pn  pulseaudio   

pulseaudio-module-gsettings recommends no packages.

pulseaudio-module-gsettings suggests no packages.

Bug#947918: gtk

[Gürkan Myczko]

> On 12 Mar 2022, at 22:06, Nilson Silva  wrote:
> 
> Hello Gürkan Myczko!
Hi Nilson
> As for the first post, I believe that Thomas would be the best person to 
> answer your questions, since I don't know the program.
> 
> When the second one replaces GTK2-dev with GTK3, and builds the binary 
> without any problems.
> 
> My question is, even building under GTK3, the program will not be able to 
> enter Debian, for the reasons exposed in the first post?
Not sure, you can try and the only hurdle I see is when gimp and remaining 
software stops using gtk2. Well could be ftp master rejects gtk2, but my guess 
for this chance is 50 %
> 
> The package is almost ready. So, tell me something so I don't waste time.
> 
Heh don‘t look at it like that. I have done plenty packaging not entering 
Debian. You trained your finger brain muscles. Keep going.
> Strong hug!
My question for help on furnace was real btw,
best
> 
> 
> Nilson F. Silva
> 
> 81-3036-0200
> 
> 81-991616348
> 
> 81-98546-9553
> 
> 
> De: Gürkan Myczko 
> Enviado: sábado, 12 de março de 2022 11:14
> Para: 947...@bugs.debian.org <947...@bugs.debian.org>
> Assunto: Bug#947918: gtk
>  
> Oh and
> 
> gtk2, although it's available, I doubt it makes sense to package new 
> things in 2022
> into Debian. I saw they have gtk3 as well, maybe try that?
> 
> Best,

Bug#1007189: searx: Searx will not run, gives a python related error

[Anonymousellama21]

Package: searx
Version: 1.0.0+dfsg1-1
Severity: important
X-Debbugs-Cc: anonymousellam...@gmail.com

Dear Maintainer,

I've just installed searx and ran "searx-run" and got the following error:
anon@anon:/$ searx-run
Traceback (most recent call last):
  File "/usr/bin/searx-run", line 33, in 
sys.exit(load_entry_point('searx==1.0.0', 'console_scripts', 'searx-run')())
  File "/usr/bin/searx-run", line 25, in importlib_load_entry_point
return next(matches).load()
  File "/usr/lib/python3.9/importlib/metadata.py", line 77, in load
module = import_module(match.group('module'))
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 972, in _find_and_load_unlocked
  File "", line 228, in _call_with_frames_removed
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/searx/__init__.py", line 27, in 
settings, settings_load_message = searx.settings_loader.load_settings()
  File "/usr/lib/python3/dist-packages/searx/settings_loader.py", line 117, in 
load_settings
return (load_yaml(default_settings_path),
  File "/usr/lib/python3/dist-packages/searx/settings_loader.py", line 24, in 
load_yaml
with open(file_name, 'r', encoding='utf-8') as settings_yaml:
TypeError: expected str, bytes or os.PathLike object, not NoneType


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages searx depends on:
ii  python33.9.8-1
ii  python3-searx  1.0.0+dfsg1-1

searx recommends no packages.

Versions of packages searx suggests:
pn  nginx 
pn  uwsgi 
pn  uwsgi-plugin-python3  

-- no debconf information

Bug#1007032: r-cran-minqa: please consider upgrading to 3.0 source format

[Dirk Eddelbuettel]

On 10 March 2022 at 22:06, Lucas Nussbaum wrote:
| Source: r-cran-minqa
| Version: 1.2.4-1
| Severity: wishlist
| Tags: bookworm sid
| Usertags: format1.0 format1.0-kp-nv
| 
| Dear maintainer,
| 
| This package is among the few (1.9%) that still use source format 1.0 in
| bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
| advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
| this contributes to standardization of packaging practices.
| 
| Please note that this is also a sign that the packaging of this software
| could maybe benefit from a refresh. It might be a good opportunity to
| look at other aspects as well.

Good call. The package simply had not 'moved' upstream in 7 1/2 years so
neither ... had I.  So now the two most recent changelog entries are as above
and it is on salsa:

  r-cran-minqa (1.2.4-2) unstable; urgency=medium

* debian/source/format: Update to '3.0 (quilt)' (closes: #1007032)
* debian/control: Switch to virtual debhelper-compat (= 11)
* debian/control: Set Build-Depends: to recent R version
* debian/control: Set Standards-Version: to current version 
* debian/control: Add Vcs-Browser: and Vcs-Git:
* debian/compat: Removed
* debian/control: Switch from cdbs to dh-r
* debian/rules: Idem
* debian/watch: Update to https
  
   -- Dirk Eddelbuettel   Sat, 12 Mar 2022 21:03:53 -0600

  r-cran-minqa (1.2.4-1) unstable; urgency=low
  
* New upstream release
  
* debian/control: Set (Build-)Depends: to current R version
* debian/control: Set Standards-Version: to current version 
  
   -- Dirk Eddelbuettel   Thu, 09 Oct 2014 11:34:40 -0500

The uploaded package will close the bug in a few minutes too.

Dirk

| 
| This mass bug filing was discussed on debian-devel@:
| https://lists.debian.org/debian-devel/2022/03/msg00074.html
| 
| Thanks
| 
| Lucas

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1007188: zsh: completion for "info -f" does not work

[Vincent Lefevre]

Package: zsh
Version: 5.8.1-1
Severity: normal

In a directory where there is a file with the .info extension:

zira% autoload -U compinit
zira% compinit
zira% info -f ./

If I type [TAB], I don't get any completion. It should complete
on the .info files (at least).

As documented:

   -f, --file=MANUAL
  specify Info manual to visit

-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----===
ii  bubblewrap   0.6.1-1  amd64utility for unprivileged chroot 
and namespace manipulation
ii  curl 7.82.0-1 amd64command line tool for 
transferring data with URL syntax
ii  dpkg-dev 1.21.1   all  Debian package development tools
ii  git-extras   6.1.0-1  all  Extra commands for git
ii  mercurial-common 6.0.2-1  all  easy-to-use, scalable 
distributed version control system (common files)
ii  meson0.61.2-1 all  high-productivity build system
ii  ninja-build  1.10.1-1 amd64small build system closest in 
spirit to Make
ii  pass 1.7.4-5  all  lightweight directory-based 
password manager
ii  pulseaudio-utils 15.0+dfsg1-4 amd64Command line tools for the 
PulseAudio sound server
ii  qpdf 10.6.2-1 amd64tools for transforming and 
inspecting PDF files
ii  systemd  250.3-2  amd64system and service manager
ii  udev 250.3-2  amd64/dev/ and hotplug management 
daemon
ii  vlc-bin  3.0.16-1+b8  amd64binaries from VLC
ii  youtube-dl   2021.12.17-1 all  downloader of videos from 
YouTube and other sites

The following files were modified:

/etc/systemd/journald.conf
/etc/systemd/logind.conf
/etc/systemd/system.conf

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh depends on:
ii  libc6   2.33-7
ii  libcap2 1:2.44-1
ii  libtinfo6   6.3-2
ii  zsh-common  5.8.1-1

Versions of packages zsh recommends:
ii  libgdbm6  1.23-1
ii  libncursesw6  6.3-2
ii  libpcre3  2:8.39-13

Versions of packages zsh suggests:
ii  zsh-doc  5.8.1-1

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1007187: O: libbs2b -- Bauer stereophonic-to-binaural DSP library

[Boyuan Yang]

Package: wnpp

See https://bugs.debian.org/1004890 .


signature.asc
Description: This is a digitally signed message part

Bug#1007186: zfs-dkms: loop devices return I/O errors

[Felix Dörre]

Package: zfs-dkms
Version: 2.1.2-1
Severity: important

Dear Maintainer,

After upgrading to kernel 5.16, reading form loop devices while using zfs 2.1.2 
always returns I/O errors:

[232395.971807] loop0: detected capacity change from 0 to 199925
[232395.972106] I/O error, dev loop0, sector 0 op 0x0:(READ) flags 0x800 
phys_seg 1 prio class 0
[232395.972121] SQUASHFS error: Failed to read block 0x0: -5
[232395.972125] unable to read squashfs_super_block

This bug was already reported and fixed upstream in January:
https://github.com/openzfs/zfs/issues/12926
https://github.com/openzfs/zfs/pull/12975

the fixes are included in the 2.1.3 release.

Please consider packaging a newer version of zfs, as having no loop devices 
strongly hinders using the system.


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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  dkms   2.8.7-2
ii  file   1:5.41-2
ii  libc6-dev [libc-dev]   2.33-7
ii  libpython3-stdlib  3.9.8-1
ii  lsb-release11.1.0
ii  perl   5.34.0-3
ii  python3-distutils  3.9.10-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  5.16.11-1
ii  zfs-zed 2.1.2-1
ii  zfsutils-linux  2.1.2-1

Versions of packages zfs-dkms suggests:
ii  debhelper  13.6

-- debconf information excluded

Bug#1007185: btrfsmaintenance: reproducible builds: Timestamp embedded in manpage

[Nicholas D Steeves]

Hi Vagrant!

Vagrant Cascadian  writes:

> Source: btrfsmaintenance
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: timestamps locale
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>
> The build timestamp is embedded in
> /usr/share/man/man8/btrfsmaintenance.8.gz:
>
>   
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/btrfsmaintenance.html
>
>   .TH·BTRFSMAINTENANCE·8·"12·March,·2022"·v0.5
>   vs.
>   .TH·BTRFSMAINTENANCE·8·"13·March,·2022"·v0.5
>
> The attached patch fixes this by passing the --utc argument to date in
> debian/create-man-page.sh and by using a locale-independent date format.
>
>
> With this patch applied, btrfsmaintenance should build reproducibly on
> tests.reproducible-builds.org!
>

Wow!  Thank you for catching this so quickly, and for submitting a
patch, and sorry I missed this.  By the way, are ISO 8601 dates in man
pages a goal in Debian?  I noted GNU man pages use "%B %d, %Y", and
chose the more international little endian long-form.  There's no
problem changing to ISO 8601 as you suggest, I'm just curious.

>
> Thanks for maintaining btrfsmaintenance!

You're welcome :-)

On a tangential topic, what would you recommend for making shell scripts
such as btrfsmaintenance aware of plug/unplug (alternatively off battery
vs on battery) state, to suspend and resume CPU and IO intensive
operations, and without falling back to polling?  UPower, to cover both
laptops and servers that have a UPS?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Simon McVittie]

On Sat, 12 Mar 2022 at 20:56:38 +, Brian Potkin wrote:
> I wouldn't see libgtk as providing a fallbac. Why would a fallback be
> needed when the printing system does the jobi, as you have demonstrated?

cups upstream's medium to long term plan seems to be that toolkits like
GTK and Qt should browse for mDNS printers themselves, and cups-browsed
will eventually disappear, so that the only print queues shown are the
ones manually configured in cups and the ones auto-discovered by the
toolkits' print dialogs:

The intention of CUPS upstream is that the application's print dialogs
browse the Bonjour broadcasts as an AirPrint-capable iPhone does,
but it will take its time until all toolkit developers add the needed
functionality, and programs using old toolkits or no toolkits at all,
or the command line stay uncovered.
— https://github.com/OpenPrinting/cups-filters

In bullseye, cups-browsed is usually installed on desktop systems. The
intention seems to be that the printers discovered by cups-browsed take
precedence over the ones discovered by GTK, but in current bullseye this
doesn't work reliably, and instead both sets appear as near-duplicates
(see below).

In bullseye, if you print to the entries generated by GTK from mDNS,
then GTK will submits a PDF via IPP directly to the printer, bypassing
cups (and that doesn't always work, as seen here). In the implementation
in bookworm, backported here as the versions with ~mr6 or ~mr6.1 in
their names, GTK's fallback entries are implemented by asking the local
instance of cups to set up a temporary print queue, and then submitting
the job via IPP to that temporary queue, which seems to be more reliable
in practice.

So, if you think cups is always going to be better at IPP than GTK is,
I hope you would agree that the ~mr6 or ~mr6.1 versions, which make more
use of cups than the version currently in bullseye, are a better answer
than what GTK in bullseye is currently doing?

If the response to asking for testing of possible improvements is going
to be people characterizing GTK as irretrievably inept, then that is
not going to help me to find the time and motivation to work on making
things better (the opposite, in fact).

In particular, if the changes I'm proposing are bringing GTK closer to
what you want, which I think they are, then it seems counterproductive to
discourage me from making them. Conversely, if you think these changes are
wrong, please focus on proposing solutions rather than ascribing blame:
that's a much more effective way to motivate volunteers to do as you ask.

> If I set up a manual destination, I would be extremely annoyed if it was
> interfered with.

I believe the intention is that if there is a manually-configured queue,
then any automatically-discovered entries that can be identified as being
the same printer are ignored.

Also, if there is no manually-configured queue, but there is an
automatically-discovered entry from cups-browsed, then the intention
is that GTK uses that one, and any entries discovered by GTK that can
be identified as the same printer are ignored. So as far as I can
tell, it's aiming to do what you want: manual configuration "wins"
vs. auto-detection, and cups-browsed's auto-detection "wins" vs. GTK's,
so in each case, GTK is aiming to prioritize the cups printing system
higher than its own code path.

The reason we're seeing duplicates seems to be that they are not always
identified as being the same printer in the way that was intended. In
the implementation of that deduplication in bullseye's GTK, entries for
the same printer are not always identified as such, so you're offered
the result of GTK's mDNS discovery *in addition to* the one from cups,
instead of having the one from cups replace it. The changes between
bullseye and bookworm (proposed here as the ~mr6 and ~mr6.1 versions)
change the deduplication so that the duplicates coming from GTK's own
mDNS discovery are eliminated more reliably.

The code in the ~mr6 version (which is a direct backport from bookworm)
appears to be correct for bookworm's cups-browsed but not for bullseye's,
because the different versions of cups-browsed choose slightly different
names for mDNS-advertised printers. The change between ~mr6 and ~mr6.1
adjusts the naming used by GTK to match bullseye's cups-browsed, so
that the version coming from cups-browsed will "win" and replace what
GTK would have done in the absence of cups-browsed.

If you have a better implementation of this, great! Please talk to
upstream, preferably without insulting them ("these changes would make
xyz more reliable" is more likely to get the changes accepted than
"your implementation of xyz is awful and you should use this instead",
even if the resulting code is identical).

> Problem: it does not live up to its promises and hasn't for
> many years. It is inept.

Even if true, this is not an effective way to make volunteers do what
you say they should. At best, it's demoralizing 

Bug#1000714: muparser: Please update to latest upstream version 2.3.2

[Nicholas Breen]

Hello again,

One of my packages now has an upstream dependency on muparser >= 2.3, so
I'd definitely like to see the newer version in the archive.  Within the
next few days, I plan to upload a NMU containing only the previously
described changes, plus a one-line addition to install the new *.cmake
files - and will upload to DELAYED/14 as an additional safety.  Please
let me know at any time if I should cancel the upload.

The latest upstream version is now 2.3.3, but it requires no further
changes to the packaging.  Current diff attached.

Thanks again for your work on muparser.



-- 
Nicholas Breen
nbr...@debian.org
diff --git a/debian/changelog b/debian/changelog
index c48b85d..45589aa 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+muparser (2.3.3-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release.
+  * Drop patches - no longer needed with upstream move to cmake.
+  * Update debian/watch and Homepage in debian/control.
+
+ -- Nicholas Breen   Sat, 12 Mar 2022 14:13:16 -0800
+
 muparser (2.2.6.1+dfsg-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index f4f7491..8febf57 100644
--- a/debian/control
+++ b/debian/control
@@ -4,12 +4,12 @@ Uploaders: Gudjon I. Gudjonsson ,
Scott Howard 
 Section: libs
 Priority: optional
-Build-Depends: debhelper (>= 12~),
-   automake
+Build-Depends: cmake,
+   debhelper (>= 12~)
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/science-team/muparser
 Vcs-Git: https://salsa.debian.org/science-team/muparser.git
-Homepage: http://muparser.sourceforge.net
+Homepage: https://beltoforion.de/en/muparser/
 
 Package: libmuparser-dev
 Architecture: any
diff --git a/debian/copyright b/debian/copyright
index 21065bb..3f39d20 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -2,12 +2,9 @@ Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: muparser
 Upstream-Contact: Ingo Berg 
 Source: http://muparser.sourceforge.net
-Files-Excluded: */*.dll
-*/*.lib
-*/vs
 
 Files: *
-Copyright: 2004-2007 Ingo Berg 
+Copyright: 2004-2022 Ingo Berg 
 License: Expat
   Permission is hereby granted, free of charge, to any person obtaining a copy
   of this software and associated documentation files (the "Software"), to deal
diff --git a/debian/libmuparser-dev.install b/debian/libmuparser-dev.install
index 7df81cd..f304b9d 100644
--- a/debian/libmuparser-dev.install
+++ b/debian/libmuparser-dev.install
@@ -1,3 +1,4 @@
 usr/include/*
 usr/lib/*/lib*.so
 usr/lib/*/pkgconfig/*
+usr/lib/*/cmake/muparser
diff --git a/debian/patches/FTBFS_hurd.patch b/debian/patches/FTBFS_hurd.patch
deleted file mode 100644
index e603046..000
--- a/debian/patches/FTBFS_hurd.patch
+++ /dev/null
@@ -1,26 +0,0 @@
-Description: Allow building on hurd
-Author: Scott Howard 
-Bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533817
-
-Index: muparser/build/autoconf/aclocal.m4
-===
 muparser.orig/build/autoconf/aclocal.m4	2013-01-26 23:30:49.773669077 -0500
-+++ muparser/build/autoconf/aclocal.m4	2013-01-26 23:30:53.421669002 -0500
-@@ -1258,7 +1258,7 @@
-   ;;
- 
-   powerpc-apple-macos* | \
--  *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | *-*-k*bsd*-gnu | \
-+  *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | *-*-k*bsd*-gnu | *-*-gnu* | \
-   *-*-mirbsd* | \
-   *-*-sunos4* | \
-   *-*-osf* | \
-@@ -1309,7 +1309,7 @@
- SONAME_FLAG=
- 
- case "${BAKEFILE_HOST}" in
--  *-*-linux* | *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | \
-+  *-*-linux* | *-*-gnu* | *-*-freebsd* | *-*-openbsd* | *-*-netbsd* | \
-   *-*-k*bsd*-gnu | *-*-mirbsd* )
- if test "x$SUNCXX" = "xyes"; then
- SONAME_FLAG="-h "
diff --git a/debian/patches/fix-versionnum.patch b/debian/patches/fix-versionnum.patch
deleted file mode 100644
index 1810865..000
--- a/debian/patches/fix-versionnum.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From: Teemu Ikonen 
-  Andreas Tille 
-Date: Sun, 13 Jan 2019 18:59:59 +0100
-Subject: [PATCH] Fix version number to 2.2.6 in build system.
-

- Makefile.in | 4 ++--
- build/autoconf/configure.ac | 2 +-
- 2 files changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/Makefile.in b/Makefile.in
-index 157be77..305167c 100644
 a/Makefile.in
-+++ b/Makefile.in
-@@ -139,9 +139,9 @@ COND_WINDOWS_IMPLIB_1___muParser_dll___importlib = \
- @COND_USE_SOVERSION_0@__muParser_dll___targetsuf2 = .$(SO_SUFFIX)
- @COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@__muParser_dll___targetsuf3 \
- @COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@	= \
--@COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@	.$(SO_SUFFIX).2.2.4
-+@COND_PLATFORM_MACOSX_0_USE_SOVERCYGWIN_0_USE_SOVERSION_1@	.$(SO_SUFFIX).2.2.6
- 

Bug#1006923: Add a method to append something to reprotest's build-command

[Santiago R.R.]

Control: tags -1 + patch

El 10/03/22 a las 12:30, Holger Levsen escribió:
> Hi Santiago,
> 
> On Tue, Mar 08, 2022 at 11:06:32AM +0100, Santiago R.R. wrote:
> > Could reprotest have an --append-build-command option please?
> 
> yes, please. patches most welcome, too! ;)

Done :-) (Hoping it is OK)
https://salsa.debian.org/reproducible-builds/reprotest/-/merge_requests/18

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1006863: tevent: reproducible-builds: build path embedded in various libraries

[Andrew Bartlett]

On Sat, 2022-03-12 at 13:53 -0800, Vagrant Cascadian wrote:
> On 2022-03-07, Andrew Bartlett wrote:
> > I would rather this be discussed and implemented upstream.
> > 
> > For one, the tevent build system is shared with the rest of Samba, and
> > if possible this should be implemented by default for all 'make
> > install' runs, just as we do to strip out the bin/default from -rpath.
> 
> Originally reported as https://bugs.debian.org/1006863 where I proposed
> passing additional arguments via CFLAGS in the debian build system.
> 
> Attached is a proof of concept patch that works by adding the argument
> to CFLAGS by patching the upstream buildsystem.
> 
> The patch is bit ugly in how it derives the top level source directory
> and likely error-prone... a cleaner way of going about that would be
> much appreciated!
> 
> It also requires gcc 8+ or clang 10+ ... making it detect weather the
> argument was supported and only adding it conditionally might be
> desireable.

testflags=True should be doing that, the CI should help determine if
that works for this option.

> I am not too familiar with samba project processes, let me know if
> there's a better place to send this!

https://wiki.samba.org/index.php/Contribute shows how to open a Merge
Request for samba.  Once you get a gitlab username let me know and you
can skip to using our shared development repo for a full CI.

conf.env.srcdir should get you the srcdir you need.

I guess my main concern is once Samba is packaged etc, can we still get
a full backtrace?  How does this interact with debug packages etc?

Andrew Bartlett

-- 
Andrew Bartlett (he/him)https://samba.org/~abartlet/
Samba Team Member (since 2001)  https://samba.org
Samba Developer, Catalyst IThttps://catalyst.net.nz/services/samba

Bug#1007185: btrfsmaintenance: reproducible builds: Timestamp embedded in manpage

[Vagrant Cascadian]

Source: btrfsmaintenance
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps locale
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in
/usr/share/man/man8/btrfsmaintenance.8.gz:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/diffoscope-results/btrfsmaintenance.html

  .TH·BTRFSMAINTENANCE·8·"12·March,·2022"·v0.5
  vs.
  .TH·BTRFSMAINTENANCE·8·"13·March,·2022"·v0.5

The attached patch fixes this by passing the --utc argument to date in
debian/create-man-page.sh and by using a locale-independent date format.


With this patch applied, btrfsmaintenance should build reproducibly on
tests.reproducible-builds.org!


Thanks for maintaining btrfsmaintenance!


live well,
  vagrant
From b7b79e3fa70b925e173e4c21aa6022a6a0a5987e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 12 Mar 2022 22:37:04 +
Subject: [PATCH] debian/create-man-page.sh: Use UTC timezone and a
 locale-idependent date string.

Without this, the locale may output a translated month, or building in
a different timezone may result in a different day or month.
---
 debian/create-man-page.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/create-man-page.sh b/debian/create-man-page.sh
index 9057e4d..5d8fa39 100755
--- a/debian/create-man-page.sh
+++ b/debian/create-man-page.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-man_date=$(date -d "@$(dpkg-parsechangelog -STimestamp)" +"%d %B, %Y")
+man_date=$(date --utc -d "@$(dpkg-parsechangelog -STimestamp)" +"%Y-%m-%d")
 
 cat << EOF > debian/tmp/btrfsmaintenance.md
 % BTRFSMAINTENANCE 8 "$man_date" v$DEB_VERSION_UPSTREAM
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#1007184: xrt: reproducible builds: Timestamps embedded in version.h

[Vagrant Cascadian]

Source: xrt
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in /usr/include/xrt/version.h and
various binaries that make use of this include file:

  
https://tests.reproducible-builds.org/debian/rb-pkg/experimental/amd64/diffoscope-results/xrt.html

  
static·const·char·xrt_build_version_date_rfc[]·=·"Thu,·10·Mar·2022·00:03:39·-1200";
  vs.
  
static·const·char·xrt_build_version_date_rfc[]·=·"Thu,·13·Apr·2023·08:35:26·+1400";
 
  static·const·char·xrt_build_version_date[]·=·"2022-01-19·15:01:01";
  vs.
  static·const·char·xrt_build_version_date[]·=·"2022-01-20·17:01:01";


The attached patch fixes this by using cmake's TIMESTAMP feature for
both, and passing the UTC argument for both strings.


With this patch applied, xrt should build reproducibly on
tests.reproducible-builds.org once it migrates to bookworm/testing!

In unstable and experimental, it is additionally affected by varied
build paths.


Thanks for maintaining xrt!


live well,
  vagrant
From cba92515b6c76f93d792cb0ae246617e4900e42a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 12 Mar 2022 21:19:21 +
Subject: [PATCH] src/CMake/version.cmake: Consistently use UTC timezone for
 timestamps.

While cmake TIMESTAMP respects the SOURCE_DATE_EPOCH environment
variable, it needs to be specified in the UTC timezone otherwise the
local timezone is used.

Convert XRT_DATE_RFC to use cmake TIMESTAMP.

https://reproducible-builds.org/docs/source-date-epoch/
---
 src/CMake/version.cmake | 10 ++
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/src/CMake/version.cmake b/src/CMake/version.cmake
index b74d30f..64efdba 100644
--- a/src/CMake/version.cmake
+++ b/src/CMake/version.cmake
@@ -33,15 +33,9 @@ execute_process(
 string(REPLACE "\n" "," XRT_MODIFIED_FILES "${XRT_MODIFIED_FILES}")
 
 # Get the build date RFC format
-execute_process(
-  COMMAND date -R
-  WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
-  OUTPUT_VARIABLE XRT_DATE_RFC
-  OUTPUT_STRIP_TRAILING_WHITESPACE
-)
-
+string(TIMESTAMP XRT_DATE_RFC "%a, %d %b %Y %H:%M:%S %Z" UTC)
 
-string(TIMESTAMP XRT_DATE "%Y-%m-%d %H:%M:%S")
+string(TIMESTAMP XRT_DATE "%Y-%m-%d %H:%M:%S" UTC)
 
 
 configure_file(
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1006863: tevent: reproducible-builds: build path embedded in various libraries

[Vagrant Cascadian]

On 2022-03-07, Andrew Bartlett wrote:
> I would rather this be discussed and implemented upstream.
>
> For one, the tevent build system is shared with the rest of Samba, and
> if possible this should be implemented by default for all 'make
> install' runs, just as we do to strip out the bin/default from -rpath.

Originally reported as https://bugs.debian.org/1006863 where I proposed
passing additional arguments via CFLAGS in the debian build system.

Attached is a proof of concept patch that works by adding the argument
to CFLAGS by patching the upstream buildsystem.

The patch is bit ugly in how it derives the top level source directory
and likely error-prone... a cleaner way of going about that would be
much appreciated!

It also requires gcc 8+ or clang 10+ ... making it detect weather the
argument was supported and only adding it conditionally might be
desireable.

I am not too familiar with samba project processes, let me know if
there's a better place to send this!


live well,
  vagrant

> On Sun, 2022-03-06 at 16:43 -0800, Vagrant Cascadian wrote:
>> Source: tevent
>> Severity: normal
>> Tags: patch
>> User: reproducible-bui...@lists.alioth.debian.org
>> Usertags: buildpath
>> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
>> 
>> The build path and resulting Build ID for various libraries is
>> embedded:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/tevent.html
>> 
>>   /usr/lib/x86_64-linux-gnu/libtevent.so.0.11.0
>> 
>>   /build/1st/tevent-0.11.0/bin/default/../../tevent.c:303
>>   vs.
>>   /build/2/tevent-0.11.0/2nd/bin/default/../../tevent.c:303
>> 
>> The attached patch to debian/rules fixes this by passing
>> -ffile-prefix-map via CFLAGS in the dh_auto_configure override.
>> 
>> Alternately, updating to use the CFLAGS passed via dh/debhelper would
>> also likely fix this.
>> 
>> With this patch applied tevent should build reproducibly on
>> tests.reproducible-builds.org!

From 8324603d80051d6ad2f3f5fcdcc0a110f159b5aa Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 12 Mar 2022 21:46:46 +
Subject: [PATCH] buildtools/wafsamba/samba_autoconf.py: Add -ffile-prefix-map
 to CFLAGS.

Without this, the build path is embedded in various binaries, which
requires additional knowledge about the build environment in order to
reproduce the build.
---
 buildtools/wafsamba/samba_autoconf.py | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/buildtools/wafsamba/samba_autoconf.py b/buildtools/wafsamba/samba_autoconf.py
index 4d2aea6..d618182 100644
--- a/buildtools/wafsamba/samba_autoconf.py
+++ b/buildtools/wafsamba/samba_autoconf.py
@@ -725,6 +725,13 @@ def SAMBA_CONFIG_H(conf, path=None):
 if Options.options.debug:
 conf.ADD_CFLAGS('-g', testflags=True)
 
+# Remove build path using -ffile-prefix-map. Requires gcc 8+ or clang 10+
+# https://reproducible-builds.org/docs/build-path/
+
+# Determine the top-level source directory by stripping out the relative path that waf was called as.
+sourcedir=os.path.abspath(sys.argv[0]).split(sys.argv[0].lstrip('.'))[0]
+conf.ADD_CFLAGS('-ffile-prefix-map=%s=.' % sourcedir, testflags=True)
+
 if Options.options.pidl_developer:
 conf.env.PIDL_DEVELOPER_MODE = True
 
-- 
2.35.1



signature.asc
Description: PGP signature

Bug#947918: gtk

[Nilson Silva]

Hello Gürkan Myczko!
As for the first post, I believe that Thomas would be the best person to answer 
your questions, since I don't know the program.


When the second one replaces GTK2-dev with GTK3, and builds the binary without 
any problems.

My question is, even building under GTK3, the program will not be able to enter 
Debian, for the reasons exposed in the first post?

The package is almost ready. So, tell me something so I don't waste time.

Strong hug!



Nilson F. Silva

81-3036-0200

81-991616348

81-98546-9553


De: Gürkan Myczko 
Enviado: sábado, 12 de março de 2022 11:14
Para: 947...@bugs.debian.org <947...@bugs.debian.org>
Assunto: Bug#947918: gtk

Oh and

gtk2, although it's available, I doubt it makes sense to package new
things in 2022
into Debian. I saw they have gtk3 as well, maybe try that?

Best,

Bug#1007182: live-config: Add ability to use cloud-init for configuration

[Roland Clobus]

Hello Michael Kesper,

On 12/03/2022 21:42, Michael Kesper wrote:

Please add the ability to configure debian live media per default
with the cloud-init standard.
Cloud-Init can already be used for VMs starting with debian cloud images
and offers declarative configuration of many aspects, see
https://cloudinit.readthedocs.io/en/latest/
Live media should search on the modifiable file systems for such
configuration items, removing the need for rebuilding whole images
for simple adaptations.


Could you elaborate some more? The documentation you pointed at is quite 
a lot and does (at first glance) not show _how_ the live media would 
support the cloud-init standard.
Do you have a working example or a proof-of-concept that can be used for 
the integration if this feature?


With kind regards,
Roland Clobus


OpenPGP_signature
Description: OpenPGP digital signature

Bug#982925: libgtk: print dialog lists autodetected printer twice

[Brian Potkin]

On Sat 26 Feb 2022 at 19:43:08 +0100, Daniel Gröber wrote:

> Here are my test results:
> 
> TLDR:
> 
> - Printing via cups entry (be that cups-browsed or manual) always succeeds

You have just confirmed that the printing system (CUPS + cups-filters
+ (optionally) cups-browsed) works effieiently and as designed.
> 
> - Printing via libgtk's fallback entry always fails

I wouldn't see libgtk as providing a fallbac. Why would a fallback be
needed when the printing system does the jobi, as you have demonstrated?
On bullseye libgtk treads its own path and ignores the CUPS APIs. It is
little wonder users (like the bug submitter) experience consternation.

If it wasn't for cups-bowsed, we would be overrun with bug reports.
> 
> - Both proposed fixes work and succeed in removing the duplicate entry for
>   cups-browsed, but not for a manually added printer with default name or
>   when the user chooses a name that doesn't match the cups-browsed/libgtk
>   mangling scheme.

If I set up a manual destination, I would be extremely annoyed if it was
interfered with.

> Resultion: printing is still hell on earth :]

libgtk is not part of the printing system; it is a helper program. It
says - here are some destinations, click on them and I will do your
prinring. Problem: it does not live up to its promises and hasn't for
many years. It is inept. So let's have the source of this bug on
bullseye correectly and fairly and squarly identified. It is libgtk.
That is your hell :).

BTW, whoever said Qt is more competent hasn't looked at how it behaves
without cups-browsed.

With thanks to Simon McVittie and everyone else for caring.

Regards,

Brian.

Bug#1007183: buster-pu: package libphp-adodb/5.20.14-1

[Jean-Michel Vourgère]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: buster
Severity: normal

Hello

I'd like to patch CVE-2021-3850

The one-line patch is already released in sid, and in old-old-security
as version 5.20.9-1+deb9u1 thanks to the ELTS team.

The patch, from upstream, removes the detection of a string being 
already quoted. This results in the proper escaping always taking place.
Note that this function is only called for escaping pg_connect arguments.

Is that ok?

Tell me if you think it's better to upload in buster-security.diff -Nru libphp-adodb-5.20.14/debian/changelog libphp-adodb-5.20.14/debian/changelog
--- libphp-adodb-5.20.14/debian/changelog	2019-01-07 07:18:32.0 +0100
+++ libphp-adodb-5.20.14/debian/changelog	2022-03-12 21:40:01.0 +0100
@@ -1,3 +1,10 @@
+libphp-adodb (5.20.14-1+deb10u1) buster; urgency=high
+
+  * Add patch to prevent auth bypass with PostgreSQL
+connections. (Fixes: CVE-2021-3850) (Closes: #1004376)
+
+ -- Jean-Michel Vourgère   Sat, 12 Mar 2022 21:40:01 +0100
+
 libphp-adodb (5.20.14-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru libphp-adodb-5.20.14/debian/patches/CVE-2021-3850.patch libphp-adodb-5.20.14/debian/patches/CVE-2021-3850.patch
--- libphp-adodb-5.20.14/debian/patches/CVE-2021-3850.patch	1970-01-01 01:00:00.0 +0100
+++ libphp-adodb-5.20.14/debian/patches/CVE-2021-3850.patch	2022-02-06 09:56:10.0 +0100
@@ -0,0 +1,26 @@
+From 952de6c4273d9b1e91c2b838044f8c250c29 Mon Sep 17 00:00:00 2001
+From: Damien Regad 
+Date: Mon, 10 Jan 2022 09:41:32 +0100
+Subject: [PATCH] Prevent auth bypass with PostgreSQL connections
+
+Thanks to Emmet Leahy of Sorcery Ltd for reporting this vulnerability
+(CVE-2021-3850).
+
+This is a minimalistic approach to patch the issue, to reduce the risk
+of causing regressions in the legacy stable branch.
+
+Fixes #793
+---
+ drivers/adodb-postgres64.inc.php | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/adodb-postgres64.inc.php
 b/drivers/adodb-postgres64.inc.php
+@@ -51,7 +51,6 @@
+ {
+ 	$len = strlen($s);
+ 	if ($len == 0) return "''";
+-	if (strncmp($s,"'",1) === 0 && substr($s,$len-1) == "'") return $s; // already quoted
+ 
+ 	return "'".addslashes($s)."'";
+ }
diff -Nru libphp-adodb-5.20.14/debian/patches/series libphp-adodb-5.20.14/debian/patches/series
--- libphp-adodb-5.20.14/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libphp-adodb-5.20.14/debian/patches/series	2022-02-06 09:55:43.0 +0100
@@ -0,0 +1 @@
+CVE-2021-3850.patch


signature.asc
Description: This is a digitally signed message part.

Bug#1007182: live-config: Add ability to use cloud-init for configuration

[Michael Kesper]

Package: live-config
Version: 11.0.3
Severity: wishlist

Dear Maintainer,

Please add the ability to configure debian live media per default
with the cloud-init standard.
Cloud-Init can already be used for VMs starting with debian cloud images
and offers declarative configuration of many aspects, see
https://cloudinit.readthedocs.io/en/latest/
Live media should search on the modifiable file systems for such
configuration items, removing the need for rebuilding whole images
for simple adaptations.

Feel free to move to another package if this is the wrong address.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages live-config depends on:
ii  live-config-systemd [live-config-backend]  11.0.3

Versions of packages live-config recommends:
ii  iproute25.16.0-2
ii  keyboard-configuration  1.207
ii  live-config-doc 11.0.3
ii  live-tools  1:20190831
ii  locales 2.33-7
ii  sudo1.9.9-1
ii  user-setup  1.88

Versions of packages live-config suggests:
ii  pciutils  1:3.7.0-6
ii  wget  1.21.2-2+b1

-- no debconf information

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

On Sat 05 Mar 2022 at 17:59:51 +0100  Petra R.-P.  
wrote:
> Update for linux-image-5.16.0-3-686 :
[...]

The error persists also in linux-image-5.16.0-4-686 (5.16.12-1) .

 Petra

Bug#1007181: bullseye-pu: package libphp-adodb/5.20.19-1

[Jean-Michel Vourgère]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: bullseye
Severity: normal

Hello

I'd like to patch CVE-2021-3850

The one-line patch is already released in sid, and in old-old-security
as version 5.20.9-1+deb9u1 thanks to the ELTS team.

The patch, from upstream, removes the detection of a string being 
already quoted. This results in the proper escaping always taking place.
Note that this function is only called for escaping pg_connect arguments.

Is that ok?

Tell me if you think it's better to upload in bullseye-security.diff -Nru libphp-adodb-5.20.19/debian/changelog libphp-adodb-5.20.19/debian/changelog
--- libphp-adodb-5.20.19/debian/changelog	2020-12-19 08:08:01.0 +0100
+++ libphp-adodb-5.20.19/debian/changelog	2022-03-12 18:50:26.0 +0100
@@ -1,3 +1,10 @@
+libphp-adodb (5.20.19-1+deb11u1) bullseye; urgency=high
+
+  * Add patch to prevent auth bypass with PostgreSQL
+connections. (Fixes: CVE-2021-3850) (Closes: #1004376)
+
+ -- Jean-Michel Vourgère   Sat, 12 Mar 2022 18:50:26 +0100
+
 libphp-adodb (5.20.19-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru libphp-adodb-5.20.19/debian/patches/CVE-2021-3850.patch libphp-adodb-5.20.19/debian/patches/CVE-2021-3850.patch
--- libphp-adodb-5.20.19/debian/patches/CVE-2021-3850.patch	1970-01-01 01:00:00.0 +0100
+++ libphp-adodb-5.20.19/debian/patches/CVE-2021-3850.patch	2022-02-06 09:56:10.0 +0100
@@ -0,0 +1,26 @@
+From 952de6c4273d9b1e91c2b838044f8c250c29 Mon Sep 17 00:00:00 2001
+From: Damien Regad 
+Date: Mon, 10 Jan 2022 09:41:32 +0100
+Subject: [PATCH] Prevent auth bypass with PostgreSQL connections
+
+Thanks to Emmet Leahy of Sorcery Ltd for reporting this vulnerability
+(CVE-2021-3850).
+
+This is a minimalistic approach to patch the issue, to reduce the risk
+of causing regressions in the legacy stable branch.
+
+Fixes #793
+---
+ drivers/adodb-postgres64.inc.php | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/adodb-postgres64.inc.php
 b/drivers/adodb-postgres64.inc.php
+@@ -51,7 +51,6 @@
+ {
+ 	$len = strlen($s);
+ 	if ($len == 0) return "''";
+-	if (strncmp($s,"'",1) === 0 && substr($s,$len-1) == "'") return $s; // already quoted
+ 
+ 	return "'".addslashes($s)."'";
+ }
diff -Nru libphp-adodb-5.20.19/debian/patches/series libphp-adodb-5.20.19/debian/patches/series
--- libphp-adodb-5.20.19/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ libphp-adodb-5.20.19/debian/patches/series	2022-02-06 09:55:43.0 +0100
@@ -0,0 +1 @@
+CVE-2021-3850.patch


signature.asc
Description: This is a digitally signed message part.

Bug#1006784: automake: fixes for python3.10 distutils changes

[Stefano Rivera]

Control: reopen -1

Hi Gianfranco (2022.03.04_18:19:35_-0400)
> With this patch, automake will install to /usr for locally built code
> and debian-packaged code. This probably isn't desired. Maybe check
> prefix and select the appropriate scheme from that?

I take this back. Of course it is combining posix_prefix with the
specified prefix, which will do the right thing.

We should apply this patch, ASAP.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1007180: debianutils: [INTL:de] updated German man page translation

[Helge Kreutzmann]

Package: debianutils
Version: 5.7
Severity: wishlist
Tags: patch l10n

Please find the updated German man page translation for debianutils
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of debianutils man page template to German
# Copyright (C) Helge Kreutzmann , 2011, 2012, 2017, 
2018, 2020, 2022.
# This file is distributed under the same license as the debianutils package.
#
msgid ""
msgstr ""
"Project-Id-Version: debianutils man page 5.7\n"
"POT-Creation-Date: 2021-09-23 12:52-0400\n"
"PO-Revision-Date: 2022-03-12 21:05+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: de \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: utf-8\n"

#. type: TH
#: add-shell.8:1
#, no-wrap
msgid "ADD-SHELL"
msgstr "ADD-SHELL"

#. type: TH
#: add-shell.8:1 remove-shell.8:1
#, no-wrap
msgid "23 Sep 2021"
msgstr "23. Sep. 2021"

#. type: SH
#: add-shell.8:2 installkernel.8:2 ischroot.1:3 remove-shell.8:2 run-parts.8:9
#: savelog.8:3 update-shells.8:2 which.1:3
#, no-wrap
msgid "NAME"
msgstr "NAME"

#. type: Plain text
#: add-shell.8:4
msgid "add-shell - add shells to the list of valid login shells"
msgstr "add-shell - Shells zu der Liste der gültigen Anmelde-Shells hinzufügen"

#. type: SH
#: add-shell.8:4 installkernel.8:4 ischroot.1:5 remove-shell.8:4 run-parts.8:11
#: savelog.8:5 update-shells.8:4 which.1:5
#, no-wrap
msgid "SYNOPSIS"
msgstr "ÜBERSICHT"

#. type: Plain text
#: add-shell.8:8
msgid "B I [I...]"
msgstr "B I [I…]"

#. type: SH
#: add-shell.8:8 installkernel.8:6 ischroot.1:8 remove-shell.8:8 run-parts.8:20
#: savelog.8:11 update-shells.8:7 which.1:7
#, no-wrap
msgid "DESCRIPTION"
msgstr "BESCHREIBUNG"

#. type: Plain text
#: add-shell.8:18
msgid ""
"B copies I to I, adds the given "
"shells to this file if they are not already present, and copies this "
"temporary file back to I."
msgstr ""
"B kopiert I nach I, fügt die "
"angegebenen Shells zu dieser Datei hinzu falls sie dort noch nicht enthalten "
"sind und kopiert die temporäre Datei wieder zu I zurück."

#. type: Plain text
#: add-shell.8:20
msgid "The shells must be provided by their full pathnames."
msgstr "Die Shells müssen mit ihrem vollen Pfadnamen angegeben werden."

#. type: SH
#: add-shell.8:20 remove-shell.8:17
#, no-wrap
msgid "ENVIRONMENT"
msgstr "UMGEBUNG"

#. type: TP
#: add-shell.8:21 remove-shell.8:18
#, no-wrap
msgid "I"
msgstr "I"

#. type: Plain text
#: add-shell.8:26 remove-shell.8:23
msgid "specifies the base path under which I resides."
msgstr "legt den Basispfad fest, unter dem sich I befindet."

#. type: SH
#: add-shell.8:26 remove-shell.8:23 savelog.8:166 update-shells.8:34
#, no-wrap
msgid "SEE ALSO"
msgstr "SIEHE AUCH"

#.  -*- nroff -*-
#. type: Plain text
#: installkernel.8:1 run-parts.8:8 which.1:2
msgid "B(5)"
msgstr "B(5)"

#. type: TH
#: installkernel.8:1
#, no-wrap
msgid "INSTALLKERNEL"
msgstr "INSTALLKERNEL"

#. type: TH
#: installkernel.8:1
#, no-wrap
msgid "7 Jan 2001"
msgstr "7. Jan. 2001"

#. type: TH
#: installkernel.8:1
#, no-wrap
msgid "Debian Linux"
msgstr "Debian Linux"

#. type: Plain text
#: installkernel.8:4
msgid "installkernel - install a new kernel image"
msgstr "installkernel - installiert ein neues Kernel-Image"

#. type: Plain text
#: installkernel.8:6
msgid "BI"
msgstr "BI"

#. type: Plain text
#: installkernel.8:13
msgid ""
"B installs a new kernel image onto the system from the Linux "
"source tree.  It is called by the Linux kernel makefiles when B is invoked there."
msgstr ""
"B installiert ein neues Kernel-Image auf das System aus dem "
"Linux-Quellbaum. Es wird von den Linux-Kernel-Makefiles aufgerufen, wenn "
"dort B ausgeführt wird."

#. type: Plain text
#: installkernel.8:24
msgid ""
"The new kernel is installed into I<{directory}/vmlinuz-{version}>.  If a "
"symbolic link I<{directory}/vmlinuz> already exists, it is refreshed by "
"making a link from I<{directory}/vmlinuz> to the new kernel, and the "
"previously installed kernel is available as I<{directory}/vmlinuz.old>."
msgstr ""
"Der neue Kernel wird in I<{Verzeichnis}/vmlinuz-{Version}> installiert. "
"Falls bereits ein symbolischer Link I<{Verzeichnis}/vmlinuz> existiert, wird "
"er erneuert, indem ein Link von I<{Verzeichnis}/vmlinuz> auf den neuen "
"Kernel gelegt wird. Der vorher installierte Kernel ist unter I<{Verzeichnis}/"
"vmlinuz.old> verfügbar."

#. type: SH
#: installkernel.8:24 ischroot.1:35 savelog.8:159
#, no-wrap
msgid "BUGS"
msgstr "FEHLER"

#.  -*- nroff -*-
#. type: Plain text
#: ischroot.1:2
msgid ""
"B resides in /sbin only because the Linux kernel makefiles "
"call it from there.  It should really be in /usr/sbin.  It isn't needed to "
"boot a system."
msgstr ""
"B liegt nur in /sbin, da die Makefiles des Linux-Kernels es "

Bug#1007179: ITS: gumbo-parser

[Bastian Germann]

Source: gumbo-parser

The package was touched the last time by the Maintainer in 2015 and there have been 4 NMUs since 
then. I intend to salvage gumbo-parser because I maintain two packages that depend on it.

Bug#1007178: Incorrect dependency from libghc-curl-dev?

[Keith A. Bare II]

Package: libghc-curl-dev
Version: 1.3.8-12+b1

I'm attempting to build a system for CMU Computer Club users that will
provide development environments and some common libraries for several
programming languages.  This ran into problems due to conflicts between
libcurl4-gnutls-dev and libcurl4-openssl-dev.

Haskell seemed to be the only language with curl bindings depending on the
OpenSSL variant, so I figured I might need to drop it.

But when I looked at the dependencies more carefully, I noticed:

(bullseye)kbare@builds:~$ apt-cache show libghc-curl-dev
Package: libghc-curl-dev
Source: haskell-curl (1.3.8-12)
Version: 1.3.8-12+b1
Installed-Size: 3035
Maintainer: Debian Haskell Group <
pkg-haskell-maintain...@lists.alioth.debian.org>
Architecture: amd64
Provides: libghc-curl-dev-1.3.8-5dcc8
Depends: libcurl4-openssl-dev, libghc-base-dev-4.13.0.0-2f220,
libghc-bytestring-dev-0.10.10.1-c40ee, libghc-containers-dev-0.6.2.1-ab1cf,
libc6 (>= 2.2.5), libcurl3-gnutls (>= 7.16.2), libgmp10

So libghc-curl-dev says it depends on the curl OpenSSL development package
but the curl GNUTLS runtime shared library.  Looking closer at the source
package, I see the Build-Dependency is actually against the GNUTLS flavor
of libcurl, so it seems like the dependency on libcurl4-openssl-dev may be
in error.

Found this working with Debian 11/bullseye.

--Keith

Bug#1007177: ITP: libmediascan -- scanner to find media files and extract metadata from them

[Paul Gevers]

Package: wnpp
Severity: wishlist
Owner: Paul Gevers 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libmediascan
  Version : 0.1
  Upstream Author : Andy Grundman
* URL : https://github.com/andygrundman/libmediascan
* License : GPL3.0
  Programming Lang: C and Perl
  Description : scanner to find media files and extract metadata from them

libmediascan consists of a C library and corresponding Perl module to:
* Scan a file tree for media files
* Generate audio, video, and image thumbnails at scan-time.
* Determine DLNA profile information during scanning
  
It supports change notification methods for background directory watching.

The library depends on FFmpeg to handle video files, libjpeg/libpng/libgif for
image and thumbnail support, and libexif for JPEG tags.

libmediascan is an evolution of the work done on the Perl modules Audio::Scan
and Image::Scale:
  http://search.cpan.org/dist/Audio-Scan
  http://search.cpan.org/dist/Image-Scale

I intend to maintain this package inside the Perl team where its
siblings are also maintained.

Bug#1007176: rust-regex: CVE-2022-24713: RUSTSEC-2022-0013: Regexes with large repetitions on empty sub-expressions take a very long time to parse

[Salvatore Bonaccorso]

Source: rust-regex
Version: 1.5.4-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rust-regex.

CVE-2022-24713[0]:
| regex is an implementation of regular expressions for the Rust
| language. The regex crate features built-in mitigations to prevent
| denial of service attacks caused by untrusted regexes, or untrusted
| input matched by trusted regexes. Those (tunable) mitigations already
| provide sane defaults to prevent attacks. This guarantee is documented
| and it's considered part of the crate's API. Unfortunately a bug was
| discovered in the mitigations designed to prevent untrusted regexes to
| take an arbitrary amount of time during parsing, and it's possible to
| craft regexes that bypass such mitigations. This makes it possible to
| perform denial of service attacks by sending specially crafted regexes
| to services accepting user-controlled, untrusted regexes. All versions
| of the regex crate before or equal to 1.5.4 are affected by this
| issue. The fix is include starting from regex 1.5.5. All users
| accepting user-controlled regexes are recommended to upgrade
| immediately to the latest version of the regex crate. Unfortunately
| there is no fixed set of problematic regexes, as there are practically
| infinite regexes that could be crafted to exploit this vulnerability.
| Because of this, it us not recommend to deny known problematic
| regexes.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24713
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24713
[1] https://rustsec.org/advisories/RUSTSEC-2022-0013.html
[2] https://github.com/rust-lang/regex/security/advisories/GHSA-m5pq-gvj9-9vr8
[3] 
https://github.com/rust-lang/regex/commit/ae70b41d4f46641dbc45c7a4f87954aea356283e
[4] https://groups.google.com/g/rustlang-security-announcements/c/NcNNL1Jq7Yw

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1007175: RFP: poezio-omemo -- OMEMO End-to-End Encryption plugin for poezio

[Maxime Buquet]

Package: wnpp
Severity: wishlist

* Package name: poezio-omemo
  Version : 0.5.0
  Upstream Author : Maxime “pep” Buquet
* URL : https://lab.louiz.org/poezio/poezio-omemo
* License : GPLv3
  Programming Lang: Python
  Description : OMEMO End-to-End Encryption plugin for poezio

I am the author and maintainer of poezio-omemo[0], a plugin for
poezio[1], an xmpp client written in Python. This plugin is an interface
to slixmpp-omemo[2] for poezio.

Its dependencies are slixmpp and poezio.

[0]: https://lab.louiz.org/poezio/poezio-omemo
[0]: https://lab.louiz.org/poezio/poezio
[0]: https://lab.louiz.org/poezio/slixmpp-omemo


signature.asc
Description: PGP signature

Bug#1007174: RFP: slixmpp-omemo -- OMEMO End-to-End Encryption plugin for slixmpp

[Maxime Buquet]

Package: wnpp
Severity: wishlist

* Package name: slixmpp-omemo
  Version : 0.6.0
  Upstream Author : Maxime “pep” Buquet
* URL : https://lab.louiz.org/poezio/slixmpp-omemo
* License : GPLv3
  Programming Lang: Python
  Description : OMEMO End-to-End Encryption plugin for slixmpp

I am the author and maintainer of slixmpp-omemo[0], a plugin for
slixmpp, an xmpp library written in Python, implementing the OMEMO
End-to-End Encryption mechanism (XEP-0384 version 0.3.0[2] currently in
the library).

Its main dependencies are slixmpp and python-omemo. The latter would
need an update but both are fortunately already present.

[0]: https://lab.louiz.org/poezio/slixmpp-omemo
[1]: https://lab.louiz.org/poezio/slixmpp
[2]: https://xmpp.org/extensions/attic/xep-0384-0.3.0.html


signature.asc
Description: PGP signature

Bug#1006456: transition: openldap

[Ryan Tandy]

On Fri, Mar 11, 2022 at 10:15:31PM +0100, Sebastian Ramacher wrote:

Please go ahead


Thank you. openldap/2.5.11+dfsg-1 has just been accepted into unstable.

Should I bump the remaining autopkgtest issues to RC severity at this 
time?


Could you please update the ben file for the transition? The 
auto-generated one is not ideal. I think it should look something like:


is_affected = .build-depends ~ /\b(libldap(2)?\-dev|libslapi\-dev)\b/;
is_bad = .depends ~ /\b(libldap\-2\.4\-2|libslapi\-2\.4\-2)\b/;
is_good = .depends ~ /\b(libldap\-2\.5\-0|libslapi\-2\.5\-0)\b/;

Thank you,
Ryan

Bug#238706: Not a wishlist, but a bug

[a...@prnet.info]

In the meantime this bug is unfixed,
Workaround except mouse drag/drop the seek button is to use mouse wheel. 
It moves the seek button pretty fast.

Bug#1007172: r-cran-pki incompatible with OpenSSL 3

[Steve Langasek]

Package: r-cran-pki
Version: 0.1-9-1
Severity: serious
Tags: patch experimental
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Hi Andreas,

r-cran-pki is incompatible with OpenSSL 3, which is currently in
experimental.  This shows up as an autopkgtest failure:

[...]
>  -- Ciphers
info("Ciphers")
> skey <- PKI.random(256)
> for (cipher in c("aes256ecb", "aes256ofb", "bfcbc", "bfecb", "bfofb", 
> "bfcfb"))
+ assert(cipher, all(PKI.decrypt(PKI.encrypt(charToRaw("foo!"), skey, 
cipher), skey, cipher)[1:4] == charToRaw("foo!")))
   .  aes256ecb 
   .  aes256ofb 
   .  bfcbc 
Error in PKI.encrypt(charToRaw("foo!"), skey, cipher) : 
  error:0308010C:digital envelope routines::unsupported
Calls: assert -> stopifnot -> PKI.decrypt -> PKI.encrypt
Execution halted
autopkgtest [09:48:31]: test run-unit-test: ---]
[...]

  
(https://autopkgtest.ubuntu.com/results/autopkgtest-jammy/jammy/amd64/r/r-cran-pki/20220223_094913_a5969@/log.gz)

The issue is that r-cran-pki exposes use of various older, insecure
algorithms which are no longer available in the default crypto provider in
openssl, so additional steps are required in the code in order to enable use
of these algorithms.

I've prepared the attached patch which fixes the issue, and have uploaded it
to Ubuntu, since we are shipping OpenSSL 3 for the upcoming release.  Please
consider including it in Debian as well (and forwarding upstream).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru r-cran-pki-0.1-9/debian/patches/openssl3-compat.patch 
r-cran-pki-0.1-9/debian/patches/openssl3-compat.patch
--- r-cran-pki-0.1-9/debian/patches/openssl3-compat.patch   1969-12-31 
16:00:00.0 -0800
+++ r-cran-pki-0.1-9/debian/patches/openssl3-compat.patch   2022-03-12 
00:09:19.0 -0800
@@ -0,0 +1,85 @@
+Description: Fix compatibility with OpenSSL 3
+ Some algorithms exposed by PKI are now 'legacy' in OpenSSL and require
+ explicit enablement.
+Author: Steve Langasek 
+Last-Update: 2022-03-12
+Forwarded: no
+
+Index: r-cran-pki-0.1-9/src/pki.h
+===
+--- r-cran-pki-0.1-9.orig/src/pki.h
 r-cran-pki-0.1-9/src/pki.h
+@@ -20,6 +20,10 @@
+ #include 
+ #include 
+ 
++#if OPENSSL_VERSION_NUMBER >= 0x3000L
++#include 
++#endif
++
+ #if __APPLE__
+ #if defined MAC_OS_X_VERSION_10_7 && MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
+ /* use accelerated crypto on OS X instead of OpenSSL crypto */
+Index: r-cran-pki-0.1-9/src/pki-x509.c
+===
+--- r-cran-pki-0.1-9.orig/src/pki-x509.c
 r-cran-pki-0.1-9/src/pki-x509.c
+@@ -225,6 +225,28 @@
+ static EVP_CIPHER_CTX *get_cipher(SEXP sKey, SEXP sCipher, int enc, int 
*transient, SEXP sIV) {
+ EVP_CIPHER_CTX *ctx;
+ PKI_init();
++
++#if OPENSSL_VERSION_NUMBER >= 0x3000L
++static OSSL_PROVIDER *legacy_provider = NULL;
++static OSSL_PROVIDER *default_provider = NULL;
++static OSSL_LIB_CTX *ossl_ctx = NULL;
++
++if (!ossl_ctx)
++  ossl_ctx = OSSL_LIB_CTX_new();
++if (!ossl_ctx)
++  Rf_error("OSSL_LIB_CTX_new failed\n");
++
++if (!legacy_provider)
++  legacy_provider = OSSL_PROVIDER_load(ossl_ctx, "legacy");
++if (!legacy_provider)
++  Rf_error("OSSL_PROVIDER_load(legacy) failed\n");
++
++if (!default_provider)
++  default_provider = OSSL_PROVIDER_load(ossl_ctx, "default");
++if (!default_provider)
++  Rf_error("OSSL_PROVIDER_load(default) failed\n");
++#endif
++
+ if (inherits(sKey, "symmeric.cipher")) {
+   if (transient) transient[0] = 0;
+   return (EVP_CIPHER_CTX*) R_ExternalPtrAddr(sCipher);
+@@ -265,13 +287,29 @@
+   else if (!strcmp(cipher, "aes256ofb"))
+   type = EVP_aes_256_ofb();
+   else if (!strcmp(cipher, "blowfish") || !strcmp(cipher, "bfcbc"))
++#if OPENSSL_VERSION_NUMBER >= 0x3000L
++  type = EVP_CIPHER_fetch(ossl_ctx, "BF-CBC", NULL);
++#else
+   type = EVP_bf_cbc();
++#endif
+   else if (!strcmp(cipher, "bfecb"))
++#if OPENSSL_VERSION_NUMBER >= 0x3000L
++  type = EVP_CIPHER_fetch(ossl_ctx, "BF-ECB", NULL);
++#else
+   type = EVP_bf_ecb();
++#endif
+   else if (!strcmp(cipher, "bfofb"))
++#if OPENSSL_VERSION_NUMBER >= 0x3000L
++  type = EVP_CIPHER_fetch(ossl_ctx, "BF-OFB", NULL);
++#else
+   type = EVP_bf_ofb();
++#endif
+   else if (!strcmp(cipher, "bfcfb"))
++#if OPENSSL_VERSION_NUMBER >= 0x3000L
++  type = EVP_CIPHER_fetch(ossl_ctx, "BF-CFB", NULL);
++#else
+   type = EVP_bf_cfb();
++#endif
+   else Rf_error("unknown cipher `%s'", CHAR(STRING_ELT(sCipher, 0)));
+ 
+   if 

Bug#1007171: git clone of packaging repo fails

[Thomas Koch]

Source: emacs
Severity: normal
X-Debbugs-Cc: tho...@koch.ro, debian-emac...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Posting this as a bug against the emacs source package in lack of a better 
place.

Trying to git clone the emacs repository from salsa fails:

% git clone https://salsa.debian.org/rlb/deb-emacs.git
Cloning into 'deb-emacs'...
remote: Enumerating objects: 1328855, done.
remote: Counting objects: 100% (64295/64295), done.
remote: Compressing objects: 100% (12952/12952), done.
error: object 676f341671bedf6007a029bb2f3c472ebe308603: missingNameBeforeEmail: 
invalid author/committer line - missing space before email
fatal: fsck error in packed object
fatal: fetch-pack: invalid index-pack output

Searching for the error message provided a workaround:

git clone --config transfer.fsckobjects=false \
--config receive.fsckobjects=false \
--config fetch.fsckobjects=false \
https://salsa.debian.org/rlb/deb-emacs.git

After cloning I could investigate the broken object:


% git cat-file -p 676f341671bedf60
tree 81fcfcb9f01174b95c685913b481dba5e16aaa5d
parent 7f27ada42c3342ed80354cd684f310a6c2d23db8
author  863032744 +
committer  863032744 +

Recognize either / or - as a machine/suptype separator from uname -m
to cope with older systems that have the older uname.

Output of git fsck:

error in commit 676f341671bedf6007a029bb2f3c472ebe308603: 
missingNameBeforeEmail: invalid author/committer line - missing space before 
email
error in commit 7fb42a25e934250edf3ed3c0ef16be2a16c3e3a3: 
missingNameBeforeEmail: invalid author/committer line - missing space before 
email
error in commit b563928ca802b46a1facff442d91c6e922ee8e1d: 
missingNameBeforeEmail: invalid author/committer line - missing space before 
email
error in commit dd17bafcae829d6420d099e169bbbcec2cdd6cf6: 
missingNameBeforeEmail: invalid author/committer line - missing space before 
email

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmIs5qkACgkQB/xIkQQr
plrlRxAAwk0DTwPqiphr4bZ0C4k3mMRdijzy5hz/2BN9V6QfTdY0hrlIIKQgdx6e
Nz+zaUKOgmp23wg5SID0xxekA1RctZQchL7yobIICfddfBeDiZc6i+W5GryYYV3b
Qbtz9CeoazHGsMEllsd0FvGpfvE+NFRBkmCWvr2FnKnNIt4f/6/zN2mhAhqndXX3
4qzhrAIhV9F0z/Rsn/Uqm86vSH+MtSICqm5FSJBuQ3abyrP0VLiJKXU4ZZgB9N5e
PCxlUpfKLTF8pN5ddeA9Fa1F6eU49pQnWLo0ZBJh50je+3uOvfqJtVx1uVM+8wHI
Z3+QVi01UTVGHz/1Fjck7JPMr5c8wRdp1Hh7ut/0B1JgjackuuavplIdeo26zA37
zTHBjmIFphFy3/4ASyNXWZnFZSwacG7qvHDqQvMqQU9pfxjpclDmMQdbbieYGtiV
HzoMZUU4/faueahGMR4J37F+lTInI891nfo6moBqaVD6G2Rn2Y6v5C1j1CTamd39
+xu0a91FHeVshYsZh3M49vFWdZ43eo45nYKM/4uownRKnEQVmNTSjhmA0oD3uK+L
R6GOwZNB6rNJnoJqCDRl1VXRhI+AZELxEZ+e7e1D8tKXF3+Y3go8k+c7whskbnJf
4p2bFJZmDXCkvknEYR0qGDMtWdQdW3cwqPxG5K8T7ycMxineBy4=
=w3n0
-END PGP SIGNATURE-

Bug#1007140: please have a check for chown user.group

[Marc Haber]

On Sat, Mar 12, 2022 at 08:52:45AM -0800, Russ Allbery wrote:
> Marc Haber  writes:
> > That regexp was copied verbatim from my codesearch search box. Did you
> > forget to switch the dropdown to "regex"?
> 
> > The shadow package contains about ten of those constructs, for example
> 
> > shadow_1:4.11.1+dfsg1-2/contrib/shadow-anonftp.patch
> 
> > -   fprintf (stderr, "%s: line %d: mkdir failed\n",
> > -   Prog, line);
> > -   else if (chown (newpw.pw_dir,
> > -   newpw.pw_uid, newpw.pw_gid))
> > -   fprintf (stderr, "%s: line %d: chown
> > failed\n",
> 
> This specific example is a false positive, though, correct?  I think you
> want to filter out hits that include a parenthesis, since those are likely
> to be calls to the C library function, which doesn't have this issue.

Of course, idiot me. I was not fully awake when I chose this example.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1007170: transition: qtbase-opensource-src

[Dmitry Shachnev]

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

Dear Release Team,

Source code for Qt 5.15.3 was released recently (source code for 5.15.x
is published after a year from the corresponding commercial release).

I have now prepared this release in experimental. As usual, we have private
ABI change for qtbase and qtdeclarative.

Ben file (based on the previous one [1]):

title = "qtbase-opensource-src and qtdeclarative-opensource-src";
is_affected = .depends ~ "qtdeclarative-abi-5-15-2" | .depends ~ 
"qtdeclarative-abi-5-15-3" | .depends ~ "qtbase-abi-5-15-2" | .depends ~ 
"qtbase-abi-5-15-3";
is_good = .depends ~ "qtbase-abi-5-15-3" | .depends ~ 
"qtdeclarative-abi-5-15-3";
is_bad = .depends ~ "qtbase-abi-5-15-2" | .depends ~ "qtdeclarative-abi-5-15-2";

The only blocker known to me is libwebp regression (#1006009), but we can NMU
it again if needed.

[1]: 
https://salsa.debian.org/release-team/transition-data/-/blob/master/old/qtbase-abi-5-15-2.ben

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1007168: paramiko: Paramiko not working with Openssh 8.8p1

[Christophe Trophime]

Source: paramiko
Version: 2.8.1-1
Severity: important

Dear Maintainer,

Since the upgrade of openssh, paramiko is no working
see #1915 issue upstream

This problem has been solved with 2.9 paramiko version
Could you please upgrade paramiko to at least 2.9



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1007167: Acknowledgement (_clock_system.h:34:27: error: using-declaration for non-member at class scope)

[Mathieu Malaterre]

For reference:

* https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/synfig.html

Bug#1007167: _clock_system.h:34:27: error: using-declaration for non-member at class scope

[Mathieu Malaterre]

Source: synfix
Version: 1.4.0+dfsg-2.1
Severity: grave

I cannot compile synfig on sid/amd64. It fails with a cryptic c++
compilation error:

libtool: compile:  g++ -DHAVE_CONFIG_H -I../.. -I../../src -Wdate-time
-D_FORTIFY_SOURCE=2 -I/usr/include -I/usr/include/glibmm-2.4
-I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sigc++-2.0
-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -pthread
-I/usr/include/giomm-2.4 -I/usr/lib/x86_64-linux-gnu/giomm-2.4/include
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/glibmm-2.4
-I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sigc++-2.0
-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include
-I/usr/include/libxml++-2.6
-I/usr/lib/x86_64-linux-gnu/libxml++-2.6/include
-I/usr/include/libxml2 -I/usr/include/glibmm-2.4
-I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/sigc++-2.0
-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -fopenmp
-DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp
-DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp
-DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16
-I/usr/include/x86_64-linux-gnu//ImageMagick-6
-I/usr/include/ImageMagick-6
-I/usr/include/x86_64-linux-gnu//ImageMagick-6
-I/usr/include/ImageMagick-6
-I/usr/include/x86_64-linux-gnu//ImageMagick-6
-I/usr/include/ImageMagick-6 -I/usr/include/cairo
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2
-I/usr/include/libpng16 -pthread -I/usr/include/pango-1.0
-I/usr/include/harfbuzz -I/usr/include/pango-1.0
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/fribidi
-I/usr/include/harfbuzz -I/usr/include/cairo -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16
-I/usr/include/mlt-7/mlt++ -I/usr/include/mlt-7 -I/usr/include/ETL
-I/usr/include/sigc++-2.0
-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -DSYNFIG_NO_DEPRECATED
-DLOCALEDIR=\"/usr/share/locale\"
-DLIBDIR=\"/usr/lib/x86_64-linux-gnu\" -DSYSCONFDIR=\"/etc/synfig\"
-ffile-prefix-map=/home/malat/synfig-1.4.0+dfsg=.
-fstack-protector-strong -Wformat -Werror=format-security -O2 -DNDEBUG
-W -Wall -c target_tile.cpp  -fPIC -DPIC -o
.libs/libsynfig_la-target_tile.o
In file included from /usr/include/ETL/ETL/clock:56,
 from target_tile.cpp:37:
/usr/include/ETL/ETL/_clock_system.h:34:27: error: using-declaration
for non-member at class scope
   34 | # define __sys_clock::clock
  |   ^
In file included from /usr/include/c++/11/mutex:39,
 from node.h:40,
 from valuenode.h:39,
 from canvas.h:40,
 from target.h:39,
 from target_tile.h:32,
 from target_tile.cpp:39:
/usr/include/c++/11/chrono:3373:25: error: expected ';' before '=' token
 3373 |   using __sys_clock = chrono::system_clock;
  | ^
/usr/include/c++/11/chrono:3373:25: error: expected unqualified-id
before '=' token
/usr/include/c++/11/chrono:3385:63: error: type/value mismatch at
argument 1 in template parameter list for 'template struct std::chrono::time_point'
 3385 | _S_from_sys(const chrono::time_point<__sys_clock,
_Dur>& __t) noexcept
  |   ^
/usr/include/c++/11/chrono:3385:63: note:   expected a type, got 'clock'
/usr/include/c++/11/chrono:3394:45: error: type/value mismatch at
argument 1 in template parameter list for 'template struct std::chrono::time_point'
 3394 | chrono::time_point<__sys_clock, _Dur>
  | ^
/usr/include/c++/11/chrono:3394:45: note:   expected a type, got 'clock'
/usr/include/c++/11/chrono: In static member function 'static
std::filesystem::__file_clock::time_point
std::filesystem::__file_clock::now()':
/usr/include/c++/11/chrono:3355:27: error: no matching function for
call to 
'std::filesystem::__file_clock::_S_from_sys(std::chrono::_V2::system_clock::time_point)'
 3355 |   { return _S_from_sys(chrono::system_clock::now()); }
  |~~~^
/usr/include/c++/11/chrono:3385:9: note: candidate: 'template static std::chrono::time_point std::filesystem::__file_clock::_S_from_sys(const int&)'
 3385 | _S_from_sys(const chrono::time_point<__sys_clock,
_Dur>& __t) noexcept
  | ^~~
/usr/include/c++/11/chrono:3385:9: note:   template argument
deduction/substitution failed:
/usr/include/c++/11/chrono:3355:27: note:   couldn't deduce template
parameter '_Dur'
 3355 |   { return 

Bug#948691: thunderbird and MOZ_APP_LAUNCHER

[Simon McVittie]

Control: tags -1 + patch

Steps to reproduce in a test account:

* testing/unstable system (I used a GNOME virtual machine)
* firefox-esr as default web browser (this is the default in GNOME anyway)
* use an expendable uid or a VM, these test steps are destructive
* rm -f ~/.config/mimeapps.list
* Completely exit from both Firefox and Thunderbird
* strace -eexecve -ff thunderbird
* no need to set up an actual email account
* press Alt, Help -> About Thunderbird, click on Privacy Policy
  - It launches firefox as a subprocess (you'll see this in the strace)
* If Firefox asks to be made the default browser:
  - Click "Make Firefox my default browser"
* Completely exit from both Firefox and Thunderbird again
* cat ~/.config/mimeapps.list
* xdg-open http://example.com

Expected result: mimeapps.list doesn't exist, is empty, or lists
firefox-esr as default web browser. example.com opens in Firefox.

Actual result: mimeapps.list has thunderbird.desktop as default for
HTML, HTTP etc., and Thunderbird opens instead of Firefox.

Mitigation: If Firefox is already running before you click the link in
Thunderbird, then the firefox-esr subprocess of Thunderbird just sends an
IPC request to the existing Firefox instance and then exits, so people who
habitually have a web browser open at all times will often not experience
this bug (which is presumably why the Thunderbird maintainers didn't).

On Wed, 09 Mar 2022 at 01:23:08 +, Simon McVittie wrote:
> https://bugs.debian.org/980461 seems to be basically the same bug,
> and points to upstream bug report
> https://bugzilla.mozilla.org/show_bug.cgi?id=1494436 where the
> other suggestion was to remove MOZ_APP_LAUNCHER from the environment
> before launching any external URL or MIME-type handler. I'll try to
> put together a patch for that.

The attached patch for Thunderbird works, and gives me the expected
result: Firefox doesn't ask to be made the default browser, and
doesn't write itself into mimeapps.list as though it was Thunderbird.

Please consider applying this in both unstable and stable: this bug is
really confusing when it happens to a non-technical user.

smcv
From: Simon McVittie 
Date: Wed, 9 Mar 2022 11:22:42 +
Subject: Bug 1494436 - Unset MOZ_APP_LAUNCHER for external MIME handlers

If Thunderbird sets this in its startup script (as it does in Debian
and Fedora), Firefox does not set this in its startup script (it doesn't
in Debian), and Firefox is the handler for clicking a link in
Thunderbird, then Firefox will think it is part of Thunderbird and offer
to make Thunderbird (not Firefox!) the default browser. If the user
accepts this, it will break the ability to open normal HTTP links and
HTML files from other applications.

The same would be true for any other pair of Mozilla-based applications.
To avoid this, unset MOZ_APP_LAUNCHER for the Firefox child process.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1494436
Bug-Debian: https://bugs.debian.org/948691
---
 toolkit/system/gnome/nsGIOService.cpp | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/toolkit/system/gnome/nsGIOService.cpp b/toolkit/system/gnome/nsGIOService.cpp
index 3f0a53b..b2479d2 100644
--- a/toolkit/system/gnome/nsGIOService.cpp
+++ b/toolkit/system/gnome/nsGIOService.cpp
@@ -23,6 +23,17 @@
 
 using namespace mozilla;
 
+static bool GetAppLaunchContext() {
+  GAppLaunchContext* context = g_app_launch_context_new();
+  // Unset this before launching third-party MIME handlers. Otherwise,
+  // if Thunderbird sets this in its startup script (as it does in Debian
+  // and Fedora), and Firefox does not set this in its startup script
+  // (it doesn't in Debian), then Firefox will think it is part of
+  // Thunderbird and try to make Thunderbird the default browser.
+  g_app_launch_context_unsetenv(context, "MOZ_APP_LAUNCHER");
+  return context;
+}
+
 // s. a. the code gtk_should_use_portal() uses to detect if in flatpak env
 // https://gitlab.gnome.org/GNOME/gtk/-/blob/4300a5c609306ce77cbc8a3580c19201dccd8d13/gdk/gdk.c#L472
 static bool GetFlatpakPortalEnv() {
@@ -240,7 +251,9 @@ nsGIOMimeApp::LaunchWithURI(nsIURI* aUri,
   uris.data = const_cast(spec.get());
 
   GError* error = nullptr;
-  gboolean result = g_app_info_launch_uris(mApp, , nullptr, );
+  GAppLaunchContext* context = GetAppLaunchContext();
+  gboolean result = g_app_info_launch_uris(mApp, , context, );
+  g_object_unref(context);
 
   if (!result) {
 g_warning("Cannot launch application: %s", error->message);
@@ -546,7 +559,10 @@ nsGIOService::ShowURI(nsIURI* aURI) {
   nsresult rv = aURI->GetSpec(spec);
   NS_ENSURE_SUCCESS(rv, rv);
   GError* error = nullptr;
-  if (!g_app_info_launch_default_for_uri(spec.get(), nullptr, )) {
+  GAppLaunchContext* context = GetAppLaunchContext();
+  g_app_info_launch_default_for_uri(spec.get(), context, );
+  g_object_unref(context);
+  if (error) {
 g_warning("Could not launch default application for URI: %s",
 

Bug#1007140: please have a check for chown user.group

[Russ Allbery]

Marc Haber  writes:

> That regexp was copied verbatim from my codesearch search box. Did you
> forget to switch the dropdown to "regex"?

> The shadow package contains about ten of those constructs, for example

> shadow_1:4.11.1+dfsg1-2/contrib/shadow-anonftp.patch

> - fprintf (stderr, "%s: line %d: mkdir failed\n",
> - Prog, line);
> - else if (chown (newpw.pw_dir,
> - newpw.pw_uid, newpw.pw_gid))
> - fprintf (stderr, "%s: line %d: chown
>   failed\n",

This specific example is a false positive, though, correct?  I think you
want to filter out hits that include a parenthesis, since those are likely
to be calls to the C library function, which doesn't have this issue.

-- 
Russ Allbery (r...@debian.org)  

Bug#1006009: fixed in libwebp 1.2.2-1

[Dmitry Shachnev]

Control: reopen -1
Control: found -1 libwebp/1.2.2-1

Hi all,

On Thu, Mar 10, 2022 at 11:17:50PM -0500, Andres Salomon wrote:
> Hi,
>
> Are you sure that 1.2.2 fixes the build failure?  The 1.2.2 release was
> tagged on Jan 20th:
>
> https://chromium.googlesource.com/webm/libwebp/+/refs/tags/v1.2.2
>
> The MIPS regression wasn't reported until Feb, and the commit that fixed it
> was made on March 1st:
>
> https://bugs.chromium.org/p/webp/issues/detail?id=558
>
> https://chromium.googlesource.com/webm/libwebp/+/e4cbcdd2b5ff33a64f97fe49d67fb56f915657e8%5E%21/
>
> So it would remain unfixed in 1.2.2-1 unless you patched something else to
> fix it? I don't see that particular commit in the uploaded source:
>
> https://sources.debian.org/src/libwebp/1.2.2-1/src/dsp/lossless_enc_mips32.c/

Indeed, with 1.2.2-1 this bug appears again:

https://buildd.debian.org/status/fetch.php?pkg=qtimageformats-opensource-src=mipsel=5.15.3-1=1647075018=0

Please add back the patch from NMU which was dropped.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Francesco C]

The same here with linux-image-5.16.0-4-686 : different machine but
the same ata controller (ata_piix).

linux-image-5.15.x were all fine ; the same with custom kernels of the
5.15.x series : custom kernels of the 5.16 series all fail to boot and
stop loading at the same point.

Bug#1007166: debianutils: Partial translation of which(1) into hungarian

[Helge Kreutzmann]

Package: debianutils
Version: 5.7
Severity: wishlist

In manpages-l10n we integrated hungarian some time ago. I just
discovered, that the hungarian translation of which(1) is based on the
debianutils one, however, from ~ 20 years ago.

I slightly worked on the po file for the hungarian translation of
which(1), which you will find attached.

Please add this to your po files, so that the translation to hungarian
is included.

I also included how the man page will look like. 

Greetings

   Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/
.\" -*- nroff -*-
.\"***
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"***
.TH WHICH 1 "29 Jun 2016" Debian 
.SH NÉV
which \- megmutatja a parancsok teljes elérési útját
.SH SYNOPSIS
which [\-a] filename ...
.SH LEÍRÁS
\fBwhich\fP returns the pathnames of the files (or links) which would be
executed in the current environment, had its arguments been given as
commands in a strictly POSIX\-conformant shell.  It does this by searching
the PATH for executable files matching the names of the arguments.  It does
not canonicalize path names.
.SH KAPCSOLÓK
.TP 
\fB\-a\fP
print all matching pathnames of each argument
.SH "EXIT STATUS"
.TP 
\fB0\fP
if all specified commands are found and executable
.TP 
\fB1\fP
if one or more specified commands is nonexistent or not executable
.TP 
\fB2\fP
if an invalid option is specified
# Hungarian translation of manpages
# This file is distributed under the same license as the manpages-l10n package.
# Copyright © of this file:
# Horneczki Gábor , 2001.
msgid ""
msgstr ""
"Project-Id-Version: manpages-l10n\n"
"POT-Creation-Date: 2021-08-27 16:30+0200\n"
"PO-Revision-Date: 2001-01-05 12:34+0100\n"
"Last-Translator: Horneczki Gábor \n"
"Language-Team: Hungarian <>\n"
"Language: hu\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Lokalize 20.12.0\n"

#. type: TH
#: original/man1/which.1:2 archlinux fedora-36 fedora-rawhide mageia-cauldron
#: opensuse-leap-15-4 opensuse-tumbleweed
#, no-wrap
msgid "WHICH"
msgstr "WHICH"

#. type: TH
#: original/man1/which.1:2
#, no-wrap
msgid "15 May 1997"
msgstr ""

#. type: TH
#: original/man1/which.1:2
#, no-wrap
msgid "Debian GNU/Linux"
msgstr "Debian GNU/Linux"

#. type: SH
#: original/man1/which.1:3 archlinux fedora-36 fedora-rawhide mageia-cauldron
#: opensuse-leap-15-4 opensuse-tumbleweed
#, no-wrap
msgid "NAME"
msgstr "NÉV"

#. type: Plain text
#: original/man1/which.1:5
msgid "which - locate a command"
msgstr "which - megmutatja a parancsok teljes elérési útját"

#. type: SH
#: original/man1/which.1:5 archlinux fedora-36 fedora-rawhide mageia-cauldron
#: opensuse-leap-15-4 opensuse-tumbleweed
#, no-wrap
msgid "SYNOPSIS"
msgstr "ÁTTEKINTÉS"

#. type: Plain text
#: original/man1/which.1:7
msgid "B"
msgstr "B"

#. type: SH
#: original/man1/which.1:7 archlinux fedora-36 fedora-rawhide mageia-cauldron
#: opensuse-leap-15-4 opensuse-tumbleweed
#, no-wrap
msgid "DESCRIPTION"
msgstr "LEÍRÁS"

#. type: Plain text
#: original/man1/which.1:10
#, fuzzy
msgid ""
"B returns the files which would be executed had its arguments been "
"given as commands."
msgstr ""
"A I beolvas egy programnév sorozatot és kinyomtatja a teljes elérési "
"útját a burok által végrehajtható programoknak.  Mindezt a burok B<$PATH> "
"környezeti változóban megadott elérési út szerinti keresésének "
"szimulálásával végzi."

#. type: SH
#: archlinux fedora-36 fedora-rawhide mageia-cauldron opensuse-leap-15-4
#: opensuse-tumbleweed
#, no-wrap
msgid "OPTIONS"
msgstr "KAPCSOLÓK"

#. type: TP
#: archlinux fedora-36 fedora-rawhide mageia-cauldron opensuse-leap-15-4
#: opensuse-tumbleweed
#, no-wrap
msgid "B<--all>, B<-a>"
msgstr "B<--all>, B<-a>"

#. type: Plain text
#: archlinux fedora-36 fedora-rawhide mageia-cauldron opensuse-leap-15-4
#: opensuse-tumbleweed
msgid "Print all matching executables in B, not just the first."
msgstr ""

#. type: SH
#: archlinux fedora-36 fedora-rawhide mageia-cauldron opensuse-leap-15-4
#: opensuse-tumbleweed
#, no-wrap
msgid "RETURN VALUE"
msgstr "VISSZATÉRÉSI ÉRTÉK"

#. type: Plain text
#: archlinux fedora-36 fedora-rawhide mageia-cauldron opensuse-leap-15-4
#: opensuse-tumbleweed
msgid ""
"B returns the number of failed arguments, or -1 when no \\`programname"
"\\' was given."
msgstr ""

#. type: SH
#: archlinux fedora-36 fedora-rawhide mageia-cauldron opensuse-leap-15-4
#: opensuse-tumbleweed
#, no-wrap
msgid "EXAMPLE"
msgstr "PÉLDA"

#. type: SH
#: archlinux fedora-36 fedora-rawhide mageia-cauldron 

Bug#1004149: python3-pip: Build isolation breaks editable system-wide installs

[Stefano Rivera]

Control: reassign -1 python3.10
Control: affects -1 python3-pip, python3.9

Hi Felix (2022.01.21_14:13:46_-0400)
> Performing an editable system-wide install of this (i.e. running
> `pip install -e` outside a venv) results in a successful pip invocation,
> but a non-importable module:

Did a bit of triage on this bug, and there are several underlying
bugs.

This all comes down to setuptools, which is now configured by python's
sysconfig module, and patched by _distutils_system_mod.

For Python 3.10, this should be resolved by:
https://salsa.debian.org/cpython-team/python3/-/merge_requests/18

So, I'm reassigning this to python3.10.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1004818: os-autoinst: FTBFS: test failure

[Roland Clobus]

On Tue, 1 Feb 2022 23:29:03 +0100 Sebastian Ramacher 
 wrote:

Source: os-autoinst
Version: 4.6.1632799442.f77d4e1-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org
Tags: sid bookworm ftbfs

os-autoinst FTBFS in unstable:

Start 3: test-perl-testsuite

...

It might be that the FTBFS was caused by the Perl transition.
Since then, the package has been rebuilt with success 
(4.6.1632799442.f77d4e1-1+b2), see

https://buildd.debian.org/status/logs.php?pkg=os-autoinst=amd64

Locally, with sbuild, I've been able to build the package as well, 
without issues.


Can this bug report be closed?

With kind regards,
Roland Clobus


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006888: RFP: sasl-xoauth2 -- XOAUTH2 plugin for libsasl2

[Etienne Dechamps]

I would like to second this RFP. I recently received a notification
from Google warning me that they are phasing out password
authentication, which (in the case of my account) will stop working on
May 30. Once that happens, OAuth2 will be the only supported GMail
SMTP authentication mechanism. This in turn means sasl-xoauth2 (or
equivalent) will become a hard requirement to be able to use GMail
SMTP from Postfix, for example.

Bug#1007101: Patch provided

[Roland Clobus]

Hello maintainers,

in build/make.sh the 'js' target was not updated to match the changes in 
the function 'build_repo'.
This caused the line 'cp: missing destination file operand after 
'DataTables.js.build' in the build log 
(https://buildd.debian.org/status/fetch.php?pkg=datatables.js=all=1.11.5%2Bdfsg-1=1646341330=0)


See the attached patch to update the build script.

With kind regards,
Roland Clobus
diff --git a/debian/patches/js-target.patch b/debian/patches/js-target.patch
new file mode 100644
index 000..430cfdc
--- /dev/null
+++ b/debian/patches/js-target.patch
@@ -0,0 +1,12 @@
+--- a/build/make.sh
 b/build/make.sh
+@@ -418,7 +418,8 @@
+ 		;;
+ 
+ 	"js")
+-		build_js
++		build_js umd.js jquery.dataTables js
++		build_js esm.js jquery.dataTables mjs
+ 		;;
+ 
+ 	"css")
diff --git a/debian/patches/series b/debian/patches/series
index 35582f3..83c1950 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 disable_git
 use-tempdir-and-errexit.patch
 use-uglify-and-sassc.patch
+js-target.patch


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007165: please import upstream v21.1.0

[Nicholas D Steeves]

Source: txtorcon
Version: 20.0.0-1
Severity: normal
X-Debbugs-Cc: Jérémy Bobbio 

Hi,

v21.1.0 was released some time ago, and should probably be imported
without delay, because this action may speed resolution of #1006102.

FYI, txtorcon meets the criteria for salvaging, but this is easy to
fix! :-)

  https://wiki.debian.org/PackageSalvaging


Cheers,
Nicholas

Bug#1006912: is it time to have account deletion in policy?

[Roland Clobus]

On 12/03/2022 14:00, Holger Levsen wrote:

On Sat, Mar 12, 2022 at 01:21:24PM +0100, Marc Haber wrote:

Or would it be enough for reproducible images if adduser would finally
implement #243929, making it possible to pre-determine UIDs before an
image is built?


for reproducible images it would be 'enough' but I believe this would also shift
the burden of the work to each and every image designer, so in a way this feels
like a workaround with the main purpose of removing load from base-passwd
maintenance while putting load on everyone else forever :/

Roland Clobus has put a lot of work & thoughts into reproducible images, so I've
added him to cc: now, so he can comment on this aspect of #1006912.


I've read #243929 and #1006912.

For reproducible images (based on live-build) the order of the creation 
of each user is determined by the order in which the packages are 
installed. When the image is built, it starts with the default user 
list, which is then expanded by the packages as they are installed.
When, while (re-)generating an image, an account is deleted, it will 
also be in a deterministic order.
So from the viewpoint of reproducible images, it does not matter in 
which order the lines in  /etc/passwd are, nor whether the same UID 
number is assigned to a username.


With kind regards,
Roland Clobus



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007164: RM: shovill [arm64 ppc64el armhf armel i386 mips64el mipsel ppc64el s390x] -- ROM; Unusable everywhere except amd64

[Nilesh Patra]

Package: ftp.debian.org
Severity: normal


shovill Depends on megahit which is amd64-only and hence shovill
is usable only on amd64.

Please remove the cruft shovill binaries on !amd64 archs.

Regards,
Nilesh

Bug#1007163: opendht: Please use sandboxed unit file

[Federico Ceratto]

Package: opendht
Severity: normal

Dear Maintainer,

opendht ships a SystemD unit file with sandboxing since version 2.1.9.5:
tools/systemd/dhtnode.service.in

Can you please use it? Thanks!

Bug#947918: gtk

[Gürkan Myczko]

Oh and

gtk2, although it's available, I doubt it makes sense to package new 
things in 2022

into Debian. I saw they have gtk3 as well, maybe try that?

Best,

Bug#983109: Build vlc with srt support

[Florian Ernst]

tags 983109 - wontfix
tags 983109 + patch
retitle 983109 Build vlc 3.0.17+ with srt support
thanks

Hello all,

providing some perspective, with my newly-acquired srt maintainer hat
on, and directly adjusting this bug's metadata accordingly.

On Fri, Feb 19, 2021 at 05:05:58PM +0100, Sebastian Ramacher wrote:
> On 2021-02-19 16:34:48, Anton Lundin wrote:
> > >From reading the rules file it looks like #962624 was the reason to not
> > build vlc with srt support. It looks like that bug is fixed to me, and I
> > think it would be nice to include srt support in vlc.
> > 
> > 
> > I took a quick stab at building my own vlc with srt support but i got
> > stpped by:
> > [...]
> > So, there is some incompatibility still left there.
> 
> Given the recent commits
> https://code.videolan.org/videolan/vlc-3.0/-/commit/3aad852a05d9a3b2469328cb9ea2e20b0acbce5c,
> I don't expect vlc 3.0.x to gain support for srt 1.4.x. This needs to be
> fixed upstream first. Once that's done, we can enable srt support again.

Just for reference, development in the "vlc-3.0" repo as linked above
has been discontinued in favor of the "vlc" repo. While the former only
goes up to tag 3.0.14 the latter includes some even older commits that
update SRT usage in VLC, cf.
.

And these changes were released starting with tag 3.0.17 and are still
present in the most recent 3.0.17.3 which was tagged yesterday, cf.

| vlc master ± git diff 3.0.16..3.0.17 -- configure.ac | grep srt
| -PKG_ENABLE_MODULES_VLC([SRT], [access_srt access_output_srt], [srt >= 1.2.2 
srt < 1.3.0], [SRT input/output plugin], [auto], [], [], [-DENABLE_SRT])
| +PKG_ENABLE_MODULES_VLC([SRT], [access_srt access_output_srt], [srt >= 
1.3.0], [SRT input/output plugin], [auto], [], [], [-DENABLE_SRT])
| vlc master ± git diff 3.0.16..3.0.17.3 -- configure.ac | grep srt
| -PKG_ENABLE_MODULES_VLC([SRT], [access_srt access_output_srt], [srt >= 1.2.2 
srt < 1.3.0], [SRT input/output plugin], [auto], [], [], [-DENABLE_SRT])
| +PKG_ENABLE_MODULES_VLC([SRT], [access_srt access_output_srt], [srt >= 
1.3.0], [SRT input/output plugin], [auto], [], [], [-DENABLE_SRT])

I thus simply took upstream 3.0.17.3 and applied the Debian packaging
from 3.0.16-1 to it, then also applied the attached patch and found the
build completing fine, but now with SRT enabled again. The attached
patch more or less reverts the commit 8663ed5 which disabled SRT usage
back in 2020, cf.
.

Here some relevant excerpts from the binary package debdiff:

| New files in second set of .debs, found in package vlc-plugin-access-extra
| --
| -rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/vlc/plugins/access/libaccess_srt_plugin.so
| [...]
| New files in second set of .debs, found in package vlc-plugin-base
| --
| -rw-r--r--  root/root   
/usr/lib/x86_64-linux-gnu/vlc/plugins/access_output/libaccess_output_srt_plugin.so
| [...]
| Control files of package vlc-plugin-access-extra: lines which differ (wdiff 
format)
| 
---
| Depends: libc6 (>= 2.14), {+libsrt1.4-gnutls (>= 1.4.4),+} libvlccore9 (>= 
[-3.0.16),-] {+3.0.17.3),+} libvncclient1 (>= 0.9.10), libxcb-composite0, 
libxcb-shm0, libxcb1 (>= 1.6), vlc-plugin-abi-3-0-0f
| [...]
| Control files of package vlc-plugin-base: lines which differ (wdiff format)
| ---
| Depends: vlc-data (= [-3.0.16-1),-] {+3.0.17.3-0.1),+} liba52-0.7.4 (>= 
0.7.4), libarchive13 (>= 3.1.2), libaribb24-0 (>= 1.0.3), libasound2 (>= 
1.0.27), libass9 (>= 1:0.13.6), libavahi-client3 (>= 0.6.16), libavahi-common3 
(>= 0.6.16), libavc1394-0 (>= 0.5.3), libavcodec58 (>= 7:4.4), libavformat58 
(>= 7:4.4), libavutil56 (>= 7:4.4), libbluray2 (>= 1:1.0.0), libc6 (>= 2.33), 
libcairo2 (>= 1.13.1), libcddb2 (>= 1.3.2), libchromaprint1 (>= 1.3.2), 
libdav1d5 (>= 0.1.0), libdbus-1-3 (>= 1.9.14), libdc1394-25 (>= 2.2.6), libdca0 
(>= 0.0.5), libdvbpsi10 (>= 1.3.0), libdvdnav4 (>= 6.1.0), libdvdread8 (>= 
6.1.0), libebml5 (>= 1.4.2), libfaad2 (>= 2.7), libflac8 (>= 1.3.0), 
libfontconfig1 (>= 2.12.6), libfreetype6 (>= 2.2.1), libfribidi0 (>= 1.0.0), 
libgcc-s1 (>= 3.4), libgcrypt20 (>= 1.9.0), libglib2.0-0 (>= 2.28.0), 
libgnutls30 (>= 3.7.2), libgpg-error0 (>= 1.14), libharfbuzz0b (>= 0.9.4), 
libixml10 (>= 1:1.8.0), libjpeg62-turbo (>= 1.3.1), libkate1 (>= 0.3.0), 
liblirc-client0, liblua5.2-0 (>= 5.2.4), libmad0 (>= 0.15.1b-3), libmatroska7 
(>= 1.6.3), libmpcdec6 (>= 1:0.1~r435), libmpeg2-4 (>= 0.5.1), libmpg123-0 (>= 
1.28.0), libmtp9 (>= 1.1.0), libncursesw6 (>= 6), libnfs13 (>= 1.9.7), libogg0 
(>= 1.1.0), libopenmpt-modplug1 (>= 

Bug#1006912: is it time to have account deletion in policy?

[Marc Haber]

On Sat, Mar 12, 2022 at 01:00:44PM +, Holger Levsen wrote:
> Roland Clobus has put a lot of work & thoughts into reproducible images, so 
> I've
> added him to cc: now, so he can comment on this aspect of #1006912.

Policy editors, I think we can now choose between taking care of the
needs of reproducible images right with this policy change or do
de-scope this temporarily until we have settled on the new wording
(which also includes some definitions) and then handle this in a second
change. I think the second change also needs the base-passwd people in
the loop.

How would you prefer to do this?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#947918: ITP: soundtracker -- Fasttracker II compatible music sequencer and sampler

[Gürkan Myczko]

Hello Thomas and Nilson

SoundTracker is a music sequencer and sampler (aka tracker), that 
allows to
play and edit Fasttracker II modules in the .xm file format and to 
import
Protracker modules in the .mod format. A module is a music file that 
contains

notes and samples.


Are you aware of pt2-clone (.mod) and ft2-clone (nonfree due to 
graphics, .xm)?



Why is this package useful?
 The package is useful for people who work with this music format.


The CLI players modplug-tools (modplug123) and openmpt123 as well as ocp 
(OpenCP
UNIX fork, now original) are playing modules way more accurate than xmp, 
mikmod,

or timidity.


Is it a dependency for another package?
 No.



Do you use it?
 Yes.



How does it compare to other packages?
 * xmp can play .xm files, but not edit them
 * milkytracker provides similar functionality but with a different 
GUI.

 * milkytracker’s timing is less accurate than that of soundtracker, so
modules with sung parts might play out of sync. It is therefor not an
alternative for .xm files containing sung parts or other long samples.


What would be great is however if someone worked on furnace, I've got a 
working
package at sid.ethz.ch/debian/furnace but look at the github page or 
contact me

on irc (tarzeau) what is needed for it to go officially into Debian.

Bug#1007157: gnome-sudoku menu entry is not shown on my pinephone

[Salvo Tomaselli]

I created a patch for upstream
https://gitlab.gnome.org/GNOME/gnome-sudoku/-/merge_requests/40

Il giorno sab 12 mar 2022 alle ore 12:41 Jeremy Bicha
 ha scritto:
>
> On Sat, Mar 12, 2022 at 6:27 AM Salvo 'LtWorf' Tomaselli
>  wrote:
> > I use mobian on a pinephone and gnome-sudoku is not shown among the apps by 
> > default.
> >
> > That's because the .desktop file lacks an entry to mark it as "phone 
> > friendly".
>
> Thank you for taking the time to report this bug.
>
> Please report these issues upstream to GNOME first.
> https://gitlab.gnome.org/GNOME/gnome-sudoku/-/issues
>
> I don't have a phone running mobile GNOME so I'm not sure how to test,
> but I guess Iagno & GNOME Sudoku scale down well enough.
>
> Thanks,
> Jeremy Bicha



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#1007156: iagno menu entry is not shown on my pinephone

[Salvo Tomaselli]

Upstream master already has it
https://gitlab.gnome.org/GNOME/iagno/-/commit/66cbfee802228657f5feb83a14fea869c41cbe56


Il giorno sab 12 mar 2022 alle ore 12:15 Salvo 'LtWorf' Tomaselli
 ha scritto:
>
> Package: iagno
> Version: 1:3.38.1-2
> Severity: normal
> Tags: patch upstream
> X-Debbugs-Cc: tipos...@tiscali.it
>
> Dear Maintainer,
>
> I use mobian on a pinephone and iagno is not shown among the apps by default.
>
> That's because the .desktop file lacks an entry to mark it as "phone 
> friendly".
>
> I attach a 1 line patch to correct the .desktop file.
>
> Best
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages iagno depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
> ii  libc62.33-7
> ii  libcairo21.16.0-5
> ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
> ii  libglib2.0-0 2.70.4-1
> ii  libgsound0   1.0.3-2
> ii  libgtk-3-0   3.24.31-1
> ii  librsvg2-2   2.52.5+dfsg-3+b1
>
> Versions of packages iagno recommends:
> pn  yelp  
>
> iagno suggests no packages.
>
> -- no debconf information



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#1005952: libjs-vega -- programmed web graphics with JSON

[Martin]

Hi,

maybe you like to merge the RFPs #761826 and #1005952?

TIA & Cheers

Bug#1006912: is it time to have account deletion in policy?

[Holger Levsen]

On Sat, Mar 12, 2022 at 01:21:24PM +0100, Marc Haber wrote:
> > unpredictable or non-deterministic allocation of such ids is a cause of non-
> > reproducibiliy for Debian images and installations, so us reproducible folks
> > would like to see "sensible" to be expanded to take reproducible builds into
> > account.
> So we should go (in Policy) more towards "dynamic global UIDs and GIDs
> which may post additional load towards the base-passwd maintainers?

I guess so, yes. :/

> Or would it be enough for reproducible images if adduser would finally
> implement #243929, making it possible to pre-determine UIDs before an
> image is built?

for reproducible images it would be 'enough' but I believe this would also shift
the burden of the work to each and every image designer, so in a way this feels
like a workaround with the main purpose of removing load from base-passwd
maintenance while putting load on everyone else forever :/

Roland Clobus has put a lot of work & thoughts into reproducible images, so I've
added him to cc: now, so he can comment on this aspect of #1006912.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Smart things make us dumb.


signature.asc
Description: PGP signature

Bug#1007162: ITP: emacs-lsp-java -- Java LSP support for emacs

[Thomas Koch]

Package: wnpp
Severity: wishlist
Owner: Thomas Koch 
X-Debbugs-Cc: debian-de...@lists.debian.org, tho...@koch.ro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: emacs-lsp-java
  Version : 0.20211124
  Upstream Author : Ivan Yonchovski
* URL : https://github.com/emacs-lsp/lsp-java
* License : GPL 3+
  Programming Lang: elisp
  Description : Java LSP support for emacs



-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmIsmCAACgkQB/xIkQQr
plpGTQ/+NkUbyU8t+HL5GGlykFin2ODujFKNaUBT7q6W1Z7ogQisKgkHW+uR7qKc
hUA9nKOk9yARKhUXbkqNOXshviayRylkmH9/nSyyiUuNcpis44cfCamZ5sUrW503
k0/dC3/agDctqaO74Qo0UrsDST0A7k7R+Y3qKxEHIO8IFylpngM7POBQvEjqyqaW
NCwmWhVxaTvYlizgb1qnEsndxp+Mcd9TkzPU+XRX8zDhJWWtjLVhAbCJrbX0SwJE
mEoI10F4h5Ftsb+lg4g8GivFi4m4t3X5toWpgcqG0NCR8tVq8KnI36BGr5yIw7zB
T0O7zcIlJzF09eKRXFzQA6rt0qiudClctJ1FpJ4ldGsTKFmqUIdihfMIuWBjL0t3
chufD3+JclvO4V2RKG0GN/BaavkYCjktgZqd4DvwxIxhFBEEYS2LkVwgOLS7N2uQ
shRcgvHVs09bfA9b0YE0n50SfLDeZZYa0UFAFLOodmB63bIpa270G3d3z+g42wTI
ti4TW2xGvyaCJMdxOD8v7L268G+8XXTee+/2RTEn0MsoIp/qNELToJBWheO+Q6/g
gmCr9jySpWfqIUiJEB1P+XEA8TaAu0APxEM6vZAc30GCWexyrZCvKkklLXYrG6Fo
Nxy9Re/8g7oT2wPc3EMtEVcuQcYppZELXnOZAlmeMTZFa/IZ0RY=
=qlrx
-END PGP SIGNATURE-

Bug#955733:

[Laurent GUERBY]

Tested on bullseye genericcloud and same issue of locale not working

https://cloud.debian.org/images/cloud/bullseye/daily/20220310-944/debia
n-11-genericcloud-amd64-daily-20220310-944.qcow2

cloud-init 20.4.1-2+deb11u1

Bug#1007161: ITP: node-concordance -- Node.js library to compare, format, diff and serialize any JavaScript value

[Yadd]

Package: wnpp
Severity: wishlist
Owner: Yadd 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: node-concordance
  Version : 5.0.4
  Upstream Author : Mark Wubben (https://novemberborn.net/)
* URL : https://github.com/concordancejs/concordance
* License : ISC
  Programming Lang: JavaScript
  Description : Node.js library to compare, format, diff and serialize any 
JavaScript value

Concordance recursively describes JavaScript values, whether they're booleans
or complex object structures. It recurses through all enumerable properties,
list items (e.g. arrays) and iterator entries.

The same algorithm is used when comparing, formatting or diffing values. This
means Concordance's behavior is consistent, no matter how you use it.

This library is a dependency of node-ava (not yet packaged), a very
popular JavaScript test suite, needed to test many node packages
(currently we use patches to launch test with tape or jest, but this
disables many subtests and requires a lot of work at each update).

node-concordance will be maintained under JS Team umbrella.

Bug#1007160: ITP: dap-mode -- DAP UI controls implemented using treemacs

[Thomas Koch]

Package: wnpp
Severity: wishlist
Owner: Thomas Koch 
X-Debbugs-Cc: debian-de...@lists.debian.org, tho...@koch.ro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: dap-mode
  Version : 0.7
  Upstream Author : Ivan Yonchovski
* URL : https://github.com/emacs-lsp/dap-mode
* License : GPL 3+
  Programming Lang: elisp
  Description : DAP UI controls implemented using treemacs

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmIskhoACgkQB/xIkQQr
plpVvw//Y7A6FujJySzVsQ2y1oXLCTL5JM66XzxnWD6gUqwK0ZEBfvhxzwcEECFO
CM7zTtyTvjXLkl8hgZYGs2p4cSnqYBaHfKWMLsvHYYIknE0+huNdHlbMjoZltdSB
Yi/srIQj+jzcx7Chh4sADH+ByePXZx+R/EycOdl9B5rbKr9eFIL3jKCNKi2NFMLw
/9Xzr3jkX2unfUVaZKJ7TXy3llyARev/eH9cLP6iPukr7pUx7biePfvXeeEL5rHw
5A0DZy8mH0XCTXsy37oTQhvUfz8j5QIj2HbT4+HtiDIBDopQH5XRytuongnw8Zrf
D0lm7K8T8CUDEQAAfp/hJlkgnvS6dQf0Du8IH6r7zh9IkvvVSmSRXKNozB1lLbvN
pYjqRB4RIHYiz8kOQ02ishf/wxrVoI3jS/c8gxRap6FglfTXVoZ6q3KHhx0yDXqk
PBh6bWJeqPSxKDK1u0RHSlZq8I5lwFTEi80IDbDhuzPaPezFB7akk44QyLUM5CVu
xZPo/4BJYSD/KuPBOcsDeVOHib1/LnhtkWrXfC4oPly57HS9uTmUMFk5dPbg2YLn
yK+Mk00DUsUJiQvEDol0GYqp9Hqr+nB34yYZHVZ9xYoQeBE//BMSg0mKtyGy+sky
7lF+mKP0r4IkviJKQV8aMWwembfs8Sos8vD5X+u1c6qEyV+91S8=
=tfbZ
-END PGP SIGNATURE-

Bug#1006912: is it time to have account deletion in policy?

[Marc Haber]

On Sat, Mar 12, 2022 at 11:58:31AM +, Holger Levsen wrote:
> On Fri, Mar 11, 2022 at 08:15:37PM +0100, Marc Haber wrote:
> > This is my patch.
> 
> I like your patch. :) I just have one comment:
> 
> > +``Dynamic local`` allocated ids should by default be arranged in some
> > +sensible order, but the behavior should be configurable.
> 
> unpredictable or non-deterministic allocation of such ids is a cause of non-
> reproducibiliy for Debian images and installations, so us reproducible folks
> would like to see "sensible" to be expanded to take reproducible builds into
> account.

So we should go (in Policy) more towards "dynamic global UIDs and GIDs
which may post additional load towards the base-passwd maintainers?

Or would it be enough for reproducible images if adduser would finally
implement #243929, making it possible to pre-determine UIDs before an
image is built?

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1006912: is it time to have account deletion in policy?

[Holger Levsen]

Hi Marc,

On Fri, Mar 11, 2022 at 08:15:37PM +0100, Marc Haber wrote:
> This is my patch.

I like your patch. :) I just have one comment:

> +``Dynamic local`` allocated ids should by default be arranged in some
> +sensible order, but the behavior should be configurable.

unpredictable or non-deterministic allocation of such ids is a cause of non-
reproducibiliy for Debian images and installations, so us reproducible folks
would like to see "sensible" to be expanded to take reproducible builds into
account.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

„Ich dachte immer, jeder sei gegen den Krieg, bis ich herausfand, dass es
 welche gibt, die nicht hingehen müssen.“ (Erich Maria Remarque)


signature.asc
Description: PGP signature

Bug#1007159: ITP: lsp-treemacs -- treemacs integration for Emacs LSP

[Thomas Koch]

Package: wnpp
Severity: wishlist
Owner: Thomas Koch 
X-Debbugs-Cc: debian-de...@lists.debian.org, tho...@koch.ro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: lsp-treemacs
  Version : 0.4
  Upstream Author : Ivan Yonchovski
* URL : https://github.com/emacs-lsp/lsp-treemacs
* License : GPL 3+
  Programming Lang: elisp
  Description : treemacs integration for Emacs LSP



-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmIsir4ACgkQB/xIkQQr
plqYZQ//fwx5eDLj2SBFlkgimjFKKD1zGKGfMVU/FbwQGXvdW0vok9yBOG6Qwp/0
ahmo8TdKHziMJFKtrvnnjkZiT5UfvP5P1csYOL9H+Chds91NadPPJqYv5x+zTpSM
wmZZPUEoV/Q0lCSIkrT5PfCzP9iQiHG0XtmY96Np+WBYDPYAkNREQtR8TXgapYWF
Vyx6kHj/JvCQbNAZKusii5pmCwRuXitNaE3BtIaAKk1r6W3TXNZoEEWUHsTF1poS
PVOIuVsGO45SCRVAF87vBcaOdcssqvNvDPoHlwToJEWgG8GV0UhdEGRAFY5MEdEN
Psxt1DkjQsbR6iv1MCeJNMoXwbV2fiThmapSwFwDpj+talfoRZZNSkSzpK18oEG7
AqNMlsHV1T/SRlRHlHkfuKOpMS9FJKEa/68FsjdnImymE8dbyQv8CgVV+/Q3h19K
Diug5vuIsNs+2aivhQcorfvJToYL/UwOelMAyMrn9SSyyVVjZrNkmZGr76Yn7dnX
yfcOmtndkQnjGwOuqWGG7HrRZ6LxCIK8ArNxyjlEYKgr1lEP1Dow46p0c4NRsP9m
AG5VeYcGOyOGavkvXdkkggMuuAChOQNpUP+VPEjN6d/VraaNCfc9hYTjgRgsvamT
3YxD1xizQTbt4bWm/7WbXphxKlF8fWvarPogrvazzeWfNGvkmpo=
=NcLc
-END PGP SIGNATURE-

Bug#1007157: gnome-sudoku menu entry is not shown on my pinephone

[Jeremy Bicha]

On Sat, Mar 12, 2022 at 6:27 AM Salvo 'LtWorf' Tomaselli
 wrote:
> I use mobian on a pinephone and gnome-sudoku is not shown among the apps by 
> default.
>
> That's because the .desktop file lacks an entry to mark it as "phone 
> friendly".

Thank you for taking the time to report this bug.

Please report these issues upstream to GNOME first.
https://gitlab.gnome.org/GNOME/gnome-sudoku/-/issues

I don't have a phone running mobile GNOME so I'm not sure how to test,
but I guess Iagno & GNOME Sudoku scale down well enough.

Thanks,
Jeremy Bicha

Bug#1007158: ITP: emacs-posframe -- Emacs library to Pop a frame at point

[Thomas Koch]

Package: wnpp
Severity: wishlist
Owner: Thomas Koch 
X-Debbugs-Cc: debian-de...@lists.debian.org, tho...@koch.ro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: emacs-posframe
  Version : 1.1.7
  Upstream Author : Feng Shu 
* URL : https://github.com/tumashu/posframe
* License : GPL 3+
  Programming Lang: elisp
  Description : Emacs library to Pop a frame at point



-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmIshtAACgkQB/xIkQQr
ploZLg//a6gw/zv82ftBfMQCJM71uYA37Rkpve0yvDq8S4XHgjdpzRztNO4waXO2
dtH9xtbI2wgCp6zOi2ttobSlQRmLHiTHBC5YLAR8PAYEV9LQSoeSxMHv1NI72Ut+
3bL8kdXrOxJ5yjcO7jGeN6xX4ntMMrlgbDOycxozHaI20+6LeANZGIkx7Rig3ozE
OFrwWYPdNF7jeIF9axMGKL7RRIrUdIZF+/9TOc/rKQA7umKgTENBQeSW+HrXYSoA
IOmP1y0ktW9J8MD7spZJKgWKl2Z9oIfj6ooS91rKck5loIPnMJk1KDte2+Zbu1Ng
YeQjh/NLpjwXOUh6p7MgBYx3tC6OxwV6XR5wHgd7BrfY8wuCgRms+TayekzdFn50
LWj6Y7lglmSRBFEk4Cymm4CY78n1Kz+R5cSWxp9TFLijZQqxKMyBvCDSB/K2rGDq
7fqxtlTD4RFVrSsPOKNJuCsYfvpYrETY6D6cy6pio7ZKTRNUxJnx+8/rsJ9P7cKS
EUzOO3AwwFNBOogd3an+a/dvkRlQOGrushB0/feQ6p9FWMiomo4Vwh03PPVIHTna
JHvcQtMNYFYOWjOH1LfrWBS+la00KlEPutZuIU2bOrMgzRUbp2ls5aAuo2d3fuVx
sO7DRlMDK0X9y/yzSOpE6gZyUSuTRqeWnRYkGnYplE4uArrCPdg=
=Cquu
-END PGP SIGNATURE-

Bug#1007157: gnome-sudoku menu entry is not shown on my pinephone

[Salvo 'LtWorf' Tomaselli]

Package: gnome-sudoku
Version: 1:40.2-1
Severity: normal
Tags: upstream patch
X-Debbugs-Cc: tipos...@tiscali.it

Dear Maintainer,

I use mobian on a pinephone and gnome-sudoku is not shown among the apps by 
default.

That's because the .desktop file lacks an entry to mark it as "phone friendly".

I attach a 1 line patch to correct the .desktop file.

Best

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gnome-sudoku depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libgcc-s112-20220302-1
ii  libgee-0.8-2 0.20.5-1
ii  libglib2.0-0 2.70.4-1
ii  libgtk-3-0   3.24.31-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libpango-1.0-0   1.50.4+ds-1
ii  libpangocairo-1.0-0  1.50.4+ds-1
ii  libqqwing2v5 1.3.4-1.1+b1
ii  libstdc++6   12-20220302-1

Versions of packages gnome-sudoku recommends:
pn  yelp  

gnome-sudoku suggests no packages.

-- no debconf information
Description: Show the app on phosh (mobian)
 This magic entry in the desktop file tells the mobian default launcher,
 phosh, that the application is optimised for a phone sized touchscreen and
 should be shown in the app menu.
Author: Salvo 'LtWorf' Tomaselli 

--- gnome-sudoku-40.2.orig/data/org.gnome.Sudoku.desktop.in
+++ gnome-sudoku-40.2/data/org.gnome.Sudoku.desktop.in
@@ -12,3 +12,4 @@ Categories=GNOME;GTK;Game;LogicGame;
 StartupNotify=true
 Version=1.0
 DBusActivatable=true
+X-Purism-FormFactor=Workstation;Mobile;

Bug#1007156: iagno menu entry is not shown on my pinephone

[Salvo 'LtWorf' Tomaselli]

Package: iagno
Version: 1:3.38.1-2
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: tipos...@tiscali.it

Dear Maintainer,

I use mobian on a pinephone and iagno is not shown among the apps by default.

That's because the .desktop file lacks an entry to mark it as "phone friendly".

I attach a 1 line patch to correct the .desktop file.

Best

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages iagno depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.4-1
ii  libgsound0   1.0.3-2
ii  libgtk-3-0   3.24.31-1
ii  librsvg2-2   2.52.5+dfsg-3+b1

Versions of packages iagno recommends:
pn  yelp  

iagno suggests no packages.

-- no debconf information
Description: Show the app on phosh (mobian)
 This magic entry in the desktop file tells the mobian default launcher,
 phosh, that the application is optimised for a phone sized touchscreen and
 should be shown in the app menu.
Author: Salvo 'LtWorf' Tomaselli 

--- iagno-3.38.1.orig/data/org.gnome.Reversi.desktop.in
+++ iagno-3.38.1/data/org.gnome.Reversi.desktop.in
@@ -14,3 +14,4 @@ Type=Application
 Categories=GNOME;GTK;Game;BoardGame;
 StartupNotify=true
 DBusActivatable=true
+X-Purism-FormFactor=Workstation;Mobile;

Bug#1007155: probably unresolved dependencies in package bind9-dyndb-ldap

[christian_k...@gmx.net]

Package: bind9-dyndb-ldap
Version: 11.6-3
Platform: amd64


Dear Maintainer,

after upgrading my system (Debian Bullseye), I cannot start the naming
service.
With 'systemctl status named.service' I have got the following output:

● named.service - BIND Domain Name Server
 Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor
preset: enabled)
 Active: failed (Result: exit-code) since Sat 2022-03-12 11:33:01
CET; 19min ago
   Docs: man:named(8)
    Process: 1062 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited,
status=1/FAILURE)
   Main PID: 1062 (code=exited, status=1/FAILURE)
    CPU: 62ms

Mär 12 11:33:00 neptun named[1062]: loading DynDB instance 'local_db'
driver '/usr/lib/bind/ldap.so'
*Mär 12 11:33:00 neptun named[1062]: failed to dynamically load instance
'local_db' driver '/usr/lib/bind/ldap.so': libdns-9.16.15-Debian.so:
cannot open shared object file: No such file or directory (failure)**
*Mär 12 11:33:00 neptun named[1062]: dynamic database 'local_db'
configuration failed: failure
Mär 12 11:33:00 neptun named[1062]: loading configuration: failure
Mär 12 11:33:00 neptun named[1062]: exiting (due to fatal error)
Mär 12 11:33:01 neptun systemd[1]: named.service: Scheduled restart job,
restart counter is at 5.
Mär 12 11:33:01 neptun systemd[1]: Stopped BIND Domain Name Server.
Mär 12 11:33:01 neptun systemd[1]: named.service: Start request repeated
too quickly.
Mär 12 11:33:01 neptun systemd[1]: named.service: Failed with result
'exit-code'.
Mär 12 11:33:01 neptun systemd[1]: Failed to start BIND Domain Name Server.

The command 'ldd /usr/lib/bind/ldap.so' says:

   linux-vdso.so.1 (0x7ffda3ab4000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1
(0x7fd4f1ce)
    libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3
(0x7fd4f1c0)
    libldap_r-2.4.so.2 => /lib/x86_64-linux-gnu/libldap_r-2.4.so.2
(0x7fd4f1ba8000)
*    libdns-9.16.15-Debian.so => not found**
**    libisc-9.16.15-Debian.so => not found**
*    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fd4f19e)
    /lib64/ld-linux-x86-64.so.2 (0x7fd4f1d6)
    libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3
(0x7fd4f19b)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
(0x7fd4f19a8000)
    libkrb5support.so.0 =>
/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7fd4f1998000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
(0x7fd4f199)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
(0x7fd4f197)
    liblber-2.4.so.2 => /lib/x86_64-linux-gnu/liblber-2.4.so.2
(0x7fd4f1958000)
    libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2
(0x7fd4f1938000)
    libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30
(0x7fd4f1738000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fd4f171)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd4f1708000)
    libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0
(0x7fd4f15d)
    libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0
(0x7fd4f15a8000)
    libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2
(0x7fd4f142)
    libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6
(0x7fd4f1408000)
    libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8
(0x7fd4f13c)
    libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6
(0x7fd4f137)
    libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10
(0x7fd4f12e8000)
    libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7
(0x7fd4f12d8000)

The output of the command 'apt-cache show bind9-dyndb-ldap | grep
Depends' is:

Depends: bind9-libs (>= 1:9.16.15), libc6 (>= 2.14), libkrb5-3 (>=
1.6.dfsg.2), libldap-2.4-2 (>= 2.4.7), libuuid1 (>= 2.16), bind9 (>= 9.11)

The libraries libdns-9.16.15-Debian.so and libisc-9.16.15-Debian.so are
not installed on my system, instead I have found the files

/lib/x86_64-linux-gnu/libdns-9.16.22-Debian.so
/lib/x86_64-linux-gnu/libisc-9.16.22-Debian.so

So I assume, that there could be a dependency problem.

Best regards,
Christian

Bug#1007154: ftp.debian.org: libwebp_1.2.2-1_amd64 stuck in "Uploaded" state

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: libw...@packages.debian.org
Control: affects -1 src:libwebp

libwebp_1.2.2-1 has been built successfully on all architectures' buildds,
but the amd64 build never progressed past Uploaded state. Perhaps the
upload had unlucky timing relative to recent maintenance?

Is there something that can be done to retrieve this package from wherever
it has got lost, or should I be asking for a binNMU as a workaround?

If this has got stuck because of an infrastructure issue, other packages
might be affected (libwebp just happens to be one that I've noticed
because I have both :amd64 and :i386 installed).

Thanks,
smcv

Bug#1006680: Stopgap

[Barak A. Pearlmutter]

As a stop-gap until this is fixed, you can run this script (as root, obviously).


fix-guake-desktop-link
Description: Binary data

Bug#1007153: ITP: bui-el -- Emacs Buffer interface library

[Thomas Koch]

Package: wnpp
Severity: wishlist
Owner: Thomas Koch 
X-Debbugs-Cc: debian-de...@lists.debian.org, tho...@koch.ro

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: bui-el
  Version : 1.2.1
  Upstream Author : Alex Kost 
* URL : https://github.com/alezost/bui.el
* License : GPL 3+
  Programming Lang: elisp
  Description : Emacs Buffer interface library

 BUI (Buffer User Interface) is a library for making 'list' (similar
 to "M-x list-packages") and 'info' (similar to customization buffers)
 interfaces to display various data (packages, buffers, functions,
 etc.).
 .
 It is not an end-user package, it is a library that is intended to be
 used by other packages.
 .
 Basically, at first you define 'list'/'info' interface using
 `bui-define-interface' macro, and then you can make user commands
 that will display entries using `bui-get-display-entries' and similar
 functions.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmIseQQACgkQB/xIkQQr
plqSqhAAyZtb5dLlyVSU89qGKGLycdh1aJjKWGhkeev63HJj44bP9XEhh0akJwcg
8d27z8B3OeeRYhR5t95Lq5tcA9tyLDO+qVcyQCVRCclT3tkR1axz28BrA1i8ntKy
8dCk+HuhmOAEbJ15iNWQD08t4JmP1AMlFJaGwuBP28BfR6FK0LZ0LtHCowxzdJFn
SPz2cY04pSz31+IgzW+5UJXFUsglAr1x4JXmA1xRP0IhyzTSZUmwvax6dSFnxCMr
pDsjcZ39vbetOooaevBOE7aLtP9RAg+53//nxrz5kTOtWCtAcxeSouHe8THwh+0K
4iMiP1o4MLxKsUC8qLlZnCmh+JyMm5bq8qEV2OzKR/LxbequiZlNZoTyj18Nmkkx
aMukXXSixJRBO1Y/PqkNpBOjtMoQq2/VnGRSgWw+pCYUzr0pxgGU/EqUOetPViNP
wJEmrdIgG8qhCPMUFkPxlWStkigwlbVTVQ6F9sR5CPxbI+fU8vV+7q7YehSDUnwj
mvuY5Ma0dMKueUYmD9LmmX4p/9cDIsPk0nJzec7zNvyiBRaUIA9E8mgUGigE3rnU
rhqIDxk9oZvEBRm/Xl4AIjNjrlT0MrS+xPTCqOq2TKYHHlG/ZVnrfnIV8R+O8PaO
q1hhxTduheLGx9SH6WMDsn4Ng3E+yZJVDfCDDIsCR8r1YFmslfA=
=iCVC
-END PGP SIGNATURE-

Bug#1007108: Fwd: ITP: qpwgraph -- User interface for controlling the PipeWire Graph

[Christopher Obbard]

Hi Dylan,

On 11/03/2022 21:55, Dylan Aïssi wrote:

I had a look at it and of course it is good, nothing that could
prevent me to upload it.


Thank you for looking, your nitpicks are appreciated, since it helps me 
to become a better packager!




- salsa-ci.yml is not needed anymore as we can directly use the config
file from the salsa team:

https://salsa.debian.org/salsa-ci-team/pipeline/blob/master/README.md#basic-use


Right, I initially used dh_make which generated that salsa-ci.yml file. 
I've now removed it from the repo.


Do you think it is worth opening a bug/merge request there to either 
remove the generated file or add a comment about it not being needed any 
more?




- If you plan to maintain this package under the umbrella of the
Debian Multimedia Team, you need to move the git repo under the team
namespace and update the d/control fields accordingly. Just created a
repo for you:

salsa.debian.org:multimedia-team/qpwgraph.git


I've pushed the source there, thanks!



- Is there a specific reason to target the upstream dev website
instead of the gitlab repo in the d/watch file? I guess he can forget
to update it contrary to its gitlab repo.


I did think about that, but most other packages I have seen target the 
upstream's website in the watch file.


For the record, the upstream tarball on the author's website doesn't 
include the gitlab-ci file or some other bits, so they're not the same 
archive as what you would download from gitlab.




- The history of your master and upstream branches is uncommon, I
think you cloned the upstream repo and then imported the upstream
tarball with gbp? It would be cleaner to just create these branches
using gbp import-orig.


Right, I wanted to experiment with keeping the upstream git history 
(like the pipewire packaging) rather than just importing all of the 
files in a single commit like how import-orig would in the usual case. I 
did that by:


$ git init
$ git remote add upstream g...@gitlab.freedesktop.org:rncbc/qpwgraph.git
$ git checkout -b upstream v0.2.2
$ gbp import-orig --upstream-vcs-tag v0.2.2 --pristine-tar 
../qpwgraph-0.2.2.tar.gz



I have recreated those branches using import-orig without the git 
history, so hopefully it is a bit clearer now.



Thanks!
Chris

Bug#1006978: Info received (Bug#1006978: ugrepping /sys/kernel takes too long or grepping /sys/kernel is not thorough)

[Peter Mueller]

Ricardo, could I kindly ask you to please tell the ugrep developer what kind of 
file is /sys/kernel/security/apparmor/revision and why it has size 0, contents 
"10", and behaves in a special way?  They seem not to have Debian at their 
disposal, while I'm not knowledgable enough to make sense of it.  Look:
# ls -laF /sys/kernel/security/apparmor/revision -r--r--r-- 1 root root 0 Mar 
12 01:56 /sys/kernel/security/apparmor/revision # cat 
/sys/kernel/security/apparmor/revision 10 ^C # grep -r dvistyle 
/sys/kernel/security/apparmor grep: /sys/kernel/security/apparmor/revision: 
Resource temporarily unavailable grep: /sys/kernel/security/apparmor/.remove: 
Invalid argument grep: /sys/kernel/security/apparmor/.replace: Invalid argument 
grep: /sys/kernel/security/apparmor/.load: Invalid argument # grep dvistyle 
/sys/kernel/security/apparmor/revision ^C
The ^C messages are caused by me pressing Ctrl+C interrupting hanged processes.

Bug#1007128: apt: [INTL:de] updated German po file translation

[Helge Kreutzmann]

H{a|e}llo David,
On Sat, Mar 12, 2022 at 01:36:59AM +0100, David Kalnischkies wrote:
> thanks for the update!

You are welcome.

> As a German speaker myself, I have a comment through:

Indeed, I did not review this string on debian-l10n-german, so thanks
as well for your feedback. (Rest in German).

> On Fri, Mar 11, 2022 at 05:41:05PM +0100, Helge Kreutzmann wrote:
> > #: methods/gpgv.cc
> > #, c-format
> > msgid ""
> > "Key is stored in legacy trusted.gpg keyring (%s), see the DEPRECATION "
> > "section in apt-key(8) for details."
> > msgstr ""
> > "Schlüssel wird im veralteten Schlüsselbund trusted.gpg gespeichert (%s), "
> > "siehe den Abschnitt MISSBILLIGUNG in apt-key(8) für Details."
> 
> Der Schlüssel IST in diesem Schlüsselbund gespeichert, apt hat ihn dort
> gefunden, deswegen erscheint diese Warnung. "Wird" klingt für mich
> hier stattdessen so wie also würde apt selbst aktiv einen Schlüssel
> dort speichern, statt in dort passiv 'gelagert' vorzufinden.

Deine Formulierung ist näher am Original und ja, meine ist nicht ganz
eindeutig. Soll ich die Zeichenkette ändern und die überarbeitete
Datei Dir schicken oder aktualisierst Du es selber?

> Ist das ein simpler Fehler oder ist der String so für sich alleine
> missverständlich und wir sollten ein //TRANSLATOR: voranstellen der den
> Kontext etwas beleuchtet – und wenn ja Vorschläge?

Ich gebe zu, dass ich vielleicht nicht immer tief genug in den Kontext
abtauche, wenn nur einzelne Zeichenketten zu aktualiseren sind. Wir
haben auf debian-l10n-german lange Diskussionen, wie wortegtreu oder
frei wir übersetzen sollten, daher versuche ich, nicht immer ganz eng
am Original „zu kleben“ - was nicht immer optimal ist (bin auch mehr
der Anhänger der worttreue, soweit möglich). 

Insofern sehe ich das hier nicht als grundsätzliches Problem, der Satz
ist eindeutig, ich habe ihn nur zu frei übersetzt.

Viele Grüße

 Helge


-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1007152: RFP: virtiofsd -- vhost-user virtio-fs device backend written in Rust

[Thomas Koch]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: tho...@koch.ro, debian-r...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: virtiofsd
  Version : 1.1.0
  Upstream Author : multiple, Chromium OS, Intel Corp, Red Hat
* URL : https://gitlab.com/virtio-fs/virtiofsd
* License : BSD and Apache
  Programming Lang: Rust
  Description : vhost-user virtio-fs device backend written in Rust

Implementation of virtio FS: https://virtio-fs.gitlab.io for fast sharing of
host filesystem with a VM guest.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdgQCBVl/ppbxMTvKB/xIkQQrploFAmIsbr4ACgkQB/xIkQQr
plqxEw//VkwmpCB5b+ZTnhpfXSQPd68sl0Vy8mqaqVfJkkKqN9RfxjKZZbimFV0H
uvpK6cyhmWW8EvYn3Di0LBeDcuYPzJ6jEe0p6ammxrdbrotITWklQ/Zv5GF+49sm
BVOKbybNjihuNav6Fhp5DYN9mcJcfFd2vkTLqNGlIrwTngHmzjt3qvh3Y/yqXZ91
WHeWTIQKsp+8jdOJMlvLZNF1tEsSO1sO4qBNk1P1PCiXVlQ0C9M3sqlhyEl4EZQr
IieIELXulSluVmTzeikwRC1QG4Ee88T5o7pcbhHPyAbpJWQNW2v0W8t/10krtNHQ
4vpHpHPM/aMOiyDifQZw+frj4YoPZaEpgpXr5q7Y6paiWFimQ2OU+owYoCShoEsQ
hDNJtwEKKwiCR4HCOd/EgTLkfL7kCu2SCFksMc9WIQJrEjL6D3dKjh6wuj4u6+Ly
yG1zN78ArNwKkak4o68GuX6XP58rItYCZ/GeXqNQwBKj/YeA9QGhdllKkJHNyODb
JxPxnoHJkIlOJILbB340zChvjaA4WD1J9rITUBQ97Idoi/H6eGDDB5kFH7R6Hcqp
xWP1ALk8mjG+UHT5YuioQxwwBgKgx8U3Vtxhmv0fTws+qyV2TV8ZqkT/axNhGJrx
g+koZ0CHvtgctv7lKlQk7SptVzL4dYdM3CHMHMyqrddFFFPoO9M=
=e4xL
-END PGP SIGNATURE-

Bug#1004488: Update grpc to new upstream version 1.37

[GCS]

On Mon, Mar 7, 2022 at 8:50 AM Pirate Praveen  wrote:
> I was not able to build on my laptop due to lack of disk space (40 GB was not 
> sufficient). I was hoping to build it on a vps but temporarily using gem 
> install in gitlab as gitlab is in contrib anyway.
 I think you are a DD and can use any porterbox to build packages.

> Can you share the debs ? or it could take a few days for me to build it.
 OK, I have uploaded those to p.d.o [1]. Small local testing shows
those might be in good shape. Please report back in some days how you
see the status.

Regards,
Laszlo/GCS
[1] https://people.debian.org/~gcs/grpc/

Bug#1007048: latex-cjk-chinese-arphic: please consider upgrading to 3.0 source format

[Hilmar Preuße]

Am 11.03.2022 um 03:45 teilte Danai SAE-HAN (韓達耐) mit:

Hi Danai,


Thanks Lucas.  I'll give it a go.



https://salsa.debian.org/tex-team/latex-cjk-chinese-arphic/-/commit/e5f4b4ab310ac47095e6884d41d5f6173d77cbad

Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006927: /usr/bin/dh_fixperms: please don't make all files executable in subdirectories of /usr/libexec

[Niels Thykier]

Simon McVittie:
> Package: debhelper
> Version: 13.4
> Severity: normal
> File: /usr/bin/dh_fixperms
> 
> In debhelper 13.4, usr/libexec was added to the array @executable_files_dirs
> of directories in which all files are to be made executable.
> 
> I'm not sure that this is necessarily appropriate: several packages install
> files into subdirectories of /usr/libexec that are not directly executable.
> In particular:
> 
> * There is a convention in GLib and GLib-adjacent packages to install
>   "as-installed" integration test suites (for use by e.g. autopkgtest),
>   including both executables and non-executable data, into
>   /usr/libexec/installed-tests
> * Valgrind uses /usr/libexec/valgrind for private data that is
>   a mixture of executables, non-executable XML files, and shared libraries
> * sudo uses /usr/libexec/sudo for plugins
> 
> [...]
>
> I would personally take option 2 and process the @executable_files_dirs
> non-recursively, if it was up to me, because all the use-cases that
> I'm aware of for mixing executable and non-executable files in the
> ${libexecdir} also want to group them into a subdirectory. The other
> @executable_files_dirs don't generally have subdirectories (the only
> counterexamples I know of are /usr/bin/mh/, which has a special exception
> in Policy, and some mh-like mail suites) so processing the other
> directories non-recursively shouldn't have any practical effect on many
> packages.
> 

Thanks for the analysis.  I am happy to review a patch or a MR to this
effect. :)

> In any case, I would hope that we can assume that upstream build systems
> usually chmod executables +x without dh_fixperms' help, because if they
> didn't do that, they would not work as expected in a manual installation
> from source code or in a non-Debian packaging system.
> 
> Thanks,
> smcv
> 
> [...]

Note that `dh_fixperms` is also used by packages where people manually
add a debian specific script to /usr/bin (etc.) besides the upstream
build system (or where there is no upstream build system at all).  Here
it is useful as you cannot set mode (or ownership) via d/install.

Thanks,
~Niels

Bug#1007151: node-fecha: Drop bundled files and rebuild from source

[Yadd]

Package: node-fecha
Version: 4.2.1-2
Severity: serious
Justification: Policy 2.1

Currently package published upstream bundles instead of building them
usinf rollup (even if it is easy).