Bug#1027780: RM: php-mf2 -- RoDM; no rdeps, outdated, no changes since 2016

[William Desportes]

Package: ftp.debian.org
Severity: normal
Usertags: rm-request
X-Debbugs-CC: bhu...@swecha.net


Hi,

I will be using: RoDM (Request of Debian Maintainer) for my requests.

You may close and deny them if you think I am mistaken. All requests are manual.


Please proceed to deleting the package php-mf2. Since 2016 there was no 
updates. Even if upstream had a new version in 2022.


List of checks:

- [x] Outdated version in Debian
- [x] Missing autopkgtests
- [x] Missing build tests
- [x] Missing Debian Vcs-* fields
- [x] Not maintained
- [x] Not used (no rdepends)
- [  ] No watch file
- [x] Upstream provides tests
- [x] Found on GitLab salsa (But d/changelogs do not match: 
https://salsa.debian.org/bhuvan/php-mf2)
- [x] Standards are outdated
- [x] Had to have a NMU upload for buildinfo files


Found on UDD by SQL: "select DISTINCT 
CONCAT('https://tracker.debian.org/pkg/',source),bin,vcs_url,vcs_browser from all_sources 
WHERE (vcs_url IS NULL OR vcs_browser IS NULL ) AND (bin LIKE '%php%' OR source LIKE 
'%php%') AND distribution = 'debian' AND release IN('sid', 'bookworm');"

--
William Desportes

Bug#1027779: ITP: receptor -- Link controllers with executors across a mesh of nodes

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: receptor
  Version : 1.3.0
  Upstream Contact: https://github.com/ansible/receptor/issues
* URL : https://github.com/ansible/receptor
* License : Apache-2.0
  Programming Lang: golang
  Description : Link controllers with executors across a mesh of nodes

Receptor is an overlay network intended to ease the distribution
of work across a large and dispersed collection of workers.
Receptor nodes establish peer-to-peer connections with each other via
existing networks.

Receptor comes as daemon and a python client. This package provides the daemon.
It is a crucial part of ansible/awx, see also
https://bugs.debian.org/908763

Current packaging work is available at
https://salsa.debian.org/go-team/packages/receptor.git

Bug#1027778: inetutils-ping: ICMPv6 Destination unreachable Unknown code 6

[Marco Moock]

Package: inetutils-ping
Version: 2:2.4-1
Severity: normal
Tags: ipv6 upstream
X-Debbugs-Cc: m...@posteo.de

Dear Maintainer,

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

Sending ICMPv6 echo request to an address where the router replies with ICMPv6 
destination unreachable - Reject route to destination. That is Type 1 code 6.
Defined in RFC4443: ftp://rfc-editor.org/in-notes/rfc4443.html
The message is:

m@ryz:~$ ping6 fd00:acd::4 -c 1
PING fd00:acd::4 (fd00:acd::4): 56 data bytes
64 bytes from fd00:abcd::1: Destination unreachable: Unknown code 6
--- fd00:acd::4 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
m@ryz:~$ 

This should be a proper message like "Route to destination rejected by ".




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

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

Versions of packages inetutils-ping depends on:
ii  libc62.36-7
ii  netbase  6.4

inetutils-ping recommends no packages.

inetutils-ping suggests no packages.

-- no debconf information

Bug#1027777: kitty: ssh kitten fails due to missing terminfo file

[Jesse Weaver]

Package: kitty
Version: 0.26.5-2
Severity: normal
X-Debbugs-Cc: pianohac...@gmail.com

Dear Maintainer,

The kitty ssh integration (the ssh kitten, as documented at
https://sw.kovidgoyal.net/kitty/kittens/ssh/), fails on Debian.

As found at https://github.com/kovidgoyal/kitty/issues/5835 , it's an issue 
specific to the Debian
packaging of kitty.

`kitty +kitten ssh` fails out of the box with:

...
FileNotFoundError: [Errno 2] No such file or directory: 
'/usr/lib/kitty/terminfo/kitty.terminfo'.

It is possible to work around this error by copying the plaintext terminfo file 
to
/usr/lib/kitty/terminfo/kitty.terminfo, and the compiled terminfo file to 
/usr/lib/kitty/x/xterm-kitty .

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

Kernel: Linux 6.1.0-0-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8@iso, LC_CTYPE=en_US.UTF-8@iso (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 kitty depends on:
ii  kitty-shell-integration  0.26.5-2
ii  kitty-terminfo   0.26.5-2
ii  libc62.36-7
ii  libdbus-1-3  1.14.4-1
ii  libharfbuzz0b6.0.0-1
ii  liblcms2-2   2.13.1-1+b1
ii  libpng16-16  1.6.39-2
ii  libpython3.103.10.9-1
ii  librsync22.3.2-1+b1
ii  libssl3  3.0.7-1
ii  libwayland-client0   1.21.0-1
ii  libx11-6 2:1.8.3-3
ii  libx11-xcb1  2:1.8.3-3
ii  libxkbcommon-x11-0   1.4.1-1
ii  libxkbcommon01.4.1-1
ii  python3  3.10.6-3+b1
ii  python3.10   3.10.9-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages kitty recommends:
ii  kitty-doc 0.26.5-2
ii  libcanberra0  0.30-10

Versions of packages kitty suggests:
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b4
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b4

-- no debconf information

Bug#1027776: mlucas: FTBFS on arm64: fermat-number feature known broken on arm64

[Steve Langasek]

Package: mlucas
Version: 20.1.1-1
Severity: serious
Tags: patch
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Hi Alex,

In addition to bug #1014547 causing mlucas to fail to build on all arm
architectures, after working around this bug the package still fails to
build on arm64 where it successfully built before.  This is because the
arm64 SIMD implementation is known buggy with respect to the fermat number
feature - there is an assert in the code that causes test/fermat-test to
fail immediately:

  [...]
  ERROR: at line 1150 of file upstream/src/Mlucas.c
  Assertion failed: ARMv8 SIMD builds do not support Fermat-number testing!
  [...]

(https://launchpad.net/ubuntu/+source/mlucas/20.1.1-1ubuntu1/+build/24577469)

The previous version of mlucas was removed from testing because it depends
on python2 which has been removed, so the only options here are either to
have the ftp team remove the arm64 binary, or to ignore the test failure.

In Ubuntu, I have done the latter by applying the attached patch.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru mlucas-20.1.1/debian/rules mlucas-20.1.1/debian/rules
--- mlucas-20.1.1/debian/rules  2021-12-20 15:07:38.0 -0800
+++ mlucas-20.1.1/debian/rules  2023-01-02 00:24:48.0 -0800
@@ -13,6 +13,7 @@
 # configure script detects optimization and debbuging flags automatically
 export DEB_CFLAGS_MAINT_STRIP = -O2 -g
 
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
 # main packaging script based on dh7 syntax
 %:
@@ -24,3 +25,10 @@
 
 override_dh_auto_configure:
dh_auto_configure -- --enable-mlucas-default-path
+
+override_dh_auto_test:
+ifeq ($(DEB_HOST_ARCH, arm64)
+   dh_auto_test || true
+else
+   dh_auto_test
+endif

Bug#1027775: cctbx, autopkgtest failure, errors about directory not being empty and being unable to find files.

[Peter Michael Green]

Package: cctbx
Version: 2022.9+ds2+~3.11.2+ds1-5
Severity: serious

Despite the fix uploaded for bug 1024859 the cctbx autopkgtest is still 
failing

and preventing the package from migrating to testing.


Testing cctbx with python3.10:
Sorry: Please run this program in an empty directory.
autopkgtest [21:28:30]: test command1: ---]
command1 FAIL non-zero exit status 1



=== 316 passed, 429 skipped, 2 xfailed, 8 warnings in 14.64s ===
cp: cannot stat 'dxtbx/tests': No such file or directory
cp: cannot stat 'dxtbx/conftest.py': No such file or directory
autopkgtest [21:28:55]: test command2: ---]
command2 FAIL non-zero exit status 1

Bug#1027766: vim: backspace doesn't remove characters anymore

[Cyril Lacoux]

Hi,

Same here, it seems that the M from VIM is gone : no history on undo command, 
no completion when opening a new file and a lot things are broken.

$ dpkg -L vim-common | grep debian.vim
/usr/share/vim/@VIMCUR@/debian.vim

Everything seem ok after moving the file to /usr/share/vim/vim90.

Regards,
-- 
Cyril Lacoux

Bug#1026718: lazpaint: FTBFS: /usr/bin/ld.bfd: cannot find -lpangocairo-1.0: No such file or directory

[Juliette DAMON-ELSASS]

Hi Lucas,

Ok, I am not familiar with those build messages. So probably the dependency is 
not well defined in Lazarus or FreePascal. A temporary fix could be to indicate 
the dependency explicitly in the control file.

I've not been able to install a VM with sid. I tried with mini.iso but it told 
me about a missing kernel. I've tried instead installing a standard Debian, I 
could upgrade to bookworm, but not to sid. I could compile on bookworm with 
debuild though I did not try yet to remove "unused" packages with apt.

Anyway, there is another bug report that was made, related to the dependency of 
FPC to GTK2. I suppose it is the same thing:
https://bugs.debian.org/1026719

Indeed, the package libgtk2.0-0 depends on  libpangocairo-1.0-0. So maybe it is 
just about adding libgtk2.0-0 to the control file?

Regards,

-- 
  Juliette DAMON-ELSASS
  circu...@fastmail.com

On Mon, Jan 2, 2023, at 5:24 PM, Lucas Nussbaum wrote:
> Hi Juliette,
>
> On 31/12/22 at 01:13 +0100, Juliette DAMON-ELSASS wrote:
>> Hello Lucas,
>> 
>> Just to check, are you building using debuild or a similar tool, not calling 
>> make directly?
>> 
>> Normally all needed packages determined by the build tool or are specified 
>> in the control file.
>
> As shown in the build log, I use sbuild (with a fairly standard
> invocation).
>
> Did you try to rebuild your package with pbuilder or sbuild? What was
> the result?
>
> Lucas

Bug#1026933: Transition Qt 6.4.2

[Sebastiaan Couwenberg]

On 12/30/22 12:43, Sebastian Ramacher wrote:

On 2022-12-30 05:07:54 +0100, Patrick Franz wrote:

Qt 6.4.2~rc1 has now been built successfully on every architecture
except s390x where the builds have been queued. However, we don't see a
reason why 6.4.2 couldn't be built on s390x.


Please go ahead.


Testing migration is blocked by this hint:

 # 2022-12-31
 # uncorrdinated change of -dev package names
 block qt6-base

Can you elaborate what the maintainer needs to do to get this transition 
unblocked?


Kind Regards,

Bas

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

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Noah Meyerhans]

On Tue, Jan 03, 2023 at 03:26:37AM +0100, Marco d'Itri wrote:
> > Debian's default sysctl settings should reside in procps (as it owns
> > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> > package.
> Nowadays systemd is a source of common sysctl settings among different 
> distributions.

I've opened https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027773 to
request this sysctl setting be applied globally there.  Will keep this
bug open against iputils-ping to track the removal of the
cap_net_raw/setuid settings when that's done.

noah

Bug#1027774: RM: php-htmlawed -- RoDM; no rdeps, no watch file, no changes since 2016

[William Desportes]

Package: ftp.debian.org
Severity: normal
Usertags: rm-request
X-Debbugs-CC: bhu...@swecha.net


Hi,

I will be using: RoDM (Request of Debian Maintainer) for my requests.

You may close and deny them if you think I am mistaken. All requests are manual.


Please proceed to deleting the package php-htmlawed. Since 2016 (it's first 
upload) there was no updates.


List of checks:

- [x] Missing autopkgtests
- [x] Missing build tests
- [x] Missing Debian Vcs-* fields
- [x] Not maintained
- [x] Not used (no rdepends)
- [x] No watch file (but the salsa repo could have a file for this)
- [x] Upstream has some form of tests
- [x] Found on GitLab salsa (But d/changelogs do not match: 
https://salsa.debian.org/bhuvan/htmlawed)
- [x] Standards are outdated
- [x] Had to have a NMU upload for buildinfo files


Found on UDD by SQL: "select DISTINCT 
CONCAT('https://tracker.debian.org/pkg/',source),bin,vcs_url,vcs_browser from all_sources 
WHERE (vcs_url IS NULL OR vcs_browser IS NULL ) AND (bin LIKE '%php%' OR source LIKE 
'%php%') AND distribution = 'debian' AND release IN('sid', 'bookworm');"

--
William Desportes

Bug#1027772: bullseye-pu: package e2tools/0.1.0-3+deb11u1

[肖盛文]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: atzli...@sina.com, 1027...@bugs.debian.org, Santiago Vila 


Hi,

[ Reason ]
close #1027361: e2tools: FTBFS in bullseye (missing build-depends on e2fsprogs)

The e2tools version in unstable does not have this problem.

[ Impact ]

e2tools fails to build:

/bin/sed -e 's|[@]HAVE_EXT2FS_XATTRS_FALSE@||g' -e 
's|[@]HAVE_EXT2FS_XATTRS_TRUE@|# |g'  -e 's|[@]top_builddir@|.|g' -e 
's|[@]top_srcdir@|.|g' -e 's|[@]DD@|/bin/dd|g' -e 's|[@]MKE2FS@||g' < 
tests/simple-test.shin > tests/simple-test.sh
/bin/chmod +x tests/simple-test.sh
FAIL: tests/simple-test.sh
=
   e2tools 0.1.0: ./test-suite.log
=

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

[ Tests ]
I can confirm that installing e2fsprogs is sufficient to avoid the problem.

[ Risks ]
Basically no risk, just a change to the Build-depenendency of the e2fsprogs
binary package.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable
  [x] the issue is verified as fixed in unstable

[ Changes ]

Add e2fsprogs as a Build-dependency of the e2tools package

Thanks!
diff -Nru e2tools-0.1.0/debian/changelog e2tools-0.1.0/debian/changelog
--- e2tools-0.1.0/debian/changelog  2020-12-15 09:50:50.0 +0800
+++ e2tools-0.1.0/debian/changelog  2023-01-03 10:18:46.0 +0800
@@ -1,3 +1,29 @@
+e2tools (0.1.0-3+deb11u1) bullseye; urgency=medium
+
+  * Rebuild for bullseye
+
+ -- xiao sheng wen   Tue, 03 Jan 2023 10:18:46 +0800
+
+e2tools (0.1.0-3) unstable; urgency=medium
+
+  * d/control:
+  - Build-Depends + e2fsprogs(Closes: #1027361), Thanks Santiago Vila
+  - Bump Standards-Version: 4.6.2
+  * Ran wrap-and-sort -t -a -s
+  * update-debian-copyright to 2023 year
+
+ -- xiao sheng wen   Sun, 01 Jan 2023 08:59:07 +0800
+
+e2tools (0.1.0-2) unstable; urgency=medium
+
+  * d/control: Bump Standards-Version: 4.6.0
+  * d/rules: remove override_dh_clean target to
+ fix lintian temporary-debhelper-file
+  * d/watch: use @PACKAGE@ @ARCHIVE_EXT@ @ANY_VERSION@
+  * update-debian-copyright to 2021 year
+
+ -- xiao sheng wen   Fri, 17 Dec 2021 09:37:53 +0800
+
 e2tools (0.1.0-1) unstable; urgency=medium
 
   * change Vcs-Git to https://salsa.debian.org/debian/e2tools.git
@@ -12,13 +38,12 @@
   * d/copyright:
   - debian/* add email atzli...@sina.com
   - update Upstream-Contact, Upstream-Source, etc.
-  - add email and date info from AUTHORS, NEWS.md, e2tool-e2ls.c, etc.
   * d/rules: delete "export CC"
   * d/watch: update to version 4,update the new upstream URL
   * add upstream/metadata
   * d/manpages: upstream had included the debian's man
 
- -- xiao sheng wen   Tue, 15 Dec 2020 09:50:50 +0800
+ -- xiao sheng wen   Mon, 14 Dec 2020 15:56:30 +0800
 
 e2tools (0.0.16-7) unstable; urgency=medium
 
diff -Nru e2tools-0.1.0/debian/control e2tools-0.1.0/debian/control
--- e2tools-0.1.0/debian/control2020-12-14 14:55:35.0 +0800
+++ e2tools-0.1.0/debian/control2023-01-03 10:18:46.0 +0800
@@ -2,9 +2,14 @@
 Section: misc
 Priority: optional
 Maintainer: xiao sheng wen 
-Build-Depends: debhelper-compat (= 13), e2fslibs-dev, uuid-dev, ss-dev,
+Build-Depends:
+ debhelper-compat (= 13),
+ e2fslibs-dev,
+ e2fsprogs,
  pkgconf,
-Standards-Version: 4.5.1
+ ss-dev,
+ uuid-dev,
+Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Homepage: https://e2tools.github.io
 Vcs-Browser: https://salsa.debian.org/debian/e2tools
@@ -12,7 +17,9 @@
 
 Package: e2tools
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: utilities for manipulating files in an ext2/ext3 filesystem
  E2tools is a simple set of utilities to read, write, and manipulate
  files in an ext2/ext3 filesystem.
diff -Nru e2tools-0.1.0/debian/copyright e2tools-0.1.0/debian/copyright
--- e2tools-0.1.0/debian/copyright  2020-12-15 09:49:35.0 +0800
+++ e2tools-0.1.0/debian/copyright  2023-01-03 10:18:46.0 +0800
@@ -5,17 +5,17 @@
 
 Files: *
 Copyright:
- 1993-1997 Theodore Ts'o 
- 2002-2004 Keith W. Sheffield 
+ 1997 Theodore Ts'o
+ 2002 Keith W. Sheffield
  2007- Hans Ulrich Niedermann 
- 2015- Christoph Gysin 
+ 2015- Christoph Gysin
 License: GPL-2+
 
 Files: debian/*
 Copyright: 2003-2005 Robert Millan 
  2005 Lucas Wall 
  2009 Iulian Udrea 
- 2020- xiao sheng wen 
+ 2020-2023 xiao sheng wen 
 License: GPL-2+
 
 License: GPL-2+
@@ -24,13 +24,13 @@
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2 of the License, or
  (at your option) any later version.
- . 
+ .
  This program is distributed in the hope that it will be useful
  but WITHOUT ANY WARRANTY;

Bug#1027771: its nocompatible

[Craig Small]

For some reason the issue is not vim-ale its something broken in the
generic vim infrastructure.

debian.vim sets nocompatible which is supposed to stop the issue but it doesn't
running vim -N or putting "set nocompatible" in ~/.vimrc fixes it

Bug#1027771: vim-ale gives error messages when starting

[Craig]

Package: vim-ale
Version: 3.2.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

vim-ale is being very unhappy, this is a brand-new installation of the package, 
I previous used vim-syntastic but its going away.
I think it is assuming a particular vim version or some additional package 
installed.

My ~/.vimrc is merely:
packadd! ale

Whenever I try to edit any file I get:

Error detected while processing /usr/share/vim-ale/plugin/ale.vim:
line   48:
E697: Missing end of List ']': 
line   49:
E10: \ should be followed by /, ? or &
line   50:
E10: \ should be followed by /, ? or &
line   51:
E10: \ should be followed by /, ? or &
line   52:
E10: \ should be followed by /, ? or &
line   53:
E10: \ should be followed by /, ? or &
line   54:
E10: \ should be followed by /, ? or &
line  201:
E10: \ should be followed by /, ? or &
line  203:
E10: \ should be followed by /, ? or &
Error detected while processing 
/usr/share/vim-ale/plugin/ale.vim[331]..function ale#events#Init:
line   30:
E10: \ should be followed by /, ? or &

(hit enter)
".vimrc" 8L, 112B
Error detected while processing BufRead Autocommands for "*vimrc*"..function 
6_StarSetf[2]..FileType Autocommands for "*":
E116: Invalid arguments for function ale#events#FileTypeEvent
Error detected while processing BufRead Autocommands for "*"..function 
ale#events#ReadOrEnterEvent:
line3:
E33: No previous substitute regular expression
Error detected while processing BufWinEnter Autocommands for "*"..function 
ale#events#LintOnEnter[5]..ale#Queue[15]..ale#ShouldDoNothing:
line   60:
E488: Trailing characters: tbufvar(a:buffer, '&l:statusline') =~# 
'CtrlPMode.*funky'
Error detected while processing BufEnter Autocommands for "*"..function 
ale#events#ReadOrEnterEvent:
line3:
E33: No previous substitute regular expression


If I try to save my .vimrc file or edit a line:
".vimrc" 8L, 112B written
Error detected while processing BufWritePost Autocommands for "*"..function 
ale#events#SaveEvent[13]..ale#Queue[15]..ale#ShouldDoNothing:
line   60:
E488: Trailing characters: tbufvar(a:buffer, '&l:statusline') =~# 
'CtrlPMode.*funky'
Press ENTER or type command to continue






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

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

Versions of packages vim-ale depends on:
ii  vim 2:9.0.1000-2
ii  vim-gtk3 [vim]  2:9.0.1000-2

vim-ale recommends no packages.

vim-ale suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEXT3w9TizJ8CqeneiAiFmwP88hOMFAmOzok8SHGNzbWFsbEBk
ZWJpYW4ub3JnAAoJEAIhZsD/PITj9oIP+wSMpboOjKFZQYV+z/K6z8D0Q6VJ2TPn
fH9BHblybBpXZxVJUo2RgM3OxxSsggatz1DY8P+92OuCjlwrFeCLG7Y47Q3A7auC
5N5AjsNgvZucGPF2DfflAvT1KFfEZha9+5SjKkUANc6aS8F1kWzXZyNql+y5mfrN
vgkJXxwRD3IGihQl43ET1esZ/D8qHO8dBSYTqbrFWmmnnq5j4AjZ48dJBx2gu46r
56lkSFilITptfXIgM2CNoAu/4e1NeyfsO2fwM7GqhypN4ZG6xIYSbJ+TtsmMiED5
K5s2zfqU1P9XKUJa0G0BgjkgkdZjB/EfDSdd0G99GchCMebK8htJJjrUF08Hqz24
cVm/Fo2hnCd06XVqzatHkHPlcH6lHT1YioiU63eRgmHUbCMLNcp+bS5LRZ384Csi
84QslM54J/Lzst4W75jnmlBtFAHxR9EdBIpAn0nNc20tlzfewd/BaN3eFCsUbqsf
vy1OKuRW5rejacXRo5CbYwcQdhiY7PHVEYh2lx5KE5YwrFSfwsr137cYgjCQkFPA
IgnTxFz0vkCc4KZMFY2bJF6VoMT0dOSwdyYVg3HsCZfgtfYmg+KotTgnMu5gOn5m
2f3+uCKXLyv8pGfe2J8ZjaxAJoN4ktLXiIGqeRS2j9Qd9OZ0JNULJWlO07j2lZjG
zeZgdBQpVOhL
=PKed
-END PGP SIGNATURE-

Bug#1001248: grub-efi-amd64-bin: Add luks2 module

[Vagrant Cascadian]

On 2021-12-06, Marc Riedel wrote:
> Please add luks2 module to build-efi-images and please notice in the
> changelog, that only PBKDF2 is currently supported.

I've been poking at this, and grub-efi-amd64-bin 2.06-7 does end up with
luks2.mod on the boot partition, but it fails to load unless I disable
secure boot from EFI.

With secure boot disabled, I was able to manually decrypt a luks2 volume
with cryptomount (when using --pbkdf2 pbkdf2) ... from rough memory:

  insmod luks2
  insmod pbkdf2
  insmod password_pbkdf2
  cryptmount -u UUID
  ls (cryptN)/

Not entirely sure I actually needed to load pbkdf2 and password_pkdf2.


So it seems support is needed to make sure the luks2 module is signed
and loaded from grub.cfg when needed...


> *** /tmp/build-efi-images.patch
> --- build-efi-images.orig   2021-12-06 23:47:58.369609691 +0100
> +++ build-efi-images2021-12-06 23:48:07.717711282 +0100
> @@ -180,6 +180,7 @@
> gcry_twofish
> gcry_whirlpool
> luks
> +   luks2
> lvm
> mdraid09
> mdraid1x

Will this patch fix the signed module issue? Or is that handled some
other way?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027770: ITP: python-hatch-requirements-txt -- Read dependencies from requirements-txt

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-hatch-requirements-txt
  Version : 0.3.0
  Upstream Contact: Dominic Davis-Foster 
* URL : https://github.com/repo-helper/hatch-requirements-txt
* License : MIT/expat
  Programming Lang: Python
  Description : Read dependencies from requirements-txt

This module required for packing python-apeye-core:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027765

Where python-apeye-core dependency is needed to package python-apeye
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027764

Where the python-apeye dependency is needed for packaging:
python-shippinglabel:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027763
Which in turn is a required dependency for the package.
python-coincidence:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481

Note: 
python-coincidence is needed to run all tests in these packages:
 * python-dom-toml
 * python-consolekitm
 * python-dist-meta
 * python-shippinglabel
 * python-apeye
 * python-apeye-core
 * domdf-python-tools
 * python-shippinglabel
All under ITPs.

Bug#460070: - cron: Using day-of-month and day-of-week together doesn't work as expected

[Ángel]

The above patch by Mr. Feliz changed the semantics of crontab by making
cron AND the dom and dow fields instead of the default OR-when-not-
star. This would be more consistent overall, but that ship has sailed
decades ago.

Interestingly, the cron on early versions of UNIX [1] doesn't seem to
have that behavior but the "normal" one (it might have been a bug in
the scheduling). Although some time later it got clearly spelled on
SUSv2 [2] (probably on v1 as well), and Vixie even defines it as a
"bizarre" but "it's the standard".

With the odd behavior set in stone, using day-of-month and day-of-week
together (which would be useful, as already shown on this bug) requires
using a syntax which doesn't conflict with the previous one (that SHALL
keep working as-is).

The attached patch allows adding an optional '&&' token (surrounded by
whitespace) before the day of week field to mark that the day of week
of this line must match *in addition* to the day of month field. Since
it's a per-entry marker, lines ANDing the fields and ORing the fields
can be freely mixed in the same file. As a counterpart to &&, a '||'
token is also recognised at the same place although it's a no-op merely
for presentation purposes, since it "selects" the default behavior
(marking entries with dom and dow can be useful as an explicit reminder
of the dow gotcha).

The original crontab would look like this
21 11   5-15 * && Thuecho test1
21 11   5-15 * && Friecho test2

which is much nicer than the date tests embedded in the command


The patch is also available at
https://salsa.debian.org/Angel-guest/cron/-/tree/bug460070

Regards


[1]
https://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd/cron.c
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/cron.8
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/cron.c
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man8/cron.8
https://minnie.tuhs.org/cgi-bin/utree.pl?file=2.9BSD/usr/src/cmd/cron.c

[2] - https://pubs.opengroup.org/onlinepubs/7908799/xcu/crontab.html
Description: Allow using day-of-month and day-of-week together
 by prepending a `&&' token (surrounded by whitespace) to the
 dow field in order to take into account both dom and dow, from
 the standardised default of matching either of them.
 .
 For symmetry, an `||' is also allowed at the same place, useful
 mainly to serve as a reminder of this unintuitive behavior.
Bug-Debian: https://bugs.debian.org/460070
Last-Update: 2023-01-02
Index: cron/cron.c
===
--- cron.orig/cron.c
+++ cron/cron.c
@@ -336,6 +336,8 @@ find_jobs(vtime, db, doWild, doNonWild)
 	 * on Sundays;  '* * 1,15 * *' will run *only* the 1st and 15th.  this
 	 * is why we keep 'e->dow_star' and 'e->dom_star'.  yes, it's bizarre.
 	 * like many bizarre things, it's the standard.
+	 * We add as an extension the syntax '* * 1,15 * && Sun' to run only
+	 * on the 1st and 15th that are Sundays.
 	 */
 	for (u = db->head;  u != NULL;  u = u->next) {
 		for (e = u->crontab;  e != NULL;  e = e->next) {
@@ -345,7 +347,7 @@ find_jobs(vtime, db, doWild, doNonWild)
 			if (bit_test(e->minute, minute) &&
 			bit_test(e->hour, hour) &&
 			bit_test(e->month, month) &&
-			( ((e->flags & DOM_STAR) || (e->flags & DOW_STAR))
+			( ((e->flags & DOM_STAR) || (e->flags & (DOW_STAR | DOW_AND)))
 			  ? (bit_test(e->dow,dow) && bit_test(e->dom,dom))
 			  : (bit_test(e->dow,dow) || bit_test(e->dom,dom {
 if ((doNonWild && !(e->flags & (MIN_STAR|HR_STAR)))
Index: cron/cron.h
===
--- cron.orig/cron.h
+++ cron/cron.h
@@ -190,6 +190,7 @@ typedef	struct _entry {
 #define	WHEN_REBOOT	0x04
 #define	MIN_STAR	0x08
 #define	HR_STAR		0x10
+#define	DOW_AND		0x20
 } entry;
 
 			/* the crontab database will be a list of the
Index: cron/crontab.5
===
--- cron.orig/crontab.5
+++ cron/crontab.5
@@ -216,8 +216,13 @@ field matches the current time.  For exa
 .br
 ``30 4 1,15 * 5''
 would cause a command to be run at 4:30 am on the 1st and 15th of each
-month, plus every Friday.  One can, however, achieve the desired result
-by adding a test to the command (see the last example in EXAMPLE CRON FILE
+month, plus every Friday.  To allow running it the 1st and 15th of each
+month
+.I only when they are Friday
+this cron allows prepending a ``&&'' token before the day of week to get
+that behavior (for symmetry, it is also possible to prepend a ``||'',
+with the above default behavior).  Alternatively, one can add a test for
+the date into the command (see the last example in EXAMPLE CRON FILE
 below).
 .PP
 Instead of the first five fields, one of eight special strings may appear:
@@ -273,7 +278,8 @@ MAILTO=paul
 0 */4 1 * mon   echo "run every 4th hour on the 1st and on every Monday"
 0 0 */2 * sun   echo "run at midn on every

Bug#1027766: vim: backspace doesn't remove characters anymore

[Christoph Anton Mitterer]

Control: tags -1 - ftbfs
Control: severity -1 important

Still not used to reportbug's new numbering...

Bug#1024020: net-snmp: CVE-2022-44792 CVE-2022-44793

[Craig Small]

On Fri, 30 Dec 2022 at 18:33, Salvatore Bonaccorso  wrote:
> Upstream has addressed both issues with
> https://github.com/net-snmp/net-snmp/commit/be804106fd0771a7d05236cff36e199af077af57

I've made a debian patch and uploaded 5.9.3+dfsg-2 that has this fix.

 - Craig

Bug#1027270: guymager doesn't require libprocps

[Craig Small]

On Sat, 31 Dec 2022 at 22:21, Michael Prokop  wrote:
> I just uploaded guymager v0.8.13-2 which takes care of this.
Great, that's another one down. Thanks for the quick response.

 - Craig

Bug#1027769: cpmtools: build with libdsk?

[Jacob Nevins]

Package: cpmtools
Severity: wishlist

It would be lovely if Debian's cpmtools could be built against libdsk
(which is in Debian as of March 2018) -- these days, most of my cpmtools
usage needs a libdsk-enabled build.

Bug#1027768: cpmtools: New upstream version 2.23 available

[Jacob Nevins]

Package: cpmtools
Severity: wishlist

As subject. (Debian currently has 2.20.)

2.23 was released around Nov 2022. It adds new formats, a few new
features, and various bugfixes.
Attached, for convenience, all the upstream change descriptions between
2.20 and 2.23 (since upstream only include the most recent changes in
their tarball).

Some differences I've noticed that look relevant for packaging:
 - new man page diskdefs.5
 - there are some new configuration directives in diskdefs ("dirblks"
   and "bootsec"), and some existing formats have them added, but I
   think they are backward compatible, so shouldn't need special
   conffile handling?

(For info, upstream has also incorporated a patch that Debian used to
have, but has since fallen out of Debian:
)
Changes since 2.22:

o  Use 16 bit block pointers for file systems > 256 blocks, not >= 256
o  Translate CP/M file name character '/' to ',' for the host and back
o  dirblks in Kaypro format fixed
o  Misc fixes for directory listing
o  Added bootsec diskdefs option
o  Check Device_close return value
o  Check for too small block number when reading file data
o  Replaced obsolete macros in configure.in
o  Cygwin/Windows support did not build any more and likely not for quite
   some time, so it was removed.

Changes since 2.21:

o  Refactored curses terminal calls into own module
o  Many autoconf changes with the hope to improve portability and
   likely just breaking things
o  New diskdef for HP200

Changes since 2.20:

o  rc759 diskdef renamed to rc75x, as it works for the series
o  diskdefs.5 added
o  Many disk formats from Larry Kraemer added
o  Renamed ampdsdd to ampro400d for consistency with libdsk and because
   ampdsdd very likely was wrong
o  Check for invalid block size
o  Output line number for diskdefs errors
o  Correctly output create or access time for CP/M 3 in cpmls
o  Spectravideo SVI-728 diskdef added
o  $DESTDIR support
o  Correctly handle empty files
o  Fix block allocation for large directories.
o  Fix time stamp conversion
o  Allow user number 16-31 for CP/M 2.2
o  Intel MDS/22 formats added
o  Crash when using blocksize 16384 fixed

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Marco d'Itri]

On Jan 03, Adam Borowski  wrote:

> Debian's default sysctl settings should reside in procps (as it owns
> /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> package.
Nowadays systemd is a source of common sysctl settings among different 
distributions.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1027767: libdsk: New upstream version 1.5.19 available

[Jacob Nevins]

Package: libdsk
Severity: wishlist

As subject. (Debian currently has 1.5.9.)

1.5.19 was released 2022-02-27. As well as ~3.5 years of bugfixes (some
of which matter to me), it includes (not a complete list):

 - new utilities dsklabel, dskparse, lsgotek
 - new drivers/formats for some Apple formats and Gotek floppy emulators
 - new text-based "ldbst" format, which is very useful for fiddling with
   the details of disc images
 - bug fix for data loss in the 'rcpmfs' driver

Bug#1027766: vim: backspace doesn't remove characters anymore

[Christoph Anton Mitterer]

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


Hey.

The following probably still worked with 2:9.0.1000-1, but definitely works 
again
when going back to the version in testing (2:9.0.0813-1+b1).

When I edit a file (pre-existing or new) I can only remove characters with
backspace when I've added them previously when in edit-mode.
As soon as I leave that, then go back into edit-mode and then backspace, it 
doesn't
work anymore.

Seemed to be "specific to "my" configuration though, as it does work with 
--clean.
However, after bisecting all my vimrc’s options, none seemed to have caused it 
and
even if I fully empty the file it still doesn't work (only when I move it away).

Find my .vim/vimrc attached.


Thanks,
Chris.

-- Package-specific info:

--- real paths of main Vim binaries ---
/usr/bin/vi is /usr/bin/vim.gtk3
/usr/bin/vim is /usr/bin/vim.gtk3
/usr/bin/gvim is /usr/bin/vim.gtk3

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

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

Versions of packages vim depends on:
ii  libacl1  2.3.1-2
ii  libc62.36-7
ii  libgpm2  1.20.7-10+b1
ii  libselinux1  3.4-1+b4
ii  libsodium23  1.0.18-1
ii  libtinfo66.4-1
ii  vim-common   2:9.0.1000-2
ii  vim-runtime  2:9.0.1000-2

vim recommends no packages.

Versions of packages vim suggests:
ii  universal-ctags [ctags]  5.9.20210829.0-1
ii  vim-doc  2:9.0.1000-2
ii  vim-scripts  20210124.2

-- no debconf information
set viminfo+=n~/.vim/viminfo
set termguicolors


filetype plugin on

highlight Normal guifg=White guibg=Black
syntax enable

autocmd ColorScheme * highlight ExtraWhitespace ctermbg=red guibg=red
highlight ExtraWhitespace ctermbg=red guibg=red
autocmd InsertEnter * match ExtraWhitespace /\s\+\%#\@  :silent :set hlsearch! hlsearch?:if 
ExtraWhitespace:match none:let ExtraWhitespace=0:else:match 
ExtraWhitespace /\s\+$\| \+\ze\t/:redraw!:let 
ExtraWhitespace=1:endif
"noremap   :silent :set hlsearch! hlsearch?

set nowrap

Bug#1027765: ITP: python-apeye-core -- Main function of apeye library

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-apeye-core
  Version : 1.1.0
  Upstream Contact: Dominic Davis-Foster 
* URL : https://github.com/domdfcoding/apeye-core
* License : BSD 3-Clause 
  Programming Lang: Python
  Description : Main function of apeye library

module needed to package python-apeye
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027764

Where python-apeye is required dependency for packaging:
python-shippinglabel:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027763

Which in turn is a required dependency for the package.
python-coincidence:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481

Bug#1027764: ITP: python-apeye -- Handy tools for working with URLs and APIs

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-apeye
  Version : 1.3.0
  Upstream Contact: Dominic Davis-Foster 
* URL : https://github.com/domdfcoding/apeye
* License : LGPL-3+
  Programming Lang: Python
  Description : Handy tools for working with URLs and APIs

module needed to package python-shippinglabel:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027763

Which in turn python-shippinglabel is needed for packaging:
python-coincidence:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481

Bug#1027762: Regression Pipewire 0.63 breaks underruns breaking emacspeak accessibility

[Jason White]

I tested your supplied code with Pipewire 0.3.63-1, and reproduced the bug.

Bug#1027763: ITP: python-shippinglabel -- Utilities for handling packages

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-shippinglabel
  Version : 1.4.1
  Upstream Contact: Dominic Davis-Foster 
* URL : https://github.com/domdfcoding/shippinglabel
* License : MIT/expat
  Programming Lang: Python
  Description : Utilities for handling packages

 module needed to package python-coincidence
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027481

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

[Vincent Lefevre]

On 2023-01-02 23:08:39 +0100, Aurelien Jarno wrote:
> This U+1FAF6 character is new in Unicode 14, which is supported starting
> with glibc 2.35. Older glibc does not know about this character, causing
> mutt to display it with '?'. With newer glibc mutt displays the
> character.
> 
> Now I am not sure it is a bug in glibc, it rather seems an issue with
> screen. I can reproduce the shifts in both, stable and unstable, by
> putting this char in a file and just running cat on the file.

I've look at the "screen" code, and it has a file encoding.c with
some kind of table (intervals) of double-width characters, and it
gives the URL of a script to regenerate these tables.

Since these tables depend on the Unicode version (which depends on
the libc6 version), shouldn't the screen package have a versioned
dependency on libc6?

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

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Noah Meyerhans]

On Tue, Jan 03, 2023 at 01:48:29AM +0100, Adam Borowski wrote:
> Most settings are in /etc/sysctl.conf, especially network related ones.
> 
> That /usr/lib/sysctl.d/ path doesn't have its settings applied normally.

systemd-sysctl is run by default and processes /usr/lib/sysctl.d/.  This
is the case even on systems that don't have procps installed.

If the intent is to set sysctl values _everywhere_, then neither procps
nor systemd is the right place.

noah

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Adam Borowski]

On Mon, Jan 02, 2023 at 04:43:34PM -0800, Noah Meyerhans wrote:
> > Debian's default sysctl settings should reside in procps (as it owns
> > /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> > package.
> 
> Is that documented anywhere?  It's certainly not the case today:
> 
> $ for i in /usr/lib/sysctl.d/*.conf; do
>   dpkg -S $i
> done
> tracker-miner-fs: /usr/lib/sysctl.d/30-tracker.conf
> bubblewrap: /usr/lib/sysctl.d/50-bubblewrap.conf
> systemd-coredump: /usr/lib/sysctl.d/50-coredump.conf
> systemd: /usr/lib/sysctl.d/50-pid-max.conf
> procps: /usr/lib/sysctl.d/99-protect-links.conf

$ apt-file search /etc/sysctl
ceph-osd: /etc/sysctl.d/30-ceph-osd.conf  
corekeeper: /etc/sysctl.d/corekeeper.conf
lxc: /etc/sysctl.d/30-lxc-inotify.conf
lxd: /etc/sysctl.d/10-lxd-inotify.conf
octavia-agent: /etc/sysctl.d/octavia-agent-sysctl.conf
open-infrastructure-container-tools: /etc/sysctl.d/zz-container.conf
open-infrastructure-system-images: 
/usr/share/system-images/container-server/config/includes.chroot/etc/sysctl.d/net.ipv4.ip_forward.conf
procps: /etc/sysctl.conf
procps: /etc/sysctl.d/README.sysctl
systemd: /etc/sysctl.d/99-sysctl.conf
tup: /etc/sysctl.d/unprivileged-clone.conf

Most settings are in /etc/sysctl.conf, especially network related ones.

That /usr/lib/sysctl.d/ path doesn't have its settings applied normally.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1027762: Acknowledgement (Regression Pipewire 0.63 breaks underruns breaking emacspeak accessibility)

[Sam Hartman]

control: retitle -1 Regression Pipewire 0.3.63 breaks underruns breaking
emacspeak accessibility
control: found -1 0.3.63-1

I'm sorry.  I meant pipewire 0.3.59 works and 0.3.63 is broken.
I apologize for the sloppiness.

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Noah Meyerhans]

On Tue, Jan 03, 2023 at 01:36:30AM +0100, Adam Borowski wrote:
> > > I'm entirely happy to reassign this request to systemd and have the
> > > setting applied more broadly.
> > Some options:
> > - conflict with systemd < version_with_the_new_default
> > - wait for a full release and then just drop it
> > - when sysctl in postinst reports the new default
> > - a mix of the last two options
> 
> Debian's default sysctl settings should reside in procps (as it owns
> /sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
> package.

Is that documented anywhere?  It's certainly not the case today:

$ for i in /usr/lib/sysctl.d/*.conf; do
  dpkg -S $i
done
tracker-miner-fs: /usr/lib/sysctl.d/30-tracker.conf
bubblewrap: /usr/lib/sysctl.d/50-bubblewrap.conf
systemd-coredump: /usr/lib/sysctl.d/50-coredump.conf
systemd: /usr/lib/sysctl.d/50-pid-max.conf
procps: /usr/lib/sysctl.d/99-protect-links.conf

Bug#1027762: Regression Pipewire 0.63 breaks underruns breaking emacspeak accessibility

[Sam Hartman]

package: pipewire-pulse
severity: important
tags: accessibility
x-debbugs-cc: debian-accessibil...@lists.debian.org

Hi.  I use emacspeak, a screen reader/desktop on top of emacs for access
to terminal applications.
I noticed that the upgrade from pipewire 0.59 to pipewire 0.63 broke
speech.
I'd get the initial output from emacspeak but  not anything else.
After some digging around, I've reduced things to a much simpler use of
libespeak-ng.

Emacspeak will generate streams that underrun frequently.  In
particular, it generates audio only when it it has something to say.
That used to work.
In particular, under pipewire 0.59, the following program says 'begin'
and 'end now' a few seconds later.
However under pipewire 0.63, I only get the 'begin' message.

// link against -lespeak-ng
#include 
#include 
#include 
#include 
const char * a_str = "Begin";
const char * b_str = "end now";
int main() {
  unsigned int unique_identifier = 0;
  espeak_Initialize(AUDIO_OUTPUT_PLAYBACK, 512, NULL, 0);
  assert(espeak_SetParameter(espeakRATE, 550, 0) == EE_OK);
  espeak_Synth(a_str, strlen(a_str)+1, 0, POS_CHARACTER, 0,
 espeakCHARS_UTF8 , &unique_identifier, NULL);
  sleep(3);
  espeak_Synth(b_str, strlen(b_str), 0, POS_CHARACTER, 0,
 espeakCHARS_UTF8 , &unique_identifier, NULL);
  sleep(3);
}



I've also filed an upstream issue with libespeak-ng:
https://github.com/espeak-ng/pcaudiolib/issues/23

And there's a thread on debian-accessibility starting at
https://lists.debian.org/debian-accessibility/2022/12/msg00054.html


signature.asc
Description: PGP signature

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Adam Borowski]

On Tue, Jan 03, 2023 at 12:43:31AM +0100, Marco d'Itri wrote:
> On Jan 02, Noah Meyerhans  wrote:
> > I'm entirely happy to reassign this request to systemd and have the
> > setting applied more broadly.
> Some options:
> - conflict with systemd < version_with_the_new_default
> - wait for a full release and then just drop it
> - when sysctl in postinst reports the new default
> - a mix of the last two options

Debian's default sysctl settings should reside in procps (as it owns
/sbin/sysctl and /etc/sysctl* settings) rather than some unrelated
package.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1027761: RFS: yascreen/1.92-1 -- Yet Another Screen Library - development files

[Boian Bonev]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : yascreen
   Version  : 1.92-1
   Upstream contact : Boian Bonev 
 * URL  : https://github.com/bbonev/yascreen
 * License  : LGPL-3+
 * Vcs  : https://github.com/bbonev/yascreen
   Section  : libs

The source builds the following binary packages:

  libyascreen-dev - Yet Another Screen Library (lib(n)curses
alternative)
  libyascreen1 - Yet Another Screen Library - development files

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/y/yascreen/yascreen_1.92-1.dsc

Changes since the last upload:

 yascreen (1.92-1) unstable; urgency=medium
 .
   * Update standards to 4.6.2, no changes
   * Update to new upstream release of 1.92
 - wide char input
 - soname bump

Regards,
-- 
  Boian Bonev



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

Bug#1027760: gortr appears to be unmaintained

[Marco d'Itri]

Source: gortr
Version: 0.14.7-1
Severity: serious
Tags: upstream

gortr has not been updated upstream in over two years and probably most
users at this point have switched to stayrtr for good.

Lacking new facts I do not want it in bookworm and I will probably 
request its removal during the trixie release cycle.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1027734: prometheus-blackbox-exporter: FTBFS: inconsistent test failures

[Daniel Swarbrick]

In general, the gRPC tests (in a pristine v0.23.0 checkout) seem to be 
utterly broken.


What's more, isolating the tests to just the GRPC tests fails in a 
completely different way:


$ go test ./...
ok  github.com/prometheus/blackbox_exporter (cached)
ok  github.com/prometheus/blackbox_exporter/config  (cached)
--- FAIL: TestGRPCConnection (0.00s)
    grpc_test.go:73: GRPC probe failed
panic: Fail in goroutine after TestGRPCConnection has completed

goroutine 612 [running]:
testing.(*common).Fail(0xc00023ad00)
    /usr/lib/go-1.19/src/testing/testing.go:824 +0xe5
testing.(*common).Errorf(0xc00023ad00, {0xc68a18?, 0xc000314390?}, 
{0xc00030dfc0?, 0x0?, 0xc000394ea0?})

    /usr/lib/go-1.19/src/testing/testing.go:941 +0x65
github.com/prometheus/blackbox_exporter/prober.TestGRPCConnection.func1()
    /tmp/blackbox_exporter/prober/grpc_test.go:56 +0x6e
created by github.com/prometheus/blackbox_exporter/prober.TestGRPCConnection
    /tmp/blackbox_exporter/prober/grpc_test.go:54 +0x325
FAIL    github.com/prometheus/blackbox_exporter/prober  0.013s
FAIL

vs.

$ go test -run TestGRPC ./...
ok  github.com/prometheus/blackbox_exporter (cached) [no tests to run]
ok  github.com/prometheus/blackbox_exporter/config  (cached) [no 
tests to run]

--- FAIL: TestGRPCConnection (0.00s)
    grpc_test.go:73: GRPC probe failed
--- FAIL: TestGRPCTLSConnection (0.05s)
    grpc_test.go:237: GRPC probe failed
--- FAIL: TestGRPCServiceNotFound (0.00s)
    utils_test.go:48: Expected: probe_grpc_status_code: 5, got: 
probe_grpc_status_code: 0

--- FAIL: TestGRPCHealthCheckUnimplemented (0.00s)
    utils_test.go:48: Expected: probe_grpc_status_code: 12, got: 
probe_grpc_status_code: 0

FAIL
FAIL    github.com/prometheus/blackbox_exporter/prober  0.058s
FAIL



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Marco d'Itri]

On Jan 02, Noah Meyerhans  wrote:

> I'm entirely happy to reassign this request to systemd and have the
> setting applied more broadly.  The question that arises then is what to
> do about the file-level capabilities on the ping binary.  Ideally we
> drop them entirely (including the setuid fallback), but when?
Some options:
- conflict with systemd < version_with_the_new_default
- wait for a full release and then just drop it
- when sysctl in postinst reports the new default
- a mix of the last two options

I suggest that you improve the ping error message to also mention the 
sysctl (or maybe an appropriate writeup in README.Debian?).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#988546: Ping^1: Bug#988546: iwyu.1, include-what-you-use.1: Missing sections in the manual page

[Alejandro Colomar]

Ping.

On Sat, 15 May 2021 19:13:30 +0200 Alejandro Colomar  
wrote:

Hi,

On 5/15/21 1:14 PM, Alejandro Colomar wrote:
> Package: iwyu
> Version: 8.15-2
> Severity: minor
> X-Debbugs-Cc: Alejandro Colomar (man-pages) 
> 
> Dear Maintainer,
> 
> The manual page for this package has some formatting errors,

> and has everything in the DESCRIPTION section.
> 
> I found that the upstream manual page is correct, so it's a bug specific to

> Debian.  Where is the Debian manual page coming from??
> 
> See .


I digged in Salsa, and it looks like the manual page there

is the same as the upstream one, but the ones I got installed with
`apt-get install iwyu` are very different
(,
).  Is there anything you
do when you build the package that changes them so much?

Thanks,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/




--



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027759: pylint: Missing dependency on python3-tomli for python3 < 3.11

[Guillem Jover]

Package: pylint
Version: 2.15.9-1
Severity: serious

Hi!

It looks like the recent release is missing a dependency on
python3-tomli when the python used is not at least 3.11. Seen on
test suite failures locally and on the devscripts CI pipelines:

  https://salsa.debian.org/guillem/devscripts/-/jobs/3733272#L2644

Thanks,
Guillem

Bug#1027734: prometheus-blackbox-exporter: FTBFS: inconsistent test failures

[Daniel Swarbrick]

Hi Mathias,

Given that a pristine, upstream checkout fails on that test for the last 
two releases, I think we will have to just skip the test.


See https://github.com/prometheus/blackbox_exporter/issues/969



OpenPGP_signature
Description: OpenPGP digital signature

Bug#625758: 'adduser --disabled-login' does not behave as documented.

[Colin Watson]

On Sat, Mar 19, 2022 at 11:44:05AM +0100, Marc Haber wrote:
> After discussion in policy and on debian-devel, this is what adduser is
> going to do:
> 
> - document (README.adduser-for-packages, adduser(8)) that
>   --disabled-login and --disabled-password are only defined for
>   non-system accounts. --system accounts get an invalid password and
>   /usr/sbin/nologin unless explicitly requested otherwise regardless of
>   the --disabled options. Many packages have adduser --system
>   --disabled-(login|password) in their maintainer scripts so we cannot
>   change this behavior.
> - document (adduser(8)) that --disabled-login will just not set a
>   password and leave the password in the state that useradd created.
> - change and document (adduser(8)) that --disabled-password will behave
>   like --disabled-login and additionally set the shell to
>   /usr/sbin/nologin.

FYI, this broke openssh's autopkgtests.  I've pushed
https://salsa.debian.org/ssh-team/openssh/-/commit/af3ead2202 to fix
that.

I don't think this affects normal use of OpenSSH in Debian.  The
relevant code only runs when UsePAM is disabled, and it so happens that
the way we enable UsePAM by default in Debian is via the default
/etc/ssh/sshd_config, but the regression tests use their own sshd_config
which we don't patch.  (It may be worth looking into running the
regression tests with something closer to Debian's default sshd_config
at some point; I hadn't noticed this discrepancy until today.)  However,
it could affect systems where the admin has disabled UsePAM.

I'm not sure I really follow the logic of why the behaviour of
--disabled-password was changed in this particular way; but at any rate,
I thought I'd mention this particular observed breakage in case you
weren't aware of it.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1027758: On Tyan TN71-BP012 (POWER8) Debian 11.6 successfully installed

[oliviosu_ppc64el]

Package: installation-reports

Boot method: USB stick
Image version: 
https://get.debian.org/images/release/current/ppc64el/iso-dvd/debian-11.6.0-ppc64el-DVD-1.iso
Date: 2022 Fri Dec 30 15:01

Machine: Tyan TN71-BP012
Processor: ppc64el POWER8 (raw), altivec supported
Memory: 133598MB
Partitions:
Sys. de fichiers Type blocs de 1K Utilisé Disponible Uti% Monté sur
udev devtmpfs    63386560   0   63386560   0% /dev
tmpfs    tmpfs   13359936   15168   13344768   1% /run
/dev/sda2    ext4   238263032 3925436  222161676   2% /
tmpfs    tmpfs   66799424   0   66799424   0% /dev/shm
tmpfs    tmpfs   5120   0   5120   0% /run/lock
tmpfs    tmpfs   13359872 832   13359040   1% /run/user/1000

Output of lspci -knn (or lspci -nn):
:00:00.0 PCI bridge [0604]: IBM POWER8 Host Bridge (PHB3) [1014:03dc]
0001:00:00.0 PCI bridge [0604]: IBM POWER8 Host Bridge (PHB3) [1014:03dc]
0001:01:00.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8748 48-Lane, 12-Port 
PCI Express Gen 3 (8 GT/s) Switch, 27 x 27mm FCBGA [10b5:8748] (rev ca)
0001:02:01.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8748 48-Lane, 12-Port 
PCI Express Gen 3 (8 GT/s) Switch, 27 x 27mm FCBGA [10b5:8748] (rev ca)
0001:02:02.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8748 48-Lane, 12-Port 
PCI Express Gen 3 (8 GT/s) Switch, 27 x 27mm FCBGA [10b5:8748] (rev ca)
0001:02:08.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8748 48-Lane, 12-Port 
PCI Express Gen 3 (8 GT/s) Switch, 27 x 27mm FCBGA [10b5:8748] (rev ca)
0001:02:09.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8748 48-Lane, 12-Port 
PCI Express Gen 3 (8 GT/s) Switch, 27 x 27mm FCBGA [10b5:8748] (rev ca)
0001:02:0a.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8748 48-Lane, 12-Port 
PCI Express Gen 3 (8 GT/s) Switch, 27 x 27mm FCBGA [10b5:8748] (rev ca)
0001:02:10.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8748 48-Lane, 12-Port 
PCI Express Gen 3 (8 GT/s) Switch, 27 x 27mm FCBGA [10b5:8748] (rev ca)
0001:02:11.0 PCI bridge [0604]: PLX Technology, Inc. PEX 8748 48-Lane, 12-Port 
PCI Express Gen 3 (8 GT/s) Switch, 27 x 27mm FCBGA [10b5:8748] (rev ca)
0001:03:00.0 Ethernet controller [0200]: Mellanox Technologies MT27520 Family 
[ConnectX-3 Pro] [15b3:1007]
Subsystem: Mellanox Technologies MT27520 Family [ConnectX-3 Pro] [15b3:0050]
Kernel driver in use: mlx4_core
Kernel modules: mlx4_core
0001:04:00.0 Ethernet controller [0200]: Mellanox Technologies MT27520 Family 
[ConnectX-3 Pro] [15b3:1007]
Subsystem: Mellanox Technologies MT27520 Family [ConnectX-3 Pro] [15b3:0050]
Kernel driver in use: mlx4_core
Kernel modules: mlx4_core
0001:05:00.0 SATA controller [0106]: Marvell Technology Group Ltd. 88SE9235 
PCIe 2.0 x2 4-port SATA 6 Gb/s Controller [1b4b:9235] (rev 11)
Subsystem: Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 
Gb/s Controller [1b4b:9235]
Kernel driver in use: ahci
Kernel modules: ahci
0001:06:00.0 USB controller [0c03]: Texas Instruments TUSB73x0 SuperSpeed USB 
3.0 xHCI Host Controller [104c:8241] (rev 02)
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci
0001:07:00.0 PCI bridge [0604]: ASPEED Technology, Inc. AST1150 PCI-to-PCI 
Bridge [1a03:1150] (rev 03)
0001:08:00.0 VGA compatible controller [0300]: ASPEED Technology, Inc. ASPEED 
Graphics Family [1a03:2000] (rev 30)
Subsystem: ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000]
Kernel driver in use: ast
Kernel modules: ast
0002:00:00.0 PCI bridge [0604]: IBM POWER8 Host Bridge (PHB3) [1014:03dc]


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:    [O]
Configure network:  [O] *firmware non free 
needed.(firmware-misc-nonfree_20210315-3_all.deb) mlx4_core
Detect media:   [O] *no grub menu for boot media (USB stick) have to 
create menu entry in Petitboot
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:    [O]
Clock/timezone setup:   [O]
User/password setup:    [O]
Install tasks:  [O]
Install boot loader:    [O] *grub menu on disk display in Petitboot working fine
Overall install:    [O]

Comments/Problems:
To boot USB stick "manual" Petitboot entry have to be created with:
selecting USB stick device (here sdb)
Kernel:  /install/vmlinux
Initrd:  /install/initrd.gz
Boot arguments:  /root=/dev/sdb ro quiet

After intallation grub boot menu working fine on computer SSD (here sda)

Installed system working fine Thanks.
Best regards

Bug#973617: fonts-materialdesignicons-webfont: New upstream release

[Julian Gilbey]

On Mon, Jan 02, 2023 at 07:37:10PM +, Julian Gilbey wrote:
> I just tried building node-webfont on bullseye with bullseye-backports
> and it's not happy:
> 
> The following packages have unmet dependencies:
>  sbuild-build-depends-main-dummy : Depends: node-svg2ttf but it is not 
> installable
>Depends: node-nunjucks (>= 3.2.3) but it 
> is not installable
>Depends: node-parse-json (>= 5.2.0) but 
> 5.1.0+~cs5.1.6-2 is to be installed
>Depends: node-xml2js (>= 0.4.23) but it is 
> not going to be installed
>Depends: node-jasmine but it is not 
> installable
> 
> So at least 4 (and quite possibly more) nodejs packages would have to
> be backported to bullseye-backports to be able to do this.
> (node-xml2js is too old in stable for this package.)

Another update:

* node-svg2ttf: requires node-xmldom to be backported
  * node-xmldom: builds with bullseye-backports
* node-nunjucks: builds with bullseye-backports
* node-parse-json: builds with bullseye-backports
* node-xml2js: builds with bullseye-backports
* node-jasmine: has the dependencies require to build, but the build
   fails on one of the tests

So it may only be six packages which require backporting in order to
backport node-webfont (once it reaches testing), but node-jasmine
might well require some additional help, perhaps from the maintainer;
it might be that it has a versioned dependency that has not been
declared in the build-depends.

Best wishes,

   Julian

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

[Aurelien Jarno]

Hi,

On 2023-01-02 16:34, Vincent Lefevre wrote:
> Package: libc6
> Version: 2.36-7
> Severity: serious
> 
> The new libc6 appears to have some change related to Unicode that
> yields display issues in screen 4.9.0-3, such as horizontal and/or
> vertical text shifting. A consequence of this text shifting is that
> in Mutt (in particular with arrow_cursor), one may select a message
> to be deleted, but a different message is actually deleted.
> 
> There is no such issue under bullseye (Debian 11.6), which also has
> GNU Screen 4.09.00, so the breakage appears to be due to libc6.
> 
> If the change has been done on purpose, then there are missing
> dependency relationships that should prevent the installation
> of incompatible software until such software has been updated
> to support this change.
> 
> Example to reproduce the issue with the U+1FAF6 HEART HANDS character
> under Debian/unstable:

This U+1FAF6 character is new in Unicode 14, which is supported starting
with glibc 2.35. Older glibc does not know about this character, causing
mutt to display it with '?'. With newer glibc mutt displays the
character.

Now I am not sure it is a bug in glibc, it rather seems an issue with
screen. I can reproduce the shifts in both, stable and unstable, by
putting this char in a file and just running cat on the file.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1027753: geeqie crashes on ssh-forwared remote X

[Lars Rohwedder]

Am 02.01.23 um 21:10 schrieb Andreas Rönnquist:

On Mon, 02 Jan 2023 20:44:32 +0100
Lars Rohwedder  wrote:


When I try to run "geeqie" via remote X (via "ssh -v -Y", that's why
I got the debug output from ssh, too) I got this error messages
to the console and geeqie seems to crash immediately:



Thanks for your report - Could you please try to run geeqie with the command

LIBGL_ALWAYS_INDIRECT=1 geeqie


Same result:


$ LIBGL_ALWAYS_INDIRECT=1 geeqie
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 58284
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 58294
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: channel 2: FORCE input drain
debug1: channel 2: free: x11, nchannels 3
debug1: channel 1: FORCE input drain
Segmentation fault


and report back here?

If that doesn't work, try to run geeqie with

geeqie --disable-clutter

>

Whatever this option does, but geeqie works fine with this parameter. :-D

Thank you so far! :-)

Lars R.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Noah Meyerhans]

On Mon, Jan 02, 2023 at 10:09:44PM +0100, Marco d'Itri wrote:
> > With that in place, unprivileged users are able to excute ping for both
> > IPv4 and IPv6 targets without cap_net_raw (currently set as either a
> > file-based attribute on the ping binary or acquired via setuid).  But
> > since that applies system-wide, not just to the ping binary, there may
> > be objections.
> I do not think that the submitter made clear why this would be 
> preferable, so I had to research it myself. See:
> 
> https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
> https://github.com/systemd/systemd/pull/13141
> 
> Since this is one of the systemd sysctl defaults (of which I think that 
> we should adopt more, especially the network-related ones!) I agree with 
> changing this.
> I would just do it in the systemd package package to allow all packages 
> to benefit from it without having to care if ping is installed.

I'm entirely happy to reassign this request to systemd and have the
setting applied more broadly.  The question that arises then is what to
do about the file-level capabilities on the ping binary.  Ideally we
drop them entirely (including the setuid fallback), but when?

I could leave things completely decoupled, and simply wait until systemd
makes the change and then upload iputils and assume that anybody
upgrading iputils is also upgrading systemd.  That seems to be what
Fedora did, according to the fedoraproject.org wiki cited above.
Alternatives would seem to involve some level of versioned dependency,
which doesn't feel right.

noah

Bug#1027757: xsimd: new upstream release

[Drew Parsons]

Source: xsimd
Version: 8.1.0-7
Severity: normal

Upstream has now released xsimd 10.0.0.

Pythran developers report that xsimd 10 fixes some problems managing
functions for both scalar and vector calculations.

Could a package of the new version be made?

I recommend uploading to experimental first instead of unstable,
since we're preparing to go into freeze soon for the next debian
stable release

(a chain of packages will be affected: xsimd - pythran - scipy, then
others using scipy)

Drew

Bug#983539: false positive (.DEFAULT?) E: debian-rules-missing-required-target

[Axel Beckert]

Control: tag -1 + moreinfo

Hi John,

John Scott wrote:
> This package uses Debhelper. What I think causes the false positive is
> that, instead of using a pattern rule like
> %:
>   dh $@
> 
> I use the .DEFAULT special target and also call mkdir prior, like:
> .DEFAULT:
>   mkdir -p $(unpacked_dir)
>   dh $@ -D$(unpacked_dir) -Bbuild
> 
> The .DEFAULT special target, unlike pattern rules, is specified by
> POSIX, and as Lintian indicates this is an error, I'd very much
> appreciate if this could be fixed.

Do I understand it right that ".DEFAULT:" is equivalent to "%:"?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1026931: rocminfo: fails with error "lsmod: not found"

[Étienne Mollier]

Hi Cory,

Cordell Bloor, on 2022-12-24:
> After installing rocminfo on a fresh new Debian image, I ran the command
> and saw the error:
> 
> sh: 1: lsmod: not found
> ROCk module is NOT loaded, possibly no GPU devices
> 
> After running `apt install kmod`, this problem was resolved and I saw
> normal output:
> 
> ROCk module is loaded
> 

Thanks for your report, this would have been caught by a proper
autopkgtest, so sounds like I would have to spend some time to
wrap up something.  I guess the end result would look similar to
running the test suite, with a check on /dev/kfd availability,
and a proper skip if not running on real hardware.  Shouldn't be
too hard, autopkgtest provides the appropriate knobs for that.

Best wishes,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.
On air: Nemrud - Lion Of Commagene


signature.asc
Description: PGP signature

Bug#1027756: RFP: vncdotool -- command line VNC client

[Petter Reinholdtsen]

Package: wnpp
Severity: wishlist

* Package name: vncdotool
  Version : 1.0
  Upstream Author : Marc Sibson
* URL : https://pypi.org/project/vncdotool/
* License : MIT
  Programming Lang: Python
  Description : command line VNC client

vncdotool is a command line VNC client. It can be useful to automating
interactions with virtual machines or hardware devices that are
otherwise difficult to control.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1008281: setting sysctl net.ipv4.ping_group_range

[Marco d'Itri]

On Jan 02, Noah Meyerhans  wrote:

> With that in place, unprivileged users are able to excute ping for both
> IPv4 and IPv6 targets without cap_net_raw (currently set as either a
> file-based attribute on the ping binary or acquired via setuid).  But
> since that applies system-wide, not just to the ping binary, there may
> be objections.
I do not think that the submitter made clear why this would be 
preferable, so I had to research it myself. See:

https://fedoraproject.org/wiki/Changes/EnableSysctlPingGroupRange
https://github.com/systemd/systemd/pull/13141

Since this is one of the systemd sysctl defaults (of which I think that 
we should adopt more, especially the network-related ones!) I agree with 
changing this.
I would just do it in the systemd package package to allow all packages 
to benefit from it without having to care if ping is installed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1025116: [Debian-med-packaging] Bug#1025116: python-pybedtools: (autopkgtest) needs update for python3.11: No module named 'pysam.libchtslib'

[Étienne Mollier]

Hi Andreas,

Andreas Beckmann, on 2023-01-02:
> python3-pysam is now available for python3.11, please revert the "stick
> to python3.10" changes.

Thanks for the reminder, I think I sprinkled that "fix" in a
couple of other packages, but they should crop up as I
accompanied them with a FIXME item in the control file.

Besh wishes,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#1027476: cron: postrm script fails because expected dpkg-statoverride is not present

[Jonas Smedegaard]

Control: severity -1 serious

According to Debian Policy §6.6, "all postrm actions must only rely on
essential packages and must gracefully skip any actions that require the
package’s dependencies if those dependencies are unavailable."

This bug is therefore serious.

 - Jonas

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

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

signature.asc
Description: signature

Bug#1026628: pyro4: FTBFS: AssertionError: must fail

[GCS]

Control: tags -1 +pending

Hi,

On Mon, Jan 2, 2023 at 4:15 PM Bo YU  wrote:
> Although skip failed test cases are not perfect solution to fix such
> issues, but upstream has decided to end pyro4's life on python3.10. I
> think it is ok to skip these failed test cases on python 3.10. There is
> no sense to patch test files if in order to pass these failed cases. If
> to fix pyro4's core code, I am not sure if how many work need to be
> finished.
 Just confirmed, your patch fixes this issue. Thanks for your contribution!

> PS: I would like to package pyro5 if it makes sense.:)
 Do you have packaging experience? Can you do it in a day or two?

Regards,
Laszlo/GCS

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2023-01-02, Vagrant Cascadian wrote:
> On 2022-12-28, Vagrant Cascadian wrote:
>> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those
>> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The
>> commit triggering the issue has been identified as:
>>
>>   a9bf024b2933bba0e23038892970a18b72dfaeb4
>>   efi_loader: disk: a helper function to create efi_disk objects from
>>   udevice
>>
>> Workarounds I've heard are to disable EFI support for that board
...
> Obviously, it breaks EFI booting...
>
> Worst case, I suppose we could create two variants, one with EFI, one
> without...

I have pushed a patch to git implementing an odroid-c2-noefi variant:

  
https://salsa.debian.org/debian/u-boot/-/commit/711ca985af1cab6f11e33fcf5e30dcc40dc7e64d

This would not close the bug, but at least downgrade the severity...


I still do not have confirmation if the other amlogic boards are
similarly affected.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027751: need to properly depend on python3-exceptiongroup

[Timo Röhling]

Control: notfound -1 7.1.2-4
Control: found -1 7.2.0-3

Hi,

* Nilesh Patra  [2023-01-03 00:53]:

My hunch is that the issue is this:

| $ apt show python3-pytest | grep excep
| Depends: python3-attr, python3-more-itertools, python3-pkg-resources, python3-pluggy (>= 0.12), 
python3-py, python3-exceptiongroup | python3 (>> 3.11), python3-importlib-metadata | python3 
(>> 3.8), python3-iniconfig, python3-packaging, python3-tomli | python3 (>> 3.11), 
python3:any

The "python3 (>> 3.11)" dependency is now beginning to be satisfied with doko's 
new python3.11 upload i.e. version 3.11.1 (see[1])
exceptiongroup should still be picked in this scnario, this is a bit odd 
though, but definitely worth a look.

[1]: 
https://tracker.debian.org/news/1404008/accepted-python311-3111-2-source-into-unstable/


You are probably right. Technically, this is a dh-python bug,
because dh-python generates the wrong dependency as long as Python
3.10 is still in the archive ;)

The dependency python3-exceptiongroup was added with pytest 7.2.0,
btw (I fixed the affected version).


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1027751: need to properly depend on python3-exceptiongroup

[Colin Watson]

On Tue, Jan 03, 2023 at 12:53:47AM +0530, Nilesh Patra wrote:
> While building pairtools version 1.0.2-1 I noticed this error. I have 
> temporarliy added
> a build depend on exceptiongroup in the said package to work around the issue.

I ran into the same thing in python-ws4py, and am applying the same
workaround there.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#981600: nghttp2: missing build-depends on tzdata

[Santiago Vila]

fixed 981600 1.51.0-1
thanks

Hi. For some reason this is not a problem in bookworm anymore,
therefore I'm marking this as fixed in this version.
(Could someone double-check?)

For bullseye, I propose the attached patch.

Note: Some people ask why bother to fix bugs like this
in stable when debootstrap installs tzdata by default.

Well, I believe the fact that this bug took so much time to be properly
diagnosed is an indication that adding a single line to debian/control
may save a good amount of debugging time for those who work with minimal
chroots (i.e. without packages which are really not build essential).

Andreas: I see that you tagged this "sid bookworm".
Should it not be really "bullseye" given that it does not happen
anymore in bookworm?

Thanks.diff -Nru nghttp2-1.43.0/debian/changelog nghttp2-1.43.0/debian/changelog
--- nghttp2-1.43.0/debian/changelog 2021-02-13 18:47:24.0 +0100
+++ nghttp2-1.43.0/debian/changelog 2023-01-02 21:18:00.0 +0100
@@ -1,3 +1,10 @@
+nghttp2 (1.43.0-1+deb11u1) bullseye; urgency=medium
+
+  * Add missing tzdata to Build-Depends, required for the unit tests
+when building the arch-dependent packages. Closes: #981600.
+
+ -- Tomasz Buchert   Mon, 02 Jan 2023 21:18:00 +0100
+
 nghttp2 (1.43.0-1) unstable; urgency=medium
 
   * New upstream release 1.43.0
diff -Nru nghttp2-1.43.0/debian/control nghttp2-1.43.0/debian/control
--- nghttp2-1.43.0/debian/control   2021-02-13 18:47:24.0 +0100
+++ nghttp2-1.43.0/debian/control   2023-01-02 21:15:08.0 +0100
@@ -16,6 +16,7 @@
libsystemd-dev,
libxml2-dev,
pkg-config,
+   tzdata,
zlib1g-dev
 Build-Depends-Indep: python3-sphinx
 Standards-Version: 4.5.1

Bug#1027176: u-boot-amlogic: broken non-EFI boot on odroid-c2

[Vagrant Cascadian]

On 2022-12-28, Vagrant Cascadian wrote:
> The odroid-c2 fails to boot syslinux/extlinux style menus (e.g. those
> produced by u-boot-menu) or boot.scr as of upstream 2022.07-rc1. The
> commit triggering the issue has been identified as:
>
>   a9bf024b2933bba0e23038892970a18b72dfaeb4
>   efi_loader: disk: a helper function to create efi_disk objects from
>   udevice
>
> Workarounds I've heard are to disable EFI support for that board, or to
> boot using EFI rather than boot scripts or syslinux/extlinux style
> menus.

Well, this patch applied to 2022.10+dfsg-2 or 2023.01~rc4+dfsg-1 is
enough to get it booting on odroid-c2 with syslinux/extlinux style menus
and boot scripts:

diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
index a4c4fc7906..281d5e0014 100644
--- a/configs/odroid-c2_defconfig
+++ b/configs/odroid-c2_defconfig
@@ -67,3 +67,4 @@ CONFIG_BMP_16BPP=y
 CONFIG_BMP_24BPP=y
 CONFIG_BMP_32BPP=y
 CONFIG_OF_LIBFDT_OVERLAY=y
+# CONFIG_EFI_LOADER is not set

Obviously, it breaks EFI booting...

Worst case, I suppose we could create two variants, one with EFI, one
without...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1027755: libclamav11: unable to install over libclamav9 which cyrus-common 3.6.0-1 depends on

[Andy Dorman]

Package: libclamav11
Version: 1.0.0+dfsg-1
Severity: important

Dear Maintainer,

Tried to install Clamav 1.0.0 to try and fix libclamav9 bug #1027130.

When I try to install, aptitude/dpkg returns ths error:

Preparing to unpack .../libclamav11_1.0.0+dfsg-1_amd64.deb ...
Unpacking libclamav11:amd64 (1.0.0+dfsg-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libclamav11_1.0.0+dfsg-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libfreshclam.so.2', which is 
also in package libclamav9:amd64 0.103.7+dfsg-1+b2
Errors were encountered while processing:
 /var/cache/apt/archives/libclamav11_1.0.0+dfsg-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
dpkg: dependency problems prevent configuration of clamav:
 clamav depends on libclamav11 (>= 1.0.0); however:
  Package libclamav11:amd64 is not installed.


I am unable to delete libclamav9 due to cyrus 3.6.0-1 dependency.


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

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

Versions of packages libclamav11 depends on:
ii  libbz2-1.01.0.8-5+b1
ii  libc6 2.36-7
ii  libcurl4  7.87.0-1
ii  libgcc-s1 12.2.0-11
ii  libjson-c50.16-2
ii  libmspack00.10.1-2
ii  libpcre2-8-0  10.40-3
ii  libssl3   3.0.7-1
ii  libtfm1   0.13.1-1
ii  libxml2   2.9.14+dfsg-1.1+b2
ii  zlib1g1:1.2.13.dfsg-1

libclamav11 recommends no packages.

Versions of packages libclamav11 suggests:
pn  libclamunrar   
pn  libclamunrar9  

Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

[Paul Gevers]

Hi,

On 02-01-2023 21:10, Axel Beckert wrote:

Another weird point seems that
t/recipes/checks/desktop/gnome/gir/gir/eval/desc says:

   Testname: gir
   Check: desktop/gnome/gir
   Test-Architecture: amd64

So that clearly means it should only be run on amd64. So why is it run
on arm64 at all?


I suspect this is a lintian internal, but I guess you figured that out.


Ah, ok. Yeah, kinda makes sense. I kinda expected that this version is
usually the one the bug report was written against with any additional
version hints being added as secondary version via Control statements.


I cake these reports from a template and file them in with what I see on 
ci.d.n.



P.S.: Any idea how we get Salsa CI autopkgtests on arm64?


I understand the issue is on the salsa admin side where there are issues 
with shared runners or something. There is a host available that could 
run the tests, but the host can't be added for $reasons.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027753: geeqie crashes on ssh-forwared remote X

[Andreas Rönnquist]

On Mon, 02 Jan 2023 20:44:32 +0100
Lars Rohwedder  wrote:
>
>When I try to run "geeqie" via remote X (via "ssh -v -Y", that's why
>I got the debug output from ssh, too) I got this error messages
>to the console and geeqie seems to crash immediately:
>

Thanks for your report - Could you please try to run geeqie with the command

LIBGL_ALWAYS_INDIRECT=1 geeqie

and report back here?

If that doesn't work, try to run geeqie with

geeqie --disable-clutter

- this is the geeqie bug https://github.com/BestImageViewer/geeqie/issues/829

Already fixed in later versions.

/Andreas Rönnquist
gus...@debian.org

Bug#1025868: lintian autopkgtest fails on all but amd64: x86_64-linux-gnu expected build-and-evaluate-test-packages/eval/checks/desktop/gnome/gir/gir/generic.t

[Axel Beckert]

Hi Paul,

finally found time to tackle this.

Axel Beckert wrote:
> > Can you please investigate the situation
> 
> Already done. Issue are mostly hardcoded x86_64 and amd64 strings in
> the test suite.
> 
> Problem is IIRC that Lintian's testsuite currently doesn't support a
> templating system, at least not for many of these places. IIRC I fixed
> already some of them which were easy to fix.

Actually there seems a possibility to fix this like in these cases
t/recipes/checks/desktop/gnome/gir/gir/eval/post-test which has the
following sed command in it:

  s, usr/lib/[^/${}]+/girepository-1.0$, usr/lib/MULTIARCH/girepository-1.0,

But it doesn't seem to be applied in the comparison, because if I put
"MULTIARCH" into the hints file, it fails on amd64 as well.

Another weird point seems that
t/recipes/checks/desktop/gnome/gir/gir/eval/desc says:

  Testname: gir
  Check: desktop/gnome/gir
  Test-Architecture: amd64

So that clearly means it should only be run on amd64. So why is it run
on arm64 at all?

Hrm, a "git grep Test-Architecture" shows that most if not all other
such cases have "Test-Architectures" (plural with trailing "s") in
that place. So this is a typo which hasn't been caught yet.

So with my commit f415bc56c4b40d25410af21f2ea629e8eb0733b6 this part
of the test failures should be fixed. And with commit
695582b83f397d6bd5f47f99af77b2195ed1e604 we should also have an
internal check which finds such field name typos. (Needs to be
maintained, though, if fields get added or removed.)

Still need to figure out where the issue with bin-sbin-mismatch. But
that tag is known (at least to me) for weird false positives.

Paul Gevers wrote:
> On 10-12-2022 22:55, Axel Beckert wrote:
> > Ehm, that version no more in the archive anywhere. Did you maybe mean
> > 2.115.3 as currently in Testing and Unstable? (Feel free to remove the
> > moreinfo tag once this is clarified.)
> 
> I meant, I see the issue *since* that version.

Ah, ok. Yeah, kinda makes sense. I kinda expected that this version is
usually the one the bug report was written against with any additional
version hints being added as secondary version via Control statements.

> But indeed, that's a bit weird if not commented on. I have added a
> `found` version now.

Thanks!

> > Will have to look into it again, but I fear in short term, it means to
> > either reduce the tests or only run a subset on non-amd64
> > architectures.
> 
> If the test can't easily support other architectures (which is fine in my
> opinion) than please ensure it only runs on amd64. I advice to do that by
> adding a "Architecture: amd64" field to d/t/control.

Thanks for that hint. But there's already enough code in place for
that so that making it work should be merely fixing a few more lines.
The big question is which lines. ;-) But at least half of the issue is
fixed already.

P.S.: Any idea how we get Salsa CI autopkgtests on arm64?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1026962: openjfx: tries to build with -j64 on a host with 2 processors

[tony mancill]

On Sat, Dec 24, 2022 at 05:25:40PM -0800, tony mancill wrote:
> On Sat, Dec 24, 2022 at 08:22:43PM +0100, Aurelien Jarno wrote:
> > Source: openjfx
> > Version: 11.0.11+0-1.1
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the 
> > past)
> > 
> > openjfx tries to build with -j64 on zani.debian.org, which only has 2
> > processors and 8GB of RAM:
> > 
> > buildd   3853047  0.0  0.0  67668 4 ?S11:07   0:00 cmake 
> > --build 
> > /build/openjfx-fzmlCD/openjfx-11.0.11+1/modules/javafx.web/build/linux/Release
> >  --config Release -- -j64
> > buildd   3853048  0.0  0.0   3200   272 ?S11:07   0:00 
> > /usr/bin/gmake -f Makefile -j64
> > 
> > This hogs the buildd resources and we had to kill the build.
> 
> Yeah, that seems excessive.  FWIW, the most recent upload didn't change
> anything related to the build options, so this has built successfully in
> the past.
> 
> It built successfully on armel with the auto-detected value -j4, so it's
> surprising to see it pick 64 if there are only 2 processors.  The only
> reference to the number of compile threads is this bit of Groovy from
> build.gradle:
> 
> defineProperty("NUM_COMPILE_THREADS", 
> "${Runtime.runtime.availableProcessors()}")
> 
> I will have a look to try to determine where the value of 64 is coming
> from.  We can clamp the value if need be.

I have been poking at this and the issue isn't with NUM_COMPILE_THREADS.
It appears that cmake is picking the value of 64 all by itself, and it
doesn't respect CMAKE_BUILD_PARALLEL_LEVEL when it is set in the build
environment.  So perhaps cmake has changed.

In any event, I will continue to look for a way to avoid this on s390x.

Bug#1027754: libxstream-java: CVE-2022-41966

[Salvatore Bonaccorso]

Source: libxstream-java
Version: 1.4.19-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libxstream-java.

CVE-2022-41966[0]:
| XStream serializes Java objects to XML and back again. Versions prior
| to 1.4.20 may allow a remote attacker to terminate the application
| with a stack overflow error, resulting in a denial of service only via
| manipulation the processed input stream. The attack uses the hash code
| implementation for collections and maps to force recursive hash
| calculation causing a stack overflow. This issue is patched in version
| 1.4.20 which handles the stack overflow and raises an
| InputManipulationException instead. A potential workaround for users
| who only use HashMap or HashSet and whose XML refers these only as
| default map or set, is to change the default implementation of
| java.util.Map and java.util per the code example in the referenced
| advisory. However, this implies that your application does not care
| about the implementation of the map and all elements are comparable.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-41966
https://www.cve.org/CVERecord?id=CVE-2022-41966
[1] https://x-stream.github.io/CVE-2022-41966.html
[2] https://github.com/x-stream/xstream/security/advisories/GHSA-j563-grx4-pjpv
[3] 
https://github.com/x-stream/xstream/commit/e9151f221b4969fb15b1e946d5d61dcdd459a391
 

Regards,
Salvatore

Bug#1027472: Update LedgerSMB to 1.10

[Erik Huelsmann]

Hi,

Thank you for checking and creating this issue. Overall, you're completely
correct. There is however some nuance I'd like to provide to the statement
you quoted:

"""

Versions 1.6 and older
should no longer be used due to known security issues that cannot be resolved
in that code base.
"""

While this statement is true for the 1.6 version released upstream
(I'm upstream
as well as the last person to update the package), the CVE fixes that
this statement
refers to *have* been backported to Debian. The "cannot" part refers
to security issues
in the 1.2 code base. For 1.3+ it should have said "will not".


Now we *are* on the topic of updating the package, I have some
questions with respect to
the JavaScript the 1.10 and higher releases depend on, since the build
process for the
JavaScript assets has changed from direct inclusion of DojoToolkit
dependency to a much
broader set of dependencies built with WebPack. I'm looking for
someone with experience
packaging similar applications on Debian. Can you help me get in
contact with a person who
might be able to help me?

Regards,

Erik.

Bug#1026633: Info received (Grig)

[Christoph Berg]

Re: Black Michael
> Current github master plus one small patch fixes the compilation.

Hi Michael,

I see it has already been merged, thanks!

Let's see if they also tag a new release. Otherwise I'll make a temp
tarball in a few days.

Christoph

Bug#1027753: geeqie crashes on ssh-forwared remote X

[Lars Rohwedder]

Package: geeqie
Version: 1:1.6-9+deb11u1
Severity: important
X-Debbugs-Cc: ro...@pep-project.org

When I try to run "geeqie" via remote X (via "ssh -v -Y", that's why
I got the debug output from ssh, too) I got this error messages
to the console and geeqie seems to crash immediately:


$ geeqie 
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 46680
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 46696
debug1: x11_connect_display: $DISPLAY is launchd
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: channel 2: FORCE input drain
debug1: channel 2: free: x11, nchannels 3
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
debug1: channel 1: FORCE input drain
Segmentation fault


Running geeqie in a local terminal it runs fine.

Geeqie in Debian 9 and 10 worked properly, locally and via ssh-tunneled remote 
X.


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

Kernel: Linux 5.10.0-20-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.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 geeqie depends on:
ii  geeqie-common1:1.6-9+deb11u1
ii  libc62.31-13+deb11u5
ii  libcairo21.16.0-5
ii  libchamplain-0.12-0  0.12.20-1
ii  libchamplain-gtk-0.12-0  0.12.20-1
ii  libclutter-1.0-0 1.26.4+dfsg-2
ii  libclutter-gtk-1.0-0 1.8.4-4
ii  libcogl201.22.8-2
ii  libdjvulibre21   3.5.28-2
ii  libexiv2-27  0.27.3-3+deb11u1
ii  libffmpegthumbnailer4v5  2.1.1-0.2+b1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libheif1 1.11.0-1
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblcms2-2   2.12~rc1-2
ii  liblirc-client0  0.10.1-6.3
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenjp2-7 2.4.0-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpoppler-glib8 20.09.0-3.1+deb11u1
ii  libstdc++6   10.2.1-6
ii  libtiff5 4.2.0-1+deb11u1
ii  libwebp6 0.6.1-2.1
ii  sensible-utils   0.0.14

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.3.3op2-3+deb11u2
ii  exiftran 2.10-4
ii  exiv20.27.3-3+deb11u1
ii  imagemagick  8:6.9.11.60+dfsg-1.3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3
ii  librsvg2-common  2.50.3+dfsg-1
ii  zenity   3.32.0-6

Versions of packages geeqie suggests:
pn  geeqie-dbg 
ii  gimp   2.10.22-4
pn  libjpeg-progs  
pn  xpaint 

-- no debconf information

Bug#973617: fonts-materialdesignicons-webfont: New upstream release

[Julian Gilbey]

On Mon, Jan 02, 2023 at 05:20:00PM +, Julian Gilbey wrote:
> [...]
> > 
> > I've added you as maintainer, feel free to push directly to this repo.
> > Please note that on every push, packages are automatically backported to the
> > current stable. You may join #debian-openstack-commits to see the build
> > result.
> 
> Now this may be tricky, because building the proposed new version of
> the fonts requires the new node-webfont package; would that be
> backported as well?  (BTW, I've just pushed a new version to my
> experimental repository at
> https://salsa.debian.org/debian/fonts-materialdesignicons-webfont
> which generates a version 1.6.50 package as well as the newer ones.)

I just tried building node-webfont on bullseye with bullseye-backports
and it's not happy:

The following packages have unmet dependencies:
 sbuild-build-depends-main-dummy : Depends: node-svg2ttf but it is not 
installable
   Depends: node-nunjucks (>= 3.2.3) but it is 
not installable
   Depends: node-parse-json (>= 5.2.0) but 
5.1.0+~cs5.1.6-2 is to be installed
   Depends: node-xml2js (>= 0.4.23) but it is 
not going to be installed
   Depends: node-jasmine but it is not 
installable

So at least 4 (and quite possibly more) nodejs packages would have to
be backported to bullseye-backports to be able to do this.
(node-xml2js is too old in stable for this package.)

Best wishes,

   Julian

Bug#1027752: nvidia-cuda-toolkit-gcc: Depends on gcc-11 that should not be in bookworm

[Bastian Germann]

Package: nvidia-cuda-toolkit-gcc
Version: 11.6.2-4
Severity: important
Control: block 1023690 by -1

Please switch to gcc-12 which will be the default compiler in bookworm.

Bug#1027751: need to properly depend on python3-exceptiongroup

[Nilesh Patra]

Source: pytest
Version: 7.1.2-4
Severity: serious
X-Debbugs-Cc: roehl...@debian.org

Hi,

While building pairtools version 1.0.2-1 I noticed this error. I have 
temporarliy added
a build depend on exceptiongroup in the said package to work around the issue.

| I: pybuild base:240: export CURPY=python3.10; cd 
/<>/.pybuild/cpython3_3.10/build && python3.10 -m pytest -v
| Traceback (most recent call last):
|  File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main
|mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
|  File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details
|return _get_module_details(pkg_main_name, error)
|  File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details
|__import__(pkg_name)
|  File "/usr/lib/python3/dist-packages/pytest/__init__.py", line 5, in 
|from _pytest._code import ExceptionInfo
|  File "/usr/lib/python3/dist-packages/_pytest/_code/__init__.py", line 2, in 

|from .code import Code
|  File "/usr/lib/python3/dist-packages/_pytest/_code/code.py", line 60, in 

|from exceptiongroup import BaseExceptionGroup
| ModuleNotFoundError: No module named 'exceptiongroup'
| E: pybuild pybuild:388: test: plugin custom failed with: exit code=1: export 
CURPY=python3.10; cd /<>/.pybuild/cpython3_3.10/build && 
python3.10 -m pytest -v

My hunch is that the issue is this:

| $ apt show python3-pytest | grep excep
| Depends: python3-attr, python3-more-itertools, python3-pkg-resources, 
python3-pluggy (>= 0.12), python3-py, python3-exceptiongroup | python3 (>> 
3.11), python3-importlib-metadata | python3 (>> 3.8), python3-iniconfig, 
python3-packaging, python3-tomli | python3 (>> 3.11), python3:any

The "python3 (>> 3.11)" dependency is now beginning to be satisfied with doko's 
new python3.11 upload i.e. version 3.11.1 (see[1])
exceptiongroup should still be picked in this scnario, this is a bit odd 
though, but definitely worth a look.

[1]: 
https://tracker.debian.org/news/1404008/accepted-python311-3111-2-source-into-unstable/

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

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

Bug#953790: quassel-client: Typo in spanish translation

[Lisandro Damián Nicanor Pérez Meyer]

Control: forwarded -1 https://github.com/quassel/quassel-i18n/pull/2


On Thu, 29 Dec 2022 at 21:37, Diederik de Haas  wrote:
>
> On Fri, 13 Mar 2020 10:31:57 -0300 Lisandro Damián Nicanor Pérez Meyer
[snip]
> Could you try again at https://github.com/quassel/quassel-i18n/pulls ?
> They recently did merge an update to German translation there.

Done, let's see how it goes.

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1027038: QR code support

[Jameson Graef Rollins]

Hey Joey, thanks so much for the feedback.

I in fact have been using an extension to impass that does exactly this
(very similar to what you suggest), but I haven't gotten around to
pushing it upstream.  I'll try to do that asap and push out a new
release.

Thanks again for the feedback!

jamie.


On Mon, Dec 26 2022, Joey Hess  wrote:
> Package: impass
> Version: 0.12.2-1
> Severity: wishlist
>
> The "pass" password manager has a show QR code option, which makes it
> easy to transfer a single password to a phone. On the phone, you just
> copy and paste the password into whatever program. This is perfect for
> me, since I don't want my phone to have access to all my passwords, but
> do occasionally need one there.
>
> Might it make sense to add a similar feature to impass? I'll leave that
> to you. I tried to cobble something together from existing parts, and
> the script below does a decent job. But a feature would make the idea
> discoverable to users; I would not have thought of doing this if I had
> not see the feature in "pass".
>
> #!/bin/sh
> buf="$(xsel)"
> IMPASS_XPASTE=xclip impass gui
> xsel -b | qr
> echo "$buf" | xsel -i
>
> -- 
> see shy jo

Bug#1027750: libass: fix x86 assembly on Hurd

[Oneric]

Source: libass
Version: 1:0.17.0-2
Severity: wishlist

Hi!

reenabling assembly for i386 packages with the 0.17.0 upgrade
lead to package build errors on Hurd, because our configuration
logic didn't know how to configure the assembler on GNU Hurd.
This was fixed upstream in
  
https://github.com/libass/libass/commit/a943ef542e72e849dc0c1047465e0506781374b5

There are no plans for a new upstream release (yet), but a backport of the
fix applying cleanly on the 0.17.0 tarball (some whitespace changes were
needed) is attached if you want to use it for the meantime.

Cheers

Oneric
From 842e77f9347cd6eba4d40736ea47db635b45a6a7 Mon Sep 17 00:00:00 2001
From: Oneric 
Date: Sun, 1 Jan 2023 15:51:36 +0100
Subject: [PATCH] configure: support x86 assembly on GNU Hurd

Hurd too uses ELF and 16-byte stack alignment
just like Linux and many other Unix-likes.

Supposedly its host triplet can include a version number at the end.
Without getting more specific about how a version number is allowed to
look like, checking for *-gnu* overlaps with X32's -gnux32 suffix which
is present on non-Hurd systems.
Linux is the only X32 platform I know about and it uses an identical
configuration to GNU Hurd, so this shouldn't be a problem. Though to be
safe, let's move the case with *-gnu* at the end, to ensure if there's
a "-gnux32"-like suffix on any non-Linux, non-Hurd system it will match
the proper host regex before seeing Hurd's *-gnu* pattern.

Thanks to youpi1 for advice about Hurd and testing.

Backported from upstream a943ef542e72e849dc0c1047465e0506781374b5
---
 configure.ac | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 28dc3b7..77bd7b6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -274,9 +274,6 @@ AS_IF([test "x$enable_asm" != xno], [
 [*darwin*], [
 ASFLAGS="$ASFLAGS -f macho$BITTYPE -DPREFIX -DSTACK_ALIGNMENT=16"
 ],
-[*linux*|*solaris*|*haiku*], [
-ASFLAGS="$ASFLAGS -f elf$BITTYPE -DSTACK_ALIGNMENT=16"
-],
 [*dragonfly*|*bsd*], [
 ASFLAGS="$ASFLAGS -f elf$BITTYPE"
 ],
@@ -286,6 +283,9 @@ AS_IF([test "x$enable_asm" != xno], [
 ASFLAGS="$ASFLAGS -DPREFIX"
 ])
 ],
+[*linux*|*solaris*|*haiku*|*-gnu*], [
+ASFLAGS="$ASFLAGS -f elf$BITTYPE -DSTACK_ALIGNMENT=16"
+],
 [ # default
 AC_MSG_ERROR(m4_text_wrap(m4_normalize([
 Please contact libass upstream to figure out if ASM
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1027337: Update 2

[Xan Charbonnet]

At the 96 hour mark it hit 2.5GB, 64.6%.  I reverted the seven MariaDB 
packages back to 10.5.15, and the problem has disappeared.  mariadbd is 
holding steady at 135MB, 3.4%.


I'm happy to help participate in figuring out what's going wrong.

Bug#1027749: update-initramfs could diagnose attempt to run with /dev not mounted

[Peter Maydell]

Package: initramfs-tools
Version: 0.140
Severity: wishlist

When the config files specify MODULES=dep, update-initramfs
tries to autodetect which modules to load. To do this, all of
/proc/, /sys/, and /dev/ must be mounted. If either /proc/ or
/sys/ isn't mounted, update-initramfs fails with an error
message which explicitly mentions a filename in /proc/ or
/sys/, cluing the user in to what they forgot. However if
/dev/ is not mounted, the error is a generic one:
"mkinitramfs: failed to determine device for /".

Obviously this is user error, but I think it would be helpful
if update-initramfs explicitly complained about missing
/dev/, or at least that it failed to find a specific file in /dev/.

I think because update-initramfs is a tool you might
need to run in a weird situation where you're trying to
rescue a non-booting system it's perhaps worth checking
for something it would clearly not make sense to check
in a more average tool that can just assume the system
is in a sane state.

The situation where I ran into this was that on moving a
disk to new hardware I needed to rebuild the initrd to
get it to boot. So I booted a livecd, mounted the disk,
chrooted into it and ran update-initramfs. Once I
realised I'd forgotten to mount or bind-mount all these
other things into the chroot it worked fine :-)

thanks
-- PMM

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

[Sven Joachim]

On 2023-01-02 19:08 +0100, Vincent Lefevre wrote:

> On 2023-01-02 18:07:52 +0100, Sven Joachim wrote:
>> On 2023-01-02 16:34 +0100, Vincent Lefevre wrote:
>> > There is no such issue under bullseye (Debian 11.6), which also has
>> > GNU Screen 4.09.00, so the breakage appears to be due to libc6.
>>
>> Without having looked at the problem: this appears to be a rather bold
>> conclusion.  There are also newer versions of mutt, ncurses and a few
>> other libraries which mutt or screen depend upon that could be
>> responsible.
>
> I've tested with the same version of Mutt (from Git). However, indeed,
> ncurses is different. I doubt that other libraries matter.

Probably not; the most likely candidates besides libc6 would be
ncurses-base (i.e. the terminfo database) and libncursesw6.  My advice
would be to start with a minimal bullseye chroot and then upgrade first
libc6, then ncurses-base and finally libncursesw6 to the sid or bookworm
versions.

>> > Example to reproduce the issue with the U+1FAF6 HEART HANDS character
>> > under Debian/unstable:
>> >
>> > 1. Run "screen" in a 80-column terminal.
>> >
>> > 2. Open this mailbox with "mutt -F /dev/null -f heart-hands.mbox".
>> >Result: line 10 is shifted 1 column to the right, and character "v"
>> >appears on the following line.
>>
>> I failed to reproduce that step, the 'v' appears on the last column for
>> me.
>
> Sorry, I did the test with my own version of Mutt. So, for this
> particular behavior at step 2, you need
>
>   mutt -n -F /dev/null -f heart-hands.mbox
>
> i.e. with the -n option so that the system-wide Muttrc configuration
> file is not read.

I still see the 'v' on the last column with mutt 2.2.9-1.

Cheers,
   Sven

Bug#1027748: manpages: Please update to version 6.02

[Helge Kreutzmann]

Package: manpages
Version: 6.01-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: Mario Blättermann 

Hello Marcos,
hello Tobias,
could you kindly update to 6.02 in the next days (this week would be
ideal). 

This version corrects several (english!) fixes, reported by
translators. And if you publish the update this week, then
manpages-l10n can still pick it up before the freeze and have current
translations (pending work of translators of course) in Bookworm.

Thanks for your support!


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

Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  konqueror [man-browser]  4:22.12.0-3
ii  man-db [man-browser] 2.11.1-1

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#1027084: blhc: recognize _FORTIFY_SOURCE level 3

[Christian Göttsche]

On Tue, 27 Dec 2022 at 23:11, Simon Ruderich  wrote:
>
> On Tue, Dec 27, 2022 at 05:48:20PM +0100, Christian Göttsche wrote:
> > Please recognize -D_FORTIFY_SOURCE=3 as fortification enabled.
>
> Hi,
>
> should be implemented with [1]. Please test.

Works fine.
Thanks!

>
> Best,
> Simon
>
> [1] 
> https://ruderich.org/simon/gitweb/?p=blhc/blhc.git;a=commitdiff;h=88f15389b533468857f01490368376b539a598b3
> --
> + privacy is necessary
> + using gnupg http://gnupg.org
> + public key id: 0x92FEFDB7E44C32F9

Bug#1027747: gtkwave: Drop ghwdump in favor of ghdl's version

[Andreas Bombe]

Package: gtkwave
Version: 3.3.104-2+b1
Severity: normal

Currently ghwdump is shipped with gtkwave, however it is outdated and
will fail when used in the current ghdl's testsuite. Upstream for
gtkwave has dropped ghwdump and upstream for ghdl has included it.

In the new ghdl packages I have included ghwdump in a temporary location
in /usr/lib/ghdl so that it can be used in the testsuite by
autopkgtests. I intend to create a new binary package "ghwdump" as part
of the ghdl packaging, and for that I'd like to move ownership of
/usr/bin/ghwdump from gtkwave to that package.

As newer versions of gtkwave drop ghwdump from their sources this will
happen anyway, but will require coordination on part of the dependency
relationships between those packages.

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

[Vincent Lefevre]

On 2023-01-02 19:27:28 +0100, Vincent Lefevre wrote:
> Hmm... This also depends on the terminal.
> 
> This problem (both step 2 and step 3) is reproducible with xterm,
> rxvt and GNOME Terminal, but not mlterm.
> 
> This might also be a terminal bug, but several terminals would be
> affected by the same bug!

Forget this remark: without "screen", there is a small display issue
in mlterm. This appears to be related to the width of the character
(mlterm considers that it takes 1 column, contrary to the other
terminals).

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

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

[Vincent Lefevre]

On 2023-01-02 19:08:17 +0100, Vincent Lefevre wrote:
> > > Example to reproduce the issue with the U+1FAF6 HEART HANDS character
> > > under Debian/unstable:
> > >
> > > 1. Run "screen" in a 80-column terminal.
> > >
> > > 2. Open this mailbox with "mutt -F /dev/null -f heart-hands.mbox".
> > >Result: line 10 is shifted 1 column to the right, and character "v"
> > >appears on the following line.
> > 
> > I failed to reproduce that step, the 'v' appears on the last column for
> > me.
> 
> Sorry, I did the test with my own version of Mutt. So, for this
> particular behavior at step 2, you need
> 
>   mutt -n -F /dev/null -f heart-hands.mbox
> 
> i.e. with the -n option so that the system-wide Muttrc configuration
> file is not read.

Hmm... This also depends on the terminal.

This problem (both step 2 and step 3) is reproducible with xterm,
rxvt and GNOME Terminal, but not mlterm.

This might also be a terminal bug, but several terminals would be
affected by the same bug!

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

Bug#1027710: libruby3.0: drop Provides: ruby-dbm (now provided separately)

[Antonio Terceiro]

Control: reassign -1 dhelp
Control: retitle -1 dhelp: dependency on ruby-dbm satisfied by (obsolete) 
libruby3.0

On Mon, Jan 02, 2023 at 11:28:54AM +0100, Drew Parsons wrote:
> Package: libruby3.0
> Version: 3.0.4-8
> Severity: normal
> 
> A new ruby-dbm package was recently created to resolve Bug#1027407
> (dhelp Depends: ruby-dbm)
> 
> But libruby3.0 still declares Provides: ruby-dbm (= 1.1.0)
> and so the new ruby-dbm 1.1.0-2 doesn't actually get installed by a
> standard upgrade.
> 
> I guess libruby3.0 should now drop Provides: ruby-dbm
> since it no longer provides dbm.

libruby3.0 won't be part of the release, and in fact I want to get it
removed RSN. Instead of dropping the provides from libruby3.0, I think
the correct fix for this is tighttening the dependency in dhelp instead.


signature.asc
Description: PGP signature

Bug#1027746: transition: log4cxx

[Tobias Frost]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: log4...@packages.debian.org
Control: affects -1 + src:log4cxx

Hi,

I'm currently preparing for log4cxx13 -> log4cxx15 transition.
(SO_NAME 14 had been skipped by upstream)

All it's r-depends builds fine, and there are only three, I anticipate
a smooth transition:

R-Dependees are:
solarpowerlog ✔
ros-rosconsole ✔
ros-ros-comm ✔

(zookeeper is B-D on log4cxx, however it is not using it, #1027732)


Waiting for the green light from you ;-)

-- 
tobi

Bug#969516: Please support installing onto f2fs root filesystem

[Stuart]

Is there any update to this? I can't find the source anywhere to test it
myself either.

Bug#415292: libgl1-mesa-glx: assertion failure in libGL.so.1

[Fabio Pedretti]

forwarded 415292 https://gitlab.freedesktop.org/mesa/mesa/-/issues/49
thanks

Il giorno lun 2 gen 2023 alle ore 19:03 G. Branden Robinson
 ha scritto:
>
> At 2023-01-02T18:54:02+0100, Fabio Pedretti wrote:
> > upstream bug report was closed with:
> > "This code has been rewritten since and almost certainly fixed,
> > closing."
>
> Jesus.  I'd never trust a claim like that without output from a formal
> verification suite to confirm it.
>
> I think we may have a brogrammer at play.

Well, this Debian bug report is over 15 years old. :)

Il giorno lun 2 gen 2023 alle ore 19:03 G. Branden Robinson
 ha scritto:
>
> At 2023-01-02T18:54:02+0100, Fabio Pedretti wrote:
> > upstream bug report was closed with:
> > "This code has been rewritten since and almost certainly fixed,
> > closing."
>
> Jesus.  I'd never trust a claim like that without output from a formal
> verification suite to confirm it.
>
> I think we may have a brogrammer at play.
>
> Regards,
> Branden

Bug#1027745: gtkwave: New upstream version available

[Andreas Bombe]

Package: gtkwave
Version: 3.3.104-2+b1
Severity: wishlist

There have been new upstream releases in the meantime, up to 3.3.114.
Additionally the upstream package can be switched to gtkwave-gtk3 to get
a variant that should work with gtk3 (the gtkwave upstream package is
still gtk1/gtk2 only) and solve #967502.

The included ghwdump has been dropped in the meantime in favor of its
distribution with ghdl. While packaging the current ghdl release I had
to include its ghwdump in order to allow autopkgtests to function as the
gtkwave ghwdump is too old to understand current ghw files. I will file
a separate bug about that.

Bug#1027733: libc6: new libc6 breaks GNU Screen handling of some Unicode characters

[Vincent Lefevre]

On 2023-01-02 18:07:52 +0100, Sven Joachim wrote:
> On 2023-01-02 16:34 +0100, Vincent Lefevre wrote:
> > There is no such issue under bullseye (Debian 11.6), which also has
> > GNU Screen 4.09.00, so the breakage appears to be due to libc6.
> 
> Without having looked at the problem: this appears to be a rather bold
> conclusion.  There are also newer versions of mutt, ncurses and a few
> other libraries which mutt or screen depend upon that could be
> responsible.

I've tested with the same version of Mutt (from Git). However, indeed,
ncurses is different. I doubt that other libraries matter.

> > Example to reproduce the issue with the U+1FAF6 HEART HANDS character
> > under Debian/unstable:
> >
> > 1. Run "screen" in a 80-column terminal.
> >
> > 2. Open this mailbox with "mutt -F /dev/null -f heart-hands.mbox".
> >Result: line 10 is shifted 1 column to the right, and character "v"
> >appears on the following line.
> 
> I failed to reproduce that step, the 'v' appears on the last column for
> me.

Sorry, I did the test with my own version of Mutt. So, for this
particular behavior at step 2, you need

  mutt -n -F /dev/null -f heart-hands.mbox

i.e. with the -n option so that the system-wide Muttrc configuration
file is not read.

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

Bug#415292: libgl1-mesa-glx: assertion failure in libGL.so.1

[G. Branden Robinson]

At 2023-01-02T18:54:02+0100, Fabio Pedretti wrote:
> upstream bug report was closed with:
> "This code has been rewritten since and almost certainly fixed,
> closing."

Jesus.  I'd never trust a claim like that without output from a formal
verification suite to confirm it.

I think we may have a brogrammer at play.

Regards,
Branden


signature.asc
Description: PGP signature

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Bastian Germann]

Am 15.12.22 um 06:40 schrieb Nick Hastings:

The repackaging comment does not only go for musl but also the other
3rd party components.

Striping out the bundled source would change Zig drastically and would
make both producing and maintaining this package much harder. I think
that the bundled source is part of what makes Zig Zig.


Okay. Just keep them for now. But when the package is in the archive please
register the package with the Security Team to have those embedded copies.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Bastian Germann]

Am 15.12.22 um 06:40 schrieb Nick Hastings:

Should I also reupload to mentors?


You can skip that. Just notify me and the RFS bug when you want to trigger 
another review.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Bastian Germann]

Am 15.12.22 um 06:40 schrieb Nick Hastings:

Ok. I haven't been able find a definitive short version of the CC0
license. There seem to be some variations checking
/usr/share/doc/*/copyright on my system. Can you suggest what I should
use for this?


License: CC0
 On Debian systems, the full text of the Creative Commons Zero 1.0 Universal
 can be found in the file `/usr/share/common-licenses/CC0-1.0'.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Bastian Germann]

Am 15.12.22 um 06:40 schrieb Nick Hastings:

Checking the files themselves I see that for
most files third clause does indeed specify University of California,
Berkeley and its contributors. However there are a handful of others
that specify different people in the clause 3 and have correspondingly
modified clause 4. So I guess I need to grind through and separate them
all?


Yes. The NetBSD Foundation allows to relicense their files under BSD-4-clause
to BSD-2-clause, see http://www.netbsd.org/about/redistribution.html

For the rest of the files you would have to make separate BSD-4-clause variants,
e.g. BSD-4-clause-Utah or BSD-4-clause-Adam-Glass.

Bug#415292: libgl1-mesa-glx: assertion failure in libGL.so.1

[Fabio Pedretti]

Hi Nikita,

upstream bug report was closed with:
"This code has been rewritten since and almost certainly fixed, closing."

Can you try with a recent Debian system and report back?

Thanks.

Bug#1027744: spare-manual-page triggers for binaries in /usr/libexec

[Russ Allbery]

Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: r...@debian.org

A section 8 manual page for a binary in /usr/libexec triggers:

I: kafs-client: spare-manual-page [usr/share/man/man8/kafs-dns.8.gz]
N: 
N:   Each manual page in /usr/share/man should have a reason to be there. This
N:   manual page does not appear to have a valid reason to be shipped.
N:   
N:   For manual pages in sections 1 and 8, an executable (or a link to one)
N:   should exist. This check currently considers all installation packages
N:   created by the same sources, as long as they are present.
N: 
N:   Please refer to Manual pages (Section 12.1) in the Debian Policy Manual
N:   and Bug#583125 for details.
N: 
N:   Visibility: info
N:   Show-Always: no
N:   Check: documentation/manual
N:   Renamed from: manpage-without-executable

I think this is incorrect and section 8 is the appropriate section for
documenting root-only helper programs that may be installed in
/usr/libexec.  (At least, if section 8 is not the right section, I'm not
sure what the right section would be.)

Fix is probably to just add /usr/libexec to the list of directories
checked for binaries to satisfy this test.

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

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

Versions of packages lintian depends on:
ii  binutils2.39.90.20221231-1
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.21.15
ii  dpkg-dev1.21.15
ii  file1:5.41-4
ii  gettext 0.21-10
ii  gpg 2.2.40-1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.12.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.28-2
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.32-1+b1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.15
ii  libemail-address-xs-perl1.05-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004004-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.634-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.001+ds-1+b1
ii  libsereal-encoder-perl  5.001+ds-2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.28-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.13-2
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.17-1
ii  libwww-mechanize-perl   2.15-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.84+ds-1+b1
ii  lzip [lzip-decompressor]1.23-4
ii  lzop1.04-2
ii  man-db  2.11.1-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-6
ii  t1utils 1.41-4
ii  unzip   6.0-27
ii  xz-utils5.4.0-0.1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template

Bug#1019984: libglx-mesa0: GL_VERSION update

[Fabio Pedretti]

Hi Alexandre,

Can you try again with mesa 22.3.1-1, which is in testing now, and
report back if the issue is fixed?

Thanks.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Bastian Germann]

Am 15.12.22 um 06:40 schrieb Nick Hastings:

I'd be more than happy to move it to salsa, but thought it was only
available for DDs/DMs. I see now that that is incorrect. I registered an
account and it seems to be pending approval.

In the mean time I've made a debian directory in the repo and moved
everything into it.


You would enable the CI at https://salsa.debian.org/nickh/zig/-/settings/ci_cd
by setting the CI/CD configuration file to 
recipes/debian.yml@salsa-ci-team/pipeline