Bug#1021757: licensecheck: Handle wrapped copyright statements

[Andreas Metzler]

Package: licensecheck
Version: 3.3.0-1
Severity: normal

Hello,

licensecheck does seem to handle wrapped copyright statements:

(sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.8$ head -n4 
m4/ltoptions.m4 m4/lib-prefix.m4
==> m4/ltoptions.m4 <==
# Helper functions for option handling.-*- Autoconf -*-
#
#   Copyright (C) 2004-2005, 2007-2009, 2011-2015 Free Software
#   Foundation, Inc.

==> m4/lib-prefix.m4 <==
# lib-prefix.m4 serial 20
dnl Copyright (C) 2001-2005, 2008-2022 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,

(sid)ametzler@argenau:/tmp/GUILE-GNUTLS/guile-gnutls-3.7.8$ licensecheck -r m4 
--copyright | grep -A1 -E 'm4/ltoptions.m4|m4/lib-prefix.m4'
m4/lib-prefix.m4: FSF Unlimited License (with License Retention)
  [Copyright: 2001-2005, 2008-2022 Free Software Foundation, Inc.]
--
m4/ltoptions.m4: FSF Unlimited License (with License Retention)
  [Copyright: 2004-2005, 2007-2009, 2011-2015 Free Software]

cu Andreas

Bug#1017845: Endless fork loop at installation time: /usr/bin/emacs --batch -l /tmp/emacs-int-comp-subr--trampoline-7363726f6c6c2d6f746865722d77696e646f77_scroll_other_window_0-.el

[Sean Whitton]

Hello,

On Sun 21 Aug 2022 at 02:46PM +02, Axel Beckert wrote:

> Package: emacs-common
> Version: 1:28.1+1-2
> Severity: serious
> X-Debbugs-Cc: a...@debian.org
> Control: affects -1 elpa-folding elpa-org elpa-git-timemachine 
> elpa-password-store
>
> Hi,
>
> upgrading emacs respectively emacs-gtk from 27.1 to 28.1 causes an
> endless fork loops during package configuration time:

Are you able to reproduce this with what's in sid at present?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1017711: emacs-gtk: terminated with signal SIGABRT, 137 MB coredump

[Sean Whitton]

Hello,

On Mon 22 Aug 2022 at 02:55AM +02, Vincent Lefevre wrote:

> Control: found -1 1:28.1+1-2
> Control: severity -1 serious
>
> On 2022-08-19 12:10:31 +0200, Vincent Lefevre wrote:
>> I have noticed that Emacs left a 137 MB coredump.
>
> This has occurred again (this time a 54 MB coredump).
> This is going to use much disk space...
>
>> gdb says:
>>
>> Reading symbols from /usr/bin/emacs...
>> Reading symbols from 
>> /usr/lib/debug/.build-id/d0/b7c40dc33110b0623ea2ca797a6d3f3eb166b5.debug...
>> [New LWP 1483812]
>> [New LWP 1483816]
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> Core was generated by `/usr/bin/emacs --batch -l 
>> /tmp/emacs-async-comp-cc-engine.el-2UV1nf.el'.
>
> This time,
>
> Core was generated by `/usr/bin/emacs --batch -l 
> /tmp/emacs-async-comp-auth-source.el-84YT0a.el'.
> Program terminated with signal SIGABRT, Aborted.
>
> I'm wondering whether this is related to bug 1017845, as a
> "/usr/bin/emacs --batch -l /tmp/emacs-async-..." is also involved.

Can you reproduce this with what's in sid now?

It may have been fixed by adding the emacs-el dependency.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1021756: Blender isn't compiled with GMP support

[Adam Logghe]

Package: blender
Version: 3.2.2+dfsg-3
Severity: important
X-Debbugs-Cc: a...@devtty.net

Dear Maintainer,

   In trying to do some geometry node work I was unable to use the Mesh
Boolean node because it said that Blender hadn't been compiled with GMP
support so it deactivated itself.

I found a bug report against Void Linux with the same issues, testing and a
resolution ---

https://github.com/void-linux/void-packages/issues/36751

As that bug report points out that's also going to cause bad behaviour in
doing

https://en.wikipedia.org/wiki/Constructive_solid_geometry

ie booleans, which is an important workflow in modelling.

Cheers,

Adam


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: 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 blender depends on:
ii  blender-data  3.2.2+dfsg-3
ii  fonts-dejavu  2.37-2
ii  libavcodec59  7:5.1.2-1
ii  libavdevice59 7:5.1.2-1
ii  libavformat59 7:5.1.2-1
ii  libavutil57   7:5.1.2-1
ii  libboost-locale1.74.0 1.74.0-17
ii  libc6 2.35-2
ii  libembree3-3  3.13.4+dfsg-1
ii  libfftw3-double3  3.3.8-2
ii  libfreetype6  2.12.1+dfsg-3
ii  libgcc-s1 12.2.0-3
ii  libgl11.5.0-1
ii  libglew2.22.2.0-4+b1
ii  libgomp1  12.2.0-3
ii  libimath-3-1-29   3.1.5-1+b1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-1
ii  libjemalloc2  5.2.1-5
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libopenal11:1.19.1-2
ii  libopencolorio2.1 2.1.2+dfsg1-4
ii  libopenexr-3-1-30 3.1.5-4
ii  libopenimageio2.3 2.3.18.0+dfsg-5
ii  libopenjp2-7  2.5.0-1
ii  libopenvdb9.1 9.1.0-7+b1
ii  libosdcpu3.4.43.4.4-2
ii  libosdgpu3.4.43.4.4-2
ii  libpcre3  2:8.39-14
ii  libpng16-16   1.6.38-2
ii  libpugixml1v5 1.12.1-1
ii  libpulse0 16.1+dfsg1-2
ii  libpython3.10 3.10.7-1
ii  libsdl2-2.0-0 2.24.1+dfsg-1
ii  libsndfile1   1.1.0-3
ii  libspnav0 1.0-1
ii  libstdc++612.2.0-3
ii  libswscale6   7:5.1.2-1
ii  libtbb12  2021.5.0-15
ii  libtiff5  4.4.0-4
ii  libx11-6  2:1.8.1-2
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  libxml2   2.9.14+dfsg-1+b1
ii  libxrender1   1:0.9.10-1.1
ii  libxxf86vm1   1:1.1.4-1+b2
ii  libzstd1  1.5.2+dfsg-1
ii  zlib1g1:1.2.11.dfsg-4.1

blender recommends no packages.

blender suggests no packages.

-- no debconf information

Bug#1020193: (no subject)

[Lev Lamberov]

This bug is fixed in the upstream repository, but the fix requires a.el,
which is in NEW at the moment. I'll upload fix for pcre2el when a-el
gets accepted.

Regards,
Lev

Bug#1021755: racon: build-dependencies unsatisfiable on 32-bit.

[Peter Green]

Package: racon
Version: 1.5.0-2
Severity: serious

racon build-depends on libthread-pool-dev which is no longer available on 32-bit
architectures, this means that the package can no longer be built on those
architectures but the binaries are still in testing/unstable.

In general there are three possible avenues for fixing these kinds of issues,
in roughly descending order of preference.

1. Fix libthread-pool-dev to build on 32-bit architectures.
2. Eliminate the build-dependency (either generally or on those architectures)
3. Declare your package unsupportable on 32-bit architectures and file a removal
   request with the ftpmasters.

Which of these are possible in the case of your specific package I do not know.

Bug#1021754: rust-zoxide: build-dependencies unsatisfiable.

[Peter Green]

Package: rust-zoxide
Version: 0.4.3-4
Severity: serious

The rust-zoxide package depends on version 0.2 of the float-ord
crate, but testing/unstable now has version 0.3

Unfortunately when I try to prepare an update with debcargo I get.

REALVER=0.4.3 SOURCEONLY=1 DEBFULLNAME="Peter Michael Green" 
DEBEMAIL=plugw...@debian.org ./update.sh zoxide
Updating crates.io index
  Downloaded zoxide v0.8.3
debcargo failed: failed to parse manifest at 
`/root/.cargo/registry/src/github.com-1ecc6299db9ec823/zoxide-0.8.3/Cargo.toml`

Caused by:
feature `strip` is required

The package requires the Cargo feature called `strip`, but that feature is 
not stabilized in this version of Cargo (1.56.0).
Consider trying a more recent nightly release.
See 
https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-strip-option
 for more information about the status of this feature.

./update.sh: abort: couldn't find crate zoxide

Bug#1021753: ganeti: conflicting curl build-depends

[Peter Green]

Package: ganeti
Version: 3.0.2-1
Tags: bookworm, sid

ganeti build-depends on both libcurl4-openssl-dev and libghc-curl-dev,
the current version of libghc-curl-dev build-depends on libcurl4-gnutls-dev
and libcurl4-gnutls-dev conflicts with libcurl4-openssl-dev.

Therefore your packages build-dependencies are unsatisfiable.

Bug#1021752: RM: librust-serde+derive-dev -- NBS; no longer built

[James McCoy]

Package: ftp.debian.org
Severity: normal

The package is no longer built.  It is now a Provides of
librust-serde+serde-derive-dev.

Bug#809443: autopkgtest: support systemd-nspawn as an isolation-container level virtualization tool

[Daniel Kahn Gillmor]

On Wed 2015-12-30 19:42:23 +0100, Raphaël Hertzog wrote:
> systemd-nspawn supports --template and/or --ephemeral (provided that you use 
> btrfs)
> so that you can have throw-away chroots. It also supports various
> networking related options (--private-network notably) so that you can get
> proper network isolation.
>
> It would thus be nice to be able to use it with autopkgtest.

This seems like a good idea to me, as well.

I haven't done much hacking on autopkgtest, but if you have pointers for
how to add a new isolation-container backend, i'd be happy to try to
work on it.

What's the best approach?  Should someone who wanted to add an nspawn
isolation container try to copy ./virt/autopkgtest-virt-lxc and
./tools/autopkgtest-build-lxc (and their associated manpages) and tweak
them to use nspawn instead of lxc?

Or is there a better way forward?

 --dkg


signature.asc
Description: PGP signature

Bug#1021751: dc3dd: reproducible-builds: date in dc3dd manpage

[Vagrant Cascadian]

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

The date is embedded in /usr/share/man/man1/dc3dd.1.gz:

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

  .TH·DC3DD·"1"·"October·2022"·"dc3dd·7.2.646"·"User·Commands"
  vs.
  .TH·DC3DD·"1"·"November·2023"·"dc3dd·7.2.646"·"User·Commands"

The attached patches fix this by adding help2man to Build-Depends and
using the packaged version of help2man from Makefile.am.

According to my local tests, with these patches applied dc3dd should
build reproducibly on tests.reproducible-builds.org!

Thanks for maintaining dc3dd!

live well,
  vagrant
From 0ff67d76e43a58719330b29cf6dc666c6c3adb48 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 14 Oct 2022 01:05:51 +
Subject: [PATCH 1/2] debian/control: Add help2man to Build-Depends.

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 389d0ef..417b1b4 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,7 @@ Maintainer: Debian Security Tools 
 Build-Depends: bison,
debhelper-compat (= 13),
gperf,
+   help2man,
liblocale-gettext-perl
 Standards-Version: 4.6.0.1
 Homepage: http://dc3dd.sf.net
-- 
2.37.2

From 00a23d1d0db3ab5f6abd7dbba6a6ae09a7f0e2ed Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 14 Oct 2022 01:06:25 +
Subject: [PATCH 2/2] man/Makefile.am: Use packaged help2man.

The embedded copy of help2man is an old version lacking fixes to
support reproducible timestamps.
---
 man/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/man/Makefile.am b/man/Makefile.am
index 19b4841..3ba7c8b 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -51,7 +51,7 @@ mapped_name = `echo $*|sed 's/^install$$/ginstall/; s/^test$$/[/'`
 	 rm -rf $t;	\
 	 mkdir $t;	\
 	 (cd $t && $(LN_S) ../../src/$(mapped_name) $*); \
-	$(PERL) -- $(srcdir)/help2man		\
+	help2man	\
 	 --source='$(PACKAGE_STRING)'		\
 	 --include=$(srcdir)/$*.x			\
 	 --output=$t/$@ $t/$*;			\
-- 
2.37.2



signature.asc
Description: PGP signature

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

[Vincent Lefevre]

Package: general
Severity: normal

The /etc/fstab file is created using by default ext4 with just
the errors=remount-ro option. However, the Debian FAQ recommends
the nodelalloc mount option to avoid performance degradation and
preserve data safety:

https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_is_dpkg_so_slow_when_using_new_filesystems_such_as_btrfs_or_ext4.3F

  For ext4, use instead the "nodelalloc" mount option, which should
  fix both the performance degradation and the data safety issues,
  and not for just dpkg, but for any application in the system.

So this option should be used by default for btrfs and ext4.

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

Bug#1021749: ca-certificates: expired certificates: Cybertrust_Global_Root.crt GlobalSign_Root_CA_-_R2.crt

[Paul Wise]

Package: ca-certificates
Version: 20211016
Severity: normal
File: /usr/share/ca-certificates/mozilla/Cybertrust_Global_Root.crt
File: /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt

I noticed that there are two expired certificates in ca-certificates,
presumably Mozilla would have removed them and so an update is needed.

   $ cat test
   now=$(date -u)
   date -d "$now"
   now="$(date -d "$now" +%s)"
   for f in /usr/share/ca-certificates/mozilla/* ; do
date="$(openssl x509 -enddate -noout -in "$f" | cut -d= -f2)"
d="$(date -d "$date" +%s)"
if [ $((d<=now)) -eq 1 ] ; then
 echo Expired: $f $date $d $now
fi
   done
   
   $ sh test
   Fri 14 Oct 2022 08:53:43 AWST
   Expired: /usr/share/ca-certificates/mozilla/Cybertrust_Global_Root.crt Dec 
15 08:00:00 2021 GMT 1639555200 1665708823
   Expired: /usr/share/ca-certificates/mozilla/GlobalSign_Root_CA_-_R2.crt Dec 
15 08:00:00 2021 GMT 1639555200 1665708823

This results in some programs such as GnuPG dirmngr printing errors.

   $ journalctl --no-hostname --user -ru dirmngr | head | grep error
   Oct 14 08:59:38 dirmngr[986199]: error loading certificate 
'/etc/ssl/certs/ca-certificates.crt': Certificate expired
   Oct 14 08:59:38 dirmngr[986199]: error loading certificate 
'/etc/ssl/certs/ca-certificates.crt': Certificate expired

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages ca-certificates depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  openssl3.0.5-2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information:
  ca-certificates/title:
* ca-certificates/trust_new_crts: yes
* ca-certificates/enable_crts: mozilla/ACCVRAIZ1.crt, 
mozilla/AC_RAIZ_FNMT-RCM.crt, mozilla/AC_RAIZ_FNMT-RCM_SERVIDORES_SEGUROS.crt, 
mozilla/Actalis_Authentication_Root_CA.crt, mozilla/AffirmTrust_Commercial.crt, 
mozilla/AffirmTrust_Networking.crt, mozilla/AffirmTrust_Premium.crt, 
mozilla/AffirmTrust_Premium_ECC.crt, mozilla/Amazon_Root_CA_1.crt, 
mozilla/Amazon_Root_CA_2.crt, mozilla/Amazon_Root_CA_3.crt, 
mozilla/Amazon_Root_CA_4.crt, mozilla/ANF_Secure_Server_Root_CA.crt, 
mozilla/Atos_TrustedRoot_2011.crt, 
mozilla/Autoridad_de_Certificacion_Firmaprofesional_CIF_A62634068.crt, 
mozilla/Baltimore_CyberTrust_Root.crt, mozilla/Buypass_Class_2_Root_CA.crt, 
mozilla/Buypass_Class_3_Root_CA.crt, mozilla/CA_Disig_Root_R2.crt, 
mozilla/Certigna.crt, mozilla/Certigna_Root_CA.crt, 
mozilla/certSIGN_ROOT_CA.crt, mozilla/certSIGN_Root_CA_G2.crt, 
mozilla/Certum_EC-384_CA.crt, mozilla/Certum_Trusted_Network_CA_2.crt, 
mozilla/Certum_Trusted_Network_CA.crt, mozilla/Certum_Trusted_Root_CA.crt, 
mozilla/CFCA_EV_ROOT.crt, mozilla/Comodo_AAA_Services_root.crt, 
mozilla/COMODO_Certification_Authority.crt, 
mozilla/COMODO_ECC_Certification_Authority.crt, 
mozilla/COMODO_RSA_Certification_Authority.crt, 
mozilla/Cybertrust_Global_Root.crt, mozilla/DigiCert_Assured_ID_Root_CA.crt, 
mozilla/DigiCert_Assured_ID_Root_G2.crt, 
mozilla/DigiCert_Assured_ID_Root_G3.crt, mozilla/DigiCert_Global_Root_CA.crt, 
mozilla/DigiCert_Global_Root_G2.crt, mozilla/DigiCert_Global_Root_G3.crt, 
mozilla/DigiCert_High_Assurance_EV_Root_CA.crt, 
mozilla/DigiCert_Trusted_Root_G4.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_2009.crt, 
mozilla/D-TRUST_Root_Class_3_CA_2_EV_2009.crt, mozilla/EC-ACC.crt, 
mozilla/emSign_ECC_Root_CA_-_C3.crt, mozilla/emSign_ECC_Root_CA_-_G3.crt, 
mozilla/emSign_Root_CA_-_C1.crt, mozilla/emSign_Root_CA_-_G1.crt, 
mozilla/Entrust.net_Premium_2048_Secure_Server_CA.crt, 
mozilla/Entrust_Root_Certification_Authority.crt, 
mozilla/Entrust_Root_Certification_Authority_-_EC1.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G2.crt, 
mozilla/Entrust_Root_Certification_Authority_-_G4.crt, 
mozilla/ePKI_Root_Certification_Authority.crt, 
mozilla/e-Szigno_Root_CA_2017.crt, mozilla/E-Tugra_Certification_Authority.crt, 
mozilla/GDCA_TrustAUTH_R5_ROOT.crt, mozilla/GlobalSign_ECC_Root_CA_-_R4.crt, 
mozilla/GlobalSign_ECC_Root_CA_-_R5.crt, mozilla/GlobalSign_Root_CA.crt, 
mozilla/GlobalSign_Root_CA_-_R2.crt, mozilla/GlobalSign_Root_CA_-_R3.crt, 
mozilla/GlobalSign_Root_CA_-_R6.crt, mozilla/GlobalSign_Root_E46.crt, 
mozilla/GlobalSign_Root_R46.crt, mozilla/GLOBALTRUST_2020.crt, 
mozilla/Go_Daddy_Class_2_CA.crt, 
mozilla/Go_Daddy_Root_Certificate_Authority_-_G2.crt, mozilla/GTS_Root_R1.crt, 
mozilla/GTS_Root_R2.crt, 

Bug#1021748: mupen64plus: no video (SDL reports an invalid pitch)

[Michael Gold]

Source: mupen64plus
Version: 2.5+6
Severity: important

Dear Maintainer,

With the most recent mupen64plus package, I no longer see video with any
game.  (A previous version was working.)  The console shows some errors:
Core: Setting video mode: 960x720
Core Error: SDL_SetVideoMode failed: Parameter 'pitch' is invalid
Video Error: Could not set video mode.
Core: Setting video mode: 960x720
Core Error: SDL_SetVideoMode failed: Parameter 'pitch' is invalid
Video Error: Could not set video mode.
Video Error: Error setting display mode

This bug was already reported and fixed upstream:
https://github.com/mupen64plus/mupen64plus-core/issues/969

In case anyone's looking for a workaround, I've attached some code that
can be built as a shared object and loaded via $LD_PRELOAD.

- Michael


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

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

Versions of packages mupen64plus-audio-all depends on:
ii  mupen64plus-audio-sdl  2.5-5

mupen64plus-audio-all recommends no packages.

mupen64plus-audio-all suggests no packages.

-- no debconf information
#define _GNU_SOURCE// make dlfcn.h define RTLD_NEXT
#include 
#include 
#include 
#include 

struct SDL_Surface*
SDL_CreateRGBSurfaceFrom(void *pixels,
int width, int height, int depth, int pitch,
uint32_t Rmask, uint32_t Gmask, uint32_t Bmask, uint32_t Amask)
{
static struct SDL_Surface*(*real_fn)(void*, int, int, int, int,
uint32_t, uint32_t, uint32_t, uint32_t) = NULL;
if (!pitch) {
pitch = (depth + 7) / 8 * width;
}
if (!real_fn) {
real_fn = dlsym(RTLD_NEXT, __func__);
if (!real_fn) {
errno = ELIBACC;
return (void*)0;
}
}
return real_fn(pixels, width, height, depth, pitch,
Rmask, Gmask, Bmask, Amask);
}


signature.asc
Description: PGP signature

Bug#1021747: RM: rust-hex-literal-impl -- ROM; absorbed into rust-hex-literal

[James McCoy]

Package: ftp.debian.org
Severity: normal

As of version 0.3.0 of rust-hex-literal, rust-hex-literal-impl is
irrelevant.  It's functionality was moved directly into
rust-hex-literal.

Bug#1021698: libical3: Version 3.0.15-2 cannot parse ics files anymore

[Nicolas Mora]

Hello,

Le 2022-10-13 à 04 h 42, Konstantinos a écrit :


Came to work todat after upgrading from 3.0.14-1+b1 to 3.0.15-2 and could not
see my calendar. Evolution would neither parse calendar.ics nor tasks.ics.
After downgrading to 3.0.14-1+b1 everything works again. I know this is
debian/testing but breaking users' calendar is quite critical.

I can't reproduce your bug on a fresh Debian bookworm install with 
package libical3 3.0.15-2


I've tried with a remote calendar hosted on a nextcloud, and a local ics 
file. Both work fine.


I've attached the local ics file used for my tests. Can you test it and 
tell me if your evolution parses it correctly?


If possible, can you share an anonymized calendar in this bug to 
reproduce the problem? Beware not to send personal data in this bug.


/NicolasBEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ical.marudot.com//iCal Event Maker
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Havana
LAST-MODIFIED:20201011T015911Z
TZURL:http://tzurl.org/zoneinfo-outlook/America/Havana
X-LIC-LOCATION:America/Havana
BEGIN:STANDARD
TZNAME:CST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:19701101T01
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:19700308T00
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20221013T233444Z
UID:1665703999138-78...@ical.marudot.com
DTSTART;TZID=America/Havana:20221013T12
DTEND;TZID=America/Havana:20221013T18
SUMMARY:test
URL:http://there.com
DESCRIPTION:test
LOCATION:there
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20221013T233444Z
UID:1665704069173-51...@ical.marudot.com
DTSTART;TZID=America/Havana:20221013T12
RRULE:FREQ=DAILY
DTEND;TZID=America/Havana:20221013T12
SUMMARY:repeat
URL:http://over.com
DESCRIPTION:repeat
LOCATION:over there
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20221013T233444Z
UID:1665704032497-69...@ical.marudot.com
DTSTART;VALUE=DATE:20221014
DTEND;VALUE=DATE:20221015
SUMMARY:all day
URL:http://here.com
DESCRIPTION:all day
LOCATION:here
END:VEVENT
END:VCALENDAR

Bug#1021746: obsolete conffile /etc/dbus-1/system.d/net.hadess.PowerProfiles.conf not cleaned up on upgrades

[Michael Biebl]

Package: power-profiles-daemon
Version: 0.12-1
Severity: normal


The obsolete conffile /etc/dbus-1/system.d/net.hadess.PowerProfiles.conf
is not cleaned up on upgrades. The file is now shipped as
/usr/share/dbus-1/system.d/net.hadess.PowerProfiles.conf.



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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 power-profiles-daemon depends on:
ii  libc6  2.35-3
ii  libglib2.0-0   2.74.0-3
ii  libgudev-1.0-0 237-2
ii  libpolkit-gobject-1-0  121+compat0.1-5

power-profiles-daemon recommends no packages.

power-profiles-daemon suggests no packages.

-- no debconf information

Bug#1021742: open-iscsi: Ingest upstream 2.1.8

[Eric Mackay]

I made a merge request to ingest 2.1.8: 
https://salsa.debian.org/linux-blocks-team/open-iscsi/-/merge_requests/12


I obviously don't have permissions to push a pristine tar of 2.1.8 so it 
likely won't build in any Salsa pipelines. I did build it locally on my 
Debian 11 box with a clean git checkout.


As I mentioned in the merge request, I don't have a preference on 
whether my merge request is accepted or another is made by the package 
maintainers.


Hoping to submit some patches in the near future to the Debian package 
that rely on code added in 2.1.8

Bug#1020019: spring: FTBFS

[Markus Koschany]

I have been working on packaging a new upstream release which should address
this problem. I still need to resolve some issues with the build system and the
patches. The current results can be found in Git.


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

Bug#1021745: passwd: /etc/passwd was edited with the wrong shell path

[Najib B]

Package: passwd
Version: 1:4.12.3+dfsg1-1
Severity: important
X-Debbugs-Cc: najibbak...@gmail.com

Dear Maintainer,

I have just noticed this issue on chsh that I would like to report to you,
including a solution that I would like to mention.

--
# chsh
Changing the login shell for root
Enter the new value, or press ENTER for the default
Login Shell [/bin/zsh]: zsh
chsh: Warning: zsh does not exist

exit
$ sudo chsh
Password:
chsh: PAM: Authentication failure`
---
The problem here, is that chsh has accepted "zsh" without checking first, if
that path exists.

After exiting "root" it is not possible to login back.
The solution is to edit /etc/passwd from this:
root:x:0:0:root:/root:zsh
to this:
root:x:0:0:root:/root:/bin/zsh

Best regards,


-- System Information:
Distributor ID: Kali
Description:Kali GNU/Linux Rolling
Release:2022.3
Codename:   kali-rolling
Architecture: x86_64

Kernel: Linux 5.18.0-kali7-amd64 (SMP w/3 CPU threads; PREEMPT)
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 passwd depends on:
ii  libaudit1   1:3.0.7-1.1
ii  libc6   2.34-4
ii  libcrypt1   1:4.4.28-2
ii  libpam-modules  1.5.2-5
ii  libpam0g1.5.2-5
ii  libselinux1 3.4-1+b2
ii  libsemanage23.4-1+b2

Versions of packages passwd recommends:
ii  sensible-utils  0.0.17

passwd suggests no packages.

-- no debconf information

Bug#1008735: base-files: /etc/os-release should contain VERSION variables for testing and unstable

[Sedat Dilek]

On Thu, Oct 13, 2022 at 4:03 PM Masahiro Yamada  wrote:
>
> Hi Sedat,
>
> Sorry for my late replay.
>
>
> On Mon, Oct 3, 2022 at 6:56 PM Sedat Dilek  wrote:
> >
> > [ CC linux-kbuild folks (see [0] ]
>
>
>
> Can you give me more context of this email?
>
>
>
>
> > Hi,
> >
> > I am using Debian/unstable AMD64 and doing Linux-kernel upstream
> > development and testing.
> >
> > People using bindeb-pkg (mkdebian) from Linux-kernel sources
> > (scripts/packages) to build and test their selfmade Debian kernels get
> > a now a "n/a" for distribution.
>
>
>
> Right, if I try the latest sid,
> "lsb_release -cs" returns "n/a".
> It returned "sid" before IIRC.
>
>
> What was changed in Debian?
> Any change in the lsb_release program?
>

Hi Masahiro San,

The Debian maintainer(s) changed the co-working of these packages:

root# dpkg -l | egrep 'base-files|lsb-release' | awk '/^ii/ {print $1
" " $2 " " $3}' | column -t
ii  base-files   12.3
ii  lsb-release  12.0-1
ii  lsb-release-minimal  12.0-1

My findings:
First, /usr/bin/lsb_release-11.4 (python) VS.
/usr/bin/lsb_release-12.0 (shell) - both files attached.
Second, version 12.0 checks now explicitly for values in /etc/os-release.
As a side note: All these changes were not mentioned in lsb-release
debian/changelog.

The easiest way to fix this is to add...

VERSION_ID=sid (or unstable)

...to /etc/os-release file.

Just for the sake of technical correctness:
"sid" or "unstable" is not a numerical value - it's a string.

In version 12.3 of base-files "VERSION_CODENAME=bookworm" was added on
users' request.

Last checks:

Original (base-files version 12.0):

[ /etc/os-release ]
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

root# lsb_release --all
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:n/a
Codename:   bookworm

Modified:

[ /etc/os-release ]
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=bookworm
VERSION_ID=sid
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

root# lsb_release --all
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:sid
Codename:   bookworm

More comments see https://bugs.debian.org/1008735.

-Sedat-

>
>
>
>
>
> >
> > Background (see [1]):
> >
> > [ scripts/package/mkdebian ]
> >
> > # Try to determine distribution
> > if [ -n "$KDEB_CHANGELOG_DIST" ]; then
> > distribution=$KDEB_CHANGELOG_DIST
> > # In some cases lsb_release returns the codename as n/a, which breaks
> > dpkg-parsechangelog
> > elif distribution=$(lsb_release -cs 2>/dev/null) && [ -n
> > "$distribution" ] && [ "$distribution" != "n/a" ]; then
> > : # nothing to do in this case
> > else
> > distribution="unstable"
> > echo >&2 "Using default distribution of 'unstable' in the changelog"
> > echo >&2 "Install lsb-release or set \$KDEB_CHANGELOG_DIST 
> > explicitly"
> > fi
> >
> > Personally, I set hardcoded in my kernel build-script as a workaround:
> >
> > distribution="bookworm"
> >
> > Gioele suggested me to enrich /etc/os-release with:
> >
> > VERSION_ID=unstable <--- XXX: I prefer sid because of PRETTY_NAME and
> > it's shorter
> > VERSION_CODENAME=bookworm
> >
> > In the end the file looks like:
> >
> > PRETTY_NAME="Debian GNU/Linux bookworm/sid"
> > NAME="Debian GNU/Linux"
> > ID=debian
> > VERSION_ID=sid
> > VERSION_CODENAME=bookworm
> > HOME_URL="https://www.debian.org/;
> > SUPPORT_URL="https://www.debian.org/support;
> > BUG_REPORT_URL="https://bugs.debian.org/;
> >
> > ...and this seems to work:
> >
> > # lsb_release -cs
> > No LSB modules are available.
> > bookworm
> >
> > Please, provide a solution not to break workflows that were successful
> > for years.
> >
> > Thanks.
> >
> > Best regards,
> > -Sedat-
> >
> > [0] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n11005
> > [1] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/package/mkdebian#n123
>
>
>
> --
> Best Regards
> Masahiro Yamada


lsb_release-11.4
Description: Unix manual page


lsb_release-12.0
Description: Binary data

Bug#997972: haskell-pandoc-citeproc has been deprecated upstream

[Louis-Philippe Véronneau]

retitle 997972 haskell-pandoc-citeproc not needed, should be RMed
thanks

Hello!

I see that pandoc has been updated (many, many thanks) and the 
aforementioned 'citeproc' package has indeed been packaged as 
"haskell-citeproc".


I see no reason for this package not to be RMed, since the current 
version of pandoc in Sid supports '--citeproc' and fails with the old 
'--filter pandoc-citeproc' anyway:


---
pandoc-citeproc: Error in $: Incompatible API versions: encoded with 
[1,22,2] but attempted to decode with [1,20].

CallStack (from HasCallStack):
  error, called at ./Text/Pandoc/JSON.hs:112:48 in 
pandoc-types-1.20-JP83YEZp4VZ5qbwCPN8866:Text.Pandoc.JSON

Error running filter pandoc-citeproc:
Filter returned error status 1
make: *** [Makefile:6: pdf] Error 83
---

Cheers, and thanks for your work on this.

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄


OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021744: RFS: dwm/6.4-0.1 [NMU] -- dynamic window manager

[Matteo Bini]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dwm":

 * Package name : dwm
   Version  : 6.4-0.1
 * URL  : https://dwm.suckless.org/
 * License  : Expat
 * Vcs  : https://salsa.debian.org/hle/dwm
   Section  : x11

The source builds the following binary packages:

  dwm - dynamic window manager

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

  https://mentors.debian.net/package/dwm/

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

  dget -x https://mentors.debian.net/debian/pool/main/d/dwm/dwm_6.4-0.1.dsc

Changes since the last upload:

 dwm (6.4-0.1) unstable; urgency=low
 .
   * Non-maintainer upload.
   * New upstream release.
   * debian/control:
 - Bump Standards-Version to 4.6.1.
   * debian/copyright:
 - Update copyright for new upstream release.
 - Update Matteo's email address.
   * debian/dwm.menu:
 - Delete menu file due to Technical Committee decision.
   * debian/icons:
 - Update dwm.png with upstream one.
 - Add hicolor scalable icon in places dir (dwm_badge-symbolic.svg) for
   lightdm-gtk-greeter.
   * debian/patches/*:
 - Refresh patches for new upstream release.

Regards,

-- 
Matteo Bini

Bug#712939: control messages ugly: cont.

[Guillem Jover]

Hi!

On Thu, 2014-02-06 at 03:11:50 +0100, Guillem Jover wrote:
> On Sat, 2014-02-01 at 15:35:21 +0100, Mathieu Parent wrote:
> > Control: tag -1 + wontfix
> 
> > I can confirm that this is still the case.
> > 
> > Example:
> > http://packages.qa.debian.org/p/php-horde-activesync/news/20140129T212127Z.html
> > 
> >  php-horde-activesync - ${phppear:summary}
> > 
> > Guillem: Was it a different reason that #659814 (my guess is still #5210)?
> 
> Ah, yeah sorry, I guess I did not pay enough attention to this bug's
> details. But I think these substvars make some sense, so I'll ponder
> about the possibility of supporting this in dpkg-genchanges.

BTW, if I've reloaded the context correctly for this, substvars for
Description fields for .changes files are supported since dpkg 1.19.0,
so I guess the wontfix can be removed from here, and handled in
whatever way needed?

Thanks,
Guillem

Bug#1021743: ITP: sugarjar -- A Git/GitHub helper

[Michel Alexandre Salim]

Package: wnpp
Severity: wishlist
Owner: Michel Alexandre Salim 
X-Debbugs-Cc: debian-de...@lists.debian.org, mic...@michel-slm.name

* Package name: sugarjar
  Version : 0.0.11
  Upstream Author : Phil Dibowitz 
* URL : https://github.com/jaymzh/sugarjar
* License : Apache
  Programming Lang: Ruby
  Description : A Git/GitHub helper

SugarJar is a git/github helper. It needs one of the GitHub CLI's: the current
default is hub, but there is experimental support for gh.

SugarJar is inspired by arcanist, and its replacement at Meta, JellyFish.
Many of the features they provide for the Phabricator workflow this aims
to bring to the GitHub workflow.

In particular there are a lot of helpers for using a squash-merge workflow
that is poorly handled by the standard toolsets.

If you miss Mondrian or Phabricator - this is the tool for you!

I plan to maintain it myself, though I'd explore joining the Debian Ruby
team or granting them upload rights. I'm a Debian Maintainer so I would
initially need a sponsor to do the initial FTP upload.

Bug#1018193: ITP: the-foundation -- Opinionated C11 library for low-level functionality

[Michel Alexandre Salim]

On Fri, 2022-08-26 at 15:01 -0500, Michel Alexandre Salim wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Michel Alexandre Salim 
> X-Debbugs-Cc: debian-de...@lists.debian.org, mic...@michel-slm.name
> 
> * Package name    : the-foundation
>   Version : 1.4.0
>   Upstream Author : Jaakko Keränen 
> * URL : https://codeberg.org/skyjake/the_Foundation
> * License : BSD
>   Programming Lang: C
>   Description : Opinionated C11 library for low-level
> functionality
> 
> An object-oriented C library whose API is designed for a particular
> coding
> style, taking cues from C++ STL and Qt.
> 
> This is a dependency for Lagrange, a desktop Gemini client:
> https://codeberg.org/skyjake/lagrange
> 
> I already maintain both in Fedora, and would be nice to be able to
> use
> them as native packages when on Debian.

Note that this currently depends on PCRE, instead of PCRE2 - so it
might be worth waiting until this is addressed first

https://codeberg.org/skyjake/the_Foundation/issues/12

-- 
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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

Bug#931402: could not leave editor on examining a config file conflict

[Guillem Jover]

Control: reassign -1 apt

[ Adding some context. ]

On Thu, 2019-07-04 at 10:05:31 +0200, Harald Dunkel wrote:
> Package: dpkg
> Version: 1.18.25

> On the upgrade from Stretch to Buster there was a config
> file conflict (with /etc/issue, but that doesn't matter).
> dpkg allowed me to examine the conflict ("Z"). I could
> adjust the old file using the mg editor, I could save the
> config file using Ctrl-X Ctrl-S, but I could not leave mg
> using Ctrl-X Ctrl-C. The Ctrl-C did not work.
> 
> AFAICT dpkg's "Z" session should set the terminal back to a
> reasonable state before starting a new shell.

On Sun, 2021-02-28 at 10:06:30 -0800, Norman Rasmussen wrote:
> Package: dpkg
> Version: 1.20.7.1
> Followup-For: Bug #931402

> I can reproduce this in just the shell that's started. Ctrl-C doesn't
> seem to have any immediate effect. However once the shell is exited, the
> Ctrl-C causes dpkg to terminate early.
> 
> I suspect that dpkg isn't creating a new foreground process group, so
> the SIGINT from Ctrl-C is being delivered to dpkg instead of the shell
> (or relevant sub-process like the editor).
> 
> Adding a setsid or setpgid call somewhere in spawn_shell and/or
> show_diff would probably fix it.

So AFAICT, the problem seems to be with apt? It sets the process dpkg
is running on as session leader (setsid()), and sets the terminal as the
controlling terminal of that process in pkgDPkgPM::SetupSlavePtyMagic().

Then in pkgDPkgPM::Go() it has the following:

  /* Mask off sig int/quit. We do this because dpkg also does when
 it forks scripts. What happens is that when you hit ctrl-c it sends
 it to all processes in the group. Since dpkg ignores the signal
 it doesn't die but we do! So we must also ignore it */
  sighandler_t old_SIGQUIT = signal(SIGQUIT,SIG_IGN);
  sighandler_t old_SIGINT = signal(SIGINT,SigINT);

The code ignoring these signals is very very old, and the setsid() and
TIOCSCTTY ioctl() are more recent, which I think would have made the
former signal ignoring code irrelevant now.

I've only tested this in dpkg (w/o apt involved it works fine), and I
don't think this can be fixed sanely in dpkg, as I'd need to make dpkg
steal the controlling terminal, and force the signal disposition,
which the caller might have set for some reason, etc. But I think
getting rid of those SIG_IGN sets in apt might fix the issue at hand?

If I've misread the situation, I'm happy to fix dpkg if there's a sane
way to do that though.

Thanks,
Guillem

Bug#1021624: lxd: Global configuration /etc/lxc/config.yaml is ignored

[Mathias Gibbens]

Hi Enrique,

On Wed, 12 Oct 2022 00:31:06 +0200 Enrique Garcia 
wrote:
> According to documentation in /usr/share/doc/lxd/remotes.md, the file
> /etc/lxc/config.yml can be used to store the configuration of
> remotes. However it seems as this file would be ignored.
> The file seems to be correct, since the following workarounds do
> work:
> $ LXD_GLOBAL_CONF=/etc/lxc lxc remote list
> $ LXD_CONF=/etc/lxc lxc remote list

  I think that's a typo in the documentation. Looking at the code [1],
the default config directory is /etc/lxd/, not /etc/lxc/. Testing
locally, if I create a /etc/lxd/config.yml file defining a remote
server, it shows up in `lxc remote list` without having to do anything
else.

  Could you try moving your config file to /etc/lxd/ and letting me
know if that works? If so, I'll forward this bug upstream so we can get
the documentation fixed.

Thanks,
Mathias

[1] -- https://github.com/lxc/lxd/blob/master/lxc/config/config.go#L42


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

Bug#1021741: ITP: golang-github-slack-go-slack -- access the Slack API in Go (library)

[Cyril Brulebois]

Hi Bart,

ba...@debian.org  (2022-10-13):
> close 1021741
> stop
> there is already an ITP
> ITP 993615
> ITP 1021741

While the oversight was discovered on my side a little later (existing
repository on Salsa), I'm not sure closing duplicates this way is the
best way:
 - it uses “close” which means submitters only get a terse message about
   the bug being closed, without the rationale;
 - if the package gets uploaded inbetween (which it did), it will close
   an ITP that's been closed already; merging both reports might make
   more sense, or mailing both reports and submitters so that they can
   decide what to do about that situation?


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1011665: [RFC] Updating crowdsec, adding and updating other packages

[Cyril Brulebois]

Cyril Brulebois  (2022-10-12):
> New packages:
> -
> 
> - golang-ariga-atlas
>+ required by golang-entgo-ent
> - golang-entgo-ent
>+ required by crowdsec
>+ replaces golang-github-facebook-ent
> - golang-github-alexliesenfeld-health
>+ required by crowdsec
> - golang-github-c-robinson-iplib
>+ required by crowdsec
> - golang-github-confluentinc-bincover
>+ required by crowdsec
> - golang-github-crowdsecurity-dlog
>+ required by crowdsec
> - golang-github-crowdsecurity-grokky
>+ required by crowdsec
>+ replaces golang-github-logrusorgru-grokky
> - golang-github-crowdsecurity-machineid
>+ required by crowdsec
> - golang-github-jszwec-csvutil
>+ required by crowdsec
> - golang-github-r3labs-diff
>+ required by crowdsec
> - golang-github-slack-go-slack
>+ required by crowdsec

All in NEW:

#1021716: ITP: golang-ariga-atlas
#1021721: ITP: golang-entgo-ent
#1021725: ITP: golang-github-alexliesenfeld-health
#1021720: ITP: golang-github-c-robinson-iplib
#1021717: ITP: golang-github-confluentinc-bincover
#1021715: ITP: golang-github-crowdsecurity-dlog
#1021718: ITP: golang-github-crowdsecurity-grokky
#1021724: ITP: golang-github-crowdsecurity-machineid
#1021719: ITP: golang-github-jszwec-csvutil
#1021722: ITP: golang-github-r3labs-diff

Uploaded to NEW, but dinstall is still running:

#1021741: ITP: golang-github-slack-go-slack

For the last one, I had failed to spot earlier work that seems to have
stalled a bit since then:
  
https://salsa.debian.org/go-team/packages/golang-github-slack-go-slack/-/issues/5#note_284108

I've taken the liberty to push the latest version, but I'll make sure
to credit Takuma Shibuya in a follow-up commit!

The package seems quite similar, and we encountered the same issue,
which I've filed upstream:
  https://github.com/slack-go/slack/issues/1116

I'm very sorry, I only realized when creating the Salsa repository,
which failed because it existed already!


> New -vN packages:
> -
> 
> - golang-github-apparentlymart-go-textseg-v13
>+ required by (updated) golang-github-zclconf-go-cty
>+ upstream documents using the /v13 path in `go get`, go.mod, etc.
>+ golang-github-apparentlymart-go-textseg-dev has a few reverse
>  dependencies in main
>+ a few patches were needed to support Unicode 13 / Go 1.19, so
>  using a new -v13 package seems safer than trying to switch the
>  existing versionless package to a new upstream release; some
>  users of /v12 are actually shipping vendorized hashicorp/hcl,
>  so I'm not sure we could fix anything even if we wanted to…
>  (see nomad* and packer further down).

Dropped! Thanks to Shengjing Zhu's feedback, I'm sticking to the
unversioned golang-github-apparentlymart-go-textseg(-dev).

> - golang-github-hashicorp-hcl-v2
>+ required by golang-ariga-atlas
>+ golang-github-hashicorp-hcl-dev has 98 reverse dependencies in
>  main, so keeping the existing versionless package and introducing a
>  -v2 looks much safer!
>+ will likely be beneficial to others, since hashicorp/hcl is
>  currently stuck at 1.0.0, and hashicorp/hcl/v2 is vendorized by
>  other packages…

In NEW as well:

#1021723: ITP: golang-github-hashicorp-hcl-v2


> Updated packages:
> -
> 
> - golang-github-gin-gonic-gin
>+ required by crowdsec
>+ update from 1.6.3 to 1.8.1
>+ ratt is fine except:
>   - crowdsec:
>+ I'm working on its update, the old version doesn't count!
>   - golang-gitlab-gitlab-org-labkit:
>  + already RC-buggy: #1021583 (FTBFS)
>   - golang-nhooyr-websocket:
>  + package confusion, fixed in 1.8.7-3
>
> https://salsa.debian.org/go-team/packages/golang-nhooyr-websocket/-/commit/e00ff53
>   - nomad:
>+ already RC-buggy: #1000441 (FTBFS), #1021273 (many CVEs),
>#994214 (FTBFS)
>   - prometheus:
>  + already RC-buggy: #1020145 (FTBFS)

Final ratt check before uploading, only failures were:
 - golang-gitlab-gitlab-org-labkit: #1021583
 - nomad: multi-RC buggy.

Uploaded and accepted into unstable.

> - golang-github-zclconf-go-cty
>+ required by golang-github-hashicorp-hcl-v2
>+ update from 1.5.1 to 1.11.0
>+ ratt is fine except:
>   - nomad:
>  + already RC-buggy: #1000441, #1021273, #994214
>+ additionally, undocumented (build-)dep on
>  golang-github-apparentlymart-go-textseg, which is going to be
>  exposed by golang-github-zclconf-go-cty moving to the -v13
>package: #1021650
>   - nomad-driver-podman:
>  + RC-buggy, outdated
>+ additionally, undocumented (build-)dep on
>  golang-github-apparentlymart-go-textseg, via nomad and its
>golang-github-hashicorp-nomad-dev (#1021650): #1021652
>   - packer
>+ undocumented (build-)dep on
>  

Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

[Francois Le Hir]

I was able to fix the issue on my side.
The problem (for my situation) was a conflict between pulseaudio and pipewire 
as both were running on my system at the same time and pipewire-pulse.service 
was masked meaning the sound was not going through pipewire.

The way to test that (as a user not root):
systemctl --user restart pipewire-pulse.service
Failed to restart pipewire-pulse.service: Unit pipewire-pulse.service is masked.

I resolved the issue by uninstalling pulseaudio, rebooting and then doing a 
correct migration to pipewire as described in the debian wiki here: 
https://wiki.debian.org/PipeWire
I ended up with pipewire, pipewire-pulse, pipewire-alsa and pipewire-jack 
installed and pulseaudio not installed.

After that the sound is working fine. I am able to upgrade to wireplumber 
0.4.12-1 and everything works as it should.

Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...

[Phil Harvey]

The QuickTime ColorRepresentation is decoded into separate tags as of ExifTool 
12.45.

- Phil

> On Oct 13, 2022, at 1:52 PM, Paul Gevers  wrote:
> 
> Source: libimage-exiftool-perl, mat2
> Control: found -1 libimage-exiftool-perl/12.47+dfsg-1
> Control: found -1 mat2/0.13.0-1
> Severity: serious
> Tags: sid bookworm
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of libimage-exiftool-perl the autopkgtest of mat2 fails 
> in testing when that autopkgtest is run with the binary packages of 
> libimage-exiftool-perl from unstable. It passes when run with only packages 
> from testing. In tabular form:
> 
>   passfail
> libimage-exiftool-perl from testing12.47+dfsg-1
> mat2   from testing0.13.0-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of libimage-exiftool-perl 
> to testing [1]. Due to the nature of this issue, I filed this bug report 
> against both packages. Can you please investigate the situation and reassign 
> the bug to the right package?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=libimage-exiftool-perl
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/27021864/log.gz
> 
> ___ TestCleaning.test_all_parametred 
> ___
> 
> self = 
> 
>def test_all_parametred(self):
>for case in self.data:
>with self.subTest(case=case):
>if 'ffmpeg' in case:
>try:
>video._get_ffmpeg_path()
>except RuntimeError:
>raise unittest.SkipTest
>print('[+] Testing %s' % case['name'])
>target = './tests/data/clean.' + case['name']
>shutil.copy('./tests/data/dirty.' + case['name'], target)
>p1 = case['parser'](target)
>for k, v in p1.get_meta().items():
>if k not in case['meta']:
>continue
>if isinstance(v, dict):
>for _k, _v in v.items():
>if _k in case['meta'][k]:
>self.assertEqual(_v, case['meta'][k][_k])
>else:
>self.assertEqual(v, case['meta'][k])
>p1.lightweight_cleaning = True
>self.assertTrue(p1.remove_all())
>p2 = case['parser'](p1.output_filename)
>meta = p2.get_meta()
>if meta:
>for k, v in p2.get_meta().items():
>>  self.assertIn(k, case['expected_meta'], '"%s" is not in 
>> "%s" (%s)' % (k, case['expected_meta'], case['name']))
> E   AssertionError: 'ColorProfiles' not found in 
> {'AverageBitrate': 465641, 'BufferSize': 0, 'CompatibleBrands': ['isom', 
> 'iso2', 'avc1', 'mp41'], 'ColorRepresentation': 'nclx 1 1 1', 'CompressorID': 
> 'avc1', 'GraphicsMode': 'srcCopy', 'HandlerDescription': 'SoundHandler', 
> 'HandlerType': 'Metadata', 'HandlerVendorID': 'Apple', 'MajorBrand': 'Base 
> Media v1 [IS0 14496-12:2003]', 'MaxBitrate': 465641, 'MediaDataOffset': 48, 
> 'MediaDataSize': 379872, 'MediaHeaderVersion': 0, 'MinorVersion': '0.2.0', 
> 'MovieDataOffset': 48, 'MovieHeaderVersion': 0, 'NextTrackID': 3, 
> 'PreferredRate': 1, 'Rotation': 0, 'TimeScale': 1000, 'TrackHeaderVersion': 
> 0, 'TrackID': 1, 'TrackLayer': 0} : "ColorProfiles" is not in 
> "{'AverageBitrate': 465641, 'BufferSize': 0, 'CompatibleBrands': ['isom', 
> 'iso2', 'avc1', 'mp41'], 'ColorRepresentation': 'nclx 1 1 1', 'CompressorID': 
> 'avc1', 'GraphicsMode': 'srcCopy', 'HandlerDescription': 'SoundHandler', 
> 'HandlerType': 'Metadata', 'HandlerVendorID': 'Apple', 'MajorBrand': 'Base 
> Media v1 [IS0 14496-12:2003]', 'MaxBitrate': 465641, 'MediaDataOffset': 48, 
> 'MediaDataSize': 379872, 'MediaHeaderVersion': 0, 'MinorVersion': '0.2.0', 
> 'MovieDataOffset': 48, 'MovieHeaderVersion': 0, 'NextTrackID': 3, 
> 'PreferredRate': 1, 'Rotation': 0, 'TimeScale': 1000, 'TrackHeaderVersion': 
> 0, 'TrackID': 1, 'TrackLayer': 0}" (mp4)
> 
> tests/test_libmat2.py:552: AssertionError
> - Captured stdout call 
> -
> [+] Testing pdf
> [+] Testing png
> [+] Testing jpg
> [+] Testing wav
> [+] Testing aiff
> [+] Testing mp3
> [+] Testing ogg
> [+] Testing flac
> [+] Testing docx
> [+] Testing odt
> [+] Testing tiff
> [+] Testing bmp
> [+] Testing torrent
> [+] Testing odf
> [+] Testing odg
> [+] Testing txt
> [+] Testing gif
> [+] Testing css
> [+] Testing svg
> [+] Testing 

Bug#1020802: libz3-4: Xorg crashes on startup due to illegal instruction (SSE2) in libz3-4

[karogyoker999]

It seems to me that the libz3-4 package was compiled with SSE2 turned on.

$ objdump -d libz3.so.4 | grep pxor | wc -l
2896

$ objdump -d libz3.so.4 | grep movq | wc -l
26380

Bug#1021742: open-iscsi: Ingest upstream 2.1.8

[Eric Mackay]

Package: open-iscsi
Severity: wishlist

Please ingest open-iscsi upstream release 2.1.8. It adds support for
(among other things) running iscsid in initramfs more easily, which
could lead toward closing bug #982842. Hoping this could be included
in Bookworm and ideally Bullseye.


-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-18-amd64 (SMP w/16 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

Bug#1015860: libxalan2-java: CVE-2022-34169

[Markus Koschany]

Hi,

I just had a go at this issue and I discovered that libxalan2-java in Debian is
not affected but rather bcel.

https://tracker.debian.org/pkg/bcel

The fixing commit in OpenJDK addresses the same code which is nowhere to be
found in libxalan2-java but is present in bcel. The bcel upstream commit can be
found at

https://github.com/apache/commons-bcel/commit/f3267cbcc900f80851d561bdd16b239d936947f5


I suggest to reassign the bug to bcel. I agree that libxalan2-java should be
retired eventually. It is required by quite some reverse-dependencies though
and it may take some time to achieve that. In theory everything should work
without the library, because the code is in OpenJDK already?

I am not sure if we should request to clarify the CVE description or at least
post on oss-security to make other people aware of it. I assume the official
xalan2 release ships an internal copy of bcel and that might be the reason for
the confusion.

Regards,

Markus


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

Bug#1021741: ITP: golang-github-slack-go-slack -- access the Slack API in Go (library)

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-slack-go-slack
  Version : 0.11.3-1
  Upstream Author : Norberto Lopes
* URL : https://github.com/slack-go/slack
* License : BSD-2-clause
  Programming Lang: Go
  Description : access the Slack API in Go (library)

 This is the original Slack library for Go created by Norberto Lopes,
 transferred to a GitHub organization. This library supports most if
 not all of the api.slack.com REST calls, as well as the Real-Time
 Messaging protocol over websocket, in a fully managed way.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021394: src:libcereal: FTBFS on arm, ppc64le, s390x

[Andreas Tille]

Hi Scott,

Am Thu, Oct 13, 2022 at 01:49:17PM -0400 schrieb Scott Talbert:
> Merge request sent with patch:
> https://salsa.debian.org/med-team/libcereal/-/merge_requests/1

Thanks a lot, uploaded by sponsoring the package as you to reward you
for closing the bug.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1021740: openvswitch: CVE-2019-25076

[Moritz Mühlenhoff]

Source: openvswitch
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for openvswitch.

CVE-2019-25076[0]:
| The TSS (Tuple Space Search) algorithm in Open vSwitch 2.x through
| 2.17.2 and 3.0.0 allows remote attackers to cause a denial of service
| (delays of legitimate traffic) via crafted packet data that requires
| excessive evaluation time within the packet classification algorithm
| for the MegaFlow cache, aka a Tuple Space Explosion (TSE) attack.

https://arxiv.org/abs/2011.09107
https://sites.google.com/view/tuple-space-explosion
https://dl.acm.org/doi/10.1145/3359989.3365431
https://www.youtube.com/watch?v=5cHpzVK0D28
https://www.youtube.com/watch?v=DSC3m-Bww64

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-25076
https://www.cve.org/CVERecord?id=CVE-2019-25076

Please adjust the affected versions in the BTS as needed.

Bug#1021739: nekohtml: CVE-2022-24839

[Moritz Mühlenhoff]

Source: nekohtml
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for nekohtml.

CVE-2022-24839[0]:
| org.cyberneko.html is an html parser written in Java. The fork of
| `org.cyberneko.html` used by Nokogiri (Rubygem) raises a
| `java.lang.OutOfMemoryError` exception when parsing ill-formed HTML
| markup. Users are advised to upgrade to `= 1.9.22.noko2`. Note:
| The upstream library `org.cyberneko.html` is no longer maintained.
| Nokogiri uses its own fork of this library located at
| https://github.com/sparklemotion/nekohtml and this CVE applies only to
| that fork. Other forks of nekohtml may have a similar vulnerability.

https://github.com/sparklemotion/nekohtml/security/advisories/GHSA-9849-p7jc-9rmv
https://github.com/sparklemotion/nekohtml/commit/a800fce3b079def130ed42a408ff1d09f89e773d

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-24839
https://www.cve.org/CVERecord?id=CVE-2022-24839

Please adjust the affected versions in the BTS as needed.

Bug#1021738: man2html: CVE-2021-40647 CVE-2021-40648

[Moritz Mühlenhoff]

Source: man2html
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for man2html.

CVE-2021-40647[0]:
| In man2html 1.6g, a specific string being read in from a file will
| overwrite the size parameter in the top chunk of the heap. This at
| least causes the program to segmentation abort if the heap size
| parameter isn't aligned correctly. In version before GLIBC version
| 2.29 and aligned correctly, it allows arbitrary write anywhere in the
| programs memory.

CVE-2021-40648[1]:
| In man2html 1.6g, a filename can be created to overwrite the previous
| size parameter of the next chunk and the fd, bk, fd_nextsize,
| bk_nextsize of the current chunk. The next chunk is then freed later
| on, causing a freeing of an arbitrary amount of memory.

https://gist.github.com/untaman/cb58123fe89fc65e3984165db5d40933

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-40647
https://www.cve.org/CVERecord?id=CVE-2021-40647
[1] https://security-tracker.debian.org/tracker/CVE-2021-40648
https://www.cve.org/CVERecord?id=CVE-2021-40648

Please adjust the affected versions in the BTS as needed.

Bug#1021737: lava: CVE-2022-42902

[Moritz Mühlenhoff]

Source: lava
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for lava.

CVE-2022-42902[0]:
| In Linaro Automated Validation Architecture (LAVA) before 2022.10,
| there is dynamic code execution in lava_server/lavatable.py. Due to
| improper input sanitization, an anonymous user can force the lava-
| server-gunicorn service to execute user-provided code on the server.

https://git.lavasoftware.org/lava/lava/-/merge_requests/1834
https://git.lavasoftware.org/lava/lava/-/commit/e66b74cd6c175ff8826b8f3431740963be228b52?merge_request_iid=1834

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-42902
https://www.cve.org/CVERecord?id=CVE-2022-42902

Please adjust the affected versions in the BTS as needed.

Bug#1003002: some more information

[Emanuele Rocca]

On Thu, Oct 13, 2022 at 05:16:44PM +0200, Emanuele Rocca wrote:
> Based on this observation from Maximilian I've tried the following, which 
> seems
> to address the issue on arm64.

Not reliably though. The first few times I tried it worked, but now even with
hvc2 I could reproduce setup_console's failure.

Bug#1021576: linphone documentation

[ael]

On Thu, Oct 13, 2022 at 06:13:34PM +0200, Dennis Filder wrote:
> 
> Well, there's your answer right there: Your
> ~/.config/linphone/linphonerc still contains a lime= entry in the
> [sip] section from earlier releases.  Somehow it must have been set to

Just a further comment which may also be upstream:

linphone seems to lack any documentation on linphonerc and so on.

$ apropos linphone
gives no results, which is where I would expect to find this sort of
thing.

And /usr/share/doc/linphone-desktop doesn't seem to have anything relevant.

I am not sure about the interaction between the GUI "Preferences"
settings and linphonrc. I don't see anything about lime there.

Maybe I need to read the source to discover this sort of thing?

ael

Bug#1021576: can't have both LIME and LIME X3DH enabled at the same time

[ael]

On Thu, Oct 13, 2022 at 06:13:34PM +0200, Dennis Filder wrote:
> X-Debbugs-Cc: ael 
> 
> On Thu, Oct 13, 2022 at 12:42:52PM +0100, ael wrote:
> > Another gdb log after installing liblinphone*10-dbgsym*.
> >
> > one line that may be relevant is
> >
> > #5  0x77b37798 in bctbx_fatal(char const*, ...)
> > (fmt=fmt@entry=0x77bc1670 "You can't have both LIME and LIME X3DH 
> > enabled at the same time !\nConflicting settings are [sip] lime and [lime] 
> > lime_server_url")
> > at /usr/include/bctoolbox/logging.h:245
> >
> > This is another quick and dirty interim report for now...
> 
> Well, there's your answer right there: Your
> ~/.config/linphone/linphonerc still contains a lime= entry in the
> [sip] section from earlier releases.  Somehow it must have been set to
> 1 which conflicts with the newer LIME X3DH support that has its own
> section.  Just delete that line from the [sip] section and you should
> be good to go.  It is unfortunate that the error message is only
> written to the log, not to stderr where it would be helpful.

I don't remember editing linphonerc: it must have been many months
if not years ago.

 
> I just wonder why it didn't manifest before (assuming you didn't make
> any changes to your configuration recently).  Have you used the
> AppImage version recently?  If so it may have touched your
> configuration.

Definitely not (AppImage), and I made no recent changes to the
configuration. Perhaps a while ago I may have modified via the GUI:
I don't remember. But I use linphone regularly, and it had been working
fine until a few day ago.

But thanks so much for the diagnosis. I confirm that it seems to work
after deleting the lime=1 entry.

It does seem to leave some error handling attention if it dumps core
on a simple configuration error. I guess that is for upstream.

Thanks again,

ael

PS. I assume you will close the bug report, or should I do so?



> 
> Regards.

Bug#1020446: popt uploaded to unstable

[Håvard F . Aasen]

Control: severity -1 serious


Dear maintainer,

popt version 1.19+dfsg-1 has now been uploaded to unstable. I'm raising
the severity since gdisk now blocks popt's migration to testing.


Regards,
Håvard

Bug#1021735: libffi breaks python3.10 autopkgtest on arm64 (and 5 other packages)

[Paul Gevers]

Source: libffi
Control: found -1 libffi/3.4.3-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks

Dear maintainer(s),

With a recent upload of libffi the autopkgtest of python3.10 fails in 
testing when that autopkgtest is run with the binary packages of libffi 
from unstable on arm64. 5 other packages also fail their test on arm64. 
It passes when run with only packages from testing. In tabular form:


   passfail
libffi from testing3.4.3-2
python3.10 from testing3.10.7-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of libffi to testing 
[1]. Can you please investigate the situation?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libffi

https://ci.debian.net/data/autopkgtest/testing/arm64/p/python3.10/27000260/log.gz

== Tests result: FAILURE ==

397 tests OK.

1 test failed:
test_ctypes

20 tests skipped:
test_asdl_parser test_check_c_globals test_clinic test_devpoll
test_gdb test_ioctl test_kqueue test_msilib test_smtpnet
test_socketserver test_startfile test_tix test_tk test_urllib2net
test_urllibnet test_winconsoleio test_winreg test_winsound
test_xmlrpc_net test_zipfile64
0:17:53 load avg: 1.44
0:17:53 load avg: 1.44 Re-running failed tests in verbose mode
0:17:53 load avg: 1.44 Re-running test_ctypes in verbose mode (matching: 
test_struct_return_8H, test_struct_return_8H, test_struct_return_8H, 
test_callback_large_struct, test_struct_return_8H, test_struct_by_value)
test_struct_return_8H 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ... FAIL
test_struct_return_8H 
(ctypes.test.test_as_parameter.AsParamWrapperTestCase) ... FAIL
test_struct_return_8H (ctypes.test.test_as_parameter.BasicWrapTestCase) 
... FAIL
test_callback_large_struct 
(ctypes.test.test_callbacks.SampleCallbacksTestCase) ... FAIL

test_struct_return_8H (ctypes.test.test_functions.FunctionTestCase) ... FAIL
test_struct_by_value (ctypes.test.test_win32.Structures) ... FAIL

==
FAIL: test_struct_return_8H 
(ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase)

--
Traceback (most recent call last):
  File "/usr/lib/python3.10/ctypes/test/test_as_parameter.py", line 
190, in test_struct_return_8H
self.assertEqual((s8i.a, s8i.b, s8i.c, s8i.d, s8i.e, s8i.f, s8i.g, 
s8i.h),
AssertionError: Tuples differ: (849208960, 196605, 4, 0, -1675480192, 
458745, 8, 0) != (18, 24, 28, 30, 30, 28, 24, 18)


First differing element 0:
849208960
18

- (849208960, 196605, 4, 0, -1675480192, 458745, 8, 0)
+ (18, 24, 28, 30, 30, 28, 24, 18)

==
FAIL: test_struct_return_8H 
(ctypes.test.test_as_parameter.AsParamWrapperTestCase)

--
Traceback (most recent call last):
  File "/usr/lib/python3.10/ctypes/test/test_as_parameter.py", line 
190, in test_struct_return_8H
self.assertEqual((s8i.a, s8i.b, s8i.c, s8i.d, s8i.e, s8i.f, s8i.g, 
s8i.h),
AssertionError: Tuples differ: (849208960, 196605, 4, 0, -1806091264, 
458745, 8, 0) != (18, 24, 28, 30, 30, 28, 24, 18)


First differing element 0:
849208960
18

- (849208960, 196605, 4, 0, -1806091264, 458745, 8, 0)
+ (18, 24, 28, 30, 30, 28, 24, 18)

==
FAIL: test_struct_return_8H 
(ctypes.test.test_as_parameter.BasicWrapTestCase)

--
Traceback (most recent call last):
  File "/usr/lib/python3.10/ctypes/test/test_as_parameter.py", line 
190, in test_struct_return_8H
self.assertEqual((s8i.a, s8i.b, s8i.c, s8i.d, s8i.e, s8i.f, s8i.g, 
s8i.h),
AssertionError: Tuples differ: (849208960, 196605, 4, 0, -1806094720, 
458745, 8, 0) != (18, 24, 28, 30, 30, 28, 24, 18)


First differing element 0:
849208960
18

- (849208960, 196605, 4, 0, -1806094720, 458745, 8, 0)
+ (18, 24, 28, 30, 30, 28, 24, 18)

==
FAIL: test_callback_large_struct 
(ctypes.test.test_callbacks.SampleCallbacksTestCase)

--
Traceback (most recent call last):
  File "/usr/lib/python3.10/ctypes/test/test_callbacks.py", line 280, 
in test_callback_large_struct

self.assertEqual(check.first, s.first)
AssertionError: 281473275965456 != 3735928559

==
FAIL: test_struct_return_8H (ctypes.test.test_functions.FunctionTestCase)

Bug#1021736: rake-compiler: autopkgtest regression: cannot load such file -- rspec/core/rake_task

[Paul Gevers]

Source: rake-compiler
Version: 1.2.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of rake-compiler the autopkgtest of rake-compiler 
fails in testing when that autopkgtest is run with the binary packages 
of rake-compiler from unstable. It passes when run with only packages 
from testing. In tabular form:


   passfail
rake-compiler  from testing1.2.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rake-compiler

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rake-compiler/27031948/log.gz


┌──┐
│ Run tests for ruby3.0 from debian/ruby-tests.rake 
  │

└──┘

RUBYLIB=. GEM_PATH= ruby3.0 -S rake -f debian/ruby-tests.rake
mv lib ./.gem2deb.lib
rake aborted!
LoadError: cannot load such file -- rspec/core/rake_task
:85:in 
`require'
:85:in 
`require'
:85:in 
`require'
:85:in 
`require'
/tmp/autopkgtest-lxc.0998j3a0/downtmp/build.P4x/src/debian/ruby-tests.rake:1:in 
`'
/usr/share/rubygems-integration/all/gems/rake-13.0.6/exe/rake:27:in 
`'

(See full trace by running task with --trace)
mv ./.gem2deb.lib lib
autopkgtest [15:16:58]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020576: please update sage for pari 2.15.0 and gap 4.12.0

[Paul Gevers]

Control: severity -1 serious

Hi,

On Fri, 23 Sep 2022 15:55:41 +0200 Bill Allombert  
wrote:

Please update sagemath so that it can work with both PARI 2.15.0 (in unstable)
and GAP 4.12.0 (in experimental).

I am not saying it is easy :)


The autopkgtest of sagemath is failing with the new pari, blocking its 
migration.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021734: prometheus-alertmanager: autopkgtest regression: address already in use

[Paul Gevers]

Source: prometheus-alertmanager
Version: 0.24.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of prometheus-alertmanager the autopkgtest of 
prometheus-alertmanager fails in testing when that autopkgtest is run 
with the binary packages of prometheus-alertmanager from unstable. It 
passes when run with only packages from testing. In tabular form:


   passfail
prometheus-alertmanager from testing0.24.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can 
you please investigate the situation and fix it?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=prometheus-alertmanager

https://ci.debian.net/data/autopkgtest/testing/amd64/p/prometheus-alertmanager/27020991/log.gz

=== RUN   TestAddAlerts
--- PASS: TestAddAlerts (0.00s)
=== RUN   TestListAlerts
--- PASS: TestListAlerts (0.00s)
=== RUN   TestAlertFiltering
--- PASS: TestAlertFiltering (0.00s)
=== RUN   TestSilenceFiltering
--- PASS: TestSilenceFiltering (0.00s)
=== RUN   TestReceiversMatchFilter
--- PASS: TestReceiversMatchFilter (0.00s)
=== RUN   TestMatchFilterLabels
--- PASS: TestMatchFilterLabels (0.00s)
PASS
ok  github.com/prometheus/alertmanager/api/v1   0.011s
=== RUN   TestGetStatusHandlerWithNilPeer
--- PASS: TestGetStatusHandlerWithNilPeer (0.00s)
=== RUN   TestGetSilencesHandler
--- PASS: TestGetSilencesHandler (0.00s)
=== RUN   TestDeleteSilenceHandler
--- PASS: TestDeleteSilenceHandler (0.00s)
=== RUN   TestPostSilencesHandler
--- PASS: TestPostSilencesHandler (0.00s)
=== RUN   TestCheckSilenceMatchesFilterLabels
--- PASS: TestCheckSilenceMatchesFilterLabels (0.00s)
=== RUN   TestAlertToOpenAPIAlert
--- PASS: TestAlertToOpenAPIAlert (0.00s)
=== RUN   TestMatchFilterLabels
--- PASS: TestMatchFilterLabels (0.00s)
PASS
ok  github.com/prometheus/alertmanager/api/v2   0.013s
?   github.com/prometheus/alertmanager/api/v2/client[no test files]
?   github.com/prometheus/alertmanager/api/v2/client/alert  [no test files]
?   	github.com/prometheus/alertmanager/api/v2/client/alertgroup	[no 
test files]
?   	github.com/prometheus/alertmanager/api/v2/client/general	[no test 
files]
?   	github.com/prometheus/alertmanager/api/v2/client/receiver	[no test 
files]
?   	github.com/prometheus/alertmanager/api/v2/client/silence	[no test 
files]

?   github.com/prometheus/alertmanager/api/v2/models[no test files]
?   github.com/prometheus/alertmanager/api/v2/restapi   [no test files]
?   	github.com/prometheus/alertmanager/api/v2/restapi/operations	[no 
test files]
?   	github.com/prometheus/alertmanager/api/v2/restapi/operations/alert 
[no test files]
? 
github.com/prometheus/alertmanager/api/v2/restapi/operations/alertgroup 
[no test files]
? 
github.com/prometheus/alertmanager/api/v2/restapi/operations/general	[no 
test files]
? 
github.com/prometheus/alertmanager/api/v2/restapi/operations/receiver 
[no test files]
? 
github.com/prometheus/alertmanager/api/v2/restapi/operations/silence	[no 
test files]

=== RUN   TestCheckConfig
Checking 'testdata/conf.good.yml'  SUCCESS
Found:
 - global config
 - route
 - 0 inhibit rules
 - 1 receivers
 - 1 templates
  SUCCESS

Checking 'testdata/conf.bad.yml'  FAILED: yaml: unmarshal errors:
  line 1: cannot unmarshal !!str `BAD` into config.plain

--- PASS: TestCheckConfig (0.00s)
=== RUN   TestRoutingTest
  OK
  OK
  OK
  OK
--- PASS: TestRoutingTest (0.00s)
PASS
ok  github.com/prometheus/alertmanager/cli  0.011s
=== RUN   TestNewConfigResolver
--- PASS: TestNewConfigResolver (0.00s)
=== RUN   TestConfigResolverBind
--- PASS: TestConfigResolverBind (0.00s)
=== RUN   TestInvalidHTTPConfig
--- PASS: TestInvalidHTTPConfig (0.00s)
=== RUN   TestValidHTTPConfig
--- PASS: TestValidHTTPConfig (0.00s)
=== RUN   TestValidBasicAuthHTTPConfig
--- PASS: TestValidBasicAuthHTTPConfig (0.00s)
PASS
ok  github.com/prometheus/alertmanager/cli/config   0.006s
?   github.com/prometheus/alertmanager/cli/format   [no test files]
=== RUN   TestCalculateAdvertiseAddress
=== RUN   TestCalculateAdvertiseAddress/use_provided_bind_address
=== RUN   TestCalculateAdvertiseAddress/use_provided_advertise_address
=== RUN   TestCalculateAdvertiseAddress/discover_private_ip_address
=== RUN   TestCalculateAdvertiseAddress/error_if_getPrivateAddress_errors
=== RUN 
TestCalculateAdvertiseAddress/error_if_getPrivateAddress_returns_an_invalid_address
=== RUN 
TestCalculateAdvertiseAddress/error_if_getPrivateAddress_returns_an_empty_address

=== RUN   TestCalculateAdvertiseAddress/discover_public_advertise_address
=== RUN   TestCalculateAdvertiseAddress/error_if_getPublicAddress_errors
=== RUN 

Bug#1021733: src:sbcl: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: sbcl
Version: 2:2.2.3-2
Severity: serious
Control: close -1 2:2.2.9-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1016750

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:sbcl has been trying to migrate for 80 
days [2]. Hence, I am filing this bug. I reported bug #1016750 about the 
autopkgtest regression.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=sbcl



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...

[Paul Gevers]

Source: libimage-exiftool-perl, mat2
Control: found -1 libimage-exiftool-perl/12.47+dfsg-1
Control: found -1 mat2/0.13.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libimage-exiftool-perl the autopkgtest of mat2 
fails in testing when that autopkgtest is run with the binary packages 
of libimage-exiftool-perl from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
libimage-exiftool-perl from testing12.47+dfsg-1
mat2   from testing0.13.0-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of 
libimage-exiftool-perl to testing [1]. Due to the nature of this issue, 
I filed this bug report against both packages. Can you please 
investigate the situation and reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libimage-exiftool-perl

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mat2/27021864/log.gz

___ TestCleaning.test_all_parametred 
___


self = 

def test_all_parametred(self):
for case in self.data:
with self.subTest(case=case):
if 'ffmpeg' in case:
try:
video._get_ffmpeg_path()
except RuntimeError:
raise unittest.SkipTest
print('[+] Testing %s' % case['name'])
target = './tests/data/clean.' + case['name']
shutil.copy('./tests/data/dirty.' + case['name'], target)
p1 = case['parser'](target)
for k, v in p1.get_meta().items():
if k not in case['meta']:
continue
if isinstance(v, dict):
for _k, _v in v.items():
if _k in case['meta'][k]:
self.assertEqual(_v, case['meta'][k][_k])
else:
self.assertEqual(v, case['meta'][k])
p1.lightweight_cleaning = True
self.assertTrue(p1.remove_all())
p2 = case['parser'](p1.output_filename)
meta = p2.get_meta()
if meta:
for k, v in p2.get_meta().items():

  self.assertIn(k, case['expected_meta'], '"%s" is not in 
"%s" (%s)' % (k, case['expected_meta'], case['name']))
E   AssertionError: 'ColorProfiles' not found in 
{'AverageBitrate': 465641, 'BufferSize': 0, 'CompatibleBrands': ['isom', 
'iso2', 'avc1', 'mp41'], 'ColorRepresentation': 'nclx 1 1 1', 
'CompressorID': 'avc1', 'GraphicsMode': 'srcCopy', 'HandlerDescription': 
'SoundHandler', 'HandlerType': 'Metadata', 'HandlerVendorID': 'Apple', 
'MajorBrand': 'Base Media v1 [IS0 14496-12:2003]', 'MaxBitrate': 465641, 
'MediaDataOffset': 48, 'MediaDataSize': 379872, 'MediaHeaderVersion': 0, 
'MinorVersion': '0.2.0', 'MovieDataOffset': 48, 'MovieHeaderVersion': 0, 
'NextTrackID': 3, 'PreferredRate': 1, 'Rotation': 0, 'TimeScale': 1000, 
'TrackHeaderVersion': 0, 'TrackID': 1, 'TrackLayer': 0} : 
"ColorProfiles" is not in "{'AverageBitrate': 465641, 'BufferSize': 0, 
'CompatibleBrands': ['isom', 'iso2', 'avc1', 'mp41'], 
'ColorRepresentation': 'nclx 1 1 1', 'CompressorID': 'avc1', 
'GraphicsMode': 'srcCopy', 'HandlerDescription': 'SoundHandler', 
'HandlerType': 'Metadata', 'HandlerVendorID': 'Apple', 'MajorBrand': 
'Base Media v1 [IS0 14496-12:2003]', 'MaxBitrate': 465641, 
'MediaDataOffset': 48, 'MediaDataSize': 379872, 'MediaHeaderVersion': 0, 
'MinorVersion': '0.2.0', 'MovieDataOffset': 48, 'MovieHeaderVersion': 0, 
'NextTrackID': 3, 'PreferredRate': 1, 'Rotation': 0, 'TimeScale': 1000, 
'TrackHeaderVersion': 0, 'TrackID': 1, 'TrackLayer': 0}" (mp4)


tests/test_libmat2.py:552: AssertionError
- Captured stdout call 
-

[+] Testing pdf
[+] Testing png
[+] Testing jpg
[+] Testing wav
[+] Testing aiff
[+] Testing mp3
[+] Testing ogg
[+] Testing flac
[+] Testing docx
[+] Testing odt
[+] Testing tiff
[+] Testing bmp
[+] Testing torrent
[+] Testing odf
[+] Testing odg
[+] Testing txt
[+] Testing gif
[+] Testing css
[+] Testing svg
[+] Testing ppm
[+] Testing avi
[+] Testing mp4
- Captured stderr call 
-

Warning: [minor] Can't delete IFD0 from TIFF - ./tests/data/clean.tiff
=== warnings summary 
===

libmat2/pdf.py:11

Bug#1021394: src:libcereal: FTBFS on arm, ppc64le, s390x

[Scott Talbert]

Control: tags -1 patch

On Fri, 7 Oct 2022, Scott Talbert wrote:


Control: tags -1 help
Control: tags -1 upstream
Control: tags -1 forwarded https://github.com/USCiLab/cereal/issues/744


Merge request sent with patch:
https://salsa.debian.org/med-team/libcereal/-/merge_requests/1

Regards,
Scott

Bug#1021731: ITP: a-el -- functions for dealing with associative structures

[Lev Lamberov]

Package: wnpp
Owner: Lev Lamberov 
Severity: wishlist

* Package name: a-el
  Version : 1.0.0
  Upstream Author : Arne Brasseur 
* URL or Web page : https://github.com/plexus/a.el
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : functions for dealing with associative structures

Library for dealing with associative data structures: alists, hash-maps,
and vectors (for vectors, the indices are treated as keys).

This library is largely inspired by Clojure, it has many of the
functions found in clojure.core, prefixed with `a-'. All functions treat
their arguments as immutable, so e.g. `a-assoc' will clone the
hash-table or alist it is given. Keep this in mind when writing
performance sensitive code.

This is a new dependency of pcre2el, needed to fix RC bug. The package
will be maintained under Debian Emacsen team umbrella.

Bug#1021708: RFS: popt/1.19+dfsg-1 -- lib for parsing cmdline parameters

[Bastian Germann]

Am 13.10.22 um 19:07 schrieb Bastian Germann:

On Thu, 13 Oct 2022 11:09:56 +  wrote:

Changes since the last upload:

 popt (1.19+dfsg-1) unstable; urgency=medium
 .
   * Move from experimental to unstable.
   * Add fix-reporting-of-test-failures.patch


Have you asked the release team for a transition?


Forget it; there is no ABI change. I will sponsor later.

Bug#1021708: RFS: popt/1.19+dfsg-1 -- lib for parsing cmdline parameters

[Bastian Germann]

On Thu, 13 Oct 2022 11:09:56 +  wrote:

Changes since the last upload:

 popt (1.19+dfsg-1) unstable; urgency=medium
 .
   * Move from experimental to unstable.
   * Add fix-reporting-of-test-failures.patch


Have you asked the release team for a transition?

Bug#1021730: reprepro: support for suite pattern *- in updates (patch)

[Stefan Kisdaroczi]

Package: reprepro
Version: 5.3.0-1.2
Severity: wishlist
Tags: patch

Hi,

the attached patch allows suite pattern *- for conf/updates in addition to */.
Needed for bullseye security, -backports and -updates in the main archive.

Regards,
Stefan

Examples:

Name: security-buster
Method: http://security.debian.org/debian-security
Suite: */updates

Name: security
Method: http://security.debian.org/debian-security
Suite: *-updates

Name: backports
Method: http://ftp.debian.org/debian
Suite: *-backports

Name: updates
Method: http://ftp.debian.org/debian
Suite: *-updates
diff -uNrp reprepro-5.3.0.orig/docs/reprepro.1 reprepro-5.3.0/docs/reprepro.1
--- reprepro-5.3.0.orig/docs/reprepro.1	2018-09-09 07:17:15.0 +0200
+++ reprepro-5.3.0/docs/reprepro.1	2022-10-13 17:04:32.150363395 +0200
@@ -1678,7 +1678,7 @@ if both get their \fBMethod\fP informati
 .B Suite
 The suite to update from. If this is not present, the codename
 of the distribution using this one is used. Also "*/whatever"
-is replaced by "/whatever"
+is replaced by "/whatever", "*-whatever" is replaced by "-whatever"
 .TP
 .B Components
 The components to update. Each item can be either the name
diff -uNrp reprepro-5.3.0.orig/updates.c reprepro-5.3.0/updates.c
--- reprepro-5.3.0.orig/updates.c	2019-02-02 12:14:59.0 +0100
+++ reprepro-5.3.0/updates.c	2022-10-13 17:15:28.735408139 +0200
@@ -593,6 +593,7 @@ CFfinishparse(update_pattern) {
 		}
 		if (n->suite_from != NULL && strcmp(n->suite_from, "*") != 0 &&
 strncmp(n->suite_from, "*/", 2) != 0 &&
+strncmp(n->suite_from, "*-", 2) != 0 &&
 strchr(n->suite_from, '*') != NULL) {
 			fprintf(stderr,
 "%s:%u to %u: Unsupported suite pattern '%s'\n",
@@ -755,8 +756,8 @@ static inline char *translate_suite_patt
 
 	if (p == NULL || strcmp(p->suite_from, "*") == 0)
 		return strdup(codename);
-	if (p->suite_from[0] == '*' && p->suite_from[1] == '/')
-		return calc_dirconcat(codename, p->suite_from + 2);
+	if (p->suite_from[0] == '*' && (p->suite_from[1] == '/' || p->suite_from[1] == '-'))
+		return mprintf("%s%s", codename, p->suite_from + 1);
 	else if (strchr(p->suite_from, '*') == NULL)
 		return strdup(p->suite_from);
 	//TODO: implement this

Bug#1017411: dracut: 90kernel-modules spends 150ms doing a 3ms grep in bash

[наб]

Control: forwarded -1 https://github.com/dracutdevs/dracut/pull/2002

On Thu, Oct 13, 2022 at 05:50:48PM +0200, Thomas Lange wrote:
> > which, after shedding the bashisms and the meaningless IFS=:, is just
> > -- >8 --
> > grep ^/ "$srcmods/modules.dep" 2> /dev/null | instmods
> > -- >8 --
> I guess the dracut upstream developers do not want to have grep inside
> the initrd if not strictly needed. Only a few dracut modules install
> grep into the initrd.

You guess wrong ‒ that part's run on the host system, not in the initrd.

наб


signature.asc
Description: PGP signature

Bug#1021576: can't have both LIME and LIME X3DH enabled at the same time

[Dennis Filder]

X-Debbugs-Cc: ael 

On Thu, Oct 13, 2022 at 12:42:52PM +0100, ael wrote:
> Another gdb log after installing liblinphone*10-dbgsym*.
>
> one line that may be relevant is
>
> #5  0x77b37798 in bctbx_fatal(char const*, ...)
> (fmt=fmt@entry=0x77bc1670 "You can't have both LIME and LIME X3DH 
> enabled at the same time !\nConflicting settings are [sip] lime and [lime] 
> lime_server_url")
> at /usr/include/bctoolbox/logging.h:245
>
> This is another quick and dirty interim report for now...

Well, there's your answer right there: Your
~/.config/linphone/linphonerc still contains a lime= entry in the
[sip] section from earlier releases.  Somehow it must have been set to
1 which conflicts with the newer LIME X3DH support that has its own
section.  Just delete that line from the [sip] section and you should
be good to go.  It is unfortunate that the error message is only
written to the log, not to stderr where it would be helpful.

I just wonder why it didn't manifest before (assuming you didn't make
any changes to your configuration recently).  Have you used the
AppImage version recently?  If so it may have touched your
configuration.

Regards.

Bug#1021676: r-cran-leidenbase: autopkgtest failure on several architectures

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/cole-trapnell-lab/leidenbase/issues/36

Hi Adrian,

thanks a lot for this bug report

Am Wed, Oct 12, 2022 at 09:59:05PM +0300 schrieb Adrian Bunk:
> Source: r-cran-leidenbase
> Version: 0.1.12-1
> Severity: serious
> Control: block 1019706 by -1
> 
> https://ci.debian.net/data/autopkgtest/testing/arm64/r/r-cran-leidenbase/26869942/log.gz

I was stumbling upon this yesterday as well and have reported it
upstream[1] (even before this bug was filed ;-) - I should have opened
an according bug, sorry for missing this).

Please note that the issue is even worse on i386 (the other failing
architectures are all affected by the same problem).  I hope upstream
will find a quick solution for what looks like a rounding error issue at
first sight but may be it has a deeper cause.

Kind regards

  Andreas.

[1] https://github.com/cole-trapnell-lab/leidenbase/issues/36

-- 
http://fam-tille.de

Bug#1018754: telegram-cli: Outdated app that is no longer supported

[Bastian Germann]

Control: severity -1 grave

Setting appropriate severity. The application is not usable.

Bug#1017411: dracut: 90kernel-modules spends 150ms doing a 3ms grep in bash

[Thomas Lange]

> which, after shedding the bashisms and the meaningless IFS=:, is just
> -- >8 --
> grep ^/ "$srcmods/modules.dep" 2> /dev/null | instmods
> -- >8 --
I guess the dracut upstream developers do not want to have grep inside
the initrd if not strictly needed. Only a few dracut modules install
grep into the initrd.
-- 
regards Thomas

Bug#747096: openssh-client: key negotiation hangs for mtu 1500 and default Ciphers options

[Michal Seidl]

Package: openssh-client
Version: 1:8.4p1-5+deb11u1
Followup-For: Bug #747096
X-Debbugs-Cc: michal.se...@seznam.cz

Dear Maintainer,

* What led up to the situation?
Some network changes not under my control

* What exactly did you do (or not do) that was effective (or
 ineffective)?
Standard connetion command ssh @

* What was the outcome of this action?
Hangs on key negotiation
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

* What outcome did you expect instead?
To be aske for password as ussually

I tested this situation in problematic network from this computers:
1) Fresh Debian 11 install I am reporting bug from
2) My other Ubuntu 20.04 notebook and Ubuntu 20.04 server have the same problem
3) Windows 10 putty, Rocky Linux 9 work without problem

MS

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/1 CPU thread)
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 openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.20.11
ii  libc6 2.31-13+deb11u3
ii  libedit2  3.1-20191231-2+b1
ii  libfido2-11.6.0-2
ii  libgssapi-krb5-2  1.18.3-6+deb11u1
ii  libselinux1   3.1-3
ii  libssl1.1 1.1.1n-0+deb11u3
ii  passwd1:4.8.1-1
ii  zlib1g1:1.2.11.dfsg-2+deb11u1

Versions of packages openssh-client recommends:
ii  xauth  1:1.1-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- no debconf information

Bug#997296: r-cran-rpf: FTBFS on hppa with gcc-11

[Nilesh Patra]

fixed 997296 1.0.11+dfsg-1
close 997296
stop

This builds on hppa now with gcc-11 so closing.

https://buildd.debian.org/status/logs.php?pkg=r-cran-rpf=hppa

https://buildd.debian.org/status/fetch.php?pkg=r-cran-rpf=hppa=1.0.11%2Bdfsg-1=1635367343=0

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1020046: slimit: FTBFS: ModuleNotFoundError: No module named 'minifier'

[Bastian Germann]

This needs to be converted to a relative import.
Upstream did this in commit 
https://github.com/rspivak/slimit/commit/40956e7fc6e954b3e6d7b629faeb3303f5efb7ea

Bug#988389: logcheck-database: systemd ignore patterns miss some cases

[Stefan Kangas]

Dear maintainer,

Here are some sample messages that are currently not matched (from my
up-to-date Debian testing/bookworm system):

Oct 13 07:09:17 joffe systemd[1]:
var-cache-pbuilder-build-cow.1023683-dev-ptmx.mount: Deactivated
successfully.
Oct 13 08:59:17 joffe systemd[1]: session-832.scope: Deactivated successfully.
Oct 10 14:42:45 joffe systemd[1]: lvm2-lvmpolld.socket: Deactivated
successfully.
Oct 10 14:42:42 joffe systemd[1]: dm-event.socket: Deactivated successfully.

Oct 13 04:39:21 joffe systemd[1]: Finished Clean php session files.
Oct 13 05:27:20 joffe systemd[1]: Finished Hourly check for daily
apt-listbugs preferences cleanup.
Oct  9 00:13:29 joffe systemd[1]: Finished Autocommit of changes in
/etc directory.

Oct 11 12:51:50 joffe systemd[1]: Started pbuilder_create.
Oct 13 08:56:59 joffe systemd[1]: Started Session 832 of User skangas.
Oct 12 20:30:41 joffe systemd[1]: Started Session 755 of User skangas.
Oct 12 11:25:42 joffe systemd[1]: Started Hostname Service.

Oct 13 12:25:38 joffe systemd[1]: Starting Hourly check for daily
apt-listbugs preferences cleanup...

Oct  9 05:28:58 joffe systemd[1]: plocate-updatedb.service: Consumed
22.180s CPU time.
Oct 11 12:51:59 joffe systemd[1]:
run-rd4b1b97c71c04b88a153cbf5e084f9d3.scope: Consumed 1.054s CPU time.
Oct 11 12:52:18 joffe systemd[1]: system-pbuilder-create-650297.slice:
Consumed 2.065s CPU time.

Note also that this rule is no longer necessary:

^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]:
[-_[:alnum:]]+\.service: Succeeded\.$

The messages have been replaced with "Deactivated successfully" (as above).

Please see the attached patch.
From 8e12d82265f187966a1a708155fcca68ac1ebc49 Mon Sep 17 00:00:00 2001
From: Stefan Kangas 
Date: Thu, 13 Oct 2022 17:14:38 +0200
Subject: [PATCH] Adjust systemd rules for recent systemd

---
 rulefiles/linux/ignore.d.server/systemd | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/rulefiles/linux/ignore.d.server/systemd b/rulefiles/linux/ignore.d.server/systemd
index feedac5..f630b9f 100644
--- a/rulefiles/linux/ignore.d.server/systemd
+++ b/rulefiles/linux/ignore.d.server/systemd
@@ -1,9 +1,10 @@
-^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: (Started|Reached|Stopped) target [ +[:alnum:]]+\.$
-^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: (Starting|Stopping) [ +[:alnum:]/]+\.(\.\.)?$
+^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: (Started|Reached|Stopped) [ +_[:alnum:]]+\.$
+^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: (Starting|Stopping) [- +[:alnum:]/]+\.(\.\.)?$
 ^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: (Start|Stopp)ed [ +[:alnum:]/]+\.$
-^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: Reloading\.$
+^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: (Reloading|Reexecuting)\.$
 ^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: Time has been changed$
 ^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: [-_[:alnum:]]+.timer: Adding ([0-9]+h )?([0-9]{1,2}min )?[0-9]{1,3}\.[0-9]{3,6}m?s random time\.$
-^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: [-_[:alnum:]]+\.service: Succeeded\.$
+^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: [-_.[:alnum:]]+\.(service|mount|scope|socket): Deactivated successfully\.$
 ^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: session-[[:alnum:]]+\.scope: Succeeded\.$
-^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: Finished (Rotate log files|Daily apt (download|upgrade and clean) activities|Daily man-db regeneration)\.$
+^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: Finished [-[:alnum:] /]+\.$
+^[[:alpha:]]{3} [ :[:digit:]]{11} [._[:alnum:]\-]+ systemd\[[0-9]+\]: [-_.[:alnum:]]+\.(service|mount|scope|socket|slice): Consumed ([[:digit:].]+min )?[[:digit:].]+s CPU time\.$
-- 
2.35.1

Bug#1003002: some more information

[Emanuele Rocca]

On 2022-03-09 11:23, Maximilian Engelhardt wrote:
> What I noticed after booting the autopkgtest image is the following:
> 
> ttyAMA0 inside the vm is ttyS0 outside
> hvc0 inside the vm is hvc1 outside
> hcv1 inside the vm is hvc2 outside
> hvc0 outside the vm doesn't seem to do anything
> 
> So that's the problem, the hvc console numbers are all shifted by one. If you 
> leave out hvc2 in the qemu command line (to get the same as done by 
> autopkgtest), then hcv1 inside the vm does not exist: "No such device".

Based on this observation from Maximilian I've tried the following, which seems
to address the issue on arm64. Patch is also attached.

diff --git a/lib/autopkgtest_qemu.py b/lib/autopkgtest_qemu.py
index f958e0f..0cf307d 100644
--- a/lib/autopkgtest_qemu.py
+++ b/lib/autopkgtest_qemu.py
@@ -206,7 +206,7 @@ class Qemu:
 subdirectory of $TMPDIR)
 """
 
-self.consoles = set(['hvc0', 'hvc1'])
+self.consoles = set(['hvc0', 'hvc1', 'hvc2'])
 self.cpus = cpus
 self.images = []# type: List[QemuImage]
 self.overlay_dir = overlay_dir
@@ -359,7 +359,7 @@ class Qemu:
 ) % self.shareddir,
 ])
 
-for hvc in ('hvc0', 'hvc1'):
+for hvc in self.consoles:
 if hvc == 'hvc0' and self.qemu_architecture == 'ppc64le':
 # The first -serial argument shows up as /dev/hvc0 in
 # the VM on ppc64le, so identify it as such
diff --git a/virt/autopkgtest-virt-qemu b/virt/autopkgtest-virt-qemu
index 2b5b3fe..a92cee5 100755
--- a/virt/autopkgtest-virt-qemu
+++ b/virt/autopkgtest-virt-qemu
@@ -151,7 +151,7 @@ def setup_shell() -> str:
 user = args.user
 password = args.password
 
-for name in ('hvc1', 'ttyS1'):
+for name in ('hvc1', 'ttyS1', 'hvc2'):
 # if the VM is already prepared to start a root shell on ttyS1, just 
use it
 if name not in qemu.consoles:
 continue

Here's what the debug logs have to say. Note that the shell is found on
hvc2:

autopkgtest [17:10:10]: starting date: 2022-10-13
autopkgtest [17:10:10]: version 5.26
autopkgtest [17:10:10]: host ariel; command line: /usr/bin/autopkgtest -- qemu 
-d --cpus=2 --qemu-architecture=aarch64 /var/tmp/autopkgtest-unstable-arm64.img
autopkgtest-virt-qemu: DBG: executing open
autopkgtest-virt-qemu: DBG: find_free_port: trying 10022
autopkgtest-virt-qemu: DBG: find_free_port: 10022 is free
autopkgtest-virt-qemu: DBG: qemu architecture: aarch64

[...]

autopkgtest-virt-qemu: DBG: full qemu command-line: ['qemu-system-aarch64', 
'-machine', 'virt', '-cpu', 'cortex-a53', '-m', '1024', '-smp', '2', 
'-nographic', '-net', 'nic,model=virtio', '-net', 
'user,hostfwd=tcp:127.0.0.1:10022-:22', '-object', 
'rng-random,filename=/dev/urandom,id=rng0', '-device', 
'virtio-rng-pci,rng=rng0,id=rng-device0', '-monitor', 
'unix:/tmp/autopkgtest-qemu.bkj2lum4/monitor,server=on,wait=off', '-virtfs', 
'local,id=autopkgtest,path=/tmp/autopkgtest-qemu.bkj2lum4/shared,security_model=none,mount_tag=autopkgtest',
 '-chardev', 
'socket,path=/tmp/autopkgtest-qemu.bkj2lum4/hvc0,server=on,wait=off,id=hvc0', 
'-device', 'virtio-serial', '-device', 'virtconsole,chardev=hvc0', '-chardev', 
'socket,path=/tmp/autopkgtest-qemu.bkj2lum4/hvc2,server=on,wait=off,id=hvc2', 
'-device', 'virtio-serial', '-device', 'virtconsole,chardev=hvc2', '-chardev', 
'socket,path=/tmp/autopkgtest-qemu.bkj2lum4/hvc1,server=on,wait=off,id=hvc1', 
'-device', 'virtio-serial', '-device', 'virtconsole,chardev=hvc1', '-serial', 
'unix:/tmp/autopkgtest-qemu.bkj2lum4/ttyS0,server=on,wait=off', '-drive', 
'index=0,file=/tmp/autopkgtest-qemu.bkj2lum4/overlay.img,cache=unsafe,if=virtio,discard=unmap,format=qcow2',
 '-drive', 
'if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/AAVMF/AAVMF_CODE.fd', 
'-drive', 
'if=pflash,format=raw,unit=1,file=/tmp/autopkgtest-qemu.bkj2lum4/efivars.fd']
autopkgtest-virt-qemu: DBG: expect: b' login: '
autopkgtest-virt-qemu: DBG: expect: found "'login prompt on serial console'"
autopkgtest-virt-qemu: DBG: expect: b'ok'
autopkgtest-virt-qemu: DBG: expect: b'ok'
autopkgtest-virt-qemu: DBG: expect: found "b'ok'"
autopkgtest-virt-qemu: DBG: setup_shell(): there already is a shell on hvc2
diff --git a/lib/autopkgtest_qemu.py b/lib/autopkgtest_qemu.py
index f958e0f..0cf307d 100644
--- a/lib/autopkgtest_qemu.py
+++ b/lib/autopkgtest_qemu.py
@@ -206,7 +206,7 @@ class Qemu:
 subdirectory of $TMPDIR)
 """
 
-self.consoles = set(['hvc0', 'hvc1'])
+self.consoles = set(['hvc0', 'hvc1', 'hvc2'])
 self.cpus = cpus
 self.images = []# type: List[QemuImage]
 self.overlay_dir = overlay_dir
@@ -359,7 +359,7 @@ class Qemu:
 ) % self.shareddir,
 ])
 
-for hvc in ('hvc0', 'hvc1'):
+for hvc in self.consoles:
 if hvc == 'hvc0' and self.qemu_architecture == 'ppc64le':
 # The first -serial argument shows up as /dev/hvc0 

Bug#1021729: gnome-settings-daemon: External monitor detected but not identified.

[Ted To]

Package: gnome-settings-daemon
Version: 43.0-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
 a recent upgrade from the testing repository
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 NA
   * What was the outcome of this action?
 NA
   * What outcome did you expect instead?
 NA

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: 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 gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  43.0-2
ii  gsettings-desktop-schemas 43.0-1
ii  libasound21.2.7.2-1
ii  libc6 2.35-3
ii  libcairo2 1.16.0-6
ii  libcanberra-gtk3-00.30-10
ii  libcanberra0  0.30-10
ii  libcolord21.4.6-1
ii  libcups2  2.4.2-1+b1
ii  libfontconfig12.13.1-4.5
ii  libgcr-base-3-1   3.41.1-1
ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
ii  libgeoclue-2-02.6.0-2
ii  libgeocode-glib-2-0   3.26.3-3
ii  libglib2.0-0  2.74.0-2
ii  libgnome-desktop-3-20 43-2
ii  libgtk-3-03.24.34-3
ii  libgudev-1.0-0237-2
ii  libgweather-4-0   4.2.0-1
ii  libmm-glib0   1.18.12-1
ii  libnm01.40.0-1
ii  libnotify40.8.1-1
ii  libnspr4  2:4.35-1
ii  libnss3   2:3.83-1
ii  libpam-systemd [logind]   251.5-2
ii  libpango-1.0-01.50.10+ds-1
ii  libpangocairo-1.0-0   1.50.10+ds-1
ii  libpolkit-gobject-1-0 0.105-33
ii  libpulse-mainloop-glib0   16.1+dfsg1-2
ii  libpulse0 16.1+dfsg1-2
ii  libspa-0.2-bluetooth  0.3.59-1
ii  libupower-glib3   0.99.20-1
ii  libwacom9 2.4.0-3
ii  libwayland-client01.21.0-1
ii  libx11-6  2:1.8.1-2
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  pipewire-pulse0.3.59-1
ii  pulseaudio16.1+dfsg1-2
ii  pulseaudio-module-bluetooth   16.1+dfsg1-2
ii  wireplumber   0.4.12-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy  3.0-2
ii  libspa-0.2-bluetooth  0.3.59-1
ii  pipewire-pulse0.3.59-1
ii  wireplumber   0.4.12-1
ii  x11-xserver-utils 7.7+9+b1

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

-- no debconf information

Bug#1021728: tracker.debian.org: Please include the new "non-free-firmware" section

[Gunnar Wolf]

Package: tracker.debian.org
Severity: normal

Hello,

Last week I uploaded raspi-firmware to non-free-firmware (and was
promptly processed through NEW, whee!).

Two days ago, it successfully migrated to Texting.

I am now building the Raspberry Pi images for Bookworm , and
raspi-firmware is correctly downloaded from non-free-firmware.

However, tracker.debian.org misleadingly shows the package as if it
was removed from Debian («package is gone. This package is not in any
development repository. (...)», and no longer lists it for testing and
unstable.

Thank you very much!

Bug#1020056:

[Thomas Braun]

The reason for the build breakage can be found in

https://tracker.debian.org/media/packages/z/zeromq3/changelog-4.3.4-3

which has

zeromq3 (4.3.4-3) unstable; urgency=medium

  * Remove zmq{,_addon}.hpp as these provided by cppzmq-dev from now on
(closes: #972785).

 -- Laszlo Boszormenyi (GCS)   Mon, 15 Aug 2022
18:40:34 +0200

so I think it should be as easy as adding cppzmq-dev to the build
dependencies.

 $diff -Nur control control.new
--- control 2022-10-13 16:19:07.384578078 +0200
+++ control.new 2022-10-13 16:19:03.972578004 +0200
@@ -7,6 +7,7 @@
default-libmysqlclient-dev,
libcos4-dev,
libzmq5-dev | libzmq3-dev,
+   cppzmq-dev,
omniidl,
po-debconf
 Build-Depends-Indep: doxygen,

Bug#1003002: autopkgtest-virt-qemu: Console setup issue on armhf

[Emanuele Rocca]

On 2022-01-12 10:58, Christian Kastner wrote:
> On 2022-01-12 20:14, Christian Kastner wrote:
> > Addendum: I'm now occasionally also seeing this with arm64 when using
> > sbuild with --chroot-mode=autopkgtest. I'd say it's 50/50 between
> > success and failure.
> 
> Yet another data point: by reducing the CPU count to 1, it seems that
> the success rate climbs to 100% on arm64.

I also encountered this with an arm64 qemu image, and the count of CPUs seems
indeed to be the key difference between success and failure. On my system, the
following works fine:

  $ autopkgtest -- qemu --cpus=1 --qemu-architecture=aarch64 
/var/tmp/autopkgtest-unstable-arm64.img

Any value of --cpus greater than 1 fails consistently as follows.

  $ autopkgtest -- qemu --cpus=2 --qemu-architecture=aarch64 
/var/tmp/autopkgtest-unstable-arm64.img
  autopkgtest [16:53:30]: starting date: 2022-10-13
  autopkgtest [16:53:30]: version 5.26
  autopkgtest [16:53:30]: host ariel; command line: /usr/bin/autopkgtest -- 
qemu --cpus=2 --qemu-architecture=aarch64 
/var/tmp/autopkgtest-unstable-arm64.img
  qemu-system-aarch64: -drive 
if=pflash,format=raw,unit=0,read-only,file=/usr/share/AAVMF/AAVMF_CODE.fd: 
warning: short-form boolean option 'read-only' deprecated
  Please use read-only=on instead
  qemu-system-aarch64: terminating on signal 15 from pid 86611 
(/usr/bin/python3)
  : failure: The VM does not start a root shell on ttyS1 or hvc1 
already. The only other supported login mechanism is through --user and 
--password on the guest ttyS0
  autopkgtest [16:54:04]: ERROR: testbed failure: unexpected eof from the 
testbed

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[Holger Wansing]

Hi,



Am 13. Oktober 2022 13:26:24 MESZ schrieb "наб" 
:
>Package: manpages.debian.org
>Severity: normal
>
>Dear Maintainer,
>
>https://dyn.manpages.debian.org/faq.html:
>  source code: 
> https://anonscm.debian.org/git/collab-maint/debian-goodies.git/plain/dman?id=19924c907a8b907eaea3c0d942c5ae780ef6111e
>  static assets repository: 
> https://anonscm.debian.org/git/srv-manpages/debian-assets.git/
>  hosted on Alioth: 
> https://anonscm.debian.org/git/srv-manpages/debian-assets.git/
>   404, AIUI anonscm/alioth has been dead for years
>
>  Alioth project: https://alioth.debian.org/projects/srv-manpages/
>  doesn't even resolve
>
>  mdocml: http://mdocml.bsd.lv/
>  Report at mdocml: http://mdocml.bsd.lv/contact.html
>  it's been mandoc for close to a decade, and should be
>  mandoc: https://mandoc.bsd.lv/
>  Report at mandoc: http://mandoc.bsd.lv/contact.html
>
>I'd post a patch, but, well. No clue what against, given the givens.

The dead URLs you mention have already been reported in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960597
(but not fixed, sadly).

If you want to help with this and provide a proper patch, that
would be against debian-assets:
https://salsa.debian.org/manpages-team/debian-assets/-/blob/master/faq.tmpl

Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1021727: RFS: gixy/0.1.20-1 [ITP] -- Nginx configuration static analyzer

[Lance Lin]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "gixy".

This package was an RFP on the WNPP page. It is currently hosted at: 
https://salsa.debian.org/linqigang/gixy

I left the VCS blank as this package may be a fit for the python team. I am 
unsure where to place it once it is uploaded but would be happy to change this 
once it is decided. If not, I would be happy to maintain it on my own.

I am not on the python team, but I made sure the package was compliant with the 
python team standards.

 * Package name : gixy
   Version  : 0.1.20-1
   Upstream contact : Andrew Krasichkov 
 * URL  : https://github.com/yandex/gixy
 * License  : Python, MPL-2.0
 * Vcs  : [fill in URL of packaging vcs]
   Section  : web

The source builds the following binary packages:

  python3-gixy - Nginx configuration static analyzer

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

  https://mentors.debian.net/package/gixy/

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

  dget -x https://mentors.debian.net/debian/pool/main/g/gixy/gixy_0.1.20-1.dsc

Changes for the initial release:

 gixy (0.1.20-1) unstable; urgency=low
 .
   * Initial release. (Closes: #997953)

Regards,
-- https://salsa.debian.org/linqigang/gixy

Lance Lin 
GPG Fingerprint:  4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7

signature.asc
Description: OpenPGP digital signature

Bug#1008735: base-files: /etc/os-release should contain VERSION variables for testing and unstable

[Masahiro Yamada]

Hi Sedat,

Sorry for my late replay.


On Mon, Oct 3, 2022 at 6:56 PM Sedat Dilek  wrote:
>
> [ CC linux-kbuild folks (see [0] ]



Can you give me more context of this email?




> Hi,
>
> I am using Debian/unstable AMD64 and doing Linux-kernel upstream
> development and testing.
>
> People using bindeb-pkg (mkdebian) from Linux-kernel sources
> (scripts/packages) to build and test their selfmade Debian kernels get
> a now a "n/a" for distribution.



Right, if I try the latest sid,
"lsb_release -cs" returns "n/a".
It returned "sid" before IIRC.


What was changed in Debian?
Any change in the lsb_release program?







>
> Background (see [1]):
>
> [ scripts/package/mkdebian ]
>
> # Try to determine distribution
> if [ -n "$KDEB_CHANGELOG_DIST" ]; then
> distribution=$KDEB_CHANGELOG_DIST
> # In some cases lsb_release returns the codename as n/a, which breaks
> dpkg-parsechangelog
> elif distribution=$(lsb_release -cs 2>/dev/null) && [ -n
> "$distribution" ] && [ "$distribution" != "n/a" ]; then
> : # nothing to do in this case
> else
> distribution="unstable"
> echo >&2 "Using default distribution of 'unstable' in the changelog"
> echo >&2 "Install lsb-release or set \$KDEB_CHANGELOG_DIST explicitly"
> fi
>
> Personally, I set hardcoded in my kernel build-script as a workaround:
>
> distribution="bookworm"
>
> Gioele suggested me to enrich /etc/os-release with:
>
> VERSION_ID=unstable <--- XXX: I prefer sid because of PRETTY_NAME and
> it's shorter
> VERSION_CODENAME=bookworm
>
> In the end the file looks like:
>
> PRETTY_NAME="Debian GNU/Linux bookworm/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> VERSION_ID=sid
> VERSION_CODENAME=bookworm
> HOME_URL="https://www.debian.org/;
> SUPPORT_URL="https://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
>
> ...and this seems to work:
>
> # lsb_release -cs
> No LSB modules are available.
> bookworm
>
> Please, provide a solution not to break workflows that were successful
> for years.
>
> Thanks.
>
> Best regards,
> -Sedat-
>
> [0] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n11005
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/package/mkdebian#n123



-- 
Best Regards
Masahiro Yamada

Bug#1021726: kmail: Typo on "Secure your Communication" screen in KMail/GPG Account Assistant "Publish this key"

[Kent West]

Package: kmail
Version: 4:22.08.0-2
Severity: minor
X-Debbugs-Cc: westk@acu.local

Dear Maintainer,

*** Reporter, please consider answering these questions, where 
appropriate ***


   * What led up to the situation?
Setting up KMail

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
New Debian user (authenticating via realmd/Windows AD domain); logged into
Plasma; started KMail; did not import other email client settings; got to
"Account Assistant" window, titled "Secure your Communication", and in the
"Publish this key on public key server" text box the word "the" is 
mispelled as

"they", in the last sentence, where it says "they key cannot be removed from
there".

   * What was the outcome of this action?
Finding a misspelled word (see previous question's answer).

   * What outcome did you expect instead?
"the" instead of "they"

*** End of the template - remove these template lines ***


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: 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 kmail depends on:
ii  akonadi-server 4:22.08.0-2+b1
ii  kdepim-runtime 4:22.08.0-2
ii  kio 5.98.0-1
ii  libc6 2.35-3
ii  libgcc-s1 12.2.0-5
ii  libgpgmepp6 1.18.0-1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-22.08] 4:22.08.0-2+b1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-22.08] 4:22.08.0-2
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.08] 4:22.08.0-2+b1
ii  libkf5akonadimime5 [libkf5akonadimime5-22.08] 4:22.08.0-2
ii  libkf5akonadisearch-bin 4:22.08.0-2
ii  libkf5akonadisearch-plugins 4:22.08.0-2
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-22.08] 4:22.08.0-2
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-22.08] 4:22.08.0-2
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.08] 4:22.08.0-2+b1
ii  libkf5bookmarks5 5.98.0-1
ii  libkf5calendarcore5abi2 5:5.98.0-1
ii  libkf5calendarutils5 [libkf5calendarutils5-22.08] 4:22.08.0-2
ii  libkf5codecs5 5.98.0-1
ii  libkf5completion5 5.98.0-1
ii  libkf5configcore5 5.98.0-1
ii  libkf5configgui5 5.98.0-1
ii  libkf5configwidgets5 5.98.0-1
ii  libkf5contacts5 5:5.98.0-1
ii  libkf5coreaddons5 5.98.0-1
ii  libkf5crash5 5.98.0-1
ii  libkf5dbusaddons5 5.98.0-1
ii  libkf5grantleetheme-plugins 22.08.0-2
ii  libkf5gravatar5abi2 [libkf5gravatar5-22.08] 4:22.08.0-2
ii  libkf5guiaddons5 5.98.0-2
ii  libkf5i18n5 5.98.0-1+b1
ii  libkf5iconthemes5 5.98.0-2+b1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-22.08] 22.08.0-2
ii  libkf5identitymanagementwidgets5 [libkf5identitymanagementw 22.08.0-2
ii  libkf5itemmodels5 5.98.0-1
ii  libkf5itemviews5 5.98.0-1
ii  libkf5jobwidgets5 5.98.0-1
ii  libkf5kcmutils5 5.98.0-1
ii  libkf5kiocore5 5.98.0-1
ii  libkf5kiofilewidgets5 5.98.0-1
ii  libkf5kiogui5 5.98.0-1
ii  libkf5kiowidgets5 5.98.0-1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-22.08] 22.08.0-2
ii  libkf5ksieveui5 [libkf5ksieveui5-22.08] 4:22.08.0-2
ii  libkf5ldap5abi1 [libkf5ldap5-22.08] 22.08.0-2
ii  libkf5libkdepim5 [libkf5libkdepim5-22.08] 4:22.08.0-2
ii  libkf5libkleo5 [libkf5libkleo5-22.08] 4:22.08.0-2
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-22.08] 4:22.08.0-2
ii  libkf5mailtransport5 [libkf5mailtransport5-22.08] 22.08.0-2
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-22 22.08.0-2
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-22.08] 4:22.08.0-2
ii  libkf5messagecore5abi1 [libkf5messagecore5-22.08] 4:22.08.0-2
ii  libkf5messagelist5abi1 [libkf5messagelist5-22.08] 4:22.08.0-2
ii  libkf5messageviewer5abi1 [libkf5messageviewer5-22.08] 4:22.08.0-2
ii  libkf5mime5abi1 [libkf5mime5-22.08] 22.08.0-2
ii  libkf5mimetreeparser5abi1 [libkf5mimetreeparser5-22.08] 4:22.08.0-2
ii  libkf5notifications5 5.98.0-1
ii  libkf5notifyconfig5 5.98.0-1
ii  libkf5parts5 5.98.0-1
ii  libkf5pimcommon5abi2 [libkf5pimcommon5-22.08] 4:22.08.0-2
ii  libkf5pimcommonakonadi5abi1 [libkf5pimcommonakonadi5-22.08] 4:22.08.0-2
ii  libkf5pimtextedit5abi2 [libkf5pimtextedit5-22.08] 22.08.0-2
ii  libkf5service-bin 5.98.0-1
ii  libkf5service5 5.98.0-1
ii  libkf5sonnetui5 5.98.0-1
ii  libkf5templateparser5 [libkf5templateparser5-22.08] 4:22.08.0-2
ii  libkf5textwidgets5 5.98.0-1
ii  libkf5tnef5 [libkf5tnef5-22.08] 4:22.08.0-2
ii  libkf5webengineviewer5abi1 [libkf5webengineviewer5-22.08] 4:22.08.0-2
ii  libkf5widgetsaddons5 5.98.0-1
ii  libkf5windowsystem5 5.98.0-1
ii  libkf5xmlgui5 5.98.0-1+b1
ii  libkuserfeedbackcore1 1.2.0-2
ii  libkuserfeedbackwidgets1 1.2.0-2
ii  libqgpgme15 1.18.0-1
ii  libqt5core5a 5.15.6+dfsg-2
ii  libqt5dbus5 5.15.6+dfsg-2
ii  libqt5gui5 5.15.6+dfsg-2
ii  libqt5keychain1 0.13.2-5
ii  

Bug#574060: reportbug: Should make a backup/archive copy of bug reports under the user home dir

[Kent West]

 Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Kent West 
To: Debian Bug Tracking System <574...@bugs.debian.org>
Subject: Re: reportbug: Should make a backup/archive copy of bug reports under 
the user home dir

Package: reportbug
Version: 11.5.1
Followup-For: Bug #574060
X-Debbugs-Cc: westk@acu.local

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

Or simply a warning that the report stored in /tmp may disappear, so the user
should make a copy of it to somewhere safe.

Also maybe mention that this bug report can be sent as an attachment via the
user's normal email process (web-based GMail, etc) to the proper address (also
mention what that address is), rather than getting abandoned because the user
never learns how or gets around to setting up his own MTA. (Assuming that this
is true - my understanding of reporting bugs is newbie-ish.)

*** End of the template - remove these template lines ***


-- Package-specific info:
** Environment settings:
INTERFACE="gtk"

** /home/westk@acu.local/.reportbugrc:
reportbug_version "11.5.1"
mode standard
ui gtk
realname "Kent West"
no-cc
list-cc-me
smtphost reportbug.debian.org

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: 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 reportbug depends on:
ii  apt2.5.3
ii  python33.10.6-1
ii  python3-reportbug  11.5.1
ii  sensible-utils 0.0.17

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf1.5.79
ii  debsums3.0.2
pn  dlocate
ii  emacs-bin-common   1:28.1+1-4
ii  exim4-daemon-light [mail-transport-agent]  4.96-6
ii  file   1:5.41-4
ii  gnupg  2.2.39-1
ii  python3-urwid  2.1.2-2+b2
ii  reportbug-gtk  11.5.1
ii  xdg-utils  1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.5.3
ii  file   1:5.41-4
ii  python33.10.6-1
ii  python3-apt2.3.0+b2
ii  python3-debian 0.1.48
ii  python3-debianbts  3.2.3
ii  python3-requests   2.27.1+dfsg-1
ii  sensible-utils 0.0.17

python3-reportbug suggests no packages.

-- no debconf information

Bug#930111: kmail: Autoconfig doesn't work

[Kent West]

 Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Kent West 
To: Debian Bug Tracking System <930...@bugs.debian.org>
Subject: Re: kmail: Autoconfig doesn't work

Package: kmail
Version: 4:22.08.0-2
Followup-For: Bug #930111
X-Debbugs-Cc: westk@acu.local

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Starting KMail for first time.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Started KMail for first time. Have no idea how to configure KMail for a "Google
for Education" (I think is what it's called nowadays) account (that uses SSO
for my org's web-portal for login). The Auto-config of KMail does not find this
information. Thunderbird's does find it. (For email, at least; coughs up blood
with Calendar and Contacts, but ... meh.)

   * What was the outcome of this action?
A KMail window that knows nothing about my "Google for Education" email
account.

   * What outcome did you expect instead?
For KMail to find the required settings for my email account that is on my
university's domain but authenticates (via Microsoft?) via SSO to GMail (the
university web portal asks for my username/password/MFA, then that takes me to
a Google page saying that KMail wants to access X and Y and Z where I have to
give it perms to do so).
*** End of the template - remove these template lines ***


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: 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 kmail depends on:
ii  akonadi-server   4:22.08.0-2+b1
ii  kdepim-runtime   4:22.08.0-2
ii  kio  5.98.0-1
ii  libc62.35-3
ii  libgcc-s112.2.0-5
ii  libgpgmepp6  1.18.0-1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-22.08]  4:22.08.0-2+b1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-22.08]  4:22.08.0-2
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.08]4:22.08.0-2+b1
ii  libkf5akonadimime5 [libkf5akonadimime5-22.08]4:22.08.0-2
ii  libkf5akonadisearch-bin  4:22.08.0-2
ii  libkf5akonadisearch-plugins  4:22.08.0-2
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-22.08]  4:22.08.0-2
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-22.08]  4:22.08.0-2
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.08]  4:22.08.0-2+b1
ii  libkf5bookmarks5 5.98.0-1
ii  libkf5calendarcore5abi2  5:5.98.0-1
ii  libkf5calendarutils5 [libkf5calendarutils5-22.08]4:22.08.0-2
ii  libkf5codecs55.98.0-1
ii  libkf5completion55.98.0-1
ii  libkf5configcore55.98.0-1
ii  libkf5configgui5 5.98.0-1
ii  libkf5configwidgets5 5.98.0-1
ii  libkf5contacts5  5:5.98.0-1
ii  libkf5coreaddons55.98.0-1
ii  libkf5crash5 5.98.0-1
ii  libkf5dbusaddons55.98.0-1
ii  libkf5grantleetheme-plugins  22.08.0-2
ii  libkf5gravatar5abi2 [libkf5gravatar5-22.08]  4:22.08.0-2
ii  libkf5guiaddons5 5.98.0-2
ii  libkf5i18n5  5.98.0-1+b1
ii  libkf5iconthemes55.98.0-2+b1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-22.08]  22.08.0-2
ii  libkf5identitymanagementwidgets5 [libkf5identitymanagementw  22.08.0-2
ii  libkf5itemmodels55.98.0-1
ii  libkf5itemviews5 5.98.0-1
ii  libkf5jobwidgets55.98.0-1
ii  libkf5kcmutils5  5.98.0-1
ii  libkf5kiocore5   5.98.0-1
ii  libkf5kiofilewidgets5 

Bug#978663: facter: please package facter 4.x

[Jérôme Charaoui]

On Tue, 29 Dec 2020 15:41:08 -0500 
=?UTF-8?Q?Louis-Philippe_V=c3=a9ronneau?=  wrote:

Package: src:facter
Severity: wishlist

Dear maintainer,

While puppet 6 still supports facter 3.x, I think it wouldn't be a bad
idea to package facter 4.x in the archive.

It seems the current version of puppet in Debian (puppet 5) requires the
3.x version though [1], so we can't just push 4.x to sid.

Considering facter 4.x is a re-write in ruby, I think the best option
would be to create a "facter4" package and keep facter in Debian as
"facter3".


Now that puppet-agent 7.x is in unstable, I don't think keeping facter 
3.x is relevant at all. In fact, that version is now deprecated and 
unmaintained. So I think it's best to keep the package named "facter" in 
version 4 and beyond.


-- Jerome

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[наб]

Hi!

On Thu, Oct 13, 2022 at 02:52:21PM +0200, Joost van Baal-Ilić wrote:
> On Thu, Oct 13, 2022 at 02:15:56PM +0200, наб wrote:
> > On Thu, Oct 13, 2022 at 01:55:42PM +0200, Joost van Baal-Ilić wrote:
> > > https://dyn.manpages.debian.org/faq.html redirects here to
> > > https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html which I 
> > > asssume
> > > is build from  avr-libc 1:2.0.0+Atmel3.6.2-1.1 .  I guess you'd have to 
> > > report
> > > a bug to avr-libc.  *But* I can't find any of the problems you've found 
> > > in the
> > > webpage @ https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html 
> > > 
> > My report concerns the Debian Manpages FAQ with canonical URL
> >   https://manpages.debian.org/faq.html
> > (at least I hope that's the canonical URL!)
> 
> Aha!  It seems debiman is where this should get reported.  Either
> 
>  reportbug debiman
> 
> (it's shipped with unstable and oldstable) or @ 
> https://github.com/Debian/debiman/ .

I looked at the repository when I was preparing the report and didn't
see any matches for "alioth" or "static ass"; I looked again, this time
at the current sid package (0.0~git20200217.fc82521-1) and likewise see
no matches.

AFAICT this is an issue with the "static assets repository"
(404s in the FAQ) which is part of manpages.d.o more so than debiman
which is mostly frontend-agnostic it seems,
and doesn't ship the FAQ/Index/About pages?

Best,
наб


signature.asc
Description: PGP signature

Bug#1021660: gcc-12-offload-nvptx: offloading to nvidia via nvptx fails with cuda version 11 (default in sid)

[Giacomo Mulas]

On Thu, 13 Oct 2022, Thomas Schwinge wrote:


It does work, but only for the code that GCC/nvptx generates in that
'gcc-12' invocation, but not for the support libraries that it linkes in,
which are built for sm_30.


Does this mean then that the support libraries of gcc-11-offload-nvptx
include both support for sm_30 and sm_35? Is it possible to compile such
support libraries so that they do support more than one cuda arch level,
instead of having, as in the case of GCC 12 support libraries, _only_ sm_30
as available option (if I understood you correctly)?


However, that doesn't really help you as a user of GCC, as long as the
distributions don't (have an easy way to) build more variants for several
sm_[...].  More work is necessary in GCC/nvptx upstream to make that
feasible.


well, debian in itself does support this kind of setup, doesn't it? With
alternatives, provides in dpkg... Of course, I gather that putting together
the machinery to build a number of versions of the same package would be
somewhat of a pain to set up and maintain.

But anyway, given all you said, can this issue be solved at all, even acting
on nvptx-tools? If the issue lies in the support libraries, that problem
would still remain regardless of what you do on nvptx-tools, wouldn't it?

Thanks, bye
Giacomo

--
_

Giacomo Mulas 
_

INAF - Osservatorio Astronomico di Cagliari
via della scienza 5 - 09047 Selargius (CA)

tel.   +39 070 71180255
mob. : +39 329  6603810
_

"It's just a shadow of the man you should be
Like a garden in the forest that the world will never see
You have no thought of answers only questions to be filled"
 (Big Country)
_

Bug#1017941: greenbone-security-assistant downloads source from the network

[Sophie Brun]

Hello,

Le 12/10/2022 à 01:37, Andreas Beckmann a écrit :

A similar case is src:nvda2speechd (#1021390) and the solution there was
to move the package to non-free.


Yes I think it's the only solution here. I will move the package to non-free.

There is a new upstream release. I'm working on the update (there are several 
packages to update).

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[Joost van Baal-Ilić]

Hi наб,

On Thu, Oct 13, 2022 at 02:15:56PM +0200, наб wrote:
> On Thu, Oct 13, 2022 at 01:55:42PM +0200, Joost van Baal-Ilić wrote:
> > https://dyn.manpages.debian.org/faq.html redirects here to
> > https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html which I 
> > asssume
> > is build from  avr-libc 1:2.0.0+Atmel3.6.2-1.1 .  I guess you'd have to 
> > report
> > a bug to avr-libc.  *But* I can't find any of the problems you've found in 
> > the
> > webpage @ https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html 
> > 
> 
> Of course it does. I even got this once while testing.
> This is a caching issue ‒ for me it shows the Manpages FAQ,
> and if I Ctrl-Shift-R it shows the avr-libc FAQ(3) like it does for you.
> 
> So this is another bug, I guess, since the top bar links to
> dyn.m.d.o/faq.html instead of the correct dyn.-free page on the error
> pages for example (i got there from the nonexistent m.d.o/unrar, which
> redirected me to dyn.m.d.o/unrar to show me the 404).
> 
> My report concerns the Debian Manpages FAQ with canonical URL
>   https://manpages.debian.org/faq.html
> (at least I hope that's the canonical URL!)

Aha!  It seems debiman is where this should get reported.  Either

 reportbug debiman

(it's shipped with unstable and oldstable) or @ 
https://github.com/Debian/debiman/ .

HTH, Bye,

Joost

Bug#1021725: ITP: golang-github-alexliesenfeld-health -- simple and flexible health check library for Go

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-alexliesenfeld-health
  Version : 0.6.0-1
  Upstream Author : Alexander Liesenfeld
* URL : https://github.com/alexliesenfeld/health
* License : Expat
  Programming Lang: Go
  Description : simple and flexible health check library for Go

 This library provides an http.Handler that acts as a health endpoint. It
 can be used by cloud infrastructure or other services to determine the
 availability of an application.

 Rather than simply returning a response with HTTP status code 200, this
 library allows building health checks that test the availability of all
 required dependencies. The HTTP response contains the aggregated health
 result and details about the health status of each component.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021724: ITP: golang-github-crowdsecurity-machineid -- get the unique machine identifier of any host (library)

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-crowdsecurity-machineid
  Version : 1.0.3-1
  Upstream Author : crowdsec
* URL : https://github.com/crowdsecurity/machineid
* License : Expat
  Programming Lang: Go
  Description : get the unique machine identifier of any host (library)

 This package returns the OS native machine UUID/GUID, which the OS
 uses for internal needs. All machine IDs are usually generated during
 system installation and stay constant for all subsequent boots.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021723: ITP: golang-github-hashicorp-hcl-v2 -- Go implementation of HashiCorp Configuration Language (version 2)

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-hashicorp-hcl-v2
  Version : 2.14.1-1
  Upstream Author : HashiCorp
* URL : https://github.com/hashicorp/hcl
* License : MPL-2.0
  Programming Lang: Go
  Description : Go implementation of HashiCorp Configuration Language 
(version 2)

 HCL (HashiCorp Configuration Language) is a configuration language built by
 HashiCorp. The goal of HCL is to build a structured configuration language that
 is both human and machine friendly for use with command-line tools, but
 specifically targeted towards DevOps tools, servers, etc.

 HCL is also fully JSON compatible. That is, JSON can be used as completely
 valid input to a system expecting HCL. This helps makes systems interoperable
 with other systems.

 HCL is heavily inspired by libucl, nginx configuration, and others similar.

 This package contains the source.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html

There's an existing golang-github-hashicorp-hcl package, kind of stalled
at version 1.0.0, which is depended on by close to 100 packages. It
seems prudent to introduce a -v2 package for hashicorp/hcl/v2, leaving it
up to reverse dependencies to switch to the new version if and when they
so desire.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021722: ITP: golang-github-r3labs-diff -- diffing library for Go structures

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-r3labs-diff
  Version : 3.0.0-1
  Upstream Author : R3 Labs
* URL : https://github.com/r3labs/diff
* License : MPL-2.0
  Programming Lang: Go
  Description : diffing library for Go structures

 Utilizing field tags and reflection, this library makes it possible
 to compare two structures of the same type and create a changelog of
 all modified values. The produced changelog can easily be serialized
 to JSON.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021721: ITP: golang-entgo-ent -- entity framework for Go

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-entgo-ent
  Version : 0.11.3-1
  Upstream Author : Ent Foundation
* URL : https://github.com/ent/ent
* License : Apache-2.0
  Programming Lang: Go
  Description : entity framework for Go

 The ent package is a simple, yet powerful entity framework for Go,
 that makes it easy to build and maintain applications with large
 data-models.

 Highlights include:
  - Schema As Code - model any database schema as Go objects.
  - Easily Traverse Any Graph - run queries, aggregations and traverse
any graph structure easily.
  - Statically Typed And Explicit API - 100% statically typed and
explicit API using code generation.
  - Multi Storage Driver - supports MySQL, PostgreSQL, SQLite and
Gremlin.
  - Extendable - simple to extend and customize using Go templates.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html

This package replaces the existing golang-github-facebook-ent, which can
be removed after crowdsec has been updated.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021720: ITP: golang-github-c-robinson-iplib -- library for working with IP addresses and networks in Go

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-c-robinson-iplib
  Version : 1.0.3-1
  Upstream Author : Chad Robinson
* URL : https://github.com/c-robinson/iplib
* License : Expat
  Programming Lang: Go
  Description : library for working with IP addresses and networks in Go

 IPLib is built around and on top of the address primitives found in
 the net package, trying to make them more accessible and easier to
 manipulate, in the spirit of Python's ipaddress and Ruby's ipaddr
 libraries.

 It features:
  - tools performing common tasks against regular net.IP objects;
  - an iplib.Net interface that enhances net.IPNet.

 It also features two submodules:
  - iana: referencing IP netblocks against the Internet Assigned
Numbers Authority's Special IP Address Registry;
  - iid: generating and validating IPv6 Interface Identifiers,
including RFC4291 modified EUI64 and RFC7217 Semantically Opaque
addresses.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021719: ITP: golang-github-jszwec-csvutil -- fast and idiomatic mapping between CSV and Go values (library)

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-jszwec-csvutil
  Version : 1.7.1-1
  Upstream Author : Jacek Szwec
* URL : https://github.com/jszwec/csvutil
* License : Expat
  Programming Lang: Go
  Description : fast and idiomatic mapping between CSV and Go values 
(library)

 This package provides provides fast, idiomatic, and dependency-free
 mapping between CSV and Go values. It is not a CSV parser, it is based
 on the Reader and Writer interfaces which are implemented by e.g the
 standard Go csv package. It is possible to choose any other CSV writer
 or reader which may be more performant.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021718: ITP: golang-github-crowdsecurity-grokky -- pure Golang Grok-like library

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-crowdsecurity-grokky
  Version : 0.1.0-1
  Upstream Author : crowdsec
* URL : https://github.com/crowdsecurity/grokky
* License : WTFPL
  Programming Lang: Go
  Description : pure Golang Grok-like library

 grokky is a pure Golang Grok-like patterns library with a particular
 focus on parsing log files, and on performance (leveraging the RE2
 regular expression engine instead of Oniguruma).

 The library was designed for creating many patterns and using them
 many times, while not retaining the exact same behaviors and features
 as the original library. The main goals are simplicity, speed, and
 ease of use.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html

This package replaces the existing golang-github-logrusorgru-grokky,
which can be removed after crowdsec has been updated.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021717: ITP: golang-github-confluentinc-bincover -- easily measure code coverage of Golang binaries (library)

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-confluentinc-bincover
  Version : 0.2.0-1
  Upstream Author : Confluent Inc.
* URL : https://github.com/confluentinc/bincover
* License : Expat
  Programming Lang: Go
  Description : easily measure code coverage of Golang binaries (library)

 Bincover is a ready-to-use, generic solution to test Go binaries,
 which is robust enough to handle panics and OS exits. It provides a
 simple and flexible API that generates an “instrumented binary” that
 can measure its own coverage, runs it with user-specified command
 line arguments and environment variables, and merges coverage
 profiles generated from multiple test runs.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021716: ITP: golang-ariga-atlas -- manage your database schemas with Atlas (library)

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-ariga-atlas
  Version : 0.7.2-1
  Upstream Author : Ariga
* URL : https://github.com/ariga/atlas
* License : Apache-2.0
  Programming Lang: Go
  Description : manage your database schemas with Atlas (library)

 Atlas is an open source tool that helps developers manage their
 database schemas by applying modern DevOps principles. Contrary to
 existing tools, Atlas intelligently plans schema migrations for
 you. Atlas users can use the Atlas DDL (data definition language) to
 describe their desired database schema and use the command-line tool
 to plan and apply the migrations to their systems.

 It supports the following databases: MySQL, MariaDB, PostgresSQL,
 SQLite, TiDB, CockroachDB.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1021715: ITP: golang-github-crowdsecurity-dlog -- Go library to parse the Docker Logs stream (library)

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-crowdsecurity-dlog
  Version : 0.0.2-1
  Upstream Author : crowdsec
* URL : https://github.com/crowdsecurity/dlog
* License : Apache-2.0
  Programming Lang: Go
  Description : Go library to parse the Docker Logs stream (library)

 This library parses the binary Docker Logs stream into plain text.
 Given the full response body to a /containers//logs request, it
 strips off the log headers and returns the actual plain text message.


This is a requirement to update crowdsec:
  https://lists.debian.org/debian-go/2022/10/msg00018.html


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1019701: RFP: rpi-imager -- Raspberry Pi Imaging Utility

[Lance Lin]

Hello Francois,

>On Tue, 13 Sep 2022 09:21:20 -0700 Francois Marier  wrote:
> Package: wnpp
> Severity: wishlist
> 

> * Package name: rpi-imager
>   Version : 1.7.3
>   Upstream Author : Raspberry Pi
> * URL : https://github.com/raspberrypi/rpi-imager
> * License : Apache-2.0
>   Programming Lang: C++
>   Description : Raspberry Pi Imaging Utility
> 

> Raspberry Pi Imager is the quick and easy way to install Raspberry Pi OS and
> other operating systems (but not Debian) to a microSD card, ready to use
> with your Raspberry Pi.

I've contacted the upstream authors about this prospective package [1].

They indicated that there is not a desire to have their package in Debian due
to the long release cycle. There are a few changes that would need to be made
but without their interest or consent, it seems stuck. It is in good shape and
would be easy to put into Debian due to most of the packaging (e.g. /debian) 

being done, however.

[1] https://github.com/raspberrypi/rpi-imager/issues/493

Thank you,

Lance Lin 
GPG Fingerprint:  4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7

signature.asc
Description: OpenPGP digital signature

Bug#1020043: pillow: FTBFS: ModuleNotFoundError: No module named 'PIL'

[Nilesh Patra]

Control: tags -1 patch

Hi,

Please consider applying the patch pasted inline if deemed appropriate.
I confirm that it fixes the build locally for me.

Thanks!

diff --git a/debian/rules b/debian/rules
index 68e9a8c..96cc5ca 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,7 +23,7 @@ build-indep: build build-doc-stamp
 build: build-stamp
 
 build-doc-stamp: build
-   -PYTHONPATH=$(CURDIR)/$(wildcard build/lib.*-$(PY3VER)) $(MAKE) -C docs 
html
+   -PYTHONPATH=$(CURDIR)/$(wildcard build/lib.*) $(MAKE) -C docs html
touch $@
 
 build-stamp: $(PY3VERS:%=build-stamp-python%) $(PY3VERS:%=check-stamp-python%)


signature.asc
Description: PGP signature

Bug#1021714: lists.debian.org: Request for new mailing list: collab-maint (was: Evolving away from source package realms)

[Santiago Ruano Rincón]

Package: lists.debian.org
Severity: wishlist

Dear list masters and fellow Debian peers,

I hereby would like to propose to create a mailing list for
collaborative maintenance.

Name: debian-collab-maint

Rationale:

El 13/10/22 a las 07:02, Tobias Frost escribió:
> On Wed, Oct 12, 2022 at 04:09:54PM -0700, Russ Allbery wrote:
> 
> > Is there some way right now for me to say "any Debian contributor with
> > upload rights should feel free to merge changes and upload this package
> > without needing to consult me at all, and I will subscribe to the packages
> > feed for the package and say something if something happens that I don't
> > like" with a packaging repository on Salsa?  And if not, would that be a
> > good way to start?
> 
> In my understanding this is exactly the purpose of the Debian group on salsa.
> As [1] says:
>  Direct commits to repositories in the Debian group by any Debian developer 
> are
>  implicitly welcome. No pre-commit coordination (e.g. merge-request or mail) 
> is
>  expected.
> 
> [1] 
> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

Other than the salsa Debian group, I think it would be useful to have a
mailing list to share the responsibility of packages, and at the same
time, reduce the personal "ownership" of them. Packages with Maintainer:
debian-collab-ma...@lists.debian.org are declared to have an open an
collaborative maintenance. Rules are yet to be defined and discussed
within the project (following this thread?). In any case, concerned
packages have to be in the Salsa Debian group. However, it should be
optional for packages in the Salsa Debian group to have Maintainer:
d-c-m@l.d.o.

This mailing list would also make it possible to follow and keep track
of bugs and etc of the related packages. I am aware it is currently
possible to individually subscribe to a package's tracker, but the scope
is different from a collaborative maintenance.


Short Description: Debian Collaborative Package Maintenance

Long Description:
List for collaborative maintenance of packages in the Salsa Debian
group:
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

Category: Developers

Subscription Policy: Open

Post Policy: Open

Web Archive: yes

thanks,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[наб]

Hi!

On Thu, Oct 13, 2022 at 01:55:42PM +0200, Joost van Baal-Ilić wrote:
> https://dyn.manpages.debian.org/faq.html redirects here to
> https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html which I asssume
> is build from  avr-libc 1:2.0.0+Atmel3.6.2-1.1 .  I guess you'd have to report
> a bug to avr-libc.  *But* I can't find any of the problems you've found in the
> webpage @ https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html 

Of course it does. I even got this once while testing.
This is a caching issue ‒ for me it shows the Manpages FAQ,
and if I Ctrl-Shift-R it shows the avr-libc FAQ(3) like it does for you.

So this is another bug, I guess, since the top bar links to
dyn.m.d.o/faq.html instead of the correct dyn.-free page on the error
pages for example (i got there from the nonexistent m.d.o/unrar, which
redirected me to dyn.m.d.o/unrar to show me the 404).

My report concerns the Debian Manpages FAQ with canonical URL
  https://manpages.debian.org/faq.html
(at least I hope that's the canonical URL!)

Best,
наб


signature.asc
Description: PGP signature

Bug#1021709: manpages.debian.org: FAQ is full of deadlinks, incl. to the static assets repo

[Joost van Baal-Ilić]

Hi наб,

Thanks for your report!

On Thu, Oct 13, 2022 at 01:26:24PM +0200, наб wrote:
> Package: manpages.debian.org
> Severity: normal
> 
> Dear Maintainer,
> 
> https://dyn.manpages.debian.org/faq.html:
>   source code: 
> https://anonscm.debian.org/git/collab-maint/debian-goodies.git/plain/dman?id=19924c907a8b907eaea3c0d942c5ae780ef6111e
>   static assets repository: 
> https://anonscm.debian.org/git/srv-manpages/debian-assets.git/
>   hosted on Alioth: 
> https://anonscm.debian.org/git/srv-manpages/debian-assets.git/
>404, AIUI anonscm/alioth has been dead for years
> 
>   Alioth project: https://alioth.debian.org/projects/srv-manpages/
>   doesn't even resolve
> 
>   mdocml: http://mdocml.bsd.lv/
>   Report at mdocml: http://mdocml.bsd.lv/contact.html
>   it's been mandoc for close to a decade, and should be
>   mandoc: https://mandoc.bsd.lv/
>   Report at mandoc: http://mandoc.bsd.lv/contact.html
> 
> I'd post a patch, but, well. No clue what against, given the givens.

https://dyn.manpages.debian.org/faq.html redirects here to
https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html which I asssume
is build from  avr-libc 1:2.0.0+Atmel3.6.2-1.1 .  I guess you'd have to report
a bug to avr-libc.  *But* I can't find any of the problems you've found in the
webpage @ https://manpages.debian.org/bullseye/avr-libc/FAQ.3avr.en.html 

Bye,

Joost

Bug#1021713: CalyxOS cannot be installed from Debian 11 since it has very old fastboot version

[Tom]

Package: android-sdk-platform-tools
Version: 28.0.2+7

I am an Android developer and turns out that with current version of 
android-sdk-platform-tools [from March 
2019](https://developer.android.com/studio/releases/platform-tools.html#2802_march_2019)
 I get errors trying to use CalyxOS installer with the error:

```
fastboot too old; please download the latest version at 
https://developer.android.com/studio/releases/platform-tools.html
```

After digging into the installer I discovered that the minimum version required 
is 31.03, and current is 33.0.3 from Aug 2022. Is there a way to bump the 
version on sid so ROM developers don't get blocked by it?

Kind regards,
staticxor

Bug#1021712: gltron: segfaults on Alt+F4 (with libsdl1.2debian) or hangs on Alt+F4 (with libsdl1.2-compat)

[Simon McVittie]

Package: gltron
Version: 0.70final-12.4
Severity: normal
Tags: upstream

To reproduce:

* run gltron
* use your desktop environment or window manager's keyboard shortcut for
  closing the window, normally Alt+F4

Expected result: the game quits gracefully.

Actual result (with libsdl1.2debian): the game crashes with a segmentation
fault.

Actual result (with libsdl1.2-compat-shim, or with libsdl1.2-compat
1.2.58-1 added to the LD_LIBRARY_PATH): the game hangs indefinitely,
becomes unresponsive to SIGINT and SIGTERM, and must be killed with
SIGKILL or similar.

I reported this to sdl12-compat upstream while testing various Debian
games' compatibility with sdl12-compat, and sdl12-compat maintainer
Ryan C. Gordon diagnosed the problem as follows:

> This happens in glTron because it gets the SDL_QUIT event [...]
> which calls [SDL_Quit()] but never sets return_code to exit the loop. It
> should probably just do that and not call SystemExit, as I assume leaving
> this loop will do that too without risking another call into SDL.
>
> In real 1.2, it eventually calls SDL_GL_SwapBuffers after that SDL_Quit
> and dereferences a NULL pointer; in sdl12-compat, we just keep ending
> up back in current->idle() calling SDL_Delay() without crashing.

(See https://github.com/libsdl-org/sdl12-compat/issues/237)

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
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 gltron depends on:
ii  libc62.35-3
ii  libgcc-s112.2.0-3
ii  libgl1   1.5.0-1
ii  libpng16-16  1.6.38-2
ii  libsdl-sound1.2  1.0.3-9+b1
ii  libsdl1.2debian  1.2.15+dfsg2-8
ii  libstdc++6   12.2.0-3
ii  zlib1g   1:1.2.11.dfsg-4.1

gltron recommends no packages.

gltron suggests no packages.

-- no debconf information

Bug#1021576: can't have both LIME and LIME X3DH enabled at the same time

[ael]

Another gdb log after installing liblinphone*10-dbgsym*.

one line that may be relevant is

#5  0x77b37798 in bctbx_fatal(char const*, ...)
(fmt=fmt@entry=0x77bc1670 "You can't have both LIME and LIME X3DH 
enabled at the same time !\nConflicting settings are [sip] lime and [lime] 
lime_server_url")
at /usr/include/bctoolbox/logging.h:245

This is another quick and dirty interim report for now...

ael

Temporary breakpoint 1 at 0xd9180: file ./linphone-app/src/app/main.cpp, line 
30.
Starting program: /usr/bin/linphone 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe1b8) at 
./linphone-app/src/app/main.cpp:30
30  ./linphone-app/src/app/main.cpp: No such file or directory.
Continuing.
[New Thread 0x7fffe81ff640 (LWP 13609)]
[New Thread 0x7fffe57ff640 (LWP 13610)]
[New Thread 0x7fffe4ffe640 (LWP 13611)]
[New Thread 0x7fffd7dff640 (LWP 13612)]
[New Thread 0x7fffd75fe640 (LWP 13613)]
[New Thread 0x7fffd6dfd640 (LWP 13614)]
[New Thread 0x7fffd65fc640 (LWP 13615)]
[New Thread 0x7fffd5dfb640 (LWP 13616)]
[New Thread 0x7fffd55fa640 (LWP 13617)]
[New Thread 0x7fffd4df9640 (LWP 13618)]
[New Thread 0x7fffa640 (LWP 13619)]
[New Thread 0x7fffaf7fe640 (LWP 13620)]
[New Thread 0x7fffaeffd640 (LWP 13621)]
[New Thread 0x7fffae7fc640 (LWP 13622)]
[Thread 0x7fffae7fc640 (LWP 13622) exited]
[New Thread 0x7fffae7fc640 (LWP 13623)]

Thread 1 "linphone" received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.
#0  __pthread_kill_implementation
(threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0)
at ./nptl/pthread_kill.c:44
#1  0x748895df in __pthread_kill_internal (signo=6, threadid=)
at ./nptl/pthread_kill.c:78
#2  0x7483da02 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x74828469 in __GI_abort () at ./stdlib/abort.c:79
#4  0x77d0ca3f in  () at /lib/x86_64-linux-gnu/libbctoolbox.so.1
#5  0x77b37798 in bctbx_fatal(char const*, ...)
(fmt=fmt@entry=0x77bc1670 "You can't have both LIME and LIME X3DH 
enabled at the same time !\nConflicting settings are [sip] lime and [lime] 
lime_server_url")
at /usr/include/bctoolbox/logging.h:245
#6  0x77b4b5c6 in sip_config_read (lc=0x56435fc0)
at ./coreapi/linphonecore.c:1645
#7  _linphone_core_read_config(LinphoneCore*) (lc=0x56435fc0)
at ./coreapi/linphonecore.c:2336
#8  0x77b4cc6a in linphone_core_init(LinphoneCore*, LinphoneCoreCbs*, 
LinphoneConfig*, void*, bool_t, void*)
(lc=0x56435fc0, cbs=0x0, config=, userdata=, automatically_start=, system_context=)
at ./coreapi/linphonecore.c:2924
#9  0x77b4d109 in _linphone_core_new_with_config(_LinphoneCoreCbs*, 
_LpConfig*, void*, void*, unsigned char, unsigned char)
 (cbs=0x0, config=0x55f55c60, userdata=0x0, system_context=, automatically_start=, main_core=) at 
./coreapi/linphonecore.c:3021
#10 0x779c3a2c in 
LinphonePrivate::Factory::_createCore(_LinphoneCoreCbs*, char const*, char 
const*, void*, void*, unsigned char) const (this=, 
cbs=cbs@entry=0x0, config_path=, 
factory_config_path=0x55f59e00 "/usr/share/linphone/linphonerc-factory", 
user_data=user_data@entry=0x0, system_context=0x0, automatically_start=0 
'\000') at ./src/factory/factory.cpp:132
#11 0x779c3b29 in LinphonePrivate::Factory::createCore(char const*, 
char const*, void*) const (this=, config_path=, 
factory_config_path=, system_context=) at 
./src/factory/factory.cpp:179
#12 0x77f3c60d in 
linphone::Factory::createCore(std::__cxx11::basic_string, std::allocator > const&, 
std::__cxx11::basic_string, std::allocator > 
const&, void*) const (this=this@entry=0x562e1f50, 
configPath="/home/ael/.config/linphone/linphonerc", 
factoryConfigPath="/usr/share/linphone/linphonerc-factory", 
systemContext=systemContext@entry=0x0) at 
./obj-x86_64-linux-gnu/wrappers/cpp/src/linphone++.cc:4128
#13 0x556fa359 in CoreManager::createLinphoneCore(QString const&) 
(this=0x562c4b20, configPath=) at 
./linphone-app/src/components/core/CoreManager.cpp:234
#14 0x752ec852 in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x752dd0bd in QObject::event(QEvent*) () at 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x76162f4e in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x752b1618 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x753085c1 in QTimerInfoList::activateTimers() () at 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x75308e54 in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x713da739 in g_main_context_dispatch () at