Bug#1027286: bookworm: Please provide a symlink to the binary with a more memorable name (i.e. /usr/bin/bookworm)

[Christophe Lohr]

Hi,
  It would be nice to also do the same for its man page.
The current naming scheme is rather uncomfortable.

Best regards
Christophe

(ref: bookworm version 1.1.2+git20210715-4+b1)

Bug#1077064: reportbug: squid truncating large files with chunked transfer encoding

[Christophe Beauregard]

Package: squid
Version: 4.13-10+deb11u3
Severity: important
X-Debbugs-Cc: christophe.beaureg...@ec.gc.ca

Dear Maintainer,

I have a CGI script which serves up some larger (60+MB seems to be the
sweet spot) files via Apache through a squid caching reverse proxy. We've
recently been seeing those files being truncated (even when the content
doesn't change).

My hypothesis is the patch related to CVE-2023-46846 has either
broken chunked transfer encoding, or Apache is generating "bad" chunked
transfers which previous versions of squid were lax about handling.

I've reliably replicated the problem in a bullseye VM using fairly
minimal configurations:

/usr/lib/cgi-bin/bigfile.cgi:

#!/bin/sh

BS=16384
BC=4000
CL=`expr ${BS} \* ${BC}`
TF=/tmp/bigfile.out

if ! -f ${TF}
then
/usr/bin/dd bs=${BS} if=/dev/urandom of=${TF} count=${BC} 2>/dev/null

fi

/usr/bin/echo -e -n "Status: 200 OK\r\n"
/usr/bin/echo -e -n "Content-type: application/octet-stream\r\n"
/usr/bin/echo -e -n "Content-length: ${CL}\r\n"
/usr/bin/echo -e -n "Date: " `date -R -u` "\r\n"
/usr/bin/echo -e -n "\r\n"

exec /usr/bin/cat ${TF}

/etc/apache2/sites-enabled/test.conf:


ServerAdmin webmaster@localhost
DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Require all granted



cd /etc/apache2/mods-enabled/ && ln -s ../mods-available/cgi.load

/etc/squid/squid.conf:

access_log /var/log/squid/access.log squid
cache_log /var/log/squid/cache.log squid
cache_store_log none

icp_port 3130
coredump_dir /var/spool/squid
cache_mem 768 MB
cache_dir ufs /var/spool/squid 1024 16 256
memory_pools on

request_header_access X-Forwarded-Proto allow all
request_header_access Other deny all

cache_peer http-test parent 80 0 no-query originserver name=localaccel

acl our_sites dstdomain http-test
http_access allow our_sites
cache_peer_access localaccel allow our_sites

http_port 8080 accel vhost

restart apache2 and squid.

A normal request directly to Apache looks like:

test@http-test:~$ wget -Ox -S http://http-test:80/cgi-bin/bigfile.cgi
--2024-07-25 12:04:31--  http://http-test/cgi-bin/bigfile.cgi
Resolving http-test (http-test)... 127.0.1.1
Connecting to http-test (http-test)|127.0.1.1|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Thu, 25 Jul 2024 16:04:31 GMT
  Server: Apache/2.4.61 (Debian)
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Transfer-Encoding: chunked
  Content-Type: application/octet-stream
Length: unspecified [application/octet-stream]
Saving to: ‘x’

x   [  <=>   ]  62.50M   220MB/sin 0.3s

2024-07-25 12:04:32 (220 MB/s) - ‘x’ saved [65536000]

Same request through the reverse proxy:

test@http-test:~$ wget -Ox -S http://http-test:8080/cgi-bin/bigfile.cgi
--2024-07-25 12:05:01--  http://http-test:8080/cgi-bin/bigfile.cgi
Resolving http-test (http-test)... 127.0.1.1
Connecting to http-test (http-test)|127.0.1.1|:8080... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Thu, 25 Jul 2024 16:05:01 GMT
  Server: Apache/2.4.61 (Debian)
  Content-Type: application/octet-stream
  X-Cache: MISS from http-test
  X-Cache-Lookup: MISS from http-test:8080
  Transfer-Encoding: chunked
  Via: 1.1 http-test (squid/4.13)
  Connection: keep-alive
Length: unspecified [application/octet-stream]
Saving to: ‘x’

x   [<=> ]  62.50M  98.0MB/sin 0.6s

2024-07-25 12:05:02 (98.0 MB/s) - ‘x’ saved [65536000]

But sometimes, the request gets silently truncated:

test@http-test:~$ wget -Ox -S http://http-test:8080/cgi-bin/bigfile.cgi
--2024-07-25 12:05:52--  http://http-test:8080/cgi-bin/bigfile.cgi
Resolving http-test (http-test)... 127.0.1.1
Connecting to http-test (http-test)|127.0.1.1|:8080... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Thu, 25 Jul 2024 16:05:52 GMT
  Server: Apache/2.4.61 (Debian)
  Content-Type: application/octet-stream
  X-Cache: MISS from http-test
  X-Cache-Lookup: MISS from http-test:8080
  Transfer-Encoding: chunked
  Via: 1.1 http-test (squid/4.13)
  Connection: keep-alive
Length: unspecified [application/octet-stream]
Saving to: ‘x’

x   [ <=>]  10.33M  --.-KB/sin 0.1s

2024-07-25 12:05:54 (89.1 MB/s) - ‘x’ saved [10835159]

The rate of truncated requests is wildly variable. In my test VM it
might be 20% of the time, on our operational systems it's more like 80%.

When the request truncation happens, Apache sees it as a client disconnect
(add a %X to the Apache LogFormat). More interestingly, if you add a:

debug_options ALL,1 05,3 11,3

to squid.conf, the truncated downloads will start to spit out:

2024/07/25 12:10:48.122 

Bug#1075908: ITS: cairocffi

[Jean-Christophe Jaskula]

Hi Boyuan,

I’m not active in the Debian community and won’t be possible to find time to 
catch up and contribute again. Please move forward with your plan.

Best,
JC

> On Jul 7, 2024, at 1:28 PM, Boyuan Yang  wrote:
> 
> Source: cairocffi
> Severity: important
> Version: 1.7.1-1
> X-Debbugs-CC: jean.christophe.jask...@gmail.com
> 
> Dear Debian cairocffi package uploader,
> 
> According to information from https://tracker.debian.org/pkg/cairocffi , you
> are listed as the package uploader for Debian package cairocffi. However,
> package cairocffi saw no upload from you in the last 9 years (since 2015).
> As a result, I am filing an ITS (Intent to Salvage) request
> against your package according to section 5.12 in Debian's Developers'
> Reference [1].
> 
> As seen from DDPO page [2], it seems that package cairocffi is the only 
> Debian package
> that you are listed as maintainer or uploader. As a result, I am wondering 
> whether
> you are still active in the Debian activity.
> 
> Please feel free to let me know whether you still would like to list yourself 
> in the
> cairocffi package uploaders list. If yes, I will be happy to reconfirm your 
> package
> maintainership. If there is no response in 21 days (by July 28, 2024), I will 
> make
> a Debian package upload to remove your name from the package uploaders list. 
> After
> that, you are still welcome to contribute to Debian project as a regular 
> contributor.
> 
> Thanks and looking forward to your reply,
> 
> Best Regards,
> Boyuan Yang
> 
> [1]
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> [2] 
> https://qa.debian.org/developer.php?email=jean.christophe.jaskula%40gmail.com

Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

[Christophe Trophime]

Indeed, it seems that I have tweeked my debian box for nvidia-docker at the 
time.
In /etc/default/grub:

# Add this line for nvidia-docker
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

Christophe TROPHIME 
Research Engineer 

CNRS - LNCMI 
25, rue des Martyrs 
BP 166 
38042 GRENOBLE Cedex 9 
FRANCE 

Tel : +33 (0)4 76 88 90 02 
Fax : +33 (0) 4 76 88 10 01 
Office U 19 
M@il : christophe.troph...@lncmi.cnrs.fr

- Original Message -
> From: "Luca Boccassi" 
> To: "Christophe Trophime" 
> Cc: 1072...@bugs.debian.org
> Sent: Monday, June 3, 2024 7:33:45 PM
> Subject: Re: systemd: On a debian trixie, after upgrading systemd to latest 
> version the system fails to reboot.

> On Mon, 3 Jun 2024 at 18:29, Christophe Trophime
>  wrote:
>>
>> Hi,
>> could you please just tell what info do you need?
> 
> As already mentioned: did you customize the kernel command line?
> Cgroupsv2 has been the default for years
> 
>> - Original Message -
>> > From: "Luca Boccassi" 
>> > To: 1072...@bugs.debian.org
>> > Cc: "Christophe Trophime" 
>> > Sent: Monday, June 3, 2024 6:53:19 PM
>> > Subject: Re: systemd: On a debian trixie, after upgrading systemd to latest
>> > version the system fails to reboot.
>>
>> > Control: tags -1 moreinfo
>> >
>> > On Mon, 03 Jun 2024 18:41:12 +0200 Christophe Trophime
>> >  wrote:
>> >> Package: systemd
>> >> Version: 256~rc3
>> >> Severity: important
>> >> X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr
>> >>
>> >> Dear Maintainer,
>> >>
>> >> After upgrading systemd the machine does not reboot.
>> >> The error message says:
>> >>
>> >> systemd freezing execution
>> >> refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
>> >> shall be passed to kernel command line
>> >>
>> >>
>> >> As far as I have understood cgroup v1 is no longer supported.
>> >> So I think I have 2 choices:
>> >> * add the variable to the kernel starting command line,
>> >> * disable cgroup v1
>> >>
>> >> The point is that I cannot figure out how to do?
>> >> Cannot find how to set the variable, nor how to eventually disable
>> >> cgroup v1?
>> >>
>> >> Which packages may use the cgroup v1 features?
>> >> I'm using container tools like docker (nvidia-container), singularity
>> > and charliecloud
>> >>
>> >> Thanks for your help
>> >> Best
>> >> C
>> >>
>> >> PS: cannot provide any additional info about my debian trixie host.
>> >
>> > cgroupsv2 is the default and has been since Bookworm, did you apply
>> > some custom kernel command line that disables it?
>> >
>> > --
>> > Kind regards,
> > > Luca Boccassi


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

[Christophe Trophime]

Package: systemd
Version: 256~rc3
Severity: important
X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr

Dear Maintainer,

After upgrading systemd the machine does not reboot.
The error message says:

systemd freezing execution
refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
shall be passed to kernel command line


As far as I have understood cgroup v1 is no longer supported.
So I think I have 2 choices:
* add the variable to the kernel starting command line,
* disable cgroup v1

The point is that I cannot figure out how to do?
Cannot find how to set the variable, nor how to eventually disable
cgroup v1?

Which packages may use the cgroup v1 features?
I'm using container tools like docker (nvidia-container), singularity and 
charliecloud

Thanks for your help
Best
C

PS: cannot provide any additional info about my debian trixie host.

Bug#1071441: sway: can't launch x11 apps on vmware virtualmachine

[Christophe LELOUP]

Package: sway
Version: 1.9-1+b1
Severity: important
X-Debbugs-Cc: leloup.christophe+poube...@gmail.com

Dear Maintainer,

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

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   i launch xeyes

   * What was the outcome of this action?

   sway crash

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


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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 sway depends on:
ii  libc62.38-11
ii  libcairo21.18.0-3+b1
ii  libevdev21.13.1+dfsg-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-1
ii  libgl1-mesa-dri  24.0.7-1
ii  libglib2.0-0t64  2.80.2-1
ii  libinput10   1.25.0-1+b2
ii  libjson-c5   0.17-1+b1
ii  libpango-1.0-0   1.52.2+ds-1
ii  libpangocairo-1.0-0  1.52.2+ds-1
ii  libpcre2-8-0 10.42-4+b1
ii  libpixman-1-00.42.2-1+b1
ii  libsystemd0  255.5-1
ii  libudev1 255.5-1
ii  libwayland-client0   1.22.0-2.1+b1
ii  libwayland-cursor0   1.22.0-2.1+b1
ii  libwayland-server0   1.22.0-2.1+b1
ii  libwlroots12t64  0.17.1-2.1
ii  libxcb-icccm40.4.1-1.1+b1
ii  libxcb1  1.15-1
ii  libxkbcommon01.6.0-1+b1
ii  polkitd  124-2
ii  swaybg   1.2.1-1

Versions of packages sway recommends:
ii  foot  1.17.2-2
ii  sway-backgrounds  1.9-1
ii  wmenu 0.1.7-1

Versions of packages sway suggests:
pn  swayidle
pn  swaylock
pn  xdg-desktop-portal-gtk  
pn  xdg-desktop-portal-wlr  

-- no debconf information

Bug#1070684: lightdm-settings: Rename to lightdm-slick-greeter-settings

[Christophe Lohr]

Package: lightdm-settings
Version: 2.0.1-1
Severity: wishlist
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,
  May I suggest to rename lightdm-settings (tool & package) to something like
"lightdm-slick-greeter-settings"

Indeed, as it can be confirmed by the code itself, this GUI aims to guide user
to configure "/etc/lightdm/slick-greeter.conf".
With its current name, it may lead users to believe that they can configure
lightdm as a whole.
This may be the case in the future, but it is not its current functionality.

So, to avoid this confusion and to be consistent with other similar tools (eg.
lightdm-gtk-greeter-settings), I propose renaming it to lightdm-slick-greeter-
settings

Best regards


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'oldstable-updates'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lightdm-settings depends on:
ii  pkexec124-2
ii  python3   3.11.8-1
ii  python3-setproctitle  1.3.3-1+b2
ii  python3-xapp  2.4.1-1
ii  slick-greeter 2.0.1-1+b3

Versions of packages lightdm-settings recommends:
ii  numlockx  1.2-9

Versions of packages lightdm-settings suggests:
pn  onboard  

-- no debconf information

Bug#1069159: systemd-timesyncd: Getting TAI time?

[Christophe Lohr]

Package: systemd-timesyncd
Version: 255.4-1
Severity: normal
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,
  by default, timesyncd does not seem to provide TAI time to the system
(see  https://www.bortzmeyer.org/tai-on-debian.html)

Is there something to do for that?

Best regards


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'proposed-updates'), (500, 'oldstable-updates'), (500, 'oldoldstable-updates'), 
(500, 'oldoldstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 systemd-timesyncd depends on:
ii  libc6  2.37-15
ii  libsystemd-shared  255.4-1
ii  systemd255.4-1

systemd-timesyncd recommends no packages.

systemd-timesyncd suggests no packages.

-- no debconf information

Bug#1069134: libsundials-dev: Wrong path for klu.h

[Christophe TROESTLER]

Package: libsundials-dev
Version: 6.4.1+dfsg1-3+b3
Severity: normal
X-Debbugs-Cc: none, Christophe Troestler 

Dear Maintainer,

When activating the KLU feature of sundials, the file

/usr/include/sunlinsol/sunlinsol_klu.h

is read.  On line 34, there is

#include 

but, even with suitesparse installed, that file is not found.  It must be 
changed into

#include 

Best regards,
Christophe


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (400, 'unstable'), 
(300, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libsundials-dev depends on:
ii  cmake  3.28.3-1
ii  gfortran   4:13.2.0-7
ii  libhypre-dev   2.28.0-8
ii  libsundials-arkode56.4.1+dfsg1-3+b3
ii  libsundials-cvode6 6.4.1+dfsg1-3+b3
ii  libsundials-cvodes66.4.1+dfsg1-3+b3
ii  libsundials-ida6   6.4.1+dfsg1-3+b3
ii  libsundials-idas5  6.4.1+dfsg1-3+b3
ii  libsundials-kinsol66.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-hypre66.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-mpi6  6.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-openmp6   6.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-petsc66.4.1+dfsg1-3+b3
ii  libsundials-nvecparallel-pthread6  6.4.1+dfsg1-3+b3
ii  libsundials-nvecserial66.4.1+dfsg1-3+b3
ii  libsundials-sunlinsol3 6.4.1+dfsg1-3+b3
ii  libsundials-sunmatrix4 6.4.1+dfsg1-3+b3
ii  mpi-default-dev1.15
ii  petsc-dev  3.19.6+dfsg1-2
ii  pkg-config 1.8.1-1+b2
ii  pkgconf [pkg-config]   1.8.1-1+b2

libsundials-dev recommends no packages.

libsundials-dev suggests no packages.

-- no debconf information

Bug#927200: emacs-gtk: Frames automatically resize

[Christophe TROESTLER]

Package: emacs-gtk
Version: 1:29.2+1-2
Severity: normal
X-Debbugs-Cc: none, Christophe Troestler 

I experience the same behavior with Gtk Emacs 29.2 under X11.  The lisp 
function `set-frame-size` works as expected however.

Best,
C.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (400, 'unstable'), 
(300, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common 1:29.2+1-2
ii  emacs-common 1:29.2+1-2
ii  libacl1  2.3.2-1
ii  libasound2   1.2.10-3
ii  libc62.37-15
ii  libcairo21.18.0-1+b1
ii  libdbus-1-3  1.14.10-4
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b1
ii  libgccjit0   14-20240201-3
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3+b1
ii  libgif7  5.2.2-1
ii  libglib2.0-0 2.78.4-1
ii  libgmp10 2:6.3.0+dfsg-2+b1
ii  libgnutls30  3.8.3-1
ii  libgpm2  1.20.7-11
ii  libgtk-3-0   3.24.41-1
ii  libharfbuzz0b8.3.0-2
ii  libice6  2:1.0.10-1
ii  libjansson4  2.14-2+b2
ii  libjpeg62-turbo  1:2.1.5-2+b2
ii  liblcms2-2   2.14-2+b1
ii  libm17n-01.8.4-1+b1
ii  libotf1  0.9.16-4
ii  libpango-1.0-0   1.52.0+ds-1
ii  libpng16-16  1.6.43-1
ii  librsvg2-2   2.54.7+dfsg-2
ii  libselinux1  3.5-2
ii  libsm6   2:1.2.3-1
ii  libsqlite3-0 3.45.1-1
ii  libsystemd0  255.4-1
ii  libtiff6 4.5.1+git230720-4
ii  libtinfo66.4+20240113-1
ii  libtree-sitter0  0.20.8-2+b1
ii  libwebpdecoder3  1.3.2-0.4
ii  libwebpdemux21.3.2-0.4
ii  libx11-6 2:1.8.7-1
ii  libxcomposite1   1:0.4.5-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxi6   2:1.8.1-1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1.3+b2
ii  libxrandr2   2:1.5.4-1
ii  libxrender1  1:0.9.10-1.1
ii  zlib1g   1:1.3.dfsg-3+b1

Versions of packages emacs-gtk recommends:
ii  fonts-noto-color-emoji  2.042-1

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:29.3+1-1

-- no debconf information

Bug#1064065: libcap2-bin: captree is not packaged

[Christophe Lohr]

Package: libcap2-bin
Version: 1:2.66-5
Severity: minor

Dear Maintainer,
  Please note that the captree tool is not packaged (despite the presence of
the man page).

Best regards
Christophe


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

Kernel: Linux 6.6.13-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libcap2-bin depends on:
ii  libc62.37-15
ii  libcap2  1:2.66-5

Versions of packages libcap2-bin recommends:
ii  libpam-cap  1:2.66-5

libcap2-bin suggests no packages.

-- no debconf information

Bug#1042866: planner: Frequent segmentation faults

[Christophe Noisel]

fix have been merged : 
https://gitlab.gnome.org/World/planner/-/commit/cfca49c41c3368700f519b7e4c388037eaa6f048

Should be available at next release. Let me know if there's still an issue 
after update.

Bug#1026848: apt-cacher-ng: Two fixes for erroneous tagging

[Christophe Le Roy]

Package: apt-cacher-ng
Version: 3.7.4-1+b2
Followup-For: Bug #1026848
X-Debbugs-Cc: christophe.f...@gmail.com

Dear Maintainer,

This issue affects me as well.

For example, just after installing bookworm using apt-cacher-ng, the
maintenance web page wants to remove currently up-to-date packages.

Hopefully, exStartTradeOff parameter prevents this, but it won't last forever.

Cheers,
Christophe


-- Package-specific info:

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

Kernel: Linux 6.1.0-13-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 apt-cacher-ng depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.22
ii  libbz2-1.0 1.0.8-5+b1
ii  libc-ares2 1.18.1-3
ii  libc6  2.36-9+deb12u3
ii  libevent-2.1-7 2.1.12-stable-8
ii  libevent-pthreads-2.1-72.1.12-stable-8
ii  libfuse2   2.9.9-6+b1
ii  libgcc-s1  12.2.0-14
ii  liblzma5   5.4.1-0.2
ii  libssl33.0.11-1~deb12u2
ii  libstdc++6 12.2.0-14
ii  libsystemd0252.17-1~deb12u1
ii  libwrap0   7.6.q-32
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20230311

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.8-10
pn  doc-base  

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission non accordée: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
* apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/port: keep
  apt-cacher-ng/bindaddress: keep
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/gentargetmode: No automated setup
  apt-cacher-ng/proxy: keep

Bug#1042866: Frequent segmentation faults

[Christophe Noisel]

Hello,
thank you for reporting this.
I can reproduce the crash with both the current package and the last commit on 
the project git. Hopefully I'll fix this soon and will report here when merged 
with the main branch.

Christophe

Bug#1052033: davmail: Davmail uses too much memory

[Christophe TROESTLER]

Package: davmail
Version: 6.1.0.3423-4
Severity: normal
X-Debbugs-Cc: none, Christophe Troestler 

Dear Maintainer,

Upon launch Davmail uses 7.5GiB of virtual memory and 107.8MiB of resident 
memory but, after using it for about a day, 7.6GiB of virtual memory and 686MiB 
of resident memory.  Given that davmail only needs to keep a very small state, 
that seems to point to a memory leak.

As a complement of information:

java --version
openjdk 17.0.9-ea 2023-10-17
OpenJDK Runtime Environment (build 17.0.9-ea+4-Debian-1)
OpenJDK 64-Bit Server VM (build 17.0.9-ea+4-Debian-1, mixed mode, sharing)

Best regards,
C.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (400, 'unstable'), 
(300, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages davmail depends on:
ii  davmail-server  6.1.0.3423-4
ii  default-jre 2:1.17-74
ii  libopenjfx-java 11.0.11+1-3.1
ii  libswt-cairo-gtk-4-jni  4.26.0-1

davmail recommends no packages.

davmail suggests no packages.

-- no debconf information

Bug#1051472: Acknowledgement (xdg-desktop-portal-gnome fails to start on Gnome Wayland)

[Christophe Branchereau]

I've been able to solve the problem with an "apt install --reinstall
xdg-desktop-portal"

After that the service did restart ok, and xdg-desktop-portal-gnome
too, subsequently

So it's possible that this bug was only on my system due to something
local, and should be closed.

On Fri, Sep 8, 2023 at 3:36 PM Debian Bug Tracking System
 wrote:
>
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1051472: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051472.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
>   cbrancher...@gmail.com
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
>  Debian GNOME Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 1051...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1051472: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051472
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#1051472: xdg-desktop-portal-gnome fails to start on Gnome Wayland

[Christophe Branchereau]

Package: xdg-desktop-portal-gnome
Version: 44.2-2
Severity: important
X-Debbugs-Cc: cbrancher...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Apt-dist up grade upgraded the package to 44.2-2

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   * What was the outcome of this action?
the portal service does not start anymore

citral@ideapad:~$ systemctl status --user xdg-desktop-portal-gnome.service 
× xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)
 Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal-gnome.service; 
static)
 Active: failed (Result: signal) since Fri 2023-09-08 15:25:15 CEST; 6min 
ago
Process: 7539 ExecStart=/usr/libexec/xdg-desktop-portal-gnome (code=killed, 
signal=ABRT)
   Main PID: 7539 (code=killed, signal=ABRT)
CPU: 28ms

Sep 08 15:25:15 ideapad systemd[6365]: Starting 
xdg-desktop-portal-gnome.service - Portal service (GNOME implementation)...
Sep 08 15:25:15 ideapad xdg-desktop-portal-gnome[7539]: **
Sep 08 15:25:15 ideapad xdg-desktop-portal-gnome[7539]: 
ERROR:../src/externalwindow-wayland.c:291:init_external_window_wayland_display: 
assertion failed: (display)
Sep 08 15:25:15 ideapad xdg-desktop-portal-gnome[7539]: Bail out! 
ERROR:../src/externalwindow-wayland.c:291:init_external_window_wayland_display: 
assertion failed: (display)
Sep 08 15:25:15 ideapad systemd[6365]: xdg-desktop-portal-gnome.service: Main 
process exited, code=killed, status=6/ABRT
Sep 08 15:25:15 ideapad systemd[6365]: xdg-desktop-portal-gnome.service: Failed 
with result 'signal'.
Sep 08 15:25:15 ideapad systemd[6365]: Failed to start 
xdg-desktop-portal-gnome.service - Portal service (GNOME implementation).

   * What outcome did you expect instead?

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


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

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

Versions of packages xdg-desktop-portal-gnome depends on:
ii  dbus-user-session1.14.10-1
ii  dbus-x11 1.14.10-1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gsettings-desktop-schemas44.0-2
ii  libadwaita-1-0   1.4~beta-3
ii  libc62.37-7
ii  libcairo21.16.0-7
ii  libfontconfig1   2.14.2-4
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.77.2-1
ii  libgnome-bg-4-2  44.0-2
ii  libgnome-desktop-4-2 44.0-2
ii  libgtk-4-1   4.12.1+ds-2
ii  libwayland-client0   1.22.0-2
ii  libx11-6 2:1.8.6-1
ii  xdg-desktop-portal   1.17.2-1
ii  xdg-desktop-portal-gtk   1.14.1-1

Versions of packages xdg-desktop-portal-gnome recommends:
ii  gnome-settings-daemon  45~beta-1
ii  gnome-shell44.4-1

Versions of packages xdg-desktop-portal-gnome suggests:
ii  accountsservice  23.13.9-3
ii  evince   45~alpha-2

-- no debconf information

Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0

[Christophe Trophime]

- Original Message -
> From: "Gilles Filippini" 
> To: "Christophe Trophime" , "1042822" 
> <1042...@bugs.debian.org>
> Sent: Thursday, August 31, 2023 7:46:45 PM
> Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier 
> version aka 5.0.0

> Christophe Trophime a écrit le 31/08/2023 à 18:57 :
>> 
>> 
>> ----- Original Message -
>>> From: "Gilles Filippini" 
>>> To: "Christophe Trophime" ,
>>> 1042...@bugs.debian.org
>>> Sent: Thursday, August 31, 2023 6:47:36 PM
>>> Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier
>>> version aka 5.0.0
>> 
>>> Hi Christophe,
>>>
>>> Christophe Trophime a écrit le 01/08/2023 à 14:35 :
>>>> Source: med-fichier
>>>> Version: Please upgrade to 5.0.0 version
>>>> Severity: normal
>>>>
>>>> Dear Maintainer,
>>>>
>>>> It would be great if med was upgraded to enable use a Salome 9.11 generated
>>>> mesh files.
>>>
>>> Where is it downloadable from?
>> 
>>>From https://www.salome-platform.org/?page_id=2430.
>> I take a quick look at the sources. It requires a more recent hdf5 version 
>> (1.12
>> if I rember correctly).
> 
> This would be unfortunate. I didn't plan to ship HDF5 1.12 because this
> release is (or will soon be) retired by the HDF Group:
> https://portal.hdfgroup.org/display/support/Downloads

Could you check with med-fichier upstream if they support hdf5 1.14 or if it is 
planned
in a near future?

> 
>> I thought that Salome 9.11 was build on top of med 5 but this is not the 
>> case.
>> The upgrade is not urgent.. Maybe we shall contact Salome upstream to now 
>> when
>> they plan to upgrade to med 5
>> before moving on this issue.
>> 
>> Best
>> C
>> 
>>>
>>> Thx,
> >> _g.


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0

[Christophe Trophime]

- Original Message -
> From: "Gilles Filippini" 
> To: "Christophe Trophime" , 
> 1042...@bugs.debian.org
> Sent: Thursday, August 31, 2023 6:47:36 PM
> Subject: Re: Bug#1042822: med-fichier: Please upgrade to latest med-fichier 
> version aka 5.0.0

> Hi Christophe,
> 
> Christophe Trophime a écrit le 01/08/2023 à 14:35 :
>> Source: med-fichier
>> Version: Please upgrade to 5.0.0 version
>> Severity: normal
>> 
>> Dear Maintainer,
>> 
>> It would be great if med was upgraded to enable use a Salome 9.11 generated
>> mesh files.
> 
> Where is it downloadable from?

>From https://www.salome-platform.org/?page_id=2430.
I take a quick look at the sources. It requires a more recent hdf5 version 
(1.12 if I rember correctly).
I thought that Salome 9.11 was build on top of med 5 but this is not the case.
The upgrade is not urgent.. Maybe we shall contact Salome upstream to now when 
they plan to upgrade to med 5
before moving on this issue.

Best
C

> 
> Thx,
> _g.


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#970687: quodlibet: segfaults when playing any audio stream (Internet Radio)

[Christophe Alonso]

Dear maintainer,

it seems this bug does not appear anymore in 4.3.0-2 (Bookworm version). 
Both Radio Stations and podcasts are working just fine.


Sincerely,

Christophe

Bug#1042822: med-fichier: Please upgrade to latest med-fichier version aka 5.0.0

[Christophe Trophime]

Source: med-fichier
Version: Please upgrade to 5.0.0 version
Severity: normal

Dear Maintainer,

It would be great if med was upgraded to enable use a Salome 9.11 generated
mesh files.

Best
C.

Bug#1039559: lightdm does not start Xorg

[Christophe Lohr]

Le 04/07/2023 à 10:09, Yves-Alexis Perez a écrit :

Is
xserver-xorg-video-nouveau package installed? If not, can you install it
just to check if it does fix the problem (by not using fbdev)?


Bingo! You're right!
(Well, you're right all along actually... sorry for the inconvenience)

Actually, my Xorg used 'fbdev' instead of 'nouveau' because the 'nouveau 
kernel driver' was blacklisted for loading at boot,

probably due to some remnants of a past attempt with nvidia...

Now, lightdm reworks well!

(well, there are still questions on using lightdm with fbdev, but I 
leave this to experts ;-) )


Thank you for everything.
Best regards
Christophe

Bug#1039559: lightdm does not start Xorg

[Christophe Lohr]

Le 03/07/2023 à 21:54, Yves-Alexis Perez a écrit :

On Wed, 2023-06-28 at 09:06 +0200, Christophe Lohr wrote:
> X works well by itself. As a workaround, I'm now using gdm and 
Cinnamon (in

> place of lightdm an Mate, which have my preferences ;) )
>  (attached is the Xorg.0.log in this configuration)

According to the log you're using the fbdev userland driver. Not sure 
why it

doesn't work on LightDM though.


According to systemd, lightdm is running and seems happy.
except that it does not launch Xorg


    # systemctl status lightdm
    • lightdm.service - Light Display Manager
     Loaded: loaded (/lib/systemd/system/lightdm.service; enabled; 
preset: enabled)
     Active: active (running) since Tue 2023-07-04 08:47:59 CEST; 
20s ago

       Docs: man:lightdm(1)
       Main PID: 1364 (lightdm)
      Tasks: 3 (limit: 38290)
     Memory: 4.1M
    CPU: 42ms
     CGroup: /system.slice/lightdm.service
     └─1364 /usr/sbin/lightdm

    juil. 04 08:47:59 dyn-salsa-030 systemd[1]: Starting 
lightdm.service - Light Display Manager...
    juil. 04 08:47:59 dyn-salsa-030 systemd[1]: Started lightdm.service 
- Light Display Manager.



How to know more about it?
I have outputs by strace and ltrace if needed.
I expected to see any errors, or attempts for  execve( Xorg ...) or 
similar. But there's nothing.
Are there any dependencies between lightdm and other components? (eg. 
dbus plymouth etc.)


Best regards
Christophe

Bug#1039559: lightdm does not start Xorg

[Christophe Lohr]

Le 27/06/2023 à 18:07, Yves-Alexis Perez a écrit :

On Tue, 2023-06-27 at 09:10 +0200, Christophe Lohr wrote:
>   After a debian update this morning, I'm facing an unexpected problem:
> lightdm does not start Xorg!
> still the text console

> Xorg seems to work well by iteslf (xinit, xterm, xeyes ...)
> but lightdm does not launch it
> and no greeter also

> Suprisingly, there is no unusual error messages in lightdm.log
> (note that there is no Xorg.0.log since Xorg is not launched)
> Nothing remarkable in dmesg either

> So, I'm lost. How to investigate this issue?

Hi Christophe, it looks a lot like #1038611. Could you check if it's not a
duplicate, especially if you're using a binary proprietary driver like 
NVidia

or AMD?


Hi, Yves-Alexis
Many thanks for your answer. Indeed, the symptoms are very similar.
I also have a NVIDIA video card (GP107GL Quadro P400)
But I use the NOUVEAU driver.

X works well by itself. As a workaround, I'm now using gdm and Cinnamon 
(in place of lightdm an Mate, which have my preferences ;) )

(attached is the Xorg.0.log in this configuration)

I hop this can help.

Best regards
Christophe
[40.779] (--) Log file renamed from "/var/log/Xorg.pid-2430.log" to "/var/log/Xorg.0.log"
[40.780] 
X.Org X Server 1.21.1.7
X Protocol Version 11, Revision 0
[40.780] Current Operating System: Linux dyn-salsa-030 6.3.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.3.7-1 (2023-06-12) x86_64
[40.780] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.3.0-1-amd64 root=UUID=29b11126-5426-4ae8-977f-72451484759e ro quiet
[40.781] xorg-server 2:21.1.7-3 (https://www.debian.org/support) 
[40.781] Current version of pixman: 0.42.2
[40.781] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[40.781] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[40.781] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 28 08:54:35 2023
[40.781] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[40.782] (==) No Layout section.  Using the first Screen section.
[40.782] (==) No screen section available. Using defaults.
[40.782] (**) |-->Screen "Default Screen Section" (0)
[40.782] (**) |   |-->Monitor ""
[40.783] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[40.783] (==) Automatically adding devices
[40.783] (==) Automatically enabling devices
[40.783] (==) Automatically adding GPU devices
[40.783] (==) Automatically binding GPU devices
[40.783] (==) Max clients allowed: 256, resource mask: 0x1f
[40.783] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[40.783] 	Entry deleted from font path.
[40.783] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[40.783] (==) ModulePath set to "/usr/lib/xorg/modules"
[40.783] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[40.783] (II) Loader magic: 0x5565d81eff00
[40.783] (II) Module ABI versions:
[40.783] 	X.Org ANSI C Emulation: 0.4
[40.783] 	X.Org Video Driver: 25.2
[40.783] 	X.Org XInput driver : 24.4
[40.783] 	X.Org Server Extension : 10.0
[40.785] (++) using VT number 1

[40.790] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c2
[40.798] (--) PCI:*(1@0:0:0) 10de:1cb3:1028:11be rev 161, Mem @ 0x9200/16777216, 0x8000/268435456, 0x9000/33554432, I/O @ 0x3000/128, BIOS @ 0x/131072
[40.799] (II) LoadModule: "glx"
[40.799] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[40.802] (II) Module glx: vendor="X.Org Foundation"
[40.802] 	compiled for 1.21.1.7, module version = 1.0.0
[40.802] 	ABI class: X.Org Server Extension, version 10.0
[40.948] (==) Matched nouveau as autoconfigured driver 0
[40.948] (==) Matched nv as autoconfigured driver 1
[40.948] (==) Matched modesetting as autoconfigured driver 2
[40.948] (==) Matched fbdev as autoconfigured driver 3
[40.948] (==) Matched vesa as autoconfigured driver 4
[40.948] (==) Assigned the driver to the xf86ConfigLayout
[40.948] (II) LoadModule: "nouveau"
[40.949] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[40.949] (II) Module nouveau: vendor="X.Org Foundation"
[40.949] 	compiled for 1.21.1.3, module version = 1.0.17
[40.949] 	Mo

Bug#1039579: gnome-terminal.wrapper does not support the '--' syntax itself

[Christophe Lohr]

Dear Simon,
  Thank you very much for your quick and comprehensive explanations. 
(Could be a manpage by itself!)


Indeed, I'm scripting some tasks needing a terminal in an agnostic way. 
So, 'x-terminal-emulator -e ...' is the best way for me.


I am grateful for your guidance.

Best regards,
Christophe

Le 27/06/2023 à 15:13, Simon McVittie a écrit :

On Tue, 27 Jun 2023 at 14:11:35 +0200, Christophe Lohr wrote:

   The code of this wrapper make several rearrangements to convert '-e' and '-x'
options into the '--' syntax, but it seems to not support itself the '--'
syntax on its command line. Isn't it?
Is this an oversight or I am wrong?
May I suggest adding support for "--"?

Please could you clarify why it would be useful for gnome-terminal.wrapper
to support the "--" syntax?

The only purpose of gnome-terminal.wrapper is to implement Debian's
x-terminal-emulator interface as defined in
<https://www.debian.org/doc/debian-policy/ch-customized-programs.html#packages-providing-a-terminal-emulator>,
which is a subset of xterm's command-line interface and therefore uses
"-e" to prefix a command to run. xterm does not support the GNU-style "--"
and there is no guarantee that an implementation of x-terminal-emulator
will support it either, so accepting it in gnome-terminal.wrapper
would just make it a bit more likely for people to write calls like
"x-terminal-emulator -- less /etc/hosts" which will actually only work
for a few specific terminal emulators.

If you're writing code that runs gnome-terminal (specifically) as a
subprocess, please use the gnome-terminal command and its preferred
"--" syntax.  There is no need to use the wrapper in this case, and in
fact it would be counterproductive to do so: all it does is to slow down
startup a little bit, and make some features unavailable.

If you're writing code that runs the generic x-terminal-emulator command
as a subprocess, then you will have to use the "-e" syntax, otherwise it
won't work correctly with xterm (and probably many other terminal emulators).

If you're writing code that supports multiple specific commands as ways
to run a command in a terminal, then it needs to "just know" whether
each one expects "-e", "-x", "--", or no argument at all. The table of
known terminals in
<https://gitlab.gnome.org/GNOME/glib/-/blob/2.76.3/gio/gdesktopappinfo.c#L2698>
is an example of this technique. Everyone involved recognises that this
is not a pleasant interface, but that's the price we pay for portability.

 smcv

Bug#1039579: gnome-terminal.wrapper does not support the '--' syntax itself

[Christophe Lohr]

Package: gnome-terminal
Version: 3.46.8-1
Severity: wishlist
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,
  The code of this wrapper make several rearrangements to convert '-e' and '-x'
options into the '--' syntax, but it seems to not support itself the '--'
syntax on its command line. Isn't it?
Is this an oversight or I am wrong?
May I suggest adding support for "--"?

Best regards
Christophe


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 
'oldstable-updates'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.8-1
ii  dbus-x11 [dbus-session-bus]   1.14.8-1
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gnome-terminal-data   3.46.8-1
ii  gsettings-desktop-schemas 43.0-1
ii  libatk1.0-0   2.48.3-1
ii  libc6 2.36-9
ii  libgcc-s1 13.1.0-6
ii  libglib2.0-0  2.74.6-2
ii  libgtk-3-03.24.37-2
ii  libpango-1.0-01.50.14+ds-1
ii  libstdc++613.1.0-6
ii  libuuid1  2.38.1-5+b1
ii  libvte-2.91-0 0.70.6-1
ii  libx11-6  2:1.8.6-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.50.4-2
ii  nautilus-extension-gnome-terminal  3.46.8-1
ii  yelp   42.2-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#1039559: lightdm does not start Xorg

[Christophe Lohr]

Package: lightdm
Version: 1.32.0-2
Severity: important
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,

  After a debian update this morning, I'm facing an unexpected problem: lightdm 
does not start Xorg!
still the text console

Xorg seems to work well by iteslf (xinit, xterm, xeyes ...)
but lightdm does not launch it
and no greeter also

Suprisingly, there is no unusual error messages in lightdm.log
(note that there is no Xorg.0.log since Xorg is not launched)
Nothing remarkable in dmesg either

So, I'm lost. How to investigate this issue?

Best regards
Christophe


-- System Information:
Debian Release: trixie/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'proposed-updates'), (500, 
'oldstable-updates'), (500, 'oldoldstable-updates'), (500, 'oldoldstable'), 
(500, 'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lightdm depends on:
ii  adduser3.134
ii  dbus   1.14.8-1
ii  debconf [debconf-2.0]  1.5.82
ii  libaudit1  1:3.0.9-1
ii  libc6  2.36-9
ii  libgcrypt201.10.2-2
ii  libglib2.0-0   2.74.6-2
ii  libpam-systemd [logind]252.11-1
ii  libpam0g   1.5.2-6
ii  libxcb11.15-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.8-3

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+23

Versions of packages lightdm suggests:
ii  accountsservice  22.08.8-6
ii  upower   0.99.20-2
ii  xserver-xephyr   2:21.1.7-3

-- Configuration Files:
/etc/pam.d/lightdm changed:
auth  requisite pam_nologin.so
session  required pam_env.so readenv=1
session  required pam_env.so readenv=1 envfile=/etc/default/locale
@include common-auth
-auth  optional pam_gnome_keyring.so
@include common-account
session  [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so close
session  requiredpam_limits.so
session  requiredpam_loginuid.so
@include common-session
session [success=ok ignore=ignore module_unknown=ignore default=bad] 
pam_selinux.so open
-session optionalpam_gnome_keyring.so auto_start
@include common-password
@include local-krb5


-- debconf information:
  lightdm/daemon_name: /usr/sbin/lightdm
* shared/default-x-display-manager: lightdm


-- lightdm.log
[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.32.0, UID=0 PID=4984
[+0.00s] DEBUG: Loading configuration dirs from 
/usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from 
/usr/share/lightdm/lightdm.conf.d/01_debian.conf
[+0.00s] DEBUG: Loading configuration dirs from 
/usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from 
/etc/lightdm/lightdm.conf.d/99-local.conf
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Registered seat module local
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: Using cross-namespace EXTERNAL authentication (this will 
deadlock if server is GDBus < 2.73.3)
[+0.00s] DEBUG: _g_io_module_get_default: Found default implementation local 
(GLocalVfs) for ‘gio-vfs’
[+0.00s] DEBUG: Monitoring logind for seats
[+0.00s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.01s] DEBUG: Loading users from org.freedesktop.Accounts
[+0.01s] DEBUG: User /org/freedesktop/Accounts/User1000 added
[+0.01s] DEBUG: User /org/freedesktop/Accounts/User1001 added
[+0.02s] DEBUG: User /org/freedesktop/Accounts/User1002 added
[+0.02s] DEBUG: User /org/freedesktop/Accounts/User1003 added
[+1.78s] DEBUG: Seat seat0 changes active session to 6
[+9.42s] DEBUG: Seat seat0 changes active session to 1


-- dmesg
[0.00] Linux version 6.3.0-1-amd64 (debian-ker...@lists.debian.org) 
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 
SMP PREEMPT_DYNAMIC Debian 6.3.7-1 (2023-06-12)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-6.3.0-1-amd64 
root=UUID=29b11126-5426-4ae8-977f-72451484759e ro quiet
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers

Bug#1034904: ImportError: cannot import name 'util' from 'distutils' (/usr/lib/python3.11/distutils/__init__.py)

[Christophe Alonso]

Installing python3-distutils solved the problem here. May be diffuse 
should depend on this package as well.




OpenPGP_0xF1596A7FBB6E093A.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

Reported to the GCC maintainers: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110156

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

I've managed to reproduce the bug in virtual machines (even on my laptop), in 
case anyone is curious to see it in action.

The magic configuration is to force the CPU topology to 
multiple-sockets-multiple-cores (the default KVM config is typically 
multiple-socket-single-core). The CPU model doesn't appear to matter. The leak 
obviously grows much more slowly than on my 2-socket-20-core server, but it's 
clearly visible.

From: Beauregard,Christophe (ECCC) 
Sent: Monday, June 5, 2023 12:44
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

I've managed to find a workaround. Not a great workaround, but it seems to let 
me take advantage of all cores for OMP without penalty. I'll be running some 
more tests on that.

The thread needs to call:

#include 
omp_pause_resource_all(omp_pause_soft);

at thread termination (a hard pause seens fine, too). The program needs to 
compiled with -fopenmp.

The call releases the TLS variables, and I believe that's what triggers the 
release of the memory mapped thread arena.

The downsides of that fix are (a) OMP doesn't get to share the thread pool 
across the program but instead blows it away for each thread the finishes, and 
(b) calling programs need to know stuff about the use of OMP at a level they 
really shouldn't need to know about.

It doesn't feel like something that can be shimmed into the GM API in a nice 
place, as IMHO there really isn't much other than Initialize/DestroyMagick() 
that should even care about crossing thread boundaries.

It's not entirely a new class of problem. For example, the issue that led me to 
trying the omp_pause_resource_all() call: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035

I still need to dig deeper as it's not clear to me why my particular machine is 
seeing the problem, but I certainly intend to follow up with gomp. I really 
hope it's a bug; a threading API that itself isn't thread-safe would just be... 
weird.

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

I've managed to find a workaround. Not a great workaround, but it seems to let 
me take advantage of all cores for OMP without penalty. I'll be running some 
more tests on that.

The thread needs to call:

#include 
omp_pause_resource_all(omp_pause_soft);

at thread termination (a hard pause seens fine, too). The program needs to 
compiled with -fopenmp.

The call releases the TLS variables, and I believe that's what triggers the 
release of the memory mapped thread arena.

The downsides of that fix are (a) OMP doesn't get to share the thread pool 
across the program but instead blows it away for each thread the finishes, and 
(b) calling programs need to know stuff about the use of OMP at a level they 
really shouldn't need to know about.

It doesn't feel like something that can be shimmed into the GM API in a nice 
place, as IMHO there really isn't much other than Initialize/DestroyMagick() 
that should even care about crossing thread boundaries.

It's not entirely a new class of problem. For example, the issue that led me to 
trying the omp_pause_resource_all() call: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035

I still need to dig deeper as it's not clear to me why my particular machine is 
seeing the problem, but I certainly intend to follow up with gomp. I really 
hope it's a bug; a threading API that itself isn't thread-safe would just be... 
weird.

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

FWIW, I think I may have figured out what's happening. It's probably something 
to note in the http://www.graphicsmagick.org/OpenMP.html documentation.

In a nutshell, my understanding is that libgomp keeps track of its thread pool 
in thread local storage. When that thread local storage happens to be in the 
main process, all is well, everything works fine, etc. When that thread local 
storage is in a transient pthread (and, apparently, you're running on a certain 
class memory/CPU configuration) and your transient thread terminates, that 
thread local storage doesn't (always) get cleaned up.

What this means in practice is making GM API calls from within a pthread can 
result in undefined behaviour when an API triggers OpenMP calls.

I suspect this isn't a particularly desirable situation, as GraphicsMagick 
appears to have put at least some effort into making the API thread-safe.

It likely means that even my mallopt(M_ARENA_MAX,n) fix is still not right, and 
the only "safe" solution is to disable OpenMP completely in that particular 
application.

I'm going to keep looking for a better workaround/mitigation. It would be ideal 
if there was a mechanism to keep the thread pool in the main process and still 
have it used from the subthread.

____
From: Beauregard,Christophe (ECCC) 
Sent: Monday, June 5, 2023 09:20
To: László Böszörményi (GCS) ; Bob Friesenhahn 
; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak



Never mind, you can close this. I've managed to reproduce the leak without GM:

/*
 * gcc -o gomparena gomparena.c -fopenmp
 */
#include 
#include 
#include 
#include 
#include 

static void* go_omp(void* arg) {
  const int m = 1024;
  double* a = alloca(m*sizeof(double));

  #pragma omp parallel for
  for( int n = 0; n < m; n ++ ) {
a[n] = n*n;
  }
  return NULL;
}

int main ( int argc, char **argv )
{
  int cycles = 10;

  while(cycles--) {
pid_t myp = getpid();
char s[1024];
#if 1
/* this code path has a thread arena leak */
pthread_t thread_id;
pthread_create(&thread_id, NULL, go_omp, NULL);

/* pthread_detach(thread_id); also shows the problem */
pthread_join(thread_id, NULL);
#else
/* this code path doesn't have a thread arena leak */
go_omp(NULL);
#endif

sleep(1);

fprintf(stderr,"%lld\n", (long long)time(0));
snprintf(s,sizeof(s),
  "ps -o vsz -o rss -o user -o command -p %lld", (long 
long)myp);
system(s);
snprintf(s,sizeof(s),
  "pmap -x %lld | grep 65404 | wc -l", (long long)myp);
system(s);
  }

  return 0;
}


From: Beauregard,Christophe (ECCC) 
Sent: Monday, June 5, 2023 08:58
To: László Böszörményi (GCS) ; Bob Friesenhahn 
; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

>Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile?

I'm not sure. It took me most of a week to even properly isolate the problem 
and find a repeatable test case on that one machine, and even then I feel like 
it's still a moving target.

I've done more poking and it's not 100% exclusive to GetImageDepth(). In fact, 
I'm seeing the problem now if I comment out the call to GetImageDepth() (but in 
my original application, ReadImage() without GetImageDepth() in another code 
path isn't enough to trigger the bug).

My working theory is something about how GM uses the OpenMP/libgomp API is 
tickling a bug in a code path that's only seen with certain CPU/memory configs.

The questions I can't answer are (a) is there possibly something 
incomplete/incorrect in how GM uses OpenMP which could lead to this sort of 
bug? and (b) just how deep does this rabbit hole go (glibc? kernel?)?

I'm starting to think that I might need to peel off a machine from the 
development cluster and investigate whether I can reproduce the error in a 
container, at which point I can play around with different configurations of 
libraries, compilers, etc.

c.

From: László Böszörményi (GCS) 
Sent: Sunday, June 4, 2023 06:25
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Cc: Beauregard,Christophe (ECCC) 
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

[You don't often get email from g...@debian.org. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Hi,

On Sat, Jun 3, 2023 at 8:30 PM Bo

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

Never mind, you can close this. I've managed to reproduce the leak without GM:

/*
 * gcc -o gomparena gomparena.c -fopenmp
 */
#include 
#include 
#include 
#include 
#include 

static void* go_omp(void* arg) {
  const int m = 1024;
  double* a = alloca(m*sizeof(double));

  #pragma omp parallel for
  for( int n = 0; n < m; n ++ ) {
a[n] = n*n;
  }
  return NULL;
}

int main ( int argc, char **argv )
{
  int cycles = 10;

  while(cycles--) {
pid_t myp = getpid();
char s[1024];
#if 1
/* this code path has a thread arena leak */
pthread_t thread_id;
pthread_create(&thread_id, NULL, go_omp, NULL);

/* pthread_detach(thread_id); also shows the problem */
pthread_join(thread_id, NULL);
#else
/* this code path doesn't have a thread arena leak */
go_omp(NULL);
#endif

sleep(1);

fprintf(stderr,"%lld\n", (long long)time(0));
snprintf(s,sizeof(s),
  "ps -o vsz -o rss -o user -o command -p %lld", (long 
long)myp);
system(s);
snprintf(s,sizeof(s),
  "pmap -x %lld | grep 65404 | wc -l", (long long)myp);
system(s);
  }

  return 0;
}

________
From: Beauregard,Christophe (ECCC) 
Sent: Monday, June 5, 2023 08:58
To: László Böszörményi (GCS) ; Bob Friesenhahn 
; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

>Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile?

I'm not sure. It took me most of a week to even properly isolate the problem 
and find a repeatable test case on that one machine, and even then I feel like 
it's still a moving target.

I've done more poking and it's not 100% exclusive to GetImageDepth(). In fact, 
I'm seeing the problem now if I comment out the call to GetImageDepth() (but in 
my original application, ReadImage() without GetImageDepth() in another code 
path isn't enough to trigger the bug).

My working theory is something about how GM uses the OpenMP/libgomp API is 
tickling a bug in a code path that's only seen with certain CPU/memory configs.

The questions I can't answer are (a) is there possibly something 
incomplete/incorrect in how GM uses OpenMP which could lead to this sort of 
bug? and (b) just how deep does this rabbit hole go (glibc? kernel?)?

I'm starting to think that I might need to peel off a machine from the 
development cluster and investigate whether I can reproduce the error in a 
container, at which point I can play around with different configurations of 
libraries, compilers, etc.

c.

From: László Böszörményi (GCS) 
Sent: Sunday, June 4, 2023 06:25
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Cc: Beauregard,Christophe (ECCC) 
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

[You don't often get email from g...@debian.org. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Hi,

On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn
 wrote:
> I am definitely able to confirm that memory consumption builds due to
> invoking GetImageDepth() via a POSIX thread.  The rate that it builds
> is image sensitive since some images cause GetImageDepth() to perform
> more OpenMP loops.
 Unfortunately I can not reproduce. My processor is an Intel K variant
CPU, six cores and twelve threads, 64 Gb of RAM.
GM is 1.3.40 with two security fixes backported, compiled with GCC
v12.2.0. Tried with three PNG images, all memory consumption is static
from the beginning. Do I need some special case of PNG files to
experience this issue?

> My own testing is under Ubuntu 20.04 using GCC 10.
 Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile? At least I do wonder why
this issue is CPU / machine dependent.

Regards,
Laszlo/GCS

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

>Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile?

I'm not sure. It took me most of a week to even properly isolate the problem 
and find a repeatable test case on that one machine, and even then I feel like 
it's still a moving target.

I've done more poking and it's not 100% exclusive to GetImageDepth(). In fact, 
I'm seeing the problem now if I comment out the call to GetImageDepth() (but in 
my original application, ReadImage() without GetImageDepth() in another code 
path isn't enough to trigger the bug).

My working theory is something about how GM uses the OpenMP/libgomp API is 
tickling a bug in a code path that's only seen with certain CPU/memory configs.

The questions I can't answer are (a) is there possibly something 
incomplete/incorrect in how GM uses OpenMP which could lead to this sort of 
bug? and (b) just how deep does this rabbit hole go (glibc? kernel?)?

I'm starting to think that I might need to peel off a machine from the 
development cluster and investigate whether I can reproduce the error in a 
container, at which point I can play around with different configurations of 
libraries, compilers, etc.

c.

From: László Böszörményi (GCS) 
Sent: Sunday, June 4, 2023 06:25
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Cc: Beauregard,Christophe (ECCC) 
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

[You don't often get email from g...@debian.org. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Hi,

On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn
 wrote:
> I am definitely able to confirm that memory consumption builds due to
> invoking GetImageDepth() via a POSIX thread.  The rate that it builds
> is image sensitive since some images cause GetImageDepth() to perform
> more OpenMP loops.
 Unfortunately I can not reproduce. My processor is an Intel K variant
CPU, six cores and twelve threads, 64 Gb of RAM.
GM is 1.3.40 with two security fixes backported, compiled with GCC
v12.2.0. Tried with three PNG images, all memory consumption is static
from the beginning. Do I need some special case of PNG files to
experience this issue?

> My own testing is under Ubuntu 20.04 using GCC 10.
 Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile? At least I do wonder why
this issue is CPU / machine dependent.

Regards,
Laszlo/GCS

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

And to answer the question about mtrace.

root@host:~# MALLOC_TRACE=mtrace.log  ./threadarena Zoom140.png
1685735077
   VSZ   RSS USER COMMAND
2312024 8124 root ./threadarena Zoom140.png
33
1685735078
   VSZ   RSS USER COMMAND
4605784 9684 root ./threadarena Zoom140.png
67
1685735079
   VSZ   RSS USER COMMAND
6899544 11232 root./threadarena Zoom140.png
101
1685735080
   VSZ   RSS USER COMMAND
9193304 12796 root./threadarena Zoom140.png
135
1685735081
   VSZ   RSS USER COMMAND
11487064 14328 root   ./threadarena Zoom140.png
169
1685735082
   VSZ   RSS USER COMMAND
13780824 15924 root   ./threadarena Zoom140.png
203
1685735084
   VSZ   RSS USER COMMAND
16074584 17424 root   ./threadarena Zoom140.png
237
1685735085
   VSZ   RSS USER COMMAND
18368344 19004 root   ./threadarena Zoom140.png
271
1685735086
   VSZ   RSS USER COMMAND
20662104 20536 root   ./threadarena Zoom140.png
305
1685735087
   VSZ   RSS USER COMMAND
20989784 21948 root   ./threadarena Zoom140.png
309
root@host:~# mtrace ./threadarena mtrace.log
- 0x7f31380008d0 Free 365 was never alloc'd 0x7f315afcc4d4
- 0x7f3150008a70 Free 367 was never alloc'd 0x7f315afcc4bb
- 0x7f3150006ed0 Free 369 was never alloc'd 0x7f315afcc4bb
- 0x7f3150008300 Free 370 was never alloc'd 0x7f315afcc4bb
- 0x7f3150008a90 Free 371 was never alloc'd 0x7f315afcc4bb
- 0x7f315000b350 Free 372 was never alloc'd 0x7f315afcc4bb
- 0x7f315000b150 Free 373 was never alloc'd 0x7f315afcc4bb
- 0x7f315000b050 Free 374 was never alloc'd 0x7f315afcc4bb
- 0x7f315000af50 Free 375 was never alloc'd 0x7f315afcc4bb
...
- 0x7f2c5000a610 Free 3839 was never alloc'd 0x7f315afcc4bb
- 0x7f2c50002d90 Free 3840 was never alloc'd 0x7f315afcc4bb
- 0x7f2c50007df0 Free 3842 was never alloc'd 0x7f315afcc4bb
- 0x7f2c50011940 Free 3843 was never alloc'd 0x7f315afcc4bb
- 0x7f2c50011ad0 Free 3844 was never alloc'd 0x7f315afcc4bb
- 0x7f2c5000a740 Free 3846 was never alloc'd 0x7f315afcc4bb
- 0x7f2c58d0 Free 3847 was never alloc'd 0x7f315afcc4d4

Memory not freed:
-
   Address Size Caller
0x555b1d8652d0 0xd0  at 0x7f315a4a90f9

There's a total of 514 "Free xxx was never alloc'd" messages, which doesn't 
match the thread arena leaks. It might match the total number of threads OpenMP 
might use, but it seems a bit off.

As an extra data point, restricting the number of OpenMP threads doesn't fix 
the problem:

root@host:~# OMP_NUM_THREADS=8 ./threadarena  Zoom140.png
1685735486
   VSZ   RSS USER COMMAND
345944  8324 root ./threadarena Zoom140.png
4
1685735487
   VSZ   RSS USER COMMAND
608088  9724 root ./threadarena Zoom140.png
7
1685735488
   VSZ   RSS USER COMMAND
870232 11156 root ./threadarena Zoom140.png
10
1685735489
   VSZ   RSS USER COMMAND
1132376 12556 root./threadarena Zoom140.png
13
1685735490
   VSZ   RSS USER COMMAND
1394520 13988 root./threadarena Zoom140.png
16
1685735491
   VSZ   RSS USER COMMAND
1656664 15388 root./threadarena Zoom140.png
19
1685735492
   VSZ   RSS USER COMMAND
1918808 16820 root./threadarena Zoom140.png
22
1685735493
   VSZ   RSS USER COMMAND
2180952 18220 root./threadarena Zoom140.png
25
1685735494
   VSZ   RSS USER COMMAND
2443096 19652 root./threadarena Zoom140.png
28
1685735495
   VSZ   RSS USER COMMAND
2705240 21052 root./threadarena Zoom140.png
31


From: Beauregard,Christophe (ECCC) 
Sent: Friday, June 2, 2023 15:32
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

I'm kind of stuck with this version of GM; my organization is currently 
tracking Debian LTS.

I suppose I should have added some more points... while digging into this I did 
run diagnostics under gdb on my "real" application.

The threads themselves are terminating correctly; there aren't any 
lingering/unjoined threads, and the internal pthreads cleanup routines are all 
being hit. No sign of any red flags.

Running with MAGICK_DEBUG=resource:

root@host:~# MAGICK_DEBUG=resource ./threadarena  Zoom140.png
18:46:16 0:0.000223  0.000u 2666849 
resource.c/InitializeMagickResources/447/Resource:
  Total physical memory 128776 MB (3298 pages and 4096 bytes per page)
18:46:16 0:0.000279  0.000u 2666849 
resource.c/InitializeMagickResources/615/Resource:
  40 CPU cores are available
18:46:16 0:0.000294  0.000u 2666849 
resource.c/InitializeMagickResources/644/Resource:
  System file open limits are 1024 soft, 1048576 hard
18:46:16 0:0.000306  0.000u 2666849 
resource.c/SetMagickResourceLimit/964/Resource:
  Set files resource limit to 256
18:46:16 0:0.000321  0.000u 26668

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

oot/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732755
   VSZ   RSS USER COMMAND
241172 127532 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732765
   VSZ   RSS USER COMMAND
241252 129068 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
==2674090==
==2674090== HEAP SUMMARY:
==2674090== in use at exit: 216 bytes in 2 blocks
==2674090==   total heap usage: 1,703 allocs, 1,701 frees, 17,954,690 bytes 
allocated
==2674090==
==2674090== 8 bytes in 1 blocks are still reachable in loss record 1 of 2
==2674090==at 0x483877F: malloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2674090==by 0x57B10F8: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2674090==by 0x57C1076: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2674090==by 0x57AF599: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2674090==by 0x400FFE1: call_init.part.0 (dl-init.c:72)
==2674090==by 0x40100E8: call_init (dl-init.c:30)
==2674090==by 0x40100E8: _dl_init (dl-init.c:119)
==2674090==by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)
==2674090==by 0x1: ???
==2674090==by 0x1FFF000786: ???
==2674090==by 0x1FFF000794: ???
==2674090==
==2674090== 208 bytes in 1 blocks are still reachable in loss record 2 of 2
==2674090==at 0x483877F: malloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==2674090==by 0x57B10F8: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2674090==by 0x57C063A: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2674090==by 0x57B1584: omp_set_num_threads (in 
/usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==2674090==by 0x49437BB: InitializeMagickResources (in 
/usr/lib/libGraphicsMagick-Q16.so.3.22.0)
==2674090==by 0x491117A: InitializeMagickEx (in 
/usr/lib/libGraphicsMagick-Q16.so.3.22.0)
==2674090==by 0x4911451: InitializeMagick (in 
/usr/lib/libGraphicsMagick-Q16.so.3.22.0)
==2674090==by 0x1093A6: main (in /root/threadarena)
==2674090==
==2674090== LEAK SUMMARY:
==2674090==definitely lost: 0 bytes in 0 blocks
==2674090==indirectly lost: 0 bytes in 0 blocks
==2674090==  possibly lost: 0 bytes in 0 blocks
==2674090==still reachable: 216 bytes in 2 blocks
==2674090== suppressed: 0 bytes in 0 blocks
==2674090==
==2674090== For lists of detected and suppressed errors, rerun with: -s
==2674090== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

So, that's... great. There are trivial increases in process heap use, but you 
have to expect that with valgrind. There are no thread arena leaks at all, and 
only a smattering of memory lost in initialization code.

Granted, the leaking thread arenas are memory mapped areas, so memcheck might 
not trigger on them. I might have a go at the valgrind-mmt fork unless someone 
has a better idea.

I was hoping another set of eyes could spot something trivial and obvious in 
how GetImageDepth() invokes/manages OpenMP, because the more I look at this bug 
the less I trust my sanity.

From: Bob Friesenhahn 
Sent: Friday, June 2, 2023 14:38
To: Beauregard,Christophe (ECCC) ; 
1037...@bugs.debian.org <1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

[You don't often get email from bfrie...@simple.dallas.tx.us. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Christophe,

It would be good to test a modern GM version which supports "resource
limited memory".  Probably Debian's 1.4 version supports that.

For a version which supports the resource limited memory allocator,
you can set 'MAGICK_DEBUG=resource' in the environment prior to
running the program.  This will cause very verbose output with a tally
similar to:

13:27:40 0:0.007952  0.050u 173194 resource.c/unknown/236/Resource:
   memory +65.2MiB/81.0MiB/39.0GiB
13:27:40 0:0.027664  0.190u 173194 resource.c/unknown/818/Resource:
   memory -3.3KiB/81.0MiB/39.0GiB
13:27:40 0:0.027692  0.190u 173194 resource.c/unknown/818/Resource:
.
.
.
13:27:40 0:0.033629  0.220u 173194 resource.c/unknown/818/Resource:
   memory -65.2MiB/0B/39.0GiB

The "0B" at the end means that at least as related to memory allocated
by the resource limited memory allocator (used only for non-public
allocations), there are no leaks.

The type of leak you seem to be finding is a thread-specific memory
allocation leak where a destructor did not fire to free the memory
when the thread quit.  I don't believe that GetImageDepth() uses
thread-specific memory but the "thread arena"s that you are talking
about likely do.

For allocations which specifically use a memory allocator, I have had
some good luck using Glibc's mtrace.

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, 
https://can01.s

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

Package: graphicsmagick
Version: 1.4+really1.3.36+hg16481-2+deb11u1
Severity: normal
Tags: upstream

The GraphicsMagick API has a thread arena and more general memory leak
somewhere in the GetImageDepth() API call, presumably a side-effect of
the OpenMP usage.

First, you need a server class system... a lot of beefy cores (i.e. I
can't reproduce it on my quad-core laptop), and possibly a lot of RAM
(128G on this one):

root@host:~# grep 'model name' /proc/cpuinfo |tail -1
model name  : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
root@host:~# grep processor /proc/cpuinfo |tail -1
processor   : 39

Then you need this test program:

root@host:~# cat threadarena.c
/*
 * gcc -o threadarena threadarena.c \
 *    `GraphicsMagick-config --cppflags --ldflags --libs`
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void* readimage(void* arg) {
  ImageInfo *imageInfo;
  ExceptionInfo exception;
  const char* filename = (const char*) arg;
  ImageCharacteristics chars;

  imageInfo=CloneImageInfo(0);
  GetExceptionInfo(&exception);

  (void) strncpy(imageInfo->filename, arg, MaxTextExtent-1 );

  Image *image = ReadImage(imageInfo, &exception);
  if (image == (Image *) NULL)
  {
CatchException(&exception);
perror("ReadImage");
  }

  GetImageDepth(image,&image->exception);

  DestroyImage(image);
  DestroyImageInfo(imageInfo);
  DestroyExceptionInfo( &exception );
  return NULL;
}

int main ( int argc, char **argv )
{
  const char* file = argv[1];
  if( file == NULL ) {
fprintf(stderr,"usage: %s \n", argv[0]);
return 1;
  }

  InitializeMagick(NULL);

  while(1) {
pid_t myp = getpid();
char s[PATH_MAX];
#if 1
/* this code path has a thread arena leak */
pthread_t thread_id;
pthread_create(&thread_id, NULL, readimage, argv[1]);

/* pthread_detach(thread_id); also shows the problem */
pthread_join(thread_id, NULL);
#else
/* this code path doesn't have a thread arena leak */
readimage(argv[1]);
#endif

sleep(1);

fprintf(stderr,"%lld\n", (long long)time(0));
snprintf(s,sizeof(s),
  "ps -o vsz -o rss -o user -o command -p %lld", (long 
long)myp);
system(s);
snprintf(s,sizeof(s),
  "pmap -x %lld | grep 65404 | wc -l", (long long)myp);
system(s);
  }

  DestroyMagick();

  return 0;
}

Compile and run the test program:

root@host:~# gcc -o threadarena threadarena.c `GraphicsMagick-config --cppflags 
--ldflags --libs`

root@host:~# ./threadarena  Zoom140.png
1685713732
   VSZ   RSS USER COMMAND
2443096 8248 root ./threadarena Zoom140.png
35
1685713734
   VSZ   RSS USER COMMAND
4802392 9816 root ./threadarena Zoom140.png
70
1685713735
   VSZ   RSS USER COMMAND
7161688 11352 root./threadarena Zoom140.png
105
1685713736
   VSZ   RSS USER COMMAND
9520984 12920 root./threadarena Zoom140.png
140
1685713737
   VSZ   RSS USER COMMAND
11880280 14456 root   ./threadarena Zoom140.png
175
1685713738
   VSZ   RSS USER COMMAND
14239576 16040 root   ./threadarena Zoom140.png
210
1685713739
   VSZ   RSS USER COMMAND
16598872 17608 root   ./threadarena Zoom140.png
245
1685713740
   VSZ   RSS USER COMMAND
18958168 19128 root   ./threadarena Zoom140.png
280
1685713741
   VSZ   RSS USER COMMAND
20989784 20660 root   ./threadarena Zoom140.png
310
1685713742
   VSZ   RSS USER COMMAND
20989784 22100 root   ./threadarena Zoom140.png
309
1685713743
   VSZ   RSS USER COMMAND
20989784 23492 root   ./threadarena Zoom140.png
308
1685713744
   VSZ   RSS USER COMMAND
20989784 24900 root   ./threadarena Zoom140.png
307
1685713745
   VSZ   RSS USER COMMAND
20989784 26292 root   ./threadarena Zoom140.png
306

As you can see, the number of thread arenas (65404 k mapped sections)
according to pmap grows dramatically with each invocation of
GetImageDepth(), and the virtual memory usage blows up to ~20G before
stabilizing. RSS also increases, albeit less dramatically, but eventually
the system does start to hit an OOM condition.

My understanding of malloc thread arenas is that new threads are supposed
to reuse the arenas, and only attempt to create new ones when an existing
arena is locked, so I assume that's what's happening here. And I also assume
there's some missing housekeeping that's also leaking RSS memory.

Some fun facts about the bug:

1. so far, only GetImageDepth() triggers the error. Reading pixel data and
other transformations seems fine.

2. it only happens when the API is called from within a thread (hence the
pthread_start()). If you call it from the main process, no problem.

3. the problem can be mitigated by mallopt(M_ARENA_MAX, n); for some fixed
n (currently running with 8)

Bug#1033222: libgl1-mesa-dri: Segmentation fault with nouveau_dri.so

[Christophe Lohr]

Package: libgl1-mesa-dri
Version: 22.3.3-1
Severity: normal
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,
  Xorg is carshing with a segfault:

(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55c365ce4cf9]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f00ef25af90]
(EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x4406c) [0x7f00ed75999c]
(EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x1e4c9) [0x7f00ed733df9]
(EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x266) [0x7f00ed715b96]
(EE) unw_get_proc_name failed: no unwind info found [-10]
../..
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)


any workaround meantime? ;-)


Best regards
Christophe




-- Package-specific info:
glxinfo:

DISPLAY is not set.

/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions
diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 
by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions
diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/powerpc64le-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/powerpc64le-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/powerpc64le-linux-gnu/libGLESv1_CM.so.1.1.0 by 
glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib

Bug#1029683: python3-renderpm: renderPM can't set standard fonts

[Christophe Monniez]

Package: python3-renderpm
Version: 3.6.12-1
Severity: important
X-Debbugs-Cc: christo...@monniez.eu

Dear Maintainer,


Since the `gsfonts` package was replaced by `fonts-urw-base35`,
`python3-renderpm` reportlab is not able to draw any of the 14 standard fonts 
anymore.

The reportlab documentation states that those fonts only needs to be
referenced by names.

For example, this simple python3 script should work:

```
from reportlab.graphics.renderPM import PMCanvas
c = PMCanvas(10,10)
c.setFont('Times-Roman', 32)
```

But leads to this error on Debian Bookworm:
```
Warn: Can't find .pfb for face 'Times-Roman'
Traceback (most recent call last):
  File "/tmp/canvas.py", line 4, in 
c.setFont('Times-Roman', 32)
  File "/usr/lib/python3/dist-packages/reportlab/graphics/renderPM.py", line 
405, in setFont
_setFont(self._gs,fontName,fontSize)
  File "/usr/lib/python3/dist-packages/reportlab/graphics/utils.py", line 42, 
in setFont
_errorDump(fontName,fontSize)
  File "/usr/lib/python3/dist-packages/reportlab/graphics/utils.py", line 29, 
in _errorDump
rl_exec(code,dict(RenderPMError=RenderPMError))
  File "", line 1, in 
reportlab.graphics.utils.RenderPMError: Error in setFont('Times-Roman',32) 
missing the T1 files?
```

Altough the `fonts-urw-base35` is properly installed.

This applies to any of the 14 standard fonts:
Courier, Courier-Bold, Courier-BoldOblique, Courier-Oblique, Helvetica,
Helvetica-Bold, Helvetica-BoldOblique, Helvetica-Oblique, Symbol,
Times-Bold, Times-BoldItalic, Times-Italic, Times-Roman, ZapfDingbats

The above script works on Bullseye when the `gsfonts` package is
installed, it also works if the `reportlab==3.6.12` package is installed
via `pip`.

It seems that when the `gsfonts` are installed, the file `n021003l.pfb`
is used for `Times-Roman`. On the other hand, without the `gsfonts, when
using the upstream pip package, the file `reportlab/fonts/_er_.pfb`
is used. I saw that the `fonts` directory from upstream is completely
removed in the Debian package.

I think that it should work out of the box as it was when `gsfonts` were
available and as stated in the upstream documentation. Either the
`fonts` directory should not be removed from the package, or the package
should include the `gsfonts` pfb files for the 14 standard fonts, or the
package should be patched to work with the `fonts-urw-base35` provided
files.

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

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

Versions of packages python3-renderpm depends on:
ii  fonts-urw-base35  20200910-6
ii  libc6 2.36-8
ii  libfreetype6  2.12.1+dfsg-4
ii  python3   3.10.6-3+b1

python3-renderpm recommends no packages.

python3-renderpm suggests no packages.

-- no debconf information

Thanks

Bug#1027647: libgl1-mesa-dri: Crash when using basic application like "git gui"

[Christophe CURIS]

Package: libgl1-mesa-dri
Version: 22.2.4-1
Severity: important
Tags: upstream

Dear Maintainer,

Since my latest update, I am experiencing a number of problems, but the most
severe one now is a reproducible crash when simply using "git gui":

(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55a6f911bcc9]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7fe78565af90]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_key_delete+0x14c) 
[0x7fe7856a9ccc]
(EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) [0x7fe78565aef2]
(EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd3) [0x7fe785645472]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 5: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so (?+0x0) [0x7fe78309d063]
(EE) 6: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so 
(nouveau_drm_screen_create+0x779b3c) [0x7fe784077c6c]
(EE) 7: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so 
(__driDriverGetExtensions_d3d12+0x5587f2) [0x7fe783602612]
(EE) 8: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so 
(__driDriverGetExtensions_d3d12+0x558401) [0x7fe783602221]
(EE) 9: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so 
(__driDriverGetExtensions_d3d12+0x129f4) [0x7fe7830bc814]
(EE) 10: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so 
(__driDriverGetExtensions_d3d12+0x5d7b7) [0x7fe7831075d7]
(EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (pthread_condattr_setpshared+0x4d4) 
[0x7fe7856a7fd4]
(EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (__xmknodat+0x23c) [0x7fe78572866c]

After a reboot and a 2nd try, the problem appeared again:

(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55809ceebcc9]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7ff532a5af90]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (pthread_key_delete+0x14c) 
[0x7ff532aa9ccc]
(EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x12) [0x7ff532a5aef2]
(EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0xd3) [0x7ff532a45472]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 5: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so (?+0x0) [0x7ff53089d063]
(EE) 6: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so 
(nouveau_drm_screen_create+0x6bef79) [0x7ff5317bd0a9]
(EE) 7: /usr/lib/x86_64-linux-gnu/dri/crocus_dri.so 
(__driDriverGetExtensions_d3d12+0xc5030) [0x7ff53096ee50]
(EE) 8: /usr/lib/xorg/modules/libglamoregl.so (glamor_destroy_pixmap+0x14c) 
[0x7ff5323f8c5c]
(EE) unw_get_proc_name failed: no unwind info found [-10]
(EE) 9: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) 
[0x7ff5327190b3]
(EE) 10: /usr/lib/xorg/Xorg (BlockHandler+0xad) [0x55809cd7d0ed]
(EE) 11: /usr/lib/xorg/Xorg (WaitForSomething+0x153) [0x55809cee5643]
(EE) 12: /usr/lib/xorg/Xorg (SendErrorToClient+0x113) [0x55809cd78473]
(EE) 13: /usr/lib/xorg/Xorg (InitFonts+0x3bc) [0x55809cd7c6cc]
(EE) 14: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) 
[0x7ff532a4618a]
(EE) 15: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) 
[0x7ff532a46245]
(EE) 16: /usr/lib/xorg/Xorg (_start+0x21) [0x55809cd65b71]




-- Package-specific info:
glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_get_drawable_type, GLX_EXT_libglvnd, GLX_EXT_no_config_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_ATI_pixel_format_float, GLX_EXT_buffer_age, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_no_config_context, GLX_EXT_swap_control, 
GLX_EXT_swap_control_tear, GLX_EXT_texture_from_pixmap, 
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_INTEL_swap_event, 
GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, GLX_MESA_swap_control, 
GLX_NV_float_buffer, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, 

Bug#1023013:

[Christophe TROESTLER]

Dear maintainer,

I encountered the same problem.  Here is the problem in syslog (similar to what 
Bernhard Übelacker reported).  The bug is only triggered by a few 
data-projectors.  I'll try to post a backtrace ASAP.

Best,
C.


2022-12-20T12:50:55.565570+01:00 poincare kernel: [12458.299721] 
gnome-shell[122742]: segfault at 58 ip 7f167e488770 sp 7ffed78d7138 
error 6 in liblcms2.so.2.0.13[7f167e47a000+3c000]
2022-12-20T12:50:55.565603+01:00 poincare kernel: [12458.299759] Code: 81 c4 a0 
00 00 00 5b 5d 41 5c c3 e8 2a 1d ff ff 66 2e 0f 1f 84 00 00 00 00 00 8b 47 58 
c3 66 66 2e 0f 1f 84 00 00 00 00 00 90 <89> 77 58 c3 66 66 2e 0f 1f 84 00 00 00 
00 00 90 8b 47 5c c3 66 66

Bug#1020575: pipewire-pulse: Sound card not detected

[Christophe Lohr]

Le 23/09/2022 à 17:42, Dylan Aïssi a écrit :

The hardware is well detected by the system:
But pipewire does not see the card (only the dummy pulseaudio sink):

Please try with pipewire 0.3.58-2 in debian/unstable. This version
should fix this issue.


Yes, this works!
Thanks

Bug#1020575: pipewire-pulse: Sound card not detected

[Christophe Lohr]

Package: pipewire-pulse
Version: 0.3.57-1
Severity: normal
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,

The audio card of my ASUS K501N laptop by pipewire-pulse.

The hardware is well detected by the system:

# lspci -v -s 0:8
00:08.0 Audio device: NVIDIA Corporation MCP79 High Definition Audio (rev b1)
Subsystem: ASUSTeK Computer Inc. MCP79 High Definition Audio
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
Memory at fae78000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel


The card is also detected by alsa:

$ aplay -l
 List of PLAYBACK Hardware Devices 
card 0: NVidia [HDA NVidia], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0


But pipewire does not see the card (only the dummy pulseaudio sink):

$ pw-cli list-objects|grep -B6 Audio
id 31, type PipeWire:Interface:Node/3
object.serial = "33"
factory.id = "18"
client.id = "32"
node.description = "Dummy Output"
node.name = "auto_null"
media.class = "Audio/Sink"


What can I do?

Best regards
Christophe


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

Kernel: Linux 5.19.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 pipewire-pulse depends on:
ii  init-system-helpers  1.65.2
ii  pipewire 0.3.57-1

pipewire-pulse recommends no packages.

Versions of packages pipewire-pulse suggests:
pn  libspa-0.2-bluetooth  
ii  pulseaudio-utils  15.0+dfsg1-4+b1

-- no debconf information

Bug#1020547: xserver-xorg-video-nouveau: Unreadable screen on a G102M

[Christophe Lohr]

On Fri, 23 Sep 2022 08:45:36 +0200 Christophe Lohr 
 wrote:

> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.17-2

> I have an ASUS K501N with a Geforce G102M
> With the new xorg-nouveau driver, the screen is unreadable full of 
glitchs

> I have no idea on how to fix this.
>
> --
> [img001.jpg 
<https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1020547;filename=img001.jpg;msg=5> 
(image/jpeg, attachment)]>



Hello,
  I fixed the issue by creating the file 
/etc/X11/xorg.conf.d/nouveau.conf with the following content:


Section "Device"
    Identifier "G102M"
    Driver "nouveau"
EndSection

Obviousely, only dri&friends drivers were automatically loaded by Xorg, 
and not the xorg-vido-driver itself

simply
I think you can close the bugreport

Regards
Christophe

Bug#1002725: evince: printing broken as apparmor denies access to pxgsettings

[Christophe TROESTLER]

Hi,

I had the same problem and I confirm that the fix works — modulo the version as 
on my machine it was
/usr/lib/x86_64-linux-gnu/libproxy/0.4.18/pxgsettings

Bug#1019486: gdm3: Gdm3 crashes (oh no something has gone wrong)

[Christophe TROESTLER]

Package: gdm3
Version: 42.0-1
Severity: grave
X-Debbugs-Cc: none, Christophe Troestler 

Dear Maintainer,

After the latest update, gdm3 (42.0) starts with the message “oh no something 
has gone wrong”.  =/var/log/syslog= contains the stack trace below.  Note sure 
how to fix this.

Best regards,
Christophe

-

Sep 10 13:31:33 poincare gnome-shell[184978]: libsoup3 symbols detected. Using 
libsoup2 and libsoup3 in the same process is not supported.
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: == Stack trace for 
context 0x55d5b8bbf190 ==
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #0   55d5b8ca6920 i   
resource:///org/gnome/shell/ui/dateMenu.js:377 (14a0de263b00 @ 73)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #1   55d5b8ca6850 i   
resource:///org/gnome/shell/ui/dateMenu.js:352 (14a0de263a10 @ 486)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #2   55d5b8ca67b8 i   
resource:///org/gnome/shell/ui/dateMenu.js:316 (14a0de263d30 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #3   55d5b8ca66c0 i   
resource:///org/gnome/shell/ui/dateMenu.js:944 (14a0de26a790 @ 1329)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #4   55d5b8ca6628 i   
resource:///org/gnome/shell/ui/panelMenu.js:11 (24683107e830 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #5   55d5b8ca6590 i   
resource:///org/gnome/shell/ui/panelMenu.js:97 (24683107eb00 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #6   55d5b8ca64f8 i   
resource:///org/gnome/shell/ui/dateMenu.js:853 (14a0de26a9c0 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #7   55d5b8ca6450 i   
resource:///org/gnome/shell/ui/panel.js:698 (14a0de262970 @ 101)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #8   55d5b8ca6388 i   
resource:///org/gnome/shell/ui/panel.js:709 (14a0de2629c0 @ 109)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #9   55d5b8ca62e8 i   
resource:///org/gnome/shell/ui/panel.js:662 (14a0de2628d0 @ 109)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #10   55d5b8ca6240 i  
 resource:///org/gnome/shell/ui/panel.js:486 (14a0de2623d0 @ 705)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #11   55d5b8ca61a8 i  
 resource:///org/gnome/shell/ui/panel.js:447 (14a0de262c40 @ 18)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #12   55d5b8ca60f8 i  
 resource:///org/gnome/shell/ui/main.js:228 (36c0410e54c0 @ 663)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #13   55d5b8ca6050 i  
 resource:///org/gnome/shell/ui/main.js:166 (36c0410e5380 @ 324)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #14   55d5b8ca5fc8 i  
 resource:///org/gnome/shell/ui/init.js:6 (36c0410c9290 @ 63)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #15   7ffd87d517d0 b  
 self-hosted:2408 (36c0410a7880 @ 753)
Sep 10 13:31:33 poincare org.gnome.Shell.desktop[184978]: #16   55d5b8ca5ee8 i  
 self-hosted:2355 (36c0410a7830 @ 375)
Sep 10 13:31:33 poincare gnome-session[184930]: gnome-session-binary[184930]: 
WARNING: Application 'org.gnome.Shell.desktop' killed by signal 5
Sep 10 13:31:33 poincare gnome-session[184930]: gnome-session-binary[184930]: 
WARNING: App 'org.gnome.Shell.desktop' respawning too quickly



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (400, 'unstable'), (300, 'stable'), (100, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gdm3 depends on:
ii  accountsservice   22.08.8-1
ii  adduser   3.128
ii  cinnamon [x-window-manager]   5.4.11-1
ii  cinnamon-session [x-session-manager]  5.4.0-1
ii  dbus [default-dbus-system-bus]1.14.0-2
ii  dbus-bin  1.14.0-2
ii  dbus-daemon   1.14.0-2
ii  dconf-cli 0.40.0-3
ii  dconf-gsettings-backend   0.40.0-3
ii  debconf [debconf-2.0] 1.5.79
ii  gir1.2-gdm-1.042.0-1
ii  gnome-session [x-session-manager] 42.0-1
ii  gnome-session-bin 42.0-1+b1
ii  gnome-session-common  42.0-1
ii  gnome-settings-daemon 43~beta-1+b1
ii  gnome-shell   42.4-2
ii  gnome-terminal [x-terminal-emulator]  3.44.1-1
ii  gsettings-desktop-schemas 43~alpha-1
ii  konsole [x-terminal-emulator] 4:22.04.1-1
ii  kwin-x11 [x-window-manager]   4:5.25.4-2
ii  l

Bug#766595: gnome-shell memory leak

[Christophe TROESTLER]

I run gnome-shell 42.4-1+b1 (Wayland, only extensions are Caffeine, topIcons 
Plus and Window List) and it seems to still have a memory leak.  It started at 
about 150MB and is now at more than 400MB and counting.

Bug#1012389: duplicity: Can't backup anymore - AssertionError

[Christophe Lohr]

Hi Alexander,
  Many thanks for your answers.


a) report your full duplicity invocation (without that i have no clue
what backend you're using, whether this was a full backup
only or incremental or whatever)


duplicity does the full backup normally
The issue occurs while trying to do an incremental backup

On my setup, the backend is a cifs partition mounted locally


and b) reproduce the problem from a clean state, run duplicity with -v9 and
provide the resulting log as well (minus personal/private information).


Well, I hopefully have found a workaround:  With the option 
"--no-encryption" duplicity makes full and incremental backups as usual 
(except ciphering, which is not really a point in my case. I just need 
no to lose data)
Obviously, duplicity encounters some bad interactions with possible 
recent updates of gpg...


Best regards
Christophe

Bug#1012389: duplicity: Can't backup anymore - AssertionError

[Christophe Lohr]

Package: duplicity
Version: 0.8.22-1
Severity: important
Tags: upstream

Dear Maintainer,

I can't use duplicity anymore.
For instance:
~$ duplicity collection-status $TARGET
Traceback (innermost last):
  File "/usr/bin/duplicity", line 92, in 
with_tempdir(main)
  File "/usr/bin/duplicity", line 75, in with_tempdir
fn()
  File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1577, in
main
do_backup(action)
  File "/usr/lib/python3/dist-packages/duplicity/dup_main.py", line 1599, in
do_backup
action).set_values()
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 761,
in set_values
self.set_matched_chain_pair(local_sig_chains + remote_sig_chains,
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 775,
in set_matched_chain_pair
sig_chains = sig_chains and self.get_sorted_chains(sig_chains)
  File "/usr/lib/python3/dist-packages/duplicity/dup_collections.py", line 992,
in get_sorted_chains
assert len(chain_list) == 2
 AssertionError


What's wrong? What should I do?

Best regards


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

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

Versions of packages duplicity depends on:
ii  gnupg  2.2.35-2
ii  libc6  2.33-7
ii  librsync2  2.3.2-1+b1
ii  python33.10.4-1+b1
ii  python3-fasteners  0.17.3-2
ii  python3-future 0.18.2-6
ii  python3-lockfile   1:0.12.2-2.2
ii  python3.10 3.10.4-1

Versions of packages duplicity recommends:
ii  python3-oauthlib  3.2.0-1
ii  python3-paramiko  2.8.1-1
ii  python3-pexpect   4.8.0-3
ii  python3-urllib3   1.26.9-1
ii  rsync 3.2.4-1

Versions of packages duplicity suggests:
ii  lftp 4.9.2-1+b1
ii  ncftp2:3.2.5-2.2
pn  par2 
pn  python3-boto 
ii  python3-pip  22.1.1+dfsg-1
pn  python3-swiftclient  
pn  tahoe-lafs   

-- no debconf information

Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted

[Christophe Trophime]

- Original Message -
> From: "Andreas Beckmann" 
> To: "Christophe Trophime" 
> Cc: "1008245" <1008...@bugs.debian.org>
> Sent: Friday, March 25, 2022 3:25:48 PM
> Subject: Re: Bug#1008245: update-glx config for nvidia but libegl point to 
> mesa-diverted

> On 25/03/2022 12.56, Christophe Trophime wrote:
>>> update-glx --display nvidia
> 
> Thanks.
> 
> I'm not sure whether this will yield helpful debug information, but you
> could run
> 
>   strace --trace=/open eglinfo

I attached the output as eglinfo.log

> 
> to get a list of all files opened when running eglinfo. This should at
> least show whether nvidia libraries are being tried ...
> 

Indeed it seems that it tried some nvidia libs

> 
> Andreas
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libGLdispatch.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/glvnd/egl_vendor.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d/10_nvidia.json", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-glsi.so.470.103.01", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/egl/egl_external_platform.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/egl/egl_external_platform.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
openat(AT_FDCWD, "/usr/share/egl/egl_external_platform.d/10_nvidia_wayland.json", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-egl-wayland.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libwayland-server.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libwayland-client.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libffi.so.8", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnvidia-eglcore.so.470.103.01", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profile-globals-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/LNCMI-G/trophime/.nv/nvidia-application-profiles-rc.d", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/nvidia/nvidia-application-profiles-rc.d/", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-470.103.01-rc", O_RDONLY) = 3
openat(AT_FDCWD, "/usr/share/nvidia/nvidia-application-profiles-rc", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/self/comm", O_RDONLY) = 3
openat(AT_FDCWD, "/usr/share/glvnd/egl_vendor.d/50_mesa.json", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libEGL_mesa.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libgbm.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libglapi.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libexpat.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libX11-xcb.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0"

Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted

[Christophe Trophime]

> On 25/03/2022 09.57, Christophe Trophime wrote:
>> Why on earth, glx--libEGL.so.1-x86_64-linux-gnu points to mesa-diverted??
> 
> MESA and modern NVIDIA drivers (starting after the 418 series) use
> libglvnd to provide generic loader libraries libGL.so.1, libEGL.so.1,
> ... while MESA and NVIDIA only provide some implementations:
> libGLX_${VENDOR}.so.0, libEGL_${VENDOR}.so.0, ...
> (NVIDIA still ships GLVND builds of (loader) libGL.so.1 etc., but we use
> them from src:libglvnd.)
> The name "mesa-diverted" is misleading nowadays since it actually
> contains diverted libglvnd libraries ... this won't be fixed, because
> once all the NVIDIA drivers predating GLVND usage reach EoL (Tesla 418
> in 03/2022 and legacy 390 in 12/2022), i.e. once there are no longer
> NVIDIA-specific libGL.so.1 etc. we can simplify the diversion and
> alternatives setup for bookworm, since most things done can now be
> solved by libglvnd.
> 

Hi, Andreas
thanks for your explanations. This is more clear now.

>> Running glxinfo I can confirm that I'm using Nvidia driver (even if
>> glx--libGL.so.1-x86_64-linux-gnu points to mesa-diverted).
> 
> As expected.
> 
>> But running eglinfo clearly states that I'm using mesa driver.
> 
> That's the point we need to look into.
> 
> Luca, can you confirm that eglinfo should report something
> "NVIDIA-specific" or is that a red herring?
> 
> Christophe, you should have something like these libraries
> related to EGL installed:
> 
> ii  libegl-mesa0:amd64  21.3.7-1  amd64
> free implementation of the EGL API -- Mesa vendor library
> ii  libegl-nvidia0:amd64470.103.01-3  amd64
> NVIDIA binary EGL library
> ii  libegl1:amd64   1.4.0-1   amd64
> Vendor neutral GL dispatch library -- EGL support
> ii  libnvidia-egl-wayland1:amd641:1.1.9-1.1   amd64
> Wayland EGL External Platform library -- shared library
> ii  libnvidia-eglcore:amd64 470.103.01-3  amd64
> NVIDIA binary EGL core libraries
> ii  libwayland-egl1:amd64   1.20.0-1  amd64
> wayland compositor infrastructure - EGL library
> ii  nvidia-egl-common   470.103.01-3  amd64
> NVIDIA binary EGL driver - common files
> ii  nvidia-egl-icd:amd64470.103.01-3  amd64
> NVIDIA EGL installable client driver (ICD)
> 
> Please send the configuration of the nvidia alternative, too:
> 
> update-glx --display nvidia
> 
nvidia - auto mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/current
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLESv1_CM_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv1_CM_nvidia.so.1
  slave nvidia--libGLESv2_nvidia.so.2-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLESv2_nvidia.so.2
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libcuda.so-i386-linux-gnu is /usr/lib/i386-linux-gnu/libcuda.so
  slave nvidia--libcuda.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so
  slave nvidia--libcuda.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libcuda.so.1
  slave nvidia--libcuda.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libcuda.so.1
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvcuvid.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so
  slave nvidia--libnvcuvid.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvcuvid.so.1
  slave nvidia--libnvidia-cfg.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
  slave nvidia--libnvidia-encode.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.1
  slave nvidia--libnvidia-ml.so-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libnvidia-ptxjitcompiler.so.1-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libnvidia-ptxjitcompiler.so.1
  slave nvidia--libnvidia-ptxjitcompiler.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ptxjitcompiler.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1
  slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy
  slave nvidia--nvidia-application-profiles-key-documentation is 
/usr/share/nvidia/nvidia-application-profiles-key-documentation
  slave nvidia--nvidia-blacklists-nouveau.conf is 
/etc/nvidia/nvidia-blacklists-

Bug#1008245: update-glx config for nvidia but libegl point to mesa-diverted

[Christophe Trophime]

Package: update-glx
Version: 1.2.1
Severity: normal

Dear Maintainer,

I've setup my debian Testing to use nvidia driver 470.103.01.
The system is setup to use nvidia drive: update-glx --config glx
However running update-glx --query glx reports:

Name: glx
Link: /usr/lib/glx
Slaves:
 glx--libEGL.so.1-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libEGL.so.1
 glx--libGL.so.1-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libGL.so.1
 glx--libGLESv1_CM.so.1-x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1
 glx--libGLESv2.so.2-x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/libGLESv2.so.2
 glx--libGLX_indirect.so.0-x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0
 glx--libglxserver_nvidia.so 
/usr/lib/xorg/modules/extensions/libglxserver_nvidia.so
 glx--libnvidia-cfg.so.1-x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/libnvidia-cfg.so.1
 glx--nvidia-blacklists-nouveau.conf 
/etc/modprobe.d/nvidia-blacklists-nouveau.conf
 glx--nvidia-bug-report.sh /usr/bin/nvidia-bug-report.sh
 glx--nvidia-drm-outputclass.conf 
/usr/share/X11/xorg.conf.d/nvidia-drm-outputclass.conf
 glx--nvidia-load.conf /etc/modules-load.d/nvidia.conf
 glx--nvidia-modprobe.conf /etc/modprobe.d/nvidia.conf
 glx--nvidia_drv.so /usr/lib/xorg/modules/drivers/nvidia_drv.so
Status: auto
Best: /usr/lib/nvidia
Value: /usr/lib/nvidia

Alternative: /usr/lib/mesa-diverted
Priority: 5
Slaves:
 glx--libEGL.so.1-x86_64-linux-gnu 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
 glx--libGL.so.1-x86_64-linux-gnu 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
 glx--libGLESv1_CM.so.1-x86_64-linux-gnu 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
 glx--libGLESv2.so.2-x86_64-linux-gnu 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
 glx--libGLX_indirect.so.0-x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0

Alternative: /usr/lib/nvidia
Priority: 100
Slaves:
 glx--libEGL.so.1-x86_64-linux-gnu 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
 glx--libGL.so.1-x86_64-linux-gnu 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
 glx--libGLESv1_CM.so.1-x86_64-linux-gnu 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1
 glx--libGLESv2.so.2-x86_64-linux-gnu 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
 glx--libGLX_indirect.so.0-x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
 glx--libglxserver_nvidia.so /usr/lib/nvidia/libglxserver_nvidia.so
 glx--libnvidia-cfg.so.1-x86_64-linux-gnu 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
 glx--nvidia-blacklists-nouveau.conf /etc/nvidia/nvidia-blacklists-nouveau.conf
 glx--nvidia-bug-report.sh /usr/lib/nvidia/nvidia-bug-report.sh
 glx--nvidia-drm-outputclass.conf /etc/nvidia/nvidia-drm-outputclass.conf
 glx--nvidia-load.conf /etc/nvidia/nvidia-load.conf
 glx--nvidia-modprobe.conf /etc/nvidia/nvidia-modprobe.conf
 glx--nvidia_drv.so /usr/lib/nvidia/nvidia_drv.so

Why on earth, glx--libEGL.so.1-x86_64-linux-gnu points to mesa-diverted??

Running glxinfo I can confirm that I'm using Nvidia driver (even if 
glx--libGL.so.1-x86_64-linux-gnu points to mesa-diverted).
But running eglinfo clearly states that I'm using mesa driver.

I have trouble running singularity container for some paraview app when using 
--nv for preloading nvidia driver
I suspect that my problem is linked with these "wrong" links

Can you please confirm or infirm my  statements?

Best
C

-- Package-specific info:
Diversions:
diversion of /usr/lib/aarch64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.0.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.0.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGL.so.1.7.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGL.so.1.7.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv1_CM.so.1.2.0 by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv2.so to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/libGLESv2.so by glx-diversions
diversion of /usr/lib/aarch64-linux-gnu/libGLESv2.so.2 to 
/usr/lib/mesa-diverted/aarch64-linux-gnu/

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

[Christophe Trophime]

Source: paramiko
Version: 2.8.1-1
Severity: important

Dear Maintainer,

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

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



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

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

Bug#1006309: boost-defaults: boost 1.74 2 years old and not C++20 compatible

[Christophe Prud'homme]

Source: boost-defaults
Severity: important

Dear Maintainer,


   * What led up to the situation?
boost 1.74 is 2 years old and not C++20 compatible.

C++20 is out for 2 years now, G++ and Clang now support it quite well

boost 1.74 (the default boost) is incompatible with C++20. Boost 1.77 or
1.78 are needed at least.

In practice, the boost packages are becoming obsolete and not in line with
the C++ compiler developments

Boost is however an important software piece for C++ developers.

We thus need to use other distribution channels, which is a pity.

We could provide packaging help if needed.


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500,
'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-72-generic (SMP w/56 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


[image: photo]
Christophe Prud'homme
Professor at  Université de Strasbourg
A  7 rue René Descartes, 67084 Strasbourg
P  +33 368850089  < +33 368850089>
M  +33 687646051  <+33 687646051>
E  christophe.prudho...@cemosis.fr  
W  http://www.cemosis.fr  <http://www.cemosis.fr>
<http://linkedin.com/in/christopheprudhomme/> <http://twitter.com/prudhomm>

Create your own email signature
<https://www.wisestamp.com/create-own-signature/?utm_source=promotion&utm_medium=signature&utm_campaign=create_your_own&srcid=>
‌

Bug#1003943: netcdf-parallel: wrong path to header in config cmake file

[Christophe Trophime]

Source: netcdf-parallel
Version: 1:4.8.1-2
Severity: normal

Dear Maintainer,

The config cmake file shipped with this package does not provide 
a valid directory for netcdf headers.

--- netcdf-parallel-4.8.1.orig/netCDFConfig.cmake.in
+++ netcdf-parallel-4.8.1/netCDFConfig.cmake.in
@@ -6,7 +6,7 @@
 
 set(NetCDFVersion "@PACKAGE_VERSION@")
 set_and_check(netCDF_INSTALL_PREFIX "@PACKAGE_CMAKE_INSTALL_PREFIX@")
-set_and_check(netCDF_INCLUDE_DIR "@PACKAGE_CMAKE_INSTALL_INCLUDEDIR@")
+set_and_check(netCDF_INCLUDE_DIR 
"@PACKAGE_CMAKE_INSTALL_LIBDIR@/netcdf/mpi/include")
 set_and_check(netCDF_LIB_DIR "@PACKAGE_CMAKE_INSTALL_LIBDIR@")
 
 set(netCDF_LIBRARIES netCDF::netcdf)

The above patch fixes this issue

Best
C

Bug#1003401: ITP: libconvert-uu-perl -- Perl module for uuencode and uudecode

[Christophe Maudoux]

retitle 1003401 ITP: libconvert-uu-perl -- Perl module for uuencode and 
uudecode


owner 1003401 !

thanks



Hi,

I will take care of this package.

Cheers

--
Christophe Maudoux
Doctorant en cybersécurité
Ingénieur systèmes & réseaux
Mainteneur WebSSO LemonLDAP::NG <https://lemonldap-ng.org/welcome/>

Bug#1001679: ITA: libmail-verify-perl -- Utility to verify an email address

[Christophe Maudoux]

retitle 1001679 ITA: libmail-verify-perl -- Utility to verify an email 
address


owner 1001679 !

thanks


Hi,

I willing to take care of this package.

Cheers

--
Christophe Maudoux
Doctorant en cybersécurité
Ingénieur systèmes & réseaux
Mainteneur WebSSO LemonLDAP::NG <https://lemonldap-ng.org/welcome/>

Bug#920212: ITA: libclamav-client-perl -- Perl client for the ClamAV virus scanner daemon

[Christophe Maudoux]

retitle 920212 ITA: libclamav-client-perl -- Perl client for the ClamAV 
virus scanner daemon


owner 920212 !

thanks


Hi,

I willing to take care of this package.

Cheers

--
Christophe Maudoux
Doctorant en cybersécurité
Ingénieur systèmes & réseaux
Mainteneur WebSSO LemonLDAP::NG <https://lemonldap-ng.org/welcome/>

Bug#1003208: ITP: libstatistics-zscore-perl -- Perl scoring module that uses statistics standard score.

[Christophe Maudoux]

Package: wnpp
Severity: wishlist
Owner: Christophe Maudoux 

* Package name: libstatistics-zscore-perl
  Version : 0.0002
  Upstream Author : Takeshi Miki 
* URL : https://metacpan.org/release/Statistics-Zscore
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl scoring module that uses statistics standard score.

This module is a scoring module that uses statistics STANDARD SCORE.

In statistics, a standard score is a dimensionless quantity
derived by subtracting the population mean from an individual raw score
and then dividing the difference by the population standard deviation.
This conversion process is called standardizing or normalizing.

Standard scores are also called z-values, z-scores, normal scores,
and standardized variables.

Bug#1003132: ITP: libgeohash-perl -- Perl module to handle geohash.

[Christophe Maudoux]

Package: wnpp
Severity: wishlist
Owner: Christophe Maudoux 

* Package name: libgeohash-perl
  Version : 0.04
  Upstream Author : Kazuhiro Osawa 
* URL : https://metacpan.org/release/Geohash
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to handle geohash.

This module handles geohash. It uses Geo::Hash or Geo::Hash::XS as a backend 
module. You can choose Pure-Perl or XS implementation. Some useful methods have 
been added.

Bug#1003110: ITP: libgeo-hash-xs-perl -- Perl module to quickly encode/decode geohash strings.

[Christophe Maudoux]

Package: wnpp
Severity: wishlist
Owner: Christophe Maudoux 

* Package name: libgeo-hash-xs-perl
  Version : 0.00015
  Upstream Author : Daisuke Maki 
* URL : https://metacpan.org/release/Geo-Hash-XS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to quickly encode/decode geohash strings.

This module encodes and decodes geohash strings, fast.

This package is a dependency of libgeohash-perl. It will be maintainded under
Perl team umbrella.

Bug#1003076: ITP: libgeo-hash-perl -- Perl module to encode/decode geohash.org locations.

[Christophe Maudoux]

Package: wnpp
Severity: wishlist
Owner: Christophe Maudoux 

* Package name: libgeo-hash-perl
  Version : 0.02
  Upstream Author : Andy Armstrong 
* URL : https://metacpan.org/release/Geo::Hash
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to encode/decode geohash.org locations.

Geohash is a latitude/longitude geocode system invented by Gustavo Niemeyer
when writing the web service at geohash.org, and put into the public domain.

This module encodes and decodes geohash locations.

This package is a dependency of libgeohash-perl. It will be maintainded under
Perl team umbrella.

Bug#1003047: ITP: libgeo-hash-perl -- Perl module to encode/decode geohash.org locations.

[Christophe Maudoux]

Package: wnpp
Severity: wishlist
Owner: Christophe Maudoux 

* Package name    : libgeo-hash-perl   Version : 0.02
   Upstream Author : Andy Armstrong 
* URL : https://metacpan.org/release/Geo::Hash
* License : Artistic or GPL-1+
   Programming Lang: Perl
   Description : Perl module to encode/decode geohash.org locations.

Geohash is a latitude/longitude geocode system invented by Gustavo Niemeyer
when writing the web service at geohash.org, and put into the public domain.

This module encodes and decodes geohash locations.

This package is a dependency of libgeohash-perl. It will be maintainded 
under

Perl team umbrella.

Bug#1001694: opencascade: Please upgrade to 7.5.3p1

[Christophe Trophime]

Source: opencascade
Version: 7.5.1+dfsg1-2
Severity: wishlist

Dear Maintainer,
could you please upgrade to 7.5.3p1?

NB: please do not consider using latest release 7.6.0 unless we
can install different versions of opencascade side by side.

Thanks


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

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

Bug#1001464: paraview: enable web support

[Christophe Trophime]

Package: paraview
Version: 5.10.0~rc1-1
Severity: wishlist

Dear Maintainer,

Could you please enable web support by simply changing
DPARAVIEW_ENABLE_WEB to ON in d/rules?

I would like to use pywebvue with paraview.

Best


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

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

Versions of packages paraview depends on:
ii  libavcodec58   7:4.4.1-2+b1
ii  libavformat58  7:4.4.1-2+b1
ii  libavutil567:4.4.1-2+b1
ii  libc6  2.32-5
ii  libdouble-conversion3  3.1.5-7
ii  libexpat1  2.4.1-3
ii  libfreetype6   2.11.0+dfsg-1
ii  libgcc-s1  11.2.0-12
ii  libgdal29  3.3.3+dfsg-2
ii  libgl2ps1.41.4.2+dfsg1-2
ii  libglew2.2 2.2.0-4
ii  libglx01.3.4-2+b1
ii  libhdf5-103-1  1.10.7+repack-4
ii  libjpeg62-turbo1:2.1.2-1
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2
ii  libnetcdf191:4.8.1-1
ii  libopengl0 1.3.4-2+b1
ii  libopenmpi34.1.2-1
ii  libpdal-base13 2.3.0+ds-2+b1
ii  libpng16-161.6.37-3
ii  libpython3.9   3.9.9-1
ii  libqt5core5a   5.15.2+dfsg-14
ii  libqt5gui5 5.15.2+dfsg-14
ii  libqt5help55.15.2-5+b1
ii  libqt5network5 5.15.2+dfsg-14
ii  libqt5widgets5 5.15.2+dfsg-14
ii  libstdc++6 11.2.0-12
ii  libswscale57:4.4.1-2+b1
ii  libtiff5   4.3.0-2
ii  libx11-6   2:1.7.2-2+b1
ii  libxcursor11:1.2.0-2
ii  libxml22.9.12+dfsg-5+b1
ii  python3-autobahn   17.10.1+dfsg1-7
ii  python3-matplotlib 3.3.4-2
ii  python3-mpi4py 3.1.2-2
ii  python3-six1.16.0-2
ii  python3-twisted20.3.0-7
ii  tcl [tclsh]8.6.11+1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages paraview recommends:
ii  mpi-default-bin  1.14
pn  paraview-doc 
ii  python3-paraview [python3-paraview]  5.10.0~rc1-1

Versions of packages paraview suggests:
pn  h5utils 
ii  hdf5-tools  1.10.7+repack-4

-- no debconf information

Bug#1001093:

[Christophe Troestler]

For me, upgrading the firmware to version 1.53 seems¹ to have solved the 
problem.



¹ Few tests at the time of this writing.

Bug#1001093: (no subject)

[Christophe Troestler]

The bug is reported to the kernel:

Bug#1001093: linux-image-5.15.0-2-amd64: Fan at full speed when resuming from suspend

[Christophe Troestler]

Package: src:linux
Version: 5.15.5-1
Severity: normal
X-Debbugs-Cc: none, Christophe Troestler 

Dear Maintainer,

After resuming from suspend, the fan runs at full speed on an X1 Carbon (5th 
gen, 2017).  Rebooting the machine is not enough to solve the problem, I have 
to shutdown it and restart it.  I am not the only one to get this problem:
<https://ask.fedoraproject.org/t/fan-at-full-speed-after-suspend-on-thinkpad-x260-with-kernel-5-10/14762>

Best,
Christophe

-- Package-specific info:


Version:


Linux version 5.15.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-12) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian 
5.15.5-1 (2021-11-26)


Command line:
=

BOOT_IMAGE=/vmlinuz-5.15.0-2-amd64 root=/dev/mapper/main-root ro quiet


Not tainted
===


Kernel log:
===

Unable to read kernel log; any relevant messages should be attached


Model information
=

sys_vendor: LENOVO
product_name: 20HR002MMB
product_version: ThinkPad X1 Carbon 5th
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N1MET37W (1.22 )
board_vendor: LENOVO
board_name: 20HR002MMB
board_version: SDK0J40697 WIN


Loaded modules:
===

sd_mod
sg
uas
usb_storage
scsi_mod
scsi_common
btrfs
blake2b_generic
xor
zstd_compress
raid6_pq
ufs
qnx4
hfsplus
hfs
cdrom
minix
msdos
jfs
xfs
hid_logitech_hidpp
uhid
xt_conntrack
nft_chain_nat
xt_MASQUERADE
nf_nat
nf_conntrack_netlink
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nft_counter
xt_addrtype
nft_compat
nf_tables
libcrc32c
nfnetlink
br_netfilter
bridge
stp
llc
l2tp_ppp
l2tp_netlink
l2tp_core
xfrm_user
ip6_udp_tunnel
udp_tunnel
xfrm_algo
pppox
ppp_generic
slhc
ctr
ccm
rfcomm
cmac
algif_hash
algif_skcipher
af_alg
snd_usb_audio
snd_usbmidi_lib
snd_rawmidi
r8152
bnep
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
btusb
btrtl
btbcm
btintel
bluetooth
jitterentropy_rng
tun
sha512_ssse3
sha512_generic
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
cdc_mbim
videodev
cdc_wdm
cdc_ncm
cdc_ether
usbnet
drbg
ansi_cprng
qcserial
usb_wwan
mii
usbserial
mc
ecdh_generic
ecc
overlay
snd_soc_skl
snd_soc_hdac_hda
snd_hda_ext_core
snd_soc_sst_ipc
snd_soc_sst_dsp
snd_soc_acpi_intel_match
intel_rapl_msr
snd_hda_codec_hdmi
snd_soc_acpi
binfmt_misc
joydev
intel_rapl_common
snd_soc_core
snd_ctl_led
intel_pmc_core_pltdrv
iwlmvm
mei_hdcp
snd_hda_codec_conexant
snd_compress
intel_pmc_core
snd_hda_codec_generic
mac80211
snd_hda_intel
libarc4
snd_intel_dspcfg
nls_ascii
snd_intel_sdw_acpi
nls_cp437
snd_hda_codec
x86_pkg_temp_thermal
intel_powerclamp
vfat
fat
iwlwifi
rapl
snd_hda_core
iTCO_wdt
rmi_smbus
intel_cstate
intel_uncore
efi_pstore
serio_raw
pcspkr
intel_pmc_bxt
snd_hwdep
iTCO_vendor_support
rmi_core
snd_pcm
wmi_bmof
intel_wmi_thunderbolt
watchdog
cfg80211
snd_timer
mei_me
thinkpad_acpi
ucsi_acpi
intel_xhci_usb_role_switch
mei
typec_ucsi
nvram
platform_profile
roles
intel_pch_thermal
typec
ledtrig_audio
snd
soundcore
rfkill
ac
evdev
acpi_pad
coretemp
msr
parport_pc
ppdev
lp
parport
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
hid_generic
usbhid
dm_crypt
dm_mod
i915
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
rtsx_pci_sdmmc
mmc_core
i2c_algo_bit
ttm
nvme
drm_kms_helper
aesni_intel
nvme_core
crypto_simd
cec
t10_pi
crc_t10dif
rc_core
cryptd
crct10dif_generic
e1000e
psmouse
i2c_i801
i2c_smbus
ptp
xhci_pci
pps_core
xhci_hcd
drm
rtsx_pci
usbcore
crct10dif_pclmul
crct10dif_common
usb_common
wmi
i2c_hid_acpi
i2c_hid
battery
hid
video
button


PCI devices:


00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v6/7th Gen Core 
Processor Host Bridge/DRAM Registers [8086:5904] (rev 02)
Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 620 
[8086:5916] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 v5/v6 / 
E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
Subsystem: Lenovo ThinkPad X1 Carbon 5th Gen [17aa:224f]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller [

Bug#998790: firefox: Video not playing

[Christophe Troestler]

I had to create a nex profile for video to work again (I also had many tabs 
open, I have few now).

Bug#998790: firefox: Video not playing

[Christophe Troestler]

Subject: firefox: Video not playing
Package: firefox
Version: 94.0-1
Severity: normal

Dear Maintainer,

Playing videos on, say, youtube (e.g. ) 
does not work: the “loading circle” keeps turning but nothing happens (even 
with troubleshoot mode turned on).

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-3
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi8  3.4.2-3
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.11.0+dfsg-1
ii  libgcc-s111.2.0-10
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.0-3
ii  libgtk-3-0   3.24.30-3
ii  libnspr4 2:4.32-1
ii  libnss3  2:3.72-1
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libstdc++6   11.2.0-10
ii  libvpx7  1.11.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libx11-xcb1  2:1.7.2-2+b1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.2-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.4.1-1+b1

Versions of packages firefox suggests:
ii  fonts-lmodern  2.004.5-6.1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-8
ii  libgssapi-krb5-2   1.18.3-7
ii  pulseaudio 15.0+dfsg1-2

-- no debconf information

Bug#992524: deborphan: missing orphaner

[Christophe Lohr]

On Fri, 20 Aug 2021 02:34:52 +0200 Chris Hofstaedtler 
wrote:
> * Jan De Luyck  [210819 20:57]:
> > After upgrading to deborphan 1.7.34 (after bullseye release) I
noticed that the
> > orphaner binary is no longer being included.
>
> The changelog explicitly said:
> > * Remove orphaner, editkeep

Are these tools (orphaner editkeep) packaged elsewhere?
are there recommended front-ends?

Best regards
Christophe

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Christophe Geuzaine]

> On 12 Feb 2021, at 14:24, Bernhard Übelacker  wrote:
> 
> Am 12.02.21 um 12:12 schrieb Drew Parsons:
>> Version mismatch could cause problems.
>> Bernhard, can you provide the versions of each of the packages you're 
>> reporting on
>> (dolfinx, eigen3, gmsh) ?
> 
> Hello,
> these are the versions I have used in this test VM.
> 
> Would it be possible that libgmsh should use
> the Memory.h below /usr instead of ./contrib ?

You could configure Gmsh with "cmake -DENABLE_SYSTEM_CONTRIB=1", which will 
instruct Gmsh to use "system" versions of the contrib packages if they are 
available.

Christophe


> 
> Kind regards,
> Bernhard
> 
> 
> # dpkg -l | grep -E "dolfinx|eigen3|gmsh" | LANG=C sort -k3b,3b -k2b,2b
> ii  dolfinx-doc2019.2.0~git20201109.17bda9f-6 all 
>  Documentation and demo programs for DOLFIN
> ii  libdolfinx-dev 2019.2.0~git20201109.17bda9f-6 all 
>  Shared links and header files for DOLFIN
> ii  libdolfinx-real-dev:amd64  2019.2.0~git20201109.17bda9f-6 
> amd64Shared links and header files for DOLFIN (real numbers)
> ii  libdolfinx-real2019.2-dbgsym:amd64 2019.2.0~git20201109.17bda9f-6 
> amd64debug symbols for libdolfinx-real2019.2
> ii  libdolfinx-real2019.2:amd642019.2.0~git20201109.17bda9f-6 
> amd64Shared libraries for DOLFIN
> ii  python3-dolfinx-real   2019.2.0~git20201109.17bda9f-6 
> amd64Python interface for DOLFIN (Python 3)
> ii  python3-dolfinx:amd64  2019.2.0~git20201109.17bda9f-6 
> amd64Python interface for DOLFIN (Python 3)
> ii  libeigen3-dev  3.3.9-2all 
>  lightweight C++ template library for linear algebra
> ii  gmsh   4.7.1+ds1-2
> amd64Three-dimensional finite element mesh generator
> ii  gmsh-doc   4.7.1+ds1-2all 
>  Three-dimensional finite element mesh generator documentation
> ii  libgmsh4-dbgsym:amd64  4.7.1+ds1-2
> amd64debug symbols for libgmsh4
> ii  libgmsh4:amd64 4.7.1+ds1-2
> amd64Three-dimensional finite element mesh generator shared library
> ii  python3-gmsh   4.7.1+ds1-2all 
>  Three-dimensional finite element mesh generator Python 3 wrapper
> 

— 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://people.montefiore.uliege.be/geuzaine

Bug#840336: elpa-markdown-mode: Freezes Emacs when using TeX input mode in a header

[Christophe Troestler]

I can no longer reproduce this bug either (I'm using Emacs 27.1 now).

Regards,
C.


On  8 December 2020 at 15:23 CET, Nicholas D Steeves  wrote:
>
> Control: tags -1 = unreproducible
> Control: fixed -1 markdown-mode/2.3+154-2
>
> Hi Christophe,
>
> I was unable reproduce the issue on sid with emacs 1:27.1+1-3 and
> elpa-markdown-mode 2.4-1.
>
> This bug looks safe to close now, but I'll leave it open for six months
> on the off chance a new trigger can be identified.
>
> Regards,
> Nicholas

Bug#938795: vmtk does not build any more

[Christophe Trophime]

Hi,
maybe rebuilding vtk9 with gdcm support will fix this?

By the way, I've noticed that vtk9 is built with gl2ps support
whereas paraview is not. Not sure but this may lead to some troubles.
Would be great to rebuild paraview with gl2ps also.

Best
C

Christophe TROPHIME 
Research Engineer 

CNRS - LNCMI 
25, rue des Martyrs 
BP 166 
38042 GRENOBLE Cedex 9 
FRANCE 

Tel : +33 (0)4 76 88 90 02 
Fax : +33 (0) 4 76 88 10 01 
Office U 19 
M@il : christophe.troph...@lncmi.cnrs.fr

- Original Message -
> From: "Andreas Tille" 
> To: "Drew Parsons" 
> Cc: 938...@bugs.debian.org, "debian-science" 
> , "Johannes Ring" 
> Sent: Tuesday, December 8, 2020 9:08:12 AM
> Subject: Re: vmtk does not build any more

> Hi,
> 
> On Tue, Dec 08, 2020 at 04:21:01AM +0800, Drew Parsons wrote:
>> First thing to try would be building against vtk9, which Anton recently
>> released for us.
> 
> Thanks for the hint but switching to vtk9 leads to cmake errors:
> 
> -- The imported target "vtkgdcmsharpglue" references the file
>   "/usr/lib/x86_64-linux-gnu/libvtkgdcmsharpglue.so"
> but this file does not exist.  Possible reasons include:
> * The file was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and contained
>   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
> but not all the files it references.
> 
> -- The imported target "vtkgdcmJava" references the file
>   "/usr/lib/x86_64-linux-gnu/jni/libvtkgdcmJava.so"
> but this file does not exist.  Possible reasons include:
> * The file was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and contained
>   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
> but not all the files it references.
> 
> -- The imported target "vtkgdcmPython" references the file
>   "/usr/lib/python/dist-packages/vtkgdcmPython.so"
> but this file does not exist.  Possible reasons include:
> * The file was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and contained
>   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
> but not all the files it references.
> 
> -- The imported target "vtkgdcmPythonD" references the file
>   "/usr/lib/x86_64-linux-gnu/libvtkgdcmPythonD.so.3.0.7"
> but this file does not exist.  Possible reasons include:
> * The file was deleted, renamed, or moved to another location.
> * An install or uninstall procedure did not complete successfully.
> * The installation package was faulty and contained
>   "/usr/lib/x86_64-linux-gnu/gdcm-3.0/GDCMTargets.cmake"
> but not all the files it references.
> ...
> 
> 
> This does not happen with vtk7.  But may be it needs ITK5?
> 
> Kind regards
> 
> Andreas.
> 
> --
> http://fam-tille.de

Bug#975881: Build of xt_ACCOUNT.ko failed for: 5.9.0-3-amd64

[jean-christophe manciot]

Package: xtables-addons-dkms
Version: 3.11-1

distribution: bullseye
linux-headers-5.9.0-3-amd64: 5.9.9-1
linux-headers-5.9.0-3-common: 5.9.9-1
linux-source-5.9: 5.9.9-1
linux-image-5.9.0-3-amd64: 5.9.9-1
linux-kbuild-5.9: 5.9.9-1
linux-compiler-gcc-10-x86: 5.9.9-1
linux-config-5.9: 5.9.9-1

Installing aforementioned packages with:
xtables-addons-dkms: 3.11-1
xtables-addons-common: 3.11-1
xtables-addons-source: 3.11-1

leads to:
Preparing to unpack .../linux-image-amd64_5.9.9-1_amd64.deb ...
Unpacking linux-image-amd64 (5.9.9-1) over (5.9.9-1) ...
Setting up linux-image-5.9.0-3-amd64 (5.9.9-1) ...
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 5.9.0-3-amd64:
Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area...
make -j8 KERNELRELEASE=5.9.0-3-amd64 -C
/lib/modules/5.9.0-3-amd64/build
M=/var/lib/dkms/xtables-addons/3.11/build/extensions
XA_ABSTOPSRCDIR=/var/lib/dkms/xt
ables-addons/3.11/build
XA_TOPSRCDIR=/var/lib/dkms/xtables-addons/3.11/build V=1 modules ;
find /var/lib/dkms/xtables-addons/3.11/build -name '*.ko' -exec mv
-v {} /var/lib/dkms/xtables-addons/3.11/build \;
Error!  Build of xt_ACCOUNT.ko failed for: 5.9.0-3-amd64 (x86_64)
Consult the make.log in the build directory
/var/lib/dkms/xtables-addons/3.11/build/ for more information.

with /var/lib/dkms/xtables-addons/3.11/build/make.log attached:
DKMS make.log for xtables-addons-3.11 for kernel 5.9.0-3-amd64 (x86_64)
Thu 26 Nov 2020 08:13:08 AM CET
make: Entering directory '/usr/src/linux-headers-5.9.0-3-amd64'
make -C /usr/src/linux-headers-5.9.0-3-amd64 -f
/usr/src/linux-headers-5.9.0-3-common/Makefile modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \
echo >&2; \
echo >&2 "  ERROR: Kernel configuration is invalid."; \
echo >&2 " include/generated/autoconf.h or
include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src
to fix it."; \
echo >&2 ; \
/bin/false)
make -f /usr/src/linux-headers-5.9.0-3-common/scripts/Makefile.build
obj=/var/lib/dkms/xtables-addons/3.11/build/extensions \
single-build= \
need-builtin=1 need-modorder=1
make -f /usr/src/linux-headers-5.9.0-3-common/scripts/Makefile.build
obj=/var/lib/dkms/xtables-addons/3.11/build/extensions/ACCOUNT \
 \
...

/usr/src/linux-headers-5.9.0-3-amd64/include/generated/autoconf.h and
/usr/src/linux-headers-5.9.0-3-amd64/include/config/auto.conf are
available despite the error message:
-rw-r--r-- 1 root root 208797 Nov 19 08:19
/usr/src/linux-headers-5.9.0-3-amd64/include/generated/autoconf.h
-rw-r--r-- 1 root root 138648 Nov 19 08:19
/usr/src/linux-headers-5.9.0-3-amd64/include/config/auto.conf

-- 
Jean-Christophe
DKMS make.log for xtables-addons-3.11 for kernel 5.9.0-3-amd64 (x86_64)
Thu 26 Nov 2020 08:13:08 AM CET
make: Entering directory '/usr/src/linux-headers-5.9.0-3-amd64'
make -C /usr/src/linux-headers-5.9.0-3-amd64 -f /usr/src/linux-headers-5.9.0-3-common/Makefile modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\
echo >&2;			\
echo >&2 "  ERROR: Kernel configuration is invalid.";		\
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;			\
/bin/false)
make -f /usr/src/linux-headers-5.9.0-3-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.11/build/extensions \
single-build= \
need-builtin=1 need-modorder=1
make -f /usr/src/linux-headers-5.9.0-3-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.11/build/extensions/ACCOUNT \
 \
need-builtin= \
need-modorder=1
make -f /usr/src/linux-headers-5.9.0-3-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.11/build/extensions/pknock \
 \
need-builtin= \
need-modorder=1
   gcc-10 -Wp,-MMD,/var/lib/dkms/xtables-addons/3.11/build/extensions/.compat_xtables.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/10/include -I/usr/src/linux-headers-5.9.0-3-common/arch/x86/include -I./arch/x86/include/generated -I/usr/src/linux-headers-5.9.0-3-common/include -I./include -I/usr/src/linux-headers-5.9.0-3-common/arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I/usr/src/linux-headers-5.9.0-3-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-5.9.0-3-common/include/linux/kconfig.h -include /usr/src/linux-headers-5.9.0-3-common/include/linux/compiler_types.h -D__KERNEL__ -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -fal

Bug#974772: intel-media-va-driver: Programs crash with "Illegal instruction" in iHD_drv_video.so

[Christophe]

- Sebastian Ramacher  a écrit :
> Control: forwarded -1 https://github.com/intel/media-driver/issues/1081
> Control: tags -1 = upstream
> 
> On 2020-11-14 23:16:35 +0100, Christophe CURIS wrote:
> > Package: intel-media-va-driver
> > Version: 20.3.0+dfsg1-1
> > Severity: important
> > Tags: ftbfs
> > 
> > Dear Maintainer,
> > 
> > Since my latest debian update, VLC is crashing when playing video with the 
> > message:
> >   Illegal instruction
> > 
> > After a bit of debug in GDB, I have confirmed that the crash comes from:
> >   /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> > 
> > (gdb) bt
> > #0  0x7fffa133ba6b in ?? () from 
> > /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> > #1  0x7fffa133bb8f in ?? () from 
> > /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> > #2  0x7fffa133b2c8 in ?? () from 
> > /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> > #3  0x7fffa133bc67 in ?? () from 
> > /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> > #4  0x7fffa1342a05 in ?? () from 
> > /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> > #5  0x7fffa12c6597 in ?? () from 
> > /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
> > #6  0x7fffac244e86 in ?? () from /usr/lib/x86_64-linux-gnu/libva.so.2
> > #7  0x7fffac245feb in vaInitialize () from 
> > /usr/lib/x86_64-linux-gnu/libva.so.2
> > 
> > I am suspecting it is because the package is compiled from a very recent 
> > architecture
> > (i7 with sse4.1 explicitely enabled) which my processor does not support.
> 
> That means that you're CPU/GPU is too old and is not supported by
> intel-media-driver. As a workaround, you can set the environment
> variable LIBVA_DRIVER_NAME to i915 (or remove intel-media-va-driver from
> your system). But in any case, the driver should
> at least bail out if it detects an unsupported platform before running
> into illegal instructions. This is currently tracked upstream at
> https://github.com/intel/media-driver/issues/1081

Hi Sebastian,

Thanks for your feedback.
On my side, I have continued investigations and managed to compile something.
Good news: it looks like it is working now (Well, I mean apps not crashing).

I had a quick look, it seems impossible to remove this package due to 
dependancies. Maybe I would have more luck with the "-non-free" alternative but 
I seriously doubt.

On your side, what would be good behaviour if I tryed to propose a patch?

My current patch is an "ugly hack" that replaces one SSE4.1 instruction by its 
SSE2 counterpart and changes the "-m" settings (-march=, -msseXX)
I consider this not ok for the general use, so there could be tradeoffs...

> 
> Cheers
> 
> 
> > 
> > I have tryed compiling the package from source, but after tweaking the 
> > flags to
> > set -march=native, the compilation fails:
> > 
> > In file included from 
> > [...]/intel-media-driver-20.3.0+dfsg1/media_driver/linux/common/cm/hal/cm_mem_os.h:30,
> >  from 
> > [...]/intel-media-driver-20.3.0+dfsg1/media_driver/agnostic/common/cm/cm_mem.h:128,
> >  from 
> > [...]/intel-media-driver-20.3.0+dfsg1/media_driver/agnostic/common/cm/cm_buffer_rt.cpp:33:
> > /usr/lib/gcc/x86_64-linux-gnu/10/include/smmintrin.h: In function ‘void 
> > CmFastMemCopyFromWC(void*, const void*, size_t, CPU_INSTRUCTION_LEVEL)’:
> > /usr/lib/gcc/x86_64-linux-gnu/10/include/smmintrin.h:582:1: error: inlining 
> > failed in call to ‘always_inline’ ‘__m128i 
> > _mm_stream_load_si128(__m128i*)’: target specific option mismatch
> >   582 | _mm_stream_load_si128 (__m128i *__X)
> >   | ^
> > In file included from 
> > [...]/intel-media-driver-20.3.0+dfsg1/media_driver/agnostic/common/cm/cm_mem.h:128,
> >  from 
> > [...]/intel-media-driver-20.3.0+dfsg1/media_driver/agnostic/common/cm/cm_buffer_rt.cpp:33:
> > [...]/intel-media-driver-20.3.0+dfsg1/media_driver/linux/common/cm/hal/cm_mem_os.h:201:53:
> >  note: called from here
> >   201 | xmm3 = _mm_stream_load_si128(mmSrc + 3);
> >   |~^~~
> > 
> > I am wondering what would be a good solution to at least avoid crashes...
> 
> 
> > 
> > Regards,
> > Christophe
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >   APT prefers testing
> >   APT policy: (500, 'testing')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 5.2.0-2-amd

Bug#974772: intel-media-va-driver: Programs crash with "Illegal instruction" in iHD_drv_video.so

[Christophe CURIS]

Package: intel-media-va-driver
Version: 20.3.0+dfsg1-1
Severity: important
Tags: ftbfs

Dear Maintainer,

Since my latest debian update, VLC is crashing when playing video with the 
message:
  Illegal instruction

After a bit of debug in GDB, I have confirmed that the crash comes from:
  /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so

(gdb) bt
#0  0x7fffa133ba6b in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
#1  0x7fffa133bb8f in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
#2  0x7fffa133b2c8 in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
#3  0x7fffa133bc67 in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
#4  0x7fffa1342a05 in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
#5  0x7fffa12c6597 in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
#6  0x7fffac244e86 in ?? () from /usr/lib/x86_64-linux-gnu/libva.so.2
#7  0x7fffac245feb in vaInitialize () from 
/usr/lib/x86_64-linux-gnu/libva.so.2

I am suspecting it is because the package is compiled from a very recent 
architecture
(i7 with sse4.1 explicitely enabled) which my processor does not support.

I have tryed compiling the package from source, but after tweaking the flags to
set -march=native, the compilation fails:

In file included from 
[...]/intel-media-driver-20.3.0+dfsg1/media_driver/linux/common/cm/hal/cm_mem_os.h:30,
 from 
[...]/intel-media-driver-20.3.0+dfsg1/media_driver/agnostic/common/cm/cm_mem.h:128,
 from 
[...]/intel-media-driver-20.3.0+dfsg1/media_driver/agnostic/common/cm/cm_buffer_rt.cpp:33:
/usr/lib/gcc/x86_64-linux-gnu/10/include/smmintrin.h: In function ‘void 
CmFastMemCopyFromWC(void*, const void*, size_t, CPU_INSTRUCTION_LEVEL)’:
/usr/lib/gcc/x86_64-linux-gnu/10/include/smmintrin.h:582:1: error: inlining 
failed in call to ‘always_inline’ ‘__m128i _mm_stream_load_si128(__m128i*)’: 
target specific option mismatch
  582 | _mm_stream_load_si128 (__m128i *__X)
  | ^
In file included from 
[...]/intel-media-driver-20.3.0+dfsg1/media_driver/agnostic/common/cm/cm_mem.h:128,
 from 
[...]/intel-media-driver-20.3.0+dfsg1/media_driver/agnostic/common/cm/cm_buffer_rt.cpp:33:
[...]/intel-media-driver-20.3.0+dfsg1/media_driver/linux/common/cm/hal/cm_mem_os.h:201:53:
 note: called from here
  201 | xmm3 = _mm_stream_load_si128(mmSrc + 3);
  |~^~~

I am wondering what would be a good solution to at least avoid crashes...

Regards,
Christophe

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

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

Versions of packages intel-media-va-driver depends on:
ii  libc6  2.30-4
ii  libgcc-s1  10.2.0-16
ii  libigdgmm1120.3.2+ds1-1
ii  libstdc++6 10.2.0-16
ii  libva2 [libva-driver-abi-1.9]  2.9.0-1

intel-media-va-driver recommends no packages.

intel-media-va-driver suggests no packages.

-- no debconf information

Bug#973441: obs-studio: Adding the noise canceling filter causes a segmentation fault

[Christophe Lohr]

Package: obs-studio
Version: 26.0.2+dfsg1-1
Severity: normal
Tags: upstream

Dear Maintainer,

When I try to add the noise suppress filter on my mic, obs stops with a
segfault.


This is the output on the console:

info: User added filter 'Noise Suppression' (noise_suppress_filter_v2) to
source 'Capture Audio (Entrée PulseAudio)'
Erreur de segmentation (core dumped)


This is what gdp says about the core file:

Core was generated by `obs'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fd338c7eb71 in _celt_autocorr () from /lib/x86_64-linux-
gnu/libcodec2.so.0.9
[Current thread is 1 (Thread 0x7fd2f25c7700 (LWP 3578386))]
(gdb) bt
#0  0x7fd338c7eb71 in _celt_autocorr () at /lib/x86_64-linux-
gnu/libcodec2.so.0.9
#1  0x7fd338c7ed2a in pitch_downsample () at /lib/x86_64-linux-
gnu/libcodec2.so.0.9
#2  0x7fd2f3880006 in rnnoise_process_frame () at /usr//lib/x86_64-linux-
gnu/obs-plugins/obs-filters.so
#3  0x7fd2f3892f4c in  () at /usr//lib/x86_64-linux-gnu/obs-plugins/obs-
filters.so
#4  0x7fd33c155b8b in obs_source_output_audio () at /lib/x86_64-linux-
gnu/libobs.so.0
#5  0x7fd32800be15 in  () at /usr//lib/x86_64-linux-gnu/obs-plugins/linux-
pulseaudio.so
#6  0x7fd336823b2d in  () at /lib/x86_64-linux-gnu/libpulse.so.0
#7  0x7fd33426dbf5 in  () at /usr/lib/x86_64-linux-
gnu/pulseaudio/libpulsecommon-13.0.so
#8  0x7fd3342705ab in  () at /usr/lib/x86_64-linux-
gnu/pulseaudio/libpulsecommon-13.0.so
#9  0x7fd334270966 in  () at /usr/lib/x86_64-linux-
gnu/pulseaudio/libpulsecommon-13.0.so
#10 0x7fd3342711ba in  () at /usr/lib/x86_64-linux-
gnu/pulseaudio/libpulsecommon-13.0.so
#11 0x7fd3368391a3 in pa_mainloop_dispatch () at /lib/x86_64-linux-
gnu/libpulse.so.0
#12 0x7fd3368394ce in pa_mainloop_iterate () at /lib/x86_64-linux-
gnu/libpulse.so.0
#13 0x7fd336839570 in pa_mainloop_run () at /lib/x86_64-linux-
gnu/libpulse.so.0
#14 0x7fd336847439 in  () at /lib/x86_64-linux-gnu/libpulse.so.0
#15 0x7fd334280268 in  () at /usr/lib/x86_64-linux-
gnu/pulseaudio/libpulsecommon-13.0.so
#16 0x7fd33b1c0ea7 in start_thread (arg=) at
pthread_create.c:477
#17 0x7fd33b0f0d4f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)


Possibly the issue comes from libcodec2.so.0.9, or due to some incompatibility
with obs filters.

Best regards
Christophe



-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'testing'), (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 obs-studio depends on:
ii  libavcodec58  7:4.3.1-5
ii  libavdevice58 7:4.3.1-5
ii  libavformat58 7:4.3.1-5
ii  libavutil56   7:4.3.1-5
ii  libc6 2.31-4
ii  libcurl3-gnutls   7.72.0-1
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.2+dfsg-4
ii  libgcc-s1 10.2.0-15
ii  libjansson4   2.13.1-1
ii  libluajit-5.1-2   2.1.0~beta3+dfsg-5.1
ii  libmbedcrypto32.16.5-1
ii  libmbedtls12  2.16.5-1
ii  libmbedx509-0 2.16.5-1
ii  libobs0   26.0.2+dfsg1-1
ii  libpulse0 13.0-5
ii  libpython3.8  3.8.6-1
ii  libqt5core5a  5.14.2+dfsg-6
ii  libqt5gui55.14.2+dfsg-6
ii  libqt5svg55.14.2-2
ii  libqt5widgets55.14.2+dfsg-6
ii  libqt5x11extras5  5.14.2-2
ii  libqt5xml55.14.2+dfsg-6
ii  libspeexdsp1  1.2~rc1.2-1.1
ii  libstdc++610.2.0-15
ii  libswscale5   7:4.3.1-5
ii  libudev1  246.6-2
ii  libv4l-0  1.20.0-1.1
ii  libx11-6  2:1.6.12-1
ii  libx264-160   2:0.160.3011+gitcde9a93-2
ii  libxcb-randr0 1.14-2
ii  libxcb-shm0   1.14-2
ii  libxcb-xfixes01.14-2
ii  libxcb-xinerama0  1.14-2
ii  libxcb1   1.14-2
ii  libxcomposite11:0.4.5-1
ii  libxfixes31:5.0.3-2
ii  python3   3.8.2-3
ii  python3.8 3.8.6-1

Versions of packages obs-studio recommends:
ii  obs-plugins  26.0.2+dfsg1-1

obs-studio suggests no packages.

-- no debconf information

Bug#972974: [Pkg-clamav-devel] Bug#972974: clamav-freshclam start faild.

[jean-christophe manciot]

@Michael
Kudos :-)

On Thu, Oct 29, 2020 at 6:47 PM Michael Borgelt  wrote:
>
> Success.
> After adding 'capability dac_override' AND 'capability chown' to the
> /etc/apparmor.d/usr.bin.freshclam profile clamav-freshclam starts
> successfull.
> To succsessfull start clamav-daemon you have to set 'capability chown'
> in '/etc/apparmor.d/usr.sbin.clamd' also.
>
> Thank you
> Michael.
>
> Zitat von jean-christophe manciot :
>
> > I've just realized that lchown is only a system call, so it must be
> > used from within /usr/bin/freshclam.
> >
> > On Thu, Oct 29, 2020 at 9:33 AM jean-christophe manciot
> >  wrote:
> >>
> >> I have tried to add to /etc/apparmor.d/local/usr.bin.freshclam:
> >>   capability dac_override,
> >>
> >> and restarted apparmor then clamav-freshclam, the issue is still there:
> >> # echo 'q' | sudo systemctl --no-pager --full status clamav-freshclam
> >> ● clamav-freshclam.service - ClamAV virus database updater
> >>  Loaded: loaded (/lib/systemd/system/clamav-freshclam.service;
> >> enabled; vendor preset: enabled)
> >>  Active: failed (Result: exit-code) since Thu 2020-10-29 09:06:06
> >> CET; 42s ago
> >>Docs: man:freshclam(1)
> >>  man:freshclam.conf(5)
> >>  https://www.clamav.net/documents
> >> Process: 966650 ExecStart=/usr/bin/freshclam -d --foreground=true
> >> (code=exited, status=9)
> >>Main PID: 966650 (code=exited, status=9)
> >>
> >> Oct 29 09:06:06 hostname systemd[1]: Started ClamAV virus database updater.
> >> Oct 29 09:06:06 hostname freshclam[966650]: ERROR: lchown to user
> >> 'clamav' failed on
> >> Oct 29 09:06:06 hostname freshclam[966650]: log file
> >> '/var/log/clamav/freshclam.log'.
> >> Oct 29 09:06:06 hostname freshclam[966650]: Error was 'Operation
> >> not permitted'
> >> Oct 29 09:06:06 hostname freshclam[966650]: Thu Oct 29 09:06:06 2020
> >> -> ^lchown to user 'clamav' failed on log file
> >> '/var/log/clamav/freshclam.log'.  Error was 'Operation not permitted'
> >> Oct 29 09:06:06 hostname freshclam[966650]: Thu Oct 29 09:06:06 2020
> >> -> !Failed to switch to clamav user.
> >> Oct 29 09:06:06 hostname systemd[1]: clamav-freshclam.service: Main
> >> process exited, code=exited, status=9/n/a
> >> Oct 29 09:06:06 hostname systemd[1]: clamav-freshclam.service: Failed
> >> with result 'exit-code'.
> >>
> >> The error message regarding 'lchown' is strange: I have checked
> >> /etc/init.d/clamav-freshclam, and also config and postinst included in
> >> the DEBIAN folder of the package, none includes such a call.
> >> However, postinst does include 'chown "$dbowner":adm
> >> $FRESHCLAMLOGFILE' (with dbowner=clamav and
> >> FRESHCLAMLOGFILE=/var/log/clamav/freshclam.log), so lchown does not
> >> seem necessary wherever it is located.
> >>
> >> On Thu, Oct 29, 2020 at 12:07 AM Sebastian Andrzej Siewior
> >>  wrote:
> >> >
> >> > On 2020-10-27 07:22:22 [+], Michael Borgelt wrote:
> >> > > I have tried different permissions for the file and the
> >> directory without
> >> > > success. The obove permissions are after a clean reinstall off clamav
> >> > > package.
> >> >
> >> > The problem appears to be the apparmor or freshclam's profile for it. So
> >> > disabling apparmor should make freshclam work again.
> >> > Probably adding
> >> > | capability dac_override,
> >> >
> >> > to the profile will help, too. I will test it later today…
> >> >
> >> > Sebastian
> >>
> >>
> >>
> >> --
> >> Jean-Christophe
> >
> >
> >
> > --
> > Jean-Christophe
>
>
>
> --
> Michael Borgelt
> e-mail: mich...@borgelt.org
>


-- 
Jean-Christophe

Bug#972974: [Pkg-clamav-devel] Bug#972974: clamav-freshclam start faild.

[jean-christophe manciot]

I've just realized that lchown is only a system call, so it must be
used from within /usr/bin/freshclam.

On Thu, Oct 29, 2020 at 9:33 AM jean-christophe manciot
 wrote:
>
> I have tried to add to /etc/apparmor.d/local/usr.bin.freshclam:
>   capability dac_override,
>
> and restarted apparmor then clamav-freshclam, the issue is still there:
> # echo 'q' | sudo systemctl --no-pager --full status clamav-freshclam
> ● clamav-freshclam.service - ClamAV virus database updater
>  Loaded: loaded (/lib/systemd/system/clamav-freshclam.service;
> enabled; vendor preset: enabled)
>  Active: failed (Result: exit-code) since Thu 2020-10-29 09:06:06
> CET; 42s ago
>Docs: man:freshclam(1)
>  man:freshclam.conf(5)
>  https://www.clamav.net/documents
> Process: 966650 ExecStart=/usr/bin/freshclam -d --foreground=true
> (code=exited, status=9)
>Main PID: 966650 (code=exited, status=9)
>
> Oct 29 09:06:06 hostname systemd[1]: Started ClamAV virus database updater.
> Oct 29 09:06:06 hostname freshclam[966650]: ERROR: lchown to user
> 'clamav' failed on
> Oct 29 09:06:06 hostname freshclam[966650]: log file
> '/var/log/clamav/freshclam.log'.
> Oct 29 09:06:06 hostname freshclam[966650]: Error was 'Operation not 
> permitted'
> Oct 29 09:06:06 hostname freshclam[966650]: Thu Oct 29 09:06:06 2020
> -> ^lchown to user 'clamav' failed on log file
> '/var/log/clamav/freshclam.log'.  Error was 'Operation not permitted'
> Oct 29 09:06:06 hostname freshclam[966650]: Thu Oct 29 09:06:06 2020
> -> !Failed to switch to clamav user.
> Oct 29 09:06:06 hostname systemd[1]: clamav-freshclam.service: Main
> process exited, code=exited, status=9/n/a
> Oct 29 09:06:06 hostname systemd[1]: clamav-freshclam.service: Failed
> with result 'exit-code'.
>
> The error message regarding 'lchown' is strange: I have checked
> /etc/init.d/clamav-freshclam, and also config and postinst included in
> the DEBIAN folder of the package, none includes such a call.
> However, postinst does include 'chown "$dbowner":adm
> $FRESHCLAMLOGFILE' (with dbowner=clamav and
> FRESHCLAMLOGFILE=/var/log/clamav/freshclam.log), so lchown does not
> seem necessary wherever it is located.
>
> On Thu, Oct 29, 2020 at 12:07 AM Sebastian Andrzej Siewior
>  wrote:
> >
> > On 2020-10-27 07:22:22 [+], Michael Borgelt wrote:
> > > I have tried different permissions for the file and the directory without
> > > success. The obove permissions are after a clean reinstall off clamav
> > > package.
> >
> > The problem appears to be the apparmor or freshclam's profile for it. So
> > disabling apparmor should make freshclam work again.
> > Probably adding
> > | capability dac_override,
> >
> > to the profile will help, too. I will test it later today…
> >
> > Sebastian
>
>
>
> --
> Jean-Christophe



-- 
Jean-Christophe

Bug#972974: [Pkg-clamav-devel] Bug#972974: clamav-freshclam start faild.

[jean-christophe manciot]

I have tried to add to /etc/apparmor.d/local/usr.bin.freshclam:
  capability dac_override,

and restarted apparmor then clamav-freshclam, the issue is still there:
# echo 'q' | sudo systemctl --no-pager --full status clamav-freshclam
● clamav-freshclam.service - ClamAV virus database updater
 Loaded: loaded (/lib/systemd/system/clamav-freshclam.service;
enabled; vendor preset: enabled)
 Active: failed (Result: exit-code) since Thu 2020-10-29 09:06:06
CET; 42s ago
   Docs: man:freshclam(1)
 man:freshclam.conf(5)
 https://www.clamav.net/documents
Process: 966650 ExecStart=/usr/bin/freshclam -d --foreground=true
(code=exited, status=9)
   Main PID: 966650 (code=exited, status=9)

Oct 29 09:06:06 hostname systemd[1]: Started ClamAV virus database updater.
Oct 29 09:06:06 hostname freshclam[966650]: ERROR: lchown to user
'clamav' failed on
Oct 29 09:06:06 hostname freshclam[966650]: log file
'/var/log/clamav/freshclam.log'.
Oct 29 09:06:06 hostname freshclam[966650]: Error was 'Operation not permitted'
Oct 29 09:06:06 hostname freshclam[966650]: Thu Oct 29 09:06:06 2020
-> ^lchown to user 'clamav' failed on log file
'/var/log/clamav/freshclam.log'.  Error was 'Operation not permitted'
Oct 29 09:06:06 hostname freshclam[966650]: Thu Oct 29 09:06:06 2020
-> !Failed to switch to clamav user.
Oct 29 09:06:06 hostname systemd[1]: clamav-freshclam.service: Main
process exited, code=exited, status=9/n/a
Oct 29 09:06:06 hostname systemd[1]: clamav-freshclam.service: Failed
with result 'exit-code'.

The error message regarding 'lchown' is strange: I have checked
/etc/init.d/clamav-freshclam, and also config and postinst included in
the DEBIAN folder of the package, none includes such a call.
However, postinst does include 'chown "$dbowner":adm
$FRESHCLAMLOGFILE' (with dbowner=clamav and
FRESHCLAMLOGFILE=/var/log/clamav/freshclam.log), so lchown does not
seem necessary wherever it is located.

On Thu, Oct 29, 2020 at 12:07 AM Sebastian Andrzej Siewior
 wrote:
>
> On 2020-10-27 07:22:22 [+], Michael Borgelt wrote:
> > I have tried different permissions for the file and the directory without
> > success. The obove permissions are after a clean reinstall off clamav
> > package.
>
> The problem appears to be the apparmor or freshclam's profile for it. So
> disabling apparmor should make freshclam work again.
> Probably adding
> | capability dac_override,
>
> to the profile will help, too. I will test it later today…
>
> Sebastian



-- 
Jean-Christophe

Bug#972974: clamav-freshclam start faild.

[jean-christophe manciot]

I confirm this issue on bullseye.
There is also a similar one with clamav-daemon:

# systemctl status clamav-daemon
● clamav-daemon.service - Clam AntiVirus userspace daemon
 Loaded: loaded (/lib/systemd/system/clamav-daemon.service;
enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/clamav-daemon.service.d
 └─extend.conf
 Active: failed (Result: exit-code) since Tue 2020-10-27 09:15:31
CET; 1s ago
   Docs: man:clamd(8)
 man:clamd.conf(5)
 https://www.clamav.net/documents/
Process: 1452534 ExecStartPre=/bin/mkdir -p /run/clamav
(code=exited, status=0/SUCCESS)
Process: 1452542 ExecStartPre=/bin/chown clamav /run/clamav
(code=exited, status=0/SUCCESS)
Process: 1452550 ExecStart=/usr/sbin/clamd --foreground=true
(code=exited, status=1/FAILURE)
   Main PID: 1452550 (code=exited, status=1/FAILURE)

Oct 27 09:15:31 hostname systemd[1]: Starting Clam AntiVirus userspace daemon...
Oct 27 09:15:31 hostname systemd[1]: Started Clam AntiVirus userspace daemon.
Oct 27 09:15:31 hostname clamd[1452550]: ERROR: lchown to user
'clamav' failed on
Oct 27 09:15:31 hostname clamd[1452550]: log file '/var/log/clamav/clamav.log'.
Oct 27 09:15:31 hostname clamd[1452550]: Error was 'Operation not permitted'
Oct 27 09:15:31 hostname clamd[1452550]: Tue Oct 27 09:15:31 2020 ->
^lchown to user 'clamav' failed on log file
'/var/log/clamav/clamav.log'.  Error >
Oct 27 09:15:31 hostname systemd[1]: clamav-daemon.service: Main
process exited, code=exited, status=1/FAILURE
Oct 27 09:15:31 hostname systemd[1]: clamav-daemon.service: Failed
with result 'exit-code'.

-- 
Jean-Christophe

Bug#944030: jinja2-time: FTBFS in unstable

[Christophe Trophime]

Hi,
The patch from arch maintainer  fixes the issue
See:
https://raw.githubusercontent.com/archlinux/svntogit-community/packages/python-jinja-time/trunk/python-jinja-time-0.2.0-arrow_shift.patch

Best.

On Sat, 2 Nov 2019 18:11:35 -0700 Steve Langasek <
steve.langa...@canonical.com> wrote:
> Source: jinja2-time
> Version: 0.2.0-2
> Severity: serious
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu focal
>
> Hi Vincent,
>
> The jinja2-time source package currently fails to build from source in
> unstable:
>
> [...]
> tests/test_now.py ..FFF
 [100%]
>
> === FAILURES
===
>  test_add_time
_
>
> environment = 
>
> def test_add_time(environment):
> environment.datetime_format = '%a, %d %b %Y %H:%M:%S'
>
> template = environment.from_string(
> "{% now 'utc' + 'hours=2,seconds=30' %}"
> )
>
> >   assert template.render() == "Thu, 10 Dec 2015 01:33:31"
>
> tests/test_now.py:61:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _
> /usr/lib/python3/dist-packages/jinja2/asyncsupport.py:76: in render
> return original_render(self, *args, **kwargs)
> /usr/lib/python3/dist-packages/jinja2/environment.py:1008: in render
> return self.environment.handle_exception(exc_info, True)
> /usr/lib/python3/dist-packages/jinja2/environment.py:780: in
handle_exception
> reraise(exc_type, exc_value, tb)
> /usr/lib/python3/dist-packages/jinja2/_compat.py:37: in reraise
> raise value.with_traceback(tb)
> :1: in top-level template code
> ???
> jinja2_time/jinja2_time.py:26: in _datetime
> d = d.replace(**replace_params)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _
>
> self = 
> kwargs = {'hours': 2.0, 'seconds': 30.0}, absolute_kwargs = {}, key =
'hours'
> value = 2.0
>
> def replace(self, **kwargs):
> """ Returns a new :class:`Arrow ` object with
attributes updated
> according to inputs.
>
> Use property names to set their value absolutely::
>
> >>> import arrow
> >>> arw = arrow.utcnow()
> >>> arw
> 
> >>> arw.replace(year=2014, month=6)
> 

Bug#969739: closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#969739: fixed in xorg-server 2:1.20.9-2)

[Christophe Kalt]

please to confirm that it is indeed/again working with xserver-xorg-core
1.20.9-2

Bug#969739: Segmentation fault on startup

[Christophe Kalt]

Hi,

This isn't a conventional setup, which is why dbus isn't there, there's no
input, as I only need the output. The more unconventional part is that I'm
running X11 within a docker container. As I said, this works with an older
version, specifically, on the same host, a different container
with 2:1.20.7-2 works. Not sure what you're looking for in the kernel logs,
nothing happens when it fails to start. I'm attaching the boot sequence
logs.

Let me know what else you need, thanks.

On Thu, Sep 17, 2020 at 9:03 AM Julien Cristau  wrote:

> Control: severity -1 important
> Control: tag -1 moreinfo
>
> On Mon, Sep 07, 2020 at 11:59:34AM -0400, Christophe Kalt wrote:
> > Package: xserver-xorg-core
> > Version: 2:1.20.9-1
> > Severity: grave
> >
> > Same setup was working with 2:1.20.7-2, but with 2:1.20.9-1 crashes on
> startup
> > (xinit). /var/log/Xorg.0.log follows:
> >
> There's a number of things going wrong here...
>
> [...]
> > [881147.372] (EE) dbus-core: error connecting to system bus:
> > org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket
> /run/dbus/
> > system_bus_socket: No such file or directory)
>
> That's not good for input but probably doesn't explain the crash in
> InitOutput.
>
> [...]
> > [881147.372] (II) xfree86: Adding drm device (/dev/dri/card0)
> > [881147.372] (II) Platform probe for
> /sys/devices/pci:00/:00:02.0/drm/
> > card0
> > [881147.377] (--) PCI:*(0@0:2:0) 8086:3ea5:8086:2074 rev 1, Mem @
> 0x604b00/
> > 16777216, 0x40/134217728, I/O @ 0x4000/64, BIOS @
> 0x/131072
>
> That's Intel "Iris Plus Graphics 655".
>
> [...]
> > [881147.426] (II) modeset(G0): using drv /dev/dri/card0
> > [881147.427] (II) modeset(0): Creating default Display subsection in
> Screen
> > section
> > "Default Screen Section" for depth/fbbpp 24/32
> > [881147.427] (==) modeset(0): Depth 24, (==) framebuffer bpp 32
> > [881147.427] (EE)
> > [881147.427] (EE) Backtrace:
> > [881147.428] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x135)
> [0x557662d21f35]
> > [881147.429] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0
> (funlockfile+0x50)
> > [0x7f3bb952318f]
> > [881147.430] (EE) 2: /usr/lib/xorg/Xorg (xf86PlatformMatchDriver+0x5c0)
> > [0x557662c1a2b0]
> > [881147.430] (EE) 3: /usr/lib/xorg/Xorg (xf86CollectOptions+0x77)
> > [0x557662bfd197]
> > [881147.431] (EE) unw_get_proc_name failed: no unwind info found [-10]
> > [881147.431] (EE) 4: /usr/lib/xorg/modules/drivers/modesetting_drv.so
> (?+0x0)
> > [0x7f3bb8a25940]
> > [881147.432] (EE) 5: /usr/lib/xorg/Xorg (InitOutput+0x9ae)
> [0x557662c0085e]
> > [881147.433] (EE) 6: /usr/lib/xorg/Xorg (InitFonts+0x1cc)
> [0x557662bc235c]
> > [881147.434] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6
> (__libc_start_main+0xea)
> > [0x7f3bb936ecca]
> > [881147.434] (EE) 8: /usr/lib/xorg/Xorg (_start+0x2a) [0x557662babc9a]
> > [881147.434] (EE)
> > [881147.435] (EE) Segmentation fault at address 0x124
> > [881147.435] (EE)
> > Fatal server error:
> > [881147.435] (EE) Caught signal 11 (Segmentation fault). Server aborting
> > [881147.435] (EE)
> > [881147.435] (EE)
> > Please consult the The X.Org Foundation support
> > at http://wiki.x.org
> >  for help.
> > [881147.435] (EE) Please also check the log file at
> "/var/log/Xorg.0.log" for
> > additional information.
> > [881147.435] (EE)
> > [881147.467] (EE) Server terminated with error (1). Closing log file.
>
> Any details you can provide as to the setup and how you're starting Xorg?
>
> Please also provide a kernel log.
>
> Cheers,
> Julien
>
[0.00] Linux version 5.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 (2020-09-05)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-5.8.0-1-amd64 root=/dev/mapper/vg0-root ro
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
[0.00] x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
[0.00] x86/fpu: Enabled xstate feat

Bug#969739: Segmentation fault on startup

[Christophe Kalt]

Package: xserver-xorg-core
Version: 2:1.20.9-1
Severity: grave

Same setup was working with 2:1.20.7-2, but with 2:1.20.9-1 crashes on
startup (xinit). /var/log/Xorg.0.log follows:

[881147.371]
X.Org X Server 1.20.9
X Protocol Version 11, Revision 0
[881147.371] Build Operating System: Linux 4.19.0-10-amd64 x86_64 Debian
[881147.371] Current Operating System: Linux 74d490b3be43 5.7.0-3-amd64 #1
SMP Debian 5.7.17-1 (2020-08-23) x86_64
[881147.371] Kernel command line: BOOT_IMAGE=/vmlinuz-5.7.0-3-amd64
root=/dev/mapper/vg0-root ro
[881147.371] Build Date: 31 August 2020  03:49:48PM
[881147.371] xorg-server 2:1.20.9-1 (https://www.debian.org/support)
[881147.371] Current version of pixman: 0.36.0
[881147.371] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[881147.371] Markers: (--) probed, (**) from config file, (==) default
setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[881147.371] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Sep  7
11:37:50 2020
[881147.371] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[881147.371] (==) No Layout section.  Using the first Screen section.
[881147.371] (==) No screen section available. Using defaults.
[881147.371] (**) |-->Screen "Default Screen Section" (0)
[881147.371] (**) |   |-->Monitor ""
[881147.372] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[881147.372] (==) Automatically adding devices
[881147.372] (==) Automatically enabling devices
[881147.372] (==) Automatically adding GPU devices
[881147.372] (==) Max clients allowed: 256, resource mask: 0x1f
[881147.372] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not
exist.
[881147.372] Entry deleted from font path.
[881147.372] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not
exist.
[881147.372] Entry deleted from font path.
[881147.372] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not
exist.
[881147.372] Entry deleted from font path.
[881147.372] (WW) The directory "/usr/share/fonts/X11/Type1" does not exist.
[881147.372] Entry deleted from font path.
[881147.372] (WW) The directory "/usr/share/fonts/X11/100dpi" does not
exist.
[881147.372] Entry deleted from font path.
[881147.372] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[881147.372] Entry deleted from font path.
[881147.372] (==) FontPath set to:
/usr/share/fonts/X11/misc,
built-ins
[881147.372] (==) ModulePath set to "/usr/lib/xorg/modules"
[881147.372] (II) The server relies on udev to provide the list of input
devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[881147.372] (II) Loader magic: 0x557662daee20
[881147.372] (II) Module ABI versions:
[881147.372] X.Org ANSI C Emulation: 0.4
[881147.372] X.Org Video Driver: 24.1
[881147.372] X.Org XInput driver : 24.1
[881147.372] X.Org Server Extension : 10.0
[881147.372] (EE) dbus-core: error connecting to system bus:
org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket
/run/dbus/system_bus_socket: No such file or directory)
[881147.372] (--) using VT number 2

[881147.372] (II) systemd-logind: logind integration requires -keeptty and
-keeptty was not provided, disabling logind integration
[881147.372] (II) xfree86: Adding drm device (/dev/dri/card0)
[881147.372] (II) Platform probe for
/sys/devices/pci:00/:00:02.0/drm/card0
[881147.377] (--) PCI:*(0@0:2:0) 8086:3ea5:8086:2074 rev 1, Mem @
0x604b00/16777216, 0x40/134217728, I/O @ 0x4000/64, BIOS @
0x/131072
[881147.377] (II) LoadModule: "glx"
[881147.378] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[881147.378] (II) Module glx: vendor="X.Org Foundation"
[881147.378] compiled for 1.20.9, module version = 1.0.0
[881147.378] ABI class: X.Org Server Extension, version 10.0
[881147.378] (==) Matched modesetting as autoconfigured driver 0
[881147.378] (==) Matched fbdev as autoconfigured driver 1
[881147.378] (==) Matched vesa as autoconfigured driver 2
[881147.378] (==) Assigned the driver to the xf86ConfigLayout
[881147.378] (II) LoadModule: "modesetting"
[881147.378] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[881147.378] (II) Module modesetting: vendor="X.Org Foundation"
[881147.378] compiled for 1.20.9, module version = 1.20.9
[881147.378] Module class: X.Org Video Driver
[881147.378] ABI class: X.Org Video Driver, version 24.1
[881147.378] (II) LoadModule: "fbdev"
[881147.378] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[881147.378] (II) Module fbdev: vendor="X.Org Foundation"
[881147.378] compiled for 1.20.0, module version = 0.5.0
[881147.379] Module class: X.Org Video Driver
[881147.379] ABI class: X.Org Video Driver, version 24.0
[881147.379] (II) LoadModule: "vesa"
[881147.379] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[881147.379] (II) Module vesa: vendor="X.Org Fo

Bug#969252: libavcodec58: vcsm_init_ex not found

[Christophe Migliorini]

Package: libavcodec58
Version: 7:4.1.6-1~deb10u1+rpt1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I invoked a program that uses libavcodec58

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

examples
- ffmpeg -i 
- systemctl start minidlna
- minidlna -R

   * What was the outcome of this action?

I get the following error message (in the logs or on the console depending on 
the program I invoke)

: symbol lookup error: 
/usr/lib/arm-linux-gnueabihf/neon/vfp/libavcodec.so.58: undefined symbol: 
vcsm_init_ex

then the program stops

   * What outcome did you expect instead?

I expected the programs to run smoothly ;)

   * more troubleshooting

Since I couldn’t make sense of the [/neon/vfp/] path 
(https://packages.debian.org/search?searchon=contents&keywords=libavcodec.so.58&mode=exactfilename&suite=stable&arch=any
 only lists files in /usr/lib/arm-linux-gnueabihf/, I removed it and got the 
same result.

Then I recompiled from source (apt source ffmpeg, then compile with options 
below) and did not get any more luck.

ALSO: build fails when adding --enable-rpi to below configuration options, with 
first error being

libavdevice/rpi_vout.c:98:16: error: ‘MMAL_ENCODING_YUV10_COL’ undeclared 
(first use in this function); did you mean ‘MMAL_ENCODING_YV12’?
 return MMAL_ENCODING_YUV10_COL;
^~~
MMAL_ENCODING_YV12


BELOW
- reportbug output
— cpuinfo
- recompile options

** REPORTBUG OUTPUT

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 4.9.0-6-rpi2 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libavcodec58 depends on:
ii  libaom0  1.0.0-3
ii  libavutil56  7:4.1.6-1~deb10u1+rpt1
ii  libc62.28-10+rpi1
ii  libcairo21.16.0-4+rpt1
ii  libcodec2-0.8.1  0.8.1-2
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgsm1  1.0.18-2
ii  liblzma5 5.2.4-1
ii  libmp3lame0  3.100-2+b1
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libopus0 1.3-1
ii  libraspberrypi0  1.20180328-1~nokernel1
ii  librsvg2-2   2.44.10-2.1+rpi1
ii  libshine33.1.1-2+b1
ii  libsnappy1v5 1.1.7-1
ii  libspeex11.2~rc1.2-1+b2
ii  libswresample3   7:4.1.6-1~deb10u1+rpt1
ii  libtheora0   1.1.1+dfsg.1-15
ii  libtwolame0  0.3.13-4
ii  libva2   2.4.0-1
ii  libvorbis0a  1.3.6-2
ii  libvorbisenc21.3.6-2
ii  libvpx5  1.7.0-3+deb10u1
ii  libwavpack1  5.1.0-6
ii  libwebp6 0.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx264-155  2:0.155.2917+git0a84d98-2+rpi1
ii  libx265-165  2.9-4
ii  libxvidcore4 2:1.3.5-1
ii  libzvbi0 0.2.35-16
ii  zlib1g   1:1.2.11.dfsg-1

libavcodec58 recommends no packages.

libavcodec58 suggests no packages.

-- no debconf information

** CPUINFO

processor   : 0
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc07
CPU revision: 5

processor   : 1
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc07
CPU revision: 5

processor   : 2
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc07
CPU revision: 5

processor   : 3
model name  : ARMv7 Processor rev 5 (v7l)
BogoMIPS: 38.40
Features: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 
idiva idivt vfpd32 lpae evtstrm 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc07
CPU revision: 5

Hardware: BCM2835
Revision: a01041
Serial  : fbd62671

** RECOMPILE OPTIONS

./configure --prefix=/usr --enable-gpl --enable-libx264 --disable-programs 
--enable-mmal --enable-omx --enable-omx-rpi --enable-decoder=h264_mmal 
--enable-decoder=mpeg2_mmal --enable-encoder=h264_omx --enable-encoder=h264_omx 
--enable-nonfree --enable-gpl --enable-avresample --enable-shared 
--enable-libass  --enable-libfreetype --enable-libmp3lame --enable-libopus 
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libzvbi 
--enable-shared --disable-static --disable-doc

Bug#968807: llvm-toolchain-11: FTBS on Bulleye

[Christophe CT. TROPHIME]

Package: llvm-toolchain-11
Version: 11.0.0~+rc1-2
Severity: important

Dear Maintainer,

Hi,
Trying to build the package on Debian testing with pbuilder I run into an error
at link time:

[ 57%] Linking C shared library ../../../../lib/libomp.so.5
cd "/build/llvm-toolchain-11-11.0.0~+rc1/build-
llvm/projects/openmp/runtime/src" && /usr/bin/cmake -E cmake_link_script
CMakeFiles/omp.dir/link.txt --verbose=1
/usr/bin/gcc-10 -fPIC -g -O2 -fdebug-prefix-map=/build/llvm-
toolchain-11-11.0.0~+rc1=. -fstack-protector-strong -Wformat -Werror=format-
security -fPIC -Werror=date-time -Wall -Wextra
-Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic
-Wno-long-long -Wimplicit-fallthrough -Wno-comment -ffunction-sections -fdata-
sections -Wall -Wcast-qua
l -Wimplicit-fallthrough -Wsign-compare -Wno-extra -Wno-pedantic -Wno-maybe-
uninitialized -O2 -g -DNDEBUG -Wl,--warn-shared-textrel -Wl,--as-needed -Wl,--
version-script=/build/llvm-to
olchain-11-11.0.0~+rc1/openmp/runtime/src/exports_so.txt -static-libgcc
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,defs -Wl,-z,nodelete -shared
-Wl,-soname,libomp.so.5 -o ../../../../lib/
libomp.so.5 CMakeFiles/omp.dir/kmp_alloc.cpp.o
CMakeFiles/omp.dir/kmp_atomic.cpp.o CMakeFiles/omp.dir/kmp_csupport.cpp.o
CMakeFiles/omp.dir/kmp_debug.cpp.o CMakeFiles/omp.dir/kmp_itt.
cpp.o CMakeFiles/omp.dir/kmp_environment.cpp.o
CMakeFiles/omp.dir/kmp_error.cpp.o CMakeFiles/omp.dir/kmp_global.cpp.o
CMakeFiles/omp.dir/kmp_i18n.cpp.o CMakeFiles/omp.dir/kmp_io.cpp.o
 CMakeFiles/omp.dir/kmp_runtime.cpp.o CMakeFiles/omp.dir/kmp_settings.cpp.o
CMakeFiles/omp.dir/kmp_str.cpp.o CMakeFiles/omp.dir/kmp_tasking.cpp.o
CMakeFiles/omp.dir/kmp_threadprivate.
cpp.o CMakeFiles/omp.dir/kmp_utility.cpp.o CMakeFiles/omp.dir/kmp_barrier.cpp.o
CMakeFiles/omp.dir/kmp_wait_release.cpp.o CMakeFiles/omp.dir/kmp_affinity.cpp.o
CMakeFiles/omp.dir/kmp_
dispatch.cpp.o CMakeFiles/omp.dir/kmp_lock.cpp.o
CMakeFiles/omp.dir/kmp_sched.cpp.o CMakeFiles/omp.dir/z_Linux_util.cpp.o
CMakeFiles/omp.dir/kmp_gsupport.cpp.o CMakeFiles/omp.dir/thir
dparty/ittnotify/ittnotify_static.cpp.o CMakeFiles/omp.dir/kmp_taskdeps.cpp.o
CMakeFiles/omp.dir/kmp_cancel.cpp.o CMakeFiles/omp.dir/kmp_ftn_cdecl.cpp.o
CMakeFiles/omp.dir/kmp_ftn_ext
ra.cpp.o CMakeFiles/omp.dir/kmp_version.cpp.o CMakeFiles/omp.dir/ompt-
general.cpp.o CMakeFiles/omp.dir/z_Linux_asm.S.o  -lpthread -ldl -Wl,--version-
script=/build/llvm-toolchain-11-11
.0.0~+rc1/openmp/runtime/src/exports_so.txt
/usr/bin/ld: duplicate version tag `VERSION'
/usr/bin/ld: duplicate version tag `OMP_1.0'
/usr/bin/ld: duplicate version tag `OMP_2.0'
/usr/bin/ld: duplicate version tag `OMP_3.0'
/usr/bin/ld: duplicate version tag `OMP_3.1'
/usr/bin/ld: duplicate version tag `OMP_4.0'
/usr/bin/ld: duplicate version tag `OMP_4.5'
/usr/bin/ld: duplicate version tag `GOMP_1.0'
/usr/bin/ld: duplicate version tag `GOMP_2.0'
/usr/bin/ld: duplicate version tag `GOMP_3.0'
/usr/bin/ld: duplicate version tag `GOMP_4.0'
/usr/bin/ld: duplicate version tag `GOMP_4.5'
/usr/bin/ld: duplicate version tag `GOMP_5.0'
collect2: error: ld returned 1 exit status
make[2]: *** [projects/openmp/runtime/src/CMakeFiles/omp.dir/build.make:552:
lib/libomp.so.5] Error 1
make[2]: Target 'projects/openmp/runtime/src/CMakeFiles/omp.dir/build' not
remade because of errors.
make[2]: Leaving directory '/build/llvm-toolchain-11-11.0.0~+rc1/build-llvm'

No idea how to fix this.
Best
C.



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

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

Bug#967703: Existing proposal to port Pixelize to GTK3.

[Jean-Christophe DUBOIS]

I already provided a "port" of pixelize to gtk3 as documented in 
.


I tried to notify the official maintainer (com> or ) for this proposal but I did not 
received any feedback.


Regards.

JC

Bug#964929: iris_dri.so: Segmentation Fault

[Christophe Lohr]

Package: libgl1-mesa-dri
Version: 20.1.2-1
Severity: important
Tags: upstream

Dear Maintainer,
  Many applications fail to start on my PC wuth a Segmentation fault (ffplay 
mplayer kdenlive obs-studio)
Each time, the core file seems to point an issue with the 
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so library:


Core was generated by `ffplay /home/clohr/test.mkv'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Unexpected size of section `.reg-xstate/338339' in core file.
#0  0x7f0e3528dbcf in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
[Current thread is 1 (Thread 0x7f0e36cbf300 (LWP 338339))]
(gdb) bt
#0  0x7f0e3528dbcf in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#1  0x7f0e354575a4 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#2  0x7f0e35267b4d in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7f0e352688bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7f0e347f82bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x7f0e4349a01a in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#6  0x7f0e4348d911 in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#7  0x7f0e434930bd in  () at /lib/x86_64-linux-gnu/libSDL2-2.0.so.0
#8  0x5576924e159c in  ()
#9  0x5576924e79cf in  ()
#10 0x5576924d77f0 in main ()
(gdb) 


Some info about my graphic card:
# lspci |grep VGA
00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 
520] (rev 07)


As a workarround I use the following environment variable:
export MESA_LOADER_DRIVER_OVERRIDE=i965

Best regards
Christophe


-- Package-specific info:
glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_no_error, 
GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_no_error, 
GLX_ARB_create_context_profile, GLX_ARB_create_context_robustness, 
GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_query_renderer, GLX_MESA_swap_control, GLX_OML_swap_method, 
GLX_OML_sync_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 520 (SKL GT2) (0x1916)
Version: 20.1.2
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 520 (SKL GT2)
OpenGL core profile version string: 4.6 (Core Profile) M

Bug#964542: kdenlive: Segmentation fault at startup

[christophe . lohr]

>> this looks like a bug in your video driver or Qt5.

Hi,
  May I propose the following workarround:   edit 
/usr/share/applications/org.kde.kdenlive.desktop
and change the "Exec" command by :
    Exec=env MESA_LOADER_DRIVER_OVERRIDE=i965  kdenlive %F

(this is definitely a Mesa issue ;-) )

Best regards
Christophe

Bug#964542: kdenlive: Segmentation fault at startup

[christophe . lohr]

Le 10/07/2020 à 15:43, Patrick Matthäi a écrit :
> this looks like a bug in your video driver or Qt5.
> But anyway I have just uploaded 20.04.3-1 to unstable. Could you give it
> a try? Maybe rebuilding against current libraries solves it..

Hi Patrick,
 Many thanks for your help. Unfortunately I still get the same issue
(segfault) with this new release, except that the gdb and the core file
report slightly different errors. Well, this seems to confirm that the
issue is probably due to Mesa or Qt5 libraries (how to check?). You
probably can close (or suspend) this ticket since there is no more else
to do from the kdenlive side but to expect some fix from mesa or qt side.

Best regards
Christophe

Core was generated by `kdenlive'.
Program terminated with signal SIGSEGV, Segmentation fault.
warning: Unexpected size of section `.reg-xstate/188984' in core file.
#0  0x7f7b6d314558 in ?? () from
/usr/lib/x86_64-linux-gnu/dri/iris_dri.so
[Current thread is 1 (Thread 0x7f7b169ca700 (LWP 188984))]
(gdb) bt
#0  0x7f7b6d314558 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#1  0x7f7b6d315251 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#2  0x7f7b6d4e05a4 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7f7b6d2f0b4d in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7f7b6d2f18bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x7f7b6c8812bb in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#6  0x55ed3bc5dc6c in  ()
#7  0x7f7b7ed1b6fe in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x7f7b7feca6e3 in QQuickWindowPrivate::renderSceneGraph(QSize
const&, QSize const&) () at /lib/x86_64-linux-gnu/libQt5Quick.so.5
#9  0x7f7b7fe6f39b in  () at /lib/x86_64-linux-gnu/libQt5Quick.so.5
#10 0x7f7b7fe73837 in  () at /lib/x86_64-linux-gnu/libQt5Quick.so.5
#11 0x7f7b7eb11988 in  () at /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7f7b7dd6cf27 in start_thread (arg=)
    at pthread_create.c:479
#13 0x7f7b7e67131f in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

Bug#964542: kdenlive: Segmentation fault at startup

[christophe . lohr]

Hi,
  As additional info, here is what gdb say about the generated core file
(backtrace):

Current thread is 1 (Thread 0x7efe27e3be00 (LWP 30447))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7efe2fba955b in __GI_abort () at abort.c:79
#2  0x7efe15d62039 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#3  0x7efe16804070 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#4  0x7efe15d90a59 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#5  0x7efe15e1e1f8 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#6  0x7efe15d7d183 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#7  0x7efe15d706a6 in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#8  0x7efe162bb1aa in  () at /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
#9  0x7efe241830fd in  () at /lib/x86_64-linux-gnu/libGLX_mesa.so.0
#10 0x7efe2a5cbf23 in  () at /lib/x86_64-linux-gnu/libGLX.so.0
#11 0x7efe2a5cd6cf in  () at /lib/x86_64-linux-gnu/libGLX.so.0
#12 0x7efe2421755d in  () at
/usr/lib/x86_64-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
#13 0x7efe242151e7 in  () at
/usr/lib/x86_64-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
#14 0x7efe27a0483b in
QXcbIntegration::createPlatformOpenGLContext(QOpenGLContext*) const ()
at /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#15 0x7efe306fe21d in QOpenGLContext::create() () at
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#16 0x7efe306b9c08 in QGuiApplicationPrivate::init() () at
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#17 0x7efe3192b42e in QApplicationPrivate::init() () at
/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x55a0d486476b in  ()
#19 0x7efe2fbaae0b in __libc_start_main (main=0x55a0d48646b0,
argc=1, argv=0x7ffd0c860d88, init=, fini=,
rtld_fini=, stack_end=0x7ffd0c860d78) at
../csu/libc-start.c:308
#20 0x55a0d486d63a in _start ()
(gdb)


Hoping this helps
Best regards,
Christophe


Le 08/07/2020 à 15:07, Christophe Lohr a écrit :
> Package: kdenlive
> Version: 20.04.2-1
> Severity: normal
>
> Dear Maintainer,
>   At startup, kdenlive shows its splash screen, and suddenly stops with a 
> 'Segmentation fault' message.
>
> Best regards,
> Christophe
>
>
> -- Output of kdenlive
>
> WARNING : Fails to parse  "audiochannels"
> WARNING : Fails to parse  "audioconvert"
> WARNING : Fails to parse  "data_feed"
> "data_show" is blacklisted
> WARNING : Fails to parse  "imageconvert"
> "mask_apply" is blacklisted
> "mask_start" is blacklisted
> "mono" is blacklisted
> "region" is blacklisted
> "resize" is blacklisted
> "transition" is blacklisted
> "watermark" is blacklisted
> "burningtv" is blacklisted
> WARNING : Fails to parse  "telecide"
> "rgblut" is blacklisted
> "spot_remover" is blacklisted
> "text" is blacklisted
> "timer" is blacklisted
> WARNING : Fails to parse  "deinterlace"
> "frei0r.3dflippo" is blacklisted
> "frei0r.bluescreen0r" is blacklisted
> "frei0r.bw0r" is blacklisted
> "frei0r.gamma" is blacklisted
> "frei0r.invert0r" is blacklisted
> "frei0r.rgbsplit0r" is blacklisted
> "frei0r.transparency" is blacklisted
> "frei0r.vertigo" is blacklisted
> WARNING : Fails to parse  "jack"
> "jackrack" is blacklisted
> "videostab" is blacklisted
> "videostab2" is blacklisted
> "qtext" is blacklisted
> "resample" is blacklisted
> WARNING : Fails to parse  "avcolour_space"
> WARNING : Fails to parse  "avcolor_space"
> WARNING : Fails to parse  "avdeinterlace"
> WARNING : Fails to parse  "swscale"
> "avfilter.abench" is blacklisted
> "avfilter.acompressor" is blacklisted
> "avfilter.adelay" is blacklisted
> "avfilter.aecho" is blacklisted
> "avfilter.aemphasis" is blacklisted
> "avfilter.aeval" is blacklisted
> "avfilter.afade" is blacklisted
> "avfilter.afftfilt" is blacklisted
> "avfilter.agate" is blacklisted
> "avfilter.ametadata" is blacklisted
> "avfilter.arealtime" is blacklisted
> "avfilter.ashowinfo" is blacklisted
> "avfilter.channelmap" is blacklisted
> "avfilter.chorus" is blacklisted
> "avfilter.earwax" is blacklisted
> "avfilter.volume" is blacklisted
> "avfilter.volumedetect" is blacklisted
> "avfilter.ass" is blacklisted
> "avfilter.atadenoise" is blacklisted

Bug#964542: kdenlive: Segmentation fault at startup

[Christophe Lohr]

Package: kdenlive
Version: 20.04.2-1
Severity: normal

Dear Maintainer,
  At startup, kdenlive shows its splash screen, and suddenly stops with a 
'Segmentation fault' message.

Best regards,
Christophe


-- Output of kdenlive

WARNING : Fails to parse  "audiochannels"
WARNING : Fails to parse  "audioconvert"
WARNING : Fails to parse  "data_feed"
"data_show" is blacklisted
WARNING : Fails to parse  "imageconvert"
"mask_apply" is blacklisted
"mask_start" is blacklisted
"mono" is blacklisted
"region" is blacklisted
"resize" is blacklisted
"transition" is blacklisted
"watermark" is blacklisted
"burningtv" is blacklisted
WARNING : Fails to parse  "telecide"
"rgblut" is blacklisted
"spot_remover" is blacklisted
"text" is blacklisted
"timer" is blacklisted
WARNING : Fails to parse  "deinterlace"
"frei0r.3dflippo" is blacklisted
"frei0r.bluescreen0r" is blacklisted
"frei0r.bw0r" is blacklisted
"frei0r.gamma" is blacklisted
"frei0r.invert0r" is blacklisted
"frei0r.rgbsplit0r" is blacklisted
"frei0r.transparency" is blacklisted
"frei0r.vertigo" is blacklisted
WARNING : Fails to parse  "jack"
"jackrack" is blacklisted
"videostab" is blacklisted
"videostab2" is blacklisted
"qtext" is blacklisted
"resample" is blacklisted
WARNING : Fails to parse  "avcolour_space"
WARNING : Fails to parse  "avcolor_space"
WARNING : Fails to parse  "avdeinterlace"
WARNING : Fails to parse  "swscale"
"avfilter.abench" is blacklisted
"avfilter.acompressor" is blacklisted
"avfilter.adelay" is blacklisted
"avfilter.aecho" is blacklisted
"avfilter.aemphasis" is blacklisted
"avfilter.aeval" is blacklisted
"avfilter.afade" is blacklisted
"avfilter.afftfilt" is blacklisted
"avfilter.agate" is blacklisted
"avfilter.ametadata" is blacklisted
"avfilter.arealtime" is blacklisted
"avfilter.ashowinfo" is blacklisted
"avfilter.channelmap" is blacklisted
"avfilter.chorus" is blacklisted
"avfilter.earwax" is blacklisted
"avfilter.volume" is blacklisted
"avfilter.volumedetect" is blacklisted
"avfilter.ass" is blacklisted
"avfilter.atadenoise" is blacklisted
"avfilter.avgblur" is blacklisted
"avfilter.bbox" is blacklisted
"avfilter.bench" is blacklisted
"avfilter.blackdetect" is blacklisted
"avfilter.blackframe" is blacklisted
"avfilter.boxblur" is blacklisted
"avfilter.bwdif" is blacklisted
"avfilter.chromakey" is blacklisted
"avfilter.colorkey" is blacklisted
"avfilter.colormatrix" is blacklisted
"avfilter.colorspace" is blacklisted
"avfilter.convolution" is blacklisted
"avfilter.crop" is blacklisted
"avfilter.cropdetect" is blacklisted
"avfilter.curves" is blacklisted
"avfilter.datascope" is blacklisted
"avfilter.dctdnoiz" is blacklisted
"avfilter.deband" is blacklisted
"avfilter.deflate" is blacklisted
"avfilter.deinterlace_vaapi" is blacklisted
"avfilter.deshake" is blacklisted
"avfilter.despill" is blacklisted
"avfilter.doubleweave" is blacklisted
"avfilter.drawbox" is blacklisted
"avfilter.drawgraph" is blacklisted
"avfilter.drawgrid" is blacklisted
"avfilter.drawtext" is blacklisted
"avfilter.elbg" is blacklisted
"avfilter.eq" is blacklisted
"avfilter.fade" is blacklisted
"avfilter.field" is blacklisted
"avfilter.fieldhint" is blacklisted
"avfilter.fieldorder" is blacklisted
"avfilter.find_rect" is blacklisted
"avfilter.floodfill" is blacklisted
"avfilter.fspp" is blacklisted
"avfilter.gblur" is blacklisted
"avfilter.geq" is blacklisted
"avfilter.hflip" is blacklisted
"avfilter.hqdn3d" is blacklisted
"avfilter.hqx" is blacklisted
"avfilter.hue" is blacklisted
"avfilter.hwdownload" is blacklisted
"avfilter.idet" is blacklisted
"avfilter.il" is blacklisted
"avfilter.lenscorrection" is blacklisted
"avfilter.loop" is blacklisted
"avfilter.lumakey" is blacklisted
"avfilter.lut" is blacklisted
"avfilter.lutrgb" is blacklisted
"avfilter.lutyuv" is blacklisted
"avfilter.mcdeint" is blacklisted
"avfilter.metadata" is blacklisted
"avfilter.negate" is blacklis

Bug#958327: charliecloud: cannot use ch-run

[Christophe CT. TROPHIME]

On Mon, 20 Apr 2020 19:18:01 +0200 Peter Wienemann  
wrote:

> Hi Christophe,
>
> On 20.04.20 17:05, Christophe Trophime wrote:
> > Trying to run  a test example with some mount directory (ie ch-run -h
> > SRC:DST -w ./feelpp-v0.108-focal/ -- pwd)
> > I end up with error like: ch-run[190638]: error (charliecloud.c:553)
> > Same behaviour without -h nor -w options
>
> this looks like this upstream issue:
>
> https://github.com/hpc/charliecloud/issues/649
>
> (i. e. a UID lookup failure).
>
> Peter

>

Indeed, as suggested by Peter, I've tried with a "regular" user (my 
previous user was authentified against an AD domain with samba/winbind)

and it works.

It seems that this issue has been closed with latest charliecloud.
Would it be possible to upgrade charliecloud to 0.15?


However we may face on other problem with this version since user+mount 
feature is not available

see https://github.com/hpc/charliecloud/issues/638

when building charliecloud within a chroot env. Obviously this is the 
case when building package with pbuilder/cowbuilder?

How can we work around this?


Best

>
>

Bug#958329: charliecloud: user+mount is not supported

[Christophe Trophime]

This bug may be merged with #9538327

Sorry for the duplicate.

Bug#958329: charliecloud: user+mount is not supported

[Christophe Trophime]

Package: charliecloud
Version: 0.9.10-1
Severity: normal

Dear Maintainer,

Trying to run  a test example with some mount directory (ie ch-run -h SRC:DST 
-w ./feelpp-v0.108-focal/ -- pwd)
I end up with error like: ch-run[190638]: error (charliecloud.c:553)

It makes charliecloud unusable

Best
C.

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

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

Versions of packages charliecloud depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libc6  2.30-4

charliecloud recommends no packages.

Versions of packages charliecloud suggests:
pn  charliecloud-doc  
pn  docker.io 
pn  pv

-- debconf information:
* charliecloud/unpriv_userns_warning:

Bug#958327: charliecloud: cannot use ch-run

[Christophe Trophime]

Package: charliecloud 
Version: 0.9.10-1 
Severity: normal 

Dear Maintainer, 

Trying to run a test example with some mount directory (ie ch-run -h SRC:DST -w 
./feelpp-v0.108-focal/ -- pwd) 
I end up with error like: ch-run[190638]: error (charliecloud.c:553) 
Same behaviour without -h nor -w options 

It makes charliecloud unusable 

Best 
C. 

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

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

Versions of packages charliecloud depends on: 
ii debconf [debconf-2.0] 1.5.73 
ii libc6 2.30-4 

charliecloud recommends no packages. 

Versions of packages charliecloud suggests: 
pn charliecloud-doc  
pn docker.io  
pn pv  

-- debconf information: 
* charliecloud/unpriv_userns_warning: 



Christophe TROPHIME 
Research Engineer 

CNRS - LNCMI 
25, rue des Martyrs 
BP 166 
38042 GRENOBLE Cedex 9 
FRANCE 

Tel : +33 (0)4 76 88 90 02 
Fax : +33 (0) 4 76 88 10 01 
Office U 19 
M@il : christophe.troph...@lncmi.cnrs.fr 

Bug#958020: xserver-xorg-video-amdgpu: screen backlight can't be controlled by xbacklight

[Christophe CURIS]

Package: xserver-xorg-video-amdgpu
Version: 19.1.0-1
Severity: normal

Dear Maintainer,

I have a Lenovo Thinkpad T495; I am trying to get the screen's backlight under 
control.
The raw interface is working (/sys/class/backlight/amdgpu_bl0).
However I could not get it to be supported by 'xbacklight'.

As suggested in similar cases, I tried to add a configuration file with:

/etc/X11/xorg.conf.d/backlight.conf
--
Section "Device"
  Identifier  "Card0"
  Option  "Backlight"  "amdgpu_bl0"
EndSection
--

Acconding to the Xorg.log, the option is parsed but the driver does not 
supports it:

--
[   407.514] (WW) AMDGPU(0): Option "Backlight" is not used
--

This seems consistent with the man page for "amdgpu", but then I do not know 
how to
get this to work...

Regards,
Christophe.

-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Picasso [1002:15d8] (rev d2)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 483 Apr 17 14:59 options.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.4.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20200203 (Debian 9.2.1-28)) #1 SMP Debian 5.4.19-1 (2020-02-13)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 30921 Apr 17 15:11 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[   407.318] 
X.Org X Server 1.20.8
X Protocol Version 11, Revision 0
[   407.318] Build Operating System: Linux 4.19.0-8-amd64 x86_64 Debian
[   407.318] Current Operating System: Linux Necroman 5.4.0-4-amd64 #1 SMP 
Debian 5.4.19-1 (2020-02-13) x86_64
[   407.318] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-4-amd64 
root=UUID=05193e2f-a1dc-4f97-a036-af0f7fdd8534 ro quiet
[   407.318] Build Date: 31 March 2020  10:14:40AM
[   407.318] xorg-server 2:1.20.8-2 (https://www.debian.org/support) 
[   407.318] Current version of pixman: 0.36.0
[   407.318]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   407.318] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   407.318] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Apr 17 15:08:34 
2020
[   407.318] (==) Using config directory: "/etc/X11/xorg.conf.d"
[   407.318] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   407.319] (==) No Layout section.  Using the first Screen section.
[   407.319] (==) No screen section available. Using defaults.
[   407.319] (**) |-->Screen "Default Screen Section" (0)
[   407.319] (**) |   |-->Monitor ""
[   407.319] (==) No device specified for screen "Default Screen Section".
Using the first device section listed.
[   407.319] (**) |   |-->Device "Card0"
[   407.319] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   407.319] (**) Option "DontZap" "on"
[   407.319] (**) Option "DontZoom" "on"
[   407.319] (**) Option "DisableVidModeExtension" "yes"
[   407.319] (**) Option "BlankTime" "0"
[   407.319] (==) Automatically adding devices
[   407.319] (==) Automatically enabling devices
[   407.319] (==) Automatically adding GPU devices
[   407.319] (==) Max clients allowed: 256, resource mask: 0x1f
[   407.319] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   407.319]Entry deleted from font path.
[   407.319] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[   407.319]Entry deleted from font path.
[   407.319] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[   407.319]Entry deleted from font path.
[   407.319] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
built-ins
[   407.319] (==) ModulePath set to "/usr/lib/xorg/modules"
[   407.319] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, rec

Bug#956840: Acknowledgement (pympress: Raise an error at start)

[Christophe Troestler]

A workaround is to start it with

python3 -m pympress file.pdf

It seems there is a conflict between python3.7 (used by default by pympress) 
and python3.8 (used by most other programs).