Bug#1000495: openssh: drop the advertisement clause in BSD license

[Ritesh Raj Sarraf]

Control: forward -1 https://bugzilla.mindrot.org/show_bug.cgi?id=3368

On Wed, 2021-11-24 at 22:16 +, Colin Watson wrote:
> Regardless of what permission Niels has given, I can't unilaterally
> change it in Debian's OpenSSH packaging; it needs to be updated
> upstream
> first.  Please file a bug at bugzilla.mindrot.org about this and mark
> this bug as forwarded (I don't think it makes sense for me to be in
> the
> middle here).

Thank you Colin. I have filed a bug upstream and appropriately set this
one as forwarded.


-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#972429: ahmad

[muhammad ahmad]

Bug#948862: Experimental jpeg-xl package in Debian

[Mathieu Malaterre]

Hi Luca !

On Wed, Nov 24, 2021 at 7:47 PM Luca Versari  wrote:
>
>
>
> On Tue, Nov 16, 2021 at 12:42 PM Mathieu Malaterre  wrote:
>>
>> Dear Luca,
>
> Hi! Sorry if it took me a while to get back to you.

No worries :)

>>
>>
>> I see you have some interest in jpeg-xl package in Debian. You
>> previously mentioned:
>>
>> > I'm not sure what we could do to expedite that.
>>
>> If you work closely with upstream, the most difficult tasks for me
>> (Debian hat on) were:
>>
>> * Dealing with convenient copies [*], I could not manage to get rid of
>> highway and lodepng. Would be nice if those were not required,
>
>  I believe it should be possible to use system highway - the relevant CMake 
> flag is DJPEGXL_FORCE_SYSTEM_HWY.

Right, I see the option now. I believe I need to prepare a package for
highway ... yak shaving again :)

> As for lodepng - that's indeed not possible today, but it being a single, 
> AFAIU-not-packaged-anywhere file might make it possible to make an exception 
> there.
> Note also that lodepng should only be required for tests and tools, and not 
> for the main libjxl library.

True. But for reasons outside my responsibilities CVE can be assigned
to command line tools.
Do you know why upstream is not using the standard libpng directly ?

>> * Use of system lcms2. There is a pending patch that has never been
>> integrated upstream [**],
>
>  A similar patch to allow external lcms2 has been submitted and should be 
> integrated in the next release.

Woot \o/

>> * djxl and cjxl are using the static jxl library. This is not a good
>> practice (again Debian hat on), since every time we fix a bug in the
>> shared libjxl, this means recompiling cjxl/djxl for no good reason.
>> Please make it configurable.
>
> AFAIU, the JXL shared library doesn't expose symbols of the (non-public) C++ 
> library, which would make using it from cjxl and djxl at least somewhat 
> problematic;
> we are planning to have cjxl and djxl use the C API, but that's going to take 
> some work still.

OK, at least I understand the issue now.

>>
>> * I also see a minor issue with exported symbols in jxl-threads (but I
>> can live with that).
>
> What kind of issue?

For some reason the symbols for libjxl0.6 are extremely well defined
(kudos to whoever made that possible). Have a peak look at the symbols
file in the Debian file:

libjxl.so.0.6 libjxl0.6 #MINVER#
 JXL_0@JXL_0 0.6.1
 JxlButteraugliApiCreate@JXL_0 0.6.1
 JxlButteraugliApiDestroy@JXL_0 0.6.1
 JxlButteraugliApiSetHFAsymmetry@JXL_0 0.6.1
 JxlButteraugliApiSetIntensityTarget@JXL_0 0.6.1
...

Compare that with:

libjxl_threads.so.0.6 libjxl0.6 #MINVER#
 JxlResizableParallelRunner@Base 0.6.1
[...]
 _ZNSt6vectorISt6threadSaIS0_EE17_M_default_appendEm@Base 0.6.1
 
_ZNSt6vectorISt6threadSaIS0_EE17_M_realloc_insertIJRFvPN6jpegxl20ThreadParallelRunnerEiES6_RjEEEvN9__gnu_cxx17__normal_iteratorIPS0_S2_EEDpOT_@Base
0.6.1
 
_ZTINSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPN6jpegxl20ThreadParallelRunnerEiES5_jEE@Base
0.6.1
 
_ZTSNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPN6jpegxl20ThreadParallelRunnerEiES5_jEE@Base
0.6.1
 
_ZTVNSt6thread11_State_implINS_8_InvokerISt5tupleIJPFvPN6jpegxl20ThreadParallelRunnerEiES5_jEE@Base
0.6.1

So I was simply suprised the same care was not applied to
libjxl_threads.so.0.6, hence my remark. Could you check with upstream
why the same magic to hide c++ stl symbols is not applied.

See upstream file: % cat lib/jxl/jxl.version

>>
>>
>> Thanks for your time,
>
> Thank you!
>>
>>
>> [*] https://wiki.debian.org/EmbeddedCopies
>> [**] https://github.com/libjxl/libjxl/issues/712
>>
>> --
>> To unsubscribe, send mail to 948862-unsubscr...@bugs.debian.org.

Bug#999448: [External] Re: Bug#999448: atop: Two fixes for debian/rules: activate atopacctd before activating atop, load atop.default into pkg

[李菲]

Hi,

On Thu, Nov 25, 2021 at 3:32 AM Marc Haber 
wrote:

> Hi,
>
> On Thu, Nov 11, 2021 at 06:56:33PM +0800, 李菲 wrote:
> > wrote:
> > I guess the below 'Reproduce' can tell this :) That is, if atop starts
> > before
> > atopacctd, it will read from /var/cache/atop.d/atop.acct. Instead, if
> > atopacctd
> > starts earlier, atop will read from /run/pacct_shadow.d/00.paf
> > which is generated by atopacctd.
>
> Is this a race condition that only occurs once in a while? I tried it
> three times now on a test system and all three times it ended up with
> atop reading from the .paf file right after reboot.
>
You mean reboot the machine? I am wondering why rebooting
is needed after installing atop.  I did the following check just
after installing atop without rebooting the machine. :)
As for the reboot, I am inclined to the problem is corrected
after rebooting, mainly due to the "Before=atop.service"
in atopacct.service file.

>
> Example output:
> [2/4438]mh@testsid85:~ $ pgrep '^atop$'; pgrep '^atopacctd$'; sudo ls -la
> /proc/{$(pgrep '^atop$'),$(pgrep '^atopacctd$')}/fd
> 348
> 334
> /proc/334/fd:
> total 0
> dr-x-- 2 root root  0 Nov 24 20:12 .
> dr-xr-xr-x 9 root root  0 Nov 24 20:12 ..
> lr-x-- 1 root root 64 Nov 24 20:12 0 -> /run/pacct_source
> l-wx-- 1 root root 64 Nov 24 20:12 1 ->
> /run/pacct_shadow.d/00.paf
> lrwx-- 1 root root 64 Nov 24 20:12 2 -> 'socket:[12382]'
> l-wx-- 1 root root 64 Nov 24 20:12 3 -> /run/pacct_shadow.d/current
> lrwx-- 1 root root 64 Nov 24 20:12 4 -> 'socket:[12399]'
> lrwx-- 1 root root 64 Nov 24 20:12 5 -> 'socket:[12400]'
>
> /proc/348/fd:
> total 0
> dr-x-- 2 root root  0 Nov 24 20:12 .
> dr-xr-xr-x 9 root root  0 Nov 24 20:12 ..
> lr-x-- 1 root root 64 Nov 24 20:12 0 -> /dev/null
> lrwx-- 1 root root 64 Nov 24 20:12 1 -> 'socket:[12463]'
> lrwx-- 1 root root 64 Nov 24 20:12 2 -> 'socket:[12463]'
> lr-x-- 1 root root 64 Nov 24 20:12 3 ->
> /run/pacct_shadow.d/00.paf
> lrwx-- 1 root root 64 Nov 24 20:12 4 -> 'socket:[12504]'
> lrwx-- 1 root root 64 Nov 24 20:12 5 -> /var/log/atop/atop_20211124
> [3/4439]mh@testsid85:~ $
>
> What am I doing wrong here?
>
> > > > 2nd. Load atop.default file into the package to make it take effect
> > >
> > > The 2.6.0-2 package in sid and bullseye do install a file to
> > > /etc/default/atop. This file is different from the atop.default in the
> > > upstream tarball. Debian does set the -R by default.
> > >
> > > Please explain why you think the packaging does things wrong.
> > >
> > Sorry that I didn't make it clear just now. I'd mean if modifying the
> > atop.default file under the source code, the updates will not be synced
> > into debian/atop.default under debian/ directory during building.
>
> I would still think this is intended behavior. This originates from the
> fact that the support for /etc/default/atop was merged into Upstream
> from a series of Debian patches which the Upstream author kindly
> accepted (PR #28). We had the defaults file for longer than Upstream had
> it, therefore we had our own file.
>
> I see your point though, the next version will take upstream's file,
> apply a patch to make Debian's default file from there and install that
> to the package. That way, Upstream changes are going to be notice, and
> one more patch file doesn't make things any more complex. I have
> committed that change to git.
>
> Greetings
> Marc
>
> Sure, thanks for that. :)

Have a nice day, thanks
Fei

Bug#984158: grfcodec: diff for NMU version 6.0.6-5.1

[Adrian Bunk]

On Wed, Nov 24, 2021 at 08:38:16AM +0100, Matthijs Kooijman wrote:
> Hi Adrian,

Hi Matthijs,

> > I've prepared an NMU for grfcodec (versioned as 6.0.6-5.1) and uploaded 
> > it to DELAYED/15. Please feel free to tell me if I should cancel it, or
> > to use the changes for a maintainer upload instead.
> Thanks for your interest and picking this up!
> 
> However, I had actually *just* uploaded a new version myself yesterday, but
> it seems they are not picked up. I suspect this is because my gpg key
> expired and the validity extension I did a while ago isn't picked up by
> the keyring yet. As soon as it is, I expect my pending packages will be
> processed.

packages without valid signature are usually silently dropped,
expect that you might have to reupload.

> See also https://salsa.debian.org/openttd-team/grfcodec/-/commits/master/
> 
> I suspect it would be best to cancel your upload, and use my version
> instead.

Thanks, cancelled.

> Gr.
> 
> Matthijs

cu
Adrian

Bug#1000566: python3-numpy: does not document dh_numpy3 fully and documentation out of date

[Julian Gilbey]

Package: python3-numpy
Version: 1:1.21.4-2
Severity: minor
Tags: patch

Hi!

The dh_numpy3.1 manpage isn't actually installed; this can be easily
fixed by adding debian/python3-numpy.manpages with the one line:

debian/dh_numpy3.1

Also, the documentation is out-of-date; it still uses Python 2 names
and paths.  Attached are patches for dh_numpy3.1 and
README.DebianMaints to address this.

Best wishes,

   Julian
--- dh_numpy3.1.orig2021-11-20 04:39:08.0 +
+++ dh_numpy3.1 2021-11-25 07:15:12.441450261 +
@@ -1,14 +1,14 @@
-.TH DH_NUMPY 1 "2012-01-29" "Numpy"
+.TH DH_NUMPY3 1 "2012-01-29" "Numpy"
 .SH NAME
-dh_numpy \- adds Numpy depends to python:Depends substvar
+dh_numpy3 \- adds Numpy depends to python:Depends substvar
 .SH SYNOPSIS
-\fBdh_numpy\fR [\fIdebhelper\ options\fR]
+\fBdh_numpy3\fR [\fIdebhelper\ options\fR]
 .SH DESCRIPTION
 dh_numpy adds information about the correct versioned depends on python-numpy 
to python:Depends substvar.
 .PP
 This is needed because some Python extensions require strict versioned depends 
on python-numpy, and using this helper script is the easiest and most 
consistent way to get them.
 .PP
-The helper script uses the information stored in /usr/share/numpy/versions, 
and the architecture type of the package, to generate the Depends information; 
for a detailed description of how the dependencies are generate, please refer 
to /usr/share/doc/python-numpy/README.DebianMaints .
+The helper script uses the information stored in /usr/share/numpy3/versions, 
and the architecture type of the package, to generate the Depends information; 
for a detailed description of how the dependencies are generated, please refer 
to /usr/share/doc/python3-numpy/README.DebianMaints .
 .SH "SEE ALSO"
 \fIdebhelper\fR(7)
 .PP
--- README.DebianMaints.orig2021-11-20 04:39:08.0 +
+++ README.DebianMaints 2021-11-25 07:16:47.427700524 +
@@ -1,34 +1,34 @@
-Information for Maintainers of packages depending on python-numpy
--
+Information for Maintainers of packages depending on python3-numpy
+--
 
 With Numpy 1.4.1 upload in unstable, we had several packages failing
 to execute due to a change in 'dtype' format (some fields were added
 at the end of the data structure).
 
 After that, we decided to provide a reliable way to specify strict
-versioned depends on python-numpy by the packages depending on it, in
+versioned depends on python3-numpy by the packages depending on it, in
 order to avoid similar failures in future uploads.
 
-python-numpy provides a debhelper tool, dh_numpy, that will add Numpy
-dependencies to python:Depends substvar; what dh_numpy does is:
+python3-numpy provides a debhelper tool, dh_numpy3, that will add Numpy
+dependencies to python:Depends substvar; what dh_numpy3 does is:
 
-* if the package is arch:all, a simple dependency on 'python-numpy' is
+* if the package is arch:all, a simple dependency on 'python3-numpy' is
   added;
 * if the package is arch:any, two dependencies are added:
-  * python-numpy-abi$N, where N is the value for the current Numpy
+  * python3-numpy-abi$N, where N is the value for the current Numpy
 ABI, as defined by upstream C_ABI_VERSION value;
-  * python-numpy (>= $VER), where VER is the minimum python-numpy
+  * python3-numpy (>= $VER), where VER is the minimum python3-numpy
 package version implementing the current Numpy API, as defined by
 upstream C_API_VERSION value.
 * if the package is arch:any and the '--strict' command-line option is
-  passed to dh_numpy, a dependency against python-numpy-api$M is
+  passed to dh_numpy3, a dependency against python3-numpy-api$M is
   added, where M is the value for the current Numpy API, as defined by
   upstream C_API_VERSION value.
 
 The current values for API, ABI and version are available in the file
-/usr/share/numpy/versions .
+/usr/share/numpy3/versions .
 
-You should call dh_numpy regardless of the python helper you are using
+You should call dh_numpy3 regardless of the python helper you are using
 in the package.
 
  -- Sandro Tosi   Sun, 29 Jan 2012 11:01:45 +0100

Bug#1000292: Why was libpython3.10-dev not available in the test build?

[Graham Inggs]

HI Neil

On Wed, 24 Nov 2021 at 21:45, Neil Williams  wrote:
> pyhst2 build-depends on python3-dev which currently brings in
> libpython3.9-dev and it is this package which provides Python.h which
> pyhst2 requires.
>
> https://packages.debian.org/unstable/python3.10-dev depends on
> libpython3.10-dev
>
> So once python3-dev depends on python3.10-dev instead of python3.9-dev,
> then libpython3.10-dev would be installed and Python.h would exist.
>
> The build log attached to the bug has no reference to python3.10-dev or
> libpython3.10-dev, so the test build hasn't mimicked how the
> python3-dev build-dependency would work.
>
> This test was done without replicating this dependency for some reason.
>
> What was the setup of this test build?

I see pyhst2 uses '--buildsystem=pybuild' and pybuild attempts to
build with all supported python versions by default.

I think you can simply change the build-depends on python3-dev to
python3-all-dev.

Regards
Graham

Bug#1000152: Upgrading libsasl2-modules to 2.1.27+dfsg-2.2 or up broke freeipa-client

[Timo Aaltonen]

On 25.11.2021 1.07, Bastian Germann wrote:
On Thu, 18 Nov 2021 19:49:45 +0200 Timo Aaltonen  
wrote:

Source: cyrus-sasl2
Severity: important

Hi

As you can see from the CI results

https://ci.debian.net/packages/f/freeipa/unstable/amd64/

since 2021-11-04 and up the tests fail on installing the client with 
this error:


Cannot connect to the server due to generic error: Insufficient 
access: SASL(-4): no mechanism available: No worthy mechs found 
(Unknown authentication method)


I narrowed down the changed packages and the list includes 
libsasl2-modules-gssapi-mit. I verified that upgrading this package 
(and libsasl2-modules) broke my test system with the same error, 
everything else was upgraded earlier to current sid and that state 
worked fine.


Since the changes to cyrus-sasl2 can't be causing this, maybe there's 
some issue with building it with current gcc? I'll try building it 
with gcc-10 next.


Can you name the version that is causing this? Is it 2.1.27+dfsg-2.2 or 
I 2.1.27+dfsg-2.3 (which were published around the date you reported).




As the topic says, -2.2. Downgrading to -2.1 makes things work again.


--
t

Bug#1000565: named-resolvconf.service: should retain bind9-resolvconf.service alias

[Rob Leslie]

Package: bind9
Version: 1:9.16.22-1~deb11u1
Severity: normal
File: /lib/systemd/system/named-resolvconf.service

Dear Maintainer,

Upon upgrading from buster to bullseye, the bind9-resolvconf.service
unit was renamed to named-resolvconf.service. However, the previous unit
name was not retained as an alias, causing it to fail to start if it had
previously been enabled using the old name.

I suggest adding an alias in the [Install] section, in the same way as
was done for named.service:

# /lib/systemd/system/named-resolvconf.service
[Install]
Alias=bind9-resolvconf.service

Thanks.


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

Kernel: Linux 5.10.0-9-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 bind9 depends on:
ii  adduser3.118
ii  bind9-libs 1:9.16.22-1~deb11u1
ii  bind9-utils1:9.16.22-1~deb11u1
ii  debconf [debconf-2.0]  1.5.77
ii  dns-root-data  2021011101
ii  init-system-helpers1.60
ii  iproute2   5.10.0-4
ii  libc6  2.31-13+deb11u2
ii  libcap21:2.44-1
ii  libfstrm0  0.6.0-1+b1
ii  libjson-c5 0.15-2
ii  liblmdb0   0.9.24-1
ii  libmaxminddb0  1.5.2-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libuv1 1.40.0-2
ii  libxml22.9.10+dfsg-6.7
ii  lsb-base   11.1.0
ii  netbase6.3
ii  zlib1g 1:1.2.11.dfsg-2

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.16.22-1~deb11u1
ii  dnsutils   1:9.16.22-1~deb11u1
ii  resolvconf 1.87
ii  ufw0.36-7.1

-- Configuration Files:
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]
/etc/bind/zones.rfc1918 changed [not included]

-- debconf information excluded

Bug#1000564: sunxi-tools FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: sunxi-tools
Version: 1.4.2+git20181114.6d598a-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

sunxi-tools fails to cross build from source, because it builds the
tools for the build architecture. While its Makefile supports the
CROSS_COMPILE variable, it is not meant for cross building sunxi-tools
but for the target blobs. For cross building the tools, one should pass
CC and stuff. The easiest way of doing so is using dh_auto_build. It
mostly works except for the Makefile hard coding the build architecture
pkg-config. Please consider applying the attached patch to fix both.

Helmut
diff --minimal -Nru sunxi-tools-1.4.2+git20181114.6d598a/debian/changelog 
sunxi-tools-1.4.2+git20181114.6d598a/debian/changelog
--- sunxi-tools-1.4.2+git20181114.6d598a/debian/changelog   2019-01-06 
13:14:53.0 +0100
+++ sunxi-tools-1.4.2+git20181114.6d598a/debian/changelog   2021-11-25 
06:28:55.0 +0100
@@ -1,3 +1,12 @@
+sunxi-tools (1.4.2+git20181114.6d598a-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Make pkg-config substitutable.
+
+ -- Helmut Grohne   Thu, 25 Nov 2021 06:28:55 +0100
+
 sunxi-tools (1.4.2+git20181114.6d598a-3) unstable; urgency=medium
 
   * Only trigger a udev event if `udevadm` is available. Discovered by
diff --minimal -Nru 
sunxi-tools-1.4.2+git20181114.6d598a/debian/patches/cross.patch 
sunxi-tools-1.4.2+git20181114.6d598a/debian/patches/cross.patch
--- sunxi-tools-1.4.2+git20181114.6d598a/debian/patches/cross.patch 
1970-01-01 01:00:00.0 +0100
+++ sunxi-tools-1.4.2+git20181114.6d598a/debian/patches/cross.patch 
2021-11-25 06:28:55.0 +0100
@@ -0,0 +1,28 @@
+--- sunxi-tools-1.4.2+git20181114.6d598a.orig/Makefile
 sunxi-tools-1.4.2+git20181114.6d598a/Makefile
+@@ -36,6 +36,8 @@
+ 
+ DEFAULT_CFLAGS += -Iinclude/
+ 
++PKG_CONFIG ?= pkg-config
++
+ # Tools useful on host and target
+ TOOLS = sunxi-fexc sunxi-bootinfo sunxi-fel sunxi-nand-part sunxi-pio
+ 
+@@ -116,12 +118,12 @@
+   script_fex.h script_fex.c
+ 
+ LIBUSB = libusb-1.0
+-LIBUSB_CFLAGS ?= `pkg-config --cflags $(LIBUSB)`
+-LIBUSB_LIBS ?= `pkg-config --libs $(LIBUSB)`
++LIBUSB_CFLAGS ?= `$(PKG_CONFIG) --cflags $(LIBUSB)`
++LIBUSB_LIBS ?= `$(PKG_CONFIG) --libs $(LIBUSB)`
+ 
+ ZLIB = zlib
+-ZLIB_CFLAGS ?= `pkg-config --cflags $(ZLIB)`
+-ZLIB_LIBS ?= `pkg-config --libs $(ZLIB)`
++ZLIB_CFLAGS ?= `$(PKG_CONFIG) --cflags $(ZLIB)`
++ZLIB_LIBS ?= `$(PKG_CONFIG) --libs $(ZLIB)`
+ 
+ ifeq ($(OS),Windows_NT)
+   # Windows lacks mman.h / mmap()
diff --minimal -Nru sunxi-tools-1.4.2+git20181114.6d598a/debian/patches/series 
sunxi-tools-1.4.2+git20181114.6d598a/debian/patches/series
--- sunxi-tools-1.4.2+git20181114.6d598a/debian/patches/series  2019-01-06 
13:14:53.0 +0100
+++ sunxi-tools-1.4.2+git20181114.6d598a/debian/patches/series  2021-11-25 
06:28:55.0 +0100
@@ -1 +1,2 @@
 debian-changes
+cross.patch
diff --minimal -Nru sunxi-tools-1.4.2+git20181114.6d598a/debian/rules 
sunxi-tools-1.4.2+git20181114.6d598a/debian/rules
--- sunxi-tools-1.4.2+git20181114.6d598a/debian/rules   2018-12-16 
15:42:42.0 +0100
+++ sunxi-tools-1.4.2+git20181114.6d598a/debian/rules   2021-11-25 
06:28:52.0 +0100
@@ -15,7 +15,7 @@
 
 override_dh_auto_build:
$(MAKE) -C thunks CROSS_COMPILE=arm-none-eabi-
-   $(MAKE) CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" tools
+   dh_auto_build -- CFLAGS="$(CFLAGS) $(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" 
tools
mkimage -A arm -T script -d bin/ramboot.uboot-sh bin/ramboot.scr
 
 override_dh_auto_install: PKG := debian/sunxi-tools

Bug#1000563: iverilog FTCBFS: fails checking for the build architecture compiler

[Helmut Grohne]

Source: iverilog
Version: 11.0-1.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

iverilog fails to cross build from source, because it checks for the
build architecture compiler at the end of the configure run when the
LIBS variable is already set. As such, the macro includes those LIBS and
fails to find them for the build architecture concluding that the build
architecture compiler is broken. The solution is to run the macro early.
Please consider applying the attached patch.

Helmut
--- iverilog-11.0.orig/configure.ac
+++ iverilog-11.0/configure.ac
@@ -14,6 +14,7 @@
 AC_CANONICAL_HOST
 dnl Checks for programs.
 AC_PROG_CC
+AX_PROG_CC_FOR_BUILD
 AC_PROG_CXX
 AC_PROG_RANLIB
 AC_CHECK_TOOL(LD, ld, false)
@@ -329,6 +330,5 @@
 AC_MSG_ERROR(cannot configure white space in libdir: $libdir)
 fi
 AC_MSG_RESULT(ok)
-AX_PROG_CC_FOR_BUILD
 AC_CONFIG_FILES([Makefile ivlpp/Makefile vhdlpp/Makefile vvp/Makefile vpi/Makefile driver/Makefile driver-vpi/Makefile cadpli/Makefile libveriuser/Makefile tgt-null/Makefile tgt-stub/Makefile tgt-vvp/Makefile tgt-vhdl/Makefile tgt-fpga/Makefile tgt-verilog/Makefile tgt-pal/Makefile tgt-vlog95/Makefile tgt-pcb/Makefile tgt-blif/Makefile tgt-sizer/Makefile])
 AC_OUTPUT

Bug#1000562: ibverbs-providers: conffiles not removed: /etc/libibverbs.d/i40iw.driver

[Paul Wise]

Package: ibverbs-providers
Version: 38.0-1
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ p=ibverbs-providers ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | 
grep obsolete
ibverbs-providers:amd64: obsolete-conffile /etc/libibverbs.d/i40iw.driver
 /etc/libibverbs.d/i40iw.driver 0c578834d36b026c283bab90016e1e03 obsolete

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates-debug'), (860, 'testing-proposed-updates'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ibverbs-providers depends on:
ii  libc6    2.32-4
ii  libibverbs1  38.0-1

ibverbs-providers recommends no packages.

ibverbs-providers suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#966137: crazydiskinfo: some disks get ignored

[Paul Wise]

Control: forwarded -1 https://github.com/otakuto/crazydiskinfo/issues/17

On Thu, 23 Jul 2020 17:38:15 +0200 Adam Borowski wrote:

> Only some disks show up for me.  I've got sda, sdb, nvme0..7 on this box,
> and only sda is visible in "crazy", while smartctl handles them fine.

This is discussed in the upstream bug tracker at the URL above. The
issue is that crazydiskinfo uses libatasmart, which doesn't have
support for newer disk technologies. There is an in-progress backend
that switches to smartctl --json, but that hasn't been release yet.

https://github.com/otakuto/crazydiskinfo/tree/2.0.0

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1000561: batik: new upstream version 1.14

[tony mancill]

Source: batik
Version: 1.12-4
Severity: wishlist

I am preparing an update to batik to 1.14.  This bug is to avoid
duplication of effort.

Bug#1000439: fcitx5: icons of individual input methods are not being displayed

[Wenbin Lv]

Hi,

Icons are displayed correctly now. Thank you!

Best regards,
Wenbin Lv

On Thu, Nov 25, 2021 at 5:30 AM Boyuan Yang  wrote:
>
> Control: notfound -1 5.0.10-1
> Control: close -1
>
> On Wed, 24 Nov 2021 01:04:15 +0800 Shengjing Zhu  wrote:
> > Control: severity -1 serious
> >
> > On Tue, Nov 23, 2021 at 4:57 PM Wenbin Lv  wrote:
> > >
> > > Package: fcitx5
> > > Version: 5.0.10-1
> > > Severity: normal
> > >
> > > Dear maintainer,
> > >
> > > In version 5.0.10-1, when an input method is activated, the icon of the
> > > activated input method is not being displayed correctly in notification
> > > area. In Xfce, the icon will be blank. In MATE the icon defaults to
> > > org.fcitx.Fcitx5.png. Below is the output of fcitx5-diagnose. There is
> > > nothing interesting in the output of fcitx5 --verbose 5, though.
> > >
> >
> > This is because we begin to roll out reverting the fcitx5 icon patch
> (#976603).
> > Things will be settled when we have updated all fcitx5 packages.
> >
> > I'm raising the severity so 5.0.10-1 won't migrate to testing, until
> > we have finished updating all fcitx5 packages.
>
> Now all packages in Debian unstable are refreshed with fcitx5 icon patch
> removed. Please update your system to latest packages, and let me know if such
> issue still exist.
>
> Thanks,
> Boyuan Yang

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[David]

On Thu, 28 Oct 2021 at 14:12, Nicholas D Steeves  wrote:
> Holger Wansing  writes:
> > David  wrote (Sat, 9 Oct 2021 21:56:24 +1100):

> >> I see that the suggestion to use 'cat' comes
> >> from #604839.
> >>
> >> Yes, 'cat' will "work", however I feel there is no
> >> good reason to use 'cat' there.
> >>
> >> Because the purpose of 'cat' is for concatenating
> >> multiple files, and it also requires a shell redirection
> >> from stdout. Both are unnecessary here.
> >>
> >> I suggest this command should be used:
> >> # cp /usr/lib/syslinux/mbr.bin /dev/sdX

> Wow that's a new capability :-)  IIRC cp couldn't historically write
> directly to block devices, and DEST had to be either a target file or
> directory.  It makes me wonder if install(1) has also gained spooky new
> capabilities :-p

> > The documentation in the syslinux package also has
> >
> >   A simple MBR, roughly on par with the one installed by DOS (but
> >   unencumbered), is included in the SYSLINUX distribution.  To install
> >   it under Linux, simply type:
> >
> >   cat mbr.bin > /dev/XXX
> >
> >   ... where /dev/XXX is the device you wish to install it on.
> >
> > so I guess there is some good reason to do it thisSection 4.3.1 way.

Hello again,

I noticed a discussion [1][2][3] today which reports that using 'cp'
for this kind of action is successful with some Gnu version of 'cp'
but not with some version of Busybox.

The person also states that they would not expect 'cp' to succeed ...
'''On a traditional linux system where dev is just a directory in root
and the device files are created using mknod'''.

In my first message to this bug I suggested to use 'cp', but my
suggestion was only motivated by desire to avoid apparent
inconsistency with Section 4.3.1. Which uses the 'cat' command for an
identical purpose, as I mentioned at the time.

So it appears that if Gnu 'cp' is to be used for both situations then
that would work. On the other hand, if a non-Gnu 'cp' might be used,
then perhaps both commands in the Installation Guide should be changed
to 'cat', for consistency.

I do not have a strong opinion, nor interest, nor technical argument.
I just try to provide information which might assist to achieve the
best outcome.

With best regards, David

[1] 
https://www.reddit.com/r/linux/comments/qzxdg4/psa_dd_for_writing_a_disk_image/hlpz1b6/
[2] 
https://www.reddit.com/r/linux/comments/qzxdg4/psa_dd_for_writing_a_disk_image/hlq1cdl/
[3] 
https://www.reddit.com/r/linux/comments/qzxdg4/psa_dd_for_writing_a_disk_image/hlq8ohw/

Bug#999363: Shouldn't replace pulseaudio by pipewire by default

[Vincent Lefevre]

On 2021-11-10 15:40:21 +0100, Sebastien Bacher wrote:
> The pipewire 0.3.39-3 updated replaced pipewire-media-service Recommends by
> wireplumber, or wireplumber Recommends pipewire-pulse which makes it take
> over pulseaudio as the default sound service. We got several report of
> people upgrading and having issues on #debian-gnome.
> Pipewire is installed by default on GNOME because it's used for screen
> recording but pulseaudio is still installed and our default sound server.

This actually affects more users than just users of the GNOME desktop.
For instance, the installation of the zenity package (whose goal is
to display graphical dialog boxes from shell scripts) yields the
installation of pipewire via dependencies. So...

> Switching the default sound service is an option but should probably be a
> project discussion and not a consequence of a dependency tweak.

I entirely agree.

In particular, headphones handling is buggy with pipewire-pulse
(bug 998073), so this package should not be installed by default.

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

Bug#997908: pocl: Assertion `td->printf_buffer != NULL' failed on armel/armhf

[Andreas Beckmann]

On 22/11/2021 23.05, Rebecca N. Palmer wrote:

libgpuarray also runs ulimit (and tries and fails to run clinfo)


I didn't expect clinfo to fail ...

Andreas

Bug#997719: libvirt-python: diff for NMU version 7.9.0-0.1

[Stefano Rivera]

Control: tags 997719 + patch
Control: tags 997719 + pending

Dear maintainer,

I've prepared an NMU for libvirt-python (versioned as 7.9.0-0.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru libvirt-python-7.0.0/AUTHORS libvirt-python-7.9.0/AUTHORS
--- libvirt-python-7.0.0/AUTHORS	2021-01-15 04:52:56.818376800 -0400
+++ libvirt-python-7.9.0/AUTHORS	2021-11-01 08:22:58.888680200 -0400
@@ -12,6 +12,7 @@
Adam Litke 
Alex Jia 
Andrea Bolognani 
+   Beraldo Leal 
Boris Fiuczynski 
Brian Rak 
Chris Lalancette 
@@ -41,6 +42,7 @@
Jim Meyering 
Jiri Denemark 
John Ferlan 
+   Jonathon Jongsma 
Jovanka Gulicoska 
Ján Tomko 
KAMEZAWA Hiroyuki 
@@ -75,6 +77,7 @@
Pradipta Kr. Banerjee 
Qiaowei Ren 
Radostin Stoyanov 
+   renlei4 
Richard W.M. Jones 
Robie Basak 
Serge E. Hallyn 
@@ -87,6 +90,7 @@
Victor Stinner 
Viktor Mihajlovski 
Vincent Vanlaer 
+   w00506750 
Wojtek Porczyk 
Wu Zongyong 
Xavier Fernandez 
diff -Nru libvirt-python-7.0.0/ChangeLog libvirt-python-7.9.0/ChangeLog
--- libvirt-python-7.0.0/ChangeLog	2021-01-15 04:52:56.868377000 -0400
+++ libvirt-python-7.9.0/ChangeLog	2021-11-01 08:22:58.915347000 -0400
@@ -1,3 +1,364 @@
+2021-10-08 Daniel P. Berrangé  
+
+Add support for domain event for memory device size change
+
+
+2021-10-01 Jiri Denemark  
+
+Post-release version bump to 7.9.0
+
+
+2021-09-24 Michal Privoznik  
+
+sanitytest: Add virNetworkCreateXMLFlags() to list of name fixups
+When checking whether each C API is exported to Python and vice
+versa the sanitytest script is doing some name fixing. For
+instance virNetworkCreateXML() is translated into
+virConnect.networkCreateXML(). However, we have new C API on the
+way: virNetworkCreateXMLFlags() which is not on the list for
+these name fixups. Add it there.
+
+Mind you, the python code generator works just fine because
+generator.py:1082 compares just the prefix.
+
+
+
+2021-09-21 Jonathon Jongsma  
+
+Don't mention email patch submission in README
+Since patches are now submitted via gitlab merge requests, don't mention
+mailing list patch submission in the README. Point to the CONTRIBUTING
+file instead.
+
+
+
+2021-09-21 Jonathon Jongsma  
+
+Update readme to mention pytest instead of nose
+Commit a376a2ab switch from python-nose to python-pytest for tests, but
+the README was not updated.
+
+
+
+2021-09-21 Jonathon Jongsma  
+
+Add new autostart API for node devices
+Provide a manual override for the virNodeDeviceGetAutostart() API
+modeled on what's done for the network and storage APIs.
+
+
+
+2021-09-02 Daniel P. Berrangé  
+
+ci: remove obsolete refresh script and documentation
+We now use lcitool's manifest feature to generate files.
+
+
+
+2021-09-02 Daniel P. Berrangé  
+
+ci: re-generate containers/gitlab config from manifest
+This uses the command "lcitool manifest ci/manifest.yml" to re-generate
+all existing dockerfiles and gitlab CI config.
+
+
+
+2021-09-02 Daniel P. Berrangé  
+
+ci: define a CI manifest file
+This is to be used with the command "lcitool manifest ci/manifest.yml"
+to re-generate all existing dockerfiles and gitlab CI config.
+
+
+
+2021-09-01 Daniel P. Berrangé  
+
+rpm: drop support for RHEL-7
+We no longer support libvirt on this distro
+
+
+
+2021-09-01 Jiri Denemark  
+
+Post-release version bump to 7.8.0
+
+
+2021-08-02 Jiri Denemark  
+
+Post-release version bump to 7.7.0
+
+
+2021-07-27 Daniel P. Berrangé  
+
+gitlab: use custom docker:dind image
+The current docker:dind container has broken default seccomp filter that
+results in clone3 being blocked, which in turn breaks Fedora 35 rawhide.
+
+This custom image has a workaround that causes the seccomp filter to
+return ENOSYS for clone3 instad of EPERM, thus triggering glibc to
+fallback to clone correctly.
+
+
+
+2021-07-01 Jiri Denemark  
+
+Post-release version bump to 7.6.0
+
+
+2021-06-25 Peter Krempa  
+
+Fix BlockThreshold Callback argument conversion once more
+The conversion was changed from "OssiiO" to "OssLLO". Unfortunately the
+arguments are unsigned long long, where the proper coversion character
+is 'K'.
+
+Fixes: https://gitlab.com/libvirt/libvirt-python/-/merge_requests/40
+Fixes: fd069ac85c8cf1593587dc9287a3d5eb6bd4bdb9
+Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1976109
+
+
+2021-06-01 Jiri Denemark  
+
+Post-release version bump to 7.5.0
+
+
+2021-05-27 w00506750  
+
+iothread: fix memory access out of bounds
+When the 'pcpu' is 

Bug#669900: ITP: slideshow

[Bastian Germann]

On Sat, 21 Apr 2012 21:37:09 +0200 Thomas Dreibholz  
wrote:

* Package name: slideshow
  Version : 2.2.2
  Upstream Author : Thomas Dreibholz 
* URL : http://www.iem.uni-due.de/~dreibh/slideshow/
* License : GPL version 3
  Programming Lang: C++
  Description : HTML slide show and image presentation generator

SlideShow is a command-line tool to generate standards-compliant XHTML-1.1 
presentations from a set of image files. It can be used to easily generate 
online photo albums, including JavaScript-based slideshows. Particularly, this 
program is intended to be also used in scripts, which automatically create or 
update slideshows.


Hi Thomas,

The URL has obviously changed to https://www.uni-due.de/~be0001/slideshow/

Please only keep ITP bugs when you actually plan to hand in a package.
Just reassigning to yourself for almost 10 years once the ITP->RFP automation kicks in keeps this software from entering 
Debian as other interested packagers are kept away.


Cheers,
Bastian

Bug#1000152: Upgrading libsasl2-modules to 2.1.27+dfsg-2.2 or up broke freeipa-client

[Bastian Germann]

On Thu, 18 Nov 2021 19:49:45 +0200 Timo Aaltonen  wrote:

Source: cyrus-sasl2
Severity: important

Hi

As you can see from the CI results

https://ci.debian.net/packages/f/freeipa/unstable/amd64/

since 2021-11-04 and up the tests fail on installing the client with 
this error:


Cannot connect to the server due to generic error: Insufficient access: 
SASL(-4): no mechanism available: No worthy mechs found (Unknown 
authentication method)


I narrowed down the changed packages and the list includes 
libsasl2-modules-gssapi-mit. I verified that upgrading this package (and 
libsasl2-modules) broke my test system with the same error, everything 
else was upgraded earlier to current sid and that state worked fine.


Since the changes to cyrus-sasl2 can't be causing this, maybe there's 
some issue with building it with current gcc? I'll try building it with 
gcc-10 next.


Can you name the version that is causing this? Is it 2.1.27+dfsg-2.2 or I 2.1.27+dfsg-2.3 (which were published around 
the date you reported).

Bug#1000558: Compatibility with Symfony 5

[David Prévot]

Package: php-cboden-ratchet
Version: 0.4.2-1
Severity: serious
X-Debbugs-Cc: Debian PHP PEAR Maintainers 
User: pkg-php-p...@lists.alioth.debian.org
Usertags: Symfony5
Control: clone -1 -2 -3
Control: reassign -2 php-robmorgan-phinx 0.9.2-3
Control: reassign -3 php-laravel-framework 6.20.14+dfsg-2

Hi,

Since symfony 5 has finally been uploaded to unstable, packages now
can’t depend on php-symfony-* (<< 5) anymore. Upgrading to a new
upstream version should do the trick (Symfony 5 has been released two
years ago).

Symfony 5 (5.4, the upcoming LTS) will a priori be the version in
Bookworm, the next LTS (6.4) is expected in two years from now, so
probably well after the freeze starts (and hopefully the Bookworm
release).

Thanks in advance for fixing this issue, do not hesitate to ask for help
on pkg-php-p...@lists.alioth.debian.org if needed.

Regards

David


signature.asc
Description: PGP signature

Bug#1000557: dpkg-source should fail if maintainer is not ubuntu and DEBEMAIL contains canonical.com

[Guillem Jover]

Hi!

On Wed, 2021-11-24 at 16:02:22 -0600, William 'jawn-smith' Wilson wrote:
> Package: dpkg
> Severity: minor
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch

> dpkg-source will do a check for a scenario where the maintainer field in
> d/control does not contain "ubuntu" and the DEBEMAIL environment
> variable ends in @ubuntu.com. There are some Canonical employees that
> use an @canonical.com email address instead, so we should expand this
> check to also trigger on DEBEMAIL values that end in @canonical.com

> In Ubuntu, the attached patch was applied to achieve the following:
> 
> Have dpkg-source fail in the aforementioned scenario, rather than a
> warning.
> 
>   * scripts/Dpkg/Vendor/Ubuntu.pm: when checking for the correct
> maintainer field, also look for @canonical.com email addresses
> (LP: #1951988)

I think the patch was missing checking for canonical also in the
field. Attached what I'm planning to merge. Let me know if the address
I used in the attribution is correct or you'd prefer something else
(just copied the one in the email)?

Thanks,
Guillem
From ca991d0c7c844fa2ea86ffddc66089d08c26c246 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Wed, 24 Nov 2021 23:48:06 +0100
Subject: [PATCH] Dpkg::Vendor::Ubuntu: Update Maintainer field logic to
 include canonical

Some Ubuntu maintainers use addresses with @canonical.com, handle those
in the check.

Closes: #1000557
Based-on-patch-by: William 'jawn-smith' Wilson 
Signed-off-by: Guillem Jover 
---
 scripts/Dpkg/Vendor/Ubuntu.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Dpkg/Vendor/Ubuntu.pm b/scripts/Dpkg/Vendor/Ubuntu.pm
index 0352a127d..e222088ff 100644
--- a/scripts/Dpkg/Vendor/Ubuntu.pm
+++ b/scripts/Dpkg/Vendor/Ubuntu.pm
@@ -54,8 +54,8 @@ sub run_hook {
 # https://wiki.ubuntu.com/DebianMaintainerField
 if (defined($fields->{'Version'}) and defined($fields->{'Maintainer'}) and
$fields->{'Version'} =~ /ubuntu/) {
-   if ($fields->{'Maintainer'} !~ /ubuntu/i) {
-   if (length $ENV{DEBEMAIL} and $ENV{DEBEMAIL} =~ /\@ubuntu\.com/) {
+   if ($fields->{'Maintainer'} !~ /(?:ubuntu|canonical)/i) {
+   if (length $ENV{DEBEMAIL} and $ENV{DEBEMAIL} =~ /\@(?:ubuntu|canonical)\.com/) {
error(g_('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address'));
} else {
warning(g_('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address'));
-- 
2.34.0

Bug#996806: mailmain3: Expected test results for arc_validate tests need updating

[Jordi Mallach]

Source: mailman3
Version: 3.3.3-1
Followup-For: Bug #996806

Apparently this is fixed in upstream commit
f311b135fe13e3ec07ef2eedadba9c09b25e57ff

See

https://gitlab.com/mailman/mailman/-/commit/f311b135fe13e3ec07ef2eedadba9c09b25e57ff

for more details.

I might try to work on a fix in the following days, most probably
including an update to the latest version, which includes other fixes I
need.

Jordi

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

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

Bug#996260: packages for Buster and Bullseye

[Thorsten Alteholz]

Updated packages for Buster and Bullseye have been prepared. The progress 
of reaching the archive is tracked in #1000486 for Buster and #1000485 for 
Bullseye. Until the packages appear in the archive, they can be also 
downloaded from[1].


  Thorsten


[1] https://people.debian.org/~alteholz/packages/to-be-released-soon/

Bug#1000495: openssh: drop the advertisement clause in BSD license

[Colin Watson]

On Wed, Nov 24, 2021 at 01:50:01PM +0530, Ritesh Raj Sarraf wrote:
> Niels gave his explicit permission to drop clause 3, the "advertising" 
> clause, from his code.
> This restores the GPL compatibility.
> 
> Request if the same can be updated in this package.
> 
> References:
> * https://github.com/pyca/bcrypt/pull/170
> * 
> https://github.com/pyca/bcrypt/files/3081054/Blowfish-cypher-license-change.pdf

Regardless of what permission Niels has given, I can't unilaterally
change it in Debian's OpenSSH packaging; it needs to be updated upstream
first.  Please file a bug at bugzilla.mindrot.org about this and mark
this bug as forwarded (I don't think it makes sense for me to be in the
middle here).

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

Bug#1000557: dpkg-source should fail if maintainer is not ubuntu and DEBEMAIL contains canonical.com

[William 'jawn-smith' Wilson]

Package: dpkg
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

dpkg-source will do a check for a scenario where the maintainer field in
d/control does not contain "ubuntu" and the DEBEMAIL environment
variable ends in @ubuntu.com. There are some Canonical employees that
use an @canonical.com email address instead, so we should expand this
check to also trigger on DEBEMAIL values that end in @canonical.com

-- Package-specific info:
System tainted due to merged-usr-via-aliased-dirs.


*** /tmp/tmpb4294xf9/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

Have dpkg-source fail in the aforementioned scenario, rather than a
warning.

  * scripts/Dpkg/Vendor/Ubuntu.pm: when checking for the correct
maintainer field, also look for @canonical.com email addresses
(LP: #1951988)


Thanks for considering the patch.


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

Kernel: Linux 5.13.0-20-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru dpkg-1.20.9ubuntu2/debian/control dpkg-1.20.9ubuntu3/debian/control
--- dpkg-1.20.9ubuntu2/debian/control   2021-04-14 05:32:22.0 -0500
+++ dpkg-1.20.9ubuntu3/debian/control   2021-11-23 09:42:41.0 -0600
@@ -1,8 +1,7 @@
 Source: dpkg
 Section: admin
 Priority: required
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Dpkg Developers 
+Maintainer: Dpkg Developers 
 Uploaders: Guillem Jover 
 Homepage: https://wiki.debian.org/Teams/Dpkg
 Vcs-Browser: https://git.dpkg.org/cgit/dpkg/dpkg.git
diff -Nru dpkg-1.20.9ubuntu2/scripts/Dpkg/Vendor/Ubuntu.pm 
dpkg-1.20.9ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm
--- dpkg-1.20.9ubuntu2/scripts/Dpkg/Vendor/Ubuntu.pm2021-04-14 
05:32:22.0 -0500
+++ dpkg-1.20.9ubuntu3/scripts/Dpkg/Vendor/Ubuntu.pm2021-11-23 
09:42:41.0 -0600
@@ -55,7 +55,7 @@
 if (defined($fields->{'Version'}) and defined($fields->{'Maintainer'}) 
and
$fields->{'Version'} =~ /ubuntu/) {
if ($fields->{'Maintainer'} !~ /ubuntu/i) {
-   if (length $ENV{DEBEMAIL} and $ENV{DEBEMAIL} =~ 
/\@ubuntu\.com/) {
+   if (length $ENV{DEBEMAIL} and $ENV{DEBEMAIL} =~ 
/\@ubuntu\.com|\@canonical\.com/) {
error(g_('Version number suggests Ubuntu changes, but 
Maintainer: does not have Ubuntu address'));
} else {
warning(g_('Version number suggests Ubuntu changes, but 
Maintainer: does not have Ubuntu address'));
File /tmp/6yZkN9jpdE/dpkg-1.20.9ubuntu2/tests/t-unpack-fifo/pkg-fifo/test-fifo 
is a fifo while file 
/tmp/u2tkW_fatS/dpkg-1.20.9ubuntu3/tests/t-unpack-fifo/pkg-fifo/test-fifo is a 
fifo
File 
/tmp/6yZkN9jpdE/dpkg-1.20.9ubuntu2/tests/t-unpack-hardlink/pkg-hardlink/test-fifo-link0
 is a fifo while file 
/tmp/u2tkW_fatS/dpkg-1.20.9ubuntu3/tests/t-unpack-hardlink/pkg-hardlink/test-fifo-link0
 is a fifo
File 
/tmp/6yZkN9jpdE/dpkg-1.20.9ubuntu2/tests/t-unpack-hardlink/pkg-hardlink/test-fifo-link1
 is a fifo while file 
/tmp/u2tkW_fatS/dpkg-1.20.9ubuntu3/tests/t-unpack-hardlink/pkg-hardlink/test-fifo-link1
 is a fifo

Bug#851148:

[Dana Goyette]

Looks like Debian bullseye is missing this patch:
https://gitlab.gnome.org/GNOME/tracker-miners/-/commit/30b24e9d379458b66f2465422821a66bec3a749b

strace of tracker-extract shows this:
...
[pid 42781] openat(AT_FDCWD, "/sys/devices/system/cpu",
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 21
[pid 42781] fstat(21, {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 42781] getdents64(21, 0x5005a950 /* 32 entries */, 32768) = 928
[pid 42781] getdents64(21, 0x5005a950 /* 0 entries */, 32768) = 0
[pid 42781] close(21)   = 0
[pid 42781] sched_getaffinity(42781, 8, [0, 1, 2, 3, 4, 5, 6, 7,
8, 9, 10, 11, 12, 13, 14, 15]) = 8
[pid 42781] faccessat(AT_FDCWD, "/etc/gcrypt/fips_enabled", F_OK)
= -1 ENETDOWN (Network is down)
[pid 42781] --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP,
si_call_addr=0xa5a7c014, si_syscall=__NR_faccessat,
si_arch=AUDIT_ARCH_AARCH64} ---

For reference, my machine is a Honeycomb LX2K (LX2160A).

dana@honeycomb:~$ apt-cache policy tracker-miner-fs
tracker-miner-fs:
  Installed: 2.3.5-2.1
  Candidate: 2.3.5-2.1
  Version table:
 *** 2.3.5-2.1 500
500 http://mirrors.edge.kernel.org/debian bullseye/main arm64 Packages
100 /var/lib/dpkg/status

Bug#1000555: RM: flask-assets -- ROM; depends on non-maintainable python-flask-script

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Dear FTP master,

Since Flask 2.0 was uploaded, python-flask-script FTBFS. python-flask-script
has no support upstream, no commit since 2017. Both flask-assets and
python-flask-script have no reverse dependency. So I'm hereby asking to
remove both python-flask-script and flask-assets which depends on
python-flask-script.

Note that I asked on the Debian Python Team list, and nobody opposed to it.

This bug is for flask-assets while another one has been written for
python-flask-script.

Cheers,

Thomas Goirand

Bug#1000556: RM: python-flask-script -- ROM; FTBFS, no support upstream, no reverse dep

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal


Dear FTP master,

Since Flask 2.0 was uploaded, python-flask-script FTBFS. python-flask-script
has no support upstream, no commit since 2017. Both flask-assets and
python-flask-script have no reverse dependency. So I'm hereby asking to
remove both python-flask-script and flask-assets which depends on
python-flask-script.

Note that I asked on the Debian Python Team list, and nobody opposed to it.

This bug is for python-flask-script while another one has been written for
flask-assets.

Cheers,

Thomas Goirand

Bug#1000439: fcitx5: icons of individual input methods are not being displayed

[Boyuan Yang]

Control: notfound -1 5.0.10-1
Control: close -1

On Wed, 24 Nov 2021 01:04:15 +0800 Shengjing Zhu  wrote:
> Control: severity -1 serious
> 
> On Tue, Nov 23, 2021 at 4:57 PM Wenbin Lv  wrote:
> >
> > Package: fcitx5
> > Version: 5.0.10-1
> > Severity: normal
> >
> > Dear maintainer,
> >
> > In version 5.0.10-1, when an input method is activated, the icon of the
> > activated input method is not being displayed correctly in notification
> > area. In Xfce, the icon will be blank. In MATE the icon defaults to
> > org.fcitx.Fcitx5.png. Below is the output of fcitx5-diagnose. There is
> > nothing interesting in the output of fcitx5 --verbose 5, though.
> >
> 
> This is because we begin to roll out reverting the fcitx5 icon patch
(#976603).
> Things will be settled when we have updated all fcitx5 packages.
> 
> I'm raising the severity so 5.0.10-1 won't migrate to testing, until
> we have finished updating all fcitx5 packages.

Now all packages in Debian unstable are refreshed with fcitx5 icon patch
removed. Please update your system to latest packages, and let me know if such
issue still exist.

Thanks,
Boyuan Yang


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

Bug#999906: After upgrade to Debian Bullseye, I am not able to burn DVDs.

[Thomas Schmitt]

Hi,

> I tested at first the live CD of Debian 10.
> K3B also disrespects the speed setting. But the process seems to
> adjust the speed automatically. 18x was starting speed and it was
> reduced, so that the resulting speed was 4x.

An initial utopic speed is not necessarily the fault of the burn
program. The drive's buffer accepts data with high speed until it is
full, so only after 2 or 4 MB the observed speed drops to the real
speed of burning. DVD-R usually get burned with constant angular
velocity (rounds per minute), so that the linear speed reaches the
desired speed only at the end of burning.


> K3B under Debian 11 still behaves as before.
> Setting speed is totally ignored, the burner makes noise like a starting
> jet, and finishes with error and overall speed of 18,4x.

I really wonder what might have changed in K3B.

You could try with Xfburn again.
Its source code looks like it would ask libburn to set a speed.
Regrettably i find no hints in the web how to increase Xfburn's verbosity
so that you get to see the debug message

  Set speed to ... kb/s

which is to see immediately before the call to burn_drive_set_speed().
See:
  
https://sources.debian.org/src/xfburn/0.6.2-1/xfburn/xfburn-burn-audio-cd-composition-dialog.c/?hl=299#L299


> Unfortunately, I am not able to reproduce the error again with xorrecord.

I count this as a piece of luck for me. :))

It is not normal that a drive produces bad results if it is asked for
high speed or if it is not asked for low speed.
So whatever K3B or growisofs (*) do wrong, your drive did its share to
cause the failure.

(*) It might be that K3B uses cdrskin instead of growisofs.
But i have no idea how to find out which of both is in charge for DVD.
(cdrskin is the cdrecord compatibility wrapper of libburn.)


Have a nice day :)

Thomas

Bug#1000550: RM: elpy -- RoQA; FTBFS; unmaintained upstream

[Nicholas D Steeves]

Dear Andrey and ftpmasters,

I'm the primary uploader for this package.

Andrey Rahmatullin  writes:

> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-Cc: nstee...@gmail.com
>
> This package wasn't updated for the Python 3.9 transition and removed from
> testing on 2021-03-07. The FTBFS with 3.9 bug isn't fixed upstream and
> there are upstream maintenance problems documented at
> https://github.com/jorgenschaefer/elpy/issues/1884
>

Thank you for reminding me about this upstream thread.  Yes, it's
definitely time that I post another follow-up message there.

Could we please defer this removal until at least 2022-03-07 as a
reasonable compromise?  I think it's uncharitable and ablist to put more
pressure than that on a project whose maintainer is suffering from hand
injury/tendonitis...these things take a long time to resolve--years, not
months--and if we're a project that truly believes in diversity,
empathy, and equal opportunity, then we must accommodate people who are
struggling.

I'm also not sure what would be a sensitive way to broach a deadline
upstream.  Sure, proposing a deadline and a plan can definitely be an
opportunity to show leadership, and in thinking about this possibility
I'm coming up with a concrete structure of goals/sprints to make
progress...but in doing this I would become the defacto upstream
maintainer, and that's something I know I won't be able to commit to
long-term.

Would it be enough to couch my involvement with some kind of disclaimer
like "I'm doing this temporarily with the objective of training my (and
Gaby Launay's) replacement"?  And also of course that I'm not the best
person for the job!  I confess that I'm not a good enough Python
programmer to just fix all the problems myself.

Yes, I agree that at some point, if the project is dead, then it should
be removed from Debian.  I also appreciate the notice that I haven't
done everything I could reasonably do for the success of Elpy.  You're
right (see above).


Thank you,
Nicholas

P.S. Never have I hidden a problem by disabling a test that was arguably
relevant to a Debian QA context.  I'm also strict about not uploading
anything that has outstanding issues.


signature.asc
Description: PGP signature

Bug#1000554: RFS: libfm-qt/0.16.0-3.1 [NMU] [RC] -- Language package for libfm-qt

[S. 7]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "libfm-qt":

* Package name : libfm-qt
Version : 0.16.0-3.1
Upstream Author : LXQt team 
* URL : https://github.com/lxqt/libfm-qt
* License : LGPL-2.1+, BSD-3-Clause
* Vcs : https://salsa.debian.org/lxqt-team/libfm-qt
Section : x11

It builds those binary packages:

libfm-qt8 - file management support for pcmanfm-qt
libfm-qt-dev - file management support library for pcmanfm-qt 
(development files)

libfm-qt-l10n - Language package for libfm-qt

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


https://mentors.debian.net/package/libfm-qt/

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

dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfm-qt/libfm-qt_0.16.0-3.1.dsc


Changes since the last upload:

libfm-qt (0.16.0-3.1) unstable; urgency=high
.
* Non-maintainer upload
* Update symbols to fix FTBFS. (Closes: #984102)

Regards,

S. 7

Bug#998252: bullseye-pu: package authheaders/0.13.0-1

[Scott Kitterman]

On Mon, 01 Nov 2021 12:40:05 -0400 Scott Kitterman  
wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> This updates to the upstream bug-fix only release for the 0.13 branch,
> 0.13.1.  This module is used by mailman3 in bullseye and some of the
> bugs will preclude successful mail delivery.
> 
> From a bugfix perspective this includes all the fixes in 0.14.0 in
> unstable.  It does not include the change that caused the mailman3 test
> failures (which aren't real failures, just a change in the expected
> results).  Eventually unstable/testing will get sorted, but it's
> unrelated to these fixes, so I would prefer not to wait.  It's fixed
> upstream already.
> 
> Note: Most of the diff is the upstream PSL update which won't affect
> Debian either way, we use the system PSL.
> 
> Except for s/UNRELEASED/bullseye// in debian/changelog it is ready to
> upload.  I have successfully built the package and run the autopkgtests
> in a bullseye environment.
> 
> Scott K

The new version (0.14.0) is now in Testing, so that block to this pu going 
forward no longer exists.

Scott K

Bug#999988: postfix: depends on obsolete pcre3 library

[Scott Kitterman]

On Thursday, November 18, 2021 8:06:55 AM EST Scott Kitterman wrote:
> On November 18, 2021 11:49:06 AM UTC, Matthew Vernon  
wrote:
> >Source: postfix
> >Severity: important
> >User: matthew-pcre...@debian.org
> >Usertags: obsolete-pcre3
> >
> >Dear maintainer,
> >
> >Your package still depends on the old, obsolete PCRE3[0] libraries
> >(i.e. libpcre3-dev). This has been end of life for a while now, and
> >upstream do not intend to fix any further bugs in it. Accordingly, I
> >would like to remove the pcre3 libraries from Debian, preferably in
> >time for the release of Bookworm.
> >
> >The newer PCRE2 library was first released in 2015, and has been in
> >Debian since stretch. Upstream's documentation for PCRE2 is available
> >here: https://pcre.org/current/doc/html/
> >
> >Many large projects that use PCRE have made the switch now (e.g. git,
> >php); it does involve some work, but we are now at the stage where
> >PCRE3 should not be used, particularly if it might ever be exposed to
> >untrusted input.
> >
> >This mass bug filing was discussed on debian-devel@ in
> >https://lists.debian.org/debian-devel/2021/11/msg00176.html
> >
> >Regards,
> >
> >Matthew [0] Historical reasons mean that old PCRE is packaged as
> >pcre3 in Debian
> 
> I've investigated this and some non-trivial porting is needed.  I've
> discussed this with upstream and it's one their TODO list for the next
> postfix release.

It's implemented now for postfix 3.7, so this should be closed well before our 
next release.

Scott K

Bug#1000553: transition: simdjson

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-simdjson.html

On 2021-11-24 12:42:06 -0800, Mo Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> simdjson upstream has bumped the SOVERSION from 5 to 9.
> It has one (and only one) reverse dependency beyond my
> maintenance, so I'm opening this transition bug.
> 
> the reverse depenency src:vast is successfully built locally.

Please go ahead

Cheers

> 
> 
> Ben file:
> 
> title = "simdjson";
> is_affected = .depends ~ "libsimdjson5" | .depends ~ "libsimdjson9";
> is_good = .depends ~ "libsimdjson9";
> is_bad = .depends ~ "libsimdjson5";
> Thank you for using reportbug
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1000553: transition: simdjson

[Mo Zhou]

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

Hi release team,

simdjson upstream has bumped the SOVERSION from 5 to 9.
It has one (and only one) reverse dependency beyond my
maintenance, so I'm opening this transition bug.

the reverse depenency src:vast is successfully built locally.


Ben file:

title = "simdjson";
is_affected = .depends ~ "libsimdjson5" | .depends ~ "libsimdjson9";
is_good = .depends ~ "libsimdjson9";
is_bad = .depends ~ "libsimdjson5";
Thank you for using reportbug

Bug#1000552: openpyxl breaks python-agate-excel autopkgtest

[Paul Gevers]

Source: openpyxl, python-agate-excel
Control: found -1 openpyxl/3.0.9-1
Control: found -1 python-agate-excel/0.2.3-1
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of openpyxl the autopkgtest of python-agate-excel 
fails in testing when that autopkgtest is run with the binary packages 
of openpyxl from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
openpyxl   from testing3.0.9-1
python-agate-excel from testing0.2.3-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of openpyxl to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=openpyxl

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-agate-excel/16944816/log.gz

=== FAILURES 
===
_ TestXLSX.test_ambiguous_date 
_


self = 

def test_ambiguous_date(self):
table = agate.Table.from_xlsx('examples/test_ambiguous_date.xlsx')
self.assertColumnNames(table, ['s'])
self.assertColumnTypes(table, [agate.Date])

  self.assertRows(table, [

[datetime.date(1899, 12, 31)],
])

tests/test_table_xlsx.py:108: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/agate/testcase.py:53: in assertRows

self.assertSequenceEqual(table.rows[i], row)
E   AssertionError: Sequences differ: 1, 1))> != [datetime.date(1899, 12, 31)]

E   E   First differing element 0:
E   datetime.date(1900, 1, 1)
E   datetime.date(1899, 12, 31)
E   E   - 
E   + [datetime.date(1899, 12, 31)]
=== warnings summary 
===

tests/test_table_xls.py::TestXLS::test_header
tests/test_table_xlsx.py::TestXLSX::test_header
  /usr/lib/python3/dist-packages/agateexcel/table_xls.py:91: 
RuntimeWarning: Column names not specified. "('a', 'b', 'c')" will be 
used as names.


tests/test_table_xls.py::TestXLS::test_numeric_column_name
tests/test_table_xlsx.py::TestXLSX::test_numeric_column_name
  /usr/lib/python3/dist-packages/agate/utils.py:285: 
UnnamedColumnWarning: Column 2 has no name. Using "c".


tests/test_table_xlsx.py::TestXLSX::test_file_like
tests/test_table_xlsx.py::TestXLSX::test_from_xlsx
tests/test_table_xlsx.py::TestXLSX::test_from_xlsx_with_column_names
tests/test_table_xlsx.py::TestXLSX::test_sheet_index
tests/test_table_xlsx.py::TestXLSX::test_sheet_multiple
tests/test_table_xlsx.py::TestXLSX::test_sheet_multiple
tests/test_table_xlsx.py::TestXLSX::test_sheet_name
  /usr/lib/python3/dist-packages/openpyxl/worksheet/_reader.py:312: 
UserWarning: Unknown extension is not supported and will be removed


-- Docs: https://docs.pytest.org/en/stable/warnings.html
=== short test summary info 

FAILED tests/test_table_xlsx.py::TestXLSX::test_ambiguous_date - 
AssertionErr...
== 1 failed, 22 passed, 11 warnings in 0.53s 
===

autopkgtest [01:11:31]: test command1




OpenPGP_signature
Description: OpenPGP digital signature

Bug#998368: upstream issue

[Gert van de Kraats]

I reported the bug upstream at pulseaudio:

https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1297

Bug#1000504: linux-image-5.15.0-1-amd64: FUSE regression in 5.15.3 affecting xdg-desktop-portal

[Salvatore Bonaccorso]

Hi,

On Wed, Nov 24, 2021 at 11:33:08AM +, Simon McVittie wrote:
> Package: src:linux
> Version: 5.15.3-1
> Severity: normal
> Tags: upstream
> Control: affects -1 xdg-desktop-portal flatpak
> 
> Linux 5.15.3, 5.14.20 and other stable kernels are reported to have a
> regression that causes Flatpak apps to freeze when using a FUSE filesystem
> to load files from the host system. I can't reproduce this myself, but
> it has been seen in at least Red Hat and Gentoo, so I wanted to raise
> it in Debian as something to watch out for.
> 
> The regression was triggered by:
> https://lore.kernel.org/all/2025165430.669780...@linuxfoundation.org/
> "fuse: fix page stealing", 712a951025c0667ff00b25afc360f74e639dfabe upstream
> 
> https://lore.kernel.org/all/CAOssrKez1mnF4rWRvWgk4LJ2iDfX8xkpMKvgprFt+-ARs83=n...@mail.gmail.com/
> is a possible solution (untested - as I said, I couldn't reproduce this
> myself).
> 
> Tracked elsewhere:
> https://github.com/flatpak/flatpak/issues/4595
> https://bugzilla.redhat.com/show_bug.cgi?id=2025285

And looks there is now a fix for it:

https://lore.kernel.org/stable/CAOssrKez1mnF4rWRvWgk4LJ2iDfX8xkpMKvgprFt+-ARs83=n...@mail.gmail.com/

If you in meanwhile were able to reproduce it and can test the patch
as well that would be great.

712a951025c0 ("fuse: fix page stealing") in any case was backported as
well to 5.10.80, so would need to make sure that we do not release in
next point release a version newly affected.

Regards,
Salvatore

Bug#1000551: elfutils: Segfault in read_addrs

[Rich Ercolani]

Package: elfutils
Version: 0.183-1
Severity: normal

Dear Maintainer,

While experimenting with drgn [1], I ran into a crash[3], which seems to be 
from a bug introduced in elfutils 0.183 and fixed in 0.186[2].

I don't know if said bug meets the threshold for a backport on stable, but 
figured I'd ask, since the alternative is that I carry my own elfutils packages 
until bookworm...

- Rich

[1] - https://github.com/osandov/drgn
[2] - 
https://sourceware.org/git/?p=elfutils.git;a=commit;h=828024afc517e266f3226b469ba33f372b401821
[3] - https://github.com/osandov/drgn/issues/130

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (1000, 'stable-updates'), (1000, 'stable-security'), (1000, 
'stable-debug'), (1000, 'stable'), (901, 'proposed-updates'), (900, 
'oldstable-proposed-updates-debug'), (900, 'oldstable-debug'), (900, 
'testing'), (800, 'unstable-debug'), (500, 'proposed-updates-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages elfutils depends on:
ii  libasm1 0.183-1
ii  libc6   2.31-13+deb11u2
ii  libdw1  0.183-1
ii  libelf1 0.183-1
ii  libstdc++6  10.2.1-6

elfutils recommends no packages.

elfutils suggests no packages.

-- debconf-show failed

Bug#1000536: marked as done (python3-py-stringmatching: need to depend on a versioned python3-numpy)

[Sandro Tosi]

>  py-stringmatching (0.4.2+git20201204.6a7fb57-5) unstable; urgency=medium
>  .
>* Make versioned dependency on python3-numpy (Closes: #1000536)

then you probably need to use dh_numpy3, and not hardcode versions
(which is what i supposed you did here, given you havent pushed the
latest changes to git yet)

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

Bug#1000549: Astroberry is buster

[Jens Scheidtmann]

Note that Astroberry, the Raspian config most users report this from, is
still on buster.

Bug#1000292: Why was libpython3.10-dev not available in the test build?

[Neil Williams]

pyhst2 build-depends on python3-dev which currently brings in
libpython3.9-dev and it is this package which provides Python.h which
pyhst2 requires.

https://packages.debian.org/unstable/python3.10-dev depends on
libpython3.10-dev

So once python3-dev depends on python3.10-dev instead of python3.9-dev,
then libpython3.10-dev would be installed and Python.h would exist.

The build log attached to the bug has no reference to python3.10-dev or
libpython3.10-dev, so the test build hasn't mimicked how the
python3-dev build-dependency would work.

This test was done without replicating this dependency for some reason.

What was the setup of this test build?

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpjepMLjA5uq.pgp
Description: OpenPGP digital signature

Bug#1000271: (no subject)

[Gordon Ball]

I'm a bit mysterified by this. Failed tests do seem to be reproducible
(in debci) with this package pinned, but I can't work out how the traceback
shown actually stems from jupyter_client.

This version is meant to already include compatibility fixes
(https://github.com/dask/distributed/pull/5286) for jupyter_client 7.
I'm wondering if this is something obscure like more filehandles or
ports ending up being used and causing interference further down the
line.

Any ideas?

Bug#1000550: RM: elpy -- RoQA; FTBFS; unmaintained upstream

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: nstee...@gmail.com

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2021-03-07. The FTBFS with 3.9 bug isn't fixed upstream and
there are upstream maintenance problems documented at
https://github.com/jorgenschaefer/elpy/issues/1884


$ dak rm -Rn elpy
Will remove the following packages from unstable:

 elpa-elpy |   1.34.0-2 | all
  elpy |   1.34.0-2 | source

Maintainer: Debian Emacsen team 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#999448: [External] Re: Bug#999448: atop: Two fixes for debian/rules: activate atopacctd before activating atop, load atop.default into pkg

[Marc Haber]

Hi,

On Thu, Nov 11, 2021 at 06:56:33PM +0800, 李菲 wrote:
> wrote:
> I guess the below 'Reproduce' can tell this :) That is, if atop starts
> before
> atopacctd, it will read from /var/cache/atop.d/atop.acct. Instead, if
> atopacctd
> starts earlier, atop will read from /run/pacct_shadow.d/00.paf
> which is generated by atopacctd.

Is this a race condition that only occurs once in a while? I tried it
three times now on a test system and all three times it ended up with
atop reading from the .paf file right after reboot.

Example output:
[2/4438]mh@testsid85:~ $ pgrep '^atop$'; pgrep '^atopacctd$'; sudo ls -la 
/proc/{$(pgrep '^atop$'),$(pgrep '^atopacctd$')}/fd
348
334
/proc/334/fd:
total 0
dr-x-- 2 root root  0 Nov 24 20:12 .
dr-xr-xr-x 9 root root  0 Nov 24 20:12 ..
lr-x-- 1 root root 64 Nov 24 20:12 0 -> /run/pacct_source
l-wx-- 1 root root 64 Nov 24 20:12 1 -> /run/pacct_shadow.d/00.paf
lrwx-- 1 root root 64 Nov 24 20:12 2 -> 'socket:[12382]'
l-wx-- 1 root root 64 Nov 24 20:12 3 -> /run/pacct_shadow.d/current
lrwx-- 1 root root 64 Nov 24 20:12 4 -> 'socket:[12399]'
lrwx-- 1 root root 64 Nov 24 20:12 5 -> 'socket:[12400]'

/proc/348/fd:
total 0
dr-x-- 2 root root  0 Nov 24 20:12 .
dr-xr-xr-x 9 root root  0 Nov 24 20:12 ..
lr-x-- 1 root root 64 Nov 24 20:12 0 -> /dev/null
lrwx-- 1 root root 64 Nov 24 20:12 1 -> 'socket:[12463]'
lrwx-- 1 root root 64 Nov 24 20:12 2 -> 'socket:[12463]'
lr-x-- 1 root root 64 Nov 24 20:12 3 -> /run/pacct_shadow.d/00.paf
lrwx-- 1 root root 64 Nov 24 20:12 4 -> 'socket:[12504]'
lrwx-- 1 root root 64 Nov 24 20:12 5 -> /var/log/atop/atop_20211124
[3/4439]mh@testsid85:~ $

What am I doing wrong here?

> > > 2nd. Load atop.default file into the package to make it take effect
> >
> > The 2.6.0-2 package in sid and bullseye do install a file to
> > /etc/default/atop. This file is different from the atop.default in the
> > upstream tarball. Debian does set the -R by default.
> >
> > Please explain why you think the packaging does things wrong.
> >
> Sorry that I didn't make it clear just now. I'd mean if modifying the
> atop.default file under the source code, the updates will not be synced
> into debian/atop.default under debian/ directory during building.

I would still think this is intended behavior. This originates from the
fact that the support for /etc/default/atop was merged into Upstream
from a series of Debian patches which the Upstream author kindly
accepted (PR #28). We had the defaults file for longer than Upstream had
it, therefore we had our own file.

I see your point though, the next version will take upstream's file,
apply a patch to make Debian's default file from there and install that
to the package. That way, Upstream changes are going to be notice, and
one more patch file doesn't make things any more complex. I have
committed that change to git.

Greetings
Marc

Bug#1000549: Knotifications leaks file descriptors using phonon and should use canberra instead.

[Jens Scheidtmann]

Package: libkf5notifications5
Version: 5.54.0-1

On Raspian (armhf), numerous Kstars users have problems due to phonon
leaking  file descriptors, which is invoked from knotifications, see
https://bugs.kde.org/show_bug.cgi?id=07
Harald Sitter recommending to compile knotifications against Canberra
instead.

Original reports see here:
https://indilib.org/forum/ekos/10705-kstars-ekos-freezing-on-large-image-sequences-astroberry.html#77529

Bug#1000548: RM: meliae -- RoQA; FTBFS; uninstallable; dead upstream?

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: jel...@debian.org

This package wasn't updated for the Python 3.9 transition. It was removed from
testing even earlier than that, on 2019-09-03. Its FTBFS with 3.9 bug is
still not fixed upstream.

$ dak rm -Rn meliae
Will remove the following packages from unstable:

meliae | 0.5.1+bzr231-3 | source
python3-meliae | 0.5.1+bzr231-3 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x
python3-meliae-dbg | 0.5.1+bzr231-3 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x

Maintainer: Jelmer Vernooij 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000547: RM: ROM; NPOASR; FTBFS; doesn't work

[Andrey Rahmatullin]

Package: ftp.debian.org
X-Debbugs-Cc: debian-pyt...@lists.debian.org, rodrilopez@gmail.com
Severity: normal

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. Its FTBFS actually suggests it doesn't work with modern
celery, this was fixed upstream by
https://github.com/clokep/celery-batches/pull/21

$ dak rm -Rn celery-batches
Will remove the following packages from unstable:

celery-batches |  0.2-2 | source
python3-celery-batches |  0.2-2 | amd64, arm64, armel, armhf, i386, 
mips64el, mipsel, ppc64el, s390x

Maintainer: Debian Python Modules Team 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000546: RM: logging-tree -- RoQA; FTBFS; unmaintained

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: feder...@debian.org

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. Its last maintainer upload was in 2019. 
There is a patch for the 3.9 FTBFS in the BTS and it's also fixed upstream.

$ dak rm -Rn logging-tree
Will remove the following packages from unstable:

logging-tree |  1.8.1-0.1 | source
python3-logging-tree |  1.8.1-0.1 | all

Maintainer: Federico Ceratto 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#981464: systemctl --user start fetchmail.service

[Barak A. Pearlmutter]

Agreed: it would probably make sense for these systemd support
materials to go upstream. (Modulo approval, smoothing off rough edges,
etc.)

Let me know if there's anything I should do to help.

Bug#1000545: RM: doublex -- ROM; FTBFS; dead upstream

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org, david.vi...@gmail.com

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-11-27. The test failures aren't fixed upstream, and
https://bitbucket.org/DavidVilla/python-doublex/issues/3/#comment-60228312
suggests the upstream is not active.

$ dak rm -Rn doublex
Will remove the following packages from unstable:

   doublex |1.9.2-1 | source
python3-doublex |1.9.2-1 | all

Maintainer: David Villa Alises 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000544: RM: lasagne -- RoQA; FTBFS; orphaned

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-08-13. It was orphaned on 2020-11-18 with "Package has
bugs that cannot be easily solved and upstream is unresponsive."



$ dak rm -Rn lasagne
Will remove the following packages from unstable:

   lasagne | 0.1+git20200419.5d3c63c+ds-1 | source
lasagne-doc | 0.1+git20200419.5d3c63c+ds-1 | all
python3-lasagne | 0.1+git20200419.5d3c63c+ds-1 | all

Maintainer: Debian Science Maintainers 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000543: RM: python-enable -- ROM; FTBFS; not installable

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org, va...@debian.org

This package wasn't updated for the Python 3.9 transition. It was removed
from testing even earlier than that, on 2019-10-19. It's not installable
as it requires Python 3.7 or 3.8.
The FTBFS bug is fixed upstream at
https://github.com/enthought/enable/issues/360 (according to the bug
metadata).

$ dak rm -Rn python-enable
Will remove the following packages from unstable:

python-enable |4.8.1-1 | source
python3-enable |4.8.1-1 | amd64, arm64, armel, armhf, i386, mips64el, 
mipsel, ppc64el, s390x

Maintainer: Debian Python Modules Team 


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1000542: RM: celery-haystack -- ROM; FTBFS; doesn't work; dead upstream

[Andrey Rahmatullin]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org, fl...@debian.org

This package wasn't updated for the Python 3.9 transition and removed from
testing on 2020-12-11. Its FTBFS actually suggests it doesn't work with modern
celery, the upstream bug is https://github.com/django-haystack/celery-
haystack/issues/64. There are some PRs and a fork
(https://pypi.org/project/celery-haystack-ng/) linked there.

Bug#1000541: firmware-iwlwifi: are some firmwares missing or is the boot looking upstream unavailable ones?

[Patrice Duroux]

Package: firmware-iwlwifi
Version: 20210818-1
Severity: minor

Dear Maintainer,

This is more an observation than an issue on my system.

dmesg messages say:

[   12.316908] iwlwifi :6f:00.0: enabling device ( -> 0002)
[   12.337431] iwlwifi :6f:00.0: firmware: failed to load iwlwifi-
cc-a0-66.ucode (-2)
[   12.337443] iwlwifi :6f:00.0: Direct firmware load for iwlwifi-
cc-a0-66.ucode failed with error -2
[   12.337471] iwlwifi :6f:00.0: firmware: failed to load iwlwifi-
cc-a0-65.ucode (-2)
[   12.337476] iwlwifi :6f:00.0: Direct firmware load for iwlwifi-
cc-a0-65.ucode failed with error -2
[   12.337494] iwlwifi :6f:00.0: firmware: failed to load iwlwifi-
cc-a0-64.ucode (-2)
[   12.337497] iwlwifi :6f:00.0: Direct firmware load for iwlwifi-
cc-a0-64.ucode failed with error -2
[   12.339305] iwlwifi :6f:00.0: firmware: direct-loading firmware iwlwifi-
cc-a0-63.ucode
[   12.339338] iwlwifi :6f:00.0: api flags index 2 larger than supported by
driver
[   12.339377] iwlwifi :6f:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version:
89.3.35.37
[   12.340243] iwlwifi :6f:00.0: loaded firmware version 63.c04f3485.0
cc-a0-63.ucode op_mode iwlmvm
[   12.340301] iwlwifi :6f:00.0: firmware: failed to load iwl-debug-
yoyo.bin (-2)
[   12.649115] iwlwifi :6f:00.0: Detected Intel(R) Wi-Fi 6 AX200 160MHz,
REV=0x340
[   12.797211] iwlwifi :6f:00.0: Detected RF HR B3, rfid=0x10a100
[   12.866241] iwlwifi :6f:00.0: base HW address: 5c:80:b6:e9:d7:d9
[   13.392299] iwlwifi :6f:00.0 wlp111s0: renamed from wlan0

The iwlwifi-cc-a0-[66,65,64].ucode firmwares do not exist neither in the
package neither here:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git/tree/
But it exists there iwlwifi-cc-a0-67.ucode that is not in the package.

Could this be the reason of those messages?

Thanks,
Patrice

ps: my system kernel package is linux-image-5.15.0-1-amd64 (5.15.3-1)


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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.140

-- no debconf information

Bug#981464: systemctl --user start fetchmail.service

[GCS]

Hi Barak, Matthias,

On Tue, Nov 23, 2021 at 11:51 AM Barak A. Pearlmutter
 wrote:
> I've written a unit so I can run fetchmail under systemd as a user service.
> I'd suggest that the file /usr/lib/systemd/user/fetchmail.service (see
> below) be included in the package.
 It would be best if upstream integrates it to the source code. Even
if 6.4.25 is just around the corner.

> It would also make sense to describe how to actually enable it, by
> putting something like the following into
> /usr/share/doc/fetchmail/README.systemd:
>
> To run fetchmail as a systemd user service, for an individual user:
>
> (1) Configuration
>
> Set up your .fetchmailrc so that "fetchmail --nodetach" actually
> fetches your mail correctly.
>
> (2) Tell systemd to run it as a service
>
> Allow daemons to keep running after you log out (optional):
> $ sudo loginctl enable-linger $USERNAME
>
> Make the service available:
> $ systemctl --user enable fetchmail.service
>
> Actually turn it on:
> $ systemctl --user start fetchmail.service
>
> Monitor it, to check if it's okay:
> $ systemctl --user status fetchmail.service
>
> Monitor it harder:
> $ journalctl --user -xeu fetchmail.service
 This is also a good candidate for upstream.

> Caveat:
>
> In the below fetchmail.service file, I'm not sure if the "ExecStop="
> command is a good idea. If you just leave that line out, systemd will
> kill the process using its own mechanisms, which are effective but
> perhaps a bit brutal. Might be more robust to just leave it out.
>
> It's currently set to wake up every 5min. Not sure how to make this
> default nicely but still be easy to change. Perhaps some systemd
> wizard can help?
 That's not me, but should look into it.

The actual systemctl service file:
> $ cat /usr/lib/systemd/user/fetchmail.service
> [Unit]
> Description=Fetchmail Daemon
> Documentation=man:fetchmail(1)
>
> [Service]
> ExecStart=fetchmail --nodetach --daemon 300
> ExecStop=fetchmail --quit
> Restart=always
>
> [Install]
> WantedBy=default.target

Regards,
Laszlo/GCS

Bug#995942: Acknowledgement (/usr/bin/ibus-ui-emojier-plasma: does not show any emojis)

[Tobias Kölsch]

Dear Maintainer,

the bug does not manifest any more in the current version:

Package: plasma-desktop
Version: 4:5.23.3-1

So from my point of view this ticket can be closed.

Yours kindly,

 Tobias

PS: Thanks for the great job! I use KDE with Debian for years now and in 
my opinion it is the most usable desktop environment (over all operating 
systems I've used so far). Keep up the good work :-)

Bug#1000539: RM: boost1.71 -- ROM; Outdated version

[Anton Gladky]

Package: ftp.debian.org
Severity: normal

Dear FTP masters,

please remove the boost1.71, which is replaced by a newer version.


Thanks

Anton

Bug#1000538: fdupes never stops - no files deleted - ever asking same questions

[Pierre Meurisse]

Package: fdupes
Version: 1:2.1.2-1
Severity: important

Dear Maintainer,


I used fdupes in order to delete duplicate files in a directory with
one subdirectory :

fdupes -r -d . 

There came 6 sets of files

As I did before with debian 10, I chose to preserve one file each time. 
ex :

Set 5 of 6:

[-] ./9296.epub.epub
[+] ./calibre_bust/Samuel Richardson/Clarissa Harlowe; or the history of a 
young lady -- Volume 1 (219)/Clarissa Harlowe; or th
e history of a youn - Samuel Richardson.epub

Set 6 of 6:

  1 [-] ./pg59774-images.epub
  2 [+] ./calibre_bust/H. G. Wells/30 Strange Stories (225)/30 Strange Stories 
- H. G. Wells.epub

Usualy, the program would stop deleting unwanted files.

But with debian 11.1 The only way to stop is Crtl C then exit and no files are
deleted.
If I answer no to exit, same questions come back again. 







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

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

Versions of packages fdupes depends on:
ii  libc6  2.31-13+deb11u2
ii  libncursesw6   6.2+20201114-2
ii  libpcre2-32-0  10.36-2
ii  libtinfo6  6.2+20201114-2

fdupes recommends no packages.

fdupes suggests no packages.

-- no debconf information

Bug#1000537: apt: [INTL:de] updated German po file translation

[Helge Kreutzmann]

Package: apt
Version: 2.3.12
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for apt
attached.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# German messages for the apt suite.
# Copyright (C) 1997, 1998, 1999 Jason Gunthorpe and others.
# Helge Kreutzmann , 2020, 2021.
# Holger Wansing , 2008, 2009, 2010, 2012, 2014, 2017, 
2018.
# Jens Seidel , 2008.
# Michael Piefel , 2001, 2002, 2003, 2004, 2006.
# Rüdiger Kuhlmann , 2002.
#
#
msgid ""
msgstr ""
"Project-Id-Version: apt 2.3.12\n"
"Report-Msgid-Bugs-To: APT Development Team \n"
"POT-Creation-Date: 2021-11-17 18:30+0100\n"
"PO-Revision-Date: 2021-11-24 17:53+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: German \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n != 1;\n"

#: apt-pkg/acquire-item.cc
msgid ""
"Updating from such a repository can't be done securely, and is therefore "
"disabled by default."
msgstr ""
"Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art "
"durchgeführt werden, daher ist es standardmäßig deaktiviert."

#: apt-pkg/acquire-item.cc
msgid ""
"Data from such a repository can't be authenticated and is therefore "
"potentially dangerous to use."
msgstr ""
"Daten von solch einem Depot können nicht authentifiziert werden und deren "
"Nutzung ist daher potentiell gefährlich."

#: apt-pkg/acquire-item.cc
msgid ""
"See apt-secure(8) manpage for repository creation and user configuration "
"details."
msgstr ""
"Weitere Details zur Erzeugung von Paketdepots sowie zu deren "
"Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8)."

#: apt-pkg/acquire-item.cc
#, c-format
msgid "The repository '%s' is no longer signed."
msgstr "Das Depot »%s« ist nicht mehr signiert."

#: apt-pkg/acquire-item.cc
#, c-format
msgid "The repository '%s' no longer has a Release file."
msgstr "Das Depot »%s« enthält keine Release-Datei mehr."

#: apt-pkg/acquire-item.cc
msgid ""
"This is normally not allowed, but the option Acquire::"
"AllowDowngradeToInsecureRepositories was given to override it."
msgstr ""
"Dies ist normalerweise nicht erlaubt, was aber wegen der angegebenen Option "
"»Acquire::AllowDowngradeToInsecureRepositories« unbeachtet blieb."

#: apt-pkg/acquire-item.cc
#, c-format
msgid "The repository '%s' is not signed."
msgstr "Das Depot »%s« ist nicht signiert."

#: apt-pkg/acquire-item.cc
#, c-format
msgid "The repository '%s' does not have a Release file."
msgstr "Das Depot »%s« enthält keine Release-Datei."

#: apt-pkg/acquire-item.cc
#, c-format
msgid "The repository '%s' provides only weak security information."
msgstr ""
"Das Depot »%s« stellt nur schwache Sicherheitsinformationen zur Verfügung."

#: apt-pkg/acquire-item.cc ftparchive/writer.cc
#, c-format
msgid "Failed to readlink %s"
msgstr "readlink von %s fehlgeschlagen"

#: apt-pkg/acquire-item.cc ftparchive/cachedb.cc methods/rred.cc
#, c-format
msgid "Failed to stat %s"
msgstr "%s mit »stat« abfragen fehlgeschlagen"

#: apt-pkg/acquire-item.cc
msgid "Hash Sum mismatch"
msgstr "Hash-Summe stimmt nicht überein"

#: apt-pkg/acquire-item.cc
msgid "Insufficient information available to perform this download securely"
msgstr ""
"Es sind nur unzureichende Informationen verfügbar, um diesen Download auf "
"sichere Art durchzuführen."

#: apt-pkg/acquire-item.cc apt-pkg/contrib/fileutl.cc
#, c-format
msgid "rename failed, %s (%s -> %s)."
msgstr "Umbenennen fehlgeschlagen, %s (%s -> %s)."

#: apt-pkg/acquire-item.cc
msgid "Size mismatch"
msgstr "Größe stimmt nicht überein"

#: apt-pkg/acquire-item.cc
msgid "Invalid file format"
msgstr "Ungültiges Dateiformat"

#: apt-pkg/acquire-item.cc
msgid "Signature error"
msgstr "Signaturfehler"

#. TRANSLATORS: %s is a single techy word like 'NODATA'
#: apt-pkg/acquire-item.cc methods/gpgv.cc
#, c-format
msgid ""
"Clearsigned file isn't valid, got '%s' (does the network require "
"authentication?)"
msgstr ""
"Durch Clearsign signierte Datei ist nicht gültig, »%s« erhalten (erfordert "
"das Netzwerk eine Authentifizierung?)"

#: apt-pkg/acquire-item.cc
#, c-format
msgid ""
"An error occurred during the signature verification. The repository is not "
"updated and the previous index files will be used. GPG error: %s: %s"
msgstr ""
"Während der Überprüfung der Signatur trat ein Fehler auf. Das Depot wurde "
"nicht aktualisiert und die vorherigen Indexdateien werden verwendet. GPG-"
"Fehler: %s: %s"

#. Invalid signature file, reject (LP: #346386) (Closes: #627642)
#: apt-pkg/acquire-item.cc
#, c-format
msgid "GPG error: %s: %s"
msgstr "GPG-Fehler: %s: %s"

#: apt-pkg/acquire-item.cc
#, c-format
msgid ""
"Skipping acquire of configured file '%s' as repository '%s' doesn't have 

Bug#991548: mesa: Since 20.3.5-1 AMD Vega GPU runs at max V and 90W in idle

[Diederik de Haas]

On Wed, 28 Jul 2021 16:52:47 +0200 Pim  wrote:
> This issue looks similar: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991453

Indeed, the symptoms sound very familiar.

According to the other bug report, it was a kernel issue which got fixed with 
5.10.46-3, so the most likely case is that it's already resolved.
'merspieler' can you confirm that?
The link in the submission doesn't work for me (anymore?), but the following 
command should make it clear whether it is the same issue as #991453:

$ cat /sys/class/drm/card0/device/gpu_busy_percent

and running 'sensors' showed quite a dramatic change in power1 and fans also 
got quiet again after 5.10.46-3.

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

Bug#1000536: python3-py-stringmatching: need to depend on a versioned python3-numpy

[Julian Gilbey]

Package: python3-py-stringmatching
Version: 0.4.2+git20201204.6a7fb57-4
Severity: serious

This package uses python3-numpy when compiling the C extension, and
hence requires a binary compatible version of python3-numpy at
runtime.  It therefore needs a versioned dependency on python3-numpy,
and should not enter testing while testing has an incompatible numpy.

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Vincent Lefevre]

On 2021-11-24 16:31:08 +0100, Guillem Jover wrote:
> The symlinks must be kept for backwards compat. Please see #998169 for
> the context of this packaging cleanup.

OK, thanks. #998169 gives the explanation.

Note that I was also wondering whether these symblinks are still
actually used. For instance, libgdal29 3.3.3+dfsg-2 depends on
libodbc1 (>= 2.3.1), but

$ ldd /usr/lib/libgdal.so.29 | grep libodbc
libodbc.so.2 => /usr/lib/x86_64-linux-gnu/libodbc.so.2 
(0x7fb732d54000)
libodbcinst.so.2 => /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 
(0x7fb732d3c000)

So the .so.2 names are already used, and the symlinks are not needed
for libgdal29. Now, what about the other packages? Since these .so.2
sonames were added in 2013 (8 years ago!), I suppose that the old
.so.1 sonames are no longer used at all, so that no backward compat
symlinks are needed.

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

Bug#1000535: sphinxcontrib-restbuilder: please make the build reproducible

[Chris Lamb]

Source: sphinxcontrib-restbuilder
Version: 0.3-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
sphinxcontrib-restbuilder could not be built reproducibly.

This is because it shipped a number of (nondeterministic) doctrees
directories. Patch attached that strips these from the binary package.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2021-11-24 08:19:00.071258610 -0800
--- b/debian/rules  2021-11-24 08:36:22.646195299 -0800
@@ -13,3 +13,5 @@
dh_auto_install
# Remove the folder output/, it's not intended to get into the package.
rm -rf 
debian/python3-sphinxcontrib.restbuilder/usr/lib/python3.?/dist-packages/output
+   # Don't ship .doctrees directories
+   find debian/python3-sphinxcontrib.restbuilder -type d -name .doctrees 
-print0 | xargs -0r rm -rfv

Bug#1000530: dnsutils: dig don't accept questions about wildcard records

[Ondřej Surý]

dig is now IDN enabled and ‘*’ is not a valid not a legal IDN name.

Adding `+noidnin` turns of IDN processing (as does piping the dig
to another shell command).

e.g.

dig +noidnin '*.wildcard.rfc1925.org'

dig '*.wildcard.rfc1925.org' | cat

works.

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

> On 24. 11. 2021, at 17:03, Jörgen Hägg  wrote:
> 
> Package: dnsutils
> Version: 1:9.17.20-2
> Severity: normal
> X-Debbugs-Cc: j...@axis.com
> 
> 
> 
> 
> -- System Information:
> Debian Release: bookworm/sid
>  APT prefers oldoldstable
>  APT policy: (500, 'oldoldstable'), (500, 'unstable'), (101, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_SE:en_US:en_GB:en
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages dnsutils depends on:
> ii  bind9-dnsutils  1:9.17.20-2
> 
> dnsutils recommends no packages.
> 
> dnsutils suggests no packages.
> 
> -- no debconf information
> 
> --
> (domain obfuscated)
> 
> "dig  '*.xxx.yyy.example.com' any" returns this:
> 
> dig: '*.xxx.yyy.example.com' is not a legal name (empty label)
> 
> I get the same answer no matter what domain I test, be there
> a real wildcard record or not.
> 
> Version 1:9.17.19-3 seems to work.
> This is an example from version 1:9.11.5.P4+dfsg-5.1+deb10u6:
> 
> *.xxx.yyy.example.com.10800   IN  CNAME   xxx.yyy.example.com.
> 
> --
> dig '*.example.com' any
> 
> Older:
> ;*.example.com.   IN  ANY
> 
> Current:
> dig: '*.example.com' is not a legal name (empty label)
> 

Bug#998108: reopening 998108

[Eugen Dedu]

On 21/11/2021 00:43, Christoph Anton Mitterer wrote:

On Sat, 2021-11-20 at 15:30 -0800, Josh Triplett wrote:

I'm still experiencing this bug regularly, with complete browser UI
freezes that require killing and restarting Firefox.


Hm perhaps something else? At least I haven't suffered from that
particular issue since 94.0-2.


94.0-2 fixed the issue for me too.

Bug#761157: grep -P is very slow on binary files

[Vincent Lefevre]

Control: found -1 3.7-1

On 2014-09-11 10:12:35 +0200, Vincent Lefevre wrote:
> Between grep 2.18-2 and grep 2.20-3 (fixing bug 758105), there is a
> huge slowdown when binary files (with invalid UTF-8 sequences) are
> involved. The timings on my personal svn working copy (with all my
> files), when searching for a word that doesn't exist (no matches):
> 
> grep 2.18-2:  0.9 s
> grep 2.20-3: 11.6 s
> 
> Note: the -P is useless in this case, but it is useful in other cases.

The current grep version 3.7-1 is also affected.

The upstream bug has been closed after the move to PCRE2.

Once the new grep is available in Debian, some tests need to be
done to see whether this change introduces any regression.

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

Bug#1000534: sphinxcontrib-htmlhelp: please make the build reproducible

[Chris Lamb]

Source: sphinxcontrib-htmlhelp
Version: 2.0.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
sphinxcontrib-htmlhelp could not be built reproducibly.

This is because it uses the tag_date feature of Python eggs which gets
encoded into the binary package in a number of ways (eg. directory
names, etc.)

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible_build.patch   2021-11-24 08:09:50.781024706 
-0800
@@ -0,0 +1,14 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-11-24
+
+--- sphinxcontrib-htmlhelp-2.0.0.orig/setup.cfg
 sphinxcontrib-htmlhelp-2.0.0/setup.cfg
+@@ -1,6 +1,6 @@
+ [egg_info]
+ tag_build = .dev
+-tag_date = true
++tag_date = false
+ 
+ [aliases]
+ release = egg_info -Db ''
--- a/debian/patches/series 1969-12-31 16:00:00.0 -0800
--- b/debian/patches/series 2021-11-24 08:09:50.065024317 -0800
@@ -0,0 +1 @@
+reproducible_build.patch

Bug#1000532: sphinxcontrib-jsmath: please make the build reproducible

[Chris Lamb]

Source: sphinxcontrib-jsmath
Version: 1.0.1-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
sphinxcontrib-jsmath could not be built reproducibly.

This is because it uses the tag_date feature of Python eggs which gets
encoded into the binary package in a number of ways (eg. directory
names, etc.)

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible_build.patch   2021-11-24 08:08:45.984989045 
-0800
@@ -0,0 +1,14 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-11-24
+
+--- sphinxcontrib-jsmath-1.0.1.orig/setup.cfg
 sphinxcontrib-jsmath-1.0.1/setup.cfg
+@@ -1,6 +1,6 @@
+ [egg_info]
+ tag_build = .dev
+-tag_date = true
++tag_date = false
+ 
+ [aliases]
+ release = egg_info -Db ''
--- a/debian/patches/series 2021-11-24 08:03:57.056819762 -0800
--- b/debian/patches/series 2021-11-24 08:08:45.256988641 -0800
@@ -1 +1,2 @@
 fix_test_warnings.patch
+reproducible_build.patch

Bug#1000533: sphinxcontrib-htmlhelp: please make the build reproducible

[Chris Lamb]

Source: sphinxcontrib-htmlhelp
Version: 2.0.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
sphinxcontrib-htmlhelp could not be built reproducibly.

This is because it uses the tag_date feature of Python eggs which gets
encoded into the binary package in a number of ways (eg. directory
names, etc.)

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible_build.patch   2021-11-24 08:09:50.781024706 
-0800
@@ -0,0 +1,14 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-11-24
+
+--- sphinxcontrib-htmlhelp-2.0.0.orig/setup.cfg
 sphinxcontrib-htmlhelp-2.0.0/setup.cfg
+@@ -1,6 +1,6 @@
+ [egg_info]
+ tag_build = .dev
+-tag_date = true
++tag_date = false
+ 
+ [aliases]
+ release = egg_info -Db ''
--- a/debian/patches/series 1969-12-31 16:00:00.0 -0800
--- b/debian/patches/series 2021-11-24 08:09:50.065024317 -0800
@@ -0,0 +1 @@
+reproducible_build.patch

Bug#1000531: sphinxcontrib-applehelp: please make the build reproducible

[Chris Lamb]

Source: sphinxcontrib-applehelp
Version: 1.0.2-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
sphinxcontrib-applehelp could not be built reproducibly.

This is because it uses the tag_date feature of Python eggs which gets
encoded into the binary package in a number of ways (eg. directory
names, etc.)

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible_build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible_build.patch   2021-11-24 08:09:06.445000382 
-0800
@@ -0,0 +1,14 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2021-11-24
+
+--- sphinxcontrib-applehelp-1.0.2.orig/setup.cfg
 sphinxcontrib-applehelp-1.0.2/setup.cfg
+@@ -1,6 +1,6 @@
+ [egg_info]
+ tag_build = .dev
+-tag_date = true
++tag_date = false
+ 
+ [aliases]
+ release = egg_info -Db ''
--- a/debian/patches/series 1969-12-31 16:00:00.0 -0800
--- b/debian/patches/series 2021-11-24 08:09:05.80125 -0800
@@ -0,0 +1 @@
+reproducible_build.patch

Bug#1000530: dnsutils: dig don't accept questions about wildcard records

[Jörgen Hägg]

Package: dnsutils
Version: 1:9.17.20-2
Severity: normal
X-Debbugs-Cc: j...@axis.com




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

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

Versions of packages dnsutils depends on:
ii  bind9-dnsutils  1:9.17.20-2

dnsutils recommends no packages.

dnsutils suggests no packages.

-- no debconf information

--
(domain obfuscated)

"dig  '*.xxx.yyy.example.com' any" returns this:

dig: '*.xxx.yyy.example.com' is not a legal name (empty label)

I get the same answer no matter what domain I test, be there
a real wildcard record or not.

Version 1:9.17.19-3 seems to work.
This is an example from version 1:9.11.5.P4+dfsg-5.1+deb10u6:

*.xxx.yyy.example.com.  10800   IN  CNAME   xxx.yyy.example.com.

--
dig '*.example.com' any

Older:
;*.example.com. IN  ANY

Current:
dig: '*.example.com' is not a legal name (empty label)

Bug#999906:

[w_t...@t-online.de]

Hi Thomas,
 
thank you very much for taking care of my stuporous report.
But for my excuse, it is my first one ever.
 
I tested at first the live CD of Debian 10. K3B also disrespects
the speed setting. But the process seems to adjust the speed
automatically. 18x was starting speed and it was reduced, so that
the resulting speed was 4x. I initially set K3B to 8x. The burning
was also a success and the DVD is usable.
 
After that, I tried xorrecord under Debian 11, as I did before.
Unfortunately, I am not able to reproduce the error again with xorrecord.
 
The command I used is as follows:
xorrecord dev=/dev/dvd -nopad speed=8d -eject 
/home/daten/DeVeDe/Kongresse/2021/KK_Habt-Glauben/02_NM.iso
 
The result was a success:
  xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.
  Drive current: -outdev '/dev/dvd'
  Media current: DVD-R sequential recording
  Media status : is blank
  Media summary: 0 sessions, 0 data blocks, 0 data, 4489m free
  Beginning to write data track.
  libburn : NOTE : WRITE command repetition happened 6 times
  Writing to '/dev/dvd' completed successfully.
  xorriso : NOTE : Re-assessing -outdev '/dev/dvd' ('/dev/sr0')
  xorriso : NOTE : Disc status unsuitable for writing
  Drive current: -outdev '/dev/dvd'
  Media current: DVD-R sequential recording
  Media status : is written , is closed
  Media summary: 1 session, 1543856 data blocks, 3015m data, 0 free
 
K3B under Debian 11 still behaves as before.
Setting speed is totally ignored, the burner makes noise like a starting 
jet,
and finishes with error and overall speed of 18,4x.
 
Maybe I have had a different problem with xorriso before. I tested it only 
once,
because I was annoyed by all the testing with K3B, XFBURN etc.
 
So with your information I think libburn, is not the issue.
 
Thanks a lot for your help and have a nice day!
Werner
 
 
 
 
 
Hi,

i am the developer of libburn, which serves underneath xfburn and xorriso.
(No need to Cc: me, as i have now subscribed to this bug.)

--

Quite obviously this report is attributed to the wrong package.
But it is not obvious which one would actually be the right one.

The overall Debian system and the Linux kernel have not much stake
in speed setting of DVD burners or burn success. To blame would rather
be the backends, growisofs under K3B and libburn under the others.
growisofs did not change in a decade. The jump from libburn-1.5.0 in
Debian 10 to libburn-1.5.2 in Debian 11 isn't much suspicious either.
Other distros use it since more than a year earlier.

Please show your xorriso command line and the messages which you get at
the end of the run. (No need to show the many progress messages prefixed
by UPDATE. Everything else might be of interest. Most the very start and
the very end of the run.)

If you can afford experiments with rebooting, then it would be interesting
to see whether you get better results from a Debian 10 Live ISO.
E.g. pick your favorite desktop version from:
 

put it onto a USB stick:
 
and after booting install xorriso like
  sudo apt-get update
  sudo apt-get install xorriso

(Disclaimer: I did not test whether the 10.11.0 ISOs have apt-get.)


Have a nice day :)

Thomas


Bug#791814: Info received (sasl2-bin: fails to start saslauthd)

[Nigel Horne]

I changed the MECHANISMS from pam to getpwent and now saslauthd starts and
stays running. So that's an improvement.  However it still doesn't send email
from my phone which claims "no password provided for $address" which is a lie
and since it's sasl that changed not my phone, I continue to suspect the
sasl2 update broke sendmail.

Bug#1000351: fish: latest release breaks compat with mc

[Andrej Shadura]

Control: tag -1 patch

Apparently there’s a patch in the upstream repo:

https://github.com/MidnightCommander/mc/commit/e819ed742118dd4b9fc7d37e82830118df366ca4

--
Cheers,
  Andrej

Bug#1000529: Enable the apport build option when building on Ubuntu

[Sebastien Bacher]

Package: shotwell
Version: 0.30.14-1
Severity: minor

Dear maintainers,

Could you merge the attached patch to build with apport when on Ubuntu? 
It should have no impact on Debian. The patch is stacked on the one from


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000528

Thanks for considering,
Sebastien Bacher



diff -Nru shotwell-0.30.14/debian/changelog shotwell-0.30.14/debian/changelog
--- shotwell-0.30.14/debian/changelog	2021-11-24 16:11:17.0 +0100
+++ shotwell-0.30.14/debian/changelog	2021-11-24 16:11:17.0 +0100
@@ -3,6 +3,8 @@
   * debian/control, debian/rules:
 - Build with and enable the libunity option, it's a small library and
   also providing integration in the GNOME dash-to-dock
+  * debian/rules:
+- enable the apport option on Ubuntu
 
  -- Sebastien Bacher   Wed, 24 Nov 2021 16:11:17 +0100
 
diff -Nru shotwell-0.30.14/debian/rules shotwell-0.30.14/debian/rules
--- shotwell-0.30.14/debian/rules	2021-11-24 16:08:56.0 +0100
+++ shotwell-0.30.14/debian/rules	2021-11-24 16:11:17.0 +0100
@@ -7,9 +7,14 @@
 %:
 	dh $@  --buildsystem=meson --with gnome
 
+#Enable the apport option when building of Ubuntu 
+ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
+APPORT = -Dinstall-apport-hook=true
+endif
+
 override_dh_auto_configure:
 	dh_auto_configure -- \
-	-Dunity-support=true
+	-Dunity-support=true $(APPORT)
 
 override_dh_gnome_clean:
 	dh_gnome_clean --no-control

Bug#1000004: pcre-ocaml: depends on obsolete pcre3 library

[Stéphane Glondu]

tags 104 + help
thanks

Hello,

Le 18/11/2021 à 12:49, Matthew Vernon a écrit :
> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
> upstream do not intend to fix any further bugs in it. Accordingly, I
> would like to remove the pcre3 libraries from Debian, preferably in
> time for the release of Bookworm.
> 
> The newer PCRE2 library was first released in 2015, and has been in
> Debian since stretch. Upstream's documentation for PCRE2 is available
> here: https://pcre.org/current/doc/html/
> 
> Many large projects that use PCRE have made the switch now (e.g. git,
> php); it does involve some work, but we are now at the stage where
> PCRE3 should not be used, particularly if it might ever be exposed to
> untrusted input.

I had a look, and the new API looks very different. Is there a porting
guide somewhere?

Besides, I'm not sure it makes sense to port pcre-ocaml to pcre2 while
keeping the same OCaml API, which mimics the PCRE one. Moreover,
pcre-ocaml is widely used and has many reverse dependencies in Debian:

  approx
  ben
  caml-crush
  cduce
  coccinelle
  eliom
  galax
  liquidsoap
  mikmatch
  nurpawiki
  oasis
  ocaml-benchmark
  ocaml-cpu
  ocaml-duppy
  ocaml-expect
  ocaml-http
  ocaml-inifiles
  ocaml-lastfm
  ocaml-parany
  ocamldap
  ocamlmod
  ocamlnet
  ocamlrss
  ocsigenserver
  pxp
  xmlrpc-light

One solution could be to port these to another library (ocaml-re comes
to mind)... but this will take time, more than the Bookworm release
cycle I think.

I'm still unsure on which strategy to adopt.


Cheers,

-- 
Stéphane

Bug#791814: sasl2-bin: fails to start saslauthd

[Nigel Horne]

Package: sasl2-bin
Version: 2.1.27+dfsg2-2
Followup-For: Bug #791814

Dear Maintainer,

Everthing was fine until today an update to sasl2-bin came in, and now I can't 
send e-mail from my phone using
my SMTP server.

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

   * What led up to the situation?
I ran "apt upgrade" which updated sasl2-bin
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Tried to send an e-mail
   * What was the outcome of this action?

"ps ax | grep sasl" gives no output. Running "systemctl" shows it's not even 
trying to start the daemon.

My phone now says that I've entered the wrong username/password.  I haven't, 
and anyway I haven't changed it.
   * What outcome did you expect instead?
For my e-mails to still be able to be sent.

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


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

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

Versions of packages sasl2-bin depends on:
ii  db-util5.3.1+nmu1
ii  debconf [debconf-2.0]  1.5.79
ii  init-system-helpers1.60
ii  libc6  2.32-4
ii  libcrypt1  1:4.4.26-1
ii  libdb5.3   5.3.28+dfsg1-0.8
ii  libkrb5-3  1.18.3-7
ii  libldap-2.4-2  2.4.59+dfsg-1
ii  libpam0g   1.4.0-10
ii  libsasl2-2 2.1.27+dfsg2-2
ii  libssl1.1  1.1.1l-1
ii  lsb-base   11.1.0
ii  perl   5.32.1-6

sasl2-bin recommends no packages.

sasl2-bin suggests no packages.

-- Configuration Files:
/etc/default/saslauthd changed:
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="pam"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/run/saslauthd"


-- debconf information:
  cyrus-sasl2/upgrade-sasldb2-backup-failed:
  cyrus-sasl2/upgrade-sasldb2-failed:
  cyrus-sasl2/backup-sasldb2: /var/backups/sasldb2.bak
  cyrus-sasl2/purge-sasldb2: false

Bug#1000403: linux-image-5.15.0-1-amd64: Bluetooth no longer works with linux 5.15 on an Intel AX201 laptop

[Yuri D'Elia]

On Wed, Nov 24 2021, Salvatore Bonaccorso wrote:
> On Wed, Nov 24, 2021 at 03:36:27PM +0100, Yuri D'Elia wrote:
>> Package: src:linux
>> Version: 5.15.3-1
>> Followup-For: Bug #1000403
>>
>> I'd like to report the same, still holding true on the current package
>> with a dell 7410 with the AX201.
>>
>> The 5.16-rc1 has the same problem.
>
> Thanks for confirming. Would you be possible to bisect the issue to
> the introdcing and report it upstream (not checked if there were
> already reports about it) and then keep us in the loop?

I've found this similar report so far which sounds plausible and
includes a patch:

https://bugzilla.kernel.org/show_bug.cgi?id=213829

however I didn't have time to investigate/rebuild at the moment.
I reverted back to 5.14.

Bug#1000403: linux-image-5.15.0-1-amd64: Bluetooth no longer works with linux 5.15 on an Intel AX201 laptop

[Salvatore Bonaccorso]

Hi Yuri,

On Wed, Nov 24, 2021 at 03:36:27PM +0100, Yuri D'Elia wrote:
> Package: src:linux
> Version: 5.15.3-1
> Followup-For: Bug #1000403
> 
> I'd like to report the same, still holding true on the current package
> with a dell 7410 with the AX201.
> 
> The 5.16-rc1 has the same problem.

Thanks for confirming. Would you be possible to bisect the issue to
the introdcing and report it upstream (not checked if there were
already reports about it) and then keep us in the loop?

Regards,
Salvatore

Bug#1000528: Could you build with libunity?

[Sebastien Bacher]

Package: shotwell
Version: 0.30.14-1
Severity: minor

Dear maintainers,

Shotwell provides an option to build with libunity. The naming of the 
library is a bit misleading but it's not specific to the Unity desktop, 
it also adds integration to the GNOME dash to dock for example 
(displaying an indicator on the launcher icon during import). The 
library is used in Debian already for other components like evolution, 
it would be nice to enable it in shotwell as well. The library is small 
and doesn't have extra depends.


Thanks for considering,
Sebastien Bacher

Bug#1000403: linux-image-5.15.0-1-amd64: Bluetooth no longer works with linux 5.15 on an Intel AX201 laptop

[Yuri D'Elia]

Package: src:linux
Version: 5.15.3-1
Followup-For: Bug #1000403

I'd like to report the same, still holding true on the current package
with a dell 7410 with the AX201.

The 5.16-rc1 has the same problem.

Bug#998057: Bioc-transition has started (Was: Re: Bug#998057: transition: r-api-bioc-3.14)

[Nilesh Patra]

On Tue, Nov 23, 2021 at 08:07:49PM +0100, Sebastian Ramacher wrote:
> Please go ahead.

Thanks a lot.

@All,

me and Andreas have kick started the transition. Right now, we are at dependency
level 2.
Should you have free cycles, do not hesitate to chime in.
Here is the tracker for $more info[1]

[1]: https://release.debian.org/transitions/html/r-api-bioc-3.14.html

Regards,
Nilesh


signature.asc
Description: PGP signature

Bug#1000527: wireplumber: Desktop audio capture not working after upgrading to 0.4.5

[Anthony Fok]

Package: wireplumber
Version: 0.4.5-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: f...@debian.org

After upgrading wireplumber from 0.4.4-1 to 0.4.5-1, "Desktop Audio"
captured from OBS Studio became abnormal, either getting
intermittent bursts of audio (from desktop?) intermingled with silence,
or getting audio identical to microphone input.

Once I downgrade to 0.4.4-1 and run "systemctl --user restart wireplumber",
OBS "Desktop Audio" capture becomes normal again.  So, for about a week
now, I have been using the older wireplumber 0.4.4 as a workaround.

I searched about this issue on the Internet and didn't find other
people complaining about 0.4.5 specifically.

Eventually, I opened up pavucontrol, opened the Recording tab,
and began to see what the problem is.  With OBS Studio running,
capturing both "Desktop Audio" and "Mic/Aux", I see the difference
between WirePlumber 0.4.4 and 0.4.5:

 * WirePlumber 0.4.4 (normal behaviour):

   + OBS: Desktop Audio  from Monitor of Built-in Audio Analog Stereo
   + OBS: Mic/Auxfrom Built-in Audio Analog Stereo

 * WirePlumber 0.4.5 (wrong behaviour):

   + OBS: Desktop Audio  from Built-in Audio Analog Stereo
   + OBS: Mic/Auxfrom Built-in Audio Analog Stereo

With WirePlumber 0.4.5, manually changing "Built-in Audio Analog Stereo"
to "Monitor of Built-in Audio Analog Stereo" allows me to properly
capture Desktop Audio again.

Problem is, after I restart OBS Studio, pavucontrol then shows both
Desktop Audio and Mic/Aux capturing from "Monitor of Built-in Audio
Analog Stereo", and I have to manually fix "OBS: Mic/Aux" in pavucontrol
to use "Built-in Audio Analog Stereo".  But then upon the next restart of
OBS Studio, "OBS: Desktop Audio" is capturing my microphone again.

It seems that WirePlumber 0.4.5 somehow got the different input sources
tangled?  No such problem at all with WirePlumber 0.4.4 or with
pipewire-media-session.

Thanks in advance!

Cheers,
Anthony

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

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

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.60
ii  libc6 2.32-4
ii  libglib2.0-0  2.70.1-1
ii  libpipewire-0.3-0 0.3.40-1
ii  libwireplumber-0.4-0  0.4.5-1
ii  pipewire  0.3.40-1

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.40-1

wireplumber suggests no packages.

-- no debconf information

Bug#810926: dcmtk-www: missing file name extension of /etc/apache2/conf-available/dcmtk

[Mathieu Malaterre]

Control: fixed -1 3.6.1~20150924-1

See:

dcmtk (3.6.1~20150924-1) unstable; urgency=medium
[...]
  * Remove dcmtk-www, because it is no longer provided by upstream

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Vincent Lefevre]

On 2021-11-24 15:16:12 +0100, Vincent Lefevre wrote:
> On 2021-11-23 17:55:54 +0100, Guillem Jover wrote:
> > Nice cleanup with the odbc packaging! Unfortunately the new
> > transitional package looks a bit broken. It contains a dangling
> > symlink:
> > 
> >   $ ls -la /usr/lib/x86_64-linux-gnu/libodbccr.so.1
> >   ls: cannot access '/usr/lib/x86_64-linux-gnu/libodbccr.so.1': No such 
> > file or directory
> > 
> > Which whould point to libodbccr.so.2. But then the package is also
> > missing a dependency on libodbccr2.
> 
> I'm wondering. Why was the soname incremented? This should normally
> not be done unless the ABI is backward-incompatible. But in such a
> case, providing a symlink is wrong and could break applications that
> expect the old ABI.

This actually also applies to the stable/testing version 2.3.6-0.1+b1,
which provides:

lrwxrwxrwx 1 14 2019-07-21 19:09:45 
/usr/lib/x86_64-linux-gnu/libodbccr.so.1 -> libodbccr.so.2
lrwxrwxrwx 1 18 2019-07-21 19:09:45 
/usr/lib/x86_64-linux-gnu/libodbccr.so.2 -> libodbccr.so.2.0.0
-rw-r--r-- 1  47016 2019-07-21 19:09:45 
/usr/lib/x86_64-linux-gnu/libodbccr.so.2.0.0
lrwxrwxrwx 1 12 2019-07-21 19:09:45 /usr/lib/x86_64-linux-gnu/libodbc.so.1 
-> libodbc.so.2
lrwxrwxrwx 1 16 2019-07-21 19:09:45 /usr/lib/x86_64-linux-gnu/libodbc.so.2 
-> libodbc.so.2.0.0
-rw-r--r-- 1 447408 2019-07-21 19:09:45 
/usr/lib/x86_64-linux-gnu/libodbc.so.2.0.0

If the potentially buggy *.so.1 library versions are no longer used,
the corresponding symlinks could simply be dropped, and the package
split is not needed.

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

Bug#1000503: nbd FTBFS: configure.ac:371: error: required file 'man/nbd-client.8.sh.in' not found

[Wouter Verhelst]

Version: 1:3.23-3

On Wed, Nov 24, 2021 at 01:20:21PM +0200, Adrian Bunk wrote:
> Source: nbd
> Version: 1:3.23-2
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/logs.php?pkg=nbd=1%3A3.23-2
> 
> 
> configure.ac:371: error: required file 'man/nbd-client.8.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-server.5.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-server.1.sh.in' not found
> configure.ac:371: error: required file 'man/nbd-trdump.1.sh.in' not found
> configure.ac:371: error: required file 'man/nbdtab.5.sh.in' not found
> autoreconf: error: automake failed with exit status: 1
> dh_autoreconf: error: autoreconf -f -i returned exit code 1
> 

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

Bug#1000526: RFS: ghostwriter/2.1.0-2 -- Distraction-free, themeable Markdown editor

[Sebastien CHAVAUX]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : ghostwriter
Version : 2.1.0-2
Upstream Author : wereturtle 
* URL : https://wereturtle.github.io/ghostwriter/
* License : GPL-3.0, ISC, Expat, GPL-3.0+, CC-BY-SA-4.0
* Vcs : https://salsa.debian.org/seb95-guest/ghostwriter
Section : editors

It builds those binary packages:

ghostwriter - Distraction-free, themeable Markdown editor

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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/g/ghostwriter/ghostwriter_2.1.0-2.dsc


Changes since the last upload:

ghostwriter (2.1.0-2) unstable; urgency=medium
.
* debian/control: list of architectures changed

Regards,

Bug#995189: RFH: isc-dhcp

[Santiago Ruano Rincón]

El 07/11/21 a las 13:54, Martin-Éric Racine escribió:
> Howdy!

Hi!

> 
> ma 27. syysk. 2021 klo 21.44 Santiago Ruano Rincón
> (santiag...@riseup.net) kirjoitti:
> > El 27/09/21 a las 20:25, Martin-Éric Racine escribió:
> > > Package: wnpp
> > > Severity: normal
> > > X-Debbugs-Cc: debian-de...@lists.debian.org
> > > Control: affects -1 src:isc-dhcp
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA256
> > >
> > > The ISC DHCP suite has a lenghty list of bug reports that have been left 
> > > unattended. Some bugs date back to DHCP 3 or even earlier.
> > >
> > > Additionally, recent upstream releases are still unpackaged. One release 
> > > came out well ahead of the Bullseye freeze, a bug report requesting its 
> > > packaging was filed, but it remains unanswered.
> > >
> > > Leaving a package with a priority Important in such utter state of 
> > > neglect is unacceptable.
> > >
> > > At this point, it has become clear that, at the very least, its 
> > > maintainers need help, hence why I filed this WNPP bug.
> >
> > Indeed. I am willing to spend some cycles to help maintaining it. I
> > requested access to the ISC DHCP packaging team in salsa ~a couple of
> > weeks ago, but I hasn't been answered yet (mgilbert is its only member).
> > It was on my ToDo list to ping the maintainers (in CC).
> 
> Has any progress taken place on this?
> 
> Martin-Éric

I've started doing some work at https://salsa.debian.org/santiago/isc-dhcp/

I still didn't get any answer from current maintainers (keeping them in
CC), so I plan to retitle this bug as an ITS bug soon. Hopefully no
later than next Friday.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1000525: python-autopage: Unit test suite enabled for package build

[James Page]

Package: python-autopage
Version: Unit test suite enabled for package build
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * Enable unit testing as part of package build:
- d/rules: Enable test suite execution.
- d/control: Add missing BD on python3-fixtures.

Thanks for considering the patch.


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

Kernel: Linux 5.13.0-20-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-autopage-0.4.0/debian/control 
python-autopage-0.4.0/debian/control
--- python-autopage-0.4.0/debian/control2021-09-29 11:25:29.0 
+0100
+++ python-autopage-0.4.0/debian/control2021-11-24 14:10:26.0 
+
@@ -9,6 +9,7 @@
  dh-python,
  openstack-pkg-tools,
  python3-all,
+ python3-fixtures,
  python3-setuptools,
 Standards-Version: 4.6.0
 Vcs-Browser: https://salsa.debian.org/openstack-team/python/python-autopage
diff -Nru python-autopage-0.4.0/debian/rules python-autopage-0.4.0/debian/rules
--- python-autopage-0.4.0/debian/rules  2021-09-29 11:25:29.0 +0100
+++ python-autopage-0.4.0/debian/rules  2021-11-24 13:58:54.0 +
@@ -18,16 +18,9 @@
pkgos-dh_auto_install --no-py2 --in-tmp
 
 
+override_dh_auto_test:
 ifeq (,$(findstring nocheck, $(DEB_BUILD_OPTIONS)))
-   echo "No tests for now..."
-#  set -e ; for pyvers in $(PYTHON3S); do \
-#  python$$pyvers setup.py test ; \
-#  done
+   set -e ; for pyvers in $(PYTHON3S); do \
+   python$$pyvers setup.py test ; \
+   done
 endif
-
-
-override_dh_auto_test:
-   echo "Do nothing..."
-
-
-

Bug#1000465: libodbc1: Missing dependency and dangling symlink

[Vincent Lefevre]

On 2021-11-23 17:55:54 +0100, Guillem Jover wrote:
> Nice cleanup with the odbc packaging! Unfortunately the new
> transitional package looks a bit broken. It contains a dangling
> symlink:
> 
>   $ ls -la /usr/lib/x86_64-linux-gnu/libodbccr.so.1
>   ls: cannot access '/usr/lib/x86_64-linux-gnu/libodbccr.so.1': No such file 
> or directory
> 
> Which whould point to libodbccr.so.2. But then the package is also
> missing a dependency on libodbccr2.

I'm wondering. Why was the soname incremented? This should normally
not be done unless the ABI is backward-incompatible. But in such a
case, providing a symlink is wrong and could break applications that
expect the old ABI.

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

Bug#1000524: php-defaults in experimental should force PHP 8.1

[David Prévot]

Source: php-defaults
Version: 89
Severity: normal

Hi Ondřej,

php-defaults in experimental doesn’t break php-common-7.4, making it
pretty useless.

Regards

David


signature.asc
Description: PGP signature

Bug#1000498: segfaults in libst-1.0.so with "vertical overview" plugin enabled

[Detlev Zundel]

Hi Simon,

thanks for the quick reply!

> On Wed, 24 Nov 2021 at 10:50:29 +0100, Detlev Zundel wrote:
>> Having installed the "vertical overview" package, I experience segfaults in
>> gnome-shell killing the whole session.  I do think the addon is related as 
>> log
>> messages precede the segfaults.
>
> Is this reproducible if you disable the extension?

The crashes are not that frequent - sometimes it takes multiple days
before another crash so I only started seeing this relation while
collecting the data for the bug report.  But now that I think of it, I
did not experience segfaults before enabling the addon.  So I am pretty
sure but not 100%...

> Did you get this extension from Debian or from extensions.gnome.org?

I installed it from extensions.gnome.org and just checked that I do not
see it packaged for Debian bookworm.

> If an extension is causing a crash, there is usually not much that
> gnome-shell can do about it. Extensions work by "monkey-patching"
> the gnome-shell code, and have just as much control over execution as
> gnome-shell does.
>
>> Nov 17 17:42:40 krikkit gnome-shell[2918]: ../../../gobject/gsignal.c:2732:
>> instance '0x55db198ddf00' has no handler with id '10990'
>
> This suggests that something (presumably the vertical overview extension)
> is not keeping track of its signal handler IDs correctly.
>
>> Nov 17 17:42:40 krikkit kernel: gnome-shell[2918]: segfault at 55de45d1f627 
>> ip
>> 7f39f4900b29 sp 7ffd73fdd360 error 4 in
>> libst-1.0.so[7f39f48de000+4b000]
>
> Can you get a backtrace from this crash? systemd-coredump is usually the
> easiest way to achieve this. See: https://wiki.debian.org/HowToGetABacktrace

I installed systemd-coredump and will report after the next occurrence.

Thanks
  Detlev

Bug#998565: Errors due to changes in iso-codes data

[Scott Kitterman]

On November 24, 2021 1:54:48 PM UTC, Stuart Prescott  wrote:
>On Wednesday, 24 November 2021 18:05:57 AEDT Stuart Prescott wrote:
>> I've looked at them and fixed most of the tests locally without issues. I
>> guess I should push that somewhere so that it is visible. I'll start a
>> draft PR with upstream for it.
>
>Now done: https://github.com/flyingcircusio/pycountry/pull/86 
>
>My preference would be to upload a new upstream version of iso-codes with 
>these improvements included, giving review and acceptance that these changes 
>are appropriate. If I can't do that in a timely fashion then backporting that 
>PR is possible.

Thanks.  Now that I look at it, that solution to the flags issue in the tests 
seems obvious and appropriate.  It didn't occur to me when I was looking at the 
problem.

Scott K

Bug#999363: Shouldn't replace pulseaudio by pipewire by default

[Dylan Aïssi]

Hi,

For follow up, I first proposed this change:

> https://salsa.debian.org/utopia-team/wireplumber/-/merge_requests/7

but that involves users to manually edit conf files to get pipewire as
sound server.
That was not a suitable solution. Instead, I am reverting the order
change of wireplumber and pipewire-media-session in pipewire:

> https://salsa.debian.org/utopia-team/pipewire/-/commit/bf12b0177

at least until we decide to switch to pipewire as default sound server.

Best,
Dylan

Bug#998565: Errors due to changes in iso-codes data

[Stuart Prescott]

On Wednesday, 24 November 2021 18:05:57 AEDT Stuart Prescott wrote:
> I've looked at them and fixed most of the tests locally without issues. I
> guess I should push that somewhere so that it is visible. I'll start a
> draft PR with upstream for it.

Now done: https://github.com/flyingcircusio/pycountry/pull/86 

My preference would be to upload a new upstream version of iso-codes with 
these improvements included, giving review and acceptance that these changes 
are appropriate. If I can't do that in a timely fashion then backporting that 
PR is possible.

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1000522: ITP: libobject-pad-slotattr-final-perl -- declare Object::Pad slots readonly after construction

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Debian Perl Group 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libobject-pad-slotattr-final-perl
  Version : 0.04
  Upstream Author : Paul Evans 
* URL : https://metacpan.org/release/Object-Pad-SlotAttr-Final
* License : Artistic or GPL-1+
  Programming Lang: Perl, C
  Description : declare Object::Pad slots readonly after construction

 Object::Pad::SlotAttr::Final provides
 a third-party slot attribute for Object::Pad-based classes,
 which declares that the slot it is attached to
 shall be set as readonly when the constructor returns,
 disallowing further modification to it.

This package will be team-maintained at
https://salsa.debian.org/perl-team/modules/packages/libobject-pad-slotattr-final-perl

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGeQi8ACgkQLHwxRsGg
ASGkFBAAq2nWTvJEI41BH98hWM/hizGfhiZO9SuWkjpF19X0zRTglPPtA1zYmfsn
64kf97aPaIHQX8H2iN0TmBg6+K4dp1537V6Qrhr8v0XpoGOqD1DyRD2iJmtMsYDK
t7jdLntCIYlgSodMbAWu18xN7bCuWUABfkMnn8PDz0u6bHpcZdK86cU679K17U7q
V0C/h8QGv8v/Oa2oQqCo68+35Vxe2dU6y3Etbv73iaz5pDatc+LgbXX/SIXQcCN8
LnXoy0IAg9bOUbBy56iCCVBq9WDdoIguxiyIfXdMzyg4DID2DW474ke3zIFe+DUg
rksXVG1Pdm2YAW7zAKKNMS8m2bOGHuduK3DTrqUFfE9YQz87+ReTIWWsHltZqs3F
H88AN4nbGE8lI1jFgzeUNXNjhQtL8PflMf/2SViPEysL8aaxyOny1XfrU0UNJQ0w
45lUvZI7rb1XjCoNR2bRiIn8tkuwW6X/I1zD7Eh65U3MExx5KvpqtzOPH+WG8Urv
X1beKzqOnP03KhVIJ2Q8abVmiwTOGEyeYBpWs0mXtYlc3ZAXZtoxiV28hhab8x/h
+M3musD1FzksEs/oJ38x2+7bxDvQkgbhY0GFw+vn2DRoRSiJmyKeOJ6lZ1vhIFWU
wIochb8Wwf34oAcaxrrMXGi7KsggtlGBl35AYm57afe1ou2FTxM=
=+pla
-END PGP SIGNATURE-