Bug#1030510: Info received (Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)))

[Sebastian Ramacher]

Control: severity -1 serious

On 2023-02-07 08:36:11 -0800, Otto Kekäläinen wrote:
> Control: severity -1 normal
> Control: tags -1 help
> 
> The s390x build is still failing after 5 retries at
> https://buildd.debian.org/status/package.php?p=mariadb. The issue
> seems to be with Debian buildd, as the Launchpad s390x build passed
> just fine without the need to retry anything:
> https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all
> 
> It seems to crash on different tests every time. I could disable the
> entire test suite, but that feels like a bad idea.
> 
> I need help - if the s390x build does not pass, the 10.11 cannot enter
> Debian testing (Bookworm).

Indeed:

excuses:
Migration status for mariadb (- to 1:10.11.1-3): BLOCKED: Rejected/violates 
migration policy/introduces a regression
Issues preventing migration:
∙ ∙ Updating mariadb would introduce bugs in testing: #1029136, #1030604
∙ ∙ autopkgtest for libreoffice/blocked-on-ci-infra: armel: Ignored 
failure, i386: Ignored failure, ppc64el: Ignored failure
∙ ∙ autopkgtest for mariadb/1:10.11.1-3: amd64: Pass, arm64: Pass, armel: 
Pass, armhf: Pass, i386: Pass, ppc64el: Pass
∙ ∙ autopkgtest for mariadb-10.6/1:10.6.11-2: amd64: Regression ♻ 
(reference ♻), arm64: Regression ♻ (reference ♻), armel: Pass, armhf: Pass, 
i386: Pass, ppc64el: Not a regression
∙ ∙ missing build on s390x

And that's why the severity of this issue is serious.

Cheers
-- 
Sebastian Ramacher

Bug#1030839: pyatem needs hinting into testing

[Adrian Bunk]

Package: release.debian.org
Severity: normal

Migration status for pyatem (- to 0.8.2-1): BLOCKED: Rejected/violates 
migration policy/introduces a regression
Issues preventing migration:
∙ ∙ openswitcher/arm64 has unsatisfiable dependency
∙ ∙ openswitcher-proxy/arm64 has unsatisfiable dependency
∙ ∙ autopkgtest for pyatem/0.8.2-1: amd64: Pass, armel: Regression ♻ , armhf: 
Regression ♻ , i386: Pass, ppc64el: Regression ♻ , s390x: Regression ♻

The package currently builds only on x86 and mips* (and some ports 
architectures),
which makes:
- the binary-all package not installable on arm64, and
- autopkgtest FAIL badpkg

Bug#1030838: rust-quinn-proto: autopkgtest failure on i386

[Adrian Bunk]

Source: rust-quinn-proto
Version: 0.9.2-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/i386/r/rust-quinn-proto/31157225/log.gz

...
failures:

 connection::pacing::tests::computes_pause_correctly stdout 
thread 'connection::pacing::tests::computes_pause_correctly' panicked at 
'assertion failed: `(left == right)`
  left: `3`,
 right: `4`', src/connection/pacing.rs:272:9
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.63.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:142:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
 at /usr/src/rustc-1.63.0/library/core/src/panicking.rs:181:5
   4: quinn_proto::connection::pacing::tests::computes_pause_correctly
 at ./src/connection/pacing.rs:272:9
   5: 
quinn_proto::connection::pacing::tests::computes_pause_correctly::{{closure}}
 at ./src/connection/pacing.rs:232:5
   6: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
   7: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.63.0/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.


failures:
connection::pacing::tests::computes_pause_correctly

test result: FAILED. 103 passed; 1 failed; 0 ignored; 0 measured; 0 filtered 
out; finished in 0.87s

error: test failed, to rerun pass `--lib`
autopkgtest [22:07:02]: test librust-quinn-proto-dev:arbitrary: 
---]
autopkgtest [22:07:02]: test librust-quinn-proto-dev:arbitrary:  - - - - - - - 
- - - results - - - - - - - - - -
librust-quinn-proto-dev:arbitrary FAIL non-zero exit status 101
...
autopkgtest [22:18:39]:  summary
rust-quinn-proto:@   FLAKY non-zero exit status 101
librust-quinn-proto-dev:arbitrary FAIL non-zero exit status 101
librust-quinn-proto-dev:default FLAKY non-zero exit status 101
librust-quinn-proto-dev:native-certs FAIL non-zero exit status 101
librust-quinn-proto-dev:ring FAIL non-zero exit status 101
librust-quinn-proto-dev:rustls FLAKY non-zero exit status 101
librust-quinn-proto-dev:rustls-native-certs FAIL non-zero exit status 101
librust-quinn-proto-dev:tls-rustls FLAKY non-zero exit status 101
librust-quinn-proto-dev:webpki FAIL non-zero exit status 101
librust-quinn-proto-dev: FAIL non-zero exit status 101

Bug#1028371: bernhard: needs rebuilds on top of new protobuf

[Adrian Bunk]

On Tue, Jan 10, 2023 at 07:57:45AM +0100, Gianfranco Costamagna wrote:
> Source: bernhard
> Version: 0.2.6-3
> Severity: serious
> 
> Hello, your package is tied to a specific protobuf version, but doesn't 
> declare any explicit dependency on it
> 
> Now, the package fails to load due to pb.py not being rebuilt.
> 
> python3 -c "import bernhard"
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/bernhard/__init__.py", line 20, in 
> 
> from . import pb
>   File "/usr/lib/python3/dist-packages/bernhard/pb.py", line 36, in 
> _descriptor.FieldDescriptor(
>   File "/usr/lib/python3/dist-packages/google/protobuf/descriptor.py", line 
> 560, in __new__
> _message.Message._CheckCalledFromGeneratedFile()
> TypeError: Descriptors should not be created directly, but only retrieved 
> from their parent.
> 
> 
> Please have a look.
> (not change rebuilding works as workaround, but I think we should make sure 
> the package is not used with a wrong
> protobuf version)

The package seems to require the same protobuf version as it was 
compiled with, but the dependency is only indirectly through 
python3-protobuf.

> G.

cu
Adrian

Bug#1030096: Any ideas Re: #1030096 dask.distributed intermittent autopkgtest fail ?

[Diane Trout]

On Tue, 2023-02-07 at 07:31 +, Rebecca N. Palmer wrote:
> On 07/02/2023 03:20, Diane Trout wrote:
> > What's your test environment like?
> 
> Salsa CI.
> 
> > I don't think head is hugely different from what was released in -
> > 1.
> > 
> > The diff looks like Andreas adjusted the dask dependency version,
> > configured a salsa CI run, and added some upstream metadata files
> 
> That sounds like you're not looking at my branch at all.  As
> previously 
> stated, that's
> https://salsa.debian.org/rnpalmer-guest/dask.distributed/-/tree/fix1030096
> (It's in a fork because I can't push to debian-python.)
> 
> See earlier in this bug for which test failures still remain.

I merged in most of Rebecca's changes via git cherry pick, though I
slightly edited the changelog. (making most entries a bullet point
instead of subheadings of the one line I left out).

I think I got the code to detect if IPv6 is available to work correctly
so I could set the DISABLE_IPV6 environment variable that
dask.distrubted supports.

I went with skipping the 32bit tests instead of xfailed because I don't
think they can work as written since I really think they're making
really large memory requests that can't ever succeed on 32bit.

You did a lot of work on trying to get the flaky tests to work more
reliably, and all that's included. Well except for the apply a patch
and then revert it.

All the merges are pushed to salsa debian/master. They also passed on
my local build host running i386.

Diane

Bug#1026042: trx: License is incompatible with that of up-coming ortp 5.2.0

[Kyle Robbertze]

On 2022/12/13 19:27, Dennis Filder wrote:

Source: trx
Version: 0.5-4
Severity: important

With the recently released version 5.2 ortp has been relicensed to GNU
AGPL-3+.  Since your package is GPL-2 it is my understanding that it
may not link in ortp 5.2 until it is relicensed to either GPL-3 or
AGPL-3.

Please consult with the upstream developer whether they are open to
relicensing.  If they aren't you face the decision of whether to
maintain a fork of an older license-compatible version of ortp, remove
trx from Debian or work around this in some other way.  Ask on
debian-legal if you have questions about the details of license
compatibility and how to best handle this.


As there has not been any development upstream in several years, I think 
we will need to remove trx from Debian once the new ortp version is 
released.


Cheers
Kyle

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Kyle Robbertze
⢿⡄⠘⠷⠚⠋⠀ Debian Developer
⠈⠳⣄ https://wiki.debian.org/KyleRobbertze

Bug#1030725: dhcpcd-base: service does not restart after package updates

[Martin-Éric Racine]

On Mon, 06 Feb 2023 20:39:36 +0100 Beat Bolli  wrote:
>   This morning, version 9.4.1-16 was installed by my daily
>   unattended-upgrade run. As after all recent updates, the service
>   was stopped, but not restarted after the update. This leads to
>   loss of Internet connectivity after the DHCP lease expires.

If you are only using dhcpcd-base, it implies that DHCP is restarted
by ifupdown via /etc/network/interfaces. Is that the case here?

Martin-Éric

Bug#1030837: linux-base: [INTL:tr] turkish debconf translation update

[Atila KOÇ]

Package: linux-base
Severity: wishlist
Tags: l10n patch

Hello,

Attached is the updated Turkish translation of the linux-base debconf 
template.

It has been submitted for review to the debian-l10n-turkish mailing list.
Please include it in your next upload.

Regards,
Atila KOÇ# Turkish translation of linux-base.
# This file is distributed under the same license as the linux-base package.
# Mert Dirik , 2012, 2014.
#
msgid ""
msgstr ""
"Project-Id-Version: linux-base\n"
"Report-Msgid-Bugs-To: linux-b...@packages.debian.org\n"
"POT-Creation-Date: 2016-06-06 16:37+0100\n"
"PO-Revision-Date: 2023-01-14 21:13+0300\n"
"Last-Translator: Atila KOÇ \n"
"Language: tr\n"
"Language-Team: Debian L10n Turkish \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.4.2\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: title
#. Description
#: ../linux-base.templates:2001
msgid "Removing ${package}"
msgstr "${package} paketi kaldırılıyor"

#. Type: boolean
#. Description
#: ../linux-base.templates:3001
msgid "Abort kernel removal?"
msgstr "Çekirdeği kaldırma işlemi iptal edilsin mi?"

#. Type: boolean
#. Description
#: ../linux-base.templates:3001
msgid ""
"You are running a kernel (version ${running}) and attempting to remove the "
"same version."
msgstr ""
"(${running}) sürümündeki çekirdeği kullanıyorsunuz ve aynı sürümdeki "
"çekirdeği kaldırmaya çalışıyorsunuz."

#. Type: boolean
#. Description
#: ../linux-base.templates:3001
msgid ""
"This can make the system unbootable as it will remove /boot/vmlinuz-"
"${running} and all modules under the directory /lib/modules/${running}. This "
"can only be fixed with a copy of the kernel image and the corresponding "
"modules."
msgstr ""
"Bu eylem /boot/vmlinuz-${running} dosyasını ve /lib/modules/${running} "
"dizinindeki tüm modülleri kaldıracağından dolayı sisteminizi başlatılamaz "
"duruma getirebilir. Bu durum yalnızca bir çekirdek görüntüsü kopyası ve bu "
"görüntüye uygun modüller ile düzeltilebilir."

#. Type: boolean
#. Description
#: ../linux-base.templates:3001
msgid ""
"It is highly recommended to abort the kernel removal unless you are prepared "
"to fix the system after removal."
msgstr ""
"Kaldırma işlemi sonrasında sisteminizi düzeltmeye hazırlanmadıysanız, "
"çekirdek kaldırma işleminden vazgeçmeniz şiddetle önerilir."

Bug#1030785: Reproducibility of ocaml...

[Stéphane Glondu]

Hi Chris,

Le 07/02/2023 à 17:13, Chris Lamb a écrit :

I appreciate this info is difficult to find (!), but for a bunch of
historical reasons, there are actually a different set of variations
tested when we test sid compared to when we test bookworm. In other
words, the differences between the two builds is not just the package
version and Debian distribution.

We try to canonically document the differences on this page:

   https://tests.reproducible-builds.org/debian/index_variations.html

And almost certainly the difference is down to the build path. :)


Indeed.


Does
that help? We've had a series of build path variations in the OCaml
stack, so maybe some patch got reverted, or…?


In this specific case, the variation comes from -ffile-prefix-map being 
injected automatically into CFLAGS.



Cheers,

--
Stéphane

Bug#1030674: sox: test failure on some mips64el machines

[Helmut Grohne]

Control: retitle -1 sox: test failure on some mipsen machines

On Mon, Feb 06, 2023 at 12:57:40PM +0100, Helmut Grohne wrote:
> the sox source package didn't run tests. In -3.1, I NMUed it enabling
> tests and it built successfully on mipsel-osuosl-03. Then I added a few
> changes that probably are unrelated and uploaded -3.2, which failed
> tests on mipsel-aql-01 even after giving it back. I tried running that
> very test on eller 100 times and it succeeded there.
> 
> The test failure is:
> 
> | ok channels=1 "vox" <--> "f32".
> | /<>/src/.libs/sox WARN sox: `output.vox' output clipped 369 
> samples; decrease volume?
> | *FAIL* channels=1 "vox" <--> "f64".
> | make[1]: *** [debian/rules:16: override_dh_auto_test] Error 1

It failed in the same way on mipsel using mipsel-manda-05 now.

I'll be making tests non-fatal for all mipsen now.

Helmut

Bug#1019118: patch for rtla regression

[Helmut Grohne]

Control: tags -1 + patch
Control: forwarded -1 
https://lore.kernel.org/all/20230120070809.6169-1-jo...@mister-muffin.de/

Hi,

Johannes tried upstreaming the necessary change and that was rejected
with a note that this is the responsibility of the builder. I'm
attaching the appropriate Debian patch as requested. Please consider
applying it.

Helmut
diff --minimal -Nru linux-6.1.8/debian/changelog linux-6.1.8/debian/changelog
--- linux-6.1.8/debian/changelog2023-01-29 13:33:36.0 +0100
+++ linux-6.1.8/debian/changelog2023-02-07 07:55:34.0 +0100
@@ -1,3 +1,10 @@
+linux (6.1.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Supply the host pkg-config to the rtla build. (Closes: 
#1019118)
+
+ -- Helmut Grohne   Tue, 07 Feb 2023 07:55:34 +0100
+
 linux (6.1.8-1) unstable; urgency=medium
 
   * New upstream stable update:
diff --minimal -Nru linux-6.1.8/debian/rules.d/Makefile.inc 
linux-6.1.8/debian/rules.d/Makefile.inc
--- linux-6.1.8/debian/rules.d/Makefile.inc 2022-11-20 16:33:47.0 
+0100
+++ linux-6.1.8/debian/rules.d/Makefile.inc 2023-02-07 07:55:34.0 
+0100
@@ -7,6 +7,7 @@
 
 CC = $(CROSS_COMPILE)gcc
 CXX = $(CROSS_COMPILE)g++
+PKG_CONFIG = $(CROSS_COMPILE)pkg-config
 CFLAGS := $(shell dpkg-buildflags --get CFLAGS) -Wall
 CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) \
-I$(top_srcdir)/$(OUTDIR) \
diff --minimal -Nru linux-6.1.8/debian/rules.d/tools/tracing/rtla/Makefile 
linux-6.1.8/debian/rules.d/tools/tracing/rtla/Makefile
--- linux-6.1.8/debian/rules.d/tools/tracing/rtla/Makefile  2023-01-28 
14:24:06.0 +0100
+++ linux-6.1.8/debian/rules.d/tools/tracing/rtla/Makefile  2023-02-07 
07:55:34.0 +0100
@@ -5,7 +5,7 @@
echo '$(UPSTREAMVERSION)' >VERSION
rsync -a $(top_srcdir)/tools/tracing/rtla/ .
rsync -a $(top_srcdir)/Documentation/tools/rtla/ Documentation/
-   $(MAKE) EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS)' EXTRA_LDFLAGS='$(LDFLAGS)'
+   $(MAKE) EXTRA_CFLAGS='$(CFLAGS) $(CPPFLAGS)' EXTRA_LDFLAGS='$(LDFLAGS)' 
PKG_CONFIG='$(PKG_CONFIG)'
 
 install:
$(MAKE) install

Bug#1030813: mumble: autopkgtest regression

[Chris Knadle]

This should be fixed in Mumble 1.3.4-3.
debian/tests/control had this:

   Test-Command: smoke

when it should have been:

   Tests: smoke

If the autopkgtest passes tomorrow as shown in the Debian tracker I'll close 
this bug.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Adrian Bunk:

Source: mumble
Version: 1.3.4-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mumble/31139421/log.gz

...
autopkgtest [09:23:28]: test command1: smoke
autopkgtest [09:23:28]: test command1: [---
bash: line 1: smoke: command not found
autopkgtest [09:23:29]: test command1: ---]
autopkgtest [09:23:29]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 127

Bug#1030043: hplip-gui: traceback when launching hp-toolbox

[Ryan Thoryk]

Changing line 119 in /usr/share/hplip/base/password.py
from:
get_distro_std_name(os_name)
to:
get_distro_name()

appears to fix the issue.

--
Ryan Thoryk
r...@thoryk.com
r...@tliquest.net

Bug#1030460: (no subject)

[Marius Gripsgard]

This got fixed upstream and the fix is included my last upload. closing this


Thank you

Bug#1030836: pinball: Segfaulted on first run of "GNU table"

[Rishi Cutchin]

Package: pinball
Version: 0.3.20201218-4
Severity: normal
X-Debbugs-Cc: rishincutc...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Installed pinball-table-gnu and pinball-table-hurd
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried to load pinball-table-gnu, and segfaulted

   * What was the outcome of this action?
Segfault and crash, works perfectly fine on subsequent loads

   * What outcome did you expect instead?
Loading of table GNU level
*** End of the template - remove these template lines ***


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

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

Versions of packages pinball depends on:
ii  libc62.31-13+deb11u5
ii  libgcc-s110.2.1-6
ii  libgl1   1.3.2-1
ii  libltdl7 2.4.6-15
ii  libsdl-image1.2  1.2.12-12
ii  libsdl-mixer1.2  1.2.12-16+b1
ii  libsdl1.2debian  1.2.15+dfsg2-6
ii  libstdc++6   10.2.1-6
ii  pinball-data 0.3.20201218-4

pinball recommends no packages.

Versions of packages pinball suggests:
pn  alsa-utils  
ii  pinball-table-gnu   0.0.20200601-2
ii  pinball-table-hurd  0.0.20201119-2
ii  xinit   1.4.0-1

-- no debconf information

Bug#1030751: debuerreotype: diff for NMU version 0.15-1.1

[Tianon Gravi]

On Tue, 7 Feb 2023 at 09:15, Tianon Gravi  wrote:
> On Tue, 7 Feb 2023 at 01:33, Adrian Bunk  wrote:
> > Package: debuerreotype
> > Version: 0.15-1
> > Severity: normal
> > Tags: patch  pending
> >
> > Dear maintainer,
> >
> > I've prepared an NMU for debuerreotype (versioned as 0.15-1.1) and
> > uploaded it to DELAYED/1. Please feel free to tell me if I should
> > cancel it.
> >
> > cu
> > Adrian
>
> I'm sorry, but I must admit to being a little bit confused by this --
> why was this a whole new bug instead of just a comment on #1022854?
>
> (and why wasn't there any attempt to communicate about why it's urgent
> for you before the NMU, especially with such a short delay?  is there
> a particular reason you're doing this?  I can guess at your
> motivations, but it sure helps if they're written somewhere )

Given the timezone differences, I've dcut cancel'd the upload for now
(assuming that gets picked up correctly and I didn't mess something
up).

I'm not opposed to the change (or even it being an NMU), but doing so
without a discussion doesn't seem right and I'd like to understand
what the end goal is better and why it's urgent enough for you to
upload with a DELAYED/1 NMU. 

Thanks!

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1030835: ITP: ruff -- linter for Python, written in Rust

[James Addison]

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

* Package name: ruff
  Version : 0.0.243
  Upstream Contact: Charlie Marsh
* URL : https://github.com/charliermarsh/ruff/
* License : MIT
  Programming Lang: Rust
  Description : linter for Python, written in Rust

Ruff is a linter for Python that includes implementations of many common
checks implemented by flake8, flake8 plugins, and pylint.

Bug#1030126: gnome-bluetooth-sendto should take over gnome-bluetooth with a transitional package

[Simon McVittie]

On Tue, 07 Feb 2023 at 16:49:46 -0500, Jeremy Bícha wrote:
> On Tue, Jan 31, 2023 at 7:48 AM Simon McVittie  wrote:
> > - upload src:gnome-bluetooth3 adding a gnome-bluetooth (>= 42) transitional
> >   binary package before bookworm;
> > - upload src:gnome-bluetooth removing the gnome-bluetooth binary package
> >   before bookworm;
> > - remove the transitional gnome-bluetooth package in trixie;
> > - try to remove src:gnome-bluetooth completely in trixie
> 
> I instead am adding the gnome-bluetooth transitional package to the
> old gnome-bluetooth source package.

Aha, yes, that's a better plan that what I said: this way the transitional
package will "naturally" vanish when the old source package is removed.

smcv

Bug#1030741: firmware-brcm80211: Package firmware-brcm80211 not found in bookworm

[Mathirajan S. Manoharan]

hi Salvatore,

Thank you for your prompt replies.

The system hang is unpredictable. When it reboots after the hang, there are no 
errors on "dmesg".
How and where can i find the relevant logs, errors which could help to 
troubleshoot this issue?

regards,
-Mathi

From: Salvatore Bonaccorso  on behalf of 
Salvatore Bonaccorso 
Sent: Tuesday, February 7, 2023 1:21 PM
To: Mathirajan S. Manoharan 
Cc: 1030...@bugs.debian.org <1030...@bugs.debian.org>
Subject: Re: Bug#1030741: firmware-brcm80211: Package firmware-brcm80211 not 
found in bookworm

Hi Mathi,

On Tue, Feb 07, 2023 at 06:45:03PM +, Mathirajan S. Manoharan wrote:
> Thank you very much. I was able to install this package
> firmware-brcm80211 to get the wifi card working on my pc.
>
> But i'm running into a strange problem now. The system freezes and
> reboots after a few seconds. I have never experienced anything like
> this with Linux past several years.
>
> If i boot into single user mode and uninstall this package
> firmware-brcm80211, the system functions normally.
>
> If i install firmware-brcm80211, this makes the system unstable. The
> system freezes and reboots.
>
> Should i file a new bug for this?

Not good :(

yes can you please fill a new bug for this issue, please make sure to
attach as well kernel dmesg from the system, ideally if we catch the
error.

Regards,
Salvatore

Bug#1030834: RM: gnome-video-arcade [mipsel] -- RoQA; build dependency mame no longer builds on mipsel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block 1030833 by -1

The build dependency mame no longer builds on mipsel.

Bug#1030833: RM: mame [mipsel] -- RoQA; no longer builds on mipsel

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: Cesare Falco , Jordi Mallach 


The package did not build on mipsel some time ago (see #983507),
then it built again, and now it's unbuildable again.

The problem is that the 2 GB address space are exhausted during linking,
despite all the usual tricks already applied to get below that.

Bug#1030832: RM: tinyarray [i386] -- RoQA; no longer builds on i386

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

The package no longer builds on i386, see #1017051 for background.

Bug#1014250: Dino Notification Sounds

[Martin]

On 2023-02-07 17:02, Quinn Stambaugh wrote:
> Did this get added? I started using the experimental branch and
> currently it doesn't have notification sounds

Sorry, I forget, that I planned to do that.
I wanted to ask upstream about their opinion first.
Will ask them tomorrow, if possible!

Bug#1027844: btrfsmaintenance: noted BTRFS_BALANCE_PERIOD default in /etc/default/btrfsmaintenance is inconsistent w/systemd timer

[Nicholas D Steeves]

Hi Andy!

Sorry for the delay, reply follows inline.

andy  writes:

> thanks for the feedback...  some comments inline.  i must stress that
> while i am a multi-year user of btrfs i do not read the linux-btrfs
> mailing list and my opinions should be given appropriate weight.

Thank you for your willingness to share your experience along with what
you'd like to see.  After all, what's the point if real-world users
aren't accommodated? :)

> On Sat, 2023-01-14 at 21:47 -0500, Nicholas D Steeves wrote:
[snip]
>> From what I've been able to gather, metadata balances have been
>> considered to be actively harmful for some time; This is mostly at
>> the level of tribal knowledge on the linux-btrfs mailing list.  It's
>> also the case that empty block groups are now automatically reclaimed
>> by the kernel, so a periodic balance only seems to be useful in
>> space-constrained situations where a lot of [meta]data churn occurs.
>
> regarding balance recommendations, my initial thought would be to make
> the language in the README.Debian stronger.

Would this be enough to guard naive users from potential data loss?  You
know, the people who read docs as an afterthought, or the "it will be
fine; it won't happen to me" crowd...  At the same time, I worry that
there might be a social cost to using stronger language (it could
demotivate developers or scare people off of trying btrfs).  What do you
think?

I agree, the docs should be updated; however, I'll also need to be
prepared to provide citations and reasoning.  To be honest, I'm trusting
a recurring upstream statements on the question of metadata rebalancing.

> i had read that "Some advocate not running it at all" but to me that
> implies "may be unnecessary" rather than "may be actively harmful."
> on the basis of the latter i am certainly considering setting the
> balance.timer back to disabled.

Btw, I'm curious to learn why you've enabled balancing!

The "may be actively harmful" bit is tricky, because Btrfs gets way too
complicated way too fast...  My hope to put in place safe defaults that
work for most people, that don't bait users/sysadmins into taking on
risk, and that are good enough for the general case.  Of course you know
that a solid enough replication and backup strategy makes it ok to take
risks for optimisation, but that's the "educated/experienced sysadmin"
class of cases ;)  If rebalancing does something like keeping database
performance from degrading, then it would be worth documenting this
somewhere, along with the fact that several core devs upstream have
written statements to the effect of this: never balance metadata, unless
necessary.  Rebalancing to a new profile counts as "necessary",
obviously, and the only other corner case I'm aware is noted two
paragraphs below.

> alternatively/additionally are there default options that might make
> it safe(r)?

I believe that [metadata] balancing should probably be disabled in
upstream btrfsmaintenance.  If I remember correctly, it's enabled by
default because upstream targets 10year LTS releases such as SUSE's 11
series, which uses linux 3.0.76, where the harm reduction of metadata
balancing is significant enough to make the risk worthwhile on
server-grade hardware.

> e.g., Marc MERLIN's
> `btrfs-scrub`[1] (which i used previously) suggested that "a null
> [metadata] rebalance should help corner cases."
>

Has that corner case existed since linux-3.18?

  https://btrfs.wiki.kernel.org/index.php/Balance_Filters

Or are you referring to cleaning up inefficient use of metadata after
a batch deletion of thousands of snapshots or subvolumes (all at once)?

> from my pov i'd still like to see the values harmonized.  i originally
> noticed the inconsistency because what i believed was the default
> setting was creating a seemingly unnecessary systemd override file.

Sorry, what is this "unnecessary systemd override file"?

> this became a nagging question to resolve :)  if the (informed) user
> has chosen to enable the btrfs-balance.timer then i would say harmonize
> the value at "monthly" (1/4 the opportunity for issues).
>

People are funny, because when you write or say "This is bad, you must
never do this, but if you do this, here is how to do it" the message
that is understood is "here is how to do it" ;)

>> Thus, if I do anything, I'm inclined to set the period for balance to
>> "none" everywhere.
>
> given that one already needs to manually enable the service via
> `systemctl enable btrfs-balance.timer` i don't think it's necessary to
> set the default value to "none."  this would result in the (imho)
> counter-intuitive behavior of enabling something only to have it do
> nothing.  although an add'l comment re: the potential for harm in
> `/etc/default/btrfs` that one would hopefully see when changing the
> value from "none" to e.g., "monthly" may be the best way to ensure that
> they are an informed user.  so i could go either way on that.
>

Good point, and yes, I agree that two knobs 

Bug#1014250: Dino Notification Sounds

[Quinn Stambaugh]

Hello,

Did this get added? I started using the experimental branch and
currently it doesn't have notification sounds

-- 
Thank you for your time.
Quinn Stambaugh

Phone: +1(316)347-8619
JID: qstamba...@mailbox.org

Social Media: https://mastodon.online/@qstambaugh

Bug#822733: tzdata: Drop /etc/timezone

[Michael Biebl]

Hi

Am 07.02.23 um 23:01 schrieb Aurelien Jarno:


2022g-3. You probably want to change d-i to not create that file.


Where specifically does d-i (i.e. which component)  create /etc/timezone?


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030801: xdaliclock no longer honors -font or -geometry command line switches

[Daniel Ramaley]

JWZ, thank you for the comment!

Your little program has been a constant part of my Linux desktop since around 
1998. And i had no idea that 2.46, which looks like a minor update from the 
version number, was such a major rewrite under the hood. In the past, i 
configured xdaliclock via a janky combination of window manager hints, 
Xresources, and command line switches. I just played with the new version 
though, and see that if i just resize the window that the font adjusts 
automatically, and if i place the clock where i want it, it will reopen at that 
spot the next time i run it. Perfect! No more need for the old way of 
configuring it. You're right, this is indeed better. Thank you for keeping this 
old program alive!

Bug#1030806: pypy3: autopkgtest failure

[Stefano Rivera]

Hi Adrian (2023.02.07_16:10:23_+)

Ah, I forgot to bump the test dependency version requirement for pip.
It'll pass with the new pip in unstable (which will migrate soon).

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#599884: speed-dreams: changing back from ITP to RFP

[Matthew Fennell]

retitle 599884 RFP: speed-dreams -- Open source motorsport simulation
noowner 599884
thanks

I'm reverting this back to an RFP, as the copyright and license information for
some files is difficult to establish.

Additionally, a lot of the art in the game makes use of the Free Art License.
As far as I understand, this license is not unambiguously DFSG-compatible.

>From a technical perspective, packaging this project was very easy, so I hope
this will not dissuade someone else from picking up this package if they are
interested.

Bug#1029536: wine64-stable ENOENT

[Jens Reyer]

On 07.02.23 14:22, Bernhard Übelacker wrote:

Dear Maintainer,
if one creates this wine64-stable just as a link to wine64,
then `wine64-stable wineboot` would start to work.

# ln -s wine64 /usr/lib/wine/wine64-stable

Kind regards,
Bernhard


(rr)
692 execv( argv[1], argv + 1 );
(rr) print argv[1]
$2 = 0x7e848400 "/usr/lib/wine/wine64-stable"
(rr) shell ls -lisah /usr/lib/wine/wine64-stable
ls: cannot access '/usr/lib/wine/wine64-stable': No such file or directory
(rr) bt
#0  preloader_exec (argv=argv@entry=0x7e8483d0) at 
dlls/ntdll/unix/loader.c:692
#1  0x7f5e1d159a6b in loader_exec (machine=34404, argv=0x7e8483d0) 
at dlls/ntdll/unix/loader.c:716
#2  __wine_main (argc=, argv=0x7ffd65438648, 
envp=0x7ffd65438660) at dlls/ntdll/unix/loader.c:2416

#3  0x7d001254 in main ()
(rr)


$ ls -lisah /usr/bin/wine64-stable /usr/bin/wine64 
/usr/lib/wine/wine64-stable /usr/lib/wine/wine64

ls: cannot access '/usr/lib/wine/wine64-stable': No such file or directory
674145   0 lrwxrwxrwx 1 root root  24 Jan 27 02:36 /usr/bin/wine64 -> 
/etc/alternatives/wine64
673301   0 lrwxrwxrwx 1 root root  18 Jan 27 02:36 
/usr/bin/wine64-stable -> ../lib/wine/wine64

673289 16K -rwxr-xr-x 1 root root 15K Jan 27 02:36 /usr/lib/wine/wine64


[Ex-maintainer here]

The -stable suffix was added for the Debian alternatives system. While I 
don't expect an issue with adding an /usr/lib/wine/wine64-stable link, I 
wonder if the whole issue is really a bug (still probably a regression, 
which I can't comment on since I'm not involved in current packaging) or 
wrong usage.


I don't know what you want to do exactly, but generally I (and afaik 
upstream) recommend to just call "wine", not "wine64". This will default 
to 64-bit anyway (supporting also 32-bit if "wine32" is installed).


To force 64 bit you may set "WINEARCH=win64".

To create a new wineprefix just issue "WINEARCH=win64 wineboot" (without 
"wine" or "wine64" in front).


Of course you need the "wine" package to be installed, which basically 
just contains the relevant wrappers and links. I see no reason to not 
install this recommended package. Comments welcome!


Without "wine" installed you may use
$ /usr/lib/wine/wine64 wineboot

If you install "wine64" and "wine", but not "wine32", you'll get a 
non-critical warning on STDERR:

~
it looks like wine32 is missing, you should install it.
as root, please execute "apt-get install wine32:i386"
~
You can disable this (and some Wine output by something like this:
$ WINEDEBUG="-all" wineboot


So I suggest:

docker run -it docker.io/debian:testing-slim
# apt update && apt install wine
# wineboot

Greets
jre

Bug#1030831: Please resolve issues related to the doc/ subdir

[Nicholas D Steeves]

Package: kotlin-mode
Version: 0.0~git20230123.fddd747-1
Severity: normal
X-Debbugs-Cc: s...@debian.org

Hi Josh,

Towards the end of packaging this snapshot, I found several issues:

1. Lintian warned about "doc/indentation_logic/.gitignore".  When
reenabling installation of docs, please ensure that this file does not
end up in the elpa-kotlin-mode package.

2. "pages.pdf" should be regenerated at build time.

2a. Also related to this a probable upstream bug: the doc's Makefile's
clean target removes pages.pdf; however, upstream's git repo includes
pages.pdf, which means the development repo is in an unclean state.
This means you'll need to do something clever when regenerating
pages.pdf, to avoid an FTBFS due to "unrepresentable changes to
source".  Considering the fourth objective, noted below, will provide
a hint about how to solve this in an elegant way.

3. It appears that the rest of this subdir tree exists to build
"pages.pdf".  If this is the case, then only the PDF should be
installed.  Consult Policy §12 for where to install it.  Don't worry
about §12.4

4. Pages.pdf should have a more useful name.

Best,
Nicholas

Bug#822733: tzdata: Drop /etc/timezone

[Aurelien Jarno]

On 2023-02-06 13:05, Benjamin Drung wrote:
> On Sun, 2023-01-29 at 15:45 +0100, Michael Biebl wrote:
> > Am 29.01.2023 um 15:38 schrieb Luca Boccassi:
> > > On Sun, 29 Jan 2023, 13:15 Michael Biebl,  > > > wrote:
> > > 
> > > Am 28.01.2023 um 02:12 schrieb Luca Boccassi:
> > >  > I'm looking at this again, because handling /etc/timezone is one
> > > of the
> > >  > last large technical debt patches that we carry in Debian for
> > >  > src:systemd, and we want to drop it for Trixie.
> > >  > The idea is to add a tmpfiles.d entry in the systemd package that
> > >  > unconditionally deletes /etc/timezone if present. If someone wants 
> > > to
> > >  > keep using it, they can simply override the tmpfiles.d entry with 
> > > the
> > >  > usual mechanisms.
> > >  >
> > >  > So, could you please reconsider the proposal to stop creating it
> > > if it
> > >  > doesn't exist (but keep updating if it does) in the tzdata
> > > postinst as
> > >  > above for Trixie?
> > > 
> > > I'm a bit confused: If you forcefully want to delete /etc/timezone
> > > via a
> > > tmpfiles snippet, why let tzdata update an existing /etc/timezone?
> > > 
> > > 
> > > Because it can be overridden as mentioned, so in case there are unknown 
> > > corner cases where it's still needed, a drop-in can be added to avoid 
> > > deleting the file and it will still get updated. In the future we can 
> > > then consider removing this as well.
> > > 
> > 
> > I would prefer, if all this is handled within tzdata.
> > - It should stop creating /etc/timezone
> > - It should delete /etc/timezone on upgrades as a one-time action

Note that this means that newly installed systems will still have
/etc/timezone, as they won't see the upgrade from versions older than
2022g-3. You probably want to change d-i to not create that file.

Aurelien

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

Bug#1030830: elpa-kotlin-mode: byte-compiling for emacs fails during installation

[Adrian Bunk]

Package: elpa-kotlin-mode
Version: 0.0~git20230123.fddd747-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/k/kotlin-mode/31139417/log.gz

...
Setting up emacs-nox (1:28.2+1-10) ...
update-alternatives: using /usr/bin/emacs-nox to provide /usr/bin/emacs (emacs) 
in auto mode
update-alternatives: using /usr/bin/emacs to provide /usr/bin/editor (editor) 
in auto mode
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install elpa-kotlin-mode for emacs
install/kotlin-mode-20230123: Handling install of emacsen flavor emacs
install/kotlin-mode-20230123: byte-compiling for emacs

In toplevel form:
kotlin-mode.el:37:1: Error: Cannot open load file: No such file or directory, 
kotlin-mode-indent
ERROR: install script from elpa-kotlin-mode package failed
...

Bug#1030126: gnome-bluetooth-sendto should take over gnome-bluetooth with a transitional package

[Jeremy Bícha]

On Tue, Jan 31, 2023 at 7:48 AM Simon McVittie  wrote:
> - upload src:gnome-bluetooth3 adding a gnome-bluetooth (>= 42) transitional
>   binary package before bookworm;
> - upload src:gnome-bluetooth removing the gnome-bluetooth binary package
>   before bookworm;
> - remove the transitional gnome-bluetooth package in trixie;
> - try to remove src:gnome-bluetooth completely in trixie

I instead am adding the gnome-bluetooth transitional package to the
old gnome-bluetooth source package.

This avoided hijacking a package name. I only realized afterwards that
hijacking packages actually doesn't go through the NEW queue but I
think it is reasonable to do it this way anyway. (Of course, both
source packages have the same maintainer so it's not an adversarial
hijack.)

Thank you,
Jeremy Bícha

Bug#1029292: lomiri-greeter: Depends: lomiri-system-compositor but it is not installable

[Mike Gabriel]

Hi Adrian,

On  Di 07 Feb 2023 18:17:42 CET, Adrian Bunk wrote:


On Fri, Jan 20, 2023 at 08:48:19PM +0200, Adrian Bunk wrote:

Package: lomiri-greeter
Version: 0.1~git20230111.ba0fc6a-4
Severity: serious

The following packages have unmet dependencies:
 lomiri-greeter : Depends: lomiri-system-compositor but it is not  
installable


As the version tracking of the BTS already correctly shows, 0.1-1 now in
unstable is based on 0.1~git20230111.ba0fc6a-4 and lacks this fix that
was in 0.1~git20230111.ba0fc6a-5.

cu
Adrian


thanks for pinging me on this. I now re-fixed #1029292 (nice bug  
number, in fact) by a follow-up upload.


@marius: please remember to git-push everything you upload  
immediately(!) to Salsa. The lomiri.git on Salsa wasn't the only repo  
that was not up-to-date. In fact, please check with  
https://tracker.debian.org/ all the packages you uploaded  
recently (or use the UBports Team DDPO page) and check where you might  
have local commits danling that might need pushing. Thanks.


I will file an unblock for this upload (0.1-2) in case it gets hit by  
the softfreeze testing-migration block.


@Adrian, thanks again for spotting these kinds of issues and reporting  
them immediately. Thanks for the QA work you do!!!

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp57FR9Ycy70.pgp
Description: Digitale PGP-Signatur

Bug#1027833: user-mode-linux: hostfs directory traversal

[Jakub Wilk]

* Ritesh Raj Sarraf , 2023-01-20 16:59:
The current upstream documentation does warn about the functionality, 
and does not advertise anything about confining the namespace.


Er, but it does talk about confinement:

Hostfs without any parameters to the UML Image will allow the image to 
mount any part of the host filesystem and write to it. Always confine 
hostfs to a specific "harmless" directory (for example ``/var/tmp``) if 
running UML. This is especially important if UML is being run as root.


--
Jakub Wilk

Bug#1030829: mmc-utils: FTBFS on ppc64el with error: ‘cnt’ may be used uninitialized

[Nick Rosbrook]

Package: mmc-utils
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear Maintainer,

In Ubuntu, mcc-utils FTBFS[1] on ppc64el with the following:

 In file included from /usr/include/endian.h:35,
  from /usr/include/powerpc64le-linux-gnu/sys/types.h:176,
  from /usr/include/stdlib.h:395,
  from mmc_cmds.c:21:
 In function ‘__bswap_32’,
 inlined from ‘do_rpmb_write_block’ at mmc_cmds.c:2462:27:
 /usr/include/powerpc64le-linux-gnu/bits/byteswap.h:52:10: error: ‘cnt’ may be 
used uninitialized [-Werror=maybe-uninitialized]
52 |   return __builtin_bswap32 (__bsx);
   |  ^
 mmc_cmds.c: In function ‘do_rpmb_write_block’:
 mmc_cmds.c:2439:22: note: ‘cnt’ was declared here
  2439 | unsigned int cnt;
   |  ^~~
 cc1: all warnings being treated as errors
 make[1]: *** [Makefile:36: mmc_cmds.o] Error 1
 make[1]: Leaving directory '/<>'
 dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" returned 
exit code 2
 make: *** [debian/rules:8: binary-arch] Error 25
 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2
 


This was already fixed upstream[2]. We applied the patch in Ubuntu to fix
the build on ppc64el.

Thanks,
Nick

[1] 
https://launchpadlibrarian.net/648312622/buildlog_ubuntu-lunar-ppc64el.mmc-utils_0+git20220624.d7b343fd-1_BUILDING.txt.gz
[2] 
https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git/commit/?id=5086e7c0de4d0094f8674368a88d931b27589d53
diff -Nru 
mmc-utils-0+git20220624.d7b343fd/debian/patches/0003-fix-warning-on-uninitialized-cnt.patch
 
mmc-utils-0+git20220624.d7b343fd/debian/patches/0003-fix-warning-on-uninitialized-cnt.patch
--- 
mmc-utils-0+git20220624.d7b343fd/debian/patches/0003-fix-warning-on-uninitialized-cnt.patch
 1969-12-31 19:00:00.0 -0500
+++ 
mmc-utils-0+git20220624.d7b343fd/debian/patches/0003-fix-warning-on-uninitialized-cnt.patch
 2023-02-07 15:14:11.0 -0500
@@ -0,0 +1,54 @@
+Description: mmc-utils: fix warning on uninitialized 'cnt'
+Origin: 
https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git/commit/?id=5086e7c0de4d0094f8674368a88d931b27589d53
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/mmc-utils/+bug/2006505
+Last-Update: 2023-02-07
+---
+From 5086e7c0de4d0094f8674368a88d931b27589d53 Mon Sep 17 00:00:00 2001
+From: Giulio Benetti 
+Date: Sun, 18 Sep 2022 18:17:51 +0200
+Subject: mmc-utils: fix warning on uninitialized 'cnt'
+
+When building following warning shows up:
+```
+In function '__bswap_32',
+inlined from 'do_rpmb_write_block' at mmc_cmds.c:2293:27:
+/home/autobuild/autobuild/instance-15/output-1/host/aarch64-buildroot-linux-gnu/sysroot/usr/include/bits/byteswap.h:52:10:
 error: 'cnt' may be used uninitialized [-Werror=maybe-uninitialized]
+   52 |   return __builtin_bswap32 (__bsx);
+  |  ^
+mmc_cmds.c: In function 'do_rpmb_write_block':
+mmc_cmds.c:2270:22: note: 'cnt' was declared here
+2270 | unsigned int cnt;
+  |  ^~~
+cc1: all warnings being treated as errors
+```
+This is due to function rpmb_read_counter() that doesn't set its
+argument 'unsigned int *cnt' in all return points. So let's set
+*cnt to 0 in the return point that misses to initialize it.
+
+Signed-off-by: Giulio Benetti 
+Reviewed-by: Avri Altman 
+Link: 
https://lore.kernel.org/r/20220918161751.1132590-1-giulio.bene...@benettiengineering.com
+Signed-off-by: Ulf Hansson 
+---
+ mmc_cmds.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/mmc_cmds.c b/mmc_cmds.c
+index ef1d8c6..29abd1d 100644
+--- a/mmc_cmds.c
 b/mmc_cmds.c
+@@ -2238,8 +2238,10 @@ int rpmb_read_counter(int dev_fd, unsigned int *cnt)
+   }
+ 
+   /* Check RPMB response */
+-  if (frame_out.result != 0)
++  if (frame_out.result != 0) {
++  *cnt = 0;
+   return be16toh(frame_out.result);
++  }
+ 
+   *cnt = be32toh(frame_out.write_counter);
+ 
+-- 
+cgit 
+
diff -Nru mmc-utils-0+git20220624.d7b343fd/debian/patches/series 
mmc-utils-0+git20220624.d7b343fd/debian/patches/series
--- mmc-utils-0+git20220624.d7b343fd/debian/patches/series  2022-08-04 
02:07:11.0 -0400
+++ mmc-utils-0+git20220624.d7b343fd/debian/patches/series  2023-02-07 
15:09:50.0 -0500
@@ -1,2 +1,3 @@
 0001-Fix-typo.patch
 0002-man-mmc.1-Fix-warning-macro-not-defined.patch
+0003-fix-warning-on-uninitialized-cnt.patch

Bug#970278: smartlist: please make the build reproducible

[Santiago Vila]

El 7/2/23 a las 22:30, Chris Lamb escribió:

As to why it remains unreproducible on i386 today, I can't immediately
see why that is happening. But I don't think it's related to the
rationale I gave above. I therefore think keeping this "- patch" and
"+ moreinfo" is correct.


Seems fair to me.

Thanks a lot.

Bug#970278: smartlist: please make the build reproducible

[Chris Lamb]

Santiago Vila wrote:

> Hi. To summarize: I'd appreciate a more detailed explanation about why
> the patch is needed (if it's needed at all at this point).

Hm, the difficulty here is that the packaging and the surrounding
toolchain has changed quite a bit since we filed this bug, and we
don't keep historical archives of diffoscope output.

Looking again at my patch, however, what I believe was happening in
the past was that the build user (or similar) was being embedded into
a binary or in some configuration file. This doesn't appear to be
happening anymore on amd64 in our testing framework, and neither does
it occur locally on my amd64 laptop. What I can say is that smartlist
was definitely unreproducible on my laptop back in 2020, otherwise I
would not have filed a patch.

As to why it remains unreproducible on i386 today, I can't immediately
see why that is happening. But I don't think it's related to the
rationale I gave above. I therefore think keeping this "- patch" and
"+ moreinfo" is correct.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1030828: src:wf-config: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Source: wf-config
Version: 0.7.1-2
Severity: serious
Control: close -1 0.7.1-3
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:wf-config has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package failed to build 
from source on s390x while it built there successfully in the past.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030741: firmware-brcm80211: Package firmware-brcm80211 not found in bookworm

[Salvatore Bonaccorso]

Hi Mathi,

On Tue, Feb 07, 2023 at 06:45:03PM +, Mathirajan S. Manoharan wrote:
> Thank you very much. I was able to install this package
> firmware-brcm80211 to get the wifi card working on my pc.
> 
> But i'm running into a strange problem now. The system freezes and
> reboots after a few seconds. I have never experienced anything like
> this with Linux past several years.
> 
> If i boot into single user mode and uninstall this package
> firmware-brcm80211, the system functions normally.
> 
> If i install firmware-brcm80211, this makes the system unstable. The
> system freezes and reboots.
> 
> Should i file a new bug for this?

Not good :(

yes can you please fill a new bug for this issue, please make sure to
attach as well kernel dmesg from the system, ideally if we catch the
error.

Regards,
Salvatore

Bug#1030676: pysdl2: autopkgtest failure on s390x

[Simon McVittie]

On Mon, 06 Feb 2023 at 13:00:22 +0100, Gianfranco Costamagna wrote:
> Hello, as shown in e.g. 
> https://ci.debian.net/data/autopkgtest/unstable/s390x/p/pysdl2/30731752/log.gz
> autopkgtests are failing probably due to a Big Endian issue

I don't think this is a real regression: the tests haven't passed on
s390x since 2021, at which point they were much shorter (30 seconds
rather than 2 minutes) and presumably had less coverage.

Given that pysdl2 is a game-related library and s390x machines are
~ $15K mainframes not known for their suitability for gaming, I'm not
convinced this should be RC.

On Tue, 07 Feb 2023 at 11:06:56 +, James Addison wrote:
> It looks like this has been fixed upstream in version 0.9.12 of the library.

I have intentionally not uploaded those versions to unstable when doing
team-uploads to stop it from regressing and blocking libsdl2, because
I have no good way to test them: nothing in Debian depends on pysdl2,
and I'm not actively using it for any non-Debian software.

Unfortunately backporting test fixes from newer versions tends to be a
pain because upstream have re-indented all the tests, but I'll see what
I can do.

smcv

Bug#1028602: transition: gnustep-base, gnustep-gui

[Sebastian Ramacher]

Control: tags -1 trixie

On 2023-01-29 09:41:30 +0200, Yavor Doganov wrote:
> Sebastian Ramacher wrote:
> > On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote:
> > > I realise we are already late and in all likelihood we've missed
> > > the last bookworm train, which is rather unpleasant for us and
> > > GNUstep users but entirely our fault.
> > 
> > I am not quite sure what you mean with unpleasant. What would be
> > unpleasant for GNUstep users?
> 
> I meant that in case the transition is postponed to trixie, bookworm
> will ship with old releases of core GNUstep.  It happened for bullseye
> when I missed to inform upstream about Debian's freeze/release
> schedule.  This time the upstream releases were made in time but we
> failed to meet the deadline again.

That's unfortunate timing and it's too late. Let's do this transition
early in the trixie release cycle.

Cheers
-- 
Sebastian Ramacher

Bug#1030827: FTBFS on armhf

[Sergio Durigan Junior]

Source: pspp
Severity: important
Version: 1.6.2-1

Hi,

pspp is currently FTBFSing on armhf due to several Perl-related tests
failing with:

--8<---cut here---start->8---
+PSPP.c: loadable library and perl binaries are mismatched (got first handshake 
key 0xa500080, needed 0xa400080)
--8<---cut here---end--->8---

You can see the build log by inspecting reproducible-build's page:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pspp.html

This has been reported upstream and is also affecting Ubuntu.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1030771: nmu: x11vnc_0.9.16-7

[Paul Gevers]

Control: tags -1 bullseye

Hi Mike,

On 07-02-2023 12:14, Mike Gabriel wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-rem...@lists.debian.org

nmu x11vnc_0.9.16-7 . ANY . bullseye . -m "Rebuild against libvncserver 
0.9.13+dfsg-2+deb11u1 which unfortunately introduced an ABI incompatibility and requires 
a rebuild of its consumers. (Closes: #1027043)."


You missed a tag. Adding it for you.

[12:04:16]  yes, file a binNMU bug and tag it bullseye

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030826: RM: libvcflib [armel armhf i386 powerpc x32] -- ROM; Does not work on 32bit architectures any more

[Andreas Tille]

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

Hi,

after discussing with upstream it was decided to provide libvcflib for
64bit only.  I've adapted the Architecture field in the last upload
accordingly.  Please remove the remaining 32bit builds.

Kind regards and thanks for your work as ftpmaster
   Andreas.

Bug#1030726: marked as pending in intelrdfpmath

[Roberto C . Sánchez]

On Tue, Feb 07, 2023 at 08:44:50PM +0100, Stephen Kitt wrote:
> 
> Yes, it seems like we’d really need a mips_macros.h implementation on MIPS.
> 
That was my suspicion as well.

> I enabled the test suite, and the result is basically that the library only
> works fully on amd64, i386 (nearly, with two test failures out of ~120,000
> test cases), and ia64, which matches the architectures which the library
> claims to support. On other architectures, the number of failures varies, up
> to 12.5% of test cases on s390x.
> 
> So really I should change the library to [amd64 i386 ia64]...
> 
That's unfortunate.

> Do you have a good way of validating whether the library is good enough for
> libmongocrypt’s purposes on non-Intel architectures?
> 
libmonogocrypt has a test suite, which we don't execute as part of the
package build because of upstream's robust CI.  However, we could
definitely enable it and it would be sufficient to let us know that the
library is adequate for what libmongocrypt needs.

That said, upstream is quite close validating that libmongocrypt works
with libdfp, so that might provide a near-term alternative if you decide
that the best thing to do from a quality perspective is to restrict the
architecture list of intelrdfpmath.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#1030670: Does not depend on libspng0

[Andrea Pappacoda]

Hi Jordi, thanks for the fast report!

On Mon Feb 6, 2023 at 12:09 PM CET, Jordi Mallach wrote:
> While trying to build against the new libspng-dev, I found that even my
> build was issuing -lspng, it would fail because it could not find it.
>
> It turns out you're missing a dependency against libspng0 itself.

Whoops, I wonder how I missed that. I thought lintian had a check for
this too, but aparently it doesn't.

> Additionally, I've seen the following too:
>
> - spng.pc declares:
>
> Requires.private: zlib
>
> If I understand correctly, this is not a public dependency, which means
> libspng-dev does not need to depend on zlib-dev. In fact, that's one of
> the features SPNG advertises.

Yeah, it's not part of the public interface (i.e. not exposed in the
header file), but it's still required to statically link to the library.
Not only that, but even if shared linking is required, pkg-config
requires all the Requires.private dependencies if the --cflags flag is
specified. If you try to remove zlib.pc and ask pkgconf to find spng,
here's what happens:

$ pkg-config --cflags --libs spng   
Package zlib was not found in the pkg-config search path.
Perhaps you should add the directory containing `zlib.pc'
to the PKG_CONFIG_PATH environment variable
Package 'zlib', required by 'spng', not found

In short, zlib-dev is a required dependency. As for what spng
advertises, yeah, you _can_ avoid zlib, but by using minz instead.

> - I would downgrade the Recommends on libspng-doc to a Suggests, to
>   avoid pulling in fonts and other unneeded packages on the 95% of
>   cases.

I'd prefer to keep it a recommendation instead. I find offline
documentation extremely important, as you don't always have internet
access; not only that, you can only grep it for what you're looking for,
etc, etc. Some make documentation part of the -dev package itself, but
with a Recommends it won't pulled in by a buildd, where it really is
unneeded.

That being said, I find pulling in an extra font package annoying too,
so I'll look into dropping that.

Thanks again for the report and suggestions! I've pushed the fix to
Salsa, and I'll do an upload ASAP.

Bug#1030825: less: CVE-2022-46663: -R filtering bypass

[Salvatore Bonaccorso]

Source: less
Version: 590-1.1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for less. The severity is
set on purpose to RC level, as I think the issue might ideally be
fixed for the bookworm release in advance.

CVE-2022-46663[0]:
| less -R filtering bypass

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-46663
https://www.cve.org/CVERecord?id=CVE-2022-46663
[1] https://github.com/gwsw/less/commit/a78e1351113cef564d790a730d657a321624d79c
[2] https://www.openwall.com/lists/oss-security/2023/02/07/7

Regards,
Salvatore

Bug#1030824: libhashkit-dev needs Breaks + Replaces: libhashkit2 (<< 1.1.3-1~)

[Ondřej Surý]

Thanks, on it, I didn't noticed that while converting the debian/*.manpages to 
debian/*.install.

Ondrej
--
Ondřej Surý (He/Him)
ond...@sury.org



> On 7. 2. 2023, at 20:38, Adrian Bunk  wrote:
> 
> Package: libhashkit-dev
> Version: 1.1.3-1
> Severity: serious
> 
> Unpacking libhashkit-dev:amd64 (1.1.3-1) over (1.0.18+-1+b1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-hcHxlW/19-libhashkit-dev_1.1.3-1_amd64.deb (--unpack):
> trying to overwrite '/usr/share/man/man3/hashkit_clone.3.gz', which is also 
> in package libhashkit2:amd64 1.0.18+-1+b1

Bug#902502: moblin-gtk-engine: Should this package be removed?

[Adrian Bunk]

Control: severity -1 serious
Control tags -1 bookworm sid

On Wed, Jun 27, 2018 at 11:36:02AM +0100, Simon McVittie wrote:
> Source: moblin-gtk-engine
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: proposed-removal
> 
> GTK+-2-only themes do not seem particularly useful now that the only
> supported web browsers in Debian (Firefox and Chromium) have switched
> to GTK+ 3, making it impractical to run a Debian desktop system without
> GTK+ 3.
> 
> (See also  and
> .)
> 
> This theme was part of the discontinued Moblin project, its upstream
> website has disappeared and it hasn't had a maintainer upload in Debian
> since 2010, so it seems highly unlikely that it will be updated for GTK+
> 3. Should it be removed from Debian?
>...

Raising the severity, aiming at removing this package from bookworm.

If anyone thinks this package is still useful, please close this bug.

> Thanks,
> smcv

cu
Adrian

Bug#1030726: marked as pending in intelrdfpmath

[Stephen Kitt]

On Mon, 6 Feb 2023 16:37:57 -0500, Roberto C. Sánchez 
wrote:

> And even with the build continuing on mips64el I see this:
> 
> float128/dpml_ux_trig.c: In function '__dpml_bid_ux_degree_reduce__':
> float128/dpml_ux_trig.c:254:9: warning: implicit declaration of function
> 'UMULH' [-Wimplicit-f unction-declaration]
>   254 | UMULH((UX_FRACTION_DIGIT_TYPE) exponent, RECIP_TWELVE, k);
>   | ^
> 
> 
> When I build libmongocrypt against the resulting libintelrdfp-math, the
> libmongocrypt will then fail at link time:
> 
> /usr/bin/ld:
> /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o):
> in function `__eval_pos_poly': (.text+0xe4): undefined reference to `UMULH'
> /usr/bin/ld: (.text+0xfc): undefined reference to `UMULH' /usr/bin/ld:
> (.text+0x144): undefined reference to `UMULH' /usr/bin/ld: (.text+0x160):
> undefined reference to `UMULH' /usr/bin/ld: (.text+0x168): undefined
> reference to `UMULH' /usr/bin/ld:
> /home/roberto/mips64el/intelrdfpmath-2.0u2/debian/libintelrdfpmath-dev/usr/lib/mips64el-linux-gnuabi64/libbidgcc000.a(dpml_ux_ops_64.o):(.text+0x17c):
> more undefined references to `UMULH' follow
> 
> It might be better to simply declare intelrdfpmath '[!mipsel
> !mips64el]'.  Sadly, my experience with Intel libraries (I maintained
> TBB in Debian for several years) is that they only put effort into the
> architectures that are important to them and that you can't assume that
> their code will work on other architectures.  That could well be the
> case here.

Yes, it seems like we’d really need a mips_macros.h implementation on MIPS.

I enabled the test suite, and the result is basically that the library only
works fully on amd64, i386 (nearly, with two test failures out of ~120,000
test cases), and ia64, which matches the architectures which the library
claims to support. On other architectures, the number of failures varies, up
to 12.5% of test cases on s390x.

So really I should change the library to [amd64 i386 ia64]...

Do you have a good way of validating whether the library is good enough for
libmongocrypt’s purposes on non-Intel architectures?

Regards,

Stephen


pgpt5tua0m1VP.pgp
Description: OpenPGP digital signature

Bug#774565: closing 774565

[Thorsten Glaser]

Sebastiaan Couwenberg dixit:

>> Why did you close the bug with no explanation?
>
> Because I filed it, and no longer care for OpenLayers 3 and the shit that is
> the Node.js ecosystem.

OK, fair.

> Control: submitter -1 Thorsten Glaser 

Also fair.

But other packages will want this, so let’s keep this open and
hope for a taker.

Thanks,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#1027244: scikit-learn Re: Are we still trying to do scipy 1.10, given transition freeze?

[Andreas Tille]

Am Tue, Feb 07, 2023 at 09:05:28AM +0100 schrieb Drew Parsons:
> On 2023-02-07 08:33, Graham Inggs wrote:
> > Hi Drew
> > 
> > I think python3-scipy should declare a Breaks on python3-skbio less
> > than the version in unstable (0.5.8-3).
> > This should sort out the autopkgtest regressions of emperor,
> > python-skbio itself, q2-metadata and q2-quality-control, which are all
> > passing in unstable, and allow scipy and python-skbio to migrate
> > together.
> 
> Ok, I'll add that with the gammapy patch.

Thanks a lot.
 
> > Python-cooler seems to have a different failure, and I don't see a bug
> > filed for it.
> 
> cooler seems to be fixed in experimental, I guess it just needs to be
> uploaded to unstable.

I'll do so

Thanks for the hint

 Andreas. 

-- 
http://fam-tille.de

Bug#1030824: libhashkit-dev needs Breaks + Replaces: libhashkit2 (<< 1.1.3-1~)

[Adrian Bunk]

Package: libhashkit-dev
Version: 1.1.3-1
Severity: serious

Unpacking libhashkit-dev:amd64 (1.1.3-1) over (1.0.18+-1+b1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-hcHxlW/19-libhashkit-dev_1.1.3-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man3/hashkit_clone.3.gz', which is also in 
package libhashkit2:amd64 1.0.18+-1+b1

Bug#812127: login: wrong German error message

[Markus Hiereth]

Package: login
Version: 1:4.8.1-1
Followup-For: Bug #812127

Dear Maintainer,

besides working on the German po-file for the shadow project manual 
pages, this old bug in the Debian bug database caught my attention. It 
is really simple to fix.

I'm afraid the po file of my colleague of the German language team, 
Holger Wansing (message #52) has not been introduced in the sources 
because, according to message #57, the developers worked on the newer 
version 4.9. This would be sad.

I'm quite sure that Holgers message catalogue could be merged somehow 
with the current one.

To fix at least the reported bug without further delay, I attach a patch 
file.

Best regards
Markus



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

Kernel: Linux 5.10.0-9-686-pae (SMP w/1 CPU thread)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages login depends on:
ii  libaudit1   1:3.0-2
ii  libc6   2.32-4
ii  libcrypt1   1:4.4.18-4
ii  libpam-modules  1.4.0-9+deb11u1
ii  libpam-runtime  1.4.0-9+deb11u1
ii  libpam0g1.4.0-9+deb11u1

login recommends no packages.

login suggests no packages.

-- Configuration Files:
/etc/login.defs changed [not included]

-- no debconf information
--- shadow-4.8.1/po/de.po   2020-01-23 21:59:53.0 +0100
+++ shadow-4.8.1_mh/po/de.po2023-02-07 20:10:14.028953232 +0100
@@ -1620,7 +1620,7 @@
 
 #, c-format
 msgid "%s: Cannot possibly work without effective root\n"
-msgstr "%s: Arbeit ohne effektive root-Rechte eventuell nicht möglich\n"
+msgstr "%s: Arbeit ohne effektive root-Rechte unmöglich\n"
 
 msgid "No utmp entry.  You must exec \"login\" from the lowest level \"sh\""
 msgstr ""

Bug#774565: closing 774565

[Sebastiaan Couwenberg]

Control: submitter -1 Thorsten Glaser 

On 2/7/23 19:53, Thorsten Glaser wrote:

Why did you close the bug with no explanation?


Because I filed it, and no longer care for OpenLayers 3 and the shit 
that is the Node.js ecosystem.


Kind Regards,

Bas

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

Bug#1018061: pads: segfault at 3a ip

[Tim McConnell]

New Backtrace: 

coredumpctl gdb -1
   PID: 1546 (pads)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Tue 2023-02-07 10:08:03 CST (3h 14min ago)
  Command Line: /usr/bin/pads -D -c /etc/pads/pads.conf
Executable: /usr/bin/pads
 Control Group: /system.slice/pads.service
  Unit: pads.service
 Slice: system.slice
   Boot ID: 90f7db29bc44436f8b4d1a2cbfc52a5c
Machine ID: dacda8ffae4a44148edc6518f73d4b00
  Hostname: DebianTim
   Storage:
/var/lib/systemd/coredump/core.pads.0.90f7db29bc44436f8b4d1a2cbfc52a5c.
1546.167578608300.zst (present)
  Size on Disk: 329.8K
   Message: Process 1546 (pads) of user 0 dumped core.

Module libsystemd.so.0 from deb systemd-252.5-2.amd64
Stack trace of thread 1546:
#0  0x5641638af954 print_arp_asset_screen (pads +
0x9954)
#1  0x5641638af6f0 print_arp_asset (pads + 0x96f0)
#2  0x7fa6dbe004f6 n/a (libpcap.so.0.8 + 0x84f6)
#3  0x7fa6dbe008ec n/a (libpcap.so.0.8 + 0x88ec)
#4  0x7fa6dbe07d1d pcap_loop (libpcap.so.0.8 +
0xfd1d)
#5  0x5641638a8e5b main_pads (pads + 0x2e5b)
#6  0x5641638a847b main (pads + 0x247b)
#7  0x7fa6dbc3718a __libc_start_call_main
(libc.so.6 + 0x2718a)
#8  0x7fa6dbc37245 __libc_start_main_impl
(libc.so.6 + 0x27245)
#9  0x5641638a84b1 _start (pads + 0x24b1)
ELF object binary architecture: AMD x86-64


-- 
Tim McConnell 

On Tue, 2022-09-27 at 10:32 +0200, Bernhard Übelacker wrote:
> Hello Tim,
> I tried to have a look at those two dmesg lines and it seems
> they point to the function print_arp_asset_screen, line 115 [1],
> where parameter rec is dereferenced unconditionally.
> 
> However, if it would be possible to install systemd-coredump then
> a backtrace of those crashes should be printed to the journal.
> This would give a way better information as the two dmesg lines
> alone,
> as it would also show the functions calling print_arp_asset_screen
> and therefore leading to the crash.
> 
> The link [2] might give some more hints to collect
> more information for the maintainer.
> 
> Kind regards,
> Bernhard
> 
> 
> [1]
> https://sources.debian.org/src/pads/1.2-13/src/output/output-screen.c/#L115
>  112 print_arp_asset_screen (ArpAsset *rec)
>  113 {
>  114 /* Print to Screen */
>  115 if(rec->mac_resolved != NULL) {
>  116fprintf(stdout, "[*] Asset Found:  IP Address - %s /
> MAC Address - %s (%s)\n",
> 
> [2] https://wiki.debian.org/HowToGetABacktrace

Bug#1023850: do not require dbus, use default-dbus-system-bus | dbus-system-bus

[Simon McVittie]

Control: forwarded -1 
https://salsa.debian.org/multimedia-team/rtkit/-/merge_requests/2
Control: tags -1 + patch

On Fri, 11 Nov 2022 at 13:23:15 +0100, Dominick Grift wrote:
> rtkit currently depends on package dbus. This package pulls in package
> dbus-daemon.
> 
> this behavior is not desired on systems that use package dbus-broker
> instead of package dbus-daemon.

Please see attached, also available as part of a merge request at the
URL above.

The patch will have some conflicts if the accompanying patch in #1025609
is not applied first, but those will be trivial to resolve.

Thanks,
smcv
>From f9f4f522f3634ba853c4926f42f3497429ab16e1 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 7 Feb 2023 16:35:44 +
Subject: [PATCH 2/2] d/control: Depend on default-dbus-system-bus |
 dbus-system-bus

This allows systems that use dbus-broker to install rtkit without also
installing dbus (the reference dbus-daemon).

Closes: #1023850
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 628b362..d68ddb4 100644
--- a/debian/control
+++ b/debian/control
@@ -23,7 +23,7 @@ Package: rtkit
 Architecture: any
 Depends:
  adduser,
- dbus,
+ default-dbus-system-bus | dbus-system-bus,
  polkitd | policykit-1,
  ${misc:Depends},
  ${shlibs:Depends}
-- 
2.39.1

Bug#1025379: Bug#1025554: colord: dependency on transitional policykit-1 package

[Simon McVittie]

Control: forwarded -1 https://salsa.debian.org/debian/colord/-/merge_requests/3
Control: tags -1 + patch

On Tue, 06 Dec 2022 at 13:17:50 +, Simon McVittie wrote:
> This package has a Depends on the transitional package policykit-1, which
> has been separated into polkitd, pkexec and (deprecated) polkitd-pkla
> packages. Its Build-Depends seems to have already been replaced with
> polkitd, which might have been a previous partial fix for this bug.

Please see the attached patches, also available as a merge request at the
link above.

While preparing the first patch, I noticed that the installed-tests
probably only work if polkitd-pkla is installed, but they can easily be
adapted to work without that package (that's the second patch).

> If this package communicates with polkitd via D-Bus, please represent that
> as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
> for the strength of the requirement.

It looked like this package only needs polkitd...

> If this package runs /usr/bin/pkexec, please represent that as a Depends,
> Recommends or Suggests on pkexec, whichever is appropriate for the strength
> of the requirement.

... and not pkexec. Not pulling in pkexec would be a good piece of
security hardening, since pkexec is a setuid-root executable that has
had CVEs in the past.

> For packages that are expected to be backported to bullseye, it's OK to
> use an alternative dependency: polkitd | policykit-1 and/or
> pkexec | policykit-1.

I used the alternative dependency in the interests of being minimally
disruptive.

> This is part of a mass bug filing, see
> .

If my recent team upload of malcontent migrates to testing, this is one of
only 3 remaining source packages that would need similar changes to stop
including policykit-1 in new installations of a Debian 12 GNOME desktop
(the others are rtkit and synaptic). I haven't yet tried the equivalent
with other desktop environments.

smcv
>From 187c197a80b9d81f36b346fbca521a3eb06ee095 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 7 Feb 2023 16:47:01 +
Subject: [PATCH 1/2] d/control: Depend on polkitd | policykit-1, not just
 policykit-1

This allows colord to be installed without pulling in the transitional
package policykit-1.

Closes: #1025554, #1025379
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 11a74489..726e67a1 100644
--- a/debian/control
+++ b/debian/control
@@ -77,7 +77,7 @@ Depends:
  acl,
  adduser,
  colord-data,
- policykit-1 (>= 0.103),
+ polkitd | policykit-1 (>= 0.103),
  ${misc:Depends},
  ${shlibs:Depends},
 Suggests:
-- 
2.39.1

>From 50b64ce0a3046a2ebc847ef711f03d2b32e04348 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 7 Feb 2023 16:50:47 +
Subject: [PATCH 2/2] d/tests/installed-tests: Make the rules override work
 without polkitd-pkla

Installing policykit-1 is no longer guaranteed to provide support for
the legacy .pkla rules language.
---
 debian/tests/installed-tests | 2 +-
 debian/tests/overrides/99-allow-all-colord.pkla  | 4 
 debian/tests/overrides/99-allow-all-colord.rules | 9 +
 3 files changed, 10 insertions(+), 5 deletions(-)
 delete mode 100644 debian/tests/overrides/99-allow-all-colord.pkla
 create mode 100644 debian/tests/overrides/99-allow-all-colord.rules

diff --git a/debian/tests/installed-tests b/debian/tests/installed-tests
index 0ebf55ce..abf98144 100755
--- a/debian/tests/installed-tests
+++ b/debian/tests/installed-tests
@@ -3,7 +3,7 @@ set -eu
 
 # Override polkit checks for colord daemon. Normally this would allow
 # locally-logged-in users to do things, but our autopkgtest user isn't locally-logged-in.
-cp debian/tests/overrides/99-allow-all-colord.pkla /etc/polkit-1/localauthority/90-mandatory.d
+cp debian/tests/overrides/99-allow-all-colord.rules /etc/polkit-1/rules.d/
 
 mkdir -p /etc/systemd/system/colord.service.d/
 cp debian/tests/overrides/colord.service /etc/systemd/system/colord.service.d/10-add-dummy-sensor.conf
diff --git a/debian/tests/overrides/99-allow-all-colord.pkla b/debian/tests/overrides/99-allow-all-colord.pkla
deleted file mode 100644
index 18019af3..
--- a/debian/tests/overrides/99-allow-all-colord.pkla
+++ /dev/null
@@ -1,4 +0,0 @@
-[Allow All for Tesnting]
-Identity=unix-user:*
-Action=org.freedesktop.color-manager.*
-ResultAny=yes
diff --git a/debian/tests/overrides/99-allow-all-colord.rules b/debian/tests/overrides/99-allow-all-colord.rules
new file mode 100644
index ..b13fa6a3
--- /dev/null
+++ b/debian/tests/overrides/99-allow-all-colord.rules
@@ -0,0 +1,9 @@
+polkit.addRule(function(action, subject) {
+if (action.id.indexOf("org.freedesktop.color-manager.") === 0) {
+return polkit.Result.YES;
+}
+
+return polkit.Result.NOT_HANDLED;
+});
+
+// vim:set ft=javascript:
-- 
2.39.1

Bug#1020641: dhcpcd5: dhcpcd fails to chroot during start

[Martin-Éric Racine]

On Tue, Feb 7, 2023 at 8:07 PM Pásztor János  wrote:
> Now that explains why wpa_supplicant can communicate over its socket
> and says that the file is not found. I think with that we have reached
> a conclusion. Without a major refactor in both wpa_supplicant and
> dhcpcd this will not work.
>
> Our options are the following I think:
>
> a.) leave out Privatetmp from the unit file
>
> b.) leave in Privatetmp from the unit file and document down that one
> has to start wpa_supplicant via different means, e.g.: as a separate
> systemd unit

I'll just leave out PrivateTmp for now. If anyone ever figures out a
non-disruptive way to reintroduce it, we can return to that later.

> In the end we have managed to keep much of the hardening in place,
> which is a good this as dhcpcd is a bunch of C code which parses
> untrusted input from the network, and I am graceful for the extra
> safety net what systemd provides.

Yes, we have still retained most of the hardening. We didn't even have
any in 7.1.0, so that's already an improvement over what's in stable
and oldstable.

Major thanks for putting in the time to debug this!

Martin-Éric

Bug#1020598: Bug#1025609: rtkit: dependency on transitional policykit-1 package

[Simon McVittie]

Control: forwarded -1 
https://salsa.debian.org/multimedia-team/rtkit/-/merge_requests/2
Control: tags -1 + patch

On Tue, 06 Dec 2022 at 15:35:53 +, Simon McVittie wrote:
> This package has a Depends and/or Build-Depends on the transitional
> package policykit-1, which has been separated into polkitd, pkexec and
> (deprecated) polkitd-pkla packages.

Please consider the attached patch, also available in
https://salsa.debian.org/multimedia-team/rtkit/-/merge_requests/2.

> If this package communicates with polkitd via D-Bus, please represent that
> as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
> for the strength of the requirement.

It looked like a Depends is appropriate here.

> If this package runs /usr/bin/pkexec, please represent that as a Depends,
> Recommends or Suggests on pkexec, whichever is appropriate for the strength
> of the requirement.

It looks like this particular package does not use pkexec.

> For packages that are expected to be backported to bullseye, it's OK to
> use an alternative dependency: polkitd | policykit-1 and/or
> pkexec | policykit-1.

I used the alternative dependency in the interests of a minimally
disruptive change.

> This is part of a mass bug filing, see
> .

If my recent team upload of malcontent migrates to testing, this is one
of only 3 remaining source packages that would need similar changes to
stop including policykit-1 in new installations of a Debian 12 GNOME
desktop (the others are colord and synaptic). I haven't yet tried the
equivalent with other desktop environments.

Thanks,
smcv
>From ca2e12d3b3ac856b784cf772489fbdc08e145072 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 7 Feb 2023 16:55:29 +
Subject: [PATCH] d/control: Depend on polkitd and pkexec in preference to
 policykit-1

This allows synaptic to be installed without the policykit-1
transitional package (and therefore the legacy polkitd-pkla package),
especially in new installations.

Closes: #1025630
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 4c8af3a5..0a7ec3ce 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Vcs-Browser: https://github.com/mvo5/synaptic
 
 Package: synaptic
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, policykit-1
+Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, polkitd | policykit-1, pkexec | policykit-1
 Recommends: libgtk3-perl, xdg-utils
 Suggests: dwww, deborphan, apt-xapian-index, tasksel, software-properties-gtk
 Description: Graphical package manager
-- 
2.39.1

Bug#1030823: rust-inotify: please provide v0.10

[Jonas Smedegaard]

Source: rust-inotify
Version: 0.9.6-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please either upgrade to or separately provide newer minor upstream
release branch v0.10.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmPiocMACgkQLHwxRsGg
ASGq+w/+N0cHZC1Q68WeIYGHIPiLCMNYsB+jCcjDx3XBhz/0yni8SfPqWXs8g5pS
WyY/YGLHP3vthVAHIdvo6/ILkGuJkRL+KkqMJuFdrYVdZvIx3BSMqkd3mRYUM1D9
AXgXtsAif73t5laKIlVLD/KFnrralBBFyYcnVuK6OSvqBSwpZSiMZpiai4wFhInp
Q43PCOp+uGsPzNFYH+ThF6mV2QRhKeO6CObTt3AWT1Wj2vvJc8VXIdoVl1TxtSgs
GudoxF6QCXii9NNhgAtYZ2OBptB9Ghz7fCk8C6J5gx4gaPTGV3UyZV6ZU7dos01b
5FbiYhGyEUjlS9F7KQ6cVP0m8FXQ1woZSg/GFMXZqLHh1aPAi3xuREsMUpFbjzUK
XZhj5s7LbUupOoK0CsJWIXDqHBHQlv39+Sk75obmLw52m4tdewMMhnBkOLEbCamb
yhH+FPK53jcr6H5S2muQg/lqR1X/oCSHF7WKua1f8fCo1pBv1x2bqNhO8efYAOvL
TXgW8yyP8s7PttExiSUvN0bLvu1BxA4R+VYp/fJpTwem475rPpgYqLg6K7Qp3QZT
8S1Uzhu0X6KEXFb8ei+HbmY4Ms0x1PDVHWncqt3GB3X0O08ENUCytuRSSLzfAqxi
sw9zkjUqircaxypgsaJDb7339Y1kXBXBGAa1Y0xxsHrZyTEHpd0=
=ngKX
-END PGP SIGNATURE-

Bug#1025630: synaptic: dependency on transitional policykit-1 package

[Simon McVittie]

Control: forwarded -1 https://github.com/mvo5/synaptic/pull/109
Control: tags -1 + patch

On Tue, 06 Dec 2022 at 18:58:56 +, Simon McVittie wrote:
> This package has a Depends and/or Build-Depends on the transitional
> package policykit-1, which has been separated into polkitd, pkexec and
> (deprecated) polkitd-pkla packages.

Please see the attached patch, also available as a pull request at the
link above.

> If this package communicates with polkitd via D-Bus, please represent that
> as a Depends, Recommends or Suggests on polkitd, whichever is appropriate
> for the strength of the requirement.
> 
> If this package runs /usr/bin/pkexec, please represent that as a Depends,
> Recommends or Suggests on pkexec, whichever is appropriate for the strength
> of the requirement.

It looked like synaptic does both of these, so I added both dependencies.

> For packages that are expected to be backported to bullseye, it's OK to
> use an alternative dependency: polkitd | policykit-1 and/or
> pkexec | policykit-1.

I used the alternative dependency, in the interests of minimally
disruptive changes.

> This is part of a mass bug filing, see
> .

If my recent team upload of malcontent migrates to testing, this is one of
only 3 remaining source packages that would need similar changes to stop
including policykit-1 in new installations of a Debian 12 GNOME desktop
(the others are colord and rtkit). I haven't yet tried the equivalent
with other desktop environments.

Thanks,
smcv
>From ca2e12d3b3ac856b784cf772489fbdc08e145072 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 7 Feb 2023 16:55:29 +
Subject: [PATCH] d/control: Depend on polkitd and pkexec in preference to
 policykit-1

This allows synaptic to be installed without the policykit-1
transitional package (and therefore the legacy polkitd-pkla package),
especially in new installations.

Closes: #1025630
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 4c8af3a5..0a7ec3ce 100644
--- a/debian/control
+++ b/debian/control
@@ -12,7 +12,7 @@ Vcs-Browser: https://github.com/mvo5/synaptic
 
 Package: synaptic
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, policykit-1
+Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, polkitd | policykit-1, pkexec | policykit-1
 Recommends: libgtk3-perl, xdg-utils
 Suggests: dwww, deborphan, apt-xapian-index, tasksel, software-properties-gtk
 Description: Graphical package manager
-- 
2.39.1

Bug#1030822: rust-cookie-store: please provide v0.19

[Jonas Smedegaard]

Source: rust-cookie-store
Version: 0.16.1-2
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please either upgrade to or separately provide newer minor upstream
release branch v0.19.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmPioIMACgkQLHwxRsGg
ASGqGA//UpjHCYg+A1KD02fHusomzsI/4RvsPLSRx/j+9rt9vHU+3xTFHCXXAtCF
BbEumYtNDKk0Jbd2OBsOCf3w2l0Y8YHYw83++nOMKliXUwiwMUyDJ2vvlmgKH2/K
dwlGCmmks73w35m3Hyr+6j632dZoJK73HCAPcW7q1508WY4k2Aw9dOIglUv2DyeT
TltFFQrYT5MHenSmSQyn3Vq+1sg8qUvKoQY9x/Vn4aDGlFB1eeoxmYeyXMzJKca5
4LCYESBHpthnCXZWS8GNJsRe0oEUZNf+jFqICgPlaN/nyH7MyvKPTaDzGwOQT6ze
dWmkskmXfq4MndW3MY05sWMWFysOHMHQmNRCWVLlBbXbq0Oe8oqotpGCG/slEYl3
yCpCysxeQy0iSZCuKyfKxLUQRuxevg1Mjp9HcS9N5DFFC6Ue4i/eJtcFlead94jm
p8Rf8x2pIcQcEBx6g+kyD2GRM3bzdYqFBStEYMfUAo2dHGBa/J9IADMYDqsxbiDx
dvc7EZElOLZHxOWQvAzmSZ0HKZY4Znczyy8nqZoofUgSGJN9RUosvZKvfJXXkptj
+kjfG2fbleDZWXN3NzEDhdGukguUsORW97ndwRowjHrUUTQkF647RlLVfnkuyXvw
v32XNwhEFW50ycQjqerhal6k/Po+9h+WhicQ1r/crl5WPnYCt00=
=36d4
-END PGP SIGNATURE-

Bug#1030801: xdaliclock no longer honors -font or -geometry command line switches

[Jamie Zawinski]

Things change. Intentionally. It's better now. Adjust and move on with your 
life.

Bug#1030821: /usr/bin/wg-quick: Saves unrelated nameservers when used with resolvconf and SaveConfig=true

[arnold metselaar]

Package: wireguard-tools
Version: 1.0.20210914-1+b1
Severity: normal
File: /usr/bin/wg-quick

Dear Maintainer,

I have been using wg-quick in combination with resolvconf and the option
SaveConfig=true to make a tunnel between two hosts.
After some time the connection was no longer established; there were too
many DNS-lines /etc/wireguard/wg0.conf.

When wg-quick saves the configuration for a tunnel it uses "resolvconf -l
" to list the DNS configuration for a
specific interface, however the version of the resolvconf program in the
package resolvconf does noet support this.
Consequently wg-quick saves the nameservers supplied with the tunnel as
well as all the other ones and the configuration
file grows every time the tunnel is brought down e.g. when powering off the
system.

Using openresolv rather than resolvconf solves the issue, so arguably this
is a bug in resolvconf rather than in wg-quick.
I have not tried it with systemd-resolved.

As long as this has not been fixed, I think wireguard-tools should document
this behaviour somewhere and stop suggesting
resolvconf.

Kind regards,
Arnold Metselaar

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

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

Versions of packages wireguard-tools depends on:
ii  libc6  2.36-8

Versions of packages wireguard-tools recommends:
ii  iptables   1.8.9-2
ii  linux-image-amd64 [wireguard-modules]  6.1.8-1
ii  nftables   1.0.6-2

Versions of packages wireguard-tools suggests:
ii  resolvconf  1.91+nmu1

-- no debconf information

Bug#1030785: -ffile-prefix-map option and reproducibility

[Sven Joachim]

On 2023-02-07 17:50 +0100, Guillem Jover wrote:

> On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote:
>> When building packages, a -ffile-prefix-map option is automatically injected
>> into CFLAGS. Where does it come from? Since when?
>
> This is coming from dpkg-buildflags (in this case probably indirectly
> via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default,
> and then switched to enabled by default in dpkg 1.20.6 (see #974087).
>
>> I suspect this was added to improve reproducibility. Ironically, it makes
>> packages that capture this variable non reproducible, since the build path
>> seems to be randomized (has it always been the case? since when?). It is the
>> case of OCaml (see #1030785), and seemingly of R as well (found by grepping
>> in my /etc). I wouldn't be surprised other packages are affected as well.
>
> AFAIR this was considered at the time, yes. If the flag is effectively
> not fixing anything for the set of packages involved, and is in fact
> actually making them unreproducible when they would not then, you can
> disable the fixfilepath feature in the reproducible build flags area,
> via DEB_BUILD_MAINT_OPTIONS.

This does not help for packages which capture all build flags and store
them in some file in the package (as is the case here).  With
DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath, dpkg-buildflags falls
back to "-fdebug-prefix-map==.", and you have the same
problem.  If you disable that as well via
DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath, the
-dbgsym packages will most likely end up unreproducible.

Cheers,
   Sven

Bug#1030820: tightvncserver: Manages alternatives symlinks related to tightvncpasswd

[Sven Geuer]

Package: tightvncserver
Version: 1:1.3.10-6
Severity: normal

Dear Maintainer,

the tightvncserver package manages alternatives symlinks per
d/tightvncserver.postinst

update-alternatives --install \
$BIN/vncpasswd  vncpasswd$BIN/tightvncpasswd 70 \
--slave \
$MAN/vncpasswd.1.gz vncpasswd.1.gz   $MAN/tightvncpasswd.1.gz

and per d/tightvncserver.prerm

update-alternatives --remove \
vncpasswd $BIN/tightvncpasswd
update-alternatives --remove \
vncpasswd $BIN/tightvncpasswd


This should be moved to respective scripts of the tightvncpasswd package
instead.


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

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

Versions of packages tightvncserver depends on:
ii  libc62.36-8
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libx11-6 2:1.8.3-3
ii  perl 5.36.0-7
ii  tightvncpasswd   1:1.3.10-6
ii  x11-common   1:7.7+23
ii  x11-utils7.7+5
ii  xauth1:1.1.2-1
ii  xserver-common   2:21.1.6-1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages tightvncserver recommends:
ii  x11-xserver-utils  7.7+9+b1
ii  xfonts-base1:1.0.5+nmu1

Versions of packages tightvncserver suggests:
ii  tightvnc-java  1.3.10-4

-- no debconf information

Bug#774565: closing 774565

[Thorsten Glaser]

affects 774565 src:dygraphs
thanks

Bas Couwenberg dixit:

>close 774565 
>thanks

Why did you close the bug with no explanation? According to
https://packages.debian.org/search?keywords=jsdoc this is still
pertinent, so I’m assuming you typo’d the number or something
and accidentally closed the wrong bug.

I just saw one member vanish from the documentation because I
added an “export” in front, so jsdoc3 is *direly* needed in Debian.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

Bug#1009187: calendar: Outdated entry "Jul 22 National Day in Poland"

[Jakub Wilk]

* Andrzej A. Filip , 2022-04-08 15:14:

"Jul 22 National Day in Poland" is no longer valid.
[File /usr/share/calendar/calendar.holiday line 302 ]


How embarrassing. It was a communist holiday, which was abolished in 
1990:

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

As a data point, OpenBSD fixed this in 2006:
https://github.com/openbsd/src/commit/7eadb65f7d736d8a

--
Jakub Wilk

Bug#1030819: rust-clap: please upgrade to v4.0.32

[Jonas Smedegaard]

Source: rust-clap
Version: 4.0.29-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to newer upstream release v4.0.32.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmPinrAACgkQLHwxRsGg
ASEbjxAAkxl2eJ0o3QV6FC+8SOpBbbvMHwrM3olxgCJgbcKExJouzNmarulXqigZ
VXzcOertsrdfS/NDUjVjrJWBojGcrF+NbfrVvIdXAJ+7xdSsu+F5OjGJG10Sfjfy
f3kOwWsHlezngiIe7K5fQjRgl/1aScpHyhtH8TBMSniXiKpqPHF3bvpUHR9/N+ow
IAQBhcV/Es50TFzrdDY8TcUrmzS9VK5wwp+j5yiVVBOsOnNlZ1Pzr46sjl/wXXVP
ClXmXALjuQpMfRVoHFjsG6NbhJ+gB8q5WGvonC+kdgbrcIPubeErxWrhYLgcAXEP
W8Zba1Su1mUjaHaLAReXy+d9hUOzCABfTMNrnwFL+zNEN8Doq+QGZxAT+8CkCWgd
TpOmhwVK7s5nAB7V3GNc2eNfiQMtA0KhiAQsCpv5vpLqVLUPQvfGpIiph5qRBLTz
CM90u9s4ESENsY8+IXGztkAmK9o4l3VvNYc/gcC6dlrLKs/hskD+7nyHIt/+S3g9
wZLEY8YS38kMBIFCJKDxNXYI1AfX61nYGC4s8nS1yfqs1xUml4UhbkhHVn+SSWSH
Q3mYNcg6lJuOkjhKOnJe2afMX/Nha4B8Sgyq2wgj3Ug3GmoaZ5jb5IsJn24jwAMe
QTyX1EeZblyBzSLqS/xsSNsWdoRjPmjJl3v54w/ozc10u+FZOhM=
=UCas
-END PGP SIGNATURE-

Bug#1030818: 3.11.1 and 3.11.2 orig.tar.xz in debian are identical, by accident?

[Daniel Baumann]

Package: python3.11
Severity: normal

Hi,

the last upload of python3.11 claims to be of version 3.11.2, yet, it's
the same as 3.11.1:

daniel@daniel:~$ wget
https://deb.debian.org/debian/pool/main/p/python3.11/python3.11_3.11.1.orig.tar.xz
--2023-02-07 19:44:22--
https://deb.debian.org/debian/pool/main/p/python3.11/python3.11_3.11.1.orig.tar.xz
Resolving deb.debian.org (deb.debian.org)... 151.101.242.132,
2a04:4e42:39::644
Connecting to deb.debian.org (deb.debian.org)|151.101.242.132|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 19856648 (19M) [application/x-xz]
Saving to: ‘python3.11_3.11.1.orig.tar.xz’

python3.11_3.11.1.o 100%[===>]  18.94M  29.2MB/sin
0.6s

2023-02-07 19:44:23 (29.2 MB/s) - ‘python3.11_3.11.1.orig.tar.xz’ saved
[19856648/19856648]

daniel@daniel:~$ wget
https://deb.debian.org/debian/pool/main/p/python3.11/python3.11_3.11.2.orig.tar.xz
--2023-02-07 19:44:26--
https://deb.debian.org/debian/pool/main/p/python3.11/python3.11_3.11.2.orig.tar.xz
Resolving deb.debian.org (deb.debian.org)... 151.101.242.132,
2a04:4e42:39::644
Connecting to deb.debian.org (deb.debian.org)|151.101.242.132|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 19856648 (19M) [application/x-xz]
Saving to: ‘python3.11_3.11.2.orig.tar.xz’

python3.11_3.11.2.o 100%[===>]  18.94M  28.0MB/sin
0.7s

2023-02-07 19:44:27 (28.0 MB/s) - ‘python3.11_3.11.2.orig.tar.xz’ saved
[19856648/19856648]

daniel@daniel:~$ sha256sum python3.11_3.11.*.orig.tar.xz
85879192f2cffd56cb16c092905949ebf3e5e394b7f764723529637901dfb58f
python3.11_3.11.1.orig.tar.xz
85879192f2cffd56cb16c092905949ebf3e5e394b7f764723529637901dfb58f
python3.11_3.11.2.orig.tar.xz
daniel@daniel:~$

Regards,
Daniel

Bug#1030817: rust-clap: please update to v4.1.1

[Jonas Smedegaard]

Source: rust-clap
Version: 4.0.29-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to newer upstream release v4.1.1.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmPim+oACgkQLHwxRsGg
ASELVw//c/3Y6lf74x8+LTYuFjeM5o/2bRJfgRw+3in4B7/YRbwZqhBjoyBMrtw1
BKF6NHyW5HpTtgteDu7xFMAAyVe9cxKJ9+CFov4rlO9jvseGYfmDZzugix+vPs0O
14NSdEEMinOA2e13H1DcZno6+grryctkM4xyUG8xEtyVt7muG65hQKlUwzRyUYrM
2mSlPRyyi6Wx3DvWtNa7lS8/LVlDF+5qzqHQO7rS47QT/bw5NC0fNWhWSBX1S4BC
h6sm42Wt6fNOuKxcd6bADfYBBIPoq1SKp24Yjx3Wq3xWyrbXtrBB7SESdW6avvLA
wK+96lsfha1bxHXwpx6gtUvr7na1SP8NUZ92SmXPCRSndM3oMm6Hc+f9kFYSVssf
JZccT0VQI0ocSxay9HM4GNrmV+k06O8hxE/KKRxUFP9bemRdVnqZuzID5URbUTDs
d8t+S8dyam3+z45x7h2/Lpy0OmmpuHt3A/x/Aj1WhrQWjhJM+AygvZE3xHQlMj5q
WErOCxqF5yhp722JOvqDXkJWLz4rmp3CwwiO9hwGUl0rAFqb1OP5r+p1DlSTcwPw
/63CITo8s6zras3UOm6cqyfcfpqXjxLabiThSY2rSzrcaqTaHvtxwwb4sBsX6BbT
ZsT61pcqKLJ7fVScMu/OlBoa9LmMqa8YeQbmnxlkxW3VWNayXrs=
=K3sq
-END PGP SIGNATURE-

Bug#1030741: firmware-brcm80211: Package firmware-brcm80211 not found in bookworm

[Mathirajan S. Manoharan]

Thank you very much. I was able to install this package firmware-brcm80211 to 
get the wifi card working on my pc.

But i'm running into a strange problem now. The system freezes and reboots 
after a few seconds. I have never experienced anything like this with Linux 
past several years.

If i boot into single user mode and uninstall this package firmware-brcm80211, 
the system functions normally.

If i install firmware-brcm80211, this makes the system unstable. The system 
freezes and reboots.

Should i file a new bug for this?

regards,
-Mathi


From: Salvatore Bonaccorso 
Sent: Monday, February 6, 2023 9:43 PM
To: Mathirajan S. Manoharan ; 
1030741-d...@bugs.debian.org <1030741-d...@bugs.debian.org>
Cc: Debian Bug Tracking System 
Subject: Re: Bug#1030741: firmware-brcm80211: Package firmware-brcm80211 not 
found in bookworm

Hi,

On Mon, Feb 06, 2023 at 08:05:29PM -0800, Mathirajan S. Manoharan wrote:
> Package: firmware-brcm80211
> Severity: important
> X-Debbugs-Cc: mathi...@hotmail.com
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
>
> I'm using bookworm as my desktop OS. I have the following wireless card.
>
> 02:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM43225 
> 802.11b/g/n [14e4:4357] (rev 01)
>
> This card is not working. It displays a message that "Firmware is missing".
>
>60.592279] brcmsmac bcma0:1: firmware: failed to load brcm/bcm43xx-0.fw 
> (-2)
> [   60.593680] firmware_class: See https://wiki.debian.org/Firmware for 
> information about missing firmware
> [   60.594859] brcmsmac bcma0:1: firmware: failed to load brcm/bcm43xx-0.fw 
> (-2)
>
>
> i already have firmware-linux-free, firmware-iwlwifi, firmware-misc-nonfree 
> installed on my system. None of these have the file brcm/bcm43xx-0.fw
>
> I also tried installing "firmware-b43-installer". This also didn't install 
> the required files. So, the wifi card is unusable on bookwork.
>
> I found that the package firmware-brcm80211 has these files, but it is not 
> present in bookworm repo

It is in bookworm, but it moved to the non-free-firmware archive
component (cf.
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#non-free-split)

Regards,
Salvatore

Bug#1013876: Please close this bug report for keepassxc-browser to migrate to testing

[Bruno Kleinert]

Am Montag, dem 06.02.2023 um 23:40 +0100 schrieb Guillem Jover:
> Hi!
> 
> On Mon, 2023-02-06 at 19:57:02 +0100, Bruno Kleinert wrote:
> > neither revision gets properly loaded by Chromium as of today.
> > 
> > As the freeze approaches, I will remove the Chromium package relation
> > and the symbolic link to the Web Extension
> > /usr/share/chromium/extensions/keepassxc-browser in order "solve" this
> > RC bug.
> 
> That means that users that had this package installed will stop having
> the extension at all, so I'm not sure that's much of a practical
> difference compared to having the extension but it failing to load. :/
> 
> > Unless someone understands what is wrong for Chromium to load the
> > extension and provides a patch.
> 
> Ok, I looked into this, and the problem seems to be the browser
> variable polyfill, which is not required on Firefox, as that uses
> browser, but crhomium-based ones use chrome for the namespace.
> 
> Copying the keepassxc-browser/common/browser-polyfill.min.js from
> the upstream's release/1.8.x branch into
> /usr/share/webext/keepassxc-browser/common/browser-polyfill.js, makes
> the extension work again.
> 
> It appears as if the Build-Depends used is unrelated to that code,
> where a comment at the bottom of the minimized version points at
> version 0.8.0 from https://github.com/mozilla/webextension-polyfill,
> but the package is trying to use node-cross-fetch, which seems
> unrelated?
> 
> Thanks,
> Guillem

Hi Guillem,

many, many thanks for that pointer!

I built a fixed package locally and Chromium loads the extension. I
will upload to sid in a few minutes.

Kind regards,
Bruno


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

Bug#1030785: -ffile-prefix-map option and reproducibility

[Mattia Rizzolo]

On Tue, Feb 07, 2023 at 04:41:47PM +0100, Stéphane Glondu wrote:
> When building packages, a -ffile-prefix-map option is automatically injected
> into CFLAGS. Where does it come from? Since when?
> 
> I suspect this was added to improve reproducibility. Ironically, it makes
> packages that capture this variable non reproducible, since the build path
> seems to be randomized (has it always been the case? since when?).

The build path has always been randomized since, or at least it has been
for as long as I've been involved in Debian.

> It is the
> case of OCaml (see #1030785), and seemingly of R as well (found by grepping
> in my /etc). I wouldn't be surprised other packages are affected as well.
> 
> Is there a way to not get this option? More elegant than explicitly
> filtering it out of CFLAGS in debian/rules...

Besides doing
DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath
I actually propose to you to filter out the whole option from being
saved.  I've seen a similar pattern in other packages in the past, and
all of those packages already had a filtering function in place to
remove other gcc flags that make no sense being saved (just looking at:
-   8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread 
-fPIC -g -O2 -ffile-prefix-map=/build/ocaml-Vq2uKK/ocaml-4.13.1=. 
-fstack-protector-strong -Wformat -Werror=format-security");
+   8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread 
-fPIC -g -O2 -ffile-prefix-map=/build/ocaml-xz3WL7/ocaml-4.13.1=. 
-fstack-protector-strong -Wformat -Werror=format-security");
makes me believe that many options have been stripped out…)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1030619: spell: Ispell died (if no dictionary)

[Eriberto]

Em ter., 7 de fev. de 2023 às 14:27, Marcos Talau  escreveu:
>
> Control: tags 1030619 + patch
>
> Hi there!
>
> The attached patch fixes this issue.

Thank you very much Talau for your contributions to the spell.

Regards,

Eriberto

Bug#1025823: qt6-base FTBFS on Alpha; Unknown Q_PROCESSOR_xxx macro

[Lisandro Damián Nicanor Pérez Meyer]

El jueves, 2 de febrero de 2023 05:00:07 -03 Michael Cree escribió:
> On Wed, Feb 01, 2023 at 09:13:09AM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > It's from Thiago MAciera, qtbase's maintainer. The text says:
> > 
> > "Can I ask for a screenshot of a KDE or Qt-based application running on
> > Alpha as proof that someone is actually using this?"
> > 
> > Can you provide us that? That will definitely help us a lot.
> 
> Like the attached which shows okular running on an Alpha running
> largely up-to-date Debian unstable?
> 
> Cheers
> Michael.

The patch has been accepted upstream at commit 
eeb66b99df521c4a32b8eda1d889f615319355a6

So we still need to ship this in Debian until the next Qt release.


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

Bug#1020641: dhcpcd5: dhcpcd fails to chroot during start

[Pásztor János]

Hello Everybody,

Allow me to give you a longer update on my progress.

1.) Managed to reproduce the issue on my machine. Big thanks to
martintxo for the detailed repro steps.

2.) Checked dhcpcd-gtk with the bad case and based on the logs it
seems that it has issues with the wpa_supplicant connection

-88---
pasja@bifrost ~ % dhcpcd-gtk

(dhcpcd-gtk:346063): Gtk-WARNING **: 18:43:01.100: Theme parsing error: 
gtk-widgets.css:1214:18: Not using units is deprecated. Assuming 'px'.

** Message: 18:43:01.145: Connecting ...
** Message: 18:43:01.145: Status changed to down
** Message: 18:43:01.145: Status changed to opened
** Message: 18:43:01.145: Connected to dhcpcd-9.4.1
** Message: 18:43:01.145: Status changed to connected
** Message: 18:43:01.145: wlo1: Associated with Ibn Tufajl
** Message: 18:43:01.145: wlo1: Configured 192.168.1.122/24
** Message: 18:43:01.145: wlo1: Configured 
2001:::e700:4bdb:3e4:cd05:b45/64
** Message: 18:43:01.145: wlo1: Configured 2001:::e700::64f/128
** Message: 18:43:01.145: eno2: Link is down
** Message: 18:43:03.148: wlo1: WPA status down
** Message: 18:43:05.152: wlo1: WPA status down
-8<--END--->8---

3.) Went to check dhcpcd-gtk source and I have found out that there is
a socket based communication between dhcpcd-gtk and wpa_supplicant

https://salsa.debian.org/debian/dhcpcd-ui/-/blob/master/src/libdhcpcd/wpa.c#L56

4.) After that I have tried to connect to wpa_supplicant with wpa_cli,
without any success. Based on that I have ruled out that the issue is
in dhcpcd-gtk

-88---
root@bifrost /tmp # wpa_cli 
wpa_cli v2.10
Copyright (c) 2004-2022, Jouni Malinen  and contributors

This software may be distributed under the terms of the BSD license.
See README for more details.


Selected interface 'wlo1'

Interactive mode

Warning: Failed to attach to wpa_supplicant.
Could not connect to wpa_supplicant: wlo1 - re-trying
Warning: Failed to attach to wpa_supplicant.
Warning: Failed to attach to wpa_supplicant.
Warning: Failed to attach to wpa_supplicant.
Warning: Failed to attach to wpa_supplicant.
Warning: Failed to attach to wpa_supplicant.


^Celoop: could not process SIGINT or SIGTERM in two seconds. Looks like there
is a bug that ends up in a busy loop that prevents clean shutdown.
Killing program forcefully.
-8<--END--->8---

5.) Using strace on both programs revealed a similar socket based
communication what I have seen between dhcpcd-gtk and wpa_supplicant
The interesting part comes below from wpa_supplicant

-88---
recvfrom(11, "ATTACH", 8193, 0, {sa_family=AF_UNIX, 
sun_path="/tmp/wpa_ctrl_346236-2"}, [128->25]) = 6
getsockopt(11, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0
ioctl(11, TIOCOUTQ, [0]) = 0
sendto(11, "OK\n", 3, 0, {sa_family=AF_UNIX, 
sun_path="/tmp/wpa_ctrl_346236-2"}, 25) = -1 ENOENT (No such file or directory)
-8<--END--->8---

See the file not found error in the last line. However that file does
exist in my /tmp !!

-88---
pasja@bifrost ~ % l /tmp/wpa_ctrl_346236-2
srwxr-xr-x 1 root root 0 Feb  7 18:49 /tmp/wpa_ctrl_346236-2
-8<--END--->8---

6.) My understanding was partial at that time, so I went back and
checked what Privatetmp does exactly, and it turned out that it
creates a new mount namespace. With `systemd-cgls` I was able to
confirm that both wpa_supplicant and dhcpcd are living in the same
namespace

-88---
pasja@bifrost ~ % systemd-cgls
Control group /:
-.slice

[redacted output]

  ├─dhcpcd.service (#15832)
  │ → user.invocation_id: fb283568273843dbb14259f938137d6a
  │ ├─298963 dhcpcd: [manager] [ip4] [ip6]
  │ ├─298964 dhcpcd: [privileged proxy]
  │ ├─298965 dhcpcd: [network proxy]
  │ ├─298966 dhcpcd: [control proxy]
  │ ├─298984 wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant-wlo1.conf 
-iwlo1
  │ ├─310014 dhcpcd: [BPF ARP] wlo1 192.168.9.182
  │ └─310585 dhcpcd: [BPF ARP] enxc03ebac7d8c3 192.168.10.248
-8<--END--->8---

7.) The final step was that I have compared the mountinfo in the
working and the non-working case for wpa_supplicant and see that in
the non-working case /tmp does get an extra mount from the Privatetmp
config

-88---
root@bifrost /tmp # cat /proc/$(pidof wpa_supplicant)/mountinfo | grep '/tmp'
365 349 254:1 

Bug#1019731: Suggested fix

[Pirate Praveen]

Utkarsh suggested this change will fix this bug, we need to test it 
before we add to the gitlab package.


diff --git a/config/application.rb b/config/application.rb
index 249db9c6a6..e7481e12e1 100644
--- a/config/application.rb
+++ b/config/application.rb
@@ -234,6 +234,12 @@ class Application < Rails::Application
config.active_record.has_many_inversing = false
config.active_record.belongs_to_required_by_default = false

+ # Allow Gitlab::Diff::Position because it was disallowed
+ # with Rails 6.1.6.4 security update. Whilst they have
+ # re-added support for Symbol, they expect the projects
+ # to add the classes they need to be explicitly allowed.
+ config.active_record.yaml_column_permitted_classes = [Symbol, 
DateTime, Gitlab::Diff::Position]

+
# Enable the asset pipeline
config.assets.enabled = true

Bug#1030816: displayfont turns off UTF-8 mode

[Jakub Wilk]

Package: console-cyrillic
Version: 0.9-17.2

Apparently displayfont(1) turns off the UTF-8 mode:

   $ printf $'\u263A\n'  # U+263A WHITE SMILING FACE
   ☺

   $ displayfont | tail -n1

   $ printf $'\u263A\n'
   âÿº

--
Jakub Wilk

Bug#1030814: openldap: autopkgtest regression

[Ryan Tandy]

Hi, thanks for reporting.

On Tue, Feb 07, 2023 at 07:25:31PM +0200, Adrian Bunk wrote:

/tmp/autopkgtest-lxc.jrj8ozx8/downtmp/build.7fx/src/debian/tests/sha2-contrib: 
line 6: slappasswd: command not found


The dependency is definitely installed so it must be a PATH issue. Maybe 
because this test doesn't require root... Worked for me locally (qemu 
backend) so I'm a little surprised debci is different.  Will fix ASAP.

Bug#1030815: keyman: Missing autopkgtest dependency on pkg-config

[Adrian Bunk]

Source: keyman
Version: 16.0.138-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/k/keyman/31022569/log.gz

...
autopkgtest [03:17:05]: test test-build: [---
/tmp/autopkgtest-lxc.1u3zjijx/downtmp/build.9GP/src/debian/tests/test-build: 
line 18: pkg-config: command not found
In file included from /usr/include/keyman/keyboardprocessor.h:103,
 from keymantest.c:1:
/usr/include/keyman/keyboardprocessor_bits.h:69:10: fatal error: km_types.h: No 
such file or directory
   69 | #include 
  |  ^~~~
compilation terminated.
autopkgtest [03:17:05]: test test-build: ---]
autopkgtest [03:17:05]: test test-build:  - - - - - - - - - - results - - - - - 
- - - - -
...

Bug#1029499: php-guzzlehttp-psr7: Build killed with signal TERM after 150 minutes of inactivity

[Bernhard Übelacker]

Out of curiosity I investigated a little more.
With the below steps I could reproduce it in a minimal
Bookworm/testing amd64 qemu VM.

There the build stopped at this line:
dpkg-buildpackage: info: binary-only upload ...

And killing from outside this php process made the build continue/finish.

Previously I copied an sbuild example using
unshare instead of schroot, but there
the hang was not observable.

Kind regards,
Bernhard



# as root:

apt install mc rr gdb htop sbuild sbuild-debian-developer-setup mmdebstrap
apt build-dep php-guzzlehttp-psr7

sbuild-adduser benutzer

cat << "EOF" > /etc/schroot/chroot.d/unstable-amd64-sbuild
[unstable-amd64-sbuild]
description=Debian unstable/amd64 autobuilder
groups=root,sbuild
root-groups=root,sbuild
profile=sbuild
type=directory
directory=/srv/chroot/sbuild-createchroot
union-type=overlay
EOF


mkdir  /srv/chroot
mmdebstrap --variant=buildd unstable /srv/chroot/sbuild-createchroot


# as user:

cat << "EOF" > ~/.sbuildrc
$chroot_mode = 'schroot';
$distribution = 'unstable';

#$run_autopkgtest = 1;
$autopkgtest_root_args = '';
$autopkgtest_opts = [ '--apt-upgrade', '--', 'schroot', '--release', '%r', 
'--arch', '%a' ];
EOF

mkdir /home/benutzer/source/php-guzzlehttp-psr7/orig
cd/home/benutzer/source/php-guzzlehttp-psr7/orig
apt source php-guzzlehttp-psr7

cd /home/benutzer/source/php-guzzlehttp-psr7
cp orig try1 -a
cd try1/php-guzzlehttp-psr7-2.4.3
sbuild --no-run-lintian

Bug#1030619: spell: Ispell died (if no dictionary)

[Marcos Talau]

Control: tags 1030619 + patch

Hi there!

The attached patch fixes this issue.


Best regards,
mt
Description: Add option "--ispell-dictionary, -D" to spell
Author: Kaare Hviid 
Author: Marcos Talau 
Bug-Debian: https://bugs.debian.org/297308
Bug-Debian: https://bugs.debian.org/1030619
Last-Update: 2023-02-07
Index: spell/spell.c
===
--- spell.orig/spell.c
+++ spell/spell.c
@@ -93,7 +93,6 @@ static char *xstrdup (const char *);
 static void *xmalloc (size_t);
 static void *xrealloc (void *, size_t);
 static void error (int status, int errnum, const char *message,...);
-static void sig_chld (int);
 static void sig_pipe (int);
 void new_pipe (pipe_t *);
 void parent (pipe_t *, int, char **);
@@ -110,6 +109,7 @@ const struct option long_options[] =
   {"dictionary", required_argument, NULL, 'd'},
   {"help", no_argument, NULL, 'h'},
   {"ispell", required_argument, NULL, 'i'},
+  {"ispell-dictionary", required_argument, NULL, 'D'},
   {"ispell-version", no_argument, NULL, 'I'},
   {"number", no_argument, NULL, 'n'},
   {"print-file-name", no_argument, NULL, 'o'},
@@ -129,6 +129,9 @@ char *ispell_prog = NULL;
 /* Dictionary to use.  Just use the default if NULL.  */
 char *dictionary = NULL;
 
+/* Ispell dictionary to use (--ispell-dictionary, -D). */
+char *ispell_dict = NULL;
+
 /* Display Ispell's version (--ispell-version, -I). */
 int show_ispell_version = 0;
 
@@ -167,8 +170,8 @@ main (int argc, char **argv)
   /* Option processing loop.  */
   while (1)
 {
-  opt = getopt_long (argc, argv, "IVbdhilnosvx", long_options,
-(int *) 0);
+  opt = getopt_long (argc, argv, "IVbd:D:hi:lnos:vx", long_options,
+(int *) 0);
 
   if (opt == EOF)
break;
@@ -190,6 +193,12 @@ main (int argc, char **argv)
  else
error (0, 0, "option argument not given");
  break;
+   case 'D':
+ if (optarg != NULL)
+   ispell_dict = xstrdup (optarg);
+ else
+   error (0, 0, "option argument not given");
+ break;
case 'h':
  show_help = 1;
  break;
@@ -245,6 +254,7 @@ main (int argc, char **argv)
 "  -V, --version\t\t\tPrint the version number.\n"
 "  -b, --british\t\t\tUse the British dictionary.\n"
 "  -d, --dictionary=FILE\t\tUse FILE to look up words.\n"
+ "  -D, --ispell-dictionary=DICT\tUse DICTIONARY to look up 
words.\n"
 "  -h, --help\t\t\tPrint a summary of the options.\n"
 "  -i, --ispell=PROGRAM\t\tCalls PROGRAM as Ispell.\n"
 "  -l, --all-chains\t\tIgnored; for compatibility.\n"
@@ -475,7 +485,7 @@ new_pipe (pipe_t * the_pipe)
 
   if (signal (SIGPIPE, sig_pipe) == SIG_ERR)
 error (EXIT_FAILURE, errno, "error creating SIGPIPE handler");
-  if (signal (SIGCHLD, sig_chld) == SIG_ERR)
+  if (signal (SIGCHLD, SIG_IGN) == SIG_ERR)
 error (EXIT_FAILURE, errno, "error creating SIGCHLD handler");
 
   if (pipe (ifd) < 0)
@@ -511,14 +521,6 @@ sig_pipe (int signo)
   error (EXIT_FAILURE, 0, "broken pipe");
 }
 
-/* Handle the SIGCHLD signal.  */
-
-static void
-sig_chld (int signo)
-{
-  error (EXIT_FAILURE, 0, "Ispell died");
-}
-
 /* Send lines to and retrieve lines from *THE_PIPE (created by
`new_pipe').  Accept `argc' (the number of arguments) and `argv'
(the array of arguments), so we can search for the files we are to
@@ -555,9 +557,12 @@ parent (pipe_t * the_pipe, int argc, cha
 
 len = getline(, _size, the_pipe->fpin);
 if (len == -1) {
-  if (feof(the_pipe->fpin))
+  if (feof(the_pipe->fpin)) {
+  len = getline(, _size, the_pipe->fperr);
+  if (len != -1)
+  fprintf(stderr, "%s", buff);
   error (EXIT_FAILURE, 0, "premature EOF from Ispell's stdout");
-  else
+  } else
   error(EXIT_FAILURE, errno, "error reading errors of ispell/aspell");
 }
 
@@ -649,6 +654,12 @@ run_ispell_in_child (pipe_t * the_pipe)
   execlp ("aspell", "aspell", "-a", "-p", dictionary, NULL) < 0)
error (EXIT_FAILURE, errno, "error executing ispell/aspell");
 
+  if (ispell_dict != NULL)
+if (execlp (ispell_prog, "ispell", "-a", "-d", ispell_dict, NULL) < 0)
+  if (errno != ENOENT  ||
+  execlp ("aspell", "aspell", "-a", "-d", ispell_dict, NULL) < 0)
+   error (EXIT_FAILURE, errno, "error executing ispell/aspell");
+
   if (british)
 if (execlp (ispell_prog, "ispell", "-a", "-d", "british", NULL) < 0)
   if (errno != ENOENT  ||
Index: spell/spell.texi
===
--- spell.orig/spell.texi
+++ spell/spell.texi
@@ -113,6 +113,10 @@ this dictionary was installed with Ispel
 @itemx -d @var{file}
 Use the named dictionary.
 
+@item --ispell-dictionary=@var{dictionary}
+@itemx -D @var{dictionary}
+Use the named Ispell dictionary.
+
 @item --help
 @itemx -h
 Print 

Bug#1030814: openldap: autopkgtest regression

[Adrian Bunk]

Source: openldap
Version: 2.5.13+dfsg-4
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openldap/31139461/log.gz

...
autopkgtest [09:28:43]: test sha2-contrib: [---
/tmp/autopkgtest-lxc.jrj8ozx8/downtmp/build.7fx/src/debian/tests/sha2-contrib: 
line 6: slappasswd: command not found
autopkgtest [09:28:44]: test sha2-contrib: ---]
autopkgtest [09:28:44]: test sha2-contrib:  - - - - - - - - - - results - - - - 
- - - - - -
sha2-contrib FAIL non-zero exit status 127
autopkgtest [09:28:44]: test sha2-contrib:  - - - - - - - - - - stderr - - - - 
- - - - - -
/tmp/autopkgtest-lxc.jrj8ozx8/downtmp/build.7fx/src/debian/tests/sha2-contrib: 
line 6: slappasswd: command not found
autopkgtest [09:28:44]:  summary
slapdPASS (superficial)
smbk5pwd PASS (superficial)
sha2-contrib FAIL non-zero exit status 127

Bug#978149: Python 3.10 in bookworm

[karthek]

Sorry for spamming…
Resending the same message, I just remembered debian.org ignores mails
from mail@* addresses.

On Tue, Feb 07, 2023 at 02:24:08PM +, Stefano Rivera wrote:
> > See "ITP pyenv" @ http://bugs.debian.org/978149 .
> 
> I think the Python development community would be very happy to see
> this. Debian's selected Python releases don't meet all the needs of
> Python developers, who typically want access to all supported Python 3
> versions (and possibly the next alpha), at all times.
> 

Indeed.

> I'd be happy to review and sponsor uploads.
> 

Thanks Stefano, I packaged it almost 2 years ago while working on
Android Open-source project (AOSP). While I got response from upstream,
I Haven't got any response from debian community back then apart from
interest in it from Julian a year ago.

Since then I also didn't find any DD nearyby my city to sign my key.

I'm happy to work on the packaging…

Bug#1030813: mumble: autopkgtest regression

[Adrian Bunk]

Source: mumble
Version: 1.3.4-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mumble/31139421/log.gz

...
autopkgtest [09:23:28]: test command1: smoke
autopkgtest [09:23:28]: test command1: [---
bash: line 1: smoke: command not found
autopkgtest [09:23:29]: test command1: ---]
autopkgtest [09:23:29]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 127

Bug#1029292: lomiri-greeter: Depends: lomiri-system-compositor but it is not installable

[Adrian Bunk]

On Fri, Jan 20, 2023 at 08:48:19PM +0200, Adrian Bunk wrote:
> Package: lomiri-greeter
> Version: 0.1~git20230111.ba0fc6a-4
> Severity: serious
> 
> The following packages have unmet dependencies:
>  lomiri-greeter : Depends: lomiri-system-compositor but it is not installable

As the version tracking of the BTS already correctly shows, 0.1-1 now in 
unstable is based on 0.1~git20230111.ba0fc6a-4 and lacks this fix that
was in 0.1~git20230111.ba0fc6a-5.

cu
Adrian

Bug#1022854: Bug#1030751: debuerreotype: diff for NMU version 0.15-1.1

[Tianon Gravi]

On Tue, 7 Feb 2023 at 01:33, Adrian Bunk  wrote:
> Package: debuerreotype
> Version: 0.15-1
> Severity: normal
> Tags: patch  pending
>
> Dear maintainer,
>
> I've prepared an NMU for debuerreotype (versioned as 0.15-1.1) and
> uploaded it to DELAYED/1. Please feel free to tell me if I should
> cancel it.
>
> cu
> Adrian

I'm sorry, but I must admit to being a little bit confused by this --
why was this a whole new bug instead of just a comment on #1022854?

(and why wasn't there any attempt to communicate about why it's urgent
for you before the NMU, especially with such a short delay?  is there
a particular reason you're doing this?  I can guess at your
motivations, but it sure helps if they're written somewhere )

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1030812: autopkgtest failure : it should not work with ruby-omniauth >= 2

[Lucas Kanashiro]

Source: ruby-omniauth-bitbucket
Version: 0.0.2-1.1
Severity: Serious

In ruby-omniauth-bitbucket gemspec we can see:

$ cat omniauth-bitbucket.gemspec | grep omniauth | grep dependency
  s.add_dependency 'omniauth', '~> 1.1'
  s.add_dependency 'omniauth-oauth', '~> 1.0'

This should not work since we already have ruby-omniauth >= 2 in testing 
and unstable:


$ rmadison -u debian ruby-omniauth
ruby-omniauth | 1.2.1-1+deb8u1  | oldoldoldstable   | source, all
ruby-omniauth | 1.3.1-1+deb9u1  | oldoldstable  | source, all
ruby-omniauth | 1.8.1-1~bpo9+1  | stretch-backports | source, all
ruby-omniauth | 1.8.1-1 | oldstable | source, all
ruby-omniauth | 1.9.1-1~bpo10+1 | buster-backports  | source, all
ruby-omniauth | 1.9.1-1 | stable    | source, all
ruby-omniauth | 2.1.1-1 | testing   | source, all
ruby-omniauth | 2.1.1-1 | unstable  | source, all

This is not causing a FTBFS because we are not explicitly checking 
dependencies during tests (this is forced in autopkgtest), if the 
following change is added we can reproduce the same autopkgtest failure 
during the build:


commit 88dbbe95f4b83859ba2e009d3c97610f66b1fcff (HEAD -> master)
Author: Lucas Kanashiro 
Date:   Tue Feb 7 13:58:36 2023 -0300

    d/rules: check dependencies when running tests

    This demonstrates the FTBFS happening because we have ruby-omniauth 
>= 2

    in the archive. The same failure is reproducible with autopkgtest.

diff --git a/debian/rules b/debian/rules
index 00f8a91..2fab9b6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,7 +12,7 @@
 #export DH_RUBY_GEMSPEC=gem.gemspec
 #
 # Uncomment to check dependencies during build:
-# export GEM2DEB_TEST_RUNNER = --check-dependencies
+export GEM2DEB_TEST_RUNNER = --check-dependencies

 %:
    dh $@ --buildsystem=ruby --with ruby


All these mean that we likely have a broken ruby-omniauth-bitbucket in 
testing, we should not ship this package in a stable release. Upstream 
is inactive since 2017, so I do not expect any fix from them.


--
Lucas Kanashiro

Bug#1030811: python-qrcode FTBFS: ModuleNotFoundError: No module named 'typing_extensions'

[Adrian Bunk]

Source: python-qrcode
Version: 7.4.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=python-qrcode=all=7.4.2-1=1675788862=0

...
 ERRORS 
__ ERROR collecting .pybuild/cpython3_3.11/build/qrcode/tests/test_example.py __
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.11/build/qrcode/tests/test_example.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
qrcode/__init__.py:1: in 
from qrcode.main import QRCode
qrcode/main.py:15: in 
from typing_extensions import Literal
E   ModuleNotFoundError: No module named 'typing_extensions'
__ ERROR collecting .pybuild/cpython3_3.11/build/qrcode/tests/test_qrcode.py ___
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.11/build/qrcode/tests/test_qrcode.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
qrcode/__init__.py:1: in 
from qrcode.main import QRCode
qrcode/main.py:15: in 
from typing_extensions import Literal
E   ModuleNotFoundError: No module named 'typing_extensions'
_ ERROR collecting .pybuild/cpython3_3.11/build/qrcode/tests/test_qrcode_svg.py 
_
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.11/build/qrcode/tests/test_qrcode_svg.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
qrcode/__init__.py:1: in 
from qrcode.main import QRCode
qrcode/main.py:15: in 
from typing_extensions import Literal
E   ModuleNotFoundError: No module named 'typing_extensions'
__ ERROR collecting .pybuild/cpython3_3.11/build/qrcode/tests/test_release.py __
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.11/build/qrcode/tests/test_release.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
qrcode/__init__.py:1: in 
from qrcode.main import QRCode
qrcode/main.py:15: in 
from typing_extensions import Literal
E   ModuleNotFoundError: No module named 'typing_extensions'
__ ERROR collecting .pybuild/cpython3_3.11/build/qrcode/tests/test_script.py ___
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.11/build/qrcode/tests/test_script.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
qrcode/__init__.py:1: in 
from qrcode.main import QRCode
qrcode/main.py:15: in 
from typing_extensions import Literal
E   ModuleNotFoundError: No module named 'typing_extensions'
___ ERROR collecting .pybuild/cpython3_3.11/build/qrcode/tests/test_util.py 
ImportError while importing test module 
'/<>/.pybuild/cpython3_3.11/build/qrcode/tests/test_util.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
qrcode/__init__.py:1: in 
from qrcode.main import QRCode
qrcode/main.py:15: in 
from typing_extensions import Literal
E   ModuleNotFoundError: No module named 'typing_extensions'
=== short test summary info 
ERROR qrcode/tests/test_example.py
ERROR qrcode/tests/test_qrcode.py
ERROR qrcode/tests/test_qrcode_svg.py
ERROR qrcode/tests/test_release.py
ERROR qrcode/tests/test_script.py
ERROR qrcode/tests/test_util.py
!!! Interrupted: 6 errors during collection 
== 6 errors in 0.22s ===
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=2: cd 
/<>/.pybuild/cpython3_3.11/build; python3.11 -m pytest -k 'not 
test_script'
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 
returned exit code 13
make: *** [debian/rules:6: binary-indep] Error 25

Bug#1029198: marked as done (bugs.debian.org: linux-image-6.1.0-1-amd64/testing ERROR:M=/var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.1/b)

[Curtis Dean Smith]

Hello!
I am still experiencing this bug.  Here is the log from my latest
attempt to update:
=DKMS
make.log for xtrx-0.0.1+git20190320.5ae3a3e-3.1 for kernel
6.1.0-3-amd64 (x86_64)
Tue Feb  7 08:47:34 AM PST 2023
make: Entering directory '/usr/src/linux-headers-6.1.0-3-amd64'
  CC [M] 
/var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.1/build/xtrx.o
/var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.1/build/xtrx.c:518:27:
error: initialization of ‘void (*)(struct uart_port *, struct
ktermios *, const struct ktermios *)’ from incompatible pointer type
‘void (*)(struct uart_port *, struct ktermios *, struct ktermios
*)’ [-Werror=incompatible-pointer-types]
  518 | .set_termios= xtrx_uart_set_termios,
  |   ^
/var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.1/build/xtrx.c:518:27:
note: (near initialization for ‘xtrx_uart_ops.set_termios’)
cc1: some warnings being treated as errors
make[1]: ***
[/usr/src/linux-headers-6.1.0-3-common/scripts/Makefile.build:255:
/var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.1/build/xtrx.o] Error 1
make: *** [/usr/src/linux-headers-6.1.0-3-common/Makefile:2017:
/var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.1/build] Error 2
make: Leaving directory '/usr/src/linux-headers-6.1.0-3-amd64'
=

On 2/1/2023 at 10:21 PM, "Debian Bug Tracking System"  wrote:Your
message dated Thu, 02 Feb 2023 06:10:28 +
with message-id 
and subject line Bug#1029135: fixed in xtrx-dkms
0.0.1+git20190320.5ae3a3e-3.2
has caused the Debian Bug report #1029135,
regarding bugs.debian.org: linux-image-6.1.0-1-amd64/testing
ERROR:M=/var/lib/dkms/xtrx/0.0.1+git20190320.5ae3a3e-3.1/b
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
-- 
1029135: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029135
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1030810: django-sass-processor FTBFS: django.core.exceptions.ImproperlyConfigured

[Adrian Bunk]

Source: django-sass-processor
Version: 1.2.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=django-sass-processor=all=1.2.2-1=1675788416=0

...
 ERRORS 
__ ERROR at setup of SassProcessorTest.test_management_command_django __

cls = 

@classmethod
def setUpClass(cls):
>   super().setUpClass()

/usr/lib/python3/dist-packages/django/test/testcases.py:1182: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/django/test/testcases.py:183: in setUpClass
cls._add_databases_failures()
/usr/lib/python3/dist-packages/django/test/testcases.py:204: in 
_add_databases_failures
cls.databases = cls._validate_databases()
/usr/lib/python3/dist-packages/django/test/testcases.py:190: in 
_validate_databases
if alias not in connections:
/usr/lib/python3/dist-packages/django/utils/connection.py:73: in __iter__
return iter(self.settings)
/usr/lib/python3/dist-packages/django/utils/functional.py:48: in __get__
res = instance.__dict__[self.name] = self.func(instance)
/usr/lib/python3/dist-packages/django/utils/connection.py:45: in settings
self._settings = self.configure_settings(self._settings)
/usr/lib/python3/dist-packages/django/db/utils.py:144: in configure_settings
databases = super().configure_settings(databases)
/usr/lib/python3/dist-packages/django/utils/connection.py:50: in 
configure_settings
settings = getattr(django_settings, self.settings_name)
/usr/lib/python3/dist-packages/django/conf/__init__.py:82: in __getattr__
self._setup(name)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = , name = 'DATABASES'

def _setup(self, name=None):
"""
Load the settings module pointed to by the environment variable. This
is used the first time settings are needed, if the user hasn't
configured settings manually.
"""
settings_module = os.environ.get(ENVIRONMENT_VARIABLE)
if not settings_module:
desc = ("setting %s" % name) if name else "settings"
>   raise ImproperlyConfigured(
"Requested %s, but settings are not configured. "
"You must either define the environment variable %s "
"or call settings.configure() before accessing settings."
% (desc, ENVIRONMENT_VARIABLE))
E   django.core.exceptions.ImproperlyConfigured: Requested setting 
DATABASES, but settings are not configured. You must either define the 
environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before 
accessing settings.

/usr/lib/python3/dist-packages/django/conf/__init__.py:63: ImproperlyConfigured
...
=== short test summary info 
ERROR 
tests/test_sass_processor.py::SassProcessorTest::test_management_command_django
ERROR 
tests/test_sass_processor.py::SassProcessorTest::test_management_command_jinja2
ERROR 
tests/test_sass_processor.py::SassProcessorTest::test_management_command_multiple
ERROR tests/test_sass_processor.py::SassProcessorTest::test_sass_processor - ...
ERROR tests/test_sass_processor.py::SassProcessorTest::test_sass_src_django
ERROR tests/test_sass_processor.py::SassProcessorTest::test_sass_src_jinja2
ERROR 
tests/test_sass_processor.py::SassProcessorTest::test_sass_src_jinja2_variable
ERROR tests/test_sass_processor.py::SassProcessorTest::test_use_storage_django
ERROR tests/test_sass_processor.py::SassProcessorTest::test_use_storage_jinja2
ERROR tests/test_sass_processor.py::SassProcessorTest::test_use_storage_multiple
 2 warnings, 10 errors in 1.39s 
E: pybuild pybuild:388: test: plugin distutils failed with: exit code=1: cd 
/<>/.pybuild/cpython3_3.11_django-sass-processor/build; python3.11 
-m pytest tests
dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit 
code 13
make: *** [debian/rules:8: build-indep] Error 25

Bug#1030785: -ffile-prefix-map option and reproducibility

[Guillem Jover]

Hi!

On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote:
> When building packages, a -ffile-prefix-map option is automatically injected
> into CFLAGS. Where does it come from? Since when?

This is coming from dpkg-buildflags (in this case probably indirectly
via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default,
and then switched to enabled by default in dpkg 1.20.6 (see #974087).

> I suspect this was added to improve reproducibility. Ironically, it makes
> packages that capture this variable non reproducible, since the build path
> seems to be randomized (has it always been the case? since when?). It is the
> case of OCaml (see #1030785), and seemingly of R as well (found by grepping
> in my /etc). I wouldn't be surprised other packages are affected as well.

AFAIR this was considered at the time, yes. If the flag is effectively
not fixing anything for the set of packages involved, and is in fact
actually making them unreproducible when they would not then, you can
disable the fixfilepath feature in the reproducible build flags area,
via DEB_BUILD_MAINT_OPTIONS. Perhaps even "globally" from a language
specific packaging helper or similar?

> Is there a way to not get this option? More elegant than explicitly
> filtering it out of CFLAGS in debian/rules...

See above.


I just noticed that several of these build flag features do not have
information in the man page about when they got first introduced, so
I'll be adding that in dpkg 1.22.x, once development opens up again.

Thanks,
Guillem

Bug#1030792: [Pkg-rust-maintainers] Bug#1030792: rust-ignore: please update to v0.4.20

[Jonas Smedegaard]

Quoting Peter Green (2023-02-07 17:14:38)
> > Please update to newer upstream release v0.4.20.
> 
> I tried updating this, but discovered it uses "let else" which is not
> stabilized in the version of rustc currently in bookworm/sid.

This might be inspirational:
https://salsa.debian.org/debian/safe-network/-/blob/debian/latest/debian/patches/2008_rustc.patch

 - Jonas

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

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

signature.asc
Description: signature

Bug#1030809: RM: golang-github-willf-bitset -- ROM; duplicated with golang-github-bits-and-blooms-bitset

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-github-willf-bit...@packages.debian.org, z...@debian.org
Control: affects -1 + src:golang-github-willf-bitset

These two packages are same source.

https://github.com/willf/bitset is 302 to
https://github.com/bits-and-blooms/bitset

Bug#987013: Release goal proposal: Remove Berkeley DB

[Marco d'Itri]

On Feb 04, Paul Gevers  wrote:

> I don't see the preparation happening in time for bookworm, so if the
> preparations are done for trixie, Berkeley DB can be removed in forky.
I object again to removing Berkeley DB: it is mature software and it 
works fine.
At least inn2 uses it, and a "transition" (i.e. rebuilding the overview 
database with a different indexing method) for a non-trivial server may 
require hours of downtime.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1030510: Info received (Bug#1030510: Info received (Bug#1030510: Info received (mariadb: FTBFS on s390x: timeout)))

[Otto Kekäläinen]

Control: severity -1 normal
Control: tags -1 help

The s390x build is still failing after 5 retries at
https://buildd.debian.org/status/package.php?p=mariadb. The issue
seems to be with Debian buildd, as the Launchpad s390x build passed
just fine without the need to retry anything:
https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all

It seems to crash on different tests every time. I could disable the
entire test suite, but that feels like a bad idea.

I need help - if the s390x build does not pass, the 10.11 cannot enter
Debian testing (Bookworm).


(this email is for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030510)