Bug#1033348: Tracebacks triggered too easily, and inconsistently, when chopping short output

[Dan Jacobson]

Package: unicode
Version: 2.9-1

Sometimes, even for the same command(!), limiting the output causes a
traceback.

Certainly using head(1), sed(1), etc. should be a legitimate use, and
not cause errors.

Here, the first try works fine.
Trying it again just for fun, causes an error.

But other times the error might be on the first time, not second, or
both, or none.

There should be no error ever.

$ unicode --max 22 -r per|sed q
U+0025 PERCENT SIGN

Too many characters to display, more than 22, use --max 0 (or other value) 
option to change it
$ unicode --max 22 -r per|sed q
U+0025 PERCENT SIGN
Traceback (most recent call last):
  File "/usr/bin/unicode", line 1066, in 
main()
  File "/usr/bin/unicode", line 1063, in main
print_characters(processed_args, options.maxcount, format_string, 
options.query_wikipedia, options.query_wiktionary)
  File "/usr/bin/unicode", line 683, in print_characters
sys.stdout.flush()
BrokenPipeError: [Errno 32] Broken pipe
Exception ignored in: <_io.TextIOWrapper name='' mode='w' 
encoding='utf-8'>
BrokenPipeError: [Errno 32] Broken pipe

Bug#1033347: nmu: gridsite, mutt, slashem, util-linux

[Johannes Schauer Marin Rodrigues]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: grids...@packages.debian.org, m...@packages.debian.org, 
slas...@packages.debian.org, util-li...@packages.debian.org
Control: affects -1 + src:gridsite src:mutt src:slashem src:util-linux

Hi,

fakeroot bug #1023286 [1] is fixed now in unstable. Using the attached
script, I found four source packages that have non-root owned files for
amd64 and no files owned by a non-root user for i386. Rebuilding those
four source packages with fakeroot in unstable will fix this issue. I
didn't try the other three 32 bit architectures but assume that the
issue will be fixed there in the same way.

To prevent multi-arch:same version skews, gridsite and util-linux maybe have to
be rebuilt on ANY architecture?

Thanks!

cheers, josch

nmu gridsite_3.0.0~20180202git2fdbc6f-3+b4 . armel armhf i386 mipsel . unstable 
. -m "rebuild with fakeroot #1030638 fixed"
nmu mutt_2.2.9-1 . armel armhf i386 mipsel . unstable . -m "rebuild with 
fakeroot #1030638 fixed"
nmu slashem_0.0.7E7F3-10 . armel armhf i386 mipsel . unstable . -m "rebuild 
with fakeroot #1030638 fixed"
nmu util-linux_2.38.1-5 . armel armhf i386 mipsel . unstable . -m "rebuild with 
fakeroot #1030638 fixed"

[1] https://lists.debian.org/167595344742.2689605.6866779165899252490@localhost
#!/bin/sh

set -eu

if [ ! -e rootneeded.txt ]; then
curl --silent 
https://trends.debian.net/rulesreqroot_unstable-packages.csv \
| grep --invert-match ',adopted, fakeroot not needed' \
| sed -ne 's/,.*//p' \
| sort > rootneeded.txt
fi

if [ ! -e archany.txt ]; then
apt-get indextargets --format '$(FILENAME)' 'Identifier: Sources' 
'Component: main' 'Origin: Debian' 'Suite: unstable' \
| xargs /usr/lib/apt/apt-helper cat-file \
| grep-dctrl --invert-match --exact-match --field Architecture 
all --no-field-names --show-field=Package \
| sort > archany.txt
fi

comm -12 rootneeded.txt archany.txt > archanyrootneeded.txt

dlarchany() {
arch="$1"
while read -r src; do
echo "$src" >&2
mkdir tmp
apt-cache showsrc --only-source "$src" \
| grep-dctrl --show-field Binary 
--no-field-names '' \
| tr , '\n' \
| sort -u \
| while read -r bin; do
[ -z "$bin" ] && continue
# this fails if $bin is arch:all but we 
are not
# interested in those anyways because 
those are built
# on amd64
env --chdir tmp apt-get download 
"$bin:$arch" >/dev/null || continue
if dpkg-deb --fsys-tarfile tmp/*.deb \
| tar tv \
| grep --silent --invert-match 
' root/root '; then
echo "$src"
rm tmp/*.deb
break
fi
rm tmp/*.deb
done
rmdir tmp
done
}

dlarchany amd64 < archanyrootneeded.txt > nonrootownership_amd64.txt
dlarchany i386 < nonrootownership_amd64.txt > nonrootownership_i386.txt

comm -23 nonrootownership_amd64.txt nonrootownership_i386.txt

Bug#1033346: postfix: default master.cf bsmtp service vulnerable to allow_min_user injection out-of-box

[наб]

Package: postfix
Version: 3.5.17-0+deb11u1
Version: 3.7.4-2
Severity: normal
Tags: upstream patch

Dear Maintainer,

Please see patch, below, for more info.

Best,
наб

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

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

Versions of packages postfix depends on:
ii  adduser3.118
ii  cpio   2.13+dfsg-4
ii  debconf [debconf-2.0]  1.5.77
ii  dpkg   1.20.12
ii  e2fsprogs  1.46.2-2
ii  libc6  2.31-13+deb11u5
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libicu67   67.1-7
ii  libnsl21.3.0-2
ii  libsasl2-2 2.1.27+dfsg-2.1+deb11u1
ii  libssl1.1  1.1.1n-0+deb11u4
ii  lsb-base   11.1.0
ii  netbase6.3
ii  ssl-cert   1.1.0+nmu1

Versions of packages postfix recommends:
ii  ca-certificates  20210119
ii  python3  3.9.2-3

Versions of packages postfix suggests:
ii  dovecot-core [dovecot-common]  1:2.3.13+dfsg1-2+deb11u1
ii  libsasl2-modules   2.1.27+dfsg-2.1+deb11u1
ii  mailutils [mail-reader]1:3.10-3+b1
ii  neomutt [mail-reader]  20220429+dfsg-0.1~bpo11+1
pn  postfix-cdb
pn  postfix-doc
pn  postfix-ldap   
pn  postfix-lmdb   
pn  postfix-mysql  
pn  postfix-pcre   
pn  postfix-pgsql  
pn  postfix-sqlite 
pn  procmail   
pn  resolvconf 
pn  ufw

-- debconf information excluded
Description: secure default bsmtp master.cf against allow_min_user=yes
 Per src/trivial-rewrite/resolve.c:
/*
 * Bounce recipient addresses that start with `-'. External commands may
 * misinterpret such addresses as command-line options.
 *
 * In theory I could say people should always carefully set up their
 * master.cf pipe mailer entries with `--' before the first non-option
 * argument, but mistakes will happen regardless.
 *
 * Therefore the protection is put in place here, where it cannot be
 * bypassed.
 */
if (var_allow_min_user == 0 && STR(nextrcpt)[0] == '-') {
*flags |= RESOLVE_FLAG_ERROR;
FREE_MEMORY_AND_RETURN;
}
 .
 Indeed, the bsmtp service, enabled by default, will happy run
   bsmtp -t$nexthop -f$sender -whate...@example.org
 so finish the flags with --.
 .
 Both commented-out cyrus services are also likely vulnerable,
 but I can't find a manual or source (plus they're commented out).
Author: наб 
Last-Update: 2023-03-23
--- postfix-3.7.4.orig/conf/master.cf
+++ postfix-3.7.4/conf/master.cf
@@ -130,7 +130,7 @@ uucp  unix  -   n   n
 ifmailunix  -   n   n   -   -   pipe
   flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
 bsmtp unix  -   n   n   -   -   pipe
-  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender 
$recipient
+  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender -- 
$recipient
 scalemail-backend unix -   n   n   -   2   pipe
   flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store 
${nexthop} ${user} ${extension}
 mailman   unix  -   n   n   -   -   pipe


signature.asc
Description: PGP signature

Bug#1033345: ITP: nvitop -- An interactive NVIDIA-GPU process viewer and beyond

[M. Zhou]

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

* Package name: nvitop
* URL : https://github.com/XuehaiPan/nvitop
* License : Apache-2.0 / GPL-3.0 dual license
  Programming Lang: Python
  Description : An interactive NVIDIA-GPU process viewer and beyond

We have a couple of nvidia GPU utility monitors. Nvidia's nvidia-smi
is standard but far not readable enough for heavy GPU users like me.
I packaged gpustat -- it is good, but it does not show the standard
top informantion, and as a result I have to open another tmux window
for glances or htop, in order to make sure the neural network does
not blow up the system memory.

This nvitop just combines both gpu monitoring and CPU/ram monitoring.
Have used it for a while on GPU servers. It cannot be better.

This package will be maintained under the umbrella of the nvidia packaging
team. I suppose the package has to enter contrib because it depends on the
non-free nvidia driver.

Thank you for using reportbug

Bug#1033344: unblock: src:texlive-extra/2022.20230122-3

[Hilmar Preusse]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package src:texlive-extra. I did not upload the
package to unstable, I'd like to hear your decision beforehand.

Recently we were informed (#1033008), that the LaTeX -> OOffice
conversion engine of make4ht is severily broken and does not
work at all. The upstream author released a fix a while ago,
which was tested and was proven to solve the issue.

[ Reason ]
We would like release the make4ht engine with a working LaTeX ->
OOffice conversion engine for next stable release.

[ Impact ]
Conversion of LaTeX to OOffice documents would not be possible
using make4ht.

[ Tests ]
There were no automated tests. We only apply the patch for the issue
described here [1]. The submitter confirmed that the patch solved
the specific issue.

[ Risks ]
Code change is rather trivial and should not affect source packages.
The human end users already confirmed that the change is useful.

[ 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

Thanks,
  Hilmar

unblock src:texlive-extra/2022.20230122-3

[1] https://github.com/michal-h21/make4ht/issues/107

-- 
sigmentation fault
diff -Nru texlive-extra-2022.20230122/debian/changelog texlive-extra-2022.20230122/debian/changelog
--- texlive-extra-2022.20230122/debian/changelog	2023-02-15 13:55:21.0 +0100
+++ texlive-extra-2022.20230122/debian/changelog	2023-02-15 13:55:21.0 +0100
@@ -1,3 +1,10 @@
+texlive-extra (2022.20230122-3) unstable; urgency=medium
+
+  * Apply patch for ooffice.4ht to fix conversion LaTeX ->
+OOffice documents (Closes: #1033008).
+
+ -- Hilmar Preusse   Wed, 15 Feb 2023 13:55:21 +0100
+
 texlive-extra (2022.20230122-2) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -Nru texlive-extra-2022.20230122/debian/patches/series texlive-extra-2022.20230122/debian/patches/series
--- texlive-extra-2022.20230122/debian/patches/series	2022-09-23 23:01:08.0 +0200
+++ texlive-extra-2022.20230122/debian/patches/series	2023-02-15 13:55:21.0 +0100
@@ -13,3 +13,4 @@
 #replace_SELFAUTOPARENT
 # fix-jadetex-new-latex
 #tex4ht-babel
+update_ooffice.4ht
diff -Nru texlive-extra-2022.20230122/debian/patches/update_ooffice.4ht texlive-extra-2022.20230122/debian/patches/update_ooffice.4ht
--- texlive-extra-2022.20230122/debian/patches/update_ooffice.4ht	1970-01-01 01:00:00.0 +0100
+++ texlive-extra-2022.20230122/debian/patches/update_ooffice.4ht	2023-02-15 13:55:21.0 +0100
@@ -0,0 +1,1082 @@
+Description:  Error in odt conversion: Format error in the file, in the styles.xml #107
+Origin: Michal Hoftich 
+Forwarded: No. Patch comes from upstream.
+Author: Michal Hoftich 
+Last-Update: 20230125
+
+--- texlive-base-2022.20230122.orig/texmf-dist/tex/generic/tex4ht/ooffice.4ht	2023-01-19 22:32:03.0 +0100
 texlive-base-2022.20230122/texmf-dist/tex/generic/tex4ht/ooffice.4ht	2023-01-25 23:49:22.0 +0100
+@@ -1,4 +1,4 @@
+-% ooffice.4ht (2023-01-19-13:31), generated from tex4ht-ooffice.tex
++% ooffice.4ht (2023-01-24-13:16), generated from tex4ht-ooffice.tex
+ % Copyright 2009-2023 TeX Users Group
+ % Copyright 2001-2009 Maarten Wisse, James Naughton, Eitan M. Gurari
+ %
+@@ -17,7 +17,7 @@
+ %
+ % If you modify this program, changing the
+ % version identification would be appreciated.
+-\immediate\write-1{version 2023-01-19-13:31}
++\immediate\write-1{version 2023-01-24-13:16}
+ 
+   \exit:ifnot{Preamble,% 
+ algorithmicx,% 
+@@ -3716,9 +3716,9 @@
+   style:class="text">\Hnewline
+ 
+@@ -3861,7 +3861,7 @@
+   fo:font-size="12pt"
+   fo:font-style="italic"
+   fo:font-weight="normal"
+-  style:font-size-complex="85\prcnt:ch%"
++  style:font-size-complex="85\prcnt:ch"
+   style:font-weight-complex="bold"
+   fo:text-indent="0cm"
+   style:auto-text-indent="false"/>
+@@ -3897,11 +3897,11 @@
+   style:parent-style-name="Heading"
+   style:next-style-name="Text-body"
+   style:class="text">\Hnewline
+-
+ 
+ \Hnewline \Hnewline
+-
+ 
+ \Hnewline \Hnewline
+-
+ 
+ \Hnewline \Hnewline
+-
+ 
+ \Hnewline \Hnewline
+-
+ 
+ \Hnewline \Hnewline
+ 
+@@ -5286,7 +5286,7 @@
+   fo:font-size="12pt"
+   fo:font-style="italic"
+   fo:font-weight="normal"
+-  style:font-size-complex="85\prcnt:ch%"
++  style:font-size-complex="85\prcnt:ch"
+   style:font-weight-complex="bold"
+   fo:text-indent="0cm"
+   style:auto-text-indent="false"/>
+@@ -5322,11 +5322,11 @@
+   style:parent-style-name="Heading"
+   style:next-style-name="Text-body"
+   

Bug#1030249: "prefclean output on ..." emails

[Francesco Poli]

On Wed, 22 Mar 2023 11:42:19 -0700 andy wrote:

> i have also started receiving email notifications from apt-listbugs and
> am +1'ing the suggestion for a knob to turn off all emails.

Hello,
thanks for your comments, I am taking notice.

> 
> in my case it seems related to an Acquire::http::Proxy setting.
>  * when waking from sleep in a location where the apt-proxy is
>reachable, about 1/2 the time (from a small sample size of 1 laptop
>over a few days) it apparently tries to run before the network is
>available and emails "E: getaddrinfo: Name or service not known
>[...]" (perhaps related to #964438).

Taking what you describe into account, it really seems that you are
experiencing bug #964438 .
Unfortunately, my attempt to report a wishlist bug against systemd was
not really successful...   :-(

>  * when in a location where the apt-proxy is not reachable, i receive
>emails every so often re: "E: Connection refused - Connection
>refused".  while a valid complaint this is a known issue that i
>don't need to hear about and would like to be able to turn off.

Why do you use a proxy for HTTP in apt?
Are you forced to use a proxy (because direct HTTP connections are
disabled in your network), or do you just prefer to use a proxy
(perhaps in order to benefit from caching and similar features)?

If direct HTTP are allowed on your network, you could consider
disabling the use of the proxy for apt-listbugs, by setting

  Acquire::http::Proxy::bugs.debian.org "DIRECT";

in /etc/apt/apt.conf.d/10apt-listbugs

This should make apt-listbugs bypass the proxy for its BTS queries.
Please see the apt-listbugs(1) man page.

> 
> i am uncertain why these emails seems to have just started in the past
> few days. afaik the only possibly relevant change i made was to update
> Acquire::http::Proxy to a fqdn. please let me know if you would prefer
> a new bug report as this may be only tangentially related to this
> particular bug (while solution of an "off switch" is the same).

No need for a separate bug report, at least for the time being.

> 
> thanks in advance.

You are welcome!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp36Ee49Biit.pgp
Description: PGP signature

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Cyril Brulebois]

Hi Frédéric,

Frédéric Bonnard  (2023-03-22):
> Another important detail ... I only get that behavior in qemu in
> graphical mode. On LPARs there is no issue. I didn't try on baremetal
> so far.

Could you please guide me into reproducing this issue in QEMU? #987368
had hints, but at least the openpower.xyz part no longer works (it's no
longer resolving).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1020465: Ready to be implemented

[Soren Stoutner]

The dependencies are finally in place where this is ready to be implemented.

To make things simpler for the packagers, we are using a virtual package and 
an unversioned path for the conversion tool so that language packagers don’t 
have to make modifications to their packages when the versions of Qt change in 
Debian.

All you should need to do is the following:

1.  Build-depends on `convert-bdic`.
2.  Use /usr/bin/convert-bdic to do the dictionary conversion.
3.  Place the .bdic files in /usr/share/hunspell-bdic.

Thanks,

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


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

Bug#1033343: ITP: libstoragedisplay-perl -- Collect and display storages on Linux machines

[Vincent Danjean]

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

* Package name: libstoragedisplay-perl
  Version : 1.2.3
  Upstream Contact: Vincent Danjean 
* URL : https://metacpan.org/release/StorageDisplay
* License : Artistic or GPL-1+ (Perl)
  Programming Lang: Perl
  Description : Collect and display storages on Linux machines

 This program can be used to collect data about storage state on
 local and remote machine, and then to generate a DOT file
 the is a graphical representation of the storage state.
 .
 Data collecting requires only perl (and its basic modules) and a
 shell account with sudo rights.
 .
 DOT file generation requires more perl modules (the recommended
 ones), but this can be done on another machine.

Bug#1033341: org-mode: CVE-2023-28617

[Salvatore Bonaccorso]

Source: org-mode
Version: 9.5.2+dfsh-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: clone -1 -2
Control: reassign -2 src:emacs 1:28.2+1-13
Control: retitle -2 emacs: CVE-2023-28617

Hi,

The following vulnerability was published for org-mode (and emacs,
will close tis bug).

CVE-2023-28617[0]:
| org-babel-execute:latex in ob-latex.el in Org Mode through 9.6.1 for
| GNU Emacs allows attackers to execute arbitrary commands via a file
| name or directory name that contains shell metacharacters.


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

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1033340: redis: CVE-2023-28425

[Salvatore Bonaccorso]

Source: redis
Version: 5:7.0.9-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for redis.

Note this is not strictly speaking RC severity for the CVE issue, but
it's only present in unstable, so let's avoid it might go to testing.

Speaking of redis and bookworm, with the fix here applied, can you
have a look at the regessions, and help redis migrate to testing?

CVE-2023-28425[0]:
| Redis is an in-memory database that persists on disk. Starting in
| version 7.0.8 and prior to version 7.0.10, authenticated users can use
| the MSETNX command to trigger a runtime assertion and termination of
| the Redis server process. The problem is fixed in Redis version
| 7.0.10.


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-28425
https://www.cve.org/CVERecord?id=CVE-2023-28425
[1] https://github.com/redis/redis/security/advisories/GHSA-mvmm-4vq6-vw8c

Regards,
Salvatore

Bug#1033339: unblock: chromium/111.0.5563.110-1

[Andres Salomon]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: chrom...@packages.debian.org, Andres Salomon 
, tpear...@raptorengineering.com

Control: affects -1 + src:chromium

Please unblock package chromium so that it migrates to bookworm after 5 
days pending successful builds & autopkgtest. The upload to unstable 
fixes another set of 7 CVEs, and the same version 
(111.0.5563.110-1~deb11u1) has already been uploaded to 
security-master, just awaiting the security team's DSA.


Thanks,
Andres

Bug#1027444: closed by Giuseppe Sacco (Closing after further investigation)

[Salvatore Bonaccorso]

Ciao Giuseppe,

> Hello,
> I finally found the source of this problem: it was a hardware problem on
> the video card. In fact, after replacing the board the system started
> working correctly. Sorry to bother you.

Thanks for reporting back!

Regards,
Salvatore

Bug#1033338: unblock: opendnssec/1:2.1.12-2

[Mathieu Mirmont]

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

Please unblock package opendnssec

[ Reason ]
Adding Romanian translation.

[ Impact ]
None, just a translation.

[ Tests ]
None.

[ Risks ]
The changes are really trivial.

[ 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 opendnssec/1:2.1.12-2

-- 
Mathieu Mirmont 
diff -Nru opendnssec-2.1.12/debian/changelog opendnssec-2.1.12/debian/changelog
--- opendnssec-2.1.12/debian/changelog  2022-11-10 10:06:20.0 +0100
+++ opendnssec-2.1.12/debian/changelog  2023-03-19 09:33:29.0 +0100
@@ -1,3 +1,11 @@
+opendnssec (1:2.1.12-2) unstable; urgency=medium
+
+  * control: bump policy to 4.6.2, no code change
+  * opendnssec-common.postinst: shellcheck compliance
+  * po/ro.po: Add Romanian translation (Closes: #1033174)
+
+ -- Mathieu Mirmont   Sun, 19 Mar 2023 09:33:29 +0100
+
 opendnssec (1:2.1.12-1) unstable; urgency=medium
 
   * New upstream version 2.1.12
diff -Nru opendnssec-2.1.12/debian/control opendnssec-2.1.12/debian/control
--- opendnssec-2.1.12/debian/control2022-11-10 09:39:27.0 +0100
+++ opendnssec-2.1.12/debian/control2023-02-07 09:05:19.0 +0100
@@ -23,7 +23,7 @@
procps,
sqlite3,
xsltproc
-Standards-Version: 4.6.1
+Standards-Version: 4.6.2
 Homepage: https://www.opendnssec.org/
 Vcs-Browser: https://salsa.debian.org/debian/opendnssec
 Vcs-Git: https://salsa.debian.org/debian/opendnssec.git
diff -Nru opendnssec-2.1.12/debian/opendnssec-common.postinst 
opendnssec-2.1.12/debian/opendnssec-common.postinst
--- opendnssec-2.1.12/debian/opendnssec-common.postinst 2022-11-10 
09:39:27.0 +0100
+++ opendnssec-2.1.12/debian/opendnssec-common.postinst 2023-02-07 
09:28:51.0 +0100
@@ -11,10 +11,6 @@
 fi
 }
 
-unset_perms() {
-dpkg-statoverride --quiet --remove "$1" || true
-}
-
 disable_autostart() {
 cat <<-EOF > /etc/opendnssec/prevent-startup
OpenDNSSEC requires manual configuration before the signer and enforcer
@@ -48,10 +44,10 @@
done
 
for conf in addns.xml conf.xml kasp.xml zonelist.xml; do
-   ucf --debconf-ok /usr/share/opendnssec/$conf /etc/opendnssec/$conf
-   ucfr opendnssec /etc/opendnssec/$conf
+   ucf --debconf-ok /usr/share/opendnssec/"$conf" 
/etc/opendnssec/"$conf"
+   ucfr opendnssec /etc/opendnssec/"$conf"
[ "$conf" = "zonelist.xml" ] && owner=opendnssec || owner=root
-   set_perms $owner opendnssec 0640 /etc/opendnssec/$conf
+   set_perms "$owner" opendnssec 0640 /etc/opendnssec/"$conf"
done
 
# Prevent the daemons from being started automatically, but only on
diff -Nru opendnssec-2.1.12/debian/po/ro.po opendnssec-2.1.12/debian/po/ro.po
--- opendnssec-2.1.12/debian/po/ro.po   1970-01-01 01:00:00.0 +0100
+++ opendnssec-2.1.12/debian/po/ro.po   2023-03-19 09:29:50.0 +0100
@@ -0,0 +1,70 @@
+# Mesajele în limba română pentru pachetul opendnssec.
+# Romanian translation of opendnssec.
+# Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the opendnssec package.
+#
+# Remus-Gabriel Chelu , 2023.
+#
+# Cronologia traducerii fișierului „opendnssec”:
+# Traducerea inițială, făcută de R-GC, pentru versiunea opendnssec 1 
2.1.12-1(2022-11-01).
+# Actualizare a traducerii pentru versiunea Y, făcută de X, Y(anul).
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: opendnssec 1 2.1.12-1\n"
+"Report-Msgid-Bugs-To: opendns...@packages.debian.org\n"
+"POT-Creation-Date: 2022-11-01 10:21+0100\n"
+"PO-Revision-Date: 2023-03-11 23:16+0100\n"
+"Last-Translator: Remus-Gabriel Chelu \n"
+"Language-Team: Romanian \n"
+"Language: ro\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && "
+"n%100<=19) ? 1 : 2);\n"
+"X-Bugs: Report translation errors to the Language-Team address.\n"
+"X-Generator: Poedit 3.2.2\n"
+
+#. Type: note
+#. Description
+#: ../opendnssec-common.templates:1001
+msgid "Manual OpenDNSSEC configuration required"
+msgstr "Este necesară configurarea manuală a OpenDNSSEC"
+
+#. Type: note
+#. Description
+#: ../opendnssec-common.templates:1001
+msgid ""
+"OpenDNSSEC requires manual configuration before the signer and enforcer 
daemons "
+"can be started."
+msgstr ""
+"OpenDNSSEC necesită să fie configurat manual înainte ca demonii de semnare "
+"«signer» și de executare «enforcer» să poată fi porniți."
+
+#. Type: note
+#. Description
+#: ../opendnssec-common.templates:1001
+msgid ""
+"One of these configuration steps consists of installing and configuring a "
+"Hardware Security Module 

Bug#1033336: RM: faumachine -- RoQA; RC-buggy, depends on python 2

[Stefan Potyra]

Hi Moritz and ftp-masters,

thanks a lot for cleaning up cruft in the archive. You really rock!

May I ask for a short delay before you remove faumachine (source)? I think the
binaries have long been removed.

It's not unmaintained, just very badly maintained. Once I understand how to port
the cmp() operator to python3, there is a 50:50 chance that it will build again.
Doesn't help too much that the script taken over from geda has been ported to
scheme in the now active fork :/.

How about a deadline? Give me one month, so 22th of April and a fixed upload is
in place or you can remove it?

And once again, thanks for all your great work. Keeping debian secure and sane
really is impressive!

Cheers,
  Stefan - very bad maintainer nowadays.


signature.asc
Description: PGP signature

Bug#1033191: ccache: Solution to address the deadlocking issue with ccache 4.7 on Debian Bookworm.

[Joel Rosdahl]

On Sun, Mar 19, 2023, at 11:42, David Heidelberg wrote:
> The authors of ccache have mentioned that this version includes a rewrite 
> that addresses serious issues, such as deadlocks [2].

Just to clarify: the rewritten locking solution in 4.8 was not done to fix any 
known bug - it was done for portability reasons since the previous solution 
relied on pthread mutex behavior that is different in FreeBSD.

-- Joel

Bug#1033285: unblock: libpaper/1.1.29

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-03-21 12:03:30 +0100, Giuseppe Sacco wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package libpaper. This new version only includes non-code
> changes: a few typos corrections in manual pages and a new language
> translation.
> 
> [ Reason ]
> While this is not a necessary update, it would benefits users without
> having any functional impact.
> 
> [ Impact ]
> ditto
> 
> [ Tests ]
> nothing
> 
> [ Risks ]
> No code changes are present. There should not be any 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 ]
> nothing
> 
> Thank you very much,
> Giuseppe
> 
> unblock libpaper/1.1.29
> 

> diff -Nru libpaper-1.1.28/debian/changelog libpaper-1.1.29/debian/changelog
> --- libpaper-1.1.28/debian/changelog  2019-06-26 00:04:32.0 +0200
> +++ libpaper-1.1.29/debian/changelog  2023-03-17 14:44:15.0 +0100
> @@ -1,3 +1,14 @@
> +libpaper (1.1.29) unstable; urgency=medium
> +
> +  * Fix for parallel build. See #857058

How does this upload fix parallel building? The diff only contains
changes to translations?

Cheers

> +  * Added romanian translation. See #1032333
> +  * Updated standards-version to 4.6.0 (no changes)
> +  * Update papersize manual page. See #959403
> +  * Update paperconf manual page. See #959404
> +  * Update paperconfig manual page. See #959405
> +
> + -- Giuseppe Sacco   Fri, 17 Mar 2023 14:44:15 +0100
> +
>  libpaper (1.1.28) unstable; urgency=medium
>  
>* Completely fixed #927226.
> diff -Nru libpaper-1.1.28/debian/control libpaper-1.1.29/debian/control
> --- libpaper-1.1.28/debian/control2016-07-16 18:06:42.0 +0200
> +++ libpaper-1.1.29/debian/control2023-03-17 14:29:31.0 +0100
> @@ -2,7 +2,7 @@
>  Section: libs
>  Priority: optional
>  Maintainer: Giuseppe Sacco 
> -Standards-Version: 3.9.8
> +Standards-Version: 4.6.0
>  Build-Depends: autotools-dev, dpkg-dev (>= 1.16.1~), debhelper (>= 9), 
> dh-autoreconf, dh-exec(>= 0.3), po-debconf, autoconf
>  
>  Package: libpaper1
> diff -Nru libpaper-1.1.28/debian/po/ro.po libpaper-1.1.29/debian/po/ro.po
> --- libpaper-1.1.28/debian/po/ro.po   1970-01-01 01:00:00.0 +0100
> +++ libpaper-1.1.29/debian/po/ro.po   2023-03-17 14:22:38.0 +0100
> @@ -0,0 +1,316 @@
> +# Mesajele în limba română pentru pachetul libpaper.
> +# Romanian translation of libpaper.
> +# Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER
> +# This file is distributed under the same license as the libpaper package.
> +#
> +# Remus-Gabriel Chelu , 2023.
> +#
> +# Cronologia traducerii fișierului „libpaper”:
> +# Traducerea inițială, făcută de R-GC, pentru versiunea libpaper 
> 1.1.28(2009-07-18).
> +# Actualizare a traducerii pentru versiunea Y, făcută de X, Y(anul).
> +#
> +msgid ""
> +msgstr ""
> +"Project-Id-Version: libpaper 1.1.28\n"
> +"Report-Msgid-Bugs-To: eppes...@debian.org\n"
> +"POT-Creation-Date: 2007-07-18 19:50+0200\n"
> +"PO-Revision-Date: 2023-02-26 11:30+0100\n"
> +"Last-Translator: Remus-Gabriel Chelu \n"
> +"Language-Team: Romanian \n"
> +"Language: ro\n"
> +"MIME-Version: 1.0\n"
> +"Content-Type: text/plain; charset=UTF-8\n"
> +"Content-Transfer-Encoding: 8bit\n"
> +"Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && "
> +"n%100<=19) ? 1 : 2);\n"
> +"X-Bugs: Report translation errors to the Language-Team address.\n"
> +"X-Generator: Poedit 3.2.2\n"
> +
> +# R-GC, scrie:
> +# cum multe dintre dimensiunile ce apar aici,
> +# au nume englezești(a se citi, americane),
> +# ce traduse, nu ne spun mare lucru și care
> +# pe aici pe colo, induc în eroare, am extras
> +# dimensiunile acestora (în milimetri), din
> +# pagina de Wikipedia:
> +# 
> +#. Type: select
> +#. Choices
> +#: ../libpaper1.templates:2001
> +msgid "letter"
> +msgstr "Letter(scrisoare) [216 x 279mm]"
> +
> +#. Type: select
> +#. Choices
> +#: ../libpaper1.templates:2001
> +msgid "a4"
> +msgstr "A4 [210 x 297mm]"
> +
> +#. Type: select
> +#. Choices
> +#: ../libpaper1.templates:2001
> +msgid "note"
> +msgstr "Note(notă) [220 x 280mm]"
> +
> +#. Type: select
> +#. Choices
> +#: ../libpaper1.templates:2001
> +msgid "legal"
> +msgstr "Legal [216 x 356mm]"
> +
> +#. Type: select
> +#. Choices
> +#: ../libpaper1.templates:2001
> +msgid "executive"
> +msgstr "Executive [184 x 267mm]"
> +
> +#. Type: select
> +#. Choices
> +#: ../libpaper1.templates:2001
> +msgid "halfletter"
> +msgstr "Half Letter(½ scrisoare) [140 x 216mm]"
> +
> +#. Type: select
> +#. Choices
> +#: ../libpaper1.templates:2001
> +msgid "halfexecutive"
> +msgstr "Half Executive(½ executiv) [130 x 184mm]"
> +
> +#. Type: select
> +#. Choices
> +#: ../libpaper1.templates:2001
> +msgid "11x17"
> +msgstr "11x17 [279 x 432mm]"
> +
> +#. 

Bug#1033292: unblock: amanda/1:3.5.1-11

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-03-21 19:08:09 +, Jose M Calhariz wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: ama...@packages.debian.org, jose.calha...@tecnico.ulisboa.pt, 
> calha...@debian.org, ns-l...@dsi.ist.utl.pt
> Control: affects -1 + src:amanda
> 
> Please unblock package amanda
> 
> 
> [ Reason ]
> 
> The previous version on the fix for CVE-CVE-2022-37705 introduced a
> regression that is fixed by this version.  
> 
> 
> [ Impact ]
> 
> Breaks the use of tar, for backups in some setups, on the affected
> clients, i.e., the use of package amanda-client.  The server can not
> backup itself, but can backups clients with good amanda client
> software,
> 
> 
> 
> [ Tests ]
> 
> I manually tested the affected version and the fixed version, using a
> VM running testing (bookworm) with a amanda compiled for sid.  The
> test is to do backup of the server.  The detail that breaks or not is
> two options in a dumptype that specifies what program to use for
> backup.  When using traditional and old interface for gnutar it
> breaks.  When using the new interface it is not affected.
> 
> I do not have experience in C language to do a proper review of the
> patch that is very simple, but broken in 3.5.1-10.
> 
> 
> [ Risks ]
> 
> The fix in 3.5.1-10 for the three CVEs are a low risks ones because
> user backup is a restricted user.  Only people with previliges already
> can login as user backup and try to run the setgid binaries.  For the
> people affected by regression 3.5.1-10 can workaround using an older
> version on the affected clients.  This bugs does not affect other
> packages as amanda-client is a leaf package.
> 
> 
> 
> [ Checklist ]
>   [X] all changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in testing
> 
> [ Other info ]
> 
> for name in amanda-client amanda-common amanda-server ; do debdiff 
> "/var/cache/apt/archives/${name}_1%3a3.5.1-10_amd64.deb" 
> "/root/${name}_3.5.1-11_amd64.deb" ; done

Please provide the debdiff of the source package.

Cheers

> 
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Depends: amanda-common (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} 
> libxml-simple-perl, perl:any, libc6 (>= 2.34), libglib2.0-0 (>= 2.31.8), 
> libreadline8 (>= 6.0)
> Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Suggests: amanda-server (= [-1:3.5.1-10)-] {+1:3.5.1-11)+} | amanda-client (= 
> [-1:3.5.1-10)-] {+1:3.5.1-11)+}
> Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Depends: amanda-common (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} bsd-mailx | 
> mailx, libjson-perl, perl:any, libc6 (>= 2.34), libcurl4 (>= 7.16.2), 
> libglib2.0-0 (>= 2.31.8)
> Installed-Size: [-1076-] {+1077+}
> Suggests: amanda-client (= [-1:3.5.1-10),-] {+1:3.5.1-11),+} cpio | mt-st, 
> gnuplot
> Version: [-1:3.5.1-10-] {+1:3.5.1-11+}
> 
> 
> 
> 
> unblock amanda/1:3.5.1-11
> 

-- 
Sebastian Ramacher

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

[Sebastian Ramacher]

On 2023-02-28 16:14:42 -0700, Sam Hartman wrote:
> > "Michael" == Michael Biebl  writes:
> 
> Michael> If a service is not supposed to be enabled, then an
> Michael> override for dh_installsystemd is the correct solution,
> Michael> setting --no-enable, but not by moving it into a
> Michael> subpackage.
> 
> Sorry, I was imprecise.
> Imagine something like a webserver.
> You might well want to install the web server binary so you can run it
> as a user for development testing an app or for sharing files.
> But you might also want to  install it as a system service.
> I think two options are viable depending on factors like whether some
> dependencies want to know that it is running as a system service and
> how common each configuration will be:
> 
> * Install a disabled unit by default but keep everything into one
>   package
> 
> * or move the system service unit into its own package.  If you just
>   want the binary you install one package, but if you want the system
>   service, you install the package containing the unit.
>   In this case the unit is enabled by default.
> 
> If we were to move units back from /usr/lib/systemd/system to
> /lib/systemd/system, the second case would potentially trigger the dpkg
> bug.  But:
> 
> 
> Michael> I also don't see a good reason, why a unit file, once
> Michael> installed in /usr/lib/systemd/system should ever move back
> Michael> to /lib/systemd/system.
> 
> I agree with you here.   This requires keeping the debhelper change
> rather than backing it out after the bookworm release.
> I think both you and I support that.

Any progress here? If this issue should be fixed for bookworm, time is
running short.

Cheers
-- 
Sebastian Ramacher

Bug#1033295: cairosvg: diff for NMU version 2.5.2-1.1

[Salvatore Bonaccorso]

Control: tags 1033295 + patch
Control: tags 1033295 + pending


Dear maintainer,

I've prepared an NMU for cairosvg (versioned as 2.5.2-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru cairosvg-2.5.2/debian/changelog cairosvg-2.5.2/debian/changelog
--- cairosvg-2.5.2/debian/changelog	2021-08-30 22:54:50.0 +0200
+++ cairosvg-2.5.2/debian/changelog	2023-03-21 22:21:22.0 +0100
@@ -1,3 +1,11 @@
+cairosvg (2.5.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't allow fetching external files unless explicitly asked for
+(CVE-2023-27586) (Closes: #1033295)
+
+ -- Salvatore Bonaccorso   Tue, 21 Mar 2023 22:21:22 +0100
+
 cairosvg (2.5.2-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru cairosvg-2.5.2/debian/patches/Don-t-allow-fetching-external-files-unless-explicitl.patch cairosvg-2.5.2/debian/patches/Don-t-allow-fetching-external-files-unless-explicitl.patch
--- cairosvg-2.5.2/debian/patches/Don-t-allow-fetching-external-files-unless-explicitl.patch	1970-01-01 01:00:00.0 +0100
+++ cairosvg-2.5.2/debian/patches/Don-t-allow-fetching-external-files-unless-explicitl.patch	2023-03-21 22:20:00.0 +0100
@@ -0,0 +1,66 @@
+From: Guillaume Ayoub 
+Date: Fri, 10 Mar 2023 16:11:22 +0100
+Subject: =?UTF-8?q?Don=E2=80=99t=20allow=20fetching=20external=20files=20u?=
+ =?UTF-8?q?nless=20explicitly=20asked=20for?=
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+Origin: https://github.com/Kozea/CairoSVG/commit/12d31c653c0254fa9d9853f66b04ea46e7397255
+Bug-Debian: https://bugs.debian.org/1033295
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-27586
+
+---
+ cairosvg/__main__.py | 4 ++--
+ cairosvg/parser.py   | 6 ++
+ cairosvg/surface.py  | 3 ++-
+ 3 files changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/cairosvg/__main__.py b/cairosvg/__main__.py
+index 3ff6b5d1282f..0aad3d782489 100644
+--- a/cairosvg/__main__.py
 b/cairosvg/__main__.py
+@@ -42,8 +42,8 @@ def main(argv=None, stdout=None, stdin=None):
+ help='replace every raster pixel with its complementary color')
+ parser.add_argument(
+ '-u', '--unsafe', action='store_true',
+-help='resolve XML entities and allow very large files '
+- '(WARNING: vulnerable to XXE attacks and various DoS)')
++help='fetch external files, resolve XML entities and allow very large '
++ 'files (WARNING: vulnerable to XXE attacks and various DoS)')
+ parser.add_argument(
+ '--output-width', default=None, type=float,
+ help='desired output width in pixels')
+diff --git a/cairosvg/parser.py b/cairosvg/parser.py
+index f0f3a82573f3..61275f0a1073 100644
+--- a/cairosvg/parser.py
 b/cairosvg/parser.py
+@@ -390,6 +390,12 @@ class Tree(Node):
+ tree = ElementTree.fromstring(
+ bytestring, forbid_entities=not unsafe,
+ forbid_external=not unsafe)
++
++# Don???t allow fetching external files unless explicitly asked for
++if 'url_fetcher' not in kwargs and not unsafe:
++self.url_fetcher = (
++lambda *args, **kwargs: b'')
++
+ self.xml_tree = tree
+ root = cssselect2.ElementWrapper.from_xml_root(tree)
+ style = parent.style if parent else css.parse_stylesheets(self, url)
+diff --git a/cairosvg/surface.py b/cairosvg/surface.py
+index c5569e768032..a2f7736aabbe 100644
+--- a/cairosvg/surface.py
 b/cairosvg/surface.py
+@@ -113,7 +113,8 @@ class Surface(object):
+ :param parent_width: The width of the parent container in pixels.
+ :param parent_height: The height of the parent container in pixels.
+ :param scale: The ouptut scaling factor.
+-:param unsafe: A boolean allowing XML entities and very large files
++:param unsafe: A boolean allowing external file access, XML entities
++   and very large files
+(WARNING: vulnerable to XXE attacks and various DoS).
+ 
+ Specifiy the output with:
+-- 
+2.39.2
+
diff -Nru cairosvg-2.5.2/debian/patches/series cairosvg-2.5.2/debian/patches/series
--- cairosvg-2.5.2/debian/patches/series	2021-08-30 22:54:50.0 +0200
+++ cairosvg-2.5.2/debian/patches/series	2023-03-21 22:20:08.0 +0100
@@ -1 +1,2 @@
 0001-Remove-pytest-options-for-plugins-not-packaged-for-D.patch
+Don-t-allow-fetching-external-files-unless-explicitl.patch

Bug#1033337: RM: lvtk -- RoQA; unmaintained, depends on python2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: l...@packages.debian.org
Control: affects -1 + src:lvtk

Please remove lvtk. The last maintainer upload was in 2016, still depends on 
Python
2 and has been removed from testing since 2020.

Bug#1033336: RM: faumachine -- RoQA; RC-buggy, depends on python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: faumach...@packages.debian.org
Control: affects -1 + src:faumachine

Please remove faumachine. It FTBFSes since GCC 9 and still uses Python 2. It 
has been
removed from testing since 2019.

Bug#1033334: Don't include in Bookworm

[Moritz Muehlenhoff]

Source: rust-boxfnonce
Version: 0.1.1-2
Severity: serious

Per https://rustsec.org/advisories/RUSTSEC-2019-0040.html rust-boxfnonce is 
obsolete,
let's keep it out of bookworm (and remove from the archive).

Cheers,
Moritz

Bug#1033335: Don't include in Bookworm

[Moritz Muehlenhoff]

Source: rust-const-cstr
Version: 0.3.0-1
Severity: serious

Hi,
there is https://rustsec.org/advisories/RUSTSEC-2023-0020.html which flags
that rust-const-cstr is unmaintained. Since there are no reverse deps in the
archive, let's exclude it from bookworm (or rather remove rightaway)?

Cheers,
Moritz

Bug#1033333: Don't include in Bookworm

[Moritz Muehlenhoff]

Source: rust-encoding
Version: 0.2.33-1
Severity: serious

Hi,
there is https://rustsec.org/advisories/RUSTSEC-2021-0153.html which flags
that rust-encoding is unmaintained. Since there are no reverse deps in the
archive, let's exclude it from bookworm (or rather remove rightaway)?

Cheers,
Moritz

Bug#1033332: RM: faumachine -- RoQA; unmaintained, depends on Python 2

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: faumach...@packages.debian.org
Control: affects -1 + src:faumachine

Please remove drbdlinks. The last maintainer upload was in 2012, it's
removed from testing for over three years and still depends on Python 2.

Bug#1033325: Bug#1029849: hw-detect: storing firmware information specifically

[Cyril Brulebois]

Cyril Brulebois  (2023-03-22):
> Trying to balance informative header, appearance, and machine-readability
> I'm about to implement something like this when some packages are found:
> 
> #Package Component Reason  
> firmware-linux-nonfree   non-free-firmware modalias
> firmware-realtek non-free-firmware dmesg   
> 
> (I was about to use column -t, but that's bsdextrautils, so I'm using a
> format string with printf, allowing 30-character worth of package name.)
> 
> and otherwise:
> 
> # No firmware/microcode packages deployed by the installer
> 
> which means people can grep -v ^# to get to the actual data (if any) and
> do stuff with it, while humans have a decent-ish table.
> 
> I'm also adding the firmware summary file to the installation report via
> the bug script.
> 
> I'll test this shortly with patched hw-detect and installation-report on
> a netinst ISO, on baremetal then report actual results, instead of the
> mockup above.

Test VM with Realtek Wi-Fi USB adapter shared from the host:

#Package Component   Reason
firmware-realtek non-free-firmware   dmesg
firmware-realtek non-free-firmware   modalias
intel-microcode  non-free-firmware   cpu

Asus Vivobook:

#Package Component   Reason
firmware-realtek non-free-firmware   dmesg
firmware-amd-graphicsnon-free-firmware   modalias
amd64-microcode  non-free-firmware   cpu

Dell G3 15:

#Package Component   Reason
firmware-iwlwifi non-free-firmware   dmesg
firmware-realtek non-free-firmware   dmesg
firmware-iwlwifi non-free-firmware   modalias
firmware-misc-nonfreenon-free-firmware   modalias
firmware-realtek non-free-firmware   modalias
firmware-sof-signed  non-free-firmware   modalias
intel-microcode  non-free-firmware   cpu

I'm deliberately choosing not to duplicate package names.

The only thing I cannot really easily test is the “no firmware or
microcode packages case” since the CPU matching will pull microcode at
the very least:
  
https://salsa.debian.org/installer-team/installation-report/-/commit/2b46263446e838f3965239aa14ed65a64aea49c2#9cef33ed9dfd3270ca2973284679af40ac3e0fe0_22_32


In any case, that file is now included in installation reports, near the
end, and that looks like this:

==
Installer firmware-summary:
==
#Package Component   Reason
firmware-realtek non-free-firmware   dmesg
firmware-realtek non-free-firmware   modalias
intel-microcode  non-free-firmware   cpu


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033331: RM: ruby-omniauth-shibboleth -- ROM; rc-buggy, unmaintained upstream, leaf package

[Pirate Praveen]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ruby-omniauth-shibbol...@packages.debian.org
Control: affects -1 + src:ruby-omniauth-shibboleth
Control: block 999726 by -1

It is affected by rc bug #999726 (incompatible with ruby-omniauth 2.0) 
and unmaintained upstream. It was packaged as a dependency of gitlab 
and from 15.9 gitlab removed this dependency (this patch is backported 
to the version of gitlab in experimental).

Bug#1030249: "prefclean output on ..." emails

[andy]

i have also started receiving email notifications from apt-listbugs and
am +1'ing the suggestion for a knob to turn off all emails.

in my case it seems related to an Acquire::http::Proxy setting.
 * when waking from sleep in a location where the apt-proxy is
   reachable, about 1/2 the time (from a small sample size of 1 laptop
   over a few days) it apparently tries to run before the network is
   available and emails "E: getaddrinfo: Name or service not known
   [...]" (perhaps related to #964438).
 * when in a location where the apt-proxy is not reachable, i receive
   emails every so often re: "E: Connection refused - Connection
   refused".  while a valid complaint this is a known issue that i
   don't need to hear about and would like to be able to turn off.

i am uncertain why these emails seems to have just started in the past
few days. afaik the only possibly relevant change i made was to update
Acquire::http::Proxy to a fqdn. please let me know if you would prefer
a new bug report as this may be only tangentially related to this
particular bug (while solution of an "off switch" is the same).

thanks in advance.

andy

-- 
andy  diatribes

Bug#1033330: rygel: version bump to 0.43.2 major fixes

[useless]

Package: rygel
Version: 0.42.1-1
Severity: normal
X-Debbugs-Cc: usel...@noinfo.com

Dear Maintainer,

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

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

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


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

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

Versions of packages rygel depends on:
ii  init-system-helpers 1.65.2
ii  libc6   2.36-8
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libgee-0.8-20.20.6-1
ii  libges-1.0-01.22.0-2
ii  libglib2.0-02.74.6-1
ii  libgssdp-1.6-0  1.6.2-2
ii  libgstreamer-plugins-base1.0-0  1.22.0-3
ii  libgstreamer1.0-0   1.22.0-2
ii  libgupnp-1.6-0  1.6.3-1
ii  libgupnp-av-1.0-3   0.14.1-1
ii  libgupnp-dlna-3.0-4 0.12.0-3
ii  libmediaart-2.0-0   1.9.6-1
pn  librygel-core-2.8-0 
pn  librygel-db-2.8-0   
pn  librygel-renderer-2.8-0 
pn  librygel-server-2.8-0   
ii  libsoup-3.0-0   3.2.2-2
ii  libsqlite3-03.40.1-2
ii  libx11-62:1.8.4-2
ii  libxml2 2.9.14+dfsg-1.1+b3

Versions of packages rygel recommends:
ii  dbus-user-session  1.14.6-1
ii  gstreamer1.0-libav 1.22.0-2
ii  gstreamer1.0-plugins-base  1.22.0-3
ii  gstreamer1.0-plugins-good  1.22.0-5
ii  gstreamer1.0-plugins-ugly  1.22.0-2

Versions of packages rygel suggests:
pn  rygel-playbin  
pn  rygel-preferences  
pn  rygel-ruih 
pn  rygel-tracker  
pn  tumbler

Bug#1021330: nvidia-cuda-dev appears to break nvidia xorg

[Tim Hanson]

Hi Andreas,

Yes, so far as i can tell, this was resolved with the inclusion of 525
drivers.

Tim

On Wed, Mar 22, 2023 at 3:16 AM Andreas Beckmann  wrote:

> Control: tag -1 moreinfo
>
> On 06/10/2022 02.33, Timothy Hanson wrote:
> > Package: nvidia-cuda-dev
> > Version: 11.5.2-2
>
> > Today ran apt-get upgrade, including updating nvidia-cuda-dev.  The
> update
> > seems to have broken nvidia xorg driver; proximal reason seemsto be that
> it
> > pulls in nvidia-tesla-alternative nvidia-tesla-kernel-dkms
> libnvidia-tesla-
> > cuda1 (and others) which are a conflicting version (510.85.x).  Video
> driver
> > is:
> > ii  nvidia-kernel-dkms
> 470.141.03-2
> > amd64NVIDIA binary kernel module DKMS source
>
> That was probably a transitional issue while upgrading to new driver
> series and/or CUDA tookit. May I assume that this has been solved in the
> current versions (525 driver series, CUDA 11.8)?
>
> Andreas
>

Bug#1033329: Bad symbol versions on 32-bit architectures

[Ben Hutchings]

Source: linux
Version: 6.1.20-1
Severity: important
Tags: upstream patch

On 32-bit architectures, many symbol versions (CRCs) are recorded in
Module.symvers as 0x7fff.

This is a regression, and I have bisected it to the upstream change:

commit f292d875d0dc700b3af0bef04c5abc1dc7b3b62c
Author: Masahiro Yamada 
Date:   Fri May 13 20:39:21 2022 +0900

modpost: extract symbol versions from *.cmd files

modpost now reads CRCs from .*.cmd files, parsing them using strtol().
This is inconsistent with its parsing of Module.symvers and with their
definition as *unsigned* 32-bit values.

strtol() clamps values to [LONG_MIN, LONG_MAX], and when building on a
32-bit system this changes all CRCs >= 0x8000 to be 0x7fff.

Ben.

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

Kernel: Linux 6.1.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From 8a2d6347c9b3caed32c3e8dc4e219f43d9410d01 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Wed, 22 Mar 2023 18:51:42 +0100
Subject: [PATCH] modpost: Fix processing of CRCs on 32-bit build machines

modpost now reads CRCs from .*.cmd files, parsing them using strtol().
This is inconsistent with its parsing of Module.symvers and with their
definition as *unsigned* 32-bit values.

strtol() clamps values to [LONG_MIN, LONG_MAX], and when building on a
32-bit system this changes all CRCs >= 0x8000 to be 0x7fff.

Change extract_crcs_for_object() to use strtoul() instead.

Cc: sta...@vger.kernel.org
Fixes: f292d875d0dc ("modpost: extract symbol versions from *.cmd files")
Signed-off-by: Ben Hutchings 
---
 scripts/mod/modpost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 2c80da0220c3..1dfa80c6b471 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1722,7 +1722,7 @@ static void extract_crcs_for_object(const char *object, 
struct module *mod)
if (!isdigit(*p))
continue;   /* skip this line */
 
-   crc = strtol(p, , 0);
+   crc = strtoul(p, , 0);
if (*p != '\n')
continue;   /* skip this line */
 

Bug#1033311: sysvinit-utils: pidof not always returning a pid, when using the full path to a program

[Mark Hindley]

Control: tags -1 upstream

Jesse,

Thanks for your quick work on this.

On Wed, Mar 22, 2023 at 12:40:43PM -0300, Jesse Smith wrote:
> This has been fixed upstream for the upcoming sysvinit 3.07. Would be
> great to get some people testing it before we do an official reelase of
> the 3.07 branch.
> 
> The updated pidof will now return an PID matches for a corresponding
> executable or symbolic link. In other words, if /tmp/sleep is a symbolic
> link to /usr/bin/sleep, then it doesn't matter which path name we use,
> pidof will recognize both names go to the same real program and print
> its PID.

I have just done a local build of 3.06 with a cherry pick of just this hunk of
b70b2776

diff --git a/src/killall5.c b/src/killall5.c
index 992ce3e1..75750d32 100644
--- a/src/killall5.c
+++ b/src/killall5.c
@@ -763,6 +763,11 @@ PIDQ_HEAD *pidof(char *prog)
add_pid_to_q(q, p);
foundone++;
}
+else if ( (p->argv0) && (! strcmp(p->argv0, prog) ) )
+{
+add_pid_to_q(q, p);
+foundone++;
+}
}
}
 
-- 
2.39.2

The patched version still fails to find a running vi process when run as

 pidof $(which vi)

Is that because there are 2 layers of symlinks?

 /usr/bin/vi ->  /etc/alternatives/vi ->  /usr/bin/vim.basic

Mark

Bug#1033328: basez: typo: witn -> with

[Jakub Wilk]

Package: basez
Version: 1.6.2-1
Severity: minor
Tags: patch

--
Jakub Wilk
--- a/basez.1
+++ b/basez.1
@@ -57,7 +57,7 @@ with equal sign end padding. Appearance
 end of the encoded steam can be avoided by encoding data of size divisible
 by 5. Base32 decoding is case insensitive.
 .PP
-Base32hex encoding works the same way as base32 but witn an alternative
+Base32hex encoding works the same way as base32 but with an alternative
 character\-set [0\-9a\-v] to preserve the encoded data sort order.
 This encoding should not be confused with base32.
 .PP
--- a/basez.c
+++ b/basez.c
@@ -509,7 +509,7 @@ APPNAME
 "by 5. Base32 decoding is case insensitive.\n"
   );
   puts(
-"Base32hex encoding works the same way as base32 but witn an alternative \n"
+"Base32hex encoding works the same way as base32 but with an alternative \n"
 "character-set [0-9a-v] to preserve the encoded data sort order. \n"
 "This encoding should not be confused with base32.\n"
   );

Bug#1022222: valgrind-if-available shouldn't stop providing valgrind on mipsel

[Adam Borowski]

Control: severity -1 normal

(I intended to avoid having to argue by implementing specific objective
tests that valgrind has to meet to be declared available, but I did not
manage to get that done.  Thus, arguing...)

On Sat, Oct 22, 2022 at 12:12:40PM +0300, Adrian Bunk wrote:
> Package: valgrind-if-available
> Severity: serious

> valgrind-if-available (3.18.1-1-1) unstable; urgency=medium
> ...
>   * Drop mipsel as valgrind disagrees about blah blah baseline Loongson.

> This is wrong, and it makes at least qtmir FTBFS.

(as said already elsewhere) Failing to build because valgrind is not
available means you're using the package wrong: it may or may not pull in
valgrind, and the set of architectures can and will change without any
warning.  The whole purpose of this metapackage is to track valgrind's
availability so 100+ individual packages don't need to.

Ie, instead of:
  if arch in (foo bar baz quux)
 build --valgrind=yes
  else
 build --valgrind=no
you do:
  if `which valgrind >/dev/null`
 build --valgrind=yes
  else
 build --valgrind=no

> If there is any problem with valgrind on mipsel
> it should be discussed and resolved in valgrind first,
> if valgrind is available then valgrind-if-available
> has to provide it.

No, this particular problem is that valgrind doesn't work on _some_
mipsel machines.  This doesn't make valgrind itself useless, but makes
it unsuitable for being ran as a part of automated testsuites.

As our buildds appear to be all Loongsons, coding some complex machinery
to detect the subarch at runtime would be a waste of time.  Flat out
saying "disable valgrind tests on mipsel" is easier and works good enough
for now.

> It is also unclear what the baseline problem is this changelog
> entry is referring to, there is no open bug in the valgrind package
> mentioned and the closest I could find was a bug that was fixed (sic)
> 5 years ago.

It fails at least in 3.19 (unstable) and 3.20 (experimental):
https://buildd.debian.org/status/fetch.php?pkg=valgrind-if-available=mipsel=3.19.0-1-1=1667563987=0

==1833049== Memcheck, a memory error detector
==1833049== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1833049== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1833049== Command: /tmp/___
==1833049== 

VEX: Unsupported baseline
 Found: Loongson-baseline
Cannot continue. Good-bye

vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==1833049==at 0x5804FB44: ??? (in 
/usr/libexec/valgrind/memcheck-mips32-linux)
==1833049==by 0x5804FA2C: ??? (in 
/usr/libexec/valgrind/memcheck-mips32-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 1833049)
==1833049==at 0x401B920: __start (in /lib/mipsel-linux-gnu/ld.so.1)
==1833049==by 0x7EB7B088: ???
client stack range: [0x7EB78000 0x7EB7BFFF] client SP: 0x7EB7B090
valgrind stack range: [0x42878000 0x42977FFF] top usage: 5512 of 1048576


It appears that no one, both upstream and _in Debian_, cares enough about
mipsel to fix bugs or even report them, thus I don't expect it to be solved
anytime soon -- or, probably, ever, as mipsel is not long for this world.

But, as the trivial solution would be removing support for mipsel completely
from valgrind, I think users are better served by being provided something
that works on at least _some_ hardware.
 
> It is also suprising if this is really a mipsel-only issue as the
> changelog claims, I would have expected any issues to also show
> up on mips64el.

This very same test works fine on mips64el.

> Therefore please report any issues with valgrind on mipsel as bugs
> against src:valgrind, but in any case please make valgrind-if-available
> always provide valgrind on all architectures where it is available.

Seems we understand "available" differently:
* for you, it means "shipped at all",
* for me, it means "works for a typical set of tasks".

valgrind on mipsel is functional on old hardware but dies even on "hello
world" on Loongson.  I consider this availability to be lacking.


My plans for this bug are:
* s/available/available and functional/ in the description
* run all tests even on marginal archs, but don't fail the build if it's
  an expected failure


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Only flat-earthers have a problem folding a fitted sheet.
⢿⡄⠘⠷⠚⠋⠀ I instead shape it into a ball.
⠈⠳⣄

Bug#1033326: ruby-rails: Rails app using development environment blocks all access with 'Blocked host'

[Max Maton]

Package: ruby-rails
Version: 2:6.0.3.7+dfsg-2+deb11u1
Severity: important
X-Debbugs-Cc: i...@maxmaton.nl, t...@security.debian.org

Dear Maintainer,

Using rails 2:6.0.3.7+dfsg-2+deb11u1 we can no longer run our app using
`RAILS_ENV=development rails s`.
Curling the server (`curl http://127.0.0.1:3000`) results in an error
message:

Blocked host: 127.0.0.1
To allow requests to 127.0.0.1, add the following to your environment 
configuration:

config.hosts << "127.0.0.1"

Adding this configuration setting does not allow connections to go
through. Running the curl command using the package in bullseye works.

I was able to find this online but I'm not sure if it's related: 
https://rubyonrails.org/2021/12/15/Rails-6-0-4-4-and-6-1-4-4-have-been-released
Changelog: 
https://github.com/rails/rails/compare/v6.0.4.3...v6.0.4.4#diff-401b1f2d4b94c52328880f3baca952f374f24903245327fc4c4527d6d5655a0c

Best regards,

Max Maton


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

Kernel: Linux 5.10.0-10-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ruby-rails depends on:
ii  ruby-actioncable  2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actionmailbox2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actionmailer 2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actionpack   2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actiontext   2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-actionview   2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activejob2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activemodel  2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activerecord 2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activestorage2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-activesupport2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-bundler  2.2.5-2
ii  ruby-railties 2:6.0.3.7+dfsg-2+deb11u1
ii  ruby-sprockets-rails  3.2.1-1

ruby-rails recommends no packages.

ruby-rails suggests no packages.

-- no debconf information

Bug#1032914: phog: ships /etc/pam.d/greetd

[duck]

Quack,

On 2023-03-21 18:49, Arnaud Ferraris wrote:


@duck, any comment on the above?


Thanks for the contribution.

Honestly when I read the title I really wondered how phog could have 
ended-up shipping this file. I forgot it initially, was asked about it 
and added it quickly, so it's not like I would have rejected the idea.


Anyway, back to the patch itself. First I wonder if it's useful to ship 
the second PAM config since in the code (greetd/src/server.rs#211) it 
simply use the base greetd PAM configuration as a fallback; this is not 
a blocker though.
Then I would prefer if the changelog entries were shipped with the 
corresponding changes and not in a lump afterwards. Also the "debian:" 
and "d/*:" prefixes are not the style I use. Maybe I'm missing why some 
people still use it but with the VCS taking care of remembering which 
files have been changed I don't feel the need to add this anymore and 
it's not very non-DD friendly. I like your comments to clearly explain 
the rationale.


Regards.
\_o<

--
Marc Dequènes

Bug#1029849: hw-detect: storing firmware information specifically

[Cyril Brulebois]

Control: clone -1 -2
Control: reassign -2 installation-report
Control: retitle -2 installation-report: store and report firmware information

Cyril Brulebois  (2023-01-28):
> hw-detect already has some finish-install hooks, so it would only need
> to generate something like /var/log/installer/firmware-packages from
> it, with “$package $component” on each line?
> 
> And maybe “# no firmware packages” (with a leading # to signal a
> comment), so that people can easily iterate over it if they so wish?

Trying to balance informative header, appearance, and machine-readability
I'm about to implement something like this when some packages are found:

#Package Component Reason  
firmware-linux-nonfree   non-free-firmware modalias
firmware-realtek non-free-firmware dmesg   

(I was about to use column -t, but that's bsdextrautils, so I'm using a
format string with printf, allowing 30-character worth of package name.)

and otherwise:

# No firmware/microcode packages deployed by the installer

which means people can grep -v ^# to get to the actual data (if any) and
do stuff with it, while humans have a decent-ish table.

I'm also adding the firmware summary file to the installation report via
the bug script.

I'll test this shortly with patched hw-detect and installation-report on
a netinst ISO, on baremetal then report actual results, instead of the
mockup above.

> I don't think that's a blocker for the next d-i release, that might be
> considered a blocker for Bookworm though; debian-release@ in Cc can
> comment and raise severity if that's desired.

Cc dropped since we're implementing this right now.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033324: Debian 11 ImageMagicks policy.xml is an invalid xml file

[Jérémie Grauer]

Package: imagemagick
Version: 8:6.9.11.60+dfsg-1.3+deb11u1

The file "/etc/ImageMagick-6/policy.xml" is not a valid xml file because 
line 76 is missing "-->" to close the comment on the same line.
As a result, it creates a comment containing both this line and the next 
one, which makes the comment include "--", which is forbidden in xml.

Reference: https://www.w3.org/TR/REC-xml/#sec-comments
Currently, this prevent automatic tools from parsing this file, since it 
doesn't get validated as a valid xml file.

Bug#999726: ruby-omniauth-shibboleth: FTBFS with ruby-omniauth 2.0.x: ERROR: Test "ruby2.7" failed: Failure/Error: expect(last_response.status).to eq(302)

[Pirate Praveen]

On Tue, 10 May 2022 01:14:01 +0530 Mohd Bilal  
wrote:

> If you feel there's any other
> workaround for this please suggest. The upstream hasn't been active 
and

> I dont think they'll have new version anytime soon

as discussed in 
https://git.fosscommunity.in/debian-ruby/TaskTracker/-/issues/192#note_9797 
we can remove dependency on omniauth-shibboleth from gitlab and request 
removal from archive.


Removing the dependency here 
https://salsa.debian.org/ruby-team/gitlab/-/commit/a7773b9ac08a3c341982129c201d3a254f4561cb


I will file ROM shortly.

Bug#1033323: unblock: radsecproxy/1.9.2-2

[Sven Hartge]

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

Please unblock package radsecproxy

[ Reason ]
Getting the new logcheck rules compatible with new rsyslog format into
Debian Bookworm, preventing a regression on logcheck reporting.

[ Impact ]
logcheck ignore rules will no longer match, creating mails every hour if
logcheck is used, regressing the behavior seen in Debian Bullseye.

[ Tests ]
No automated tests but the packages with the new rules have been running
in production at my employer for the last 4 weeks, working correctly.

[ Risks ]
No risks involved, the core code of the daemon is unchanged from the
1.9.2-1 version, only the logcheck rules have changed.

[ 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 radsecproxy/1.9.2-2
diff -Nru radsecproxy-1.9.2/debian/changelog radsecproxy-1.9.2/debian/changelog
--- radsecproxy-1.9.2/debian/changelog  2023-02-16 14:28:15.0 +0100
+++ radsecproxy-1.9.2/debian/changelog  2023-03-06 16:39:08.0 +0100
@@ -1,3 +1,10 @@
+radsecproxy (1.9.2-2) unstable; urgency=medium
+
+  * Improve logcheck patterns to reduce noise
+  * Make logcheck rules compatible with all syslog timestamp formats
+
+ -- Sven Hartge   Mon, 06 Mar 2023 16:39:08 +0100
+
 radsecproxy (1.9.2-1) unstable; urgency=medium
 
   * New upstream version 1.9.2
diff -Nru radsecproxy-1.9.2/debian/logcheck.ignore.server 
radsecproxy-1.9.2/debian/logcheck.ignore.server
--- radsecproxy-1.9.2/debian/logcheck.ignore.server 2023-02-16 
14:28:15.0 +0100
+++ radsecproxy-1.9.2/debian/logcheck.ignore.server 2023-03-06 
16:39:08.0 +0100
@@ -1,3 +1,4 @@
-^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ radsecproxy\[[[:digit:]]+\]: 
(Accounting-Response|Access-(Accept|Reject)) for user [@._[:alnum:]-]+ 
(stationid [.:[:xdigit:]-]+ )?from [._[:alnum:]-]+( \([[:print:]]+\))? to 
[._[:alnum:]-]+ \([.:[:xdigit:]]+\)$
-^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ radsecproxy\[[[:digit:]]+\]: 
Access-Accept \(response to Status-Server\) from [._[:alnum:]-]+ to 
[._[:alnum:]-]+ \([.:[:xdigit:]]+\)$
-^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ radsecproxy\[[[:digit:]]+\]: replyh: 
got status server response from [._[:alnum:]-]+$
+^(\w{3} [ :0-9]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ 
radsecproxy\[[[:digit:]]+\]: (Accounting-Response|Access-(Accept|Reject)) for 
user [@._[:alnum:]-]+ (stationid [.:[:xdigit:]-]+ )?from [._[:alnum:]-]+( 
\([[:print:]]+\))? to [._[:alnum:]-]+ \([.:[:xdigit:]]+\)( operator 
[[:print:]]+)?$
+^(\w{3} [ :0-9]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ 
radsecproxy\[[[:digit:]]+\]: Access-Accept \(response to Status-Server\) from 
[._[:alnum:]-]+ to [._[:alnum:]-]+ \([.:[:xdigit:]]+\)( operator 
[._[:alnum:]-]+)?$
+^(\w{3} [ :0-9]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ 
radsecproxy\[[[:digit:]]+\]: replyh: got status server response from 
[._[:alnum:]-]+$
+^(\w{3} [ :0-9]{11}|[0-9T:.+-]{32}) [._[:alnum:]-]+ 
radsecproxy\[[[:digit:]]+\]: missing response to Access-Request for user 
[@._[:alnum:]-]+ (stationid [.:[:xdigit:]-]+ )?from [._[:alnum:]-]+ 
\([.:[:xdigit:]]+\) to [._[:alnum:]-]+$

Bug#1032412: no message at dual screen

[Gert van de Kraats]

I have the same problem at dual screen with sizes 1280 x 1024 and 1280 x 
800.


New debian-logo tries to write the message "resuming from hibernation" 
below borh screens.


This is caused by wrong computation of max height.

In my case it computes 2 * 112 + 1024, which should be only 1024.

.Problem occurs at /usr/share/plymouth/themes/emerald/emerald.script.

Next patch solves the problem for me :diff --git 
a/emerald-theme/plymouth/emerald.script 
b/emerald-theme/plymouth/emerald.script


--- a/desktop-base-12.0.5/emerald-theme/plymouth/emerald.script
+++ b/desktop-base-12.0.5_b/emerald-theme/plymouth/emerald.script
@@ -119,7 +119,8 @@ fun TextYOffset() {
 #Debug("y = " + y);

 text_height = first_line_height * 7.5;
-    min_height = window_max.height - 2 * first_line_height;
+    # subtract Window.GetY() to show info also at smallest of dual srceens
+    min_height = window_max.height - 2 * first_line_height - Window.GetY();
 #Debug("text_height=" + text_height + "; min_height=" + min_height);

 if (y + text_height > min_height)
@@ -131,8 +132,8 @@ fun TextYOffset() {

 #- Screen/window setup 
---

 # Compute screen/image ratio and scale the background accordingly
-window_max.width = Window.GetX() * 2 + Window.GetWidth();
-window_max.height = Window.GetY() * 2 + Window.GetHeight();
+window_max.width = Window.GetWidth();
+window_max.height = Window.GetHeight();
 screen_ratio = window_max.width / window_max.height;
 small_dimension = Math.Min(window_max.width, window_max.height);
 #Debug("Window.GetX():" + Window.GetX() + ", Window.GetY():" + 
Window.GetY());

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Jesse Smith]

On 2023-03-22 8:31 a.m., Mark Hindley wrote:
> Markus,
>
> Thanks for this.
>
> On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote:
>> Package: sysvinit-utils
>> Version: 3.06-2
>> Severity: normal
>> X-Debbugs-Cc: none
>>
>> Dear Maintainer,
>>
>> Passing the full path of a binary to the pidof command does not always
>> return a pid although the process is running and the man page of the
>> pidof command explicitly notes that it can be used that way.
>>
>> This might be related to the fact that all programs with which I tested
>> this and which show this unexpected behaviour were symlinks (i.e.,
>> "which " returned a symlink).
> Yes, I just tried with vim.basic which is not a symlink on my system and both
>
>  pidof vim.basic
>  pidof $(which vim.basic)
>
> work as expected.
>
>> However, on Debian Bullseye the
>> behaviour is as I expected it.
> So this appears to be a change in behaviour. I suspect this is an inadvertent
> side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e.
>
> Jesse, or was it intentional?
>


I made a fix for this and have pushed it to the 3.07 branch of the SysV
init repository. I'll publish a new version in a couple of days with
this fix. There were some other changes to killall5 which are also in
the queue, so this will fix a few issues.

Would be great to have someone check the updated pidof and report if
it's working okay for them too.

- Jesse

Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

[Salvatore Bonaccorso]

Hi,

On Sun, Feb 19, 2023 at 07:39:02PM +0100, Cyril Brulebois wrote:
> Package: preseed
> Version: 1.113
> Severity: normal
> X-Debbugs-Cc: Salvatore Bonaccorso 
> 
> Filing this against preseed for visibility, after Salvatore Bonaccorso
> reported that D-I Bookworm Alpha 1 was dealing with preseeding
> hostname=foo just fine, and that it's no longer the case with D-I
> Bookworm Alpha 2: the hostname question is asked, with either the
> default value (“debian”) or a value determined from the DHCP hostname
> (if any).
> 
> The relevant code didn't change on the installer side, but Linux
> mainline got a relevant commit: 5a704629f2 (first released in v6.0-rc1):
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a704629f2c1ba33bbb444cb18e6957e97c76e8f
> 
> At first glance, a side effect is that the kernel seems to “eat” the
> hostname=foo parameter instead of leaving it alone as it did in earlier
> versions, possibly hiding it from the installer:
> 
>   -Unknown kernel command line parameters "--- 
> BOOT_IMAGE=/install.amd/vmlinuz vga=788 hostname=miaou", will be passed to 
> userspace
>   +Unknown kernel command line parameters "--- 
> BOOT_IMAGE=/install.amd/vmlinuz vga=788", will be passed to userspace
> 
> 
> Now, parameters might be added before or after the '---' marker, and
> moving hostname=foo from after to before this marker makes this issue go
> away.
> 
> Checking the story behind that marker, i.e. debian-installer-utils
> version 1.109 first published in jessie to fix #762007, I'm not sure
> what to think about it… A cursory look at it suggests parameters found
> after that marker should be visible to both the installer and the
> kernel, but that's not the case here.
> 
> Looking at the user-space side, I'm still seeing “hostname=foo” at the
> end of /proc/cmdline, but calling user-params only returns “quiet”, and
> that's the case for both D-I Bookworm Alpha 1 and Alpha 2. Both images
> have the same /etc/preseed_aliases, which dictates what user-params
> does.
> 
> 
> Adding DEBCONF_DEBUG=developer on the kernel command line, searching for
> lines with “cdebconf” and “hostname”, the big difference is that line,
> only in Alpha 1:
> 
>   debconf: Adding [ID] -> [netcfg/get_hostname]
> 
> It happens early in the boot process (at start-up), and that comes from
> debconf's question_variable_add() function. Right after that, there's an
> extra “frontend” line (not “cdebconf” this time) marking that question
> as seen, which means the hostname prompt is skipped down the line.
> 
> Why the difference? The actual consequence of the Linux change is not in
> /proc/cmdline or user-params or preseed, it's just just about early
> start-up: /init is run without hostname=foo in its environment, which
> explains why the debconf preseeding is no longer happening.
> 
> 
> I'm not sure where to go from here though. Compensate for this change by
> adding a special case for this parameter in env2debconf? The existing
> code seems unfriendly enough as it is… maybe implement /proc/cmdline
> lookup from netcfg instead? Not doing anything? All three options seem
> suboptimal to me…

First, this was a real use case which triggered noticing the issue
with the D-I Bookworm Alpha 1 while doing some pre-testing. 

But if there is no reasy technical way to continue having the
hostname alias support for preseed, would a pracmatic solution be to
drop support for the hostname= alias, cleanup as well the
documentation on it, and have people use the longer
netcfg/get_hostname instead?

Regards,
Salvatore

Bug#1033035: hw-detect: trivial patches

[Cyril Brulebois]

Pascal Hambourg  (2023-03-17):
> On 16/03/2023 at 21:09, Cyril Brulebois wrote:
> > OK, this might be fixing an actual issue.
> 
> Attached patches v2 with more descriptions and which apply without the
> other rejected patches. Thank you for all the useful comments.

Thanks, merged. Feel free to tweak the changelog entry as you see fit.

The /target/tmp thing was self-fixing so never noticed… but the Package
thing I would have noticed/fixed while working on the firmware summary
thing (which is what I'm about to do, and reminded me I had stuff to
merge…).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Markus Fischer]

I just could reproduce another case where pidof with the argument being 
a full path to a binary doesn't return a pid. It is not related to the 
argument being a symlink.


This time it seems to be related to the program having been started with 
arguments but I don't see the unexpected behaviour with just any 
arguments, just some.


For example, when having gdb running with "gdb --core=corefile" "pidof 
$(which gdb)" does not return a pid but when I start gdb with "gdb 
--quiet" "pidof $(which gdb)" behaves as expected.

Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed

[Lee Garrett]

On Sat, 18 Mar 2023 17:06:08 +0100 Dominique Dumont  wrote:

On Tue, 14 Feb 2023 22:21:26 +0100 Lee Garrett  wrote:
> Bumped severity as this makes bts currently unusable, and probably 
> breaks for quite a few DDs their workflow.


This does not break on my system where bts is connected to local sendmail 
(which is the default setup).

Which hints at a workaround: have bts connect to local sendmail and have 
sendmail forward the mail to the SMTPS server.


While this setup might work for some people, this has IMHO quite a few hefty 
drawbacks and requires me to maintain a MTA on my local machine. I could 
elaborate, but I don't think it's on-topic for this bug report.




The change mentioned by Daniel affects only a setup where the host if 
configured via its IP address, not via a host name:
See the change in SSL.pm in commit 
https://github.com/noxxi/p5-io-socket-ssl/commit/c0a063b70f0a3ad033da0a51923c65bd2ff118a0


While Daniel did mention this commit (which might or might not be related to the 
issue), bts fails on a configured SMTPS hostname which otherwise correctly 
validates with other MUA.




Which is not the case here:

$ perl -S -MDevel::SimpleTrace bts --smtp-host smtps://mail.wgdd.de usertag 
1029588 + dod-test-with-tls
bts: failed to open SMTPS connection to smtps://mail.wgdd.de
(hostname verification failed)
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(/usr/bin/bts:2839)
at main::(/usr/bin/bts:825)

Unfortunately, I can no longer investigate this issue as it looks like that my 
IP address is now blacklisted on Daniel's server:

$ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de 
usertag 1029588 + dod-test-with-tls
bts.pl: failed to open SMTPS connection to smtps://mail.wgdd.de
(Connection refused)
at main::send_mail(mail.wgdd.de)
at main::mailbtsall(scripts/bts.pl:2849)
at main::(scripts/bts.pl:834)

On a hunch, I would guess that Daniel's server is configured to handle STARTTLS, which is not supported by bts. But I cannot verify this. 
In any case this does not explain why Daniel sees bts working with libio-socket-ssl-perl 2.077 but not with 2.078.


I'm sure that bts supports STARTTLS. I am using bts with my MTA on 587/tcp, 
which enforces STARTTLS and requires credentials (I just double-checked via 
swaks). With the old libio-socket-ssl-perl 2.069-1 this works, so it's clearly a 
regression.




All the best


Greetings,
Lee

Bug#1033322: Please create a new WebAssembly section

[Faidon Liambotis]

Package: ftp.debian.org
Severity: wishlist

I'm about to upload WasmEdge (ITP #1003128), a WebAssembly runtime.

The "wasmedge" binary package is the runtime (think JRE in Java terms),
so Section: devel is not very appropriate. I've set the source package
and the wasmedge package to Section: web for the time being, but that
doesn't feel like a complete match either.

WebAssembly[1] is an entire ecosystem, and especially with efforts such
as WASI[2] it now operates outside the confines of browsers and the web.

I think it'd be valuable to have a Section: webassembly, so that
runtimes and other software that are not strictly for development
purposes can fit in.

Thanks for the consideration,
Faidon

1: https://en.wikipedia.org/wiki/WebAssembly
2: https://wasi.dev/

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Jesse Smith]

On 2023-03-22 8:31 a.m., Mark Hindley wrote:
> Markus,
>
> Thanks for this.
>
> On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote:
>> Package: sysvinit-utils
>> Version: 3.06-2
>> Severity: normal
>> X-Debbugs-Cc: none
>>
>> Dear Maintainer,
>>
>> Passing the full path of a binary to the pidof command does not always
>> return a pid although the process is running and the man page of the
>> pidof command explicitly notes that it can be used that way.
>>
>> This might be related to the fact that all programs with which I tested
>> this and which show this unexpected behaviour were symlinks (i.e.,
>> "which " returned a symlink).
> Yes, I just tried with vim.basic which is not a symlink on my system and both
>
>  pidof vim.basic
>  pidof $(which vim.basic)
>
> work as expected.
>
>> However, on Debian Bullseye the
>> behaviour is as I expected it.
> So this appears to be a change in behaviour. I suspect this is an inadvertent
> side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e.
>
> Jesse, or was it intentional?
>
It's a side-effect of the attempt to make pidof less prone to hanging
when checking sleeping processes and zombies. I'll look into it as the
symlink should probably work, or at least we should issue a warning.

- Jesse

Bug#1019643: ruby-omniauth-oauth2-generic: FTBFS with ruby3.1: ERROR: Test "ruby3.0" failed: Failure/Error: expect(last_response.headers["Location"]).to match(%r{redirect_uri=https%3A%2F%2Fmy_se

[Pirate Praveen]

Control: forwarded -1 
https://gitlab.com/satorix/omniauth-oauth2-generic/-/issues/37


On Mon, 12 Sep 2022 22:08:30 -0300 Antonio Terceiro 
 wrote:
> We are about to start the ruby3.1 transition in unstable. While 
trying to

> rebuild ruby-omniauth-oauth2-generic with ruby3.1 enabled, the build
> failed. This does not look related to ruby3.1 though, as the failure
> happens yet at the ruby3.0 tests.

This looks like a test only failure as gitlab confirmed everything 
works with ruby 3.0 here 
https://gitlab.com/gitlab-org/gitlab/-/issues/386908


The upstream seems inactive though, still reported as 
https://gitlab.com/satorix/omniauth-oauth2-generic/-/issues/37

Bug#1032655: psi-plus segfaults

[Lee Garrett]

On 12.03.23 00:35, Stefan Kropp wrote:

On Fri, Mar 10, 2023 at 03:45:38PM +0100, Lee Garrett wrote:

psi-plus currently simply segfaults on a stock bookworm installation:

$ psi-plus
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
Segmentation fault


On my bookworm system, I also get libpng warnings, but no segfault.

Maybe a backtrace in gdb can help to get more information.


the bug was originally reported by a user on IRC, and I could confirm that I'm 
seeing the same as them, so I'm assuming that some portion of users are affected 
(and it's not just something broken on my system). I think it should be 
reproducible in a minimal bookworm gnome VM.


backtrace below:

$ gdb psi-plus
GNU gdb (Debian 13.1-2) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from psi-plus...
(No debugging symbols found in psi-plus)
(gdb) run
Starting program: /usr/bin/psi-plus
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x716956c0 (LWP 102344)]
[New Thread 0x70e946c0 (LWP 102345)]
[New Thread 0x7fffebfff6c0 (LWP 102346)]
[New Thread 0x7fffeb7fe6c0 (LWP 102347)]
[New Thread 0x7fffeaffd6c0 (LWP 102348)]
[New Thread 0x7fffea7fc6c0 (LWP 102349)]
[New Thread 0x7fffe9ffb6c0 (LWP 102350)]
[Detaching after fork from child process 102351]
[Detaching after fork from child process 102352]
[Detaching after fork from child process 102354]
[Detaching after fork from child process 102355]
[Detaching after fork from child process 102357]
[New Thread 0x7fffe91ff6c0 (LWP 102358)]
[New Thread 0x7fffe89fe6c0 (LWP 102359)]
[20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)


Thread 1 "psi-plus" received signal SIGSEGV, Segmentation fault.
0x77e94a4d in XInternAtoms () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) where
#0  0x77e94a4d in XInternAtoms () from /lib/x86_64-linux-gnu/libX11.so.6
#1  0x55918223 in X11WindowSystem::X11WindowSystem() ()
#2  0x55918805 in X11WindowSystem::instance() ()
#3  0x559e1884 in MainWin::MainWin(bool, bool, PsiCon*) ()
#4  0x558b5ba2 in PsiCon::init() ()
#5  0x559d36b6 in PsiMain::sessionStart() ()
#6  0x770dd6f0 in QObject::event(QEvent*) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x76362fae in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x770b16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x770b4681 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5

#10 0x7710a153 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7551e7a9 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0

#12 0x7551ea38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7551eacc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x77109836 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x770b017b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x770b82d6 in QCoreApplication::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5

#17 0x557e4e95 in main ()
(gdb) list
1   ../sysdeps/unix/sysv/linux/dl-vdso-setup.c: No such file or directory.
(gdb)

Regards,
Lee

Bug#1033321: initramfs-tools-core: fsck.zfs missing from initrd when root filesystem on ZFS

[Alexis Huxley]

Package: initramfs-tools-core
Version: 0.142
Severity: normal
Tags: patch

With a root filesystem on ZFS then mkinitramfs builds an initrd that
lacks fsck.zfs:

testaroli# mkinitramfs -o /boot/initrd.img-$(uname -r)
W: Couldn't identify type of root file system for fsck hook
testaroli# zstdcat /boot/initrd.img-$(uname -r) | cpio -itv | grep fsck
381518 blocks
testaroli# 

I'm sure this patch will break more than it fixes, but at least it
worked for me and writing it here may help others in the short-term:

I edited /usr/share/initramfs-tools/hooks/fsck, located the code block:

...
if [ "${MNT_DIR}" = "/" ] || [ "${MNT_TYPE}" = "auto" ]; then
MNT_FSNAME="$(resolve_device "${MNT_FSNAME}")"
fstype() { "/usr/lib/klibc/bin/fstype" "$@"; }
if ! get_fstype "${MNT_FSNAME}"; then
echo "W: Couldn't identify type of $2 file system for fsck 
hook" >&2
fi
unset -f fstype
else
...

and replaced it with:

...
if [ "${MNT_DIR}" = "/" ] || [ "${MNT_TYPE}" = "auto" ]; then
mount | sed -rn "s@.* on $MNT_DIR type ([^ ]+) \\(.*@\\1@p"
else
...

(I.e. the body of the 'then' clause is replaced.)

After which rerunning the above test produced:

testaroli# mkinitramfs -o /boot/initrd.img-$(uname -r)
testaroli# zstdcat /boot/initrd.img-$(uname -r) | cpio -itv | grep fsck
-rwxr-xr-x   1 root root55664 Feb 13 03:48 usr/sbin/fsck
-rwxr-xr-x   1 root root  762 Feb 25 23:32 usr/sbin/fsck.zfs
381657 blocks
testaroli# 

This might actually be *two* bugs in
two different packages (initramfs-tools-core because
/usr/share/initramfs-tools/hooks/fsck produces an ugly warning when
root filesysem is on ZFS; zfs-initramfs because it doesn't drop a
hook into /usr/share/initramfs-tools/hooks to get fsck.zfs included)
but certainly you know what is most appropriate better than I do.

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

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

Versions of packages initramfs-tools-core depends on:
ii  coreutils9.1-1
ii  cpio 2.13+dfsg-7.1
ii  e2fsprogs1.46.6-1
ii  klibc-utils  2.0.12-1
ii  kmod 30+20221128-1
ii  logsave  1.46.6-1
ii  udev 252.6-1

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.35.0-4+b2
ii  zstd 1.5.4+dfsg2-3

Versions of packages initramfs-tools-core suggests:
pn  bash-completion  

-- no debconf information

Bug#1033296: Acknowledgement (RFP: yabsm -- a btrfs snapshot manager and backup system)

[Nicholas Hubbard]

Version 3.15.1 was released, which fixed a problem with compatibility
with Perl version 5.34.0.
"Debian Bug Tracking System"  writes:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1033296: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033296.
>
> 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.
>
> Your message has been sent to the package maintainer(s):
>  w...@debian.org
>
> If you wish to submit further information on this problem, please
> send it to 1033...@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.


-- 
Nicholas Hubbard

Bug#1005886: debian-cd: bookworm net-install CD hangs on "Detecting Network Hardware"

[Cyril Brulebois]

Control: severity -1 important

James Addison  (2023-03-22):
> Followup-For: Bug #1005886
> X-Debbugs-Cc: powe...@gmail.com
> Control: reassign -1 cdimage.debian.org
> Control: retitle -1 cdimage.debian.org: bookworm net-install CD hangs on 
> "Detecting Network Hardware"
> 
> Sorry (both to you Tony, and also the Debian CD team) for confusion and 
> wasting
> time - I mistakenly reassigned this previously.  I've checked the list of
> bug-tracking pseudo-packages[1] and I do think that cdimage.debian.org is the
> correct package for this bug to be assigned to.

Hi Tony,

Please attach /var/log/syslog (compressed).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

[Cyril Brulebois]

Dennis van Dok  (2023-03-22):
> Tested and the touchpad is now functional. The pointer moves as
> expected. Tapping on the pad does not translate to mouse clicks, but
> the touchpad buttons work correctly.
> 
> Tap-to-click is a feature of the driver that I find annoying and
> normally leave off, but I'm not sure that should be the default for
> the installer. I have no real opinion on that, I just thought it was
> worth mentioning that it behaves that way.

Many thanks for confirming.

The installer will use whatever is implemented by the X driver, and I don't
anticipate us diverting from the default settings, unless absolutely needed.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Mark Hindley]

Markus,

Thanks for this.

On Wed, Mar 22, 2023 at 08:40:20AM +0100, Markus Fischer wrote:
> Package: sysvinit-utils
> Version: 3.06-2
> Severity: normal
> X-Debbugs-Cc: none
> 
> Dear Maintainer,
> 
> Passing the full path of a binary to the pidof command does not always
> return a pid although the process is running and the man page of the
> pidof command explicitly notes that it can be used that way.
> 
> This might be related to the fact that all programs with which I tested
> this and which show this unexpected behaviour were symlinks (i.e.,
> "which " returned a symlink).

Yes, I just tried with vim.basic which is not a symlink on my system and both

 pidof vim.basic
 pidof $(which vim.basic)

work as expected.

> However, on Debian Bullseye the
> behaviour is as I expected it.

So this appears to be a change in behaviour. I suspect this is an inadvertent
side-effect of 0b695c7e0b1cac60ed77c56f224e296f023b652e.

Jesse, or was it intentional?

Thanks

Mark

Bug#1033320: HTML5 "autofocus" tag for input element in dillo

[Alain Knaff]

Package: dillo
Version: 3.0.5-7

Hi,

[Sorry for not submitting this upstream, but apparently dillo.org's mail 
server is no longer accepting mails for the dillo.org domain.]

The attached patch adds support for HTML5's autofocus tag to Dillo: this 
allows to automatically focus certain input fields as soon as the page 
with the form loads. We're using this to implement a barcode scanner on 
a raspberry pi 3, so that the browser is immediately ready to scan, 
without a need to touch into the input field first.

Thanks,

-- 
Alain Knaff
Ingénieur Informaticien

LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère de l'Environnement, du Climat et du Développement durable
Administration de l'environnement

1, avenue du Rock'n'Roll . L-4361 Esch-sur-Alzette
Tél. (+352) 40 56 56-309
E-Mail: alain.kn...@aev.etat.lu
www.emwelt.lu . www.environnement.public.lu . www.luxembourg.lu
diff -ur dillo-3.0.5.orig/dw/fltkplatform.cc dillo-3.0.5/dw/fltkplatform.cc
--- dillo-3.0.5.orig/dw/fltkplatform.cc	2015-06-10 23:48:53.0 +0200
+++ dillo-3.0.5/dw/fltkplatform.cc	2023-03-18 12:41:21.910464773 +0100
@@ -370,6 +370,10 @@
 {
 }
 
+void FltkView::focusFltkWidget (Fl_Widget *widget)
+{
+}
+
 void FltkView::allocateFltkWidget (Fl_Widget *widget,
core::Allocation *allocation)
 {
diff -ur dillo-3.0.5.orig/dw/fltkplatform.hh dillo-3.0.5/dw/fltkplatform.hh
--- dillo-3.0.5.orig/dw/fltkplatform.hh	2015-06-30 16:06:08.0 +0200
+++ dillo-3.0.5/dw/fltkplatform.hh	2023-03-18 12:46:12.542094720 +0100
@@ -86,6 +86,7 @@
virtual void allocateFltkWidget (Fl_Widget *widget,
 core::Allocation *allocation);
virtual void drawFltkWidget (Fl_Widget *widget, core::Rectangle *area);
+   virtual void focusFltkWidget (Fl_Widget *widget);
 };
 
 
diff -ur dillo-3.0.5.orig/dw/fltkui.cc dillo-3.0.5/dw/fltkui.cc
--- dillo-3.0.5.orig/dw/fltkui.cc	2015-06-30 16:06:08.0 +0200
+++ dillo-3.0.5/dw/fltkui.cc	2023-03-18 12:33:36.914259944 +0100
@@ -460,6 +460,11 @@
this->view = NULL;
 }
 
+void FltkResource::focus ()
+{
+view->focusFltkWidget (widget);
+}
+	
 void FltkResource::sizeAllocate (core::Allocation *allocation)
 {
this->allocation = *allocation;
@@ -574,6 +579,11 @@
FltkResource::setEnabled (enabled);
 }
 
+template  void FltkSpecificResource::focus ()
+{
+   FltkResource::focus ();
+}
+	
 // --
 
 class EnterButton : public Fl_Button {
diff -ur dillo-3.0.5.orig/dw/fltkui.hh dillo-3.0.5/dw/fltkui.hh
--- dillo-3.0.5.orig/dw/fltkui.hh	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/fltkui.hh	2023-03-18 12:38:41.898264236 +0100
@@ -217,6 +217,8 @@
 
bool isEnabled ();
void setEnabled (bool enabled);
+
+   void focus ();
 };
 
 
@@ -232,6 +234,8 @@
 
bool isEnabled ();
void setEnabled (bool enabled);
+
+   void focus ();
 };
 
 
diff -ur dillo-3.0.5.orig/dw/fltkviewbase.cc dillo-3.0.5/dw/fltkviewbase.cc
--- dillo-3.0.5.orig/dw/fltkviewbase.cc	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/fltkviewbase.cc	2023-03-18 12:18:12.234001790 +0100
@@ -711,6 +711,12 @@
add (widget);
 }
 
+void FltkWidgetView::focusFltkWidget (Fl_Widget *widget)
+{
+	focused_child=widget;
+	widget->take_focus();
+}
+
 void FltkWidgetView::removeFltkWidget (Fl_Widget *widget)
 {
remove (widget);
diff -ur dillo-3.0.5.orig/dw/fltkviewbase.hh dillo-3.0.5/dw/fltkviewbase.hh
--- dillo-3.0.5.orig/dw/fltkviewbase.hh	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/fltkviewbase.hh	2023-03-18 12:39:07.514936690 +0100
@@ -132,6 +132,7 @@
void allocateFltkWidget (Fl_Widget *widget,
 core::Allocation *allocation);
void drawFltkWidget (Fl_Widget *widget, core::Rectangle *area);
+   void focusFltkWidget (Fl_Widget *widget);
 };
 
 } // namespace fltk
diff -ur dillo-3.0.5.orig/dw/ui.cc dillo-3.0.5/dw/ui.cc
--- dillo-3.0.5.orig/dw/ui.cc	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/ui.cc	2023-03-18 12:41:55.403344022 +0100
@@ -223,6 +223,10 @@
 {
 }
 
+void Resource::focus ()
+{
+}
+	
 void Resource::emitEnter ()
 {
activateEmitter.emitEnter(this);
diff -ur dillo-3.0.5.orig/dw/ui.hh dillo-3.0.5/dw/ui.hh
--- dillo-3.0.5.orig/dw/ui.hh	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/dw/ui.hh	2023-03-18 12:33:20.465828321 +0100
@@ -347,6 +347,8 @@
virtual bool isEnabled () = 0;
virtual void setEnabled (bool enabled) = 0;
 
+   virtual void focus () = 0;
+
inline void connectActivate (ActivateReceiver *receiver) {
   activateEmitter.connectActivate (receiver); }
inline void connectClicked (ClickedReceiver *receiver) {
diff -ur dillo-3.0.5.orig/src/form.cc dillo-3.0.5/src/form.cc
--- dillo-3.0.5.orig/src/form.cc	2015-06-30 16:06:09.0 +0200
+++ dillo-3.0.5/src/form.cc	2023-03-18 12:40:04.192424547 +0100
@@ -431,7 +431,7 @@
DilloHtmlInputType inp_type;
Resource *resource = NULL;
Embed 

Bug#1005886: debian-cd: bookworm net-install CD hangs on "Detecting Network Hardware"

[James Addison]

Followup-For: Bug #1005886
X-Debbugs-Cc: powe...@gmail.com
Control: reassign -1 cdimage.debian.org
Control: retitle -1 cdimage.debian.org: bookworm net-install CD hangs on 
"Detecting Network Hardware"

Sorry (both to you Tony, and also the Debian CD team) for confusion and wasting
time - I mistakenly reassigned this previously.  I've checked the list of
bug-tracking pseudo-packages[1] and I do think that cdimage.debian.org is the
correct package for this bug to be assigned to.

[1] - https://www.debian.org/Bugs/pseudo-packages

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Frédéric Bonnard]

Thanks Cyril.
Another important detail ... I only get that behavior in qemu in
graphical mode.
On LPARs there is no issue. I didn't try on baremetal so far.

F.

On Tue, 21 Mar 2023 17:44:49 +0100 Cyril Brulebois  wrote:
> Frédéric Bonnard  (2023-03-17):
> > > It would be helpful to confirm which exact kernel version is getting
> > > used in both cases (last 6.1.0-4 working, and first 6.1.0-5 not
> > > working), then look at the changes between both versions, in src:linux
> > > (and resulting udebs).
> > 
> > From linux changelog (
> > https://tracker.debian.org/media/packages/l/linux/changelog-6.1.15-1 )
> > and http://snapshot.debian.org/package/linux/,
> > I see :
> > 6.1.11-1 -> Bump ABI to 4 
> > http://snapshot.debian.org/archive/debian/20230211T151657Z/
> > 6.1.12-1 -> Bump ABI to 5 
> > http://snapshot.debian.org/archive/debian/20230217T033139Z/
> > 
> > and tested from those (rebuilding the same d-i source with the 2 kernels
> > from snapshot.d.o . 6.1.12-1 clearly doesn't work.
> > I had already have a look at the kernel changelog but missed that one :
> > ---
> > linux (6.1.12-1) unstable; urgency=medium
> > ...
> > - of: Make OF framebuffer device names unique
> > ...
> > ---
> > 
> > I recompiled the kernel deb source without that one (
> > https://github.com/torvalds/linux/commit/241d2fb56a18473af5f2ff0d512992a996eb64dd.patch
> > ) and the mini.iso actually made it to the menu... and given the
> > behaviour, a framebuffer actually makes sense.
> > 
> > Now, that patch does not harm when the kernel is installed on disk.
> > But it does in the installer...
> 
> Adding the kernel team to the loop: d-i regression on ppc64el.
> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1033319: Suggestions for ReleaseCheckList

[Adrian Bunk]

Package: release.debian.org
Severity: normal

Suggestions for both
https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList
https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/BookwormCheckList


  Before the release

Add "Notify the LTS team of the new debian-archive-keyring"


  After the release
[ ] Propose a micronews item on the #debian-publicity IRC channel

Should this be a subitem of "Notify the publicity team"
in "While Releasing"?


  After the release
[ ] Update the Project History document and upload to stable-p-u

This could be moved to (and uploaded) "Before the release".


  After the release
[ ] Check with udd maintainers that the hardcoded values are updated (see 
SuitesAndReposExtension#udd)
[ ] Check with buildd team that buildds know about trixie. (see 
SuitesAndReposExtension#wanna-build)

IMHO these should be moved to "Before the release", otherwise there might be
stress for people who realize at short notice that urgent work has to be done.


  After the release
[ ] Check with other service/package maintainers that all the other 
hardcoded suite names or codenames are updated

IMHO this should be moved to "Before the release", otherwise there might be
stress for people who realize at short notice that urgent work has to be done.

It should link to SuitesAndReposExtension, or be replaced with a list whom to 
notify,

Bug#1033318: subversion: manual page for svnserve is outdated

[Andrius Merkys]

Package: subversion
Version: 1.14.2-4

Hello,

Manual page for svnserve is outdated. It at least should contain 
'--log-file' CLI option which is seen in the output of 'svnserve 
--help'. This issue is present at least since Debian buster.


Andrius

Bug#1033317: unblock: linphone/5.1.65-4

[Bernhard Schmidt]

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

Please unblock package linphone

[ Reason ]
Two important bugs have been resolved

* Disable behind-the-scenes download of the AppImage (Closes: #1031771).
* Update documentation to highlight limitations in linphonec CLI utility
  and to properly explain how to create an initial ~/.linphonerc file
  (Closes: #1032051).

[ Impact ]
linphone will attempt to self-update by downloading a newer AppImage
version, which is upstream's preferred way of distributing linphone

The second change is documentary only and will update README.Debian and
the manpage to explain about the configuration migration logic in
linphone (CLI) vs. linphone-desktop.

[ Tests ]
No automatic tests, patches have been prepared by Dennis who has been
maintaining linphone with an excellent quality in mind.

Version has been in unstable for two weeks now

[ Risks ]
Patch has been tested and could easily be backed out if necessary

[ 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 linphone/5.1.65-4
diff -Nru linphone-5.1.65/debian/changelog linphone-5.1.65/debian/changelog
--- linphone-5.1.65/debian/changelog2023-01-21 09:21:53.0 +0100
+++ linphone-5.1.65/debian/changelog2023-03-02 20:10:59.0 +0100
@@ -1,3 +1,12 @@
+linphone (5.1.65-4) unstable; urgency=medium
+
+  * Disable behind-the-scenes download of the AppImage (Closes: #1031771).
+  * Update documentation to highlight limitations in linphonec CLI utility
+and to properly explain how to create an initial ~/.linphonerc file
+(Closes: #1032051).
+
+ -- Dennis Filder   Thu, 02 Mar 2023 20:10:59 +0100
+
 linphone (5.1.65-3) unstable; urgency=medium
 
   * Port wrappers/cpp/genwrapper.py to Python 3.11 (Closes: #1029253).
diff -Nru linphone-5.1.65/debian/linphone-cli.README.Debian 
linphone-5.1.65/debian/linphone-cli.README.Debian
--- linphone-5.1.65/debian/linphone-cli.README.Debian   1970-01-01 
01:00:00.0 +0100
+++ linphone-5.1.65/debian/linphone-cli.README.Debian   2023-03-02 
20:10:59.0 +0100
@@ -0,0 +1,24 @@
+Debian-specific information
+===
+
+linphonec by default erroneously still solely expects ~/.linphonerc to
+be present and is unaware of ~/.config/linphone/linphonerc.  To make
+linphonec use ~/.config/linphone/linphonerc invoke it with the -c
+parameter:
+
+  linphone -c $HOME/.config/linphone/linphonerc
+
+Alternatively, you can create a suitable symbolic link by running:
+
+  ln -v -s $HOME/.config/linphone/linphonerc $HOME/.linphonerc
+
+This cannot be done automatically because it might interfere with
+configuration migration logic.
+
+Also take note of the fact that the Qt-based graphical linphone
+application houses all migration logic for configuration files, chat
+logs etc.  If you have any existing such files you should run the
+graphical linphone application to ensure it is properly migrated after
+every upgrade.
+
+ -- Dennis Filder , Thu,  2 Mar 2023 19:40:11 +0100
diff -Nru linphone-5.1.65/debian/patches/disable_appimage_download.patch 
linphone-5.1.65/debian/patches/disable_appimage_download.patch
--- linphone-5.1.65/debian/patches/disable_appimage_download.patch  
1970-01-01 01:00:00.0 +0100
+++ linphone-5.1.65/debian/patches/disable_appimage_download.patch  
2023-03-02 20:10:59.0 +0100
@@ -0,0 +1,27 @@
+Description: Disable behind-the-scenes AppImage download
+ The error message is unfortunately only printed to the log, not stderr.
+Author: Dennis Filder 
+Last-Update: 2023-03-02
+Bug-Debian: https://bugs.debian.org/1031771
+Forwarded: not-needed
+--- a/coreapi/update_check.c
 b/coreapi/update_check.c
+@@ -114,6 +114,11 @@
+   return;
+   }
+ 
++  if (!getenv("LINPHONE_DO_APPIMAGE_DOWNLOAD")) {
++  bctbx_error("AppImage download disabled.  To enable it restart 
the program with the variable LINPHONE_DO_APPIMAGE_DOWNLOAD set to \"y\" in the 
environment.");
++  return;
++  }
++
+   if (version_check_url_root != NULL) {
+   belle_http_request_listener_callbacks_t belle_request_listener 
= { 0 };
+   belle_http_request_t *request;
+@@ -154,4 +159,4 @@
+   request = belle_http_request_create("GET", uri, 
belle_sip_header_create("User-Agent", linphone_core_get_user_agent(lc)), NULL);
+   belle_http_provider_send_request(lc->http_provider, request, 
update->http_listener);
+   }
+-}
+\ No newline at end of file
++}
diff -Nru linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch 
linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch
--- linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch  1970-01-01 
01:00:00.0 +0100
+++ 

Bug#844041: nvidia-cuda-toolkit: does not build when using eatmydata and overlayfs (cannot create /dev/tty)

[Andreas Beckmann]

Hi Santiago,

On 09/02/2017 11.36, Santiago Vila wrote:

retitle 844041 nvidia-cuda-toolkit: does not build when using eatmydata and 
overlayfs (cannot create /dev/tty)



I can reproduce this again (see attach), when using both eatmydata and 
overlayfs.

I think overlayfs is to blame here. It is certainly not a bug when a
package fails to build because of this, but in several cases (for example,
an unorthodox orig tarball which does not have directory entries), the
failure can be avoided in the affected package without waiting for
this to be fixed in the kernel.

So I think this would still make sense as a wishlist, just in case
somebody finds a workaround. I'm using a different title to reflect
this, and I'm also removing the "FTBFS" thing, because this is not a
real FTBFS bug.


is this still an issue 6 years later?

Andreas

Bug#1033316: Autopkgtest is flaky

[Christoph Berg]

Source: ruby-moneta
Version: 1.5.2-1
Severity: important

Hi,

ruby-moneta is currently showing up on
https://qa.debian.org/excuses.php?package=postgresql-common as a
regression in postgresql-common, but that's not true, the code hasn't
changed.

https://ci.debian.net/packages/r/ruby-moneta/testing/amd64/

This has already happened last week. Clicking the retry buttons
resolved the issue back then, on some architectures by making the test
pass, and on other architectures by making even the "reference" test
fail.

Please fix the tests to be stable.

Christoph

Bug#1033315: unblock: evolution-data-server/3.46.4-2

[Alberto Garcia]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Control: block -1 by 1029206

Please unblock package evolution-data-server. Note that this has to
happen together with #1029206: either both packages migrate or none
will.

[ Reason ]
The new upstream stable branch of WebKitGTK has replaced the 5.0
version of the API (for GTK4 users) with version 6.0. The older API
was experimental but it was nevertheless used by a few packages, which
need to switch to the new API.

In Debian this affects three packages: evolution-data-server,
gnome-builder (#1033290) and gnome-initial-setup (#1033249).

[ Impact ]
Future security updates of WebKitGTK won't provide the 5.0 API so it
won't be possible to provide them if these packages don't switch to
the 6.0 API.

[ Tests ]
Tested manually with a test case provided by the upstream developer of
evolution-data-server.

[ Risks ]
>From this package's point of view the risks are small because we're
only doing the switch to the new WebKit API, which already happened
upstream.

I don't think this functionality is even used in practice by any
current desktop app, since both evolution and gnome-online-accounts
have their own gtk3-based oauth2 wizards.

[ 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 evolution-data-server/3.46.4-2
diff -Nru evolution-data-server-3.46.4/debian/changelog 
evolution-data-server-3.46.4/debian/changelog
--- evolution-data-server-3.46.4/debian/changelog   2023-02-10 
13:07:22.0 +0100
+++ evolution-data-server-3.46.4/debian/changelog   2023-03-16 
01:41:30.0 +0100
@@ -1,3 +1,10 @@
+evolution-data-server (3.46.4-2) unstable; urgency=medium
+
+  * Cherry-pick build fixes for latest webkitgtk
+  * Build against webkitgtk 6.0 instead of 5.0
+
+ -- Jeremy Bicha   Wed, 15 Mar 2023 20:41:30 -0400
+
 evolution-data-server (3.46.4-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru evolution-data-server-3.46.4/debian/control 
evolution-data-server-3.46.4/debian/control
--- evolution-data-server-3.46.4/debian/control 2023-02-10 13:07:22.0 
+0100
+++ evolution-data-server-3.46.4/debian/control 2023-03-16 01:41:30.0 
+0100
@@ -35,7 +35,7 @@
libsoup-3.0-dev (>= 3.1.1),
libsqlite3-dev (>= 3.7.17),
libwebkit2gtk-4.1-dev [!ia64 !kfreebsd-any],
-   libwebkit2gtk-5.0-dev [!ia64 !kfreebsd-any],
+   libwebkitgtk-6.0-dev [!ia64 !kfreebsd-any],
libxml2-dev (>= 2.0.0),
gtk-doc-tools (>= 1.14),
gperf,
diff -Nru evolution-data-server-3.46.4/debian/control.in 
evolution-data-server-3.46.4/debian/control.in
--- evolution-data-server-3.46.4/debian/control.in  2023-02-10 
13:07:22.0 +0100
+++ evolution-data-server-3.46.4/debian/control.in  2023-03-16 
01:41:30.0 +0100
@@ -31,7 +31,7 @@
libsoup-3.0-dev (>= 3.1.1),
libsqlite3-dev (>= 3.7.17),
libwebkit2gtk-4.1-dev [!ia64 !kfreebsd-any],
-   libwebkit2gtk-5.0-dev [!ia64 !kfreebsd-any],
+   libwebkitgtk-6.0-dev [!ia64 !kfreebsd-any],
libxml2-dev (>= 2.0.0),
gtk-doc-tools (>= 1.14),
gperf,
diff -Nru 
evolution-data-server-3.46.4/debian/patches/M-107-Use-webkitgtk-6.0-API-version.patch
 
evolution-data-server-3.46.4/debian/patches/M-107-Use-webkitgtk-6.0-API-version.patch
--- 
evolution-data-server-3.46.4/debian/patches/M-107-Use-webkitgtk-6.0-API-version.patch
   1970-01-01 01:00:00.0 +0100
+++ 
evolution-data-server-3.46.4/debian/patches/M-107-Use-webkitgtk-6.0-API-version.patch
   2023-03-16 01:41:30.0 +0100
@@ -0,0 +1,26 @@
+From: Michael Catanzaro 
+Date: Tue, 15 Nov 2022 08:58:38 +
+Subject: M!107 - Use webkitgtk-6.0 API version
+
+In WebKitGTK 2.39.1, the GTK 4 API version has been renamed from 
webkit2gtk-5.0 to webkitgtk-6.0.
+
+Closes 
https://gitlab.gnome.org/GNOME/evolution-data-server/-/merge_requests/107
+
+(cherry picked from commit cdb16f26f63f5093479a43cab32012845bcf33ed)
+---
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 0eaa9b2..b99beb6 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -424,7 +424,7 @@ if(ENABLE_GTK4)
+ 
+   if(ENABLE_OAUTH2_WEBKITGTK4)
+   pkg_check_modules_for_option(ENABLE_OAUTH2_WEBKITGTK4 
"WebKitGTK gtk4 for built-in OAuth2 authentications" OAUTH2_WEBKITGTK4
+-  webkit2gtk-5.0>=${webkit2gtk4_minimum_version}
++  webkitgtk-6.0>=${webkit2gtk4_minimum_version}
+   )
+   endif(ENABLE_OAUTH2_WEBKITGTK4)
+ endif(ENABLE_GTK4)
diff -Nru 
evolution-data-server-3.46.4/debian/patches/M-108-Try-harder-to-support-webkitgtk-6.0.patch
 

Bug#1021330: nvidia-cuda-dev appears to break nvidia xorg

[Andreas Beckmann]

Control: tag -1 moreinfo

On 06/10/2022 02.33, Timothy Hanson wrote:

Package: nvidia-cuda-dev
Version: 11.5.2-2



Today ran apt-get upgrade, including updating nvidia-cuda-dev.  The update
seems to have broken nvidia xorg driver; proximal reason seemsto be that it
pulls in nvidia-tesla-alternative nvidia-tesla-kernel-dkms libnvidia-tesla-
cuda1 (and others) which are a conflicting version (510.85.x).  Video driver
is:
ii  nvidia-kernel-dkms  470.141.03-2
amd64NVIDIA binary kernel module DKMS source


That was probably a transitional issue while upgrading to new driver 
series and/or CUDA tookit. May I assume that this has been solved in the 
current versions (525 driver series, CUDA 11.8)?


Andreas

Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

[Dennis van Dok]

On 21-03-2023 17:39, Cyril Brulebois wrote:

Cyril Brulebois  (2023-03-08):

I should be able to share a small(-ish) ISO for you to test, so that
you can check whether touchpad support becomes available. Same story
as before: that'd be just about booting the installer, reaching the
language selection screen, and letting us know whether the touchpad's
working.


Test ISO (without any firmware, just a fresh minimal installer build)
available here for you to check whether that helps the touchpad become
alive:
   https://people.debian.org/~kibi/bug-1032136/


Tested and the touchpad is now functional. The pointer moves as 
expected. Tapping on the pad does not translate to mouse clicks, but the 
touchpad buttons work correctly.


Tap-to-click is a feature of the driver that I find annoying and 
normally leave off, but I'm not sure that should be the default for the 
installer. I have no real opinion on that, I just thought it was worth 
mentioning that it behaves that way.

Bug#1033248: ITP: python-onetimepad -- python library for the onetimepad algorithm

[matthias . geiger1024]

Control: -1 done
Thanks for bringing this to my attention. I didn't realize onetimepad offered 
*such* bad encryption. I opened an issue upstream about that: 
https://gitlab.com/tabos/banking/-/issues/68
Closing this.
---
Matthias Geiger (werdahias)



21. März 2023, 13:06 von jw...@jwilk.net:

> * Matthias Geiger , 2023-03-20 18:36:
>
>> https://github.com/jailuthra/onetimepad
>>
>
> Misleading package name. Should be: python-toy-xor-encryption-do-not-use.
>
> No, really, don't upload this to Debian.
>
>> it's a dependency for banking (#1013317).
>>
>
> It seems banking uses this via an embedded copy of 
> , which is also horrifying.
>
> -- 
> Jakub Wilk
>



signature.asc
Description: application/pgp-keys

Bug#1033230: webkit2gtk: version 2.39.90-1 lost its libgles2 runtime dependency

[Michel Dänzer]

On 3/21/23 17:27, Alberto Garcia wrote:
> On Mon, Mar 20, 2023 at 01:29:51PM +0100, Gianfranco Costamagna wrote:
> 
>> Hello, for some reasons, now webkit2gtk is not linking anymore
>> libGLESv2.so.2 causing surf to fail autopkgtests on arm64 and armhf
> 
> Hmmm... the reason is that this is now handled via libepoxy, which
> opens libGLESv2.so.2 on runtime using dlopen().
> 
> I think that I'll add the dependencies manually for now, but I wonder
> if libepoxy should depend on those libraries instead?

My understanding is that libepoxy requires its user to set up the EGL/GLX 
context, and the latter should not rely on libepoxy pulling in the 
corresponding libraries.


-- 
Earthling Michel Dänzer|  https://redhat.com
Libre software enthusiast  | Mesa and Xwayland developer

Bug#1016595: cuda: CUDA Error : system not yet initialized

[Andreas Beckmann]

Control: tag -1 moreinfo

On 03/08/2022 22.00, Antonio wrote:

Package: nvidia-cuda-dev
Version: 11.4.3-4



| NVIDIA-SMI 470.129.06   Driver Version: 470.129.06   CUDA Version: 11.4 |


May I assume that this issue has been fixed inbetween with some newer 
driver and or CUDA toolkit?

Current versions in testing are the 525 driver series and CUDA 11.8.


Andreas

Bug#1028780: python-libzim: FTBFS: libzim/libwrapper.h:161:29: error: ‘class zim::Archive’ has no member named ‘getMediaCount’

[Bastian Germann]

On Sat, 11 Mar 2023 16:50:42 +0100 Emmanuel Engelhart  wrote:
Looking at the package names visible at 
https://packages.debian.org/search?searchon=sourcenames=zimlib 
I really wonder if we have libzim-8.1.0 in the most recent dev/testing 
versions of Debian!?


Could someone please confirm the real version of the libzim that 
python-libzim package tries to build against?


In testing/unstable that is 8.0.0.

8.1.0 is in experimental. I suggest to add
https://github.com/openzim/libzim/commit/d443c8aaefba1678e563f94604f51f5a1f3b7ac0
as a patch to it (applies cleanly) and move it to unstable.

Please also add an autopkgtest so that it can migrate without unblock request.

With that, python-libzim will build and the reason for reverting zimlib back to 
8.0.0
should also be fine.

Bug#1033265: netplan.io: autopkgtest tmpfails in unstable with systemd from experimental

[Lukas Maerdian]

Thank you Paul, for raising the issue!

It looks like systemd-networkd-wait-online.service (from v253/experimental) is 
more strict about our test bridge being DOWN (no-carrier), due to not being 
connected to any real interface. Blocking the boot process for up to two 
minutes and therefore timing out the testbed after 60 sec.

I can reproduce the failure in my local DebCI VM and the attached patch fixes 
the issue for me. I'll upload this into unstable once 0.106-2 migrated to 
testing.

-- Lukas


On Mon, 20 Mar 2023 21:57:21 +0100 Paul Gevers  wrote:

Source: netplan.io
Version: 0.106-1
Severity: important
X-Debbugs-CC: syst...@packages.debian.org

Dear maintainers,

Since the upload of systemd 253~rc2-1 to experimental the autopkgtest 
tmpfails in unstable if tested with systemd from experimental. Your test 
asks for a reboot, which times out. As tmpfails are immediately retried 
by the Debian migration software, this is causing quite some load. Can 
you please investigate?


Paul

https://ci.debian.net/data/autopkgtest/unstable/amd64/n/netplan.io/32304482/log.gz

autopkgtest [19:18:33]: test autostart: [---
+ dpkg-vendor --is Debian
+ rm -f /etc/network/interfaces
+ systemctl unmask systemd-networkd.service
+ systemctl unmask systemd-networkd.socket
+ systemctl unmask systemd-networkd-wait-online.service
+ systemctl enable systemd-networkd.service
Created symlink 
/etc/systemd/system/dbus-org.freedesktop.network1.service → 
/lib/systemd/system/systemd-networkd.service.
Created symlink 
/etc/systemd/system/multi-user.target.wants/systemd-networkd.service → 
/lib/systemd/system/systemd-networkd.service.
Created symlink 
/etc/systemd/system/sockets.target.wants/systemd-networkd.socket → 
/lib/systemd/system/systemd-networkd.socket.
Created symlink 
/etc/systemd/system/sysinit.target.wants/systemd-network-generator.service 
→ /lib/systemd/system/systemd-network-generator.service.
Created symlink 
/etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service 
→ /lib/systemd/system/systemd-networkd-wait-online.service.

+ systemctl start systemd-networkd.service
+ systemctl unmask systemd-resolved.service
+ systemctl enable systemd-resolved.service
+ systemctl start systemd-resolved.service
+ mount -o remount,rw /sys
+ systemctl unmask systemd-udevd.service
Removed "/etc/systemd/system/systemd-udevd.service".
+ systemctl start systemd-udevd.service
INFO: Doing initial check that there is no existing netplan config.
● systemd-networkd.service - Network Configuration
  Loaded: loaded (/lib/systemd/system/systemd-networkd.service; 
enabled; preset: enabled)

  Active: active (running) since Mon 2023-03-20 19:18:33 UTC; 419ms ago
TriggeredBy: ● systemd-networkd.socket
Docs: man:systemd-networkd.service(8)
Main PID: 1274 (systemd-network)
  Status: "Processing requests..."
   Tasks: 1 (limit: 308759)
  Memory: 1.3M
 CPU: 33ms
  CGroup: /system.slice/systemd-networkd.servicediff --git a/debian/tests/autostart.sh b/debian/tests/autostart.sh
index f3aee9fa..2142ca2f 100755
--- a/debian/tests/autostart.sh
+++ b/debian/tests/autostart.sh
@@ -35,6 +35,7 @@ Name=eth0 en*
 
 [Network]
 DHCP=yes
+KeepConfiguration=yes
 EOF
 
 case "${AUTOPKGTEST_REBOOT_MARK:-}" in
@@ -58,6 +59,7 @@ network:
   version: 2
   bridges:
 brtest00:
+  optional: true # ignore in systemd-networkd-wait-online.service to avoid testbed timeouts
   addresses: [10.42.1.1/24]
 EOF
 
diff --git a/debian/tests/cloud-init.sh b/debian/tests/cloud-init.sh
index 031e8944..15a6e0b6 100755
--- a/debian/tests/cloud-init.sh
+++ b/debian/tests/cloud-init.sh
@@ -33,6 +33,7 @@ Name=eth0 en*
 
 [Network]
 DHCP=yes
+KeepConfiguration=yes
 EOF
 
 case "${AUTOPKGTEST_REBOOT_MARK:-}" in
@@ -45,6 +46,7 @@ network:
   version: 2
   bridges:
 brtest00:
+  optional: true # ignore in systemd-networkd-wait-online.service to avoid testbed timeouts
   addresses: [10.42.1.1/24]
 EOF
 # Prepare a dummy netplan service unit, which will be moved to /run/systemd/system/

Bug#1033314: ITS: easy-rsa

[Bastian Germann]

Source: easy-rsa
Severity: important

I am filing this intend to salvage easy-rsa in order to orphan the package 
after the waiting period.
The maintainer seems to be missing in action and the package qualifies for ITS.

Bug#1033313: OpenSSL 3 binNMUS for experimental

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu libewf_20171104-1 . ANY . experimental . -m "Rebuild against libssl3"
nmu libre_2.0.1-1 . ANY . experimental . -m "Rebuild against libssl3"
nmu psi-plus_1.4.1456-2 . ANY . experimental . -m "Rebuild against libssl3"
nmu tinc_1.1~pre18-1 . ANY . experimental . -m "Rebuild against libssl3"

Bug#1033312: debian-security-support: broken symlink: /usr/share/debian-security-support/security-support-ended -> security-support-ended.deb12

[Paul Wise]

Package: debian-security-support
Version: 1:12+2022.08.18
Control: found -1 1:12+2023.03.17
Severity: normal
File: /usr/share/debian-security-support/security-support-ended
User: debian...@lists.debian.org
Usertags: adequate broken-symlink

debian-security-support 1:12+2022.08.18 introduced a broken symlink:

   /usr/share/debian-security-support/security-support-ended -> 
security-support-ended.deb12 

This appears to be because the source package misses a .deb12 file but
the debian/rules links to it as NEXT_VERSION_ID=12 is in debian/rules.

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

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

Versions of packages debian-security-support depends on:
ii  adduser3.131
ii  debconf [debconf-2.0]  1.5.82
ii  gettext-base   0.21-12

debian-security-support recommends no packages.

debian-security-support suggests no packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1033311: sysvinit-utils: pidof not always returning a pid when using the full path to a program

[Markus Fischer]

Package: sysvinit-utils
Version: 3.06-2
Severity: normal
X-Debbugs-Cc: none

Dear Maintainer,

Passing the full path of a binary to the pidof command does not always
return a pid although the process is running and the man page of the
pidof command explicitly notes that it can be used that way.

This might be related to the fact that all programs with which I tested
this and which show this unexpected behaviour were symlinks (i.e.,
"which " returned a symlink). However, on Debian Bullseye the
behaviour is as I expected it.


Steps to reproduce:
* start vi
* in another shell run "pidof vi" and "pidof $(which vi)"

Result:
The first pidof invocation correctly returns a pid but the second
invocation does not.

Expected result:
Both invocations of pidof should return a pid. 


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: i386 (i686)

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

Versions of packages sysvinit-utils depends on:
ii  libc6  2.36-8

sysvinit-utils recommends no packages.

sysvinit-utils suggests no packages.

-- no debconf information

Bug#1018061: pads: segfault at 3a ip

[Bernhard Übelacker]

control: tags -1 +patch


Hello Tim,
nice to hear it helps. Therefore adding the patch tag.

Kind regards,
Bernhard



Am 21.03.23 um 17:53 schrieb Tim McConnell:

Hi Bernhard,
I believe the patch has fixed the issue. I haven't seen any messages
about psad since installing the patch.
Thanks so much for the fix & patience with me.

Bug#1033310: ruby-dalli: Missing dependency on ruby-connection-pool

[Petr Jurasek]

Package: ruby-dalli
Version: 3.0.6-1.1
Severity: normal

Dear Maintainer,

in file
/usr/share/rubygems-integration/all/gems/dalli-3.0.6/lib/rack/session/dalli.rb
is required 'connection_pool', but package doesn't depend on
ruby-connection-pool.

Regards
Petr Jurasek

-- System Information:
Debian Release: bookworm/sid
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 6.1.0-3-686-pae (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

ruby-dalli depends on no packages.

ruby-dalli recommends no packages.

Versions of packages ruby-dalli suggests:
pn  ruby-kgio  

-- no debconf information

Bug#1003352:

[Daniel Baumann]

On 3/22/23 06:18, Cyrus Lien wrote:
> This bug still needs a boot script mounting efivarfs in initrd for
> systems whose rootfs are on RAID volume.

as the bug sais: this has been fixed in mdadm 4.2+20230223-1.

Regards,
Daniel

Bug#1033309: xdm: Unknown session exit code 256

[Marco Moock]

Package: xdm
Version: 1:1.1.11-3+b2
Severity: normal
X-Debbugs-Cc: m...@posteo.de

Dear Maintainer,

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

   * What led up to the situation?
I run xdm and sometimes I get error 256 as an exit code.
It also doesn't delete the lock file /var/run/xdm.pid and can't start after the 
next reboot.
For me it seems xdm doesn't exit properly. It happended many times, but not 
every time xdm is being used.

   * What exactly did you do (or not do) that was effective (or
Deleting /var/run/xdm.pid after the reboot if xdm can't start helps.

This is part of an xdm log file:

Sun Jan 29 07:02:45 2023 xdm error (pid 996): Can't lock pid file 
/var/run/xdm.pid, another xdm is running (pid 763)
Sun Jan 29 07:03:38 2023 xdm error (pid 1027): Can't lock pid file 
/var/run/xdm.pid, another xdm is running (pid 763)
Sun Jan 29 07:04:22 2023 xdm info (pid 1107): Starting
Sun Jan 29 07:04:22 2023 xdm info (pid 1107): Starting X server on :0

X.Org X Server 1.21.1.6
X Protocol Version 11, Revision 0 
Current Operating System: Linux ryz 6.1.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.7-1 (2023-01-18) x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-2-amd64 
root=UUID=677e19d6-ec2a-42bc-b27f-840387b1d200 ro
xorg-server 2:21.1.6-1 (https://www.debian.org/support)
Current version of pixman: 0.42.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Jan 29 07:04:22 2023
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Sun Jan 29 07:04:27 2023 xdm info (pid 1120): sourcing /etc/X11/xdm/Xsetup
Sun Jan 29 07:04:31 2023 xdm info (pid 1120): sourcing /etc/X11/xdm/Xstartup
Sun Jan 29 07:04:31 2023 xdm info (pid 1129): executing session 
/etc/X11/xdm/Xsession
(EE) event1  - PS/2 Logitech Mouse: client bug: event processing lagging behind 
by ms, your system is too slow
(EE) event1  - PS/2 Logitech Mouse: client bug: event processing lagging behind 
by 993ms, your system is too slow
Sun Jan 29 10:37:41 2023 xdm error (pid 1107): Sun Jan 29 10:37:41 2023 xdm 
info (pid 1107): Shutting down
Unknown session exit code 256 from process 1120
(II) Server terminated successfully (0). Closing log file.
Sun Jan 29 10:37:45 2023 xdm info (pid 1107): Exiting 
Sun Jan 29 10:49:22 2023 xdm info (pid 761): Starting
Sun Jan 29 10:49:22 2023 xdm info (pid 761): Starting X server on :0

X.Org X Server 1.21.1.6
X Protocol Version 11, Revision 0
Current Operating System: Linux ryz 6.1.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.7-1 (2023-01-18) x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-2-amd64 
root=UUID=677e19d6-ec2a-42bc-b27f-840387b1d200 ro
xorg-server 2:21.1.6-1 (https://www.debian.org/support)
Current version of pixman: 0.42.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Jan 29 10:49:25 2023
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
Sun Jan 29 10:49:41 2023 xdm info (pid 888): sourcing /etc/X11/xdm/Xsetup
(EE) event0  - AT Translated Set 2 keyboard: client bug: event processing 
lagging behind by 33ms, your system is too slow
Sun Jan 29 10:50:40 2023 xdm info (pid 761): Shutting down
Sun Jan 29 10:50:40 2023 xdm info (pid 761): display :0 is being disabled
(II) Server terminated successfully (0). Closing log file.
Sun Jan 29 10:50:40 2023 xdm info (pid 761): Exiting
Sun Jan 29 10:50:40 2023 xdm info (pid 990): Starting
Sun Jan 29 10:50:40 2023 xdm info (pid 990): Starting X server on :0

X.Org X Server 1.21.1.6
X Protocol Version 11, Revision 0
Current Operating System: Linux ryz 6.1.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.1.7-1 (2023-01-18) x86_64
Kernel command line: BOOT_IMAGE=/vmlinuz-6.1.0-2-amd64 
root=UUID=677e19d6-ec2a-42bc-b27f-840387b1d200 ro
xorg-server 2:21.1.6-1 (https://www.debian.org/support)
Current version of pixman: 0.42.2
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Jan 29 10:50:40 2023
(==) Using config directory: "/etc/X11/xorg.conf.d"
(==) Using system config 

Bug#1033308: ipmitool: Upstream project archived, developer blocked from github?

[Petter Reinholdtsen]

Package: ipmitool
Version: 1.8.19-5
Severity: wishlist

According to 
https://news.slashdot.org/story/23/03/21/2126227/russian-developers-blocked-from-contributing-to-foss-tools>,
the lead developer of ipmitool has been blocked from accessing github
and his github repositories flagged as archived and turned read only.
Visiting https://github.com/ipmitool/ipmitool > show the
repository have the "Public archive" flag present.

Not quite sure how to handle this, but thought it best to notify the
package maintainer about the issue.  Perhaps contact upstream and
suggest to move away from github?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1033301: linux: arm64 kernel size increased from 31 to 39 MB, causing u-boot-rpi to fail

[Salvatore Bonaccorso]

Hi Aurelien,

Thanks for tracking this down. I would like to loop in Masahiro and
upstream to see if something can/should be done on upstream side.

Masahiro, in short, upstream change 994b7ac1697b ("arm64: remove
special treatment for the link order of head.o") (which got backported
as well to 6.1.14) caused the vmlinuz size to icrease significantly,
causing boot failures on Raspberry Pi 3 Model B Plus with u-boot
parameters previously working. Full quoting the Debian report below

On Tue, Mar 21, 2023 at 11:11:13PM +0100, Aurelien Jarno wrote:
> Source: linux
> Version: 6.1.15-1
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: vagr...@debian.org
> Control: affects -1 + u-boot-rpi
> 
> Hi,
> 
> Following the upgrade of the kernel from 6.1.12-1 to 6.1.15-1 on a
> Raspberry Pi 3 Model B Plus, u-boot (from the u-boot-rpi package) failed
> to boot with:
> 
> | 40175552 bytes read in 1695 ms (23 MiB/s)
> | 43794863 bytes read in 1817 ms (23 MiB/s)
> | Moving Image from 0x8 to 0x20, end=299
> | ERROR: RD image overlaps OS image (OS=0x20..0x299)
> 
> I tracked the issue to a significant increase of the kernel size between
> version 6.1.12-1 and 6.15-1:
> 
> | 31492   /boot/vmlinuz-6.1.0-5-arm64
> | 39236   /boot/vmlinuz-6.1.0-6-arm64
> 
> This is more than the 36MB that is allowed by u-boot with the default
> load addresses. A workaround is to shift the load addresses at the
> u-boot level as in the attached patch.
> 
> I have tracked issue on the upstream kernel side to the following commit
> on the stable tree:
> 
> | commit 3e3e4d234d46e48480a7c7c35399fa811182e8ef
> | Author: Masahiro Yamada 
> | Date:   Thu Oct 13 08:35:00 2022 +0900
> | 
> | arm64: remove special treatment for the link order of head.o
> | 
> | commit 994b7ac1697b4581b7726d2ac64321e3c840229b upstream.
> | 
> | In the previous discussion (see the Link tag), Ard pointed out that
> | arm/arm64/kernel/head.o does not need any special treatment - the only
> | piece that must appear right at the start of the binary image is the
> | image header which is emitted into .head.text.
> | 
> | The linker script does the right thing to do. The build system does
> | not need to manipulate the link order of head.o.
> | 
> | Link: 
> https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=e...@mail.gmail.com/
> | Suggested-by: Ard Biesheuvel 
> | Signed-off-by: Masahiro Yamada 
> | Reviewed-by: Nicolas Schier 
> | Link: 
> https://lore.kernel.org/r/20221012233500.156764-1-masahi...@kernel.org
> | Signed-off-by: Will Deacon 
> | Signed-off-by: Tom Saeger 
> | Signed-off-by: Greg Kroah-Hartman 
> 
> The problem is still reproducible on Linus' master.
> 
> I am reporting the bug to the linux package as I believed there is no
> real reason for such an increase in the kernel size. In case I missed
> something and this is actually wanted, the bug can be reassigned to the
> u-boot package.
> 
> Regards
> Aurelien

> --- u-boot-2023.01+dfsg.orig/include/configs/rpi.h
> +++ u-boot-2023.01+dfsg/include/configs/rpi.h
> @@ -95,32 +95,32 @@
>   *   text_offset bytes (specified in the header of the Image) into a 2MB
>   *   boundary. The 'booti' command relocates the image if necessary. Linux 
> uses
>   *   a default text_offset of 0x8.  In summary, loading at 0x8
> - *   satisfies all these constraints and reserving memory up to 0x0240
> - *   permits fairly large (roughly 36M) kernels.
> + *   satisfies all these constraints and reserving memory up to 0x02a0
> + *   permits fairly large (roughly 42M) kernels.
>   *
>   * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
>   * conflict with something else. Reserving 1M for each of them at
> - * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
> + * 0x02a0-0x02b0 and 0x02c0-0x02d0 should be plenty.
>   *
>   * On ARM, both the DTB and any possible initrd must be loaded such that they
>   * fit inside the lowmem mapping in Linux. In practice, this usually means 
> not
>   * more than ~700M away from the start of the kernel image but this number 
> can
>   * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
>   * parameter given to the kernel. So reserving memory from low to high
> - * satisfies this constraint again. Reserving 1M at 0x0260-0x0270 for
> - * the DTB leaves rest of the free RAM to the initrd starting at 0x0270.
> + * satisfies this constraint again. Reserving 1M at 0x02c0-0x02d0 for
> + * the DTB leaves rest of the free RAM to the initrd starting at 0x02d0.
>   * Even with the smallest possible CPU-GPU memory split of the CPU getting
> - * only 64M, the remaining 25M starting at 0x0270 should allow quite
> + * only 64M, the remaining 19M starting at 0x02d0 should allow quite
>   * large initrds before they start colliding with U-Boot.
>   */
>  #define