Bug#1031656: Acknowledgement (MariaDB autopkgtest upstream test suite fails on disk / data corruption on ppc64el)

[Otto Kekäläinen]

A fresh run today passed, proving the Debian autopkgtest host
hardware/kernel/overload theory is likely the cause.

https://ci.debian.net/data/autopkgtest/testing/ppc64el/m/mariadb/31582867/log.gz

autopkgtest [05:44:51]: starting date and time: 2023-02-22 05:44:51+
autopkgtest [05:44:51]: version 5.28
autopkgtest [05:44:51]: host ci-worker-ppc64el-04;
...
main.ctype_utf16_uca w2 [ pass ]612
main.ctype_sjis  w1 [ pass ]   2752
main.ctype_utf32 w5 [ pass ]357
main.ctype_ujis_ucs2 w3 [ pass ]   1618
main.ctype_utf32_uca w2 [ pass ]477
main.ctype_utf8mb4_heap  w5 [ pass ]267
main.ctype_utf8_uca  w1 [ pass ]328
main.ctype_ujis  w4 [ pass ]   2469
--
The servers were restarted 197 times
Spent 1200.107 of 326 seconds executing testcases

Completed: All 1017 tests were successful.

174 tests were skipped, 75 by the test itself.

Bug#972146: /usr/share/applications/mono-runtime-common.desktop: should not handle MIME type by executing arbitrary code

[Salvatore Bonaccorso]

Hi Gabriel,

On Sat, Feb 18, 2023 at 12:04:27PM +0100, Gabriel Corona wrote:
> Hi!
> 
> > A while has passed, and have now proposed the same change for bullseye
> > as well, cf. #1031527.
> 
> Great!
> 
> > There is no CVE assigned, if you feel strong about it, can you try to
> > get one allocated by MITRE via the cveform? I think we won't go trough
> > the needed workflow to assign a Debian specific CVE id for it. But we
> > will see what MITRE will respond on the request.
> 
> I don't believe MITRE will accept such a request and redirect me to Debian
> [1].

I requested one directly from MITRE, it is now
https://www.cve.org/CVERecord?id=CVE-2023-26314 .

Regards,
Salvatore

Bug#1029821: change gnome-desktop's default choice of Japanese input methods

[ken...@xdump.org]

Hi,

On Sat, 28 Jan 2023 16:46:35 +0900 YOSHINO Yoshihito
 wrote:
> Package: libgnome-desktop-4-2
> Followup-For: Bug #1029821
> X-Debbugs-Cc: yy.y.ja...@gmail.com
> 
snip
> 
> Attaching a patch to change the Japanese default to mozc.

I've tested with attached patch on d-i Alpha2 on GNOME
desktop environment (gnome-initial-setup 43.2-1)

It seems that it works as expected (mozc-jp is selected by default for
Japanese users)

Before (without patch):

* gnome-initial-setup select anthy as default.
* If user keeps anthy as default and finish gnome-initial-setup, user
  can't input Japanese at all. it makes user confused.
  In such a situation, user must launch gnome-control-center and 
  remove anthy from input source then add mozc-jp explicitly.
  (Setting input sources via ibus-setup seems inappropriate in such a
  situation, so it may be troublesome without attached patch.) 
* User must search mozc as a input method to input Japanese
   during gnome-initial-setup configuration process. 

After (with attached patch):

* gnome-initial-setup select mozc-jp as default correctly.
* User can input Japanese without changing configuration.
* NOTE: There may be a potential bug that ibus-mozc is not listed 
  with engine's display name correctly.
  Thus with attached patch, gnome-initial-setup will not
  show label for mozc-jp as "日本語 (Mozc)" by default.
  This is because input_widget_new can't access priv->ibus_engines. [1]

  In other words, priv->ibus_engines is not set when input_widget_new
  is called.
  To display label correctly, fetch_ibus_engines_result must be called 
  in advance. When mozc-jp is listed as non-default without patch, it
  is displayed as "日本語 (Mozc)".
  (Upstream may not considered that default_input_sources will be
  patched, so it is ok not to fix this potential bug itself.)
  

[1]
https://salsa.debian.org/gnome-team/gnome-initial-setup/-/blob/debian/master/gnome-initial-setup/pages/keyboard/cc-input-chooser.c#L203-210

[2]
https://salsa.debian.org/gnome-team/gnome-initial-setup/-/blob/debian/master/gnome-initial-setup/pages/keyboard/cc-input-chooser.c#L642-644

Regards,

Bug#1027130: Bug may still be open

[Stephen Lyons]

Dear Maintainer;

This "grave" bug has been marked as closed in 1.0.0-dfsg-1 however it is
still open in 0.103.7-dfsg-0+deb11u1 and there is no indication that it
has been resolved in 0.103.8+dfsg-0+deb11u1 which is promulgated to
solve the "serious" CVEs handled in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031509 for "Buster".

As such trying to upgrade my system is warning me that this grave bug is
present. It is not clear whether this is indeed the case or not.

I must note that I am running Devuan Stable "Chimaera" but it seems that
this issue will also arise for Debian Stable "Bulleye".

Regards

Stephen Lyons

Bug#1031760: autopkg tests fail with python3.11

[Matthias Klose]

Package:sqlobject
Version: 3.10.1+dfsg-1
Severity: serious
Tags: sid bullseye

the autopkg tests fail with python3.11:

[...]
autopkgtest [03:29:29]: test testdb-setuptools: [---
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation 
or OS distribution provider. You can override this, at the risk of breaking your 
Python installation or OS, by passing --break-system-packages.

hint: See PEP 668 for the detailed specification.
autopkgtest [03:29:30]: test testdb-setuptools: ---]
autopkgtest [03:29:30]: test testdb-setuptools:  - - - - - - - - - - results - - 
- - - - - - - -

testdb-setuptoolsFAIL non-zero exit status 1
autopkgtest [03:29:30]: test testdb-setuptools:  - - - - - - - - - - stderr - - 
- - - - - - - -

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation 
or OS distribution provider. You can override this, at the risk of breaking your 
Python installation or OS, by passing --break-system-packages.

hint: See PEP 668 for the detailed specification.
autopkgtest [03:29:30]:  summary
testdb   PASS
testdb-setuptoolsFAIL non-zero exit status 1

Bug#1031733: libcommons-fileupload-java: CVE-2023-24998

[tony mancill]

On Tue, Feb 21, 2023 at 04:10:16PM +0100, Moritz Mühlenhoff wrote:
> Source: libcommons-fileupload-java
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for libcommons-fileupload-java.
> 
> CVE-2023-24998[0]:
> | Apache Commons FileUpload before 1.5 does not limit the number of
> | request parts to be processed resulting in the possibility of an
> | attacker triggering a DoS with a malicious upload or series of
> | uploads.
> 
> https://lists.apache.org/thread/4xl4l09mhwg4vgsk7dxqogcjrobrrdoy
> https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17

I have a patched version of 1.4 ready to upload using the upstream
patch.  However, based on reading the thread above, having the ability
to limit the number of request parts is in the library is not the same
as actually limiting the request parts.  The patched library defaults to
an unlimited number, so it is necessary but not sufficient to mitigate
the risk.

Is it safe to assume that CVEs will be created for the software
components that use commons-fileupload, and so I can go ahead and upload
the patched 1.4 version and mark CVE-2023-24998 as complete?

Thanks,
tony


signature.asc
Description: PGP signature

Bug#1031759: autopkg tests fail with python3.11

[Matthias Klose]

Package: src:spyder
Version: 5.4.2+ds-2
Severity: serious
Tags: sid bullseye

the autopkg tests fail with python3.11:

[...]
autopkgtest [03:30:32]: test pytest-mainwindow: [---
Testing with python3.11:
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation 
or OS distribution provider. You can override this, at the risk of breaking your 
Python installation or OS, by passing --break-system-packages.

hint: See PEP 668 for the detailed specification.
autopkgtest [03:30:32]: test pytest-mainwindow: ---]
autopkgtest [03:30:32]: test pytest-mainwindow:  - - - - - - - - - - results - - 
- - - - - - - -

pytest-mainwindowFLAKY non-zero exit status 1
autopkgtest [03:30:32]: test pytest-ipythonconsole: preparing testbed
Reading package lists...
Building dependency tree...
Reading state information...
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up autopkgtest-satdep (0) ...
(Reading database ... 66303 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [03:30:35]: test pytest-ipythonconsole: [---
Testing with python3.11:
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation 
or OS distribution provider. You can override this, at the risk of breaking your 
Python installation or OS, by passing --break-system-packages.

hint: See PEP 668 for the detailed specification.
autopkgtest [03:30:36]: test pytest-ipythonconsole: ---]
autopkgtest [03:30:36]: test pytest-ipythonconsole:  - - - - - - - - - - results 
- - - - - - - - - -

pytest-ipythonconsole FLAKY non-zero exit status 1
autopkgtest [03:30:36]:  summary
pytest-rest  FAIL non-zero exit status 1
pytest-mainwindowFLAKY non-zero exit status 1
pytest-ipythonconsole FLAKY non-zero exit status 1

Bug#1031758: autopkg tests broken with python3.11 (timeout)

[Matthias Klose]

Package: src:python-oslo.db
Version: 12.1.0-3
Severity: serious
Tags: sid bullseye

the autopkg tests fail with a timeout, please see
https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-oslo.db/31558294/log.gz

Bug#1031757: autopkg tests broken with python3.11

[Matthias Klose]

Package: src:python-formencode
Version: 2.0.1-1
Severity: serious
Tags: sid bullseye

the autopkg tests are broken with python3.11:

[...]
autopkgtest [02:13:40]: test testfe-setuptools: [---
error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation 
or OS distribution provider. You can override this, at the risk of breaking your 
Python installation or OS, by passing --break-system-packages.

hint: See PEP 668 for the detailed specification.
autopkgtest [02:13:41]: test testfe-setuptools: ---]
autopkgtest [02:13:41]: test testfe-setuptools:  - - - - - - - - - - results - - 
- - - - - - - -

testfe-setuptoolsFAIL non-zero exit status 1
autopkgtest [02:13:42]: test testfe-setuptools:  - - - - - - - - - - stderr - - 
- - - - - - - -

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.

If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.

If you wish to install a non-Debian packaged Python application,
it may be easiest to use pipx install xyz, which will manage a
virtual environment for you. Make sure you have pipx installed.

See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation 
or OS distribution provider. You can override this, at the risk of breaking your 
Python installation or OS, by passing --break-system-packages.

hint: See PEP 668 for the detailed specification.
autopkgtest [02:13:42]:  summary
testfe   PASS
testfe-setuptoolsFAIL non-zero exit status 1

Bug#964279: [deluge] TypeError: '>' not supported between instances of 'NoneType' and 'NoneType'

[Daniel Baumann]

close 964279 2.1.1-1
thanks

Hi Lyndon,

thanks for the feedback, I'll close the bug then.

Regards,
Daniel

Bug#927196: errors with username debian-deluged

[Daniel Baumann]

close 927196
thanks

Hi,

thank you for your report. Like Robert explained, this isn't actually a
bug but intended behaviour, hence closing.

Regards,
Daniel

Bug#1028654: dpkg: add loongarch64 architecture GNU triplet

[Guillem Jover]

Hi!

On Mon, 2023-02-20 at 21:30:14 +0800, zhangdandan wrote:
> We decide to use "loongarch64-linux-gnu" as the value of the Debian loong64
> port's multiarch tuple.
> The reasons for using "loongarch64-linux-gnu" are as follows:
> 
> Firstly, we note that many of the major architectures use the -gnu style in
> Debian [3].
> 
> - amd64: x86_64-linux-gnu
> - arm64: aarch64-linux-gnu
> - riscv64: riscv64-linux-gnu
> 
> Secondly, "loongarch64-linux-gnu" is also consistent with upstream LoongArch
> gcc's latest change (replacing "loongarch64-linux-gnuf64" with
> "loongarch64-linux-gnu") [5][6] and the current revision of LoongArch
> Toolchain Conventions [7].

Ok, so then just to confirm, the support that was already in dpkg's
git and that got reverted should be fine again. If so then I'm going
to revert commit f9187c8b13478824c9eff73c92a084cc50c34cad to restore
the previous code, and then request a pre-approval from the release
team in a couple of days.

Thanks,
Guillem

Bug#1031756: unblock: imagemagick/8:6.9.11.60+dfsg-1.6

[Jeremy Bícha]

Package: release.debian.org
Control: affects -1 + src:imagemagick
X-Debbugs-Cc: imagemag...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package imagemagick

[ Reason ]
The only change in this update is including the patch from stable-security
See https://www.debian.org/security/2023/dsa-5347 and
https://bugs.debian.org/1030767

[ Impact ]

[ Tests ]
The autopkgtests have passed successfully. This package would have
migrated by now if not for the Soft Freeze.

[ Risks ]

[ 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 testing

[ Other info ]

unblock imagemagick/8:6.9.11.60+dfsg-1.6

Thank you,
Jeremy Bicha


imagemagick-unblock-20230221.debdiff
Description: Binary data

Bug#1031755: ITP: privacybrowser -- web browser that respects your privacy

[Soren Stoutner]

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

* Package name: privacybrowser
  Version : 0.1
  Upstream Contact: Soren Stoutner 
* URL : https://www.stoutner.com/privacy-browser-pc/
* License : (GPLv3+)
  Programming Lang: (C++)
  Description : web browser that respects your privacy

Privacy Browser is a browser that is more focused on privacy than any
of the other browsers currently available.  It is developed using
the Qt Toolkit and KDE Frameworks.  I am the upstream developer and
would like to also maintain the Debian package.

Bug#986964: geeqie: View in new window, new window black until zoom in/out

[Rudolf Dovičín]

Package: geeqie
Version: 1:1.6-9+deb11u1
Followup-For: Bug #986964
X-Debbugs-Cc: rudolf.dovi...@gmail.com

Dear Maintainer,

I see the same error.
I reply to this, because I think that I have additional information.

It appears in full-screen mode in the main window, too.

When I turn full-screen mode in the main window by mouse and context menu
or by [F11] keyboard key, it shows only black screen until zooming.

But in a strange way:
When I start geeqie, full-screen of the main window is OK.
Error in the main window full-screen appears after the first zoom 1:1 only,
not before.

I cannot turn on "Use GPU acceleration via Clutter library" in preferences.

I have Installed xserver-xorg 2:1.20.11-1+deb11u5 version.


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=sk_SK.UTF-8, LC_CTYPE=sk_SK.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 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+deb11u3
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+deb11u1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+deb11u1
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
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.0.6-4
pn  xpaint   

Bug#913758: Are you still having issues with hardware wallets?

[Soren Stoutner]

It seems that some hardware wallets currently work with Electrum and others 
require 
software that is not currently packaged in Debian.

I have recently added some documentation that will be included in future 
versions of 
Electrum.  Could you take a look and see if there is any information you can 
add about the 
hardware wallets you use:

https://salsa.debian.org/cryptocoin-team/electrum/-/merge_requests/16[1]

Soren

-- 
Soren Stoutner
so...@stoutner.com


[1] https://salsa.debian.org/cryptocoin-team/electrum/-/merge_requests/16


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

Bug#1030886: Proposed README file

[Soren Stoutner]

I have added a proposed README file, which can be seen at:

https://salsa.debian.org/cryptocoin-team/electrum/-/merge_requests/16[1]

Let me know if there is anything else I should add or if you think anything 
should be 
reworded.

Soren

-- 
Soren Stoutner
so...@stoutner.com


[1] https://salsa.debian.org/cryptocoin-team/electrum/-/merge_requests/16


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

Bug#734235: Is this bug still an issue?

[Soren Stoutner]

I have recently started working on the Electrum package and came across 
this old bug.  Can you confirm that it is still an issue.  It looks like at 
least 
some aspects of it have already been addressed upstream.

https://github.com/spesmilo/electrum/issues/4637[1]

-- 
Soren Stoutner
so...@stoutner.com


[1] https://github.com/spesmilo/electrum/issues/4637


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

Bug#1031275: [PATCH v3 1/6] man2/: use IEC or ISO multiples to clarify long numeric digit strings

[Alex Colomar]

Hi Rob,

On 2/21/23 18:00, Rob Landley wrote:

If you're going to tell people to learn something new: 1<<10 is a kilobyte,
1<<20 is a megabyte, 1<<30 is a gigabyte, and so on. I've sometimes used
16*(1<<30) for clarity.


That's nice, and for code it might be a good idea (although you have to 
be careful, since those are all ints, and 16*(1<<30) is going to 
overflow, so you'll need 16L).  For documentation, I don't think I like 
it that much.





Also, for the record, I had no idea what KiB / MiB means and how it's
different from KB/MB until this discussion.


Very few people do. Some people have been trying to make "fetch" happen for many
years, but it didn't.


What's "fetch"?


(Part of the reason is kibybyte/mebibyte/gibibyte are
minor tongue twisters, they're physically harder to say, so nobody does.)


I rarely talk about this stuff; more often, I write about it.  When I 
write, the shorthand MiB is nice (I never write mebibyte).  For talking, 
I say "megs" (or rather the Spanish equivalent "megas"), so being 
colloquial I can't be blamed, since I didn't really say megabytes.  If I 
say the technical term, which is rare, I try to be precise, and say 
mebibytes instead of megabytes.





I googled it before
writing this reply, and found this among the first hits:
https://ux.stackexchange.com/a/13850.


That answer was written more than a decade ago.  These days, binary
prefixes are more common.  In fact, I'd say most GNU/Linux commands


"First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it.  Burn them, it's a great symbolic gesture." - Linus Torvalds


The GNU coding standards for writing C programs are horrible.  But they 
have very nice things in their standards.  Their standardization of 
Makefile targets and variables is quite nice, and I try to follow it 
closely.




(Still there in Documentation/process/coding-style.rst.)

GNU has nothing to do with Linux, and never did. Stallman has a history of
taking credit for other people's work:


I never said so.  GNU is a set of userspace programs, Linux is a kernel, 
and GNU/Linux is the entire OS (or more precisely a relatively important 
part of it).  Most Linux distros are GNU/Linux distros, since user space 
is mostly GNU.  Since I was talking about user-space programs, GNU is 
even more appropriate than Linux, although I'm not sure about how much 
GNU conforms to these IEC prefixes, which is why I used GNU/Linux as 
more generic, referring to the entire set of programs that are included 
in such distros (e.g. Debian).


I CCed GNU coreutils so that they feel alluded and maybe improve their 
utils :)




https://functional.cafe/@tfb/109897415359142549


respect them (an important exception being GNU coreutils (for example
ls(1)).  But many programs use prefixes accurately, such as fdisk(8).

In the Linux man-pages we have units(7), which documents these.  Maybe
that page should be more known.


FYI Michael Kerrisk last updated https://github.com/mkerrisk in 2021.


That repo is just a mirror of the official repo at
,
which I maintain.


It is now
2023. He still posts monthly proof-of-life to
https://twitter.com/mkerrisk/with_replies but hasn't replied to man-pages email
in the past year that I am aware of?

Dunno why.


He's busy with his own business, and doesn't have time to continue 
maintaining the project.  It's a voluntary thing, so it's reasonable to 
be able to step out at any time.


Since 2020, I comaintained the project with Michael, and now I'm the 
only maintainer of the project.  To be more precise, let's quote the README:


Maintainers
   Alejandro Colomar  


 2020 - present (5.09 - HEAD)
   Michael Kerrisk  
 2004 - 2021 (2.00 - 5.13)
   Andries Brouwer  
 1995 - 2004(1.6  - 1.70)
   Rik Faith 
 1993 - 1995(1.0  - 1.5)



I emailed to ask, but...


BTW, that answer is inaccurate (at least today): drive manufacturers
have the distinction pretty clear, and use it precisely (with lawsuits
won thanks to this); they use metric prefixes, because they mean it.
They can sell you 1 TB instead of 1 TiB, and most people won't even
know, but those who know, will know that 1 TB is 1'000'000'000'000 B,
which is what you get.


Remember when the dictionaries gave in on "literally" meaning "an emphatic form
of figuratively"? What's the "kibybyte" equivalent we all switched to there for
clarity?

We say "metric ton" and "imperial ton". We say "degrees farenheit" and "degrees
celsius". The celsius people didn't come up with a different word for degree,
yet somehow we all survived...


Or you can say Kelvin ;)
In colloquial texts, or more appropriately in colloquial talking, 
degrees (without specifying), tons (same), or "megs", are fine, but for 
a manual, where we 

Bug#772060: Is this bug still present

[Soren Stoutner]

I recently started working on the Electrum package and noticed this bug report 
for a very old version.  Can you confirm if this is still an issue?

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#772059: Is this bug still relevant

[Soren Stoutner]

I have recently started working on the Element package.  I noticed this bug 
for a really old version.  Can you confirm if it still exists in the current 
package?

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#792399: Is bug still valid

[Soren Stoutner]

I have recently started working on Electrum.  I see this bug, which is for a 
really old version.  Can you confirm if it is still a problem?

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1031681: libkiwix: bump B-D to libzim-dev (>= 8.1.0+really8.1.0)

[Andreas Beckmann]

Followup-For: Bug #1031681

src:kiwix-tools probably needs the same B-D bump.


Andreas

Bug#1031754: ncmpc-lyrics: missing dependencies on python3-bs4 and python3-requests

[Diederik de Haas]

Package: ncmpc-lyrics
Version: 0.47-1
Severity: important
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On a barebones (arm64) system I installed (mpd,) ncmpc and ncmpc-lyrics
and when I switched to the lyrics tab/screen, I got the following error:

==
*** 20-azlyrics.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//20-azlyrics.py", line 28, in 
import requests
ModuleNotFoundError: No module named 'requests'

*** 30-karaoke_texty.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//30-karaoke_texty.py", line 24, in 
import bs4
ModuleNotFoundError: No module named 'bs4'

*** 40-tekstowo.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//40-tekstowo.py", line 24, in 
import bs4
ModuleNotFoundError: No module named 'bs4'

*** 50-genius.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//50-genius.py", line 24, in 
import bs4
ModuleNotFoundError: No module named 'bs4'

*** 51-supermusic.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//51-supermusic.py", line 28, in 
import requests
ModuleNotFoundError: No module named 'requests'

*** 52-zeneszoveg.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//52-zeneszoveg.py", line 28, in 
import requests
ModuleNotFoundError: No module named 'requests'

*** 60-google.py ***

Traceback (most recent call last):
  File "/usr/libexec/ncmpc/lyrics//60-google.py", line 24, in 
import bs4
ModuleNotFoundError: No module named 'bs4'
==

After installing the `python3-bs4` and `python3-requests` packages the lyrics
screen seem to work properly. It also installed several dependency packages
(and/or recommends), so it may be that more packages should be added
explicitly to its dependencies.

(This bug is reported from another system as that had reportbug already
properly installed and configured, so it was easier)

Cheers,
  Diederik

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

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

Versions of packages ncmpc-lyrics depends on:
ii  ncmpc  0.47-1
ii  python33.11.2-1
ii  python3-unidecode  1.3.6-1

ncmpc-lyrics recommends no packages.

ncmpc-lyrics suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY/VkwgAKCRDXblvOeH7b
bgthAQCT8uLwevUZwESKM+9/E6qgXd0i6YBgXJBHmW7jdo8wjgEA4dgyOaVOPE1C
NOCq6ZIdDl+dtWmBxZRWqE0S6/dMSQc=
=U/Vr
-END PGP SIGNATURE-

Bug#1030600: redis breaks python-fakeredis autopkgtest: Connection refused

[Adrian Bunk]

Control: tags -1 ftbfs
Control: affects -1 src:beaker

On Mon, Feb 06, 2023 at 10:46:52AM -0800, Chris Lamb wrote:
> Paul Gevers wrote:
> 
> > With a recent upload of redis the autopkgtest of python-fakeredis fails 
> > in testing when that autopkgtest is run with the binary packages of 
> > redis from unstable. It passes when run with only packages from testing. 
> 
> Just had a stab at this. Unfortunately, I tried updating the
> python-fakeredis package to the latest upstream version (hey, it worked
> before!), but I believe I get the same errors.
> 
> Some thoughts:
> 
> * I wonder if this is a compatibility issue with python3-redis; a few
>   issues on upstream's Github project seem to suggest the two projects
>   are more interconnected that one might initially believe.
> 
> * Here are the release notes for Redis, showing the difference between
>   7.0.7 in testing and 7.0.8 in unstable:
>   https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES

beaker has a FTBFS that looks similar, without fakeredis installed:
https://buildd.debian.org/status/logs.php?pkg=beaker=1.12.1-1

> Regards,

cu
Adrian

Bug#1031753: linux-image-5.10.0-21-s390x: user space process hangs on s390 kernel 5.10.162-1

[Dipak Zope]

Package: src:linux
Version: 5.10.162-1
Severity: normal
X-Debbugs-Cc: pk...@debian.org, elb...@debian.org, dipak.zo...@ibm.com

Dear Maintainer,

What led up to the situation?
* Processes does not proceed further, when there is a pending TIF_NOTIFY_SIGNAL 
signal.
  The problem is further described in the cover letter:
  https://lists.debian.org/debian-s390/2023/02/msg00019.html
  There are other relevant debian bugs #1030545, #1030510, which seems likely 
because of this issue.
What exactly did you do (or not do) that was effective (or ineffective) ?
* kernel upgrade  to 5.10.0.21-s390x
* commit 788d0824269b ("io_uring: import 5.15-stable io_uring")
* commit 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
what was the outcome of this action?
* Debian build machines started reporting test failures for multiple packages/ 
The processes
  would wait forever in do_signal.
The following patch fixes this issue:
https://lists.debian.org/debian-s390/2023/02/msg00019.html
The patch fixes the problem introduced in commit 75309018a24d ("s390: add 
support for TIF_NOTIFY_SIGNAL")
Would request to apply this to the bullseye kernel stable release.


-- Package-specific info:
** Version:
Linux version 5.10.0-21-s390x (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.162-1 (2023-01-21)

** Command line:
none

** Not tainted

** Kernel log:
none

** Model information
none

** Loaded modules:
s390_trng
rng_core
prng
ctr
xts
cbc
ecb
aes_generic
libaes
aes_s390
des_s390
libdes
sha512_s390
sha256_s390
sha1_s390
sha_common
qeth_l2
vmur
qeth
ccwgroup
fuse
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
zfcp
scsi_transport_fc
scsi_mod
dasd_eckd_mod
dasd_mod

** PCI devices:

** USB devices:
not available


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

Kernel: Linux 5.10.0-21-s390x (SMP w/2 CPU threads)
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)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-21-s390x depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-21-s390x recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-21-s390x suggests:
pn  debian-kernel-handbook  
pn  linux-doc-5.10  
ii  s390-tools  2.15.1-2

Versions of packages linux-image-5.10.0-21-s390x is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1031752: rust-typenum: autopkgtest regression on 32bit

[Adrian Bunk]

Source: rust-typenum
Version: 1.16.0-1
Severity: serious

https://tracker.debian.org/pkg/rust-typenum

...
Issues preventing migration:
∙ ∙ autopkgtest for rust-typenum/1.16.0-1: amd64: Pass, arm64: Pass, armel: 
Regression ♻ (reference ♻), armhf: Regression ♻ (reference ♻), i386: Regression 
♻ (reference ♻), ppc64el: Pass, s390x: Pass


https://ci.debian.net/data/autopkgtest/testing/armhf/r/rust-typenum/31550189/log.gz

...
error[E0119]: conflicting implementations of trait 
`generated::generic_const_mappings::ToUInt` for type 
`generated::generic_const_mappings::Const<0_usize>`
--> 
/tmp/tmp.OgQsyeMSQY/target/armv7-unknown-linux-gnueabihf/debug/build/typenum-fe1e7c2e1c5cb87d/out/generic_const_mappings.rs:4245:5
 |
61   | impl ToUInt for Const<0> {
 |  first implementation here
...
4245 | impl ToUInt for Const<4294967296> {
 | ^ conflicting implementation for 
`generated::generic_const_mappings::Const<0_usize>`
...
error: could not compile `typenum` due to 32 previous errors
...
autopkgtest [01:08:50]:  summary
rust-typenum:@   FAIL non-zero exit status 101
librust-typenum-dev:const-generics FAIL non-zero exit status 101
librust-typenum-dev:default PASS
librust-typenum-dev:force_unix_path_separator PASS
librust-typenum-dev:i128 PASS
librust-typenum-dev:no_std PASS
librust-typenum-dev:strict PASS
librust-typenum-dev: PASS

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Scarlett Moore]

On Tue, Feb 21, 2023, 3:12 PM Ryan Kavanagh  wrote:

> On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
> >   Description : A tool for glamourous shell scripts
> >
> > A tool for glamorous shell scripts. Leverage the power of Bubbles and
> > Lip Gloss in your scripts and aliases without writing any Go code!
>
> This long description does not provide users with enough information to
> understand what the package does. What are "Bubbles" and "Lip Gloss" in
> a shell script? What is a "glamourous shell script"?
>
> It would be helpful if the package's long description satisfied §3.4.2
> of the Debian Policy Manual [0]:
>
> The description field needs to make sense to anyone, even people who
> have no idea about any of the things the package deals with. [3]
>
> [...]
>
> [3] The blurb that comes with a program in its announcements and/or
> README files is rarely suitable for use in a description. It is
> usually aimed at people who are already in the community where the
> package is used.
>
> Best wishes,
> Ryan
>
> [0]
> https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description
>
> --
> |)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
> |\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A
>

Yes sorry. I will update this description to a much more useful description
tomorrow.
Thanks,
Scarlett

Bug#1029829: Re: Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705

[Amanda Trusted]

During our security testing of the fixes, we found another attack vector for 
the issue similar to the one mentioned in 
CVE-2022-37704.

Dump can be manipulated by an attacker through the RSH environment variable, 
which is used to specify the shell binary to be used for remote backups.

By manipulating this variable and invoking Dump via rundump, an attacker can 
execute arbitrary code with root privileges.

We now filter out RSH environment variable to prevent this exploit.

The fix for this issue is available at - 
https://github.com/zmanda/amanda/pull/202.

Is there anything else we can help you with to avert the March 2nd auto removal?

We also recommend pointing to the github repository 
(https://github.com/zmanda/amanda.git) instead of pointing to svn as future 
development will continue on github and we would like to phase out svn.

Best Regards,

AmandaTrusted

From: Amanda Trusted 
Date: Wednesday, February 15, 2023 at 5:10 PM
To: 1029...@bugs.debian.org <1029...@bugs.debian.org>
Cc: j...@calhariz.com 
Subject: Re: Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
Hi Jose,

Here are the relevant bug fixes -
[0] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37704 
https://www.cve.org/CVERecord?id=CVE-2022-37704
Fix - https://github.com/zmanda/amanda/pull/197

[1] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37705 
https://www.cve.org/CVERecord?id=CVE-2022-37705
Fix - https://github.com/zmanda/amanda/pull/196


[2] CVE - https://security-tracker.debian.org/tracker/CVE-2022-37703 
https://www.cve.org/CVERecord?id=CVE-2022-37703
Fix - https://github.com/zmanda/amanda/pull/198

These 3 fixes are due for release as part of Amanda 3.5.3 within a week.

Let us know if there are any other action items for us.

Regards,

AmandaTrusted

Confidentiality Notice | The information transmitted by this email is intended 
only for the person or entity to which it is addressed. This email may contain 
proprietary, business-confidential and/or privileged material. If you are not 
the intended recipient of this message, be aware that any use, review, 
re-transmission, distribution, reproduction or any action taken in reliance 
upon this message is strictly prohibited. If you received this in error, please 
contact the sender and delete the material from all computers.

Bug#1031751: rust-ahash: autopkgtest failure

[Adrian Bunk]

Source: rust-ahash
Version: 0.8.3-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-ahash/31558299/log.gz

...
Testing map/aHash-alias
thread 'main' panicked at 'attempt to add with overflow', 
/usr/src/rustc-1.63.0/library/core/src/ops/arith.rs:786:1
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:48:5
   3: ::add_assign
 at /usr/src/rustc-1.63.0/library/core/src/ops/arith.rs:779:51
   4: >::add_assign
 at /usr/src/rustc-1.63.0/library/core/src/internal_macros.rs:127:17
   5: ahash::bench_map::{{closure}}::{{closure}}
 at ./tests/bench.rs:124:25
   6: criterion::bencher::Bencher::iter
 at /usr/share/cargo/registry/criterion-0.3.6/src/bencher.rs:88:23
   7: ahash::bench_map::{{closure}}
 at ./tests/bench.rs:119:13
   8: criterion::benchmark_group::BenchmarkGroup::bench_function::{{closure}}
 at 
/usr/share/cargo/registry/criterion-0.3.6/src/benchmark_group.rs:254:60
   9:  as 
criterion::routine::Routine>::bench::{{closure}}
 at /usr/share/cargo/registry/criterion-0.3.6/src/routine.rs:209:17
  10: core::iter::adapters::map::map_fold::{{closure}}
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/adapters/map.rs:84:28
  11: core::iter::traits::iterator::Iterator::fold
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/traits/iterator.rs:2370:21
  12:  as 
core::iter::traits::iterator::Iterator>::fold
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/adapters/map.rs:124:9
  13: core::iter::traits::iterator::Iterator::for_each
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/traits/iterator.rs:787:9
  14:  as 
alloc::vec::spec_extend::SpecExtend>::spec_extend
 at /usr/src/rustc-1.63.0/library/alloc/src/vec/spec_extend.rs:40:17
  15:  as 
alloc::vec::spec_from_iter_nested::SpecFromIterNested>::from_iter
 at 
/usr/src/rustc-1.63.0/library/alloc/src/vec/spec_from_iter_nested.rs:62:9
  16:  as 
alloc::vec::spec_from_iter::SpecFromIter>::from_iter
 at 
/usr/src/rustc-1.63.0/library/alloc/src/vec/spec_from_iter.rs:33:9
  17:  as 
core::iter::traits::collect::FromIterator>::from_iter
 at /usr/src/rustc-1.63.0/library/alloc/src/vec/mod.rs:2645:9
  18: core::iter::traits::iterator::Iterator::collect
 at 
/usr/src/rustc-1.63.0/library/core/src/iter/traits/iterator.rs:1792:9
  19:  as 
criterion::routine::Routine>::bench
 at /usr/share/cargo/registry/criterion-0.3.6/src/routine.rs:205:9
  20: criterion::routine::Routine::test
 at /usr/share/cargo/registry/criterion-0.3.6/src/routine.rs:18:9
  21: criterion::benchmark_group::BenchmarkGroup::run_bench
 at 
/usr/share/cargo/registry/criterion-0.3.6/src/benchmark_group.rs:339:21
  22: criterion::benchmark_group::BenchmarkGroup::bench_function
 at 
/usr/share/cargo/registry/criterion-0.3.6/src/benchmark_group.rs:254:9
  23: ahash::bench_map
 at ./tests/bench.rs:118:9
  24: ahash::benches
 at /usr/share/cargo/registry/criterion-0.3.6/src/macros.rs:71:17
  25: ahash::main
 at /usr/share/cargo/registry/criterion-0.3.6/src/macros.rs:127:17
  26: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.

error: test failed, to rerun pass `--bench ahash`
autopkgtest [13:15:47]: test rust-ahash-0.8:@: ---]
autopkgtest [13:15:47]: test rust-ahash-0.8:@:  - - - - - - - - - - results - - 
- - - - - - - -
rust-ahash-0.8:@ FAIL non-zero exit status 101
...
autopkgtest [13:31:10]:  summary
rust-ahash-0.8:@ FAIL non-zero exit status 101
rust-ahash-0.8:default FAIL non-zero exit status 101
rust-ahash-0.8:std   FAIL non-zero exit status 101
rust-ahash-0.8:  PASS
rust-ahash-0.8:compile-time-rng PASS
rust-ahash-0.8:no-rng PASS
rust-ahash-0.8:runtime-rng PASS

Bug#1031750: redis-server: "delaycompess" typo in logrotate file

[Adrian Bunk]

Package: redis-server
Version: 5:7.0.8-2
Severity: serious

https://piuparts.debian.org/sid/fail/redis-server_5:7.0.8-3.log

...
  error: /etc/logrotate.d/redis-server:7 unknown option 'delaycompess' -- 
ignoring line
...


src:redis has two packages with logrotate files,
only the one in redis-sentinel was fixed in 5:7.0.8-3.

Bug#1031749: afnix FTBFS on 32bit: afnix-bexec: failure t_utility

[Adrian Bunk]

Source: afnix
Version: 3.8.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=afnix=3.8.0-1

...
running: t_utility
afnix-bexec: failure t_utility
make[6]: *** [../../../../cnf/mak/afnix-runx.mak:301: t_utility.exe] Error 1

Bug#1031748: zoph fails to purge when adduser is not installed

[Adrian Bunk]

Package: zoph
Version: 0.9.19-1
Severity: serious

https://piuparts.debian.org/sid/fail/zoph_1.0.1-1.log

...
  Purging configuration files for zoph (1.0.1-1) ...
  /var/lib/dpkg/info/zoph.postrm: 39: delgroup: not found
  dpkg: error processing package zoph (--purge):
   installed zoph package post-removal script subprocess returned error exit 
status 127
  Errors were encountered while processing:
   zoph
...


https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called

The postrm script is called after the package’s files have been removed or 
replaced. The package whose postrm is being called may have previously been 
deconfigured and only be “Unpacked”, at which point subsequent package changes 
do not consider its dependencies. Therefore, 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.

Bug#1031747: python-socks: autopkgtest regression

[Adrian Bunk]

Source: python-socks
Version: 2.1.1-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-socks/31564223/log.gz

...
autopkgtest [18:13:28]: test unittests: [---
=== python3.11 ===
ImportError while loading conftest 
'/tmp/autopkgtest-lxc.hgtwobwo/downtmp/autopkgtest_tmp/tests/conftest.py'.
tests/conftest.py:34: in 
from tests.proxy_server import ProxyConfig, ProxyServer
tests/proxy_server.py:9: in 
from tiny_proxy import (
E   ModuleNotFoundError: No module named 'tiny_proxy'
autopkgtest [18:13:29]: test unittests: ---]
autopkgtest [18:13:29]: test unittests:  - - - - - - - - - - results - - - - - 
- - - - -
unittestsFAIL non-zero exit status 4
...

Bug#1031382: RFS: libkysdk-base/1.0.1-1 [ITP] -- Kylin SDK basic library

[Boyuan Yang]

Control: tags -1 +moreinfo

Indeed, please fix the error listed below before we can proceed.

Thanks,
Boyuan Yang

On Thu, 16 Feb 2023 19:55:44 +0100 Adam Borowski 
wrote:
> On Thu, Feb 16, 2023 at 11:05:42AM +0800, kevin wrote:
> >  * Package name : libkysdk-base
> >    Version  : 1.0.1-1
> 
> >  libkysdk-base (1.0.1-1) unstable; urgency=medium
> >  .
> >    * Initial release. (Closes: #1031344)
> 
> Hi!
> Alas, the package fails to build:
> 
> .
> dh_missing: warning: etc/kysdk/kysdk-base/kylog-rotate-default exists in
debian/tmp but is not installed to anywhere (related file: "src/log/kylog-
rotate-default")
> dh_missing: warning: usr/include/kysdk/kysdk-base/libkylog.h exists in
debian/tmp but is not installed to anywhere (related file:
"src/log/libkylog.h")
> dh_missing: warning: usr/include/kysdk/kysdk-base/listdata.h exists in
debian/tmp but is not installed to anywhere (related file: "src/utils/data-
structure/linklist/listdata.h")
> dh_missing: warning: usr/include/kysdk/kysdk-base/skip_linklist.h exists
in debian/tmp but is not installed to anywhere (related file:
"src/utils/data-structure/linklist/skip_linklist/skip_linklist.h")
> dh_missing: error: missing files, aborting
> 
>   While detecting missing files, dh_missing noted some files with a
similar name to those
>   that were missing.  This error /might/ be resolved by replacing
references to the
>   missing files with the similarly named ones that dh_missing found -
assuming the content
>   is identical.
> 
>   As an example, you might want to replace:
>    * src/log/kylog-rotate-default
>   with:
>    * etc/kysdk/kysdk-base/kylog-rotate-default
>   in a file in debian/ or as argument to one of the dh_* tools called
from debian/rules.
>   (Note it is possible the paths are not used verbatim but instead
directories 
>   containing or globs matching them are used instead)
> 
>   Alternatively, add the missing file to debian/not-installed if it
cannot and should not
>   be used.
> 
>   The following debhelper tools have reported what they installed
(with files per package)
>    * dh_install: libkysdk-base (0), libkysdk-base-dev (1), libkysdk-
config (2), libkysdk-config-dev (3), libkysdk-log (5), libkysdk-log-dev (3),
libkysdk-timer (2), libkysdk-timer-dev (3), libkysdk-utils (4), libkysdk-
utils-dev (9)
>    * dh_installdocs: libkysdk-base (0), libkysdk-base-dev (0),
libkysdk-config (0), libkysdk-config-dev (0), libkysdk-log (0), libkysdk-
log-dev (0), libkysdk-timer (0), libkysdk-timer-dev (0), libkysdk-utils (0),
libkysdk-utils-dev (0)
>   If the missing files are installed by another tool, please file a
bug against it.
>   When filing the report, if the tool is not part of debhelper itself,
please reference the
>   "Logging helpers and dh_missing" section from the "PROGRAMMING"
guide for debhelper (10.6.3+).
> (in the debhelper package:
/usr/share/doc/debhelper/PROGRAMMING.gz)
>   Be sure to test with dpkg-buildpackage -A/-B as the results may vary
when only a subset is built
>   If the omission is intentional or no other helper can take care of
this consider adding the
>   paths to debian/not-installed.
> `
> 
> 
> Meow!
> -- 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine.
> ⢿⡄⠘⠷⠚⠋⠀
> ⠈⠳⣄
> 
> 



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

Bug#1023623: dolphin: In file rename dialog: Delete and Backspace act on file, not on text

[6251d5d9-c833-4b45-8e6e-261c9164db95]

Hi

I had the same symptoms and found a cause that I want to share with you.

For me, the cause was keyboard layouts. When I had German T3 or German 
E1 enabled or even only in the list of active layouts in Plasma, I 
observed the described behaviour.


I had this configured, because it is given as a workaround for neoqwertz 
layout on https://www.neo-layout.org/Probleme/FAQ/#linux-unix-bsd


The third workaround option (setting modifier_mapping) had the same effect.

Cure: have only one keyboard layout "German" configured in KDE Plasma.

Regards
Philipp Schwarz

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Ryan Kavanagh]

On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
>   Description : A tool for glamourous shell scripts
> 
> A tool for glamorous shell scripts. Leverage the power of Bubbles and
> Lip Gloss in your scripts and aliases without writing any Go code!

This long description does not provide users with enough information to
understand what the package does. What are "Bubbles" and "Lip Gloss" in
a shell script? What is a "glamourous shell script"?

It would be helpful if the package's long description satisfied §3.4.2
of the Debian Policy Manual [0]:

The description field needs to make sense to anyone, even people who
have no idea about any of the things the package deals with. [3]

[...]

[3] The blurb that comes with a program in its announcements and/or
README files is rarely suitable for use in a description. It is
usually aimed at people who are already in the community where the
package is used.

Best wishes,
Ryan

[0] 
https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#983597: Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()

[Dennis Filder]

This may have gotten fixed by the fix for QTBUG-107850[1] (commit
7487332)[2].  QTBUG-84858 gets a tacit mention there, but is not among
the list of duplicates that got closed through this (even though it
probably should be).

I hastily backported this to 5.15.8 (see attachment), but have not yet
checked if it actually compiles (the test might use functions/macros
missing from 5.15) or works.  I can't look into this more currently
since I'm somewhat busy.  Hopefully I can try it out this weekend.

Regards.

1: https://bugreports.qt.io/browse/QTBUG-107850
2: 
https://invent.kde.org/qt/qt/qtdeclarative/-/commit/74873324bdf3399753f9fcaf7461c0e00df628b1
Description: backport commit 7487332 to hopefully fix #983597
 Edited from the original for 6.5.0 FF: https://invent.kde.org/qt/qt/qtdeclarative/-/commit/74873324bdf3399753f9fcaf7461c0e00df628b1
--- a/src/quick/items/qquickitem.cpp
+++ b/src/quick/items/qquickitem.cpp
@@ -2326,6 +2326,7 @@
 QQuickItem::~QQuickItem()
 {
 Q_D(QQuickItem);
+d->inDestructor = true;
 
 if (d->windowRefCount > 1)
 d->windowRefCount = 1; // Make sure window is set to null in next call to derefWindow().
@@ -2689,9 +2690,8 @@
 
 const bool wasVisible = isVisible();
 op->removeChild(this);
-if (wasVisible) {
+if (wasVisible && !op->inDestructor)
 emit oldParentItem->visibleChildrenChanged();
-}
 } else if (d->window) {
 QQuickWindowPrivate::get(d->window)->parentlessItems.remove(this);
 }
@@ -2768,8 +2768,9 @@
 
 d->itemChange(ItemParentHasChanged, d->parentItem);
 
-emit parentChanged(d->parentItem);
-if (isVisible() && d->parentItem)
+if (!d->inDestructor)
+emit parentChanged(d->parentItem);
+if (isVisible() && d->parentItem && !QQuickItemPrivate::get(d->parentItem)->inDestructor)
 emit d->parentItem->visibleChildrenChanged();
 }
 
@@ -2965,7 +2966,8 @@
 
 itemChange(QQuickItem::ItemChildRemovedChange, child);
 
-emit q->childrenChanged();
+if (!inDestructor)
+emit q->childrenChanged();
 }
 
 void QQuickItemPrivate::refWindow(QQuickWindow *c)
@@ -3194,6 +3196,7 @@
 , touchEnabled(false)
 #endif
 , hasCursorHandler(false)
+, inDestructor(false)
 , dirtyAttributes(0)
 , nextDirtyItem(nullptr)
 , prevDirtyItem(nullptr)
@@ -6106,9 +6109,11 @@
 QAccessible::updateAccessibility();
 }
 #endif
-emit q->visibleChanged();
-if (childVisibilityChanged)
-emit q->visibleChildrenChanged();
+if (!inDestructor) {
+emit q->visibleChanged();
+if (childVisibilityChanged)
+emit q->visibleChildrenChanged();
+}
 
 return true;// effective visibility DID change
 }
--- a/src/quick/items/qquickitem_p.h
+++ b/src/quick/items/qquickitem_p.h
@@ -472,6 +472,7 @@
 bool replayingPressEvent:1;
 bool touchEnabled:1;
 bool hasCursorHandler:1;
+quint32 inDestructor:1; // has entered ~QQuickItem
 
 enum DirtyType {
 TransformOrigin = 0x0001,
--- a/tests/auto/quick/qquickitem2/tst_qquickitem.cpp
+++ b/tests/auto/quick/qquickitem2/tst_qquickitem.cpp
@@ -130,6 +130,7 @@
 void isAncestorOf();
 
 void grab();
+void signalsOnDestruction();
 
 private:
 QQmlEngine engine;
@@ -3520,6 +3521,52 @@
 QVERIFY(!sub2.isAncestorOf());
 }
 
+/*
+Items that are getting destroyed should not emit property change notifications.
+*/
+void tst_QQuickItem::signalsOnDestruction()
+{
+QQuickWindow window;
+window.show();
+
+// visual children, but not QObject children
+std::unique_ptr parent(new QQuickItem(window.contentItem()));
+std::unique_ptr child(new QQuickItem);
+std::unique_ptr grandChild(new QQuickItem);
+
+QSignalSpy childrenSpy(parent.get(), ::childrenChanged);
+QSignalSpy visibleChildrenSpy(parent.get(), ::visibleChildrenChanged);
+QSignalSpy childParentSpy(child.get(), ::parentChanged);
+QSignalSpy childChildrenSpy(child.get(), ::childrenChanged);
+QSignalSpy childVisibleChildrenSpy(child.get(), ::visibleChanged);
+QSignalSpy grandChildParentSpy(grandChild.get(), ::parentChanged);
+
+child->setParentItem(parent.get());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildrenSpy.count(), 1);
+QCOMPARE(childParentSpy.count(), 1);
+QCOMPARE(childChildrenSpy.count(), 0);
+QCOMPARE(childVisibleChildrenSpy.count(), 0);
+
+grandChild->setParentItem(child.get());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildrenSpy.count(), 1);
+QCOMPARE(childParentSpy.count(), 1);
+QCOMPARE(childChildrenSpy.count(), 1);
+QCOMPARE(childVisibleChildrenSpy.count(), 0);
+QCOMPARE(grandChildParentSpy.count(), 1);
+
+parent.reset();
+
+QVERIFY(!child->parentItem());
+QVERIFY(grandChild->parentItem());
+QCOMPARE(childrenSpy.count(), 1);
+QCOMPARE(visibleChildrenSpy.count(), 1);
+QCOMPARE(childParentSpy.count(), 2);
+

Bug#1031701: fixed in python-xlrd 2.0.1-1

[Diane Trout]

Sorry my coworker got hit by this too, he worked around it by using
libreoffice to convert the .xls file to .xlsx.

I'd updated the xlrd package to 2.0.1 and pushed it to experimental to
see how much it might break,

Looks like there was some more discussion while I was fiddling with the
package.

On the plus side the update also enabled autopkgtests for xlrd.

Though I had to switch from pulling from pypi to github to keep being
able to build the -docs package, as upstream removed it from their pypi
release.

Diane




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

Bug#923824: libdancer2-plugin-database-perl: FTBFS randomly (failing tests)

[Étienne Mollier]

Control: tags -1 patch

It turned out I managed to find a workaround.  Putting it below
for ulterior reference if need be; few more details are
available on upstream bug tracker:

---8<--8<--8<--8<---
--- libdancer2-plugin-database-perl.orig/t/lib/TestApp.pm
+++ libdancer2-plugin-database-perl/t/lib/TestApp.pm
@@ -209,6 +209,9 @@
 var connection_failed => 1;
 };
 get '/database_connection_failed_fires' => sub {
+# Avoid catching an old handle which may not have expired yet
+database()->disconnect;
+sleep 0.2;
 # Give a ridiculous database filename which should never exist in order to
 # force a connection failure
 my $handle = database({ 
--->8-->8-->8-->8---

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/3, please excuse my verbosity.
On air: Chicago - Beginnings


signature.asc
Description: PGP signature

Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

[Felix Geyer]

On 21.02.23 20:46, Sandro Tosi wrote:

it produces output on stderr, which many tools consider it an error
and fails build.


When raising the severity of a bug to grave I would expect some concrete details
on what exactly is broken instead of a hand-wavy "breaks some stuff".
But anyway let's focus on the issue.


dateutil.zoneinfo really shouldn't be used directly and I don't see any


can you back this quote please? zoneinfo is part of the public API,
and just breaking it (via the removal of the zonefile) and say not to
use it is going in the wrong direction.


https://dateutil.readthedocs.io/en/stable/zoneinfo.html#dateutil.zoneinfo.gettz
has a warning that you shouldn't use it.
For get_zonefile_instance() it only says "using the data provided by the
dateutil package". This implies that the data is outdated most of the time
since it's rarely updated. Unfortunately that's not clearly stated.

Of course it's part of the public API. Unfortunately its design leaves us only
with bad options.


I guess we have two options if we want to change the current behavior:
1) Ship the outdated tzdata tarball even though nothing should really use it.
2) Add a patch to remove the dateutil.zoneinfo fallback.


i think you're missing

3) fix dateutil.zoneinfo to use a system-available zone info file


It wouldn't be fixing it since the sole purpose of this API is to use the
bundled timezone database instead of the potentially absent (from a general POV,
of course the Debian package depends on tzdata) system timezone database.

I'm inclined to just ship the bundled timezone database with the package:

- We wouldn't have to permanently patch the code.
- dateutil consumers that just want accurate timezone information are supposed
  to use dateutil.tz.gettz() which already prefers the system database.
- Direct dateutil.zoneinfo users kind of opted into receiving outdated timezone
  information.

Felix

Bug#1031415: FAI fix

[Thomas Lange]

In FAI, we cannot easily determine which mke2fs or grub version will
be used in the target system since we support deb and rpm based and
other linux distributions.

As I did with the older issues of mke2fs (metadata_csum) I will add a
comment, so the user can decide if he needs to add the option
-O ^metadata_csum_seed

In FAI this has to be done in the config examples (which goes into the
package fai-doc), not in the code itself. I therefore decrease the
severity to normal.

-- 
regards Thomas

Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')

[James Addison]

Source: feynmf
Followup-For: Bug #1029439
X-Debbugs-Cc: debian-tex-ma...@lists.debian.org
Control: tags -1 help

I'm adding the 'help' tag to this bug, and am cc'ing the debian-tex-maint list,
because it feels like extra brainpower could aid in figuring this one out more
quickly.

A brief recap of this bug so far, for folks reading the list:

  * the feynmf Debian package is failing to build in testing (bookworm)
  * the bug may somehow be related to the mflogo TeX package
  * successful build logs are available on buildd.debian.org for comparison

Bug#1031746: ITP: libdex -- Library for deferred execution

[Jeremy Bícha]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-gtk-gn...@lists.debian.org
Owner: jeremy.bi...@canonical.com

Package Name: libdex-1-1 (etc)
Version: 0.1.0
Upstream Author: Christian Hergert
License: LGPL-2.1+
Programming Lang: C

Description: Library for deferred execution
 Dex is a library supporting "Deferred Execution" with the explicit goal of
 integrating with GNOME and GTK-based applications. It provides primatives
 for supporting futures in a variety of ways with both read-only and writable
 views. Additionally, integration with existing asynchronous-based APIs is
 provided through the use of wrapper promises.
 .
 "Fibers" are implemented which allows for writing synchronous looking code
 which calls asynchronous APIs from GIO underneath.

Other Info
--
This package will be maintained by the Debian GNOME team. Packaging is at
https://salsa.debian.org/gnome-team/libdex

It is a required dependency for GNOME Builder 44.

Thanks,
Jeremy Bicha

Bug#1021582: closed by Piotr Ożarowski (fixed in 1.0.4-1)

[Jelmer Vernooij]

On Tue, Feb 21, 2023 at 06:12:30PM +, Debian Bug Tracking System wrote:
> Date: Tue, 21 Feb 2023 19:10:43 +0100
> From: Piotr Ożarowski 
> To: 1021582-d...@bugs.debian.org
> Subject: fixed in 1.0.4-1
> 
> Source: pytest-aiohttp
> Source-Version: 1.0.4-1
> 
> ups, looks like I hijacked your ITP. Sorry.
> If you want to comaintain or take over this package, just update it in
> DPT repo.
> 
> I needed this package as a build dependency for another package and
> apparently didn't check WNPP close enough

No worries, all good - thanks for packaging it! Your package ended up in the
archive before I managed to do duplicate work on it.

Cheers,

Jelmer

Bug#1031745: gdb: breaks rustc gdb debuginfo tests

[Fabian Grünbichler]

Package: gdb
Version: 13.1-1
Severity: serious
Control: affects -1 src:rustc
Justification: breaks unrelated software

While preparing an update to rustc 1.65 for experimental, we noticed
that the recent gdb update in sid makes rustc FTBFS by causing 5 of its
gdb-integration test cases fail.

test [debuginfo-gdb] src/test/debuginfo/destructured-fn-argument.rs ... FAILED
test [debuginfo-gdb] src/test/debuginfo/function-arguments.rs ... FAILED
test [debuginfo-gdb] src/test/debuginfo/lexical-scope-in-stack-closure.rs ... 
FAILED
test [debuginfo-gdb] src/test/debuginfo/lexical-scope-in-unique-closure.rs ... 
FAILED
test [debuginfo-gdb] src/test/debuginfo/unsized.rs ... FAILED
command did not execute successfully: 
"/<>/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" 
"--compile-lib-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib"
 "--rustc-path" 
"/<>/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--src-base" 
"/<>/src/test/debuginfo" "--build-base" 
"/<>/build/x86_64-unknown-linux-gnu/test/debuginfo" "--stage-id" 
"stage2-x86_64-unknown-linux-gnu" "--suite" "debuginfo" "--mode" "debuginfo" 
"--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" 
"--llvm-filecheck" "/usr/lib/llvm-15/bin/FileCheck" "--optimize-tests" 
"--linker" "x86_64-linux-gnu-gcc" "--host-rustcflags" "-Crpath -Cdebuginfo=0  
-Lnative=/<>/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
 "--target-rustcflags" "-Crpath -Cdebuginfo=0  
-Lnative=/<>/build/x86_64-unknown-linux-gnu/native/rust-test-helpers"
 "--python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--skip" "src/tools/tidy" 
"--verbose" "--llvm-version" "15.0.7" "--llvm-components" "aarch64 
aarch64asmparser aarch64codegen aarch64desc aarch64disassembler aarch64info 
aarch64utils aggressiveinstcombine all all-targets amdgpu amdgpuasmparser 
amdgpucodegen amdgpudesc amdgpudisassembler amdgpuinfo amdgputargetmca 
amdgpuutils analysis arm armasmparser armcodegen armdesc armdisassembler 
arminfo armutils asmparser asmprinter avr avrasmparser avrcodegen avrdesc 
avrdisassembler avrinfo binaryformat bitreader bitstreamreader bitwriter bpf 
bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cfguard codegen core 
coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym debuginfomsf 
debuginfopdb demangle dlltooldriver dwarflinker dwp engine executionengine 
extensions filecheck frontendopenacc frontendopenmp fuzzercli fuzzmutate 
globalisel hexagon hexagonasmparser hexagoncodegen hexagondesc 
hexagondisassembler hexagoninfo instcombine instrumentation interfacestub 
interpreter ipo irreader jitlink lanai lanaiasmparser lanaicodegen lanaidesc 
lanaidisassembler lanaiinfo libdriver lineeditor linker lto m68k m68kasmparser 
m68kcodegen m68kdesc m68kdisassembler m68kinfo mc mca mcdisassembler mcjit 
mcparser mips mipsasmparser mipscodegen mipsdesc mipsdisassembler mipsinfo 
mirparser msp430 msp430asmparser msp430codegen msp430desc msp430disassembler 
msp430info native nativecodegen nvptx nvptxcodegen nvptxdesc nvptxinfo 
objcarcopts objcopy object objectyaml option orcjit orcshared orctargetprocess 
passes perfjitevents powerpc powerpcasmparser powerpccodegen powerpcdesc 
powerpcdisassembler powerpcinfo profiledata remarks riscv riscvasmparser 
riscvcodegen riscvdesc riscvdisassembler riscvinfo runtimedyld scalaropts 
selectiondag sparc sparcasmparser sparccodegen sparcdesc sparcdisassembler 
sparcinfo support symbolize systemz systemzasmparser systemzcodegen systemzdesc 
systemzdisassembler systemzinfo tablegen target textapi transformutils ve 
veasmparser vecodegen vectorize vedesc vedisassembler veinfo webassembly 
webassemblyasmparser webassemblycodegen webassemblydesc webassemblydisassembler 
webassemblyinfo webassemblyutils windowsdriver windowsmanifest x86 x86asmparser 
x86codegen x86desc x86disassembler x86info x86targetmca xcore xcorecodegen 
xcoredesc xcoredisassembler xcoreinfo xray" "--system-llvm" "--cc" "" "--cxx" 
"" "--cflags" "" "--cxxflags" "" "--adb-path" "adb" "--adb-test-dir" 
"/data/tmp/work" "--android-cross-path" "" "--channel" "stable"

our rustc build uses an (arch-dependent) cut-off for the number of "allowed to
fail" tests - for amd64 it is 8, the current version of rustc in testing/sid
(1.63.0+dfsg1-2) had 2 such failing tests when it was initially built, a
rebuild with gdb from unstable causes the fail count to go to 8 - while not
failing the build itself, the errors look problematic enough to me that it
should likely be looked at more closely *before* gdb ends up in
testing/bookworm. it does also prevent us from getting through the backlog of
rustc upstream releases in experimental, since the baseline for rustc 1.65 test
failures is 4, and the 6 additional ones caused by gdb push it over the
threshold.

the same tests are failing for
- rustc 1.65 (not yet uploaded, MR on salsa[0] which successfully 

Bug#1031327: gbp-rpm-ch: Wrong changelog header format (missing dash before version)

[Samuel Henrique]

Hello Guido,

> You need to fixup the tests too though

I have updated the Github PR and also attached the new patch with the
unit tests fixed.

Thank you,

-- 
Samuel Henrique 
From b2a7100730306d7e333ce84c00ccdaf693e6f081 Mon Sep 17 00:00:00 2001
From: Samuel Henrique 
Date: Mon, 1 Aug 2022 18:49:19 +0100
Subject: [PATCH] Fix RPM changelog header format (missing dash before version)

 As stated in the documentation at:
 https://rpm-packaging-guide.github.io/#working-with-spec-files

 "...
 Follow this format for the first line:

 * Day-of-Week Month Day Year Name Surname  - Version-Release
 ..."
---
 gbp/rpm/policy.py  |  2 +-
 tests/30_test_rpm_changelog.py | 26 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/gbp/rpm/policy.py b/gbp/rpm/policy.py
index a2155e20..59989bb8 100644
--- a/gbp/rpm/policy.py
+++ b/gbp/rpm/policy.py
@@ -85,7 +85,7 @@ class Changelog(object):
 body_name_re = r'\[(?P.*)\]'
 
 # Changelog header format (when writing out changelog)
-header_format = "* %(time)s %(name)s <%(email)s> %(revision)s"
+header_format = "* %(time)s %(name)s <%(email)s> - %(revision)s"
 header_time_format = "%a %b %d %Y"
 header_rev_format = "%(version)s"
 
diff --git a/tests/30_test_rpm_changelog.py b/tests/30_test_rpm_changelog.py
index 85142a41..2a0d068d 100644
--- a/tests/30_test_rpm_changelog.py
+++ b/tests/30_test_rpm_changelog.py
@@ -34,7 +34,7 @@ def test_str_format(self):
 time = datetime(2014, 1, 29, 12, 13, 14)
 header = _ChangelogHeader(RpmPkgPolicy, time, name="John Doe",
   email="u...@host.com", revision="1")
-eq_(str(header), "* Wed Jan 29 2014 John Doe  1\n")
+eq_(str(header), "* Wed Jan 29 2014 John Doe  - 1\n")
 
 def test_str_format_err(self):
 """Test missing properties"""
@@ -79,7 +79,7 @@ def setup(self):
 def test_str_format(self):
 """Basic test"""
 section = self.default_sect
-eq_(str(section), "* Wed Jan 29 2014 J. D.  1\n- my change\n\n")
+eq_(str(section), "* Wed Jan 29 2014 J. D.  - 1\n- my change\n\n")
 
 def test_append_entry(self):
 """Test add_entry() method"""
@@ -87,7 +87,7 @@ def test_append_entry(self):
 entry = _ChangelogEntry(RpmPkgPolicy, author="",
 text="- another\n  change")
 new_entry = section.append_entry(entry)
-eq_(str(section), "* Wed Jan 29 2014 J. D.  1\n- my change\n"
+eq_(str(section), "* Wed Jan 29 2014 J. D.  - 1\n- my change\n"
   "- another\n  change\n\n")
 eq_(new_entry, section.entries[-1])
 
@@ -96,25 +96,25 @@ def test_set_header(self):
 section = self.default_sect
 time = datetime(2014, 1, 30)
 section.set_header(time=time, name="Jane", email="u@h", revision="1.1")
-eq_(str(section), "* Thu Jan 30 2014 Jane  1.1\n- my change\n\n")
+eq_(str(section), "* Thu Jan 30 2014 Jane  - 1.1\n- my change\n\n")
 
 
 class TestChangelogParser(object):
 """Test the default changelog parser"""
 
 cl_default_style = """\
-* Wed Jan 29 2014 Markus Lehtonen  0.3-1
+* Wed Jan 29 2014 Markus Lehtonen  - 0.3-1
 - Version bump
 - Drop foo.patch
 
-* Tue Jan 28 2014 Markus Lehtonen  0.2
+* Tue Jan 28 2014 Markus Lehtonen  - 0.2
 - Update to 0.2
 
-* Mon Jan 27 2014 Markus Lehtonen  0.1
+* Mon Jan 27 2014 Markus Lehtonen  - 0.1
 - Initial version
 """
 cl_with_authors = """\
-* Wed Jan 29 2014 Markus Lehtonen  0.3-1
+* Wed Jan 29 2014 Markus Lehtonen  - 0.3-1
 [Markus Lehtonen]
 - Version bump
 [John Doe]
@@ -122,17 +122,17 @@ class TestChangelogParser(object):
 """
 # Invalid timestamp / name
 cl_broken_header_1 = """\
-* Wed Jan 29 2014Markus Lehtonen  0.3-1
+* Wed Jan 29 2014Markus Lehtonen  - 0.3-1
 - Version bump
 """
 # Whitespace before the asterisk in the header
 cl_broken_header_2 = """\
- * Wed Jan 29 2014 Markus Lehtonen  0.3-1
+ * Wed Jan 29 2014 Markus Lehtonen  - 0.3-1
 - Version bump
 """
 # Invalid timestamp
 cl_broken_header_3 = """\
-* Wed Jan 32 2014 Markus Lehtonen  0.3-1
+* Wed Jan 32 2014 Markus Lehtonen  - 0.3-1
 - Version bump
 """
 # Missing email
@@ -143,7 +143,7 @@ class TestChangelogParser(object):
 # Garbage before section header
 cl_broken_header_5 = """\
 ---garbage---
-* Wed Jan 29 2014 Markus Lehtonen  0.3-1
+* Wed Jan 29 2014 Markus Lehtonen  - 0.3-1
 - Version bump
 """
 
@@ -222,5 +222,5 @@ def test_add_section(self):
 time = datetime(2014, 1, 30)
 new_section = changelog.add_section(time=time, name="Jane Doe",
 email="j...@doe.com", revision="1.2")
-eq_(str(changelog), "* Thu Jan 30 2014 Jane Doe  1.2\n\n")
+eq_(str(changelog), "* Thu Jan 30 2014 Jane Doe  - 1.2\n\n")
 eq_(new_section, changelog.sections[0])

Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')

[James Addison]

Source: feynmf
Followup-For: Bug #1029439

Assuming that we want to keep the feynmf sources as-is (I think we do;
feynmf.dtx hasn't changed[1] since 1996, a sign of stability), then this bug
seems like a regression in another component.

Looking at the build logs for a failure-to-build[2] in this thread and a
previous successful build[3], it looks like there's some divergence after
this common line of output:

  Writing index file fmfmanps.idx

And, reading a few lines below that in what I'm guessing is a LaTeX call stack
(a series of package names, one-per-line), the common element that both call
stacks originate from is 'l3backend-dvips.def', part of the latex3[4] codebase.

My guess would be that something in latex3 has changed over the course of the
past year or two that has introduced this problem as a side-effect.

The 'l3backend-dvips.def' file is currently part of the 'texlive-latex-base'
Debian package.

[1] - https://www.ctan.org/tex-archive/macros/latex/contrib/feynmf

[2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029439#5

[3] - 
https://buildd.debian.org/status/fetch.php?pkg=feynmf=all=1.08-13=1636243992=0

[4] - https://github.com/latex3/latex3/

Bug#923824: libdancer2-plugin-database-perl: FTBFS randomly (failing tests)

[Étienne Mollier]

Control: tags -1 confirmed
Control: forwarded -1 
https://github.com/bigpresh/Dancer-Plugin-Database/issues/102

It took me several retries before triggering, but I ended up
hitting the same case of test failure, so it looks pretty much
hardware independent.  This looks to affect autopkgtest as well
on occasions[1], so can be annoying during testing migrations.
Upstream has been made aware of the issue at some point, but no
feedback from them so far.  I'm not sure how to fix that myself,
but we may be notified eventually if the issue is closed
upstream thanks to bts triage.

[1]: 
https://ci.debian.net/data/autopkgtest/testing/amd64/libd/libdancer2-plugin-database-perl/31340832/log.gz

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#998105: The issue persists, was Re:

[Sven Geuer]

Control: reopen -1 =

Hello Christian,

On Fri, 20 Jan 2023 11:01:33 + c.bu...@posteo.jp wrote:
> Dear Sven,
> 
> there is a new release 1.3.3 in "unstable" branch of Debian.
> 
> Can you please try to reproduce the problem with that version and
> then report back.
> 
> Thanks
> Christian

Unfortunately BiT version 1.3.3 still fails with a version of python3-
keyring offering keyring.backends.chainer.

Debug output:

   $ backintime-qt --debug
   DEBUG: [common/backintime.py:589 argParse] Arguments: {'debug': True} | 
unknownArgs: []
   
   Back In Time
   Version: 1.3.3
   
   Back In Time comes with ABSOLUTELY NO WARRANTY.
   This is free software, and you are welcome to redistribute it
   under certain conditions; type `backintime --license' for details.
   
   DEBUG: [common/backintime.py:677 getConfig] config file: 
/home/sg/.config/backintime/config
   DEBUG: [common/backintime.py:678 getConfig] share path: 
/home/sg/.local/share/backintime
   DEBUG: [common/backintime.py:679 getConfig] profiles: 1=Hauptprofil
   DEBUG: [common/pluginmanager.py:240 PluginManager.load] Register plugin path 
/usr/share/backintime/plugins
   DEBUG: [common/pluginmanager.py:257 PluginManager.load] Add plugin 
qt4plugin.py
   DEBUG: [common/pluginmanager.py:257 PluginManager.load] Add plugin 
notifyplugin.py
   QSocketNotifier: Can only be used with threads started with QThread
   DEBUG: [qt/qttools.py:175 createQApplication] QT QPA platform plugin: wayland
   DEBUG: [qt/qttools.py:176 createQApplication] QT_QPA_PLATFORMTHEME=gnome
   DEBUG: [qt/qttools.py:178 createQApplication] QT_STYLE_OVERRIDE=
   DEBUG: [qt/qttools.py:179 createQApplication] QT active style: fusion
   DEBUG: [qt/qttools.py:180 createQApplication] QT fallback style: Adwaita
   DEBUG: [qt/qttools.py:181 createQApplication] QT supported styles: 
['Windows', 'Fusion']
   DEBUG: [qt/qttools.py:182 createQApplication] themeSearchPaths: 
['/usr/share/icons', ':/icons']
   DEBUG: [qt/qttools.py:183 createQApplication] fallbackSearchPaths: []
   DEBUG: [qt/qttools.py:185 createQApplication] Is SystemTray available: False
   DEBUG: [qt/qttools.py:197 createQApplication] Trying to set App ID for 
non-privileged user
   DEBUG: [common/tools.py:862 keyringSupported] Available keyring backends:
   DEBUG: [common/tools.py:865 keyringSupported] keyring.backends.fail.Keyring 
(priority: 0)
   DEBUG: [common/tools.py:865 keyringSupported] 
keyring.backends.chainer.ChainerBackend (priority: 10)
   DEBUG: [common/tools.py:865 keyringSupported] 
keyring.backends.SecretService.Keyring (priority: 5)
   DEBUG: [common/tools.py:865 keyringSupported] 
keyring.backends.libsecret.Keyring (priority: 4.8)
   DEBUG: [common/tools.py:878 keyringSupported] Metaclass 
keyring.backends.Gnome.Keyring not found: AttributeError("module 
'keyring.backends' has no attribute 'Gnome'")
   DEBUG: [common/tools.py:880 keyringSupported] Metaclass 
keyring.backends.kwallet.Keyring not found: AttributeError("module 
'keyring.backends.kwallet' has no attribute 'Keyring'")
   DEBUG: [common/tools.py:884 keyringSupported] Metaclass 
keyring.backend.SecretServiceKeyring not found: AttributeError("module 
'keyring.backend' has no attribute 'SecretServiceKeyring'")
   DEBUG: [common/tools.py:886 keyringSupported] Metaclass 
keyring.backend.GnomeKeyring not found: AttributeError("module 
'keyring.backend' has no attribute 'GnomeKeyring'")
   DEBUG: [common/tools.py:888 keyringSupported] Metaclass 
keyring.backend.KDEKWallet not found: AttributeError("module 'keyring.backend' 
has no attribute 'KDEKWallet'")
   DEBUG: [common/tools.py:899 keyringSupported] Available supported backends: 
[, ]
   DEBUG: [common/tools.py:905 keyringSupported] No appropriate keyring found. 
'keyring.backends.chainer' can't be used with BackInTime
   [...]

I still need to pin python3-keyring to use
keyring.backends.SecretService.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

[Sandro Tosi]

On Sun, Jan 29, 2023 at 9:45 AM Felix Geyer  wrote:
>
> On Sat, 7 Jan 2023 03:34:19 -0500 Sandro Tosi  wrote:
> > > python-dateutil expects to have 'dateutil-zoneinfo.tar.gz' in it's 
> > > directory
> > > tree, but this file is removed in the packaging.
> > >
> > > Error:
> > > "/usr/lib/python3/dist-packages/dateutil/zoneinfo/__init__.py:26: 
> > > UserWarning:
> > > I/O error(2): Datei oder Verzeichnis nicht gefunden
> > >   warnings.warn("I/O error({0}): {1}".format(e.errno, e.strerror))"
> > >
> > > Using: "matplotlib.dates import DateFormatter"
> >
> > indeed this is breaking matplotlib, thus the grave severity. it needs
> > to be addressed for bookworm
>
> How exactly does this break matplotlib?

it produces output on stderr, which many tools consider it an error
and fails build.

> dateutil.zoneinfo really shouldn't be used directly and I don't see any

can you back this quote please? zoneinfo is part of the public API,
and just breaking it (via the removal of the zonefile) and say not to
use it is going in the wrong direction.

> I guess we have two options if we want to change the current behavior:
> 1) Ship the outdated tzdata tarball even though nothing should really use it.
> 2) Add a patch to remove the dateutil.zoneinfo fallback.

i think you're missing

3) fix dateutil.zoneinfo to use a system-available zone info file

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#1031732: iortcw: CVE-2019-25104

[Moritz Muehlenhoff]

On Tue, Feb 21, 2023 at 03:32:01PM +, Simon McVittie wrote:
> On Tue, 21 Feb 2023 at 16:09:30 +0100, Moritz Mühlenhoff wrote:
> > CVE-2019-25104[0]:
> > https://github.com/rtcwcoop/rtcwcoop/pull/45
> 
> This looks like a denial of service via memory exhaustion when running
> a multiplayer server. For a game from 2001, I would personally say this
> is normal or even minor severity: it isn't really realistic to expect
> a game this old to not be crashable.
> 
> I'm also not at all sure that iortcw is even vulnerable to this.

Please adjust the severity (and or close if not applicable at all) as
necessary, I have no insight on iortcw but only saw the CVE in the triage
of the incoming CVE feed and filed this bug to clarify impact on Debian's
packaged fork.

Cheers,
Moritz

Bug#1031706: optuna: test_create_new_trial randomly fails on s390x

[Gard Spreemann]

"Rebecca N. Palmer"  writes:

> test_create_new_trial (both parts) sometimes fails on s390x, failing
> the autopkgtest.
>
> It might make sense to remove this package on s390x, if it isn't
> reasonable to actually fix this.

Thanks for the report! I've brought this to upstream's attention [1],
but I'm a bit confused as the upstream tests seem to make some
surprising assumptions about monotonicity of `datetime.now()` [2]. I'll
hold off on further investigation until I've figured out whether I've
just misunderstood something on their part.

In the worst case I'll disable autopkgtests – or this particular test –
on s390x.

[1] https://github.com/optuna/optuna/issues/4453

[2] https://github.com/optuna/optuna/issues/4455



 Best,
 Gard


signature.asc
Description: PGP signature

Bug#1026508: ca-certificates: FTBFS: TypeError: argument 'data': 'bytearray' object cannot be converted to 'PyBytes'

[Samuel Henrique]

Hello Julien,

> This is fixed in git, I need to get around to uploading an update.

Are you also planning to update the certificates for bookworm?

I'm asking as we are already in the freeze and there are a few
bugreports about old certificates that need to be dropped[0][1] (and I
assume there's also a bunch of new ones we need to get).

Are you looking into help maintaining the package as well?

[0] https://bugs.debian.org/1021749
[1] https://bugs.debian.org/1023945

Thank you,

-- 
Samuel Henrique 

Bug#1031744: httpdirfs: usage of ubsan might introduce vulnerabilities

[Adrian Bunk]

Package: httpdirfs
Version: 1.2.4-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Package: httpdirfs
Version: 1.2.4-2
Depends: ..., libubsan1 (>= 8), ...


This is a bad idea not only due to slower execution,
but might even introduce vulnerabilities:
https://www.openwall.com/lists/oss-security/2016/02/17/9

While there are safe usages of ubsan, httpdirfs being the
only package in the archive that uses ubsan but not asan
is something that sounds wrong and underreviewed.

Bug#1031743: python3.11-minimal: Python 3.11 should be compiled as a PIE, but it is not

[j.fikar]

Package: python3.11-minimal
Version: 3.11.1-2
Severity: normal
X-Debbugs-Cc: j.fi...@gmail.com

Dear Maintainer,

if I understood it correctly, the Python 3.10 and later should be compiled as
PIE (position independent executable). That is why there are the new packages
python3-nopie, python3.10-nopie, and 3.11-nopie.

But 3.11 is not a PIE. I checked arm64, amd64, armhf, armel, and i386
architectures.

$ file /usr/bin/python3.11
/usr/bin/python3.11: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-aarch64.so.1,
BuildID[sha1]=8dad83d75a00e6b5e26095c79dee978a8d57ef7d, for GNU/Linux 3.7.0,
stripped

The same is true for Sid version python3.11-minimal (3.11.2-4). The hardening-
check is reporting the same.

On the contrary, python3.10-minimal (3.10.9-1) is correctly a PIE

$ file /usr/bin/python3.10
/usr/bin/python3.10: ELF 64-bit LSB pie executable, ARM aarch64, version 1
(SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1,
BuildID[sha1]=7d2767e751dbd5c9287dbe5cd8de9022faa9d042, for GNU/Linux 3.7.0,
stripped


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

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

Versions of packages python3.11-minimal depends on:
ii  libc6  2.35-0ubuntu3.1
ii  libexpat1  2.4.7-1ubuntu0.2
pn  libpython3.11-minimal  
ii  zlib1g 1:1.2.11.dfsg-2ubuntu9.2

Versions of packages python3.11-minimal recommends:
pn  python3.11  

Versions of packages python3.11-minimal suggests:
ii  binfmt-support  2.2.1-2

Bug#826902: Blorbtools

[David Griffith]

I've since put these Perl scripts into a package called "Blorbtools".  See 
https://gitlab.com/DavidGriffith/blorbtools



--
David Griffith
d...@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Bug#1031742: Please make reboot command configurable

[Andras Korn]

Package: unattended-upgrades
Version: 2.9.1+nmu3
Severity: wishlist

Hi,

not all flavours of shutdown(8) support a time argument; for example, runit's 
only supports 'now' or no time.

When unattended-upgrades tries to schedule a reboot on runit systems, 
shutdown(8) prints an error, causing unattended-upgrades to become sad.

I'd like to provide my own mechanism for scheduling reboots (e.g. via at(1)). 
Please add a config tunable for this.

Thanks!

András

-- System Information:
Init: runit (via /run/runit.stopit)

-- 
 Keves, mint terdkalacsban a mazsola.

Bug#1031716: python3-protobuf: Do reverse dependencies need stricter version constraints?

[GCS]

On Tue, Feb 21, 2023 at 1:27 PM Adrian Bunk  wrote:
> Looking at #1028371, should generated dependencies on python3-protobuf be
>   python3-protobuf (>= 3.21), python3-protobuf (<< 3.22)
 You mean on python3-bernhard, right?

> to ensure that the binary package is used with the same version
> as the protobuf-compiler used during the build?
 Then what? It would become uninstallable when a new protobuf version
(3.22 next time) is uploaded and built.

> If yes, are other language bindings also affected by this problem?
 I still don't get your point. How does a language binding package
version relate to the protobuf-compiler version? I don't follow the
internals of Protobuf, but I would say it's more related to the
library soname and its provided API version.

Regards,
Laszlo/GCS

Bug#1031741: goxel: usage of sanitizers might introduce vulnerabilities

[Adrian Bunk]

Package: goxel
Version: 0.10.6-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Package: goxel
Version: 0.10.6-3
Depends: libasan6 (>= 10), ...,libubsan1 (>= 8)

This is a bad idea not only due to slow execution and a factor 20
in binary size, but might even introduce vulnerabilities:
https://www.openwall.com/lists/oss-security/2016/02/17/9

This was likely unintentional due to debug=0 no longer working,
which resulted in a debug build without compiler optimization
and with sanitizers enabled after
https://github.com/guillaumechereau/goxel/commit/44745ead64b63083ccb48e8c7988d080674d795d

Replacing debug=0 with mode=release in debian/rules makes not
using the debug mode working again.

It needs an additional werror=0 due to gcc finding more issues
during compilation when optimization is enabled.

As a side effect, fixing this bug should make the package build
on all architectures again (several architectures no longer built
due to the sanitizers being unavailable or broken).

Bug#1031509: [Pkg-clamav-devel] Bug#1031509: ETA on Patch for Buster

[Sebastian Andrzej Siewior]

+LTS

On 2023-02-20 12:22:48 [+0200], Andries Malan wrote:
> Hi There
Hi,

> Would you be so kind as to provide an ETA for the above mentioned bug that
> was reported.
> This would be greatly appreciated.

I Cced the LTS team because Buster is LTS territory.

> Regards

Sebastian

Bug#1030273:

[Alexander Beerhoff]

Hi, the problem seems solved with linux-image-6.1.0-5-amd64

-- 
Umi sukoschi
Niwa ni izumi no
Ko no ma ka na

Bug#1031740: fceux usage of sanitizers might introduce vulnerabilities

[Adrian Bunk]

Package: fceux
Version: 2.6.5+dfsg1-1
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

fceux (2.6.5+dfsg1-1) unstable; urgency=medium
...
  * enable compiler address sanitizer (ASAN)


Package: fceux
Version: 2.6.5+dfsg1-1
Depends: libasan8, ..., libubsan1 (>= 8),...


This is a bad idea not only due to slow execution and a factor 20
in binary size, but might even introduce vulnerabilities:
https://www.openwall.com/lists/oss-security/2016/02/17/9

Bug#1031697: Acknowledgement (libx11-xcb1: Please update to 1.8.4 - Apps crashing under wayland due to bugs caused by patches in 1.8.3)

[Safir Secerovic]

Hello again,

I forgot to mention that I did leave out:
--disable--thread-safety-constructor configure option from debian/rules
file
along with removing the two patches [1] when rebuilding from the current
debian source package (1.8.3).

Regards,
Safir

[1]
0003-Revert-Fix-797755-Allow-X-IfEvent-to-reenter-libX11.patch
0004-Revert-Allow-X-IfEvent-to-reenter-libX11.patch



On Mon, Feb 20, 2023 at 1:21 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

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

Bug#1031739: linux: Please enable DLM kernel module in cloud kernels

[Vincent Caron]

Package: linux
Severity: normal

Dear Maintainer,

I am in a situation where I am using a GFS2 cluster in virtual machines and
realized I couldn't do it with the 'cloud' kernel because the 'dlm'
kernel module is not present in this flavour. It does work when I switch
to the bare-metal kernel.

Other distributed fs might require 'dlm' (OCFS2 comes to mind). It's a
handy tool when you can mount the same NAS-like (Ceph, etc) on multiple
virtual machines and avoid SPOFy NFS configurations this way.

The diff between the bare-metal and cloud configs seem to be :

CONFIG_DLM=m
CONFIG_DLM_DEBUG=y
CONFIG_GFS2_FS_LOCKING_DLM=y

On an AMD64 Bullseye system, the /lib/modules part of the cloud kernel
weights 72584 kB and adding the dlm.ko modules seems it would add 480 kB
which is not negligible (+0.7%).


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

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

Bug#1031738: installation-guide: documentation about limits to kernel boot parameters is outdated

[James Addison]

Source: installation-guide
Version: 20220129~deb11u1
Severity: normal
Tags: d-i patch

Dear Maintainer,

Some of the documentation related to limits in Linux kernel boot parameters in
the installation guide is outdated.

For example, the section describing[1] use of boot parameters for preseeding
references the 2.6.9 kernel in a callout note.

Please find attached a patch to update two such documentation sections.

Thanks,
James

[1] - 
https://www.debian.org/releases/bullseye/amd64/apbs02.en.html#preseed-bootparms
>From 55dbd6dae622cfb40e3397bc98e4e053b14ad45c Mon Sep 17 00:00:00 2001
From: James Addison 
Date: Tue, 21 Feb 2023 18:07:01 +
Subject: [PATCH] linux-kernel: update notes related to command-line limits

---
 en/appendix/preseed.xml  | 9 +
 en/boot-installer/parameters.xml | 9 +
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/en/appendix/preseed.xml b/en/appendix/preseed.xml
index 0a4582149..1ed69b83b 100644
--- a/en/appendix/preseed.xml
+++ b/en/appendix/preseed.xml
@@ -367,10 +367,11 @@ out any options (like preconfiguration options) that it 
recognizes.
 
 
 
-Current linux kernels (2.6.9 and later) accept a maximum of 32 command line
-options and 32 environment options, including any options added by default
-for the installer. If these numbers are exceeded, the kernel will panic
-(crash). (For earlier kernels, these numbers were lower.)
+Debian-built Linux kernels accept up to the default maximum of 32 command line
+options and 32 environment options. If these numbers are exceeded, the kernel
+will fail to boot. Additionally, there is an architecture-dependent limit to
+the number of characters for the entire kernel command line; command-lines
+longer than this limit are silently truncated.
 
 
 
diff --git a/en/boot-installer/parameters.xml b/en/boot-installer/parameters.xml
index 91d981406..18f87dc25 100644
--- a/en/boot-installer/parameters.xml
+++ b/en/boot-installer/parameters.xml
@@ -75,10 +75,11 @@ The installation system recognizes a few additional boot 
parameters
 
 
 
-With current kernels (2.6.9 or newer) you can use 32 command line options and
-32 environment options. If these numbers are exceeded, the kernel will panic.
-Also there is a limit of 255 characters for the whole kernel command line,
-everything above this limit may be silently truncated.
+Debian-built Linux kernels accept up to the default maximum of 32 command line
+options and 32 environment options. If these numbers are exceeded, the kernel
+will fail to boot. Additionally, there is an architecture-dependent limit to
+the number of characters for the entire kernel command line; command-lines
+longer than this limit are silently truncated.
 
 
 
-- 
2.39.1

Bug#1030047: ruby-sanitize: CVE-2023-23627

[duck]

Quack Salvatore,

Thanks for the patch, it looks good.
I'm in the Ruby team but not involved in this particular package but I 
think we can let your NMU flow.

It's causing havoc on other packages so the sooner the better :-).

Regards.
\_o<

--
Marc Dequènes

Bug#1003044: python3-dateutil: python_dateutil get_zonefile_instance functionality is broken (no zoneinfo found)

[James Addison]

Package: python3-dateutil
Followup-For: Bug #1003044
Control: tags -1 moreinfo

On Tue, 21 Feb 2023 00:35:16 +, James Addison wrote:
> The repro step attempted was to open a Python interpreter session and to 
> enter:
>   from matplotlib.dates import DateFormatter
>
> (that succeeded and did not emit any output)

OK: that wasn't a hugely useful comment; a more thorough date formatting
example would have been more convincing.

...the 'date_index_formatter.py'[1] example code included in the 'matplotlib'
source is a better candidate: and it also completes successfully without errors
when run using version 2.8.2-1 of the python3-dateutil package.

Given that python3-dateutil is depended-upon by a reasonably large number of
other packages, I'm reluctant to reduce the severity of this bug, but at the
same time, it's unclear what the extent of the breakage is here.

[1] - 
https://sources.debian.org/src/matplotlib/3.6.3-1/examples/ticks/date_index_formatter.py/

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

> "Michael" == Michael Biebl  writes:

Michael> Am 21.02.23 um 17:45 schrieb Sam Hartman:
>>> "Michael" == Michael Biebl  writes:
Michael> Excluding packages that only ship overrides/drop-ins, this
Michael> makes 37 affected packages in bookworm.
>> 
>> If I'm understanding this issue correctly, the concern would be a
>> package that moved from /lib/systemd/system to
>> /usr/lib/systemd/system.

Michael> Well, not really. I'm concerned about packages shipping
Michael> files in /usr/lib/systemd/system and expecting that those
Michael> services are properly enabled/started/restarted/stopped.

I appreciate that is your concern.
However, it would be easier to work with you if you expressed empathy
and understanding for the other related concerns in the space.
My understanding is that the reason this is not a trivially accepted
patch is related to usrmerge and the issue I brought up.
Have I got that right?

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Michael Biebl]

Am 21.02.23 um 17:45 schrieb Sam Hartman:

"Michael" == Michael Biebl  writes:

 Michael> Excluding packages that only ship overrides/drop-ins, this
 Michael> makes 37 affected packages in bookworm.

If I'm understanding this issue correctly, the concern would be a
package that moved from /lib/systemd/system to /usr/lib/systemd/system.


Well, not really. I'm concerned about packages shipping files in 
/usr/lib/systemd/system and expecting that those services are properly 
enabled/started/restarted/stopped.






OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031737: Wrong margin character for changed text in man pages

[Bjarni Ingi Gislason]

Package: tcl8.6-doc
Version: 8.6.13+dfsg-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

  Displaying man page "chan.3tcl" with the next version (candidate) of
groff (1.23.0).

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

(test-nroff is in the git repository)

test-nroff -man -b -ww /tmp/chan.3tcl

   * What was the outcome of this action?

See later

   * What outcome did you expect instead?

  To see '|' at the right margin for changed text.



   The macro 'VS' contains the line

.ie n 'mc \s12\(br\s0

1) There is no type size change in nroff mode, so "\s12" does not change
the type size, that is, it stays unchanged.

2) The next version of "groff" (pending) interprets "\s12" as "\s1"
with an added text "2", which means, the digit "2" is printed instead
of "\(br" (same as '|').

  Example from "chan.3tcl":

deletes all existing file-events registered on the channel.  If  2

  and warnings (if the man option "--warnings=w" and environmental
variable "MAN_KEEP_STDERR=yes" are used):

troff: backtrace: '/tmp/chan.3tcl':150: macro 'VS'
troff: backtrace: file '/tmp/chan.3tcl':304
troff:/tmp/chan.3tcl:304: warning: expected numeric expression, got a
special character
troff: backtrace: '/tmp/chan.3tcl':150: macro 'VS'
troff: backtrace: file '/tmp/chan.3tcl':352
troff:/tmp/chan.3tcl:352: warning: expected numeric expression, got a
special character

###

  The fix is to drop the type size change and use

.ie n 'mc \(br

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

Kernel: Linux 6.1.7-1 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

tcl8.6-doc depends on no packages.

tcl8.6-doc recommends no packages.

Versions of packages tcl8.6-doc suggests:
ii  tcl8.6  8.6.13+dfsg-2

-- no debconf information

Bug#1031647: git-annex: Bogus build dependency whitelist results in FTBFS on m68k

[Sean Whitton]

Hello,

On Sun 19 Feb 2023 at 07:52PM +01, John Paul Adrian Glaubitz wrote:

> git-annex currently FTBFS on m68k with an error message that indicates that 
> some
> build dependencies are missing:
>
> Configuring git-annex-10.20230126...
> Setup: Encountered missing or private dependencies:
> clientsession,
> wai,
> wai-extra,
> warp >=3.2.8,
> warp-tls >=3.2.2,
> yesod >=1.4.3,
> yesod-core >=1.6.0,
> yesod-form >=1.4.8,
> yesod-static >=1.5.1
>
> Looking at debian/control, these build dependencies are for some reason only 
> enabled
> for a subset of architectures, namely those where the build dependency 
> doesn't arise

Joey, do you know why d/control restricts these build deps as it does?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031640: Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Theodore Ts'o]

On Tue, Feb 21, 2023 at 12:17:20PM +, Christopher Obbard wrote:
> Control: severity -1 important
> Control: retitle -1 e2fsprogs generates filesystems which cannot be
> mounted on systems with older e2fsprogs
> 
> It turns out for debos the situation is a bit different. Since debos
> uses packages on the host to prepare the partitions, new features in 
> e2fsprogs from unstable which are unsupported in the target suite
> causes the built system to not boot.
> 
> One such failure at boot-time of a Debian testing system is when
> systemd-fsck tries to check a filesystem, it fails to mount the device:
> 
>   /dev/mmcblk0p5 has unsupported feature(s): FEATURE_C12
> 
> So, in short we cannot run images built for suites with older e2fsprogs
> on a host system which has e2fsprogs >=1.47.0-1.
> 
> Fixing grub2 will not fix the issue for debos, so I have retitled the
> bug.
> 
> In debos with newer e2fsprogs, we can set the following flag on a
> partition to disable the feature which allows the system running older
> e2fsprogs to boot, but older e2fsprogs doesn't allow us to set this
> flag:
> 
>   features: [ "^orphan_file" ]
> 
> So to my mind, the bug is in e2fsprogs as it doesn't maintain backwards
> compatibility.

E2fsprogs is always going to be adding new features.  Even if I dumb
down /etc/mk2fs.conf to not enable this feature in Bookworm, it *will*
enable this new feature in the next release of Debian.  This is true
for all file systems; we add new features to improve user experience.

So packages that are creating file systems to be consumed by older
target OS's must either (a) be aware of these changes for all file
systems (for example XFS is enabling the "bigtime" feature by default
in Bookworm to fix y2038 bug by expanding the size of the timestamp in
their inodes), OR, (b) run the mke2fs from the target OS in build
chroot.

This might get tricky for some target OS's, such as for example, GNU
Hurd, but the Hurd *absolutely* needs to either use mkfs.ext4 from
Hurd, or if you are using the mke2fs from Linux, you'll need
"mkfs.ext2 -O hurd".

The assumption that mkfs's from file systems never change and provide
full backwards compatibility for all target OS's is very much an
anti-pattern.

Best regards,

- Ted

Bug#1031275: [PATCH v3 1/6] man2/: use IEC or ISO multiples to clarify long numeric digit strings

[Rob Landley]

On 2/20/23 09:35, Alex Colomar wrote:
> On 2/20/23 15:29, Stefan Puiu wrote:
>> Hi Alex,
> 
> Hi Stefan,
> 
>>> 4 KiB is not that much better than 4096, since 4096 is easy to read.
>>> For higher numbers such as 33554432, it becomes more important to use 32 
>>> KiB.
>>> For consistency, using 4 KiB seems reasonable.
>> 
>> How about using KiB / MiB over a certain number of digits? It seems
>> excessive to use them everywhere.
> 
> We might do that.  So far, I prefer having the patches change 
> everything, and then we can later discuss about discarding part of them.

If you're going to tell people to learn something new: 1<<10 is a kilobyte,
1<<20 is a megabyte, 1<<30 is a gigabyte, and so on. I've sometimes used
16*(1<<30) for clarity.

>> Also, for the record, I had no idea what KiB / MiB means and how it's
>> different from KB/MB until this discussion.

Very few people do. Some people have been trying to make "fetch" happen for many
years, but it didn't. (Part of the reason is kibybyte/mebibyte/gibibyte are
minor tongue twisters, they're physically harder to say, so nobody does.)

>> I googled it before
>> writing this reply, and found this among the first hits:
>> https://ux.stackexchange.com/a/13850.
> 
> That answer was written more than a decade ago.  These days, binary 
> prefixes are more common.  In fact, I'd say most GNU/Linux commands

"First off, I'd suggest printing out a copy of the GNU coding standards,
and NOT read it.  Burn them, it's a great symbolic gesture." - Linus Torvalds

(Still there in Documentation/process/coding-style.rst.)

GNU has nothing to do with Linux, and never did. Stallman has a history of
taking credit for other people's work:

https://functional.cafe/@tfb/109897415359142549

> respect them (an important exception being GNU coreutils (for example 
> ls(1)).  But many programs use prefixes accurately, such as fdisk(8).
> 
> In the Linux man-pages we have units(7), which documents these.  Maybe 
> that page should be more known.

FYI Michael Kerrisk last updated https://github.com/mkerrisk in 2021. It is now
2023. He still posts monthly proof-of-life to
https://twitter.com/mkerrisk/with_replies but hasn't replied to man-pages email
in the past year that I am aware of?

Dunno why. I emailed to ask, but...

> BTW, that answer is inaccurate (at least today): drive manufacturers 
> have the distinction pretty clear, and use it precisely (with lawsuits 
> won thanks to this); they use metric prefixes, because they mean it. 
> They can sell you 1 TB instead of 1 TiB, and most people won't even 
> know, but those who know, will know that 1 TB is 1'000'000'000'000 B, 
> which is what you get.

Remember when the dictionaries gave in on "literally" meaning "an emphatic form
of figuratively"? What's the "kibybyte" equivalent we all switched to there for
clarity?

We say "metric ton" and "imperial ton". We say "degrees farenheit" and "degrees
celsius". The celsius people didn't come up with a different word for degree,
yet somehow we all survived...

> They have no incentives to sell 1 TiB drives, 
> because they are visually almost the same, but there's around 9.95% more 
> bytes, so it's more expensive to produce.  It's not worth it for them.

"No, a _bud_ lite..."

>> I would say making the docs easy to understand for users is more
>> important than adhering to some specs users might not be familiar
>> with.
> 
> Well, using MiB prompts readers to use their search engine to learn what 
> that is (that's how I learnt it the first time; and that's what one does 
> when reading a book and finding a new word).

"They'll google it" is the modern version of "they'll read the documentation".
They will not, you're just delegating blame.

Rob

P.S. Maybe this is a generational thing? Are the kids saying "kibibyte" in high
school these days? I know that "hacker means computer breakin specialist" is
something a small number of boomers will resist to the death despite a google
news search only pulling up one meaning in general usage. And the "two spaces
after period" thing old hands cling to will only end when they die despite the
chicago manual of style, the AP stylebook, the MLA handbook, and the APA
publication manual all agreeing its' been one space after a period for decades
now. But maybe "kibibyte" is more than a shibboleth to somebody somewhere...

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Sam Hartman]

> "Michael" == Michael Biebl  writes:
Michael> Excluding packages that only ship overrides/drop-ins, this
Michael> makes 37 affected packages in bookworm.

If I'm understanding this issue correctly, the concern would be a
package that moved from /lib/systemd/system to /usr/lib/systemd/system.
Under the TC resolution, that should not be happening for bookworm.

At least some of those packages are new services that have never been in
/lib/systemd/system.  I believe for example pam is in that set.

That's presumably not going to break something in the way that a file
moving between /lib and /usr/lib is.
But we don't want to encourage that movement.

It seems like knowing how many incorrect moves we've had would also be
valuable--how many things that used to be in /lib/systemd but are now
appearing in /usr/lib.

Bug#1031718: Same problem with BTS server

[Debian]

Maybe this error can be tracked within the Debian BTS email server?
(There should be one more reply from the system for this email that will 
fail.)


There could be found other suspect log entries in the exim log:

2023-02-21 13:39:03 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:04 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:04 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
No supported cipher suites have been found.
2023-02-21 13:39:05 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:06 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:06 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:06 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:07 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.
2023-02-21 13:39:07 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
No supported cipher suites have been found.
2023-02-21 13:39:08 TLS error on connection from 
scanner-25.ch1.censys-scanner.com [162.142.125.221] (gnutls_handshake): 
Error in the pull function.



=

email at ow...@bugs.debian.org

=


Hello Debian BTS administrators,

can you please check the log files of the mail system for a missing email?
It shoud have been send at 21 Feb 2023 13:45:01 UTC


It is regarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031718
Normally I get emails from the BTS engine without any problem.
As you can see the email for submit was received and processed by the 
system.


The log for this submit mail is:

2023-02-21 14:41:44 1pUSXU-002AnH-Kx => sub...@bugs.debian.org 
R=dnslookup T=remote_smtp H=buxtehude.debian.org [209.87.16.39] 
X=TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256 CV=no 
DN="C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP 
CA,CN=buxtehude.debian.org,EMAIL=hostmas...@buxtehude.debian.org" K 
C="250- 7971 byte chunk, total 7971\\n250 OK id=1pUSts-00Ad0p-7V"

2023-02-21 14:41:44 1pUSXU-002AnH-Kx Completed

The exact error why the mail response fails would help to solve the bug 
1031718.



Thank you for your help and support

karsten

Bug#1031712: libnet-server-perl: Use of uninitialized value in numeric eq (==) at /usr/share/perl5/Net/Server/Fork.pm line 168.

[gregor herrmann]

Control: forwarded -1 https://rt.cpan.org/Public/Bug/Display.html?id=146575
Control: tag -1 + upstream patch

On Tue, 21 Feb 2023 07:54:07 +0100, Dominique Fournier via pkg-perl-maintainers 
wrote:

> 
> Each time there is a connection in Munin (using the lib-netserver-perl 
> package as tcp server),
> a log is generated :
> munin-node: Use of uninitialized value in numeric eq (==) at 
> /usr/share/perl5/Net/Server/Fork.pm line 168.
> 
> This appears in version 2.013-1 and don't exists in version 2.009-2 of the 
> package.
> 
> Could you patch the library to remove this not needed log ?

Thanks.

This is
https://rt.cpan.org/Public/Bug/Display.html?id=146575
and
https://github.com/rhandom/perl-net-server/issues/32
with a PR at
https://github.com/rhandom/perl-net-server/pull/33

Will try to get a patch into Debian soon.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1021842: Finalizing 'inhibit-automatic-native-compilation'

[Andrea Corallo]

Tatsuya Kinoshita  writes:

> On 2023-02-20 at 20:22 +, Andrea Corallo wrote:
>> I've installed 5d0b45cd67b on emacs-29 in order to use always
>> `make-temp-file'.
>
> Please be careful with the difference between make-temp-file-internal
> and make-temp-file.
>
>> +++ b/lisp/emacs-lisp/comp.el
>>  (expand-file-name
>> - (make-temp-file-internal (file-name-sans-extension 
>> rel-filename)
>> -  0 ".eln" nil)
>> + (make-temp-file (file-name-sans-extension rel-filename) 0 
>> ".eln"
>> + nil)
>>   temporary-file-directory
>
> This second argument of make-temp-file should be nil, and expanding
> against temporary-file-directory is already done by make-temp-file.
>
> Thanks,

Hi Tatsuya,

thanks for checking, 68df9e5953c fix that.

Bests

  Andrea

Bug#1031732: iortcw: CVE-2019-25104

[Simon McVittie]

On Tue, 21 Feb 2023 at 16:09:30 +0100, Moritz Mühlenhoff wrote:
> CVE-2019-25104[0]:
> https://github.com/rtcwcoop/rtcwcoop/pull/45

This looks like a denial of service via memory exhaustion when running
a multiplayer server. For a game from 2001, I would personally say this
is normal or even minor severity: it isn't really realistic to expect
a game this old to not be crashable.

I'm also not at all sure that iortcw is even vulnerable to this.

For historical reasons iortcw is actually two separate game engines with
similar but divergent content: SP/ is a single-player game with
computer-controlled enemies and no real security implications, while
MP/ is a team-based competitive multiplayer game with only human players.

rtcwcoop appears to be a fork of iortcw which combines the SP and MP
codebases, so that gamers can play the original game's single-player story
as a cooperative multiplayer game where they fight computer-controlled
enemies.

This denial of service seems to be in code to load AI scripts for
computer-controlled enemies or allies, which can happen in rtcwcoop
or in iortcw SP/; but iortcw MP/ doesn't have any computer-controlled
characters as far as I know, so it might well be impossible for the
resource exhaustion to actually happen in practice?

smcv

Bug#1031352: Chromium on Wayland: Cannot join a Microsoft Teams enterprise meeting

[Amr Ibrahim]

Package: chromium
Version: 110.0.5481.77-2
Followup-For: Bug #1031352

Hallo,

Bug still exists in version 110.0.5481.77-2

Best,
Amr


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

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
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 chromium depends on:
ii  chromium-common110.0.5481.77-2
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libbrotli1 1.0.9-2+b6
ii  libc6  2.36-8
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-1+b2
ii  libdbus-1-31.14.6-1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1
ii  libevent-2.1-7 2.1.12-stable-5+b1
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-4
ii  libgbm122.3.3-1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.5-1
ii  libgtk-3-0 3.24.36-3
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-1+b1
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenjp2-7   2.5.0-1+b1
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libre2-9   20220601+dfsg-1+b1
ii  libsnappy1v5   1.1.9-2
ii  libstdc++6 12.2.0-14
ii  libwebp7   1.2.4-0.1
ii  libwebpdemux2  1.2.4-0.1
ii  libwebpmux31.2.4-0.1
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.3-3
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.1+b3
ii  libxnvctrl0525.85.05-1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  xdg-desktop-portal-gnome [xdg-desktop-portal-backend]  43.1-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]1.14.1-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  110.0.5481.77-2

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n110.0.5481.77-2
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6  2.36-8
ii  libdouble-conversion3  3.2.1-1
ii  libjsoncpp25   1.9.5-4
ii  libstdc++6 12.2.0-14
ii  libx11-6   2:1.8.3-3
ii  libxnvctrl0525.85.05-1
ii  x11-utils  7.7+5
ii  xdg-utils  1.1.3-4.1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium-common recommends:
ii  

Bug#1031735: oggvideotools: autopkgtest relies on an obsolet location for file Effet_force_magnetique.ogv

[Georges Khaznadar]

Package: oggvideotools
Version: 0.9.1-6
Severity: normal

Dear Maintainer,

I am the author and maintainer of package pymecavideo, which yields the
binary package python3-mecavideo.

The new version (>> 8.0~rc4) will have the file "Effet_force_magnetique.ogv"
in a new location: /usr/share/pymecavideo/data/video/Effet_force_magnetique.ogv

As this file is not accessible from the path
/usr/share/python3-mecavideo/video/Effet_force_magnetique.ogv which is used for
autopkgtests, the test fails, so the version 8.0~rc4  of package pymecavideo
introduces a regression.

To fix it, I shall upload a version 8.0~rc5 which creates a symlink from
/usr/share/python3-mecavideo/video to ../pymecavideo/data/video

But this is "quick and dirty" as a job.

Please can you modify your test script, to use instead, the definitive
location,
/usr/share/pymecavideo/data/video/Effet_force_magnetique.ogv ?

Best regards, Georges.


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

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

Versions of packages oggvideotools depends on:
ii  libc6  2.36-8
ii  libgcc-s1  12.2.0-14
ii  libgd3 2.3.3-7+b1
ii  libstdc++6 12.2.0-14
ii  libtheora0 1.1.1+dfsg.1-16.1
ii  libvorbis0a1.3.7-1
ii  libvorbisenc2  1.3.7-1

oggvideotools recommends no packages.

oggvideotools suggests no packages.

-- no debconf information

Bug#1031734: ibus-braille-preferences crashes when run

[T. Joseph Carter]

Package: ibus-braille
Version: 0.3-7
Severity: important

Upon running ibus-braille-preferences, I get this error:

```
aki:~ $ ibus-braille-preferences 
/usr/share/ibus-braille-preferences/main.py:24: PyGIWarning: Gtk was imported 
without specifying a version first. Use gi.require_version('Gtk', '4.0') before 
import to ensure that the right version gets loaded.
  from gi.repository import Gtk
/usr/share/ibus-braille-preferences/main.py:26: PyGIWarning: IBus was imported 
without specifying a version first. Use gi.require_version('IBus', '1.0') 
before import to ensure that the right version gets loaded.
  from gi.repository import IBus
Traceback (most recent call last):
  File "/usr/share/ibus-braille-preferences/main.py", line 265, in 
ibus_sharada_braille_preferences()
  File "/usr/share/ibus-braille-preferences/main.py", line 36, in __init__

self.guibuilder.add_from_file("/usr/share/ibus-braille-preferences/ui.glade")
gi.repository.GLib.GError: gtk-builder-error-quark: 
/usr/share/ibus-braille-preferences/ui.glade:75:52 Invalid property: 
GtkBox.border_width (11)
```

I suspect PyGIWarning is the clue: This probably requires GTK+ 3.x, not
4.x, but it doesn't specify what it needs. Seems line 26 is also going
to cause a potential problem. I suspect judicious use of the following
three lines added to a couple source files will fix it:

```python
from gi import require_version
require_version('Gtk', '3.0')
require_version('IBus', '1.0')
```

At least, that was all it took to get the preferences applet to run.
Didn't test the abbreviation or language editor with similar patches.

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

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

Versions of packages ibus-braille depends on:
ii  gir1.2-ibus-1.0   1.5.27-4
ii  gir1.2-pango-1.0  1.50.12+ds-1
ii  python3   3.11.1-3
ii  python3-espeak0.5-5+b1
ii  python3-gi3.42.2-3+b1
ii  python3-louis 3.24.0-1

Versions of packages ibus-braille recommends:
ii  python3-speechd  0.11.4-2

ibus-braille suggests no packages.

-- no debconf information

Bug#1031733: libcommons-fileupload-java: CVE-2023-24998

[Moritz Mühlenhoff]

Source: libcommons-fileupload-java
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libcommons-fileupload-java.

CVE-2023-24998[0]:
| Apache Commons FileUpload before 1.5 does not limit the number of
| request parts to be processed resulting in the possibility of an
| attacker triggering a DoS with a malicious upload or series of
| uploads.

https://lists.apache.org/thread/4xl4l09mhwg4vgsk7dxqogcjrobrrdoy
https://github.com/apache/commons-fileupload/commit/e20c04990f7420ca917e96a84cec58b13a1b3d17


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-2023-24998
https://www.cve.org/CVERecord?id=CVE-2023-24998

Please adjust the affected versions in the BTS as needed.

Bug#1031732: iortcw: CVE-2019-25104

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for rtcwcoop, which seems
to be a fork of iortcw, but the patches don't seem to have flown back?

CVE-2019-25104[0]:
| A vulnerability has been found in rtcwcoop 1.0.2 and classified as
| problematic. Affected by this vulnerability is the function
| AICast_ScriptLoad of the file code/game/ai_cast_script.c of the
| component Team Command Handler. The manipulation leads to denial of
| service. The name of the patch is
| f2cd18bc2e1cbca8c4b78bee9c392272bd5f42ac. It is recommended to apply a
| patch to fix this issue. The identifier VDB-221485 was assigned to
| this vulnerability.

https://github.com/rtcwcoop/rtcwcoop/pull/45


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

For further information see:

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

Please adjust the affected versions in the BTS as needed.

Bug#1031731: glusterfs: CVE-2023-26253

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for glusterfs.

CVE-2023-26253[0]:
| In Gluster GlusterFS 11.0, there is an xlators/mount/fuse/src/fuse-
| bridge.c notify stack-based buffer over-read.

https://github.com/gluster/glusterfs/issues/3954


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-2023-26253
https://www.cve.org/CVERecord?id=CVE-2023-26253

Please adjust the affected versions in the BTS as needed.

Bug#1031729: resteasy3.0: CVE-2023-0482

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for resteasy3.0.

CVE-2023-0482[0]:
| In RESTEasy the insecure File.createTempFile() is used in the
| DataSourceProvider, FileProvider and Mime4JWorkaround classes which
| creates temp files with insecure permissions that could be read by a
| local user.

https://github.com/resteasy/resteasy/pull/3409/
https://github.com/resteasy/resteasy/commit/3d8a551d80b98f185edaff6f895188ec8211366b


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-2023-0482
https://www.cve.org/CVERecord?id=CVE-2023-0482

Please adjust the affected versions in the BTS as needed.

Bug#1031730: emacs: CVE-2022-48339 CVE-2022-48338 CVE-2022-48337

[Moritz Mühlenhoff]

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

Hi,

The following vulnerabilities were published for emacs.

CVE-2022-48339[0]:
| An issue was discovered in GNU Emacs through 28.2. htmlfontify.el has
| a command injection vulnerability. In the hfy-istext-command function,
| the parameter file and parameter srcdir come from external input, and
| parameters are not escaped. If a file name or directory name contains
| shell metacharacters, code may be executed.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=1b4dc4691c1f87fc970fbe568b43869a15ad0d4c

CVE-2022-48338[1]:
| An issue was discovered in GNU Emacs through 28.2. In ruby-mode.el,
| the ruby-find-library-file function has a local command injection
| vulnerability. The ruby-find-library-file function is an interactive
| function, and bound to C-c C-f. Inside the function, the external
| command gem is called through shell-command-to-string, but the
| feature-name parameters are not escaped. Thus, malicious Ruby source
| files may cause commands to be executed.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9a3b08061feea14d6f37685ca1ab8801758bfd1c

CVE-2022-48337[2]:
| GNU Emacs through 28.2 allows attackers to execute commands via shell
| metacharacters in the name of a source-code file, because lib-
| src/etags.c uses the system C library function in its implementation
| of the etags program. For example, a victim may use the "etags -u *"
| command (suggested in the etags documentation) in a situation where
| the current working directory has contents that depend on untrusted
| input.

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=01a4035c869b91c153af9a9132c87adb7669ea1c


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-48339
https://www.cve.org/CVERecord?id=CVE-2022-48339
[1] https://security-tracker.debian.org/tracker/CVE-2022-48338
https://www.cve.org/CVERecord?id=CVE-2022-48338
[2] https://security-tracker.debian.org/tracker/CVE-2022-48337
https://www.cve.org/CVERecord?id=CVE-2022-48337

Please adjust the affected versions in the BTS as needed.

Bug#1031728: resteasy: CVE-2023-0482

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for resteasy.

CVE-2023-0482[0]:
| In RESTEasy the insecure File.createTempFile() is used in the
| DataSourceProvider, FileProvider and Mime4JWorkaround classes which
| creates temp files with insecure permissions that could be read by a
| local user.

https://github.com/resteasy/resteasy/pull/3409/
https://github.com/resteasy/resteasy/commit/3d8a551d80b98f185edaff6f895188ec8211366b


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-2023-0482
https://www.cve.org/CVERecord?id=CVE-2023-0482

Please adjust the affected versions in the BTS as needed.

Bug#1031727: epiphany-browser: CVE-2023-26081

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for epiphany-browser.

CVE-2023-26081[0]:
| In Epiphany (aka GNOME Web) through 43.0, untrusted web content can
| trick users into exfiltrating passwords, because autofill occurs in
| sandboxed contexts.

https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/1275
https://gitlab.gnome.org/GNOME/epiphany/-/commit/53363c3c8178bf9193dad9fa3516f4e10cff0ffd


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-2023-26081
https://www.cve.org/CVERecord?id=CVE-2023-26081

Please adjust the affected versions in the BTS as needed.

Bug#1031726: hdf5: CVE-2022-26061 CVE-2022-25972 CVE-2022-25942

[Moritz Mühlenhoff]

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

Hi,

The following vulnerabilities were published for hdf5. The reports
mentioned a vendor disclosure, but not sure when/how.

CVE-2022-26061[0]:
| A heap-based buffer overflow vulnerability exists in the gif2h5
| functionality of HDF5 Group libhdf5 1.10.4. A specially-crafted GIF
| file can lead to code execution. An attacker can provide a malicious
| file to trigger this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2022-1487

CVE-2022-25972[1]:
| An out-of-bounds write vulnerability exists in the gif2h5
| functionality of HDF5 Group libhdf5 1.10.4. A specially-crafted GIF
| file can lead to code execution. An attacker can provide a malicious
| file to trigger this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2022-1485

CVE-2022-25942[2]:
| An out-of-bounds read vulnerability exists in the gif2h5 functionality
| of HDF5 Group libhdf5 1.10.4. A specially-crafted GIF file can lead to
| code execution. An attacker can provide a malicious file to trigger
| this vulnerability.

https://talosintelligence.com/vulnerability_reports/TALOS-2022-1486

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-26061
https://www.cve.org/CVERecord?id=CVE-2022-26061
[1] https://security-tracker.debian.org/tracker/CVE-2022-25972
https://www.cve.org/CVERecord?id=CVE-2022-25972
[2] https://security-tracker.debian.org/tracker/CVE-2022-25942
https://www.cve.org/CVERecord?id=CVE-2022-25942

Please adjust the affected versions in the BTS as needed.

Bug#1031725: unblock: accountsservice/22.08.8-6

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: accountsserv...@packages.debian.org
Control: affects -1 + src:accountsservice

accountsservice could benefit from some appropriate age-days to get it
into testing a bit sooner. It's currently at 3 of 10 days.

(Do you want requests like this for important/RC bug fixes during soft
freeze in general, or should maintainers prefer to wait 10 days and hope
that manual intervention isn't needed?)

[ Reason ]
Fixes a regression introduced while fixing previous RC bugs.

[ Impact ]
If not accepted, accounts-daemon crashes with an assertion failure on
systems where /etc/shadow doesn't exist (pwunconv or shadowconfig off),
which is inadvisable but at least partially supported. This leads to
gdm and probably other login managers not starting, preventing login.
(#1031309)

This is a regression caused by my previous fix for #1030262, which is
already in testing. At the time of fixing #1030262 it hadn't occurred
to me that a missing /etc/shadow was something that could happen on a
supportable system.

[ Tests ]
The scenario with the crash was manually tested in a bookworm GNOME VM. It
seemed too rare and weird to add an automated test, but the automated test
added while fixing #1030262 and #1030253 still passes in this version.

[ Risks ]
The service is high-visibility and security-sensitive, but the change
is straightforward (allowing a hash table to be NULL) and was already
accepted upstream.

[ 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 testing

unblock accountsservice/22.08.8-6
diffstat for accountsservice-22.08.8 accountsservice-22.08.8

 debian/changelog   |   10 ++
 debian/patches/0005-gdm_config_file_path.patch |7 -
 debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch |1 
 debian/patches/daemon-Don-t-crash-if-etc-shadow-doesn-t-exist.patch|   41 ++
 debian/patches/series  |1 
 debian/patches/tests-fix-invocation-of-AddUser.patch   |2 
 debian/patches/tests-fix-the-signature-for-the-SetLocked-call.patch|2 
 debian/patches/user-Use-correct-format-strings-to-print-accounts_user_ge.patch |1 
 src/daemon.c   |5 -
 9 files changed, 61 insertions(+), 9 deletions(-)

diff -Nru accountsservice-22.08.8/debian/changelog accountsservice-22.08.8/debian/changelog
--- accountsservice-22.08.8/debian/changelog	2023-02-07 13:46:10.0 +
+++ accountsservice-22.08.8/debian/changelog	2023-02-18 09:22:31.0 +
@@ -1,3 +1,13 @@
+accountsservice (22.08.8-6) unstable; urgency=medium
+
+  * Team upload
+  * d/p/daemon-Don-t-crash-if-etc-shadow-doesn-t-exist.patch:
+Add patch to prevent a crash if /etc/shadow is missing or empty
+(Closes: #1031309)
+  * d/patches: Mark most patches as having been applied upstream
+
+ -- Simon McVittie   Sat, 18 Feb 2023 09:22:31 +
+
 accountsservice (22.08.8-5) unstable; urgency=medium
 
   * Team upload
diff -Nru accountsservice-22.08.8/debian/patches/0005-gdm_config_file_path.patch accountsservice-22.08.8/debian/patches/0005-gdm_config_file_path.patch
--- accountsservice-22.08.8/debian/patches/0005-gdm_config_file_path.patch	2023-02-07 13:46:10.0 +
+++ accountsservice-22.08.8/debian/patches/0005-gdm_config_file_path.patch	2023-02-18 09:22:31.0 +
@@ -1,11 +1,10 @@
 From: Josselin Mouette 
 Date: Sat, 12 Oct 2019 10:29:08 +0200
-Subject: Fix path to the GDM configuration file, which is different
+Subject: Fix path to the GDM configuration file
 
-Bug-Debian: http://bugs.debian.org/627311
-Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49993
+It's different in Debian.
 
-in Debian.
+Bug-Debian: http://bugs.debian.org/627311
 Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49993
 ---
  src/daemon.c | 2 +-
diff -Nru accountsservice-22.08.8/debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch accountsservice-22.08.8/debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch
--- accountsservice-22.08.8/debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch	2023-02-07 13:46:10.0 +
+++ accountsservice-22.08.8/debian/patches/Annotate-varargs-functions-with-G_GNUC_PRINTF.patch	2023-02-18 09:22:31.0 +
@@ -8,6 +8,7 @@
 Bug: https://gitlab.freedesktop.org/accountsservice/accountsservice/-/issues/109
 Signed-off-by: Simon McVittie 
 Forwarded: https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/120
+Applied-upstream: 23.0, commit:c142812f7653cd1f6e52224da8410cd09f102a4f
 ---
  src/daemon.c | 5 +
  src/user.c   | 5 +

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Michael Biebl]

For bookworm we have

$ apt-file search -x ^/usr/lib/systemd/system/
amazon-ec2-net-utils: /usr/lib/systemd/system/policy-routes@.service
amazon-ec2-net-utils: /usr/lib/systemd/system/refresh-policy-routes@.service
amazon-ec2-net-utils: /usr/lib/systemd/system/refresh-policy-routes@.timer
arno-iptables-firewall: 
/usr/lib/systemd/system/arno-iptables-firewall.service

boinc-client: /usr/lib/systemd/system/boinc-client.service
booth: /usr/lib/systemd/system/booth-arbitrator.service
caddy: /usr/lib/systemd/system/caddy-api.service
caddy: /usr/lib/systemd/system/caddy.service
ceph-iscsi: /usr/lib/systemd/system/rbd-target-api.service
ceph-iscsi: /usr/lib/systemd/system/rbd-target-gw.service
cfengine3: /usr/lib/systemd/system/cf-apache.service
cfengine3: /usr/lib/systemd/system/cf-execd.service
cfengine3: /usr/lib/systemd/system/cf-hub.service
cfengine3: /usr/lib/systemd/system/cf-monitord.service
cfengine3: /usr/lib/systemd/system/cf-postgres.service
cfengine3: /usr/lib/systemd/system/cf-reactor.service
cfengine3: /usr/lib/systemd/system/cf-runalerts.service
cfengine3: /usr/lib/systemd/system/cf-serverd.service
cfengine3: /usr/lib/systemd/system/cfengine3.service
cloudflare-ddns: /usr/lib/systemd/system/cloudflare-ddns.service
cloudflare-ddns: /usr/lib/systemd/system/cloudflare-ddns.timer
debomatic: /usr/lib/systemd/system/debomatic.service
drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
fail2ban: /usr/lib/systemd/system/fail2ban.service
fapolicyd: /usr/lib/systemd/system/fapolicyd.service
freedombox: /usr/lib/systemd/system/avahi-daemon.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/bind9.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/calibre-server-freedombox.service
freedombox: /usr/lib/systemd/system/coturn.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/deluged.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/freedombox-manual-upgrade.service
freedombox: /usr/lib/systemd/system/janus.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/matrix-synapse.service.d/freedombox.conf
freedombox: 
/usr/lib/systemd/system/mediawiki-jobrunner.service.d/freedombox.conf

freedombox: /usr/lib/systemd/system/nmbd.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/plinth.service
freedombox: /usr/lib/systemd/system/quasselcore.service.d/freedombox.conf
freedombox: 
/usr/lib/systemd/system/shadowsocks-libev-local@.service.d/freedombox.conf

freedombox: /usr/lib/systemd/system/smbd.service.d/freedombox.conf
freedombox: 
/usr/lib/systemd/system/syncthing@syncthing.service.d/freedombox.conf
freedombox: 
/usr/lib/systemd/system/transmission-daemon.service.d/freedombox.conf

freedombox: /usr/lib/systemd/system/tt-rss.service.d/freedombox.conf
freedombox: /usr/lib/systemd/system/wordpress-freedombox.service
freedombox: /usr/lib/systemd/system/wordpress-freedombox.timer
freedombox: /usr/lib/systemd/system/zramswap.service.d/freedombox.conf
fwknop-apparmor-profile: /usr/lib/systemd/system/usr.sbin.fwknopd
gammu-smsd: /usr/lib/systemd/system/gammu-smsd.service
libpam-modules-bin: /usr/lib/systemd/system/pam_namespace.service
mpd: /usr/lib/systemd/system/mpd.service
mpd: /usr/lib/systemd/system/mpd.socket
mpdscribble: /usr/lib/systemd/system/mpdscribble.service
nordugrid-arc-arex: /usr/lib/systemd/system/arc-arex-ws.service
nordugrid-arc-arex: /usr/lib/systemd/system/arc-arex.service
nordugrid-arc-datadelivery-service: 
/usr/lib/systemd/system/arc-datadelivery-service.service

nordugrid-arc-gridftpd: /usr/lib/systemd/system/arc-gridftpd.service
nordugrid-arc-hed: /usr/lib/systemd/system/arched.service
nordugrid-arc-infosys-ldap: 
/usr/lib/systemd/system/arc-infosys-ldap-slapd.service

nordugrid-arc-infosys-ldap: /usr/lib/systemd/system/arc-infosys-ldap.service
nvme-cli: /usr/lib/systemd/system/nvmefc-boot-connections.service
nvme-cli: /usr/lib/systemd/system/nvmf-autoconnect.service
nvme-cli: /usr/lib/systemd/system/nvmf-connect.target
nvme-cli: /usr/lib/systemd/system/nvmf-connect@.service
pass-extension-tomb: /usr/lib/systemd/system/pass-close@.service
pcscd: /usr/lib/systemd/system/pcscd.service
pcscd: /usr/lib/systemd/system/pcscd.socket
phog: /usr/lib/systemd/system/greetd.service.d/phog.conf
powerman: /usr/lib/systemd/system/powerman.service
pvpgn: /usr/lib/systemd/system/pvpgn.service
python3-charon: /usr/lib/systemd/system/charon.service
qbittorrent-nox: /usr/lib/systemd/system/qbittorrent-nox@.service
shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-local@.service
shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-redir@.service
shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-server@.service
shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-tunnel@.service
systemd-oomd: 
/usr/lib/systemd/system/-.slice.d/10-oomd-root-slice-defaults.conf
systemd-oomd: 
/usr/lib/systemd/system/user@.service.d/10-oomd-user-service-defaults.conf

tcmu-runner: 

Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Michael Biebl]

Hi Niels

On Tue, 21 Feb 2023 10:47:09 +0100 Niels Thykier  wrote:

Sorry for being terse, I should be working on something else right now 
but prioritized a short message over nothing.


Duplicate of #995569.


Sorry, missed that...

 My concerns from back then still applies and I
will not implement this feature until they are resolved. For the record, 
I do not feel the tech-ctte's resolution back then answered my question.


Additionally, we are in the bookworm freeze where toolchains are frozen 
and have been for a month now. I am also not going to implement this 
change for bookwork unless there is an agreement from the release team 
in place that this is the direction we want to go (I do not have time to 
look at that discussion right now either).


Looping in the release team.

Quoting Helmut from IRC:

helmut
'I am indeed wondering whether the ctte's acceptance of "usr-is-merged 
is pulled by init-system-helpers" would be sufficient to address 
nthykier's concerns. That's new compared to his earlier rejection.'



I'm currently evaluating what the best course of action is here.

The patch for dh_installsystemd would be quite simple and then we'd 
mostly need a couple of binNMUs. In Trixie we will need that anyway and 
I assume for backports it would be beneficial as well.

This all speaks in favor of changing dh_installsystemd.

The alternative is to basically have 35 RC bugs against affected 
packages and fixing those individually by moving the files to /lib


Dear release team, could you please have a look at 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031695 and share your 
opinion on how to proceed here.


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1029720: [Pkg-nagios-devel] Bug#1029720: Bug#1029720: monitoring-plugins-contrib: false positive w bookworm kernel: "running kernel does not match on-disk kernel image'

[Jan Wagner]

Thanks for all your input.

As the release is coming closer and I'm very short on time at the moment 
patches are very appreciated.


Thanks Jan

Bug#1031724: fava: frontend is not built from source; missing source

[Bastian Germann]

Source: fava
Version: 1.18-1
Severity: serious

The package's frontend node package is not built from source.
It cannot be built from source as the svelte framework seems to be missing from 
Debian.
Additionally, some of the node packages' dependencies (see frontend/package.json) are included in the orig tarball but 
not represented in the package source. This is a Policy violation. Please at least include the missing source.

Bug#1031723: ITP: obs-command-source -- plugin for OBS Studio providing a dummy source to execute commands

[Joao Eriberto Mota Filho]

Package: wnpp
Severity: wishlist
Owner: Joao Eriberto Mota Filho 
X-Debbugs-Cc: debian-de...@lists.debian.org, Norihiro Kamae 


* Package name: obs-command-source
  Version : 0.3.2
  Upstream Contact: Norihiro Kamae 
* URL : 
https://obsproject.com/forum/resources/dummy-source-to-execute-command.952/
* License : GPL-2
  Programming Lang: C, Python
  Description : plugin for OBS Studio providing a dummy source to execute 
commands

 This plugin provides a dummy source to execute arbitrary commands when a scene
 is switched.
 .
 Current features:
 .
   Start a command at the following events:
 * Show (the source is shown in either preview or program).
 * Hide (the source is hidden so that no longer shown in neither preview
   nor program).
 * Activate (the source goes to the program).
 * Deactivate (the source goes from the program).
 * Show in preview (the source goes to the preview).
 * Hide from preview (the source goes from the preview).
   .
   Optionally, kill the created process at these conditions (this feature is
   not available for Windows as of now):
 * When hiding, kill the process created at shown.
 * When deactivating, kill the process created at activated.
 * When hiding from the preview, kill the process created at preview.
 .
 Possible usage:
   * Implementing custom tally lights.
   * Controlling PTZ cameras by switching the scene. Ii is possible to combine
 with CURL to send some commands.
   * Start and stop a daemon program required for the scene.
   * Trigger other operations through websocket at the event. A helper script
 is available for this (request-websocket.py).
   * Start or stop a streaming and recording.
   * Open a full screen video.
   * Open a calculator to teach about finances when switching a scene.
   * Other actions.

Bug#1030298: #1030298: Patch backported from upstream, 10-day delayed NMU uploaded

[Roland Mas]

Hi all,

Upstream has a patch that I successfully tested on barriere.d.o (i386 
porterbox) after a minor tweak (the tolerance was not enough). I've 
committed it to a forked repository on salsa and submitted a merge 
request at 
https://salsa.debian.org/opencl-team/python-pyopencl/-/merge_requests/3


Also, given the urgency of the situation (since several dependent 
packages are at risk of getting thrown out of testing), I uploaded a 
10-day delayed NMU.


Thanks,

Roland.

Bug#1031722: gdb: changelog missing in binary packages

[Christian Göttsche]

Source: gdb
Version: 13.1-1
Severity: serious
Justification: violates Debian Policy 12.7.

The binary packages, e.g. gdb[1], do not contain a changelog file,
required by the Debian Policy 12.7.[2].


[1]: https://packages.debian.org/sid/amd64/gdb/filelist
[2]: 
https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes

Bug#1031719: Output from a bullseye host with pulseaudio

[Landry Minoza]

Additionally this is what I see from a Bullseye desktop in the same network

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

$ pactl load-module module-zeroconf-discover
21

$ pactl list sources
Source #0
État : SUSPENDED
Nom : alsa_output.pci-_00_1f.3.analog-stereo.monitor
[…]

Source #1
État : IDLE
Nom :
tunnel.demetra.local.alsa_output.pci-_0a_00.4.analog-stereo.monitor
[…]

Source #2
État : IDLE
Nom :
tunnel.demetra.local.alsa_input.usb-Logitech_G533_Gaming_Headset-00.mono-fallback
Description : [G533 Wireless Headset Dongle] Mono on landry@demetra
Pilote : module-tunnel.c
Spécification de l'échantillon : s16le 1ch 48000Hz
Plan des canaux : mono
Module du propriétaire : 23
Sourdine : non
Volume : mono: 65536 / 100% / 0,00 dB
   balance 0,00
Volume de base : 65536 / 100% / 0,00 dB
Moniteur de la destination : n/d
Latence : 77655 usec, configuré 25 usec
Marqueurs : NETWORK DECIBEL_VOLUME LATENCY
Propriétés :
device.description = "[G533 Wireless Headset Dongle] Mono on landry@demetra"
tunnel.remote.server = "[10.0.0.144]:4713"
tunnel.remote.source =
"alsa_input.usb-Logitech_G533_Gaming_Headset-00.mono-fallback"
device.icon_name = "audio-input-microphone"
tunnel.remote_version = "35"
tunnel.remote.user = "landry"
tunnel.remote.fqdn = "demetra"
tunnel.remote.description = "[G533 Wireless Headset Dongle] Mono"
Formats :
pcm

Source #3
État : IDLE
Nom : tunnel.demetra.local.alsa_input.pci-_0a_00.4.analog-stereo
[…]

Source #4
État : IDLE
Nom :
tunnel.demetra.local.alsa_output.usb-Logitech_G533_Gaming_Headset-00.analog-stereo.monitor
Description : Monitor Source of [G533 Wireless Headset Dongle] Stéréo
analogique on landry@demetra
Pilote : module-tunnel.c
Spécification de l'échantillon : s16le 2ch 48000Hz
Plan des canaux : front-left,front-right
Module du propriétaire : 25
Sourdine : non
Volume : front-left: 65536 / 100% / 0,00 dB,   front-right: 65536 / 100% /
0,00 dB
   balance 0,00
Volume de base : 65536 / 100% / 0,00 dB
Moniteur de la destination :
tunnel.demetra.local.alsa_output.usb-Logitech_G533_Gaming_Headset-00.analog-stereo
Latence : 0 usec, configuré 25 usec
Marqueurs : DECIBEL_VOLUME LATENCY
Propriétés :
device.description = "Monitor Source of [G533 Wireless Headset Dongle]
Stéréo analogique on landry@demetra"
device.class = "monitor"
device.icon_name = "audio-input-microphone"
Formats :
pcm

-- 
Landry MINOZA
landry.min...@gmail.com

Bug#956804:

[Valerio Bozzolan]

I just want to mention that, I don't see ANY way at all to expose any
custom environment variable to the Tomcat process itself.

Feature? Unsure.

AFAIK If you push an environment variable inside your catalina.sh, (for
example via the previously mentioned setenv.sh), that variable just die
in catalina.sh and - it seems to me - it is never exposed to the
Tomcat's Bootstrap process.

I'd just be curious if what I'm saying makes sense.

-- 
Valerio Bozz.


E-mail sent from Evolution from a random GNU/Linux distribution,
delivered from my Postfix mailserver.

Have fun with software freedom!