Bug#1028513: dovecot: autopkgtest failure with python3.11

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 1/12/23 08:10, Bas Couwenberg wrote:

The attached patch resolves the issue by using python3-passlib which has a pure 
Python implementation to fall back on when the crypt module is not available.


I've uploaded a 0-day NMU with the patch from this issue.

The changes are attached and pushed to the repo on Salsa:


https://salsa.debian.org/debian/dovecot/-/commits/debian/1%252.3.19.1+dfsg1-2.1

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff --git a/debian/changelog b/debian/changelog
index 14c1e62e2..22c9a9ce8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dovecot (1:2.3.19.1+dfsg1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * [b02ebc9] Don't use deprecated crypt module.
+(closes: #1028513)
+
+ -- Bas Couwenberg   Fri, 20 Jan 2023 07:01:26 +0100
+
 dovecot (1:2.3.19.1+dfsg1-2) unstable; urgency=medium
 
   [ Christian Göttsche ]
diff --git a/debian/tests/control b/debian/tests/control
index 106e5d04a..496cfcc0b 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -11,4 +11,4 @@ Restrictions: needs-root, breaks-testbed, allow-stderr
 
 Tests: testmails
 Restrictions: needs-root, breaks-testbed
-Depends: dovecot-imapd, dovecot-pop3d, lsb-release, python3
+Depends: dovecot-imapd, dovecot-pop3d, lsb-release, python3, python3-passlib
diff --git a/debian/tests/testmails b/debian/tests/testmails
index 71ae3caab..3329809b5 100755
--- a/debian/tests/testmails
+++ b/debian/tests/testmails
@@ -1,6 +1,5 @@
 #!/usr/bin/python3
 
-import crypt
 import grp
 import imaplib
 import os
@@ -13,6 +12,8 @@ import subprocess
 import sys
 import unittest
 
+from passlib.hash import des_crypt
+
 
 def random_string(length):
 '''Return a random string, consisting of ASCII letters, with given
@@ -57,7 +58,7 @@ class TestUser:
 
 self.salt = random_string(2)
 self.password = random_string(8)
-self.crypted = crypt.crypt(self.password, self.salt)
+self.crypted = des_crypt.using(salt=self.salt).hash(self.password)
 
 subprocess.check_call(['useradd', '-p', self.crypted, '-m', login])
 

Bug#998627:

[Norbert Lange]

On Fri, 20 Jan 2023, 06:52 Salvatore Bonaccorso,  wrote:

> Hi Norbert,
>
> On Thu, Jan 19, 2023 at 11:44:47PM +0100, Norbert Lange wrote:
> > It's been ages, why isn't this enabled by now? How should this driver
> > mature when no one can test it (without going through the hassle if
> > compiling the Kernel).
>
> Thanks for asking back. NTFS3 driver is still not in astate making it
> confident it's wise to enable it for a stable release.
>
>
> https://lore.kernel.org/ntfs3/784f82c4-de71-b8c3-afd6-468869a36...@paragon-software.com/T/#me2324a967514564949f7ebcf3f9a5965f66921bf
> is an example (it took from august to now, until the fix landed in
> mainline).
>
> I think thus the arguments from https://bugs.debian.org/998627#75
> still holds.
>
> Regards,
> Salvatore


Hello Salvatore,

AFAIK kernels receive a ton of patches in distros,
Backported and what not.
Is it not possible to atleast build the module but either blacklist it or
offer it in a separate package?

If it's in a sorry state, then that would direct the complaints to the
module, not to the configuration.

Thanks for the quick response.

Norbert

Bug#1015123: latex-cjk-chinese-arphic: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity

[Hilmar Preuße]

Am 20.12.2022 um 04:08 teilte Danai SAE-HAN (韓達耐) mit:

Hi,


Sorry, I forgot all about this!
I figured out it was a regression so in Unstable you need to go two
versions back for Fontforge, which will ignore the warnings instead of
halting the process.

I'll be back home on 30 December.
Meanwhile I'll send a message upstream.



With the latest upload of fontforge the issue is solved: #1015092 .

We could simply close the bug or tighten the build dep.

Hilmar
--
sigfault

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[Fabian Greffrath]

Hi,

Am Donnerstag, dem 19.01.2023 um 13:57 -0500 schrieb Jorge Moraleda:
> Fabian mentioned that "upstream has decided to rename the binary font
> files and in that course change the file extensions from .pfb to
> .t1." but from the above experiment it seems that upstream changed
> the actual file format, and then they changed the file extensions to
> match the new format.

to be honest, I wasn't even aware of the format change until yesterday.

> IMHO opinion, the solution would be to either not create the symbolic
> links or to preserve the original names including the extension. I
> don't know enough to know what is best.

The symlinks were introduced to facilitate the transition from the
gsfonts package, which had its fonts installed in these directories
with these exact file names. Maybe it makes sense to remove them again
immediately after the next Debian stable release to prevent subtle bugs
like this. @roland what do you think?

 - Fabian



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

Bug#983291: [Pkg-fonts-devel] Bug#983291: fonts-noto-core: Excessive fonts bundles in fonts-noto-core make desired font selection painful

[Jonas Smedegaard]

Quoting Fabian Greffrath (2023-01-20 07:52:49)
> Am Donnerstag, dem 19.01.2023 um 13:12 +0100 schrieb Jonas Smedegaard:
> > The very purpose of Noto is to cover many scripts.
> > If you need latin-cyrillic-greek coverage, pick another o the many
> > fonts covering that smaller scope.
> 
> Sure, I was expecting a stubborn reply...
> 
> However, you contradict yourself here:
> 
> On Mon, 22 Feb 2021 01:19:02 +0100 Jonas Smedegaard  wrote:
> > I agree that it makes sense to split the Noto fonts into more packages.
> 
> On Thu, 25 Feb 2021 05:56:11 +0100 Jonas Smedegaard  wrote:
> > What I will do instead is generally split more fine-grained - for all 
> > all users globally to be able to mix and match.

I stand by those words, and see no contradiction.

Perhaps it helps (at least others following along here) to include the
sentence that I wrote just before the narrow you made above:

> I will *not* split the packaging of Noto fonts to optimize specifically
> for Western society (i.e. Latin + Musical notes + emojis + math bundle).


Kind regards,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#983291: [Pkg-fonts-devel] Bug#983291: fonts-noto-core: Excessive fonts bundles in fonts-noto-core make desired font selection painful

[Fabian Greffrath]

Am Donnerstag, dem 19.01.2023 um 13:12 +0100 schrieb Jonas Smedegaard:
> The very purpose of Noto is to cover many scripts.
> If you need latin-cyrillic-greek coverage, pick another o the many
> fonts covering that smaller scope.

Sure, I was expecting a stubborn reply...

However, you contradict yourself here:

On Mon, 22 Feb 2021 01:19:02 +0100 Jonas Smedegaard  wrote:
> I agree that it makes sense to split the Noto fonts into more packages.

On Thu, 25 Feb 2021 05:56:11 +0100 Jonas Smedegaard  wrote:
> What I will do instead is generally split more fine-grained - for all 
> all users globally to be able to mix and match.

 - Fabian


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

Bug#1029231: Upstream: curl 7.87.0 seems to break curl_multi_socket_action

[Malte Eggers]

Package: libcurl4
Version: 7.87.0-2
Severity: important
Tags: upstream

Dear Maintainer,

Upstream bug: https://github.com/curl/curl/issues/10146
This breaks my matrix client (nheko). I was told a new curl release is planned 
for Feb 15, so this should probably be patched in Debian earlier than that.


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

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

Versions of packages libcurl4 depends on:
ii  libbrotli11.0.9-2+b5
ii  libc6 2.36-8
ii  libgssapi-krb5-2  1.20.1-1
ii  libidn2-0 2.3.3-1+b1
ii  libldap-2.5-0 2.5.13+dfsg-3
ii  libnghttp2-14 1.51.0-1
ii  libpsl5   0.21.0-1.2
ii  librtmp1  2.4+20151223.gitfa8646d.1-2+b2
ii  libssh2-1 1.10.0-3+b1
ii  libssl3   3.0.7-1
ii  libzstd1  1.5.2+dfsg2-3
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages libcurl4 recommends:
ii  ca-certificates  20211016

libcurl4 suggests no packages.

-- no debconf information

Bug#1029229: Relationship between txi2p and python-txi2p-tahoe

[Andrius Merkys]

Hello,

tahoe-lafs maintainers have forked txi2p (ITP #930578) as txi2p-tahoe 
(ITP #1029229) to have Python 3 support which is unavailable in the 
original txi2p. Therefore I intend to package txi2p-tahoe as 
src:python-txi2p-tahoe in Debian to provide the missing dependency for 
tahoe-lafs.


Both txi2p and txi2p-tahoe use the same Python module name txi2p. 
Nevertheless I plan to name txi2p-tahoe binary package 
python3-txi2p-tahoe to avoid possible future name clash (and the need 
for epoch) with mainstream txi2p.


Andrius

Bug#1029217: bullseye-pu: package libapreq2/2.13-7~deb11u1

[Tobias Frost]

On Thu, Jan 19, 2023 at 09:08:20PM +0100, Salvatore Bonaccorso wrote:
> Hi Tobi,
> 
> Small formal review:
> 
> On Thu, Jan 19, 2023 at 08:52:37PM +0100, Tobias Frost wrote:
> > forgot to attach the diff
> > 
> 
> > diff -Nru libapreq2-2.13/debian/changelog libapreq2-2.13/debian/changelog
> > --- libapreq2-2.13/debian/changelog 2019-09-18 09:12:54.0 +0200
> > +++ libapreq2-2.13/debian/changelog 2023-01-19 20:25:21.0 +0100
> > @@ -1,3 +1,10 @@
> > +libapreq2 (2.13-7~deb11u1) UNRELEASED; urgency=high
> 
> The version number should be 2.13-7+deb11u1 in this case. Don't forget
> to set target distribution as well to 'bullseye'.

Thanks for taking a look! I've fixed it in salsa [1].

[1] https://salsa.debian.org/debian/libapreq2/-/tree/debian/bullseye
 
> Regards,
> Salvatore

Bug#1029229: ITP: python-txi2p-tahoe -- txi2p is a set of I2P bindings for Twisted

[Andrius Merkys]

Package: wnpp
Owner: Andrius Merkys 
Control: unblock 995352 by 930578
Control: block 995352 by -1
Severity: wishlist

* Package name: python-txi2p-tahoe
  Version : 0.3.7
  Upstream Author : Aaron Gallagher <_...@habnab.it>
* URL : https://github.com/tahoe-lafs/txi2p
* License : ISC
  Programming Lang: Python
  Description : txi2p is a set of I2P bindings for Twisted

txi2p is a set of I2P bindings for Twisted 10.1 or greater. txi2p
supports both the SAM and BOB APIs for I2P. The default API is SAM.

I am aware of ITP for txi2p (#930578). I will describe their interaction 
in a follow-up message soon.


Remark: This package is to be maintained with Python Team at
   https://salsa.debian.org/python-team/packages/python-txi2p-tahoe

Bug#998627:

[Salvatore Bonaccorso]

Hi Norbert,

On Thu, Jan 19, 2023 at 11:44:47PM +0100, Norbert Lange wrote:
> It's been ages, why isn't this enabled by now? How should this driver
> mature when no one can test it (without going through the hassle if
> compiling the Kernel).

Thanks for asking back. NTFS3 driver is still not in astate making it
confident it's wise to enable it for a stable release. 

https://lore.kernel.org/ntfs3/784f82c4-de71-b8c3-afd6-468869a36...@paragon-software.com/T/#me2324a967514564949f7ebcf3f9a5965f66921bf
is an example (it took from august to now, until the fix landed in
mainline).

I think thus the arguments from https://bugs.debian.org/998627#75
still holds.

Regards,
Salvatore

Bug#1029228: ITP: libhash-safekeys-perl -- get hash contents without resetting each iterator

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libhash-safekeys-perl
  Version : 0.04
  Upstream Author : Marty O'Brien 
* URL : https://metacpan.org/release/Hash-SafeKeys
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : get hash contents without resetting each iterator

Every hash variable in Perl has its own internal iterator, accessed by the
builtin each, keys, and values functions. The iterator is also implicitly
used whenever the hash is evaluated in list context. The iterator is "reset"
whenever keys or values is called on a hash, including the implicit calls
when the hash is evaluated in list context. That makes it dangerous to do
certain hash operations inside a while ... each loop:

while (my($k,$v) = each %hash) {

@k = sort keys %hash; # Infinite loop!

@v = grep { /foo/ }, values %hash; # Ack!

print join ' ', %hash; # Run away!

}


The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1029226: [Pkg-xmpp-devel] Bug#1029226: gajim: Crashes at startup: "No translations found for en_US"

[Brian Vaughan]

$ pdb3 /usr/bin/gajim
> /usr/bin/gajim(3)()
-> import re
(Pdb) cont
No translations found for en_US
Dirs searched: [PosixPath('/home/brian/.local/share'), 
PosixPath('/usr/share/xfce4'), PosixPath('/usr/local/share'), 
PosixPath('/usr/share'), PosixPath('/usr/share')]

No plugin translation path available
Segmentation fault

On 1/19/23 20:17, Brian Vaughan wrote:

$ gajim -v
No translations found for en_US
Dirs searched: [PosixPath('/home/brian/.local/share'), 
PosixPath('/usr/share/xfce4'), PosixPath('/usr/local/share'), 
PosixPath('/usr/share'), PosixPath('/usr/share')]

No plugin translation path available
Logger gajim level set to 10
Logger nbxmpp level set to 20
01/19/2023 20:13:08 (I) gajim  Gajim Version: 1.6.1
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
01/19/2023 20:13:08 (I) gajim  English (en) dict 
available
01/19/2023 20:13:08 (I) gajim  English (Australia) 
(en_AU) dict available
01/19/2023 20:13:08 (I) gajim  English (Canada) 
(en_CA) dict available
01/19/2023 20:13:08 (I) gajim  English (United 
Kingdom) (en_GB) dict available
01/19/2023 20:13:08 (I) gajim  English (United 
States) (en_US) dict available

01/19/2023 20:13:08 (I) gajim  FARSTREAM True
01/19/2023 20:13:08 (I) gajim  GST True
01/19/2023 20:13:08 (I) gajim  AV True
01/19/2023 20:13:08 (I) gajim  GEOCLUE True
01/19/2023 20:13:08 (I) gajim  UPNP False
01/19/2023 20:13:08 (I) gajim  GSOUND True
01/19/2023 20:13:08 (I) gajim  GSPELL True
01/19/2023 20:13:08 (I) gajim  IDLE True
01/19/2023 20:13:08 (I) gajim  APPINDICATOR False
01/19/2023 20:13:08 (I) gajim AYATANA_APPINDICATOR True
01/19/2023 20:13:08 (I) gajim  SENTRY_SDK True
01/19/2023 20:13:08 (I) gajim  Used language: en_US
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.libsecret.Keyring (priority: 4.8)
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.SecretService.Keyring (priority: 5)
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.fail.Keyring (priority: 0)
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.chainer.ChainerBackend (priority: 10)
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.kwallet.DBusKeyring (priority: 4.9)
01/19/2023 20:13:08 (I) gajim.c.passwords  Select 
keyring.backends.chainer.ChainerBackend (priority: 10) backend

01/19/2023 20:13:08 (I) gajim.c.settings   Load app settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load soundevents 
settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load status_presets 
settings

01/19/2023 20:13:08 (I) gajim.c.settings   Load proxies settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load plugins settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load workspaces 
settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: xmpp.earth
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: conversations.im
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: jabber.ccc.de
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: jabber.org
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: lightwitch.org

01/19/2023 20:13:08 (I) gajim.c.settings   Commit
01/19/2023 20:13:08 (I) gajim.c.storage.cache  Connect to 
/home/brian/.cache/gajim/cache.db
01/19/2023 20:13:08 (I) gajim.c.storage.cache  1 DiscoInfo entries 
loaded
01/19/2023 20:13:08 (D) gajim.c.storage.cache  Execution time for 
_fill_disco_info_cache: 18 ms
01/19/2023 20:13:08 (D) gajim.c.storage.cache  Execution time for 
_clean_caps_table: 1 ms
01/19/2023 20:13:08 (D) gajim.c.storage.cache  Execution time for 
_load_caps_data: 1 ms

01/19/2023 20:13:08 (I) gajim.c.storage.events Creating in memory
01/19/2023 20:13:08 (I) gajim.c.storage.events Connect to None
01/19/2023 20:13:08 (I) gajim.c.storage.archive    Connect to 
/home/brian/.local/share/gajim/logs.db
01/19/2023 20:13:08 (D) gajim.c.storage.archive    Execution time for 
_get_jid_ids_from_db: 1 ms

01/19/2023 20:13:08 (I) gajim.c.cert_store 0 Certificates loaded
01/19/2023 20:13:08 (I) gajim.client   Create new nbxmpp 
client
01/19/2023 20:13:08 (I) gajim.c.settings   Set account 
settings: xmpp.earth
01/19/2023 20:13:08 (I) gajim.c.settings   Signal: resource 

Bug#1029226: [Pkg-xmpp-devel] Bug#1029226: gajim: Crashes at startup: "No translations found for en_US"

[Martin]

Thanks! This looks like the same crash, i.e. in libproxy.

Bug#1029226: [Pkg-xmpp-devel] Bug#1029226: gajim: Crashes at startup: "No translations found for en_US"

[Brian Vaughan]

$ gajim -v
No translations found for en_US
Dirs searched: [PosixPath('/home/brian/.local/share'), 
PosixPath('/usr/share/xfce4'), PosixPath('/usr/local/share'), 
PosixPath('/usr/share'), PosixPath('/usr/share')]

No plugin translation path available
Logger gajim level set to 10
Logger nbxmpp level set to 20
01/19/2023 20:13:08 (I) gajim  Gajim Version: 1.6.1
libva info: VA-API version 1.17.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_17
libva info: va_openDriver() returns 0
01/19/2023 20:13:08 (I) gajim  English (en) dict 
available
01/19/2023 20:13:08 (I) gajim  English (Australia) 
(en_AU) dict available
01/19/2023 20:13:08 (I) gajim  English (Canada) 
(en_CA) dict available
01/19/2023 20:13:08 (I) gajim  English (United 
Kingdom) (en_GB) dict available
01/19/2023 20:13:08 (I) gajim  English (United 
States) (en_US) dict available

01/19/2023 20:13:08 (I) gajim  FARSTREAM True
01/19/2023 20:13:08 (I) gajim  GST True
01/19/2023 20:13:08 (I) gajim  AV True
01/19/2023 20:13:08 (I) gajim  GEOCLUE True
01/19/2023 20:13:08 (I) gajim  UPNP False
01/19/2023 20:13:08 (I) gajim  GSOUND True
01/19/2023 20:13:08 (I) gajim  GSPELL True
01/19/2023 20:13:08 (I) gajim  IDLE True
01/19/2023 20:13:08 (I) gajim  APPINDICATOR False
01/19/2023 20:13:08 (I) gajim AYATANA_APPINDICATOR True
01/19/2023 20:13:08 (I) gajim  SENTRY_SDK True
01/19/2023 20:13:08 (I) gajim  Used language: en_US
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.libsecret.Keyring (priority: 4.8)
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.SecretService.Keyring (priority: 5)
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.fail.Keyring (priority: 0)
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.chainer.ChainerBackend (priority: 10)
01/19/2023 20:13:08 (I) gajim.c.passwords  Found keyring 
backend: keyring.backends.kwallet.DBusKeyring (priority: 4.9)
01/19/2023 20:13:08 (I) gajim.c.passwords  Select 
keyring.backends.chainer.ChainerBackend (priority: 10) backend

01/19/2023 20:13:08 (I) gajim.c.settings   Load app settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load soundevents settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load status_presets 
settings

01/19/2023 20:13:08 (I) gajim.c.settings   Load proxies settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load plugins settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load workspaces settings
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: xmpp.earth
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: conversations.im
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: jabber.ccc.de
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: jabber.org
01/19/2023 20:13:08 (I) gajim.c.settings   Load account 
settings: lightwitch.org

01/19/2023 20:13:08 (I) gajim.c.settings   Commit
01/19/2023 20:13:08 (I) gajim.c.storage.cache  Connect to 
/home/brian/.cache/gajim/cache.db
01/19/2023 20:13:08 (I) gajim.c.storage.cache  1 DiscoInfo entries 
loaded
01/19/2023 20:13:08 (D) gajim.c.storage.cache  Execution time for 
_fill_disco_info_cache: 18 ms
01/19/2023 20:13:08 (D) gajim.c.storage.cache  Execution time for 
_clean_caps_table: 1 ms
01/19/2023 20:13:08 (D) gajim.c.storage.cache  Execution time for 
_load_caps_data: 1 ms

01/19/2023 20:13:08 (I) gajim.c.storage.events Creating in memory
01/19/2023 20:13:08 (I) gajim.c.storage.events Connect to None
01/19/2023 20:13:08 (I) gajim.c.storage.archive    Connect to 
/home/brian/.local/share/gajim/logs.db
01/19/2023 20:13:08 (D) gajim.c.storage.archive    Execution time for 
_get_jid_ids_from_db: 1 ms

01/19/2023 20:13:08 (I) gajim.c.cert_store 0 Certificates loaded
01/19/2023 20:13:08 (I) gajim.client   Create new nbxmpp client
01/19/2023 20:13:08 (I) gajim.c.settings   Set account settings: 
xmpp.earth

01/19/2023 20:13:08 (I) gajim.c.settings   Signal: resource changed
01/19/2023 20:13:08 (I) gajim.c.passwords  Request password from 
keyring
01/19/2023 20:13:08 (I) gajim.c.settings   Set account settings: 
xmpp.earth

01/19/2023 20:13:08 (I) gajim.c.settings   Signal: password changed
01/19/2023 20:13:09 (I) gajim.client   Create new nbxmpp client
01/19/2023 20:13:09 (I) gajim.c.settings

Bug#1029226: [Pkg-xmpp-devel] Bug#1029226: gajim: Crashes at startup: "No translations found for en_US"

[Martin]

Hi,

I assume, that the crash is not related to the message, but to this bug:
https://bugs.debian.org/1028638

Could you run `gajim -v` or even run it in a debugger? Maybe you can
check, if it is the same bug.

Cheers

Bug#1029066: diffoscope: FTBFS if no internet is available (using internet connection during build)

[FC Stegerman]

* Chris Lamb  [2023-01-20 01:47]:
[...]
> As to a solution, though, I think this is somewhat blocking on Mattia's
> expertise in the generation of the Python test recommends. Are we, in
> essence, trying to parse the following data in setup.py?
> 
> install_requires=[
> "python-magic",
> "libarchive-c",
> ],
> extras_require={
> "distro_detection": ["distro"],
> "cmdline": ["argcomplete", "progressbar"],
> "comparators": [
> "androguard",
> "binwalk",
> "defusedxml",
> "guestfs",
> "jsondiff",
> "python-debian",
> "pypdf",
> "pyxattr",
> "rpm-python",
> "tlsh",
> ],
> },
> 
> If so, we don't necessarily have to wholesale move to pyproject.toml;
> instead, we could rejig setup.py...?

It seems that way.  And doing so via pep517, which uses pip to install
the requirements in a temporary environment, which I assume is why it
accesses the network sometimes (but not always): to install missing
requirements when the Debian package is not already installed on the
system.

I've proposed an MR [1] that moves the extras_require to a JSON file
and uses that from both setup.py and generate-recommends.py; I've
confirmed it produces the same debian/tests/control.tmp as before.

- FC

[1] https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/121

Bug#1029227: ectrans: reproducible-builds: timestamps and kernel version embeded in /usr/bin/ectrans

[Vagrant Cascadian]

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

The timestamp and kernel version is embedded in /usr/bin/ectrans:
  
  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/ectrans.html

  echo·"··timestamp···:·20240111001706"
  vs.
  echo·"··timestamp···:·20221209195542"

  echo·"··op.·system··:·Linux-6.0.0-0.deb11.2-amd64·(linux.64)"
  vs.
  echo·"··op.·system··:·Linux-5.10.0-19-amd64·(linux.64)"

The attached two patches fix this by using CMAKE_SYSTEM_NAME instead of
CMAKE_SYSTEM, and using CMake's timestamp function for the build date,
which supports a consistent timestamp if the SOURCE_DATE_EPOCH
environment variable is set.

According to my local tests, with these patches applied ectrans should
build reproducibly on tests.reproducible-builds.org once the package
migrates to bookworm/testing!

Unfortunately, there are other outstanding issues with build paths,
which are tested in unstable and experimental.


Thanks for maintaining ectrans!


live well,
  vagrant
From 8807b944d1f770f44304586ddc57a99e9900bc3d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 20 Jan 2023 01:20:29 +
Subject: [PATCH 1/2] src/programs/ectrans.in: Avoid embedding the running
 kernel version.

Use CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM to avoid embedding the
running kernel version.

https://tests.reproducible-builds.org/debian/issues/bookworm/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
---
 src/programs/ectrans.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/programs/ectrans.in b/src/programs/ectrans.in
index a80893d..4d28884 100755
--- a/src/programs/ectrans.in
+++ b/src/programs/ectrans.in
@@ -42,7 +42,7 @@ info()
   echo "Build:"
   echo "  build type  : @CMAKE_BUILD_TYPE@"
   echo "  timestamp   : @EC_BUILD_TIMESTAMP@"
-  echo "  op. system  : @CMAKE_SYSTEM@ (@EC_OS_NAME@.@EC_OS_BITS@)"
+  echo "  op. system  : @CMAKE_SYSTEM_NAME@ (@EC_OS_NAME@.@EC_OS_BITS@)"
   echo "  processor   : @CMAKE_SYSTEM_PROCESSOR@"
   echo "  c compiler  : @CMAKE_C_COMPILER_ID@ @CMAKE_C_COMPILER_VERSION@"
   echo "flags : @EC_C_FLAGS@"
-- 
2.39.0

From 337d2242cfa3b168ce998f1d3747cc5e4c18ce65 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 20 Jan 2023 01:19:06 +
Subject: [PATCH 2/2] Pass BUILD_TIMESTAMP via CMakeLists.txt and use in
 ectrans.in for the build timestamp.

The CMake TIMESTAMP function respects SOURCE_DATE_EPOCH when
specifying UTC timezone.

https://reproducible-builds.org/docs/timestamps/
---
 src/programs/CMakeLists.txt | 1 +
 src/programs/ectrans.in | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/programs/CMakeLists.txt b/src/programs/CMakeLists.txt
index b7cdc1f..74755b1 100644
--- a/src/programs/CMakeLists.txt
+++ b/src/programs/CMakeLists.txt
@@ -50,6 +50,7 @@ foreach( lang ${langs} )
   set( EC_${lang}_FLAGS "${CMAKE_${lang}_FLAGS} ${CMAKE_${lang}_FLAGS_${CMAKE_BUILD_TYPE_CAPS}}" )
 endforeach()
 
+string(TIMESTAMP BUILD_TIMESTAMP "%Y%m%d%H%M%S" UTC)
 configure_file( ectrans.in ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/ectrans @ONLY )
 
 file(COPY ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/ectrans
diff --git a/src/programs/ectrans.in b/src/programs/ectrans.in
index 4d28884..ba52641 100755
--- a/src/programs/ectrans.in
+++ b/src/programs/ectrans.in
@@ -41,7 +41,7 @@ info()
   echo ""
   echo "Build:"
   echo "  build type  : @CMAKE_BUILD_TYPE@"
-  echo "  timestamp   : @EC_BUILD_TIMESTAMP@"
+  echo "  timestamp   : @BUILD_TIMESTAMP@"
   echo "  op. system  : @CMAKE_SYSTEM_NAME@ (@EC_OS_NAME@.@EC_OS_BITS@)"
   echo "  processor   : @CMAKE_SYSTEM_PROCESSOR@"
   echo "  c compiler  : @CMAKE_C_COMPILER_ID@ @CMAKE_C_COMPILER_VERSION@"
-- 
2.39.0



signature.asc
Description: PGP signature

Bug#310442: rdiff-backup: no way to recover from full filesystem

[Paul Wise]

On Thu, 2023-01-19 at 15:28 -0300, Pablo Mestre wrote:

> I'm going to look deeper into this issue and try to reproduce the bug. 

FTR I managed to reproduce it by using GNOME Disks to create a small
disk image in a file, format it with ext4, mount it and repeatedly
backup a small dataset into it until the mount filled up.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1029226: gajim: Crashes at startup: "No translations found for en_US"

[Brian Vaughan]

Package: gajim
Version: 1.6.1-2
Severity: important
X-Debbugs-Cc: bgvaug...@gmail.com

Dear Maintainer,

On starting gajim through the applications menu, the interface appears briefly
before disappearing.

On starting gajim from the command line, an error message appears on the
terminal, then the application interface appears briefly before disappearing.

No translations found for en_US
Dirs searched: [PosixPath('/home/brian/.local/share'),
PosixPath('/usr/share/xfce4'), PosixPath('/usr/local/share'),
PosixPath('/usr/share'), PosixPath('/usr/share')]
No plugin translation path available
Aborted


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

Kernel: Linux 6.1.0-1-amd64 (SMP w/12 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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gajim depends on:
ii  desktop-file-utils   0.26-1
ii  gir1.2-gst-plugins-base-1.0  1.20.5-1
ii  gir1.2-gtk-3.0   3.24.36-1
ii  gir1.2-gtksource-4   4.8.4-4
ii  python3  3.11.1-1
ii  python3-cairo1.20.1-5
ii  python3-cryptography 38.0.4-2
ii  python3-css-parser   1.0.8-1
ii  python3-gi   3.42.2-3
ii  python3-gi-cairo 3.42.2-3
ii  python3-idna 3.3-1
ii  python3-keyring  23.9.3-2
ii  python3-nbxmpp   4.0.1-1
ii  python3-packaging23.0-1
ii  python3-pil  9.4.0-1+b1
ii  python3-precis-i18n  1.0.5-1

Versions of packages gajim recommends:
ii  alsa-utils   1.2.8-1
ii  aspell-en [aspell-dictionary]2018.04.16-0-1
ii  ca-certificates  20211016
ii  dbus 1.14.4-1
ii  fonts-noto-color-emoji   2.038-1
ii  gajim-omemo  2.9.0-1
ii  gajim-openpgp1.5.0-1
ii  gir1.2-farstream-0.2 0.2.9-1
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-gsound-1.01.0.3-2
ii  gir1.2-gspell-1  1.12.0-1+b1
ii  gir1.2-gstreamer-1.0 1.20.5-1
ii  gir1.2-gupnpigd-1.0  1.2.0-3
ii  gir1.2-secret-1  0.20.5-3
ii  gstreamer1.0-gl  1.20.5-1
ii  gstreamer1.0-nice0.1.18-2
ii  gstreamer1.0-plugins-ugly1.20.5-1
ii  notification-daemon  3.20.0-4+b1
ii  pulseaudio-utils 16.1+dfsg1-2+b1
ii  python3-dbus 1.3.2-4
ii  python3-gssapi   1.8.2-1
ii  python3-sentry-sdk   1.9.10-2
ii  xfce4-notifyd [notification-daemon]  0.6.5-1

Versions of packages gajim suggests:
ii  libxss1  1:1.2.3-1
pn  nautilus-sendto  

-- no debconf information

Bug#1020937: libgtk-3-0: fix gl on GLES-only platforms

[Dominique Martinet]

Simon McVittie wrote on Thu, Jan 19, 2023 at 11:22:29AM +:
> 11.7 will not get gtk+3.0_3.24.34-5, regardless. The changes between
> 3.24.24 and 3.24.34 are too extensive to ask the release team to review
> them (1242 lines of changes in gtk/gtkimcontextsimple.c alone) and have
> triggered serious regressions in the past, although I hope all the known
> regressions are now fixed for Debian 12.

Ah, I had misread that as 24-4 -> 24-5 (or 34-4 -> 34-5), 24->34 is
indeed quite bigger; sorry or the confusion.

> What *could* go into either 11.7 or a later 11.x point release is a
> version derived from the version 3.24.24-4+deb11u2 currently in stable,
> with the change that fixes GLES-only platforms applied as a patch. It
> would end up versioned as 3.24.24-4+deb11u3, unless it gets preempted
> by an urgent security fix or something like that.

That'd be appreciated !

> Is upstream commit 0e5fe45ea20cce074a128911949dbedf4f8265bf, from
> , necessary
> and sufficient to fix this in the 3.24.24 codebase? Or are there other
> changes required?

Yes, that commit is necessary & sufficient for my use-case.

> If upstream !5062 is believed to be sufficient, please try building
> 
> (it can be built with git-buildpackage, or let me know if you need a
> complete source package), and verify that it solves the problem for you
> on your GLES-only device(s)/driver(s).

I'll try that today and report back directly on the MR.
While the build runs I've run a diff with the local package I've been
using since late September and changelog entry / name of the patch file
aside the content is identical, so I do not expect any problem for our
workload, but might as well make sure.

> Also, please check that what I've written in the changelog is accurate.
> I don't think I had fully realised until I looked again at this patch
> that while your bug report talks about GTK failing to use GL on GLES-only
> platforms and doesn't mention X11 vs. Wayland, your patch only changes
> the Wayland code path. From a quick look at gdk/x11/gdkglcontext-x11.c,
> it seems your change is making the Wayland/EGL code path match what
> X11/GLX already did, and so you could have worked around this bug with
> GDK_BACKEND=x11, except that presumably you'd prefer to have the benefits
> of using native Wayland?

The changelog entry looks good to me, I'll comment on salsa directly to
leave a trace.
I can confirm that affects only wayland, the purpose of this patch is to
allow epiphany(/WebkitGTK) to run in a kiosk environment and having less
moving parts is appreciable, we currently run without Xwayland so I did
not actually test the X11 backend.

> The other testing that is needed on this version is to confirm that
> it doesn't break anything on Debian 11 systems where "desktop" OpenGL
> *is* available, such as ordinary x86 PCs, and presumably also embedded
> systems that use Mesa (such as the etnaviv driver). I can try it on x86,
> but any testing you can do on this would also improve our confidence
> about this backport.

I'm afraid I also won't be of much help here; my understanding is that
it would also help there (in case both GL and GLES are available,
forcing GLES would still be querying GL for init properties and would
incorrectly try to use potentially missing extensions), but I do not
have any such system to test...
For a "more normal" x86/intel system I'm running bookworm so indirectly
have that patch through 3.24.36-1 and just tested various combinaisons
of setting GDK_GL=gles or not, wayland or native X11, and it all seems
to work properly.
(I'd test the proposed package, but I do not have any stable system with
a destkop environment available right now, sorry)


Thank you for your time and explanations, I'll follow up on salsa unless
prompted here.
-- 
Dominique

Bug#1029066: diffoscope: FTBFS if no internet is available (using internet connection during build)

[Chris Lamb]

Hi all,

> […]

As Mattia writes on the Salsa bug [0], I now don't think this is a
network issue. In other words, the package FTBFS regardless of whether
you have network access or not.

To make debugging this easier, I've split out the inline Python code
in c341b63a [1], and simply running the new script results in:

$ ping -q -c1 google.com 2>&1 | grep packet
1 packets transmitted, 1 received, 0% packet loss, time 0ms

$ debian/tests/generate-recommends.py
ERROR: Could not find an activated virtualenv (required).
Traceback (most recent call last):
  File 
"/home/lamby/git/debian/reproducible-builds/diffoscope/debian/tests/generate-recommends.py",
 line 7, in 
dist = meta.load(".")
   ^^
  File "/usr/lib/python3/dist-packages/pep517/meta.py", line 72, in load
path = Path(build_as_zip(builder))
^
  File "/usr/lib/python3/dist-packages/pep517/meta.py", line 59, in 
build_as_zip
builder(dest=out_dir)
  File "/usr/lib/python3/dist-packages/pep517/meta.py", line 53, in build
env.pip_install(system['requires'])
  File "/usr/lib/python3/dist-packages/pep517/envbuild.py", line 103, in 
pip_install
check_call(
  File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m',
  'pip', 'install', '--ignore-installed', '--prefix',
  '/tmp/pep517-build-env-jzvg739_', 'setuptools', 'wheel']' returned
  non-zero exit status 3.

Regarding when this was introduced, I think a confounding factor is
that this behaviour is reliant on the behaviour of the python3-pep517
package. (Maybe this *was* a network-related issue in the past as
well… but this matters very little now.)

As to a solution, though, I think this is somewhat blocking on Mattia's
expertise in the generation of the Python test recommends. Are we, in
essence, trying to parse the following data in setup.py?

install_requires=[
"python-magic",
"libarchive-c",
],
extras_require={
"distro_detection": ["distro"],
"cmdline": ["argcomplete", "progressbar"],
"comparators": [
"androguard",
"binwalk",
"defusedxml",
"guestfs",
"jsondiff",
"python-debian",
"pypdf",
"pyxattr",
"rpm-python",
"tlsh",
],
},

If so, we don't necessarily have to wholesale move to pyproject.toml;
instead, we could rejig setup.py...?


Chris

[0] 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/325#note_366185
[1] 
https://salsa.debian.org/reproducible-builds/diffoscope/commit/c341b63a4c8cfe56be883b43b4e4faff71fc060e

Bug#1025213: mutter

[Gert van de Kraats]

Thank you for adding gallium i915 to mesa 22.3.2-1. Now at least the
default Debian testing release is usable at my laptop.

But the  problem stills persists, if the i915-driver is removed and
kms_swrast is used.

In fact it is a mutter-problem (43.2-4) with shadow buffering.
Problem can be best viewed by opening a Terminal-window at main
Gnome-Shell window.
After some fast flickering the screen is updated every second which is
driven by the blinking of the cursor at the terminal.
Clearly can be seen the current terminal-line is correctly updated with
blinking cursor, but with 3 different old backgrounds.
If the next minute is started the time at the top is switching between 
previous and current time.


With environment variables MUTTER_DEBUG=kms and COGL_DEBUG=clipping this
can be monitored.

The syslog shows messages
gnome-shell[6588]: Device '/dev/dri/card0' prefers shadow buffer
gnome-shell[6588]: Initialized single buffered shadow fb for VGA-1
gnome-shell[6588]: Initialized single buffered shadow fb for LVDS-1

Shadow buffering is only used at software rendering!
The problem disappears if shadow buffering is disabled at
src/backends/native/meta-kms-impl-device.c at
function should_force_shadow_fb:
return FALSE;

Function drmGetCap is called by mutter to check if the device
prefers shadow buffering.

Bug#1029225: Announced soft freeze date clashes with Ruby team's team-meeting to prepare for Bookworm

[Daniel Leidert]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-r...@lists.debian.org, terce...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

on December 19th, 2022, the Ruby team announced a proposed meeting from
February 6th to 10th 2023 [1,2]. One of the main tasks will be the preparation
for Bookworm and the final switch to Ruby 3.1.

Yesterday, the release team announced the final freeze dates [3].
Unfortunately, the date for the soft freeze is scheduled for February 12th,
which will make it virtually impossible for us to get the packages, which are
not yet in Testing (e.g. the whole Jekyll ecosystem), and the packages, which
are scheduled for removal before the meeting, back into Testing and therefore
into Bookworm.

We would like to ask you to postpone the freeze date(s) by a full week, so we
can care about all affected packages properly and ship them with Bookworm.

I know, that these dates have been proposed a year ago. Unfortunately, nobody
spotted this timing issue sooner. Otherwise, we would have contacted you, of
course.

Regards, Daniel

[1] https://lists.debian.org/debian-sprints/2022/12/msg2.html
[2] https://wiki.debian.org/Teams/Ruby/Meeting/Paris2023
[3] https://lists.debian.org/debian-devel-announce/2023/01/msg4.html

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmPJ31wACgkQS80FZ8KW
0F0+XQ//SX5f0NO5tbfHhV0bqMziEZneXJ5TQVAd/0C0owkCigWy5LprofRyMRUe
DR70CJwd1xsNVqQD9qnN0NrvJX2iT7R0sU28So7u3lefpMh9ISMp3NyqWYnO/CEI
BZ3b8w1iy73REg9pHnYBtvB2z2+WSfwVY6yqq2lpCmN1EDx/tezY2IAtpq/FZ2Up
Vn4f83E7nD/3LgPao/jYzPRtARxod2DfKKTkHUzLged5dSXvSGZPY6Nm1kkIdpCj
mw7o8+5ilsIAc11FiZ6u2Yfy6bj7Qwgds3hGrkA1cZH0lVMlyVyBExY1SRCgqmUO
nSymzomKsfqEOjuZnknVwwz0k2R8ZaId+KfbwSmWt7VtVtZEpT1ztHBPBUuURBeS
B/44Rv6+PLfENB6DT0GjzdidQPNiOGPtbe8tX2qvotbXHmpxSu2820c4eYsdnoMm
6G1xnt6JieFw7FdC6w0BZnA8SJG3KZ9hS5AUe+SVj3BT6CQU1X1HBEEm6CP1JFlT
t7+GqrVjyaiR7FYsTTF6Uc+ZJeprkn2IXF9awYGKzNe1KegXgu4GlsqHF3QSn2lM
4XZ7Jl007PLmez6GhPCvAI+L6jHLcxLqJ90cSFFEhzvpIzjbb2XcZecNENTUY6CT
S3bthBRtZerAIdJxVJfL2f5j9XRLvkoAFjOpVv8AjzXScf9Lve4=
=S4nU
-END PGP SIGNATURE-

Bug#1028877: flask-dance: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.11" returned exit code 13

[Simon Quigley]

Hello,

I have uploaded a fix for this bug to Ubuntu, and uploaded it to the DELAYED/5 
queue also.

If you would rather this be a team upload or would like the delay shortened, 
please do let me know.

Thanks,
--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:linuxdelta.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029224: davegnukem: Does not compile on big endian

[Bastian Germann]

Source: davegnukem
Version: 1.0.3-1
Severity: important

davegnukem does not build on big endian architectures.
The simple fix would be adding a semicolon after the "if (false)" line in 
src/sdl/djgraph.cpp.
It would obviously better to implement a big endian version of whatever that 
code implements
but please take into account that the package has to migrate to testing until 
12th Feb to be in bookworm.

Bug#1028416: systemctl kexec doesn't shutdown system properly and corrupts mounted filesystems

[Khalid Aziz]

On 1/11/23 15:40, Michael Biebl wrote:

Control: reassign -1 kexec-tools

Am 10.01.23 um 20:34 schrieb KOLANICH:

Package: systemd
Version: 252.4-1
Severity: grave
So do kexec-tools if a user has chosen to use it for
reboots during package configuration.
Either of the following can cause fs corruption (to the point one has 
to use `fsck -y`):
a) the procedure described in 
https://wiki.archlinux.org/title/Kexec#Manually
1. `kexec -l /boot/vmlinuz-6.0.0-6-amd64 
--initrd=/boot/initrd-6.0.0-6-amd64 --reuse-cmdline`

2. `systemctl kexec`
b) Just choosing to use kexec for reboots when installing it, and 
then rebooting.


Since systemd basically just calls kexec [1] and running kexec 
directly shows the same issue, let's reassign this to kexec-tools


Michael


[1] 
https://github.com/systemd/systemd/blob/main/src/shutdown/shutdown.c#L584





Can you give me the version of kexec-tools package that you saw this 
issue with?


Thanks,
Khalid

Bug#1029223: lintian: bash-term-in-posix-shell false positive, triggers on "function" in an embedded awk script

[Daniel Kahn Gillmor]

Package: lintian
Version: 2.116.0
Control: affects -1 + libreswan

Lintian, when reviewing libreswan 4.9-1, reports:

I: libreswan: bash-term-in-posix-shell 'function cool(' 
[usr/libexec/ipsec/_secretcensor:31]

But in fact the code in question is:

--
awk '   function cool(hot,   q, cooled, run) {
# warning:  may destroy input line!
q = "'"'"'" # single quote
if (hot ~ q)
--

That is, the code is not a bashism, but rather an input to awk.

This is a false positive.

 --dkg


signature.asc
Description: PGP signature

Bug#986634: 7zr ignores umask for output directory

[MichaIng]

Thanks for the link with the contained patch. Bumping this as it still 
would be great to see it merged:


---
diff FileDir.cpp FileDir_fix.cpp

569c569
< if (mkdir( name, 0700 ) == 0) bret = true;
---
> if (mkdir( name, 0777 & gbl_umask.mask ) == 0) bret = true;
---

Best regards,

Micha

Bug#998627:

[Norbert Lange]

It's been ages, why isn't this enabled by now? How should this driver
mature when no one can test it (without going through the hassle if
compiling the Kernel).

Bug#993590: distro-info-data: Store a mapping from distro to gpg keyring

[Jonathan Wiltshire]

Hi,

On Thu, Jan 19, 2023 at 01:00:29PM -0400, Stefano Rivera wrote:
> > On Fri, 03 Sep 2021 15:16:54 +0200 Johannes Schauer Marin Rodrigues
> >  wrote:
> > > please consider storing a mapping from distro to keyring in
> > > /usr/share/keyring. Currently there is no reliable way to retrieve the
> > > authoritative keyring for a given distro name. Even when limiting
> > > oneself to only Debian, it is not obvious for which suites one needs
> > > /usr/share/keyrings/debian-archive-keyring.gpg and for which one needs
> > > /usr/share/keyrings/debian-archive-removed-keys.gpg.
> > 
> > I am not sure whether distro-info-data is the right place for it. Are
> > there rules when keys move from debian-archive-keyring.gpg to debian-
> > archive-removed-keys.gpg? Shouldn't that information better be shipped
> > by debian-archive-keyring?
> 
> Can someone from the release team answer how this works?

Keys move to the removed keyring when they are no longer needed for
bootstrapping supported or LTS releases (currently, stretch onwards).
That's why there are typically three or four current keys depending on the
phase of the release cycle.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1028565: Acknowledgement (upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64)

[Salvatore Bonaccorso]

Hi Markus,

On Thu, Jan 19, 2023 at 10:21:35PM +0100, Markus Kramer wrote:
> Hi Diederik,
> Thank you for 0001-Revert-ASoC-soc-pcm-Don-t-zero-TDM-masks-in-__soc_pc.patch
> 
> Following chapter 4.2.2 of
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html
> 
> $sudo apt-get install devscripts
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> devscripts is already the newest version (2.21.3+deb11u1).
> 0 upgraded, 0 newly installed, 0 to remove and 67 not upgraded.
> 
> Next step would be to execute
> 
> bash debian/bin/test-patches
> 0001-Revert-ASoC-soc-pcm-Don-t-zero-TDM-masks-in-__soc_pc.patch
> 
> But there is no file test-patches on my client and googled in vain.
> How can I procure test-patches?

Just to be sure, have you performed the steps preceding 4.2.2 and
fetched the source, in particular 4.2.1 pareparation? When you invoke
apt-get source linux, you will get the source package, unpacked it,
and changing with the next step into the source directory you will
find below debian/bin/test-patches.

Hope this helps,

Regards,
Salvatore

Bug#1017907: ffado-mixer-qt4 fails to start with python 3.10

[Bastian Germann]

Control: severity -1 grave

The program is unusable with this, so I am raising the severity appropriately.

Bug#1014166: Is this still accurate?

[Salvatore Bonaccorso]

Hi,

On Thu, Jan 19, 2023 at 04:56:44PM -0500, Ben Westover wrote:
> Hello,
> 
> The CVE description states that versions 0.12.0 - 0.21.1 are vulnerable, but
> this package is currently version 22.0. Can this bug be closed?

A CVE description might only refer to a specific point in time's state
and might not be accurate. It needs first to be confirmed the issue
would be fixed in 0.22.0. 

What are the references confirming the CVE is fixed in 0.22.0? Can you
refer to them so we can re-check?

Regards,
Salvatore

Bug#1029220: coreutils: csplit: expr with lookbehind loses lines vs equivalent no-offset construct

[наб]

For reference, and I don't know if this is the same bug or just related,
but here's the original bug I ran into:

-- >8 --
$ rm xx*; seq 999 | csplit - /10/-5 30 /10/-5 {2} %10% 110
8
70
195
3
3
28
3560
$ head -n9 xx*
==> xx00 <==
1
2
3
4

==> xx01 <==
5
6
7
8
9
10
...
29

==> xx02 <==
30
...
94

==> xx03 <==
95

==> xx04 <==
96

==> xx05 <==
103
104
105
106
107
108
109

==> xx06 <==
110
...
999
-- >8 --

Where'd 100..102 gone?

Compare s:%:/:g:
-- >8 --
$ rm xx*; seq 999 | csplit - /10/-5 30 /10/-5 {2} /10/ 110
8
70
195
3
3
21
28
3560
$ head -n9 xx*
==> xx00 <==
1
2
3
4

==> xx01 <==
5
6
7
8
9
10
...
29

==> xx02 <==
30
...
94

==> xx03 <==
95

==> xx04 <==
96

==> xx05 <==
97
98
99
100
101
102

==> xx06 <==
103
104
105
106
107
108
109

==> xx07 <==
110
...
999
-- >8 --

And compare my diagram:
   /10/-5  30 /10/-5 {2}   %10% 110  expr
  0  1  2rep
  1-4  5-2930-94  95 96 97-99  100-109  110-999  line
  00   01  02 03 04 05 06   07   file
When the "10" regex is %-wrapped, file 05 is not allocated, as expected.

POSIX leaves what happens when applying an expression would leave a
zero-sized file unspecified, which is why it's legal for coreutils
csplit to always eject a line; for comparison, NetBSD  csplit
creates 2 empty files for the /10/-5 {2} expression, for obvious reasons.

Consider therefore the same diagram but vertical
(annotation signifying file start):
-- >8 --
1xx00
2
3
4
5xx01
6
7
8
9
10
...
29
30   xx02
...
94
95xx03
96xx04
97xx05
98
99
100   xx06
101
102
103
104
105
106
107
108
109
110   xx07
...
999
-- >8 --

Since in the csplit language, for a constant input, all expressions sans
%expr% can be reduced to line number expressions¹,
here's the equivalent invocation:
-- >8 --
$ rm xx*; seq 999 | csplit - 5 30 95 96 97 %10% 110
8
70
195
3
3
40
3560
$ head -n9 xx*
==> xx00 <==
1
2
3
4

==> xx01 <==
5
6
7
8
9
10
...
29

==> xx02 <==
30
...
94

==> xx03 <==
95

==> xx04 <==
96

==> xx05 <==
100
101
102
103
104
105
106
107
108
109

==> xx06 <==
110
...
999
-- >8 --

So, again, this appears to be lookbehind rearing its filthy head again.

Best,
наб

¹ I don't think this is strictly true for the strict POSIX dialect
  without a forward-progress hatch, like NetBSD, but it is true for the
  coreutils dialect where a regex expression always ejects a line.
  Whatever, you get the point.


signature.asc
Description: PGP signature

Bug#1029222: lvm2: pvmove keeps opened filehandles on unused PV

[Vincent Danjean]

Package: lvm2
Version: 2.03.11-2.1
Severity: wishlist

  Hi,

  On a machine, I've two VG (aya+raid1 and aya+raid6).
While a pvmove was in progress in aya+raid6, I tried
to remove an unused PV in aya+raid1.
vgreduce worked correctly
pvremove also worked correctly
but, as the PV was a RAID1 mdadm volume, I did not
succeed into stopping it due to pvmove having an
open file descriptor on it:

# vgreduce aya+raid1 /dev/md/aya-raid1-B
  Removed "/dev/md123" from volume group "aya+raid1"
# pvremove /dev/md/aya-raid1-B
  Labels on physical volume "/dev/md/aya-raid1-B" successfully wiped.
# mdadm -S /dev/md/aya-raid1-B
mdadm: failed to stop array /dev/md/aya-raid1-B: Device or resource busy
   Perhaps a running process, mounted filesystem or active volume group?
# lsof /dev/md/aya-raid1-B
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/2001/gvfs
  Output information may be incomplete.
lsof: WARNING: can't stat() fuse.portal file system /run/user/2001/doc
  Output information may be incomplete.
COMMANDPID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pvmove  688244 root   64r   BLK  9,123  0t0  573 /dev/md/../md123

  Looking at fd of pvmove, we can see:
# ls -l /proc/688244/fd
total 0
lrwx-- 1 root root 64 Jan 19 20:19 0 -> /dev/pts/25
lrwx-- 1 root root 64 Jan 19 20:19 1 -> /dev/pts/25
lrwx-- 1 root root 64 Jan 19 20:19 2 -> /dev/pts/25
lrwx-- 1 root root 64 Jan 19 20:19 3 -> 'socket:[15831408]'
lr-x-- 1 root root 64 Jan 19 22:42 42 -> /dev/sde1
lrwx-- 1 root root 64 Jan 19 22:42 5 -> /dev/md119
lr-x-- 1 root root 64 Jan 19 22:42 59 -> /dev/md118
lr-x-- 1 root root 64 Jan 19 22:42 62 -> /dev/md121
lr-x-- 1 root root 64 Jan 19 22:42 63 -> /dev/md122
lr-x-- 1 root root 64 Jan 19 22:42 64 -> /dev/md123
lr-x-- 1 root root 64 Jan 19 22:42 65 -> /dev/md124
lr-x-- 1 root root 64 Jan 19 22:42 66 -> /dev/md125
lrwx-- 1 root root 64 Jan 19 22:42 7 -> /dev/md120
lrwx-- 1 root root 64 Jan 19 22:42 8 -> /dev/md126
lrwx-- 1 root root 64 Jan 19 22:42 9 -> /dev/md127

Starting from the fifth (sde1 and the following ones),
they are all the PV present this system.

The four opened 'rw' (i.e. md119, md120, md126 and md127)
are the one in the VG where the pvmove is running (even
if only md127 and md120 are concerned by the pvmove)

All the others are PV from the other VG (not concerned by
the running pvmove). They are opened 'ro' only. But this
prevent to do some things with them : if it is a disk
partition, it cannot be removed (the kernel tells us it
cannot reload the new partition table). If it is a RAID
block as here, the mdadm RAID cannot be stopped.

It seems to me that there is no reason to keep an
opened file descriptor on PV of other VG when running
the pvmove. And it would be even better if only involved
PV in the involved VG would be locked (but there is
perhaps reason to do so here).

Note: the workaround is easy: just wait the end of the pvmove.

  Regards
Vincent

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

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: 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/bash
Init: systemd (via /run/systemd/system)

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

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.9.0-1

lvm2 suggests no packages.

Bug#1029221: alsa-ucm-conf: Wrong minimum required version for libasound2 dependency in testing/unstable

[Nicolas F. R. A. Prado]

Package: alsa-ucm-conf
Version: 1.2.8-1
Severity: important

Dear Maintainer,

the alsa-ucm-conf package in bookworm and sid, v1.2.8, contains UCM
files with "Syntax 6", which is only supported starting from libasound2
v1.2.7 [1]. To ensure that a sufficiently recent version of libasound2
that can parse all UCM files is installed, the minimum version for
libasound2 should be updated accordingly.


[1]
commit 25e44bbeb976417eebba7323db779a5c44a1a389
Author: Jaroslav Kysela 
Date:   Wed May 18 08:53:34 2022 +0200

ucm: set SYNTAX_VERSION_MAX to 6

$ git describe --contains 25e44bbeb976417eebba7323db779a5c44a1a389
v1.2.7~28


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

Kernel: Linux 6.1.6-arch1-1 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages alsa-ucm-conf depends on:
ii  libasound2  1.2.8-1+b1

alsa-ucm-conf recommends no packages.

alsa-ucm-conf suggests no packages.

-- no debconf information

Bug#1028638: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

[Sebastian Reichel]

Hi,

On Thu, Jan 19, 2023 at 04:12:14PM +0100, Sebastian Reichel wrote:
> On Wed, Jan 18, 2023 at 09:48:33PM +, Martin wrote:
> > Control: severity -1 grave
> > 
> > Justification for grave: Crashes Gajim for some users. RC, IMHO.

If I understood it correctly libproxy is only used by glib
networking code when not running GNOME.

> > On 2023-01-17 21:56, Sebastian Reichel wrote:
> > > I just got the new package through testing and now gajim segfaults
> > > ony my system with stacktrace pointing to libproxy. So this is not
> > > magically solved.
> > 
> > :-(
> > 
> > Could you check, if a downgrade to libproxy 0.4.15-15 helps?
> > That certainly helps to find the bug!
> 
> I tried downgrading libproxy1v5 and libproxy-tools to 0.4.15-15 and
> glib-networking to 2.66.0. This did not change anything.
> 
> With libproxy from testing gajim does work when being downgraded to
> 1.5.4-1 (which requires also downgrading python3-nbxmpp to
> 3.2.5-1 to be functional).

This has been reported upstream:

https://github.com/libproxy/libproxy/issues/199

Also these apparently describe the same bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970687
https://github.com/exaile/exaile/issues/737

Both workarounds mentioned in those bug reports (removing either
/usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so or
/usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0) fix the crash and
gajim successfully connects.

-- Sebastian


signature.asc
Description: PGP signature

Bug#968757: command-not-found: breaks apt-get update

[Diederik de Haas]

Package: command-not-found
Version: 20.10.1-1
Severity: critical
Justification: Breaks unrelated software
Followup-For: Bug #968757

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 01 Sep 2020 15:59:09 +0800 Paul Wise  wrote:
> Control: severity -1 important
> 
> Downgrading this because it does not happen in Debian, only in Debian
> derivatives other than Ubuntu. This happens because it hard-codes
> component priorities and does not have priority values for components
> other than the ones that Debian and Ubuntu use.

Upping the severity (hopefully) as it now does happen in Debian, since 2
days with the following error:

root@bagend:~# aptitude update
Hit http://deb.debian.org/debian bullseye InRelease
Get: 1 http://deb.debian.org/debian testing InRelease [164 kB]
Get: 2 http://deb.debian.org/debian sid InRelease [161 kB]
Get: 3 http://deb.debian.org/debian experimental InRelease [97.5 kB]
Get: 4 http://deb.debian.org/debian testing/main amd64 Packages.diff/Index 
[63.6 kB]
Get: 5 http://security.debian.org/debian-security bullseye-security InRelease 
[48.4 kB]
Get: 6 http://debug.mirrors.debian.org/debian-debug unstable-debug InRelease 
[56.7 kB]
Get: 7 http://deb.debian.org/debian testing/main amd64 Contents 
(deb).diff/Index [63.8 kB]
Get: 8 http://deb.debian.org/debian sid/main Sources.diff/Index [63.6 kB]
Get: 9 http://deb.debian.org/debian sid/non-free Sources.diff/Index [63.3 kB]
Get: 10 http://deb.debian.org/debian sid/main amd64 Packages.diff/Index [63.6 
kB]
Get: 11 http://deb.debian.org/debian sid/main Translation-en.diff/Index [63.6 
kB]
Get: 12 http://deb.debian.org/debian sid/main all Contents (deb).diff/Index 
[63.8 kB]
Get: 13 http://deb.debian.org/debian sid/main amd64 Contents (deb).diff/Index 
[63.8 kB]
Get: 14 http://deb.debian.org/debian sid/contrib Translation-en.diff/Index 
[63.3 kB]
Get: 15 http://deb.debian.org/debian sid/non-free amd64 Packages.diff/Index 
[63.3 kB]
Get: 16 http://deb.debian.org/debian experimental/main amd64 
Packages.diff/Index [63.3 kB]
Get: 17 http://deb.debian.org/debian experimental/main 
Translation-en.diff/Index [63.3 kB]
Get: 18 http://deb.debian.org/debian experimental/main amd64 Contents 
(deb).diff/Index [63.6 kB]
Get: 19 http://deb.debian.org/debian experimental/main all Contents 
(deb).diff/Index [63.6 kB]
Get: 20 http://deb.debian.org/debian experimental/contrib amd64 
Packages.diff/Index [63.3 kB]
Get: 21 http://deb.debian.org/debian experimental/contrib 
Translation-en.diff/Index [63.3 kB]
Get: 22 http://deb.debian.org/debian experimental/contrib amd64 Contents 
(deb).diff/Index [62.8 kB]
Get: 23 http://deb.debian.org/debian experimental/non-free 
Translation-en.diff/Index [63.3 kB]
Get: 24 http://deb.debian.org/debian experimental/non-free all Contents 
(deb).diff/Index [61.4 kB]
Get: 25 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Packages.diff/Index [63.6 kB]
Get: 26 http://deb.debian.org/debian testing/main amd64 Packages 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [458 B]
Get: 27 http://deb.debian.org/debian testing/main amd64 Contents (deb) 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [70 B]
Get: 28 http://deb.debian.org/debian sid/main Sources 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [22.9 kB]
Get: 29 http://deb.debian.org/debian sid/non-free Sources 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [346 B]
Get: 30 http://deb.debian.org/debian testing/main amd64 Packages 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [458 B]
Get: 31 http://deb.debian.org/debian sid/non-free Sources 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [346 B]
Get: 32 http://deb.debian.org/debian sid/main Sources 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [22.9 kB]
Get: 33 http://deb.debian.org/debian testing/main amd64 Contents (deb) 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [70 B]
Get: 34 http://deb.debian.org/debian sid/main amd64 Packages 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [14.0 kB]
Get: 35 http://deb.debian.org/debian sid/main amd64 Packages 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [14.0 kB]
Get: 36 http://debug.mirrors.debian.org/debian-debug unstable-debug/main 
Translation-en.diff/Index [63.3 kB]
Get: 37 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Contents (deb).diff/Index [63.3 kB]
Get: 38 http://deb.debian.org/debian sid/main Translation-en 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [3,772 B]
Get: 39 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Packages T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [14.2 kB]
Get: 40 http://debug.mirrors.debian.org/debian-debug unstable-debug/main 
Translation-en T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [223 B]
Get: 41 http://deb.debian.org/debian sid/main Translation-en 
T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff [3,772 B]
Get: 42 http://debug.mirrors.debian.org/debian-debug unstable-debug/main amd64 
Packages T-2023-01-19-2008.34-F-2023-01-19-2008.34.pdiff 

Bug#909567: ITP: opensnitch -- Port of the Little Snitch application firewall

[Petter Reinholdtsen]

Just for fun, I tried to build the source from Chris on Bullseye, but it
had a few issues.  I cloned it to
https://salsa.debian.org/debian/pkg-opensnitch.git > and applied a
few fixed to get it to build.  Sadly it is not working.

The opensnitch daemon fail to start with the following message in
/var/log/opensnitchd.log:

2023-01-19 21:56:02]  IMP  Starting opensnitch-daemon v1.0.0b
[2023-01-19 21:56:03]  !!!  Error while enabling probe descriptor for 
opensnitch_exec_probe: write /sys/kernel/debug/tracing/kprobe_events: no such 
file or directory

The opensnitch-ui program fail to start with this error:

Traceback (most recent call last):
  File "/usr/bin/opensnitch-ui", line 38, in 
service = UIService(app, on_exit, args.config)
  File "/usr/lib/python3/dist-packages/opensnitch/service.py", line 52, in 
__init__
self._setup_interfaces()
  File "/usr/lib/python3/dist-packages/opensnitch/service.py", line 72, in 
_setup_interfaces
namestr = names.tostring()
AttributeError: 'array.array' object has no attribute 'tostring'

I further tried to build the latest upstream source after importing it
using uscan and gbp import-orig, but could not get it to build.  Do not
know the Go language enough to debug this, but I suspect the issue is
new dependencies missing in Debian.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1014166: Is this still accurate?

[Ben Westover]

Hello,

The CVE description states that versions 0.12.0 - 0.21.1 are vulnerable, 
but this package is currently version 22.0. Can this bug be closed?


Thanks,
--
Ben Westover


OpenPGP_signature
Description: OpenPGP digital signature

Bug#986152: Offer of help

[Romain Francoise]

Hi Jeremy,

On Thu, Jan 19, 2023 at 7:01 PM Jeremy Sowden  wrote:
> I've pushed all the work to my repo on Salsa:
>
>   https://salsa.debian.org/azazel/shorewall
>
> Do you want to review it before I push to the shorewall-team repo?

It all looks pretty good to me! In fact, it's a radical improvement
over the previous packaging with seven source packages.

I've been staring at the diffoscope output for a few hours and I was
wondering why /etc/network/if-down.d/shorewall seemed to disappear in
shorewall-init but that's actually an upstream change from
5.2.5-beta1. All the other cleanups and changes look sensible to me,
especially the removal of the debconf bits.

I have not yet actually tested the packages in my lab but please feel
free to push your changes to the team repo, and I will do the final
testing and upload over the week-end. I can also take care of opening
the bugs to have the previous source packages removed from unstable.

Thanks again for the huge amount of work you put in!

> The 5.2.8 source package closes the following bugs:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852

Awesome.

> In addition, I think these are candidates for manual closure:
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217

Yup. You already marked #928912 as fixed, so nothing more to do there.

Bug#1029220: coreutils: csplit: expr with lookbehind loses lines vs equivalent no-offset construct

[наб]

Package: coreutils
Version: 9.1-1
Severity: normal

Dear Maintainer,

I've extracted the following from a break-down
I've been having for the past three hours (annotated):
-- >8 --
$ seq 90 110 | cat -n
 1  90 xx00
 2  91
 3  92
 4  93
 5  94
 6  95 xx01
 7  96
 8  97
 9  98
10  99
11  100xx02
12  101
13  102
14  103
15  104
16  105
17  106
18  107
19  108
20  109
21  110
-- >8 --

For the presented input, both of the following constructs are equivalent:
  csplit - /10/-5 %10%
  csplit - /95/   %10%

And yet:
-- >8 --
$ rm xx*; seq 90 110  | csplit - /10/-5 %10%; head -n xx0*
15
40
==> xx00 <==
90
91
92
93
94

==> xx01 <==
101
102
103
104
105
106
107
108
109
110
$ rm xx*; seq 90 110  | csplit - /95/ %10%; head -n xx0*
15
44
==> xx00 <==
90
91
92
93
94

==> xx01 <==
100
101
102
103
104
105
106
107
108
109
110
-- >8 --

Additionally to the triviality of this observation,
NetBSD agrees with my assessment.

Best,
наб

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.3.1-2
ii  libattr1 1:2.5.1-3
ii  libc62.36-7
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b4

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1029219: devscripts: Please compress files in parallel

[Sebastian Andrzej Siewior]

Package: devscripts
Version: 2.22.2
Severity: wishlist

uscan can created a repacked file based on d/copyright and I *think*
this is handled by devscripts. It invokes `xz' for compression without
the -T flag. Passing the -T argument with either 0 or 1 as the number of
CPUs has the following benefits:
- The actual compression is quicker if more than one CPU is available on
  the compressing side.
- The actual decompression is quicker if more than one CPU is available
  on the decompressing side. This requires that the compressor creates
  multiple blocks while compressing.

I tried to fix this myself but I fail to find the right spot :/

Sebastian

Bug#1029182: Just rebuild with psycopg 3.1.7-4

[Tomasz Rybak]

I noticed this bug, and similar for python-pgspecial.
You can fix it by rebuilding with python3-psycopg 3.1.7-4,
like I've just done with python-pgspecial.
Long story short - dh_python3 has hardcoded mapping
of psycopg to python3-psycopg3, and this is added to binary
dependencies via python3:Depends; you can find details in
https://lists.debian.org/debian-python/2023/01/msg00051.html
I added pydist override to psycopg 3.1.7-4.

I also experimented a bit with rebuilding pgcli; you could replace
line 28 of debian/control
python3-psycopg | python3-psycopg3 (>= 3.0.14)
with
python3-psycopg,
(see attached diff file) and it'll generate proper
dependency on python3-psycopg (>= 3.0.14).
Full dependency after this change looks like:
Depends: python3-cli-helpers, python3-pendulum, python3-pgspecial (>=
2), python3-pkg-resources, python3-prompt-toolkit (>= 3.0), python3-
psycopg (>= 3.0.14), python3-sqlparse (>= 0.3), python3-tabulate,
python3-terminaltables, python3-click, python3-configobj, python3-
pygments, python3-setproctitle, python3:any

Best regards.

-- 
Tomasz Rybak, Debian Developer 
GPG: A565 CE64 F866 A258 4DDC F9C7 ECB7 3E37 E887 AA8C
diff --git a/debian/control b/debian/control
index c414842..9cc1f84 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Depends:
  python3-pgspecial (>= 2),
  python3-pkg-resources,
  python3-prompt-toolkit (>= 3.0),
- python3-psycopg | python3-psycopg3 (>= 3.0.14),
+ python3-psycopg,
  python3-sqlparse (>= 0.3),
  python3-tabulate,
  python3-terminaltables,


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

Bug#1028565: Acknowledgement (upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64)

[Markus Kramer]

Hi Diederik,
Thank you for 0001-Revert-ASoC-soc-pcm-Don-t-zero-TDM-masks-in-__soc_pc.patch

Following chapter 4.2.2 of
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html

$sudo apt-get install devscripts
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
devscripts is already the newest version (2.21.3+deb11u1).
0 upgraded, 0 newly installed, 0 to remove and 67 not upgraded.

Next step would be to execute

bash debian/bin/test-patches
0001-Revert-ASoC-soc-pcm-Don-t-zero-TDM-masks-in-__soc_pc.patch

But there is no file test-patches on my client and googled in vain.
How can I procure test-patches?

Best regards,
Markus

Bug#1029218: dkms should perform reproducible build of modules

[Daniel Richard G.]

Package: dkms
Version: 3.0.10-1
Severity: wishlist

If I install the same DKMS package on two identically-configured Debian
sid systems, the resulting kernel modules are not bit-for-bit identical.

The integrity of kernel modules is critical to a secure system, and
ensuring that their builds are reproducible will help make that quality
significantly easier to verify.


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1027830: openssl: starttls fails on our LDAP server on bullseye, but it works on buster

[Sebastian Andrzej Siewior]

On 2023-01-19 12:02:52 [-0800], Ryan Tandy wrote:
> Hello Jonathan and Sebastian.
Hi Ryan,

> In any case I believe the use of Recommends is Policy-compliant since there
> are myriad ways to specify the trusted CAs and the default ldap.conf setting
> is only for convenience.

It sounds reasonable. Thank you for the detailed explanation.

> thanks,
> Ryan

Sebastian

Bug#1029217: bullseye-pu: package libapreq2/2.13-7~deb11u1

[Salvatore Bonaccorso]

Hi Tobi,

Small formal review:

On Thu, Jan 19, 2023 at 08:52:37PM +0100, Tobias Frost wrote:
> forgot to attach the diff
> 

> diff -Nru libapreq2-2.13/debian/changelog libapreq2-2.13/debian/changelog
> --- libapreq2-2.13/debian/changelog   2019-09-18 09:12:54.0 +0200
> +++ libapreq2-2.13/debian/changelog   2023-01-19 20:25:21.0 +0100
> @@ -1,3 +1,10 @@
> +libapreq2 (2.13-7~deb11u1) UNRELEASED; urgency=high

The version number should be 2.13-7+deb11u1 in this case. Don't forget
to set target distribution as well to 'bullseye'.

Regards,
Salvatore

Bug#1029174: dhcpcd-base: Brakes networking completely

[Krzysztof Aleksander Pyrkosz]

Package: dhcpcd-base
Followup-For: Bug #1029174
X-Debbugs-Cc: krzpyrk...@gmail.com

Dear Maintainer,
I've ran onto the same issue on a riscv64 board yesteday. Upgrading to
9.4.1-14 solved the problem.

Bug#1029217: bullseye-pu: package libapreq2/2.13-7~deb11u1

[Tobias Frost]

forgot to attach the diff

diff -Nru libapreq2-2.13/debian/changelog libapreq2-2.13/debian/changelog
--- libapreq2-2.13/debian/changelog	2019-09-18 09:12:54.0 +0200
+++ libapreq2-2.13/debian/changelog	2023-01-19 20:25:21.0 +0100
@@ -1,3 +1,10 @@
+libapreq2 (2.13-7~deb11u1) UNRELEASED; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Backport fix for CVE-2022-22728. (Closes: #1018191)
+
+ -- Tobias Frost   Thu, 19 Jan 2023 20:25:21 +0100
+
 libapreq2 (2.13-7) unstable; urgency=high
 
   * Source-only upload.
diff -Nru libapreq2-2.13/debian/patches/10-CVE-2022-22728_1of4.patch libapreq2-2.13/debian/patches/10-CVE-2022-22728_1of4.patch
--- libapreq2-2.13/debian/patches/10-CVE-2022-22728_1of4.patch	1970-01-01 01:00:00.0 +0100
+++ libapreq2-2.13/debian/patches/10-CVE-2022-22728_1of4.patch	2023-01-19 20:24:24.0 +0100
@@ -0,0 +1,385 @@
+Description: CVE-2022-22728 -- multipart form parse memory corruption
+ A flaw in Apache libapreq2 versions 2.16 and earlier could cause a
+ buffer overflow while processing multipart form uploads. A remote
+ attacker could send a request causing a process crash which could lead
+ to a denial of service attack.
+ This is #1 of 4 patches, see also https://www.openwall.com/lists/oss-security/2023/01/02/2
+Origin: https://svn.apache.org/viewvc?view=revision=1894937
+Bug-Debian: https://bugs.debian.org/1018191
+Reviewed-by: Tobias Frost 
+Last-Update: 2023-01-13 
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/library/parser_header.c
 b/library/parser_header.c
+@@ -39,7 +39,10 @@
+ HDR_GAP,
+ HDR_VALUE,
+ HDR_NEWLINE,
+-HDR_CONTINUE,
++HDR_CONTLINE,
++HDR_WANTLINE,
++HDR_NEXTLINE,
++HDR_LASTLINE,
+ HDR_COMPLETE,
+ HDR_ERROR
+ }   status;
+@@ -59,16 +62,17 @@
+ apreq_value_t *v;
+ apr_bucket *e, *f;
+ apr_status_t s;
+-struct iovec vec[APREQ_DEFAULT_NELTS], *iov, *end;
+-apr_array_header_t arr;
++struct iovec vec[APREQ_DEFAULT_NELTS], *iov;
++apr_array_header_t arr, *a = 
+ char *dest;
+ const char *data;
+ apr_size_t dlen;
++int i;
+ 
+ if (nlen == 0)
+ return APR_EBADARG;
+ 
+-param = apreq_param_make(pool, NULL, nlen, NULL, vlen - 1); /*drop (CR)LF */
++param = apreq_param_make(pool, NULL, nlen, NULL, vlen);
+ *(const apreq_value_t **) = >v;
+ 
+ arr.pool = pool;
+@@ -80,67 +84,78 @@
+ e = APR_BRIGADE_FIRST(bb);
+ 
+ /* store name in a temporary iovec array */
+-
+ while (nlen > 0) {
+ apr_size_t len;
+-end = apr_array_push();
+-s = apr_bucket_read(e, (const char **)>iov_base,
++
++if (a->nelts == a->nalloc) {
++a = apr_array_make(pool, arr.nalloc * 2, sizeof(struct iovec));
++memcpy(a->elts, arr.elts, arr.nelts * sizeof(struct iovec));
++a->nelts = arr.nelts;
++}
++iov = (struct iovec *)apr_array_push(a);
++
++assert(e != APR_BRIGADE_SENTINEL(bb));
++s = apr_bucket_read(e, (const char **)>iov_base,
+ , APR_BLOCK_READ);
+ if (s != APR_SUCCESS)
+ return s;
++iov->iov_len = len;
+ 
+ assert(nlen >= len);
+-end->iov_len = len;
+ nlen -= len;
+ 
+ e = APR_BUCKET_NEXT(e);
+ }
+ 
+ /* skip gap */
+-
+ while (glen > 0) {
++assert(e != APR_BRIGADE_SENTINEL(bb));
+ s = apr_bucket_read(e, , , APR_BLOCK_READ);
+ if (s != APR_SUCCESS)
+ return s;
+ 
+ assert(glen >= dlen);
+ glen -= dlen;
++
+ e = APR_BUCKET_NEXT(e);
+ }
+ 
+ /* copy value */
+-assert(vlen > 0);
+ dest = v->data;
+ while (vlen > 0) {
++apr_size_t off;
+ 
++assert(e != APR_BRIGADE_SENTINEL(bb));
+ s = apr_bucket_read(e, , , APR_BLOCK_READ);
+ if (s != APR_SUCCESS)
+ return s;
+ 
+-memcpy(dest, data, dlen);
+-dest += dlen;
+-assert(vlen >= dlen);
+-vlen -= dlen;
++for (off = 0; off < dlen; ++off) {
++const char ch = data[off];
++if (ch == '\r' || ch == '\n') {
++/* skip continuation CRLF(s) */
++continue;
++}
++assert(vlen > 0);
++*dest = ch;
++++dest;
++--vlen;
++}
++
+ e = APR_BUCKET_NEXT(e);
+ }
+-
+-assert(dest[-1] == '\n');
+-
+-if (dest[-2] == '\r')
+---dest;
+-
+-dest[-1] = 0;
+-v->dlen = (dest - v->data) - 1;
++v->dlen = dest - v->data;
++*dest++ = 0;
+ 
+ /* write name */
+ v->name = dest;
+-iov = (struct iovec *)arr.elts;
+-
+-while (iov <= end) {
++for (i = 0; i < a->nelts; ++i) {
++iov = (struct iovec *)a->elts + i;
+ memcpy(dest, iov->iov_base, iov->iov_len);
+ dest += 

Bug#1029217: bullseye-pu: package libapreq2/2.13-7~deb11u1

[Tobias Frost]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libapr...@packages.debian.org, Salvatore Bonaccorso 

Control: affects -1 + src:libapreq2

I've uploaded prepared an security update of libapreq2 for LTS and ELTS.
The proposed upload fixes the CVE also for bullseye.

CVE-2022-22728:

A flaw in Apache libapreq2 versions 2.16 and earlier could cause a buffer
overflow while processing multipart form uploads. A remote attacker could send
a request causing a process crash which could lead to a denial of service
attack.

I've conducted tests with e.g the reverse dependency rapache 
(libapache2-mod-r-base)

--
tobi

Bug#1029134: RM: mricron [mipsel powerpc ppc64] -- ROM; Please remove some unsupported architectures

[Paul Tagliamonte]

On Thu, Jan 19, 2023 at 08:24:52PM +0100, Andreas Tille wrote:
> According to
>https://buildd.debian.org/status/package.php?p=mricron
> the package builds on ppc64el and I left it in the architecture list.
> I had to remove ppc64 from the list of architectures since it did not
> built there.
> 
> Thanks for asking for clarification anyway

Great, I'm happy I asked!

Can you retitle to match the arches you're intending to RM on? As a
hint, I don't see anything in unstable for powerpc or ppc64; hence the
confusion :)

$ dak ls mricron -a mipsel
mricron| 1.2.20211006+dfsg-1+b1 | testing| mipsel
mricron| 1.2.20211006+dfsg-1+b1 | unstable   | mipsel
$ dak ls mricron -a powerpc
$ dak ls mricron -a ppc64

Should the title be just [mipsel]? If so, could you please change the
title to reflect the targets of the rm? If no debs are in that arch, I
can't remove it :)

Thank you!
   paultag

-- 
:wq

Bug#1029134: RM: mricron [mipsel powerpc ppc64] -- ROM; Please remove some unsupported architectures

[Andreas Tille]

Am Thu, Jan 19, 2023 at 01:27:43PM -0500 schrieb Paul Tagliamonte:
> From the title: [mipsel powerpc ppc64] 
> 
> Is ppc64 right or should it be ppc64el? I suspect you mean/want ppc64el
> but I don't want to take an rm action here until I've got a lot of
> positive confirmation.

According to
   https://buildd.debian.org/status/package.php?p=mricron
the package builds on ppc64el and I left it in the architecture list.
I had to remove ppc64 from the list of architectures since it did not
built there.
 
> If that's right, would you please re-title this bug? Thank you very
> much!

Thanks for asking for clarification anyway

Andreas. 

-- 
http://fam-tille.de

Bug#1029216: ausweisapp2: Connecting with Smartphone as Cardreader unpossible due to Certificate Error

[Simon Spies]

Package: ausweisapp2
Version: 1.26.1-1
Severity: important
X-Debbugs-Cc: s.sp...@sisesp.de

Dear Maintainer,

I noticed that connecting with a smartphone as cardreader is currently
impossible since the app hangs up during the process. All packages on my system
are up-to-date with Debian testing. The following lines from the console output
when the error occurs hint that it is some sort of certificate problem:

default   2023.01.19 20:16:08.445 45530
...viceModel::connectToRememberedServer(ui/qml/RemoteServiceModel.cpp:205) :
Starting to pair.
ifd   2023.01.19 20:16:08.445 45530
IfdClientImpl::establishConnection(ifd/base/IfdClientImpl.cpp:156) :
Establishing connection to remote device.
default   2023.01.19 20:16:08.446 45535
TlsChecker::hasValidCertificateKeyLength(network/TlsChecker.cpp:40):
Certificate is null
qt.network... 2023.01.19 20:16:08.446 45535 W (unknown:0)
: The backend "cert-only" does not support QSslKey
qt.network... 2023.01.19 20:16:08.446 45535 W (unknown:0)
: Active TLS backend does not support key creation
settings  2023.01.19 20:16:08.446 45535
...ceSettings::checkAndGenerateKey(settings/RemoteServiceSettings.cpp:182) :
Generate local keypair...
qt.network... 2023.01.19 20:16:08.685 45535 W (unknown:0)
: The backend "cert-only" does not support QSslKey
qt.network... 2023.01.19 20:16:08.685 45535 W (unknown:0)
: Active TLS backend does not support key creation
ifd   2023.01.19 20:16:08.685 45535 C
ConnectRequest::ConnectRequest(ifd/base/ConnectRequest.cpp:44) :
Cannot get required key/certificate for tls

Thank you very much in advance.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 ausweisapp2 depends on:
ii  libc6   2.36-8
ii  libhttp-parser2.9   2.9.4-5
ii  libpcsclite11.9.9-1
ii  libqt6core6 6.4.2+dfsg~rc1-3
ii  libqt6gui6  6.4.2+dfsg~rc1-3
ii  libqt6network6  6.4.2+dfsg~rc1-3
ii  libqt6qml6  6.4.2+dfsg~rc1-2
ii  libqt6quick66.4.2+dfsg~rc1-2
ii  libqt6quickcontrols2-6  6.4.2+dfsg~rc1-2
ii  libqt6statemachine6 6.4.2~rc1-2
ii  libqt6svg6  6.4.2~rc1-3
ii  libqt6websockets6   6.4.2~rc1-3
ii  libqt6widgets6  6.4.2+dfsg~rc1-3
ii  libssl3 3.0.7-1
ii  libstdc++6  12.2.0-14
ii  libudev1252.4-1
ii  qml6-module-qt-labs-platform6.4.2+dfsg~rc1-2
ii  qml6-module-qtqml   6.4.2+dfsg~rc1-2
ii  qml6-module-qtqml-models6.4.2+dfsg~rc1-2
ii  qml6-module-qtqml-statemachine  6.4.2~rc1-2
ii  qml6-module-qtqml-workerscript  6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-controls6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-layouts 6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-templates   6.4.2+dfsg~rc1-2
ii  qml6-module-qtquick-window  6.4.2+dfsg~rc1-2

Versions of packages ausweisapp2 recommends:
ii  pcsc-tools  1.6.1-1
ii  pcscd   1.9.9-1

ausweisapp2 suggests no packages.

-- no debconf information

Bug#1027830: [Pkg-openssl-devel] Bug#1027830: [ITB] Re: Bug#1027830: openssl: starttls fails on our LDAP server on bullseye, but it works on buster

[Sebastian Andrzej Siewior]

control: reassign -1 ldap-utils 2.4.57+dfsg-3

On 2023-01-04 13:50:53 [+], Jonathan Rietveld wrote:
> We've since found out that installing libldap-common resolves our
> issue, as others
> (https://github.com/wheelybird/ldap-user-manager/issues/172 and
> https://github.com/docker-mailserver/docker-mailserver/issues/2340)
> found out. This package is installed by default on buster (even before
> installing any ldap-related packages), but not on bullseye. 
> 
> Perhaps it might make sense to add libldap-common as a dependency for
> other packages like libnss-ldap, pam_ldap or ldap-utils on bullseye?

Based on Jonathan's investigation, I reasign the bug to
openldap/ldap-utils since it appears it has to depend on libldap-common
in order to get TLS to work with ceritificate validation. It has only
recommends via libldap-*.

This poped up on the openssl package but it appears to use gnutls stack
instead.

> Kind regards,
> 
> Jonathan

Sebastian

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[Jorge Moraleda]

Hello Fabian and James,

Thank you for looking into this.

I remark that the symbolic links created in the *"X11/Type1" *folder change
the file extension of the original file. In particular:

> > file /usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb
> /usr/share/fonts/X11/Type1/NimbusSans-BoldItalic.pfb: symbolic link to
> ../../type1/urw-base35/NimbusSans-BoldItalic.t1
>
(Notice the origin file has extension *"t1"* but the symbolic link changes
that to *"pfb"*)

Is this change intentional?

It appears pdfbox is using the extension to determine the file type because
renaming the symbolic link to preserve the "t1" extension in the symbolic
link fixes the problem.

Fabian mentioned that *"upstream has decided to rename the binary font
files and in that course change the file extensions from .pfb to .t1." *but
from the above experiment it seems that upstream changed the actual file
format, and then they changed the file extensions to match the new format.

IMHO opinion, the solution would be to either not create the symbolic links
or to preserve the original names including the extension. I don't know
enough to know what is best.

Bug#1029213: libgraphicsmagick-q16-3 has a hardcoded dependency on libtiff5

[GCS]

Control: merge -1 1029212

On Thu, Jan 19, 2023 at 7:15 PM Adrian Bunk  wrote:
> libgraphicsmagick-q16-3 has a hardcoded dependency on the cruft libtiff5:
> https://sources.debian.org/src/graphicsmagick/1.4%2Breally1.3.40-1/debian/control/#L44
>
> Please drop this, ${shlibs:Depends} already generates a correct dependency
> on libtiff6.
 Indeed and already reported. Will fix this shortly.

Regards,
Laszlo/GCS

Bug#310442: rdiff-backup: no way to recover from full filesystem

[Pablo Mestre]

Hi Paul

I'm going to look deeper into this issue and try to reproduce the bug. 
Also I will contact the upstream.


Thanks for your reply


El 4/1/23 a las 00:33, Paul Wise escribió:

On Tue, 2023-01-03 at 17:56 -0300, Pablo Mestre wrote:


Several months have passed since the last check regarding the bug and no
response has been issued.

Looks like you didn't CC any of the people who were affected,
the Debian bug tracker does not subscribe anyone by default.


We will proceed to close this bug and then archived if any discrepancy
arises.

I no longer use rdiff-backup, but the issue seems trivial to test, so
I tested rdiff-backup 2.0.5-4 for this issue and saw it is unfixed.


--
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#1029134: RM: mricron [mipsel powerpc ppc64] -- ROM; Please remove some unsupported architectures

[Paul Tagliamonte]

Hey Andreas,

>From the title: [mipsel powerpc ppc64] 

Is ppc64 right or should it be ppc64el? I suspect you mean/want ppc64el
but I don't want to take an rm action here until I've got a lot of
positive confirmation.

If that's right, would you please re-title this bug? Thank you very
much!

   Paul

-- 
:wq

Bug#1029215: debian-archive-keyring: bookworm SRM key

[Adam D. Barratt]

Source: debian-archive-keyring
Version: 2021.1.1
Severity: serious
X-Debbugs-Cc: debian-rele...@lists.debian.org

Hi,

We need an SRM key for bookworm, so that we can include it in the
release.

Regards,

Adam

Bug#1029214: debian-archive-keyring: bookworm archive signing keys

[Adam D. Barratt]

Source: debian-archive-keyring
Version: 2021.1.1
Severity: serious
X-Debbugs-Cc: ftpmas...@debian.org, debian-rele...@lists.debian.org

Hi,

We need new archive signing keys for bookworm, so that we can include
them in the release.

Regards,

Adam

Bug#1029213: libgraphicsmagick-q16-3 has a hardcoded dependency on libtiff5

[Adrian Bunk]

Package: libgraphicsmagick-q16-3
Version: 1.4+really1.3.39-2
Severity: serious

libgraphicsmagick-q16-3 has a hardcoded dependency on the cruft libtiff5:
https://sources.debian.org/src/graphicsmagick/1.4%2Breally1.3.40-1/debian/control/#L44

Please drop this, ${shlibs:Depends} already generates a correct dependency
on libtiff6.

Bug#1029168: fonts-urw-base35: Apache pdfbox cannot load fonts. Complains "Start marker missing"

[James Cloos]

> "f" == fabian   writes:

f> NB: The file command reveals some subtle differences between both
f> formats that pdfbox probably isn't aware of:

f> $ file *
f> NimbusRoman-BoldItalic.t1: PostScript Type 1 font text
f> (NimbusRoman-BoldItalic 1.00)
f> n022004l.pfb:  PostScript Type 1 font program data
f> (NimbusMonL-Bold 1.06)

that eans that those t1 files are pfa rather than pfb.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Bug#986152: Offer of help

[Jeremy Sowden]

On 2023-01-15, at 22:03:46 +0100, Romain Francoise wrote:
> On Sun, Jan 15, 2023 at 10:38:43AM +, Jeremy Sowden wrote:
> > I've managed to coax gbp into importing 5.2.8 into one upstream
> > branch with each upstream tar-ball as a subdirectory.
> >
> > I'm currently working on merging the debian/ directories.
>
> Cool! Thanks for working on this.

I created two new branches: debian/sid and upstream.  The starting point
for debian/sid was shorewall/debian/5.2.3.1-1; the upstream branch was
empty.  I updated debian/gbp.conf and debian/watch so that `gbp
import-orig` would import all seven upstream tar-balls into the upstream
branch, each unpacked into a separate subdirectory.  I then copied the
5.2.3.1-1 packaging from the other six master branches into debian/sid,
and applied all the 5.2.8 packaging updates.  I've added a README.source
and a paragraph in the change-log outlining the change of structure.  At
this point, I've got seven binary packages built from one source
package.  Everything's lintian-clean and the Salsa CI pipeline passes.

I've pushed all the work to my repo on Salsa:

  https://salsa.debian.org/azazel/shorewall

Do you want to review it before I push to the shorewall-team repo?

The 5.2.8 source package closes the following bugs:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932473
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956106
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960211
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971430
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971855
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986152
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002852

In addition, I think these are candidates for manual closure:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588349
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719810
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928912
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947217

J.


signature.asc
Description: PGP signature

Bug#1029212: libgraphicsmagick-q16-3: hardcode depends on libtiff5.

[Peter Green]

Package: libgraphicsmagick-q16-3
Version: 1.4+really1.3.39-2
Severity: serious

libgraphicsmagick-q16-3 has a hardcoded dependency on libtiff5,
so even after binnmuing for the tiff transition it still depends on it

This affects both the version in bookworm and the version in sid,
I have not checked other versions.

Bug#1028565: Acknowledgement (upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64) Inbox

[Diederik de Haas]

FTR: There is already an alternative fix committed in the Debian Kernel repo:
https://salsa.debian.org/kernel-team/linux/-/commit/4a65ff78c6be9208bfc9232886a7a2d199ebcac7

So what I'll describe below is how you would do it.

On Thursday, 19 January 2023 18:46:57 CET Markus Kramer wrote:
> How do I boot from this kernel?  Using dpkg -i arch/x86/boot/bzImage ?

To use `dpkg -i` you'd need a .deb file (ie Debian package)

> How could GRUB show this kernel as e.g. "before-patch", or will it
> show the creation time?
> 
> Where do I get the .patch file mentioned in
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4
> .2.2 ?

The 'problematic' commit was c34db0d6b88b and we need a revert of that:

diederik@prancing-pony:~/dev/kernel.org/linux$ git revert c34db0d6b88b
Auto-merging sound/soc/soc-pcm.c
[linux-5.10.y 3ed496982f55] Revert "ASoC: soc-pcm: Don't zero TDM masks in 
__soc_pcm_open()"
 1 file changed, 5 insertions(+)
diederik@prancing-pony:~/dev/kernel.org/linux$ git format-patch HEAD~1 -o 
../patches/
../patches/0001-Revert-ASoC-soc-pcm-Don-t-zero-TDM-masks-in-__soc_pc.patch

And that's how you'd get the .patch file which I have attached as a convenience.

If you then follow the procedure at #s4.2.2 and provide that patch file as an
argument, it would build a .deb file of the patched kernel.
That .deb file you can then install with `dpkg -i `.

Currently, (unfortunately?), it would replace your existing 5.10.0-20-amd64
kernel and there is no (easy) way to see that you would be booting into
your new patched kernel from GRUB.

HTH,
  Diederik>From 3ed496982f556d17a87f830acaf5023d4f5d9a9b Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Thu, 19 Jan 2023 18:32:38 +0100
Subject: [PATCH] Revert "ASoC: soc-pcm: Don't zero TDM masks in
 __soc_pcm_open()"

This reverts commit c34db0d6b88b1da95e7ab3353e674f4f574cccee.
---
 sound/soc/soc-pcm.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index fb874f924bbe..9a60d62f12fe 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -723,6 +723,11 @@ static int soc_pcm_open(struct snd_pcm_substream *substream)
 		ret = snd_soc_dai_startup(dai, substream);
 		if (ret < 0)
 			goto err;
+
+		if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+			dai->tx_mask = 0;
+		else
+			dai->rx_mask = 0;
 	}
 
 	/* Dynamic PCM DAI links compat checks use dynamic capabilities */
-- 
2.39.0



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

Bug#1029211: debian-policy: Add mention of the new non-free-firmware archive area

[Gunnar Wolf]

Package: debian-policy
Version: 4.6.2.0
Severity: normal
Tags: patch

It has been four months since the General Resolution 2022/vote_003 was
voted¹, but it has not yet been completely adopted. The archive area
was created and at least a package was uploaded to it in October, but
it has not seen further movement. Two days ago, a call to action for
moving packages was sent by Cyril Brulebois², and I just sent a mail
checking for other places where it should be included³.

¹ https://www.debian.org/vote/2022/vote_003
² https://lists.debian.org/debian-boot/2023/01/msg00150.html
³ https://lists.debian.org/debian-project/2023/01/msg00018.html

To my surprise, the non-free-firmware archive area has not yet been
discussed for inclusion in the Policy.

I am (now!) aware there is a clear process to get changes included in
the Policy, but this is the first time I do this, so please excuse me
for jumping all the way to "State D: Wording proposed" (of course, my
words can be checked and improved, particularly given I'm not a native
English speaker).

⁴ https://www.debian.org/doc/debian-policy/ap-process.html

I am suggesting the following patch, which I'm attaching to this bug
report, and also uploaded them to my fork of debian-policy in Salsa:


https://salsa.debian.org/gwolf/policy/-/commit/79c58a40065c01f56850f86e883d8fa482c7cca0

Thank you very much for considering this!

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

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

debian-policy depends on no packages.

Versions of packages debian-policy recommends:
ii  libjs-sphinxdoc  5.3.0-3

Versions of packages debian-policy suggests:
pn  doc-base  

-- no debconf information
diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index ab04261..15b9343 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -24,11 +24,11 @@ The aims of this are:
 
 The *main* archive area forms the *Debian distribution*.
 
-Packages in the other archive areas (``contrib``, ``non-free``) are not
-considered to be part of the Debian distribution, although we support
-their use and provide infrastructure for them (such as our bug-tracking
-system and mailing lists). This Debian Policy Manual applies to these
-packages as well.
+Packages in the other archive areas (``non-free-firmware``,
+``contrib``, ``non-free``) are not considered to be part of the Debian
+distribution, although we support their use and provide infrastructure
+for them (such as our bug-tracking system and mailing lists). This
+Debian Policy Manual applies to these packages as well.
 
 .. _s-dfsg:
 
@@ -130,6 +130,27 @@ In addition, the packages in *main*
 
 - must meet all policy requirements presented in this manual.
 
+.. _s-non-free-firmware:
+
+The non-free-firmware archive area
+~~
+
+The *non-free-firmware* archive area contains packages providing
+firmware needed to initialize, use or keep updated hardware required
+by our users, typically necessary for important functions to be
+available (i.e. wireless network connectivity) or for fixing security
+defects in hardware (i.e. CPU microcode updates). Packages in this
+archive may not comply with all of the policy requirements in this
+manual due to lack of source code availability, restrictions on
+modification or other limitations.
+
+Packages in *non-free-firmware*
+
+- must not be so buggy that we refuse to support them, and
+
+  - must meet all policy requiremens presented in this manual that it
+is possible for them to meet.
+
 .. _s-contrib:
 
 The contrib archive area
@@ -261,8 +282,8 @@ prohibited" and "distribution restricted".
 Sections
 
 
-The packages in the archive areas *main*, *contrib* and *non-free* are
-grouped further into *sections* to simplify handling.
+The packages in the archive areas *main*, *non-free-firmware*, *contrib*
+and *non-free* are grouped further into *sections* to simplify handling.
 
 The archive area and section for each package should be specified in the
 package's ``Section`` control record (see
@@ -272,8 +293,8 @@ the Debian distribution. The ``Section`` field should be of 
the form:
 
 -  *section* if the package is in the *main* archive area,
 
--  *area/section* if the package is in the *contrib* or *non-free*
-   archive areas.
+-  *area/section* if the package is in the *non-free-firmware*, *contrib*
+   or *non-free* archive areas.
 
 The Debian archive maintainers provide the authoritative list of
 sections. At present, they are: admin, cli-mono, comm, database, debug,

Bug#1029210: smartmontools.service fails since bookworm

[Harald Dunkel]

Package: smartmontools
Version: 7.3-1+b1

smartmontools.service fails, if there is nothing to monitor. Sample:

root@srvl065:~# systemctl status smartmontools
x smartmontools.service - Self Monitoring and Reporting Technology (SMART) 
Daemon
 Loaded: loaded (/lib/systemd/system/smartmontools.service; enabled; 
preset: enabled)
 Active: failed (Result: exit-code) since Thu 2023-01-19 12:06:21 CET; 5h 
59min ago
   Docs: man:smartd(8)
 man:smartd.conf(5)
Process: 13278 ExecStart=/usr/sbin/smartd -n $smartd_opts (code=exited, 
status=17)
   Main PID: 13278 (code=exited, status=17)
 Status: "No devices to monitor"
CPU: 36ms

Jan 19 12:06:21 srvl065.ac.aixigo.de smartd[13278]: Device: /dev/sda, IE 
(SMART) not enabled, skip device
Jan 19 12:06:21 srvl065.ac.aixigo.de smartd[13278]: Try 'smartctl -s on 
/dev/sda' to turn on SMART features
Jan 19 12:06:21 srvl065.ac.aixigo.de smartd[13278]: Device: /dev/sdb, opened
Jan 19 12:06:21 srvl065.ac.aixigo.de smartd[13278]: Device: /dev/sdb, [LSI  
9750-4iDISK  5.12], lu id: 0x600050e0dce50d007c02ad72, S/N: 
03019314DCE50D007C02, 137 GB
Jan 19 12:06:21 srvl065.ac.aixigo.de smartd[13278]: Device: /dev/sdb, IE 
(SMART) not enabled, skip device
Jan 19 12:06:21 srvl065.ac.aixigo.de smartd[13278]: Try 'smartctl -s on 
/dev/sdb' to turn on SMART features
Jan 19 12:06:21 srvl065.ac.aixigo.de smartd[13278]: Unable to monitor any SMART 
enabled devices. Try debug (-d) option. Exiting...
Jan 19 12:06:21 srvl065.ac.aixigo.de systemd[1]: smartmontools.service: Main 
process exited, code=exited, status=17/n/a
Jan 19 12:06:21 srvl065.ac.aixigo.de systemd[1]: smartmontools.service: Failed 
with result 'exit-code'.
Jan 19 12:06:21 srvl065.ac.aixigo.de systemd[1]: Failed to start Self 
Monitoring and Reporting Technology (SMART) Daemon.


I saw that this is an experimental feature, but I wonder what this could
be good for? IMHO smartmontools should work out of the box, even if there
are no disks, as it does for Bullseye.


Regards
Harri

Bug#1011346: Enabling V4L2 Driver in Chromium Builds

[Andres Salomon]

Control: tags -1 pending

https://salsa.debian.org/chromium-team/chromium/-/commit/727873cc6feddfca06e3708869ee5780e26e4d4f


On Thu, Jan 19 2023 at 10:50:53 AM +0100, Bastian Germann 
 wrote:

Am 18.01.23 um 19:16 schrieb Andres Salomon:
Ah great, I hadn't noticed!  If the build works, let me know and 
I'll reenable v4l2.


The build runs successfully on arm64 with v4l2 enabled and vaapi 
disabled (like in the original change).

Bug#1029209: RFS: runit-services/0.5.4 -- UNIX init scheme with service supervision (services)

[Lorenzo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "runit-services":

 * Package name : runit-services
   Version  : 0.5.4
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : BSD-3-Clause, CC0-1.0
 * Vcs  :
   https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section
  : admin

The source builds the following binary packages:

  runit-services - UNIX init scheme with service supervision (services)

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/runit-services/

Alternatively, you can download the package with 'dget' using this
command:

  dget -x
  
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.4.dsc

Git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next

Changes since the last upload:

 runit-services (0.5.4) unstable; urgency=medium
 .
   * Add a flaky autopkgtest
 - d/tests/control file
 - blacklist services that are too hard or impossible
to test
 - test all non-blacklisted services
   * update copyright
   * dbus.dep-fixer: wait for elogind only if it's enabled
   * isc-dhcp-server:
   - test config and lease
   - default to -4
   - configurable (empty by default) interfaces
   * dbus: simplify run script

Regards,
Lorenzo

Bug#1029208: prosody: Switch to Lua 5.4

[Zash]

Package: prosody
Version: 0.12.2-1
Severity: wishlist

Dear Maintainer,

Please consider switching Prosody to run with Lua 5.4 as interpreter.
This is the recommended version of Lua for Prosody assuming all
dependencies are available, which is now the case in testing as far as I
can determine.  The main benefit to Prosody is improved memory usage
thanks to improvements to the garbage collector in Lua 5.4.

-- 
Best regards,
Kim "Zash" Alvefur
Prosody developer

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 prosody depends on:
ii  adduser 3.118
ii  init-system-helpers 1.60
ii  libc6   2.31-13+deb11u5
ii  libicu6767.1-7
ii  libidn111.33-3
ii  libssl1.1   1.1.1n-0+deb11u3
ii  lsb-base11.1.0
ii  lua-expat [lua5.2-expat]1.3.9-1lua54prosody~bullseye3
ii  lua-filesystem [lua5.2-filesystem]  1.8.0-1
ii  lua-sec [lua5.2-sec]1.0.2-1prosody~bullseye1
ii  lua-socket [lua5.2-socket]  3.0~rc1+git+ac3201d-6prosody~bullseye1
ii  lua5.1  5.1.5-8.1+b3
ii  lua5.2  5.2.4-1.1+b3
pn  lua5.2-bitop
ii  lua5.3  5.3.3-1.1+b1
ii  lua5.4  5.4.2-2
ii  openssl 1.1.1n-0+deb11u3
ii  procps  2:3.3.17-5
pn  ssl-cert

Versions of packages prosody recommends:
ii  ca-certificates 20210119
ii  lua-event [lua5.2-event]0.4.6-1+b2
ii  lua-readline [lua5.2-readline]  2.9-1
ii  lua-unbound [lua5.2-unbound]0.5-2
ii  luarocks3.9.2-1

Versions of packages prosody suggests:
ii  lua-bit32   5.3.0-3
ii  lua-dbi-mysql   0.7.2-2
ii  lua-dbi-postgresql  0.7.2-2
ii  lua-dbi-sqlite3 0.7.2-2
ii  lua-event   0.4.6-1+b2
ii  lua-ldap1.2.5-1+b1
pn  lua-zlib


signature.asc
Description: PGP signature

Bug#1029207: Fwd: gamin problem on debian testing

[Robert NEMKIN]

Package: courier-imap
Version: 5.0.13+1.0.16-3+b5 amd64

Hello,

I wanted to upgrade my email server, so I decided to install Bookworm 
(current debian testing) on a new machine. I wish to use virtual users.


postfix, postgresql auth, virtual users, courier imapd.
ii  courier-authdaemon 0.71.4-1+b1 amd64Courier 
authentication daemon
ii  courier-authlib0.71.4-1+b1 amd64Courier 
authentication library
ii  courier-authlib-postgresql 0.71.4-1+b1 amd64PostgreSQL 
support for the Courier authentication library
ii  courier-authlib-userdb 0.71.4-1+b1 amd64userdb 
support for the Courier authentication library
ii  courier-base   1.0.16-3+b5 amd64Courier mail 
server - base system
ii  courier-imap   5.0.13+1.0.16-3+b5 amd64 
Courier mail server - IMAP server
ii  libcourier-unicode4:amd64  2.1.2-2+b1 amd64Courier 
Unicode library (shared runtime library)


ii  gamin  0.1.10-6 amd64File and 
directory monitoring system
ii  libgamin0  0.1.10-6 amd64Client library 
for the gamin file and directory monitoring system


It doesn't work.

I got a message from thunderbird:
(set debug, cut from imaplog.dat

WRITE: * OK [ALERT] Filesystem notification initialization error -- 
contact your mail administrator (check for configuration errors with the 
FAM/Gamin library)


This bug has a long history in debian bugtrack, suggest to install fam, 
but there is no fam in debian testing.


/var/log/mail.log:

imapd: Failed to connect to socket /tmp/fam--

I started to investigate about this socket name, mainly the two dash on 
it's end.
I downloaded and extracted gamin source, and found this in 
server/gam_channel.c:


#ifdef HAVE_ABSTRACT_SOCKETS
ret = g_strconcat("/tmp/fam-", user, "-", gam_client_id, NULL);
#else

So it needs the username. I've gave it a try and added a regular user 
along the virtual one (same username, same uid and gid) and it staarted 
to work.


Then I removed the regular user and readded with some random character 
appended, same uid, same gid, and it works also. I've checked with lsof 
that the gam_server libexeced process uses the username from the 
/etc/passwd.


lsof:

gam_serve 10851 username8u unix 0x9286ce  0t0 
90092 
@/tmp/fam-username-@ 
type=STREAM (CONNECTED)
gam_serve 10851 username9u unix 0x7a8182  0t0 
90095 
@/tmp/fam-username-@ 
type=STREAM (CONNECTED)


If I delete the regular user again, then:
gam_serve 10966200425u unix 0x9422bc0f  0t0 
95756 
@/tmp/fam-somebody-@ 
type=STREAM (LISTEN)


the gam_serve opens the socket as somebody, the imapd checks as a null 
string.


I don't know, if this is a problem, or my fault.

Thank you for any help.

Robert

Bug#1029206: [pre-approval] unblock: webkit2gtk 2.40.0-2

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock transition moreinfo
Tags: security
X-Debbugs-CC: webkit2...@packages.debian.org

I am filing this bug early so that the Release Team is aware early.

[ Reason ]
webkit2gtk only provides security support for one stable series at a
time. A new series is released each March and September. The Debian
Security Team backports these new release as security updates [1] [2]

The upcoming 2.40.0 is more disruptive than usual as it makes a major
API break for the new GTK4 library, bumping the API series from 5 to 6
[3]. This causes a small transition: gnome-builder 43 and
gnome-initial-setup 43 are the only two packages that use the gtk4
library. They will both need sourceful uploads. Patches will be ready
for both since the upstream webkitgtk team works closely with the
GNOME project.

[ Impact ]
Because the 2.38 series will be End of Life before Debian 12 is
released, I believe the Security Team wants 2.40 to make it to Testing

[ Tests ]
There are no automated tests (!)
The person who uploads gnome-builder and gnome-initial-setup (likely
me) will make sure those 2 apps still run well with the new webkit2gtk
version.

[ Risks ]
The code changes in a new major webkit2gtk release are too large to
manually review.
webkit2gtk is a key package.
Besides gnome-builder and gnome-initial-setup, webkit2gtk is used by
many packages. [4]

[ Checklist ]
  [ ] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other Info ]
webkit2gtk generally follows the GNOME release schedule. [5] A beta
(2.39.90) is expected in February. A release candidate (2.39.91)
around March 6, and the first stable release (2.40.0) around March 20.
We intend to do a test build in experimental first. I think it makes
the most sense to wait for the 2.40.0 release and not push a prelease
to Unstable/Testing.

Ubuntu 23.04 will also switch to the 2.40 series by February or early
March. Ubuntu 22.10 will need to do this transition as stable release
updates.

I don't have a ben file since the final soname isn't known yet.

[1]
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#limited-security-support

[2] https://tracker.debian.org/pkg/webkit2gtk

[3] 
https://discourse.gnome.org/t/webkitgtk-for-gtk-4-status-update-and-api-changes/11033

[4] https://release.debian.org/transitions/html/webkit2gtk-4.0.html

[5] https://wiki.gnome.org/FortyFour

Thank you,
Jeremy Bicha

Bug#993590: distro-info-data: Store a mapping from distro to gpg keyring

[Stefano Rivera]

> On Fri, 03 Sep 2021 15:16:54 +0200 Johannes Schauer Marin Rodrigues
>  wrote:
> > please consider storing a mapping from distro to keyring in
> > /usr/share/keyring. Currently there is no reliable way to retrieve the
> > authoritative keyring for a given distro name. Even when limiting
> > oneself to only Debian, it is not obvious for which suites one needs
> > /usr/share/keyrings/debian-archive-keyring.gpg and for which one needs
> > /usr/share/keyrings/debian-archive-removed-keys.gpg.
> 
> I am not sure whether distro-info-data is the right place for it. Are
> there rules when keys move from debian-archive-keyring.gpg to debian-
> archive-removed-keys.gpg? Shouldn't that information better be shipped
> by debian-archive-keyring?

Can someone from the release team answer how this works?

Thanks,

Stefano

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

Bug#1029205: openvpn: Backporting openvpn 2.6.0~rc1 to bullseye-backports breaks network-manager-openvpn connections to older servers

[Bernhard Schmidt]

Am 19.01.23 um 16:47 schrieb René Krell:

Hi Rene,


IMHO, in each case it is not a idea to backport openvpn 2.6 unless 
network-manager-openvpn supports to override also --data-ciphers.


Packages are not upgraded to backports-versions by default. You have to 
opt-in (either manually or by adjusting pin-priorities in 
apt-preferences) to upgrade to 2.6.


Since the version of network-manager-openvpn in bullseye even works with 
the backported openvpn for the majority of not-outdated configurations 
there is nothing to be fixed here.


Unless you have another convincing argument I intend to close this bug 
in a couple of days.


Bernhard

Bug#1028565: Acknowledgement (upgrade-reports: Audio breaks between 5.10.0-19-amd64 and 5.10.0-20-amd64) Inbox

[Markus Kramer]

Resending because my email yesterday did not arrive at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028565

Hi,
yesterday the `make` command ended without an error.

When I run `make` again it returns
  CALLscripts/checksyscalls.sh
  CALLscripts/atomic/check-atomics.sh
  DESCEND  objtool
  DESCEND  bpf/resolve_btfids
  CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage is ready  (#1)

$ ls -l arch/x86/boot/bzImage
-rw-r--r-- 1 markus markus 6,7M 17. Jan 22:50 arch/x86/boot/bzImage

$ file arch/x86/boot/bzImage
arch/x86/boot/bzImage: Linux kernel x86 boot executable bzImage,
version 5.10.158 (markus@debNXP) #1 SMP Sun Jan 15 21:20:37 CET 2023,
RO-rootFS, swap_dev 0x6, Normal VGA

How do I boot from this kernel?  Using dpkg -i arch/x86/boot/bzImage ?

How could GRUB show this kernel as e.g. "before-patch", or will it
show the creation time?

Where do I get the .patch file mentioned in
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
?

Best regards,
Markus

Bug#1028148: celery FTBFS with Python 3.11 as default version

[Sebastiaan Couwenberg]

Control: tags -1 patch

A patch has been committed in git:


https://salsa.debian.org/python-team/packages/celery/-/commit/c94d7c031d3686596305d435898199e3d452e87c

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1029205: openvpn: Backporting openvpn 2.6.0~rc1 to bullseye-backports breaks network-manager-openvpn connections to older servers

[René Krell]

Package: openvpn
Version: 2.6.0~rc1
Severity: normal

Dear Maintainer,

after updating openvpn from bullseye-backports from 2.5.1 to 2.6.0~rc1 I got a 
broken VPN client-to-site connection to a server
not supporting TLS 1.2 (forced min TLS version: 1.0, overridden cipher: 
AES-128-CBC).

The reason is not the explicit cipher in the setting, but 
network-manager-openvpn relies on a different option set.
Message:
--cipher set to 'AES-128-CBC' but missing in --data-ciphers 
(AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for 
cipher negotiations.

As a result, the connection cannot be established.

IMHO, in each case it is not a idea to backport openvpn 2.6 unless 
network-manager-openvpn supports to override also --data-ciphers.


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-0.deb11.6-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 not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  iproute2   6.1.0-1~bpo11+1
ii  libc6  2.31-13+deb11u5
ii  liblz4-1   1.9.3-2
ii  liblzo2-2  2.10-2
ii  libpam0g   1.4.0-9+deb11u1
ii  libpkcs11-helper1  1.27-1
ii  libssl1.1  1.1.1n-0+deb11u3
ii  libsystemd0251.3-1~bpo11+1
ii  lsb-base   11.1.0

Versions of packages openvpn recommends:
ii  easy-rsa  3.0.8-1

Versions of packages openvpn suggests:
ii  openssl   1.1.1n-0+deb11u3
pn  openvpn-systemd-resolved  
pn  resolvconf

-- debconf information:
  openvpn/create_tun: false

Bug#1028333: [Pkg-puppet-devel] Bug#1028333: puppetserver: find an upgrade path from puppet-master

[Antoine Beaupré]

On 2023-01-19 11:30:31, Jérôme Charaoui wrote:
> So considering all this I'm currently leaning towards adding a 
> transitional "puppet-master" and/or "puppet-master-passenger" package 
> for the purpose of shipping a NEWS file recommending that users migrate 
> to the puppetserver package manually.

Agreed. We should also probably make an entry in the release
notes. According to the RT, this should be done in a MR here:

https://salsa.debian.org/ddp-team/release-notes/

-- 
Never underestimate the bandwidth of a station wagon full of tapes
hurtling down the highway.
- Andrew S. Tanenbaum, "Computer Networks"

Bug#1029101: Acknowledgement (fontconfig-config: 2.14.1 upload breaks testSimpleText of libreoffice)

[Rene Engelhard]

Hi,

Am 19.01.23 um 12:46 schrieb Andreas Henriksson:

I'd like to explicitly ask if you still want me to upload any
fontconfig change ASAP or if downgrading severity means you think
it can/should wait until after release?


worked around it in libreoffice for now, so your decision in the end.


As I understand the situation something related to subpixel rendering
has changed between 2.13.x and 2.14.1.
Debian offers debconf choices "Automatic", "Always" and "Never" for
which settings to use in /etc/fonts/conf.d/$SYMLINK which are related
to the problem you're reporting.
Fedora on the other hand seems to use "always/only on KDE" (with no
alternatives) as far as I understand the commit you pointed out.

Does that mean we should:
- offer an additional alternative /or/ patch "Always"?
- make then new/patched alternative the default?
- get rid of debconf alternatives and provide one consistent
   configuration for all users?
I'd vote for the latter, the deconf thingy is confusing and leads to 
problems like this if stuff assumes behaviour

Unless we do the last option, wouldn't it mean any (test) failures
still happen if the user uses any of the other options? (Which would
suggest this is not actually a bug on the fontconfig side to me.)


Probably. Maybe just do what upstreams default is? (Whatever that is).

Or sync with other distros which so far had no problems (aka the patch I 
linked), so it's at least consistent between distros.


Fedora actually (as one can see in the linked RH bug) did an update to 
released Fedora versions to add that ... and TTBOMK Abira 
TAGOH is also fontconfig upstream?




In the mail where you tagged this patch you suggested to edit the
subpixel config file which makes me think you're using the Always
alternative, but as I understand the debconf code Automatic is
the (current) default...


Can't be. The buildds (and also my buildd chroot) does not get any 
debconf prompt (noninteractive frontend) so default is what I pasted


- without the 



If you think you have a clear picture of exactly what should happen
(on the fontconfig side) then I would very much appreciate if you
could either send a salsa MR or just NMU (and I'll make sure to import
the NMU-diff into the fontconfig packaging repo).


Unfortunately not, I just try to fix the FTBFS ;)


Regards,


Rene

Bug#1028333: puppetserver: find an upgrade path from puppet-master

[Jérôme Charaoui]

The old "puppet-master" and "puppet-master-passenger" were basically 
just configuration files for the systemd/sysvinit and Apache2/Passenger, 
because the main (ruby) code was always in the "puppet" package.


I think the way forward here is that first, we should make the 7.x 
transitional dummy package "puppet" "Breaks: puppet-master, 
puppet-master-passenger", to make clear that the old master packages 
cannot function with the libraries shipping in the latest puppet-agent 
package.


And secondly, we should carefully consider whether a "seamless" 
transition is even possible at all. Puppetserver is completely different 
software which is configured differently than the old master, and as 
such I doubt that one can simple replace one package with the other and 
expect things to "just work". Even if it does, important bits of the 
configuration may likely be lost in translation (eg. auth.conf).


So considering all this I'm currently leaning towards adding a 
transitional "puppet-master" and/or "puppet-master-passenger" package 
for the purpose of shipping a NEWS file recommending that users migrate 
to the puppetserver package manually.


-- Jérôme

Bug#915370: Please drop anacron from task-desktop and task-laptop

[Gregor Riepl]

Package: task-laptop
Version: 3.71
Followup-For: Bug #915370
X-Debbugs-Cc: onit...@gmail.com

The drop didn't happen in buster+1, but there may still be time for bookworm.

FYI: The anacron service was silently disabled by default a while ago due to a
bug, but this was only recently reported: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1028205

On the other hand, the systemd-cron package provides anacron, so it could be
installed instead, if the cron dependency should be kept.


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

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages task-laptop depends on:
ii  anacron  2.3-36
ii  tasksel  3.71

Versions of packages task-laptop recommends:
ii  avahi-autoipd   0.8-7
ii  bluetooth   5.66-1
ii  iw  5.19-1
ii  powertop2.14-1+b2
ii  wireless-tools  30~pre9-14
ii  wpasupplicant   2:2.10-10

task-laptop suggests no packages.

-- no debconf information

Bug#1028671: python-django-tagging: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.11" --system=custom "--test-args=PYTHONPATH=. DJANGO_SETTINGS_MODULE=tagging.tests.settings

[Sebastiaan Couwenberg]

Control: tags -1 patch

A patch has been committed in git:


https://salsa.debian.org/python-team/packages/python-django-tagging/-/commit/580dfcf54791ea0613c0edc622867b44e5738fb5

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1028687: termbox: FTBFS: ValueError: invalid mode: 'rUb'

[Sebastiaan Couwenberg]

Control: tags -1 patch

A patch has been committed in git:


https://salsa.debian.org/debian/termbox/-/commit/814a247912b907d66adb8b761c616e1f1a5f471f

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1028695: python-hdf5storage: FTBFS: build-dependency not installable: python-numpy-doc

[Sebastiaan Couwenberg]

Control: tags -1 pending

A fix has been committed in git:


https://salsa.debian.org/science-team/python-hdf5storage/-/commit/78d2bc277af59a8d2881b2290d175822b39ca65b

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1029204: zeroc-ice - consider building for all supported python 3 versions.

[Peter Green]

Package: zeroc-ice
Severity: wishlist

zeroc-ice currently builds a python library package which is only built against
the default python 3 version. The result of this is that zeroc-ice is tying
together the "php 7.2" transition with the "python3 as default" transition.

If zeroc-ice was to build it's python module for all supported python 3 versions
then this coupling would be broken.

Bug#1029203: ITP: r-cran-gfonts -- offline 'Google' Fonts for 'Markdown' and 'Shiny' for GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gfonts -- offline 'Google' Fonts for 'Markdown' and 
'Shiny' for GNU R
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-gfonts
  Version : 0.2.0
  Upstream Author : Victor Perrier,
* URL : https://cran.r-project.org/package=gfonts
* License : GPL-3
  Programming Lang: GNU R
  Description : offline 'Google' Fonts for 'Markdown' and 'Shiny' for GNU R
 Download 'Google' fonts and generate 'CSS' to use in 'rmarkdown' documents and
 'shiny' applications. Some popular fonts are included and ready to use.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gfonts

Bug#1028528: transition: libcotp

[Francisco Vilmar Cardoso Ruviaro]

Hi Sebastian,

On 1/17/23 22:37, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
> 
> On 2023-01-12 11:45:45 +, Francisco Vilmar Cardoso Ruviaro wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> 
>> Dear Release Team,
>> 
>> I would like to update libcotp in unstable to the 2.0.0-1.
>> 
>> I would like to request a transition slot for libcotp, changing the
>> library name from libcotp12 to libcotp2. The version 2.0.0
> 
> Why is the SONAME going backwards?
> 
I believe this was an upstream decision, please check it out:

"the soversion is now set only from the $major version (e.g. 2),
and not from $major$minor (e.g. 12) like it used to be."
https://github.com/paolostivanin/libcotp/releases/tag/v2.0.0


I checked it this way:

$ readelf -d libcotp.so.1.2.8 | grep SONAME
 0x000e (SONAME) Library soname: [libcotp.so.12]

$ readelf -d libcotp.so.2.0.0 | grep SONAME
 0x000e (SONAME) Library soname: [libcotp.so.2]


> Cheers
> 

Thanks!
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028673: pydl: FTBFS: ImportError: cannot import name 'float' from 'numpy' (/usr/lib/python3/dist-packages/numpy/__init__.py)

[Sebastiaan Couwenberg]

Control: tags -1 patch

A patch has been committed in git:


https://salsa.debian.org/debian-astro-team/pydl/-/commit/3cd70897436e4166f495aee204bcf0c7b026a5bc

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1028638: libproxy1v5: Gajim 1.6.0-1 crashes in libproxy call

[Sebastian Reichel]

Hi,

On Wed, Jan 18, 2023 at 09:48:33PM +, Martin wrote:
> Control: severity -1 grave
> 
> Justification for grave: Crashes Gajim for some users. RC, IMHO.
> 
> On 2023-01-17 21:56, Sebastian Reichel wrote:
> > I just got the new package through testing and now gajim segfaults
> > ony my system with stacktrace pointing to libproxy. So this is not
> > magically solved.
> 
> :-(
> 
> Could you check, if a downgrade to libproxy 0.4.15-15 helps?
> That certainly helps to find the bug!

I tried downgrading libproxy1v5 and libproxy-tools to 0.4.15-15 and
glib-networking to 2.66.0. This did not change anything.

With libproxy from testing gajim does work when being downgraded to
1.5.4-1 (which requires also downgrading python3-nbxmpp to
3.2.5-1 to be functional).

-- Sebastian


signature.asc
Description: PGP signature

Bug#1028592: Info received (Bug#1028592: Acknowledgement (tagcoll2 2.0.14-2 fails to build on sid))

[Holger Levsen]

control: reassign -1 src:tagcoll2,src:libwibble
thanks


-- 
cheers,
Holger

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

The wrong Amazon is burning.

Bug#1024012: [joshuaulrich/xts] Unit test failure when running on i386 (Issue #384)

[Andreas Tille]

Am Thu, Jan 19, 2023 at 06:49:24AM -0800 schrieb Adrian Bunk:
> @tillea Confirmed by my testing is that the difference between failing and 
> passing autopkgtest of `r-cran-xts` is whether `r-base-core` is from Debian 
> unstable or from the same sources recompiled with `-ffloat-store`.
> 
> `-ffloat-store` would cost some performance for FPU code in R on i386, but 
> given that it's 2023 this should not matter much since i386 is mainline 
> vintage hardware (multiarch usecases shouldn't apply here).

I fully agree that users could live with performance issues on i386 since those 
who need performance will not use i386.
 
> I would guess this change might also help with similar issues in other 
> packages, but that is just a guess.

I'd agree with reassigning this to r-base.

Bug#1024012: Unit test failure when running on i386 (Issue #384)

[Adrian Bunk]

@tillea I've got it passing by compiling R itself with `-ffloat-store` to 
mitigate the excess precision of the x87 FPU. I'll reassign the Debian bug with 
a patch in a while.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/joshuaulrich/xts/issues/384#issuecomment-1397058448
You are receiving this because you were mentioned.

Message ID: 

Bug#1029197: ip-transparent: yes is blocked by apparmor

[Simon Deziel]

On 2023-01-19 08:35, Tiger!P wrote:

Package: unbound
Version: 1.17.0-1
Severity: normal
Tags: patch

Dear Maintainer,

* What led up to the situation?
I wanted to configure a static IPv6 address in unbound, but that is not
(always) available when booting the system. Therefor I enabled
ip-transparent in the server section.


On Linux, you can use "ip-freebind: yes" which doesn't require any 
additional capability. Here's the man unbound.conf description snippet 
for it:


> Allows you to bind to IP addresses that are nonlocal or do not exist,
> like when the network interface or IP address is down.

Works like a charm as I discovered 2 days ago when running into the same 
situation as you (IPv6 not being present when unbound starts).


HTH,
Simon

Bug#1029202: snippy: Error when using snpeff 5.1

[Andreas Tille]

Package: snippy
Version: 4.6.0+dfsg-1
Severity: important
X-Debbugs-Cc: Pierre Gruet 

Hi,

I was informed that snippy is not behaving nicely in all cases when
snpeff 5.1 is used.  A colleague is rather using it successfully with
snpeff 5.0.  You can verify this with the following test script:


#!/bin/sh
# create tmp dir
TMPDIR=$(mktemp -d /tmp/snippyX)
cd $TMPDIR
# download public read data
wget 
ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR201/004/SRR2014554/SRR2014554_1.fastq.gz
wget 
ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR201/004/SRR2014554/SRR2014554_2.fastq.gz
# download reference data
wget 
https://ftp.ncbi.nlm.nih.gov/genomes/all/GCF/000/005/845/GCF_05845.2_ASM584v2/GCF_05845.2_ASM584v2_genomic.gbff.gz
gunzip GCF_05845.2_ASM584v2_genomic.gbff.gz
mkdir tmp

set -x
snippy --cpus 4 --ram 20 --tmpdir ./tmp --reference 
GCF_05845.2_ASM584v2_genomic.gbff --R1 SRR2014554_1.fastq.gz --R2 
SRR2014554_2.fastq.gz --outdir results --report --mincov 20


This script ends with:

...
[15:25:13] Running: mkdir -p reference/ref && gzip -c reference/ref.gff > 
reference/ref/genes.gff.gz 2>> snps.log
[15:25:13] Running: snpEff build -c reference/snpeff.config -dataDir . -gff3 
ref 2>> snps.log
 build -c reference/snpeff.config -dataDir . -gff3 ref
[15:25:16] Error running command, check results/snps.log


Checking the end of the log gives:

$ tail results/snps.log 
transl_table : 11
translation : 
MSDYKSTLNLPETGFPMRGDLAKREPGMLARWTDDDLYGIIRAAKKGKKTFILHDGPPYANGSIHIGHSVNKILKDIIVKSKGLSGYDSPYVPGWDCHGLPIELKVEQEYGKPGEKFTAAEFRAKCREYAATQVDGQRKDFIRLGVLGDWSHPYLTMDFKTEANIIRALGKIIGNGHLHKGAKPVHWCVDCRSALAEAEVEYYDKTSPSIDVAFQAVDQDALKAKFAVSNVNGPISLVIWTTTPWTLPANRAISIAPDFDYALVQIDGQAVILAKDLVESVMQRIGVTDYTILGTVKGAELELLRFTHPFMGFDVPAILGDHVTLDAGTGAVHTAPGHGPDDYVIGQKYGLETANPVGPDGTYLPGTYPTLDGVNVFKANDIVVALLQEKGALLHVEKMQHSYPCCWRHKTPIIFRATPQWFVSMDQKGLRAQSLKEIKGVQWIPDWGQARIESMVANRPDWCISRQRTWGVPMSLFVHKDTEELHPRTLELMEEVAKRVEVDGIQAWWDLDAKEILGDEADQYVKVPDTLDVWFDSGSTHSSVVDVRPEFAGHAADMYLEGSDQHRGWFMSSLMISTAMKGKAPYRQVLTHGFTVDGQGRKMSKSIGNTVSPQDVMNKLGADILRLWVASTDYTGEMAVSDEILKRAADSYRRIRNTARFLLANLNGFDPAKDMVKPEEMVVLDRWAVGCAKAAQEDILKAYEAYDFHEVVQRLMRFCSVEMGSFYLDIIKDRQYTAKADSVARRSCQTALYHIAEALVRWMAPILSFTADEVWGYLPGEREKYVFTGEWYEGLFGLADSEAMNDAFWDELLKVRGEVNKVIEQARADKKVGGSLEAAVTLYAEPELSAKLTALGDELRFVLLTSGATVADYNDAPADAQQSEVLKGLKVALSKAEGEKCPRCWHYTQDVGKVAEHAEICGRCVSNVAGDGEKRKFA
type : CDS
. File '/tmp/snippyBRsOJ/results/reference/./ref/genes.gff' line 30 
'NC_000913  snippy  CDS 22391   25207   .   +   0   
ID=b0026;eC_number=6.1.1.5;Name=ileS;codon_start=1;db_xref=UniProtKB/Swiss-Prot:P00956,ASAP:ABE-094,ECOCYC:EG10492,GeneID:944761;gene=ileS;gene_synonym=ECK0027%3B
 ilvS;locus_tag=b0026;product=isoleucine--tRNA 
ligase;protein_id=NP_414567.1;transl_table=11;translation=MSDYKSTLNLPETGFPMRGDLAKREPGMLARWTDDDLYGIIRAAKKGKKTFILHDGPPYANGSIHIGHSVNKILKDIIVKSKGLSGYDSPYVPGWDCHGLPIELKVEQEYGKPGEKFTAAEFRAKCREYAATQVDGQRKDFIRLGVLGDWSHPYLTMDFKTEANIIRALGKIIGNGHLHKGAKPVHWCVDCRSALAEAEVEYYDKTSPSIDVAFQAVDQDALKAKFAVSNVNGPISLVIWTTTPWTLPANRAISIAPDFDYALVQIDGQAVILAKDLVESVMQRIGVTDYTILGTVKGAELELLRFTHPFMGFDVPAILGDHVTLDAGTGAVHTAPGHGPDDYVIGQKYGLETANPVGPDGTYLPGTYPTLDGVNVFKANDIVVALLQEKGALLHVEKMQHSYPCCWRHKTPIIFRATPQWFVSMDQKGLRAQSLKEIKGVQWIPDWGQARIESMVANRPDWCISRQRTWGVPMSLFVHKDTEELHPRTLELMEEVAKRVEVDGIQAWWDLDAKEILGDEADQYVKVPDTLDVWFDSGSTHSSVVDVRPEFAGHAADMYLEGSDQHRGWFMSSLMISTAMKGKAPYRQVLTHGFTVDGQGRKMSKSIGNTVSPQDVMNKLGADILRLWVASTDYTGEMAVSDEILKRAADSYRRIRNTARFLLANLNGFDPAKDMVKPEEMVVLDRWAVGCAKAAQEDILKAYEAYDFHEVVQRLMRFCSVEMGSFYLDIIKDRQYTAKADSVARRSCQTALYHIAEALVRWMAPILSFTADEVWGYLPGEREKYVFTGEWYEGLFGLADSEAMNDAFWDELLKVRGEVNKVIEQARADKKVGGSLEAAVTLYAEPELSAKLTALGDELRFVLLTSGATVADYNDAPADAQQSEVLKGLKVALSKAEGEKCPRCWHYTQDVGKVAEHAEICGRCVSNVAGDGEKRKFA'
WARNING_TRANSCRIPT_NOT_FOUND: Too many 'WARNING_TRANSCRIPT_NOT_FOUND' warnings, 
no further warnings will be shown.
WARNING_TRANSCRIPT_ID_DUPLICATE: Transcript 'b4616' already added. File 
'/tmp/snippyBRsOJ/results/reference/./ref/genes.gff' line 3839  'NC_000913  
snippy  ncRNA   3853118 3853190 .-   .   
ID=b4616;Name=istR;db_xref=ECOCYC:G0-10201,GeneID:5061525;gene=istR;gene_synonym=ECK4425%3B
 istR-1%3B istR-2%3B psrA19;locus_tag=b4616;ncRNA_class=other;product=small 
regulatory RNA IstR-1'
WARNING_FRAMES_ZERO: All frames are zero! This seems rather odd, please check 
that 'frame' information in your 'genes' file is accurate.
ERROR: CDS check file '/tmp/snippyBRsOJ/results/reference/./ref/cds.fa' not 
found.
ERROR: Protein check file '/tmp/snippyBRsOJ/results/reference/./ref/protein.fa' 
not found.
ERROR: Database check failed.



In contrast to this my colleage reported the script was working when
using snippy via conda environment:

# create the environment
mamba create -n snippy
# install snippy (version fixing of snpeff is essential to avoid a bug when 
using genbank files as reference
input)
mamba activate snippy
mamba install -y -c conda-forge -c bioconda -c defaults snpeff=5.0 snippy
# check 

Bug#1029201: openbox-menu: do not release with bookworm

[Mateusz Łukasik]

Package: openbox-menu
Version:0.8.0+hg20161009-3.1
Severity: serious

openbox-menu should not be shipped in bookworm.

--
.''`.  Mateusz Łukasik
: :' :  l0calh0st.pl
`. `'   Debian Member -mat...@linuxmint.pl
  `-GPG: D93B 0C12 C8D0 4D7A AFBC  FA27 CCD9 1D61 11A0 6851

Bug#1029200: CVE-2022-47950: Arbitrary file access through custom S3 XML entities

[Thomas Goirand]

Source: swift-proxy
Version: 2.26.0-10
Severity: serious
Tags: patch

Title: Arbitrary file access through custom S3 XML entities
Reporter: Sébastien Meriot (OVH)
Products: Swift
Affects: <2.28.1, >=2.29.0 <2.29.2, ==2.30.0

Description:
Sébastien Meriot (OVH) reported a vulnerability in Swift's S3 XML
parser. By supplying specially crafted XML files an authenticated
user may coerce the S3 API into returning arbitrary file contents
from the host server resulting in unauthorized read access to
potentially sensitive data; this impacts both s3api deployments
(Rocky or later), and swift3 deployments (Queens and earlier, no
longer actively developed). Only deployments with S3 compatibility
enabled are affected.

See attached patches. Unless a flaw is discovered in them, these
patches will be merged to their corresponding branches on the public
disclosure date. The master branch patch applies cleanly to
stable/zed, stable/yoga, stable/xena and stable/wallaby branches,
but separate copies of it are attached for each for the sake of
clarity. The fix could be applied with some fuzz to branches as old
as stable/train, and with some minor unit test adjustments as far
back as stable/rocky. Note that the stable/wallaby branch is under
extended maintenance (as are older branches) and will receive no new
point releases, but a patch for it is provided as a courtesy.

CVE: CVE-2022-47950

Proposed public disclosure date/time:
2023-01-17, 1500UTC
Please do not make the issue public (or release public patches)
before this coordinated embargo date.

Original private report:
https://launchpad.net/bugs/1998625
For access to read and comment on this report, please reply to me
with your Launchpad username and I will subscribe you.

Bug#1029196: kylin-video: Has hard dependency on libmpv1 which doesn't exist

[Santiago Vila]

Note: Hardcoded dependency on libffmpegthumbnailer4v5 in debian/control
is also highly suspicious and should probably be removed as well.

(this is what ${shlibs:Depends} is for)

Thanks.

Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.

[Christoph Martin]

yq is in NEW:

https://ftp-master.debian.org/new/yq_3.1.0-1.html

Am 18.01.23 um 19:17 schrieb Christoph Martin:

I've build an initial package and will upload it soon for review.



OpenPGP_signature
Description: OpenPGP digital signature