Bug#1025140: diffutils: define SIGSEGV_FAULT_STACKPOINTER for loongarch

[zhangdandan]

Package: diffutils
Version: 3.8-1
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear diffutils maintainers,

    I have defined SIGSEGV_FAULT_STACKPOINTER for loongarch.
    Please consider the patch attached.


thanks,
Dandan Zhang

diff --git a/lib/sigsegv.c b/lib/sigsegv.c
index 998c827..6d9287e 100644
--- a/lib/sigsegv.c
+++ b/lib/sigsegv.c
@@ -168,6 +168,18 @@ int libsigsegv_version = LIBSIGSEGV_VERSION;
because $bsp and $bspstore never differ by more than ca. 1 KB.  */
 #  define SIGSEGV_FAULT_BSP_POINTER  ((ucontext_t *) ucp)->uc_mcontext.sc_ar_bsp
 
+# elif defined __loongarch__ || defined __loongarch64
+
+/* See glibc/sysdeps/unix/sysv/linux/loongarch/sys/ucontext.h
+   and the definition of GET_STACK in
+   glibc/sysdeps/unix/sysv/linux/loongarch/sigcontextinfo.h.
+   Note that the 'mcontext_t' defined in
+   glibc/sysdeps/unix/sysv/linux/loongarch/sys/ucontext.h
+   and the 'struct sigcontext' defined in 
+   are effectively the same.  */
+
+#  define SIGSEGV_FAULT_STACKPOINTER  ((ucontext_t *) ucp)->uc_mcontext.__gregs[LARCH_REG_SP]
+
 # elif defined __m68k__
 
 /* See glibc/sysdeps/unix/sysv/linux/m68k/sys/ucontext.h

Bug#1025139: RM: libthread-pool [armel armhf i386 mipsel hppa hurd-i386 m68k powerpc sh4 x32] -- ROM; Does not build on 32 bit architectures any more

[Andreas Tille]

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

Hi,

libthread-pool is not supported for 32 bit architectures any more.
Please remove the package for the said architectures.

Kind regards and thanks a lot for your work as ftpmaster
   Andreas.

Bug#1025058: LLVM_DEFINITIONS is a string and not a list

[Mathieu Malaterre]

Control: forwarded -1
https://reviews.llvm.org/rGd2612ef1c411aba65d7d6e4889261ecec2de52ae

LLVM_DEFINITIONS is a string and not a list

A user may be tempted to just do:

target_compile_definitions(foo PRIVATE ${LLVM_DEFINITIONS})

which would fails. The ${LLVM_DEFINITIONS} expands to a single
argument since the value of the variable is not ;-separated. The
result is that CMake thinks user is trying to specify a single
definition whose name is the entire string value minus a leading -D.

Bug#1008796: miniupnpd: compile miniupnpd also with IGD v1 only

[Mobeets]

On Mon, 2 May 2022 11:40:54 +0800 Yangfl  wrote:
> This does not help a lot. Please, consider filling at least the
> following information:
> * The hardware type and software version of the clients;
> * Network captures of IGD1 and IGD2 miniupnpds;
> * miniupnpd log, if any.
>
>
Hello,

I believe these Github issues have the information necessary to address 
this problem:


https://github.com/miniupnp/miniupnp/issues/539
https://github.com/openwrt/packages/pull/14656

Older versions of miniupnpd do not catch the Microsoft browser 
user-agent to format the rootDesc.xml and WANIPCn.xml properly. Using 
the "force_igd_desc_v1=yes" configuration option on the Debian version 
does not work properly as it does not omit the XML that is incompatible 
with Microsoft's IGD service.



*What led up to the situation?
Using an open source router software named "VyOS" that depends on this 
package for UPnP. NAT/UPnP was type "strict" on all the services tested 
(Playstation Network, Xbox Live, Microsoft Gaming Hub). UPnP tester 
programs reported also reported no ability to manipulate UPnP through 
"WANIPConnection".


* What action was performed that was effective in addressing the problem?
Grabbed the source of the miniupnpd-2.2.1 package from the Debian 
repository and re-compiled with default configure options which do NOT 
enable IGDv2.


* What was the outcome of this action?
NAT/UPnP type changed to "open" which is the intended outcome, UPnP 
testers reporting "WANIPConnection".

Bug#1025138: mariadb-server-10.5: editing config files has no apparent effect on bind-address

[Ross Boylan]

Package: mariadb-server-10.5
Version: 1:10.5.15-0+deb11u1
Severity: normal
X-Debbugs-Cc: rossboy...@stanfordalumni.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This is actually a pretty severe impact on usability for me, since I can't
contact the server from other machines.  Since I think I followed the
instructions in README.Debian,
this is probably a documentation issue  at a minimum.

** BACKGROUND
mariadb was working fine on a single machine, mostly working for mythtv.
I wanted to access the database from other machines on my local network.

Both the upstream documents and the NETWORKING section of the server
README.Debian indicate bind-address is the key directive I want to use,
replacing the default 127.0.0.1 to listen on.  I have 2 NICs and only want it
to listen on 1, and so do not want to use 0.0.0.0.

** STEPS TO REPRODUCE
1. Shut down clients, i.e., mythtv-backend, accessing the database.
2. Shut down database.
3. Edit /etc/mysql/mariadb.cnf (the README.Debian says mysql.cnf, but that's a
symlink to mariadb.cnf) by uncommenting `port = 3306` and inserting
`bind_address = 192.168.1.10` in the `[client-server]` section.
4. Restart the mariadb server.

** OBSERVED RESULT
netstat and log messages all confirm that maria continues to listen on
127.0.0.1 and no other IP addresses.

** EXPECTED RESULT
maria listening on 192.168.10.1.
I'm a little fuzzy on whether it will also listen on 127.0.0.1 in this case; I
think the documents indicate it won't.  I could live with either, but would
prefer if it continued to listen on the loopback.

** ATTEMPTED SOLUTIONS
I tried variation in the exact syntax of the bind_address specification, with a
restart each time.

Consulted documentation and other internet resources, some of which I reference
in the next section.

I noticed the bind_address of 127.0.0.1 currently seems to be set in
/etc/mysql/mariadb.conf.d/50-server.cnf, and so I tried changing it there and
commenting out my other changes.  Since the whole thing was in a [mysqld]
section it was unclear to me if any of it applies to my installation.

None of the changes made a difference, except for the error message for some
syntaxes.

** POSSIBLE EXPLANATIONS

1. The bind_address must be specified on the command line when the program is
invoked.  This wouldn't be too surprising, but I don't think the documentation
says this (https://mariadb.com/kb/en/server-system-variables/ indicates it can
be provided on the command line and is not dynamic).

2. The bind_address is being specified on the command line when the program is
invoked, and this overrides settings in the configuration files.

3. The "command line" is actually systemd for me.  Its invocations include
$MYSQLD_OPTS.  I can't tell if anything is setting that, or where it would be
set.  /etc/default/ has neither a maria nor a mysql file; some of the startup
scripts attempt to include them if they are present.

4. Some other systemd limitations are in play.  For example, perhaps I need to
explicitly declare a dependence on the necessary IP address or device.
https://mariadb.com/kb/en/configuring-mariadb-for-remote-client-access/ does
not mention this as a necessary step.  The discussion in
https://mariadb.com/kb/en/systemd/#systemd-socket-activation also makes it
sound as if this is optional.

5. debconf options are controlling the binding in some way not visible to me
inspecting the startup code.

6. systemd restart, or systemd stop and start in a short time, both of which I
think I tried, is not sufficient to do a real reset and leaves the old
configuration in play, regardless of what I changed on the disk.  But if that
were true I would have had no error variation when I varied the syntax, and I
did have such variation.  I'm pretty sure I have observed this with some other
services, maybe isc-dhcp-server.

The mythtv database user does have permission to access the database from
outside the local machine, though my problems seem to be occurring at an
earlier step.




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

Kernel: Linux 5.10.0-19-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 not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-10.5 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.77
ii  galera-4  26.4.11-0+deb11u1
ii  gawk  1:5.1.0-1
ii  iproute2  5.10.0-4
ii  libc6 2.31-13+deb11u5
ii  libdbi-perl   1.643-3+b1
ii  libpam0g  1.4.0-9+deb11u1
ii  

Bug#1025137: bullseye-pu: package g810-led/0.4.2-1

[Stephen Kitt]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

g810-led has a security issue in stable; it leaves /dev/input/eventXX
device nodes world-readable and writable (CVE-2022-46338). The issue
is marked no-dsa, but I would like to provide a fix in the next
point-release. The fix is already in unstable (0.4.2-3).

The attached debdiff fixes the issue by patching the udev rules file:
the affected device nodes have their mode set to 660 instead of 666,
and uaccess is used to provide access to the user at the console. I
own relevant hardware and have verified the fix myself on a multi-user
system.

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

Regards,

Stephen
diff -Nru g810-led-0.4.2/debian/changelog g810-led-0.4.2/debian/changelog
--- g810-led-0.4.2/debian/changelog 2020-05-23 20:33:29.0 +0200
+++ g810-led-0.4.2/debian/changelog 2022-11-30 08:24:25.0 +0100
@@ -1,3 +1,11 @@
+g810-led (0.4.2-1+deb11u1) bullseye; urgency=medium
+
+  * Control device access with uaccess instead of making everything
+world-writable. Thanks to Xavi Drudis Ferran for the report!
+Closes:#1024998. (CVE-2022-46338.)
+
+ -- Stephen Kitt   Wed, 30 Nov 2022 08:24:25 +0100
+
 g810-led (0.4.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru g810-led-0.4.2/debian/patches/device-permissions.patch 
g810-led-0.4.2/debian/patches/device-permissions.patch
--- g810-led-0.4.2/debian/patches/device-permissions.patch  1970-01-01 
01:00:00.0 +0100
+++ g810-led-0.4.2/debian/patches/device-permissions.patch  2022-11-30 
08:23:44.0 +0100
@@ -0,0 +1,74 @@
+commit e2b486fd1bc21e0b784e1b4c959770772dfced24
+Author: Stephen Kitt 
+Date:   Mon Nov 28 21:05:05 2022 +0100
+
+Rely on uaccess to control device access
+
+The udev rules currently make supported device nodes world-readable
+and writable, which means that any process on the system can read
+traffic from keyboards including passwords etc. To avoid this, while
+still allowing the "controlling" user to run g810-led without being
+root, this patch adds a uaccess tag; this ensures that the user at the
+console has write access to the devices. The mode is also changed to
+660 to ensure that existing device nodes are fixed on upgrade.
+
+Thanks to Xavi Drudis Ferran for bringing this to my attention.
+
+Fixes: #293
+Signed-off-by: Stephen Kitt 
+
+diff --git a/udev/g810-led.rules b/udev/g810-led.rules
+index 90b743b..ea05726 100644
+--- a/udev/g810-led.rules
 b/udev/g810-led.rules
+@@ -1,25 +1,25 @@
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c336", MODE="666" RUN+="/usr/bin/g213-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c330", MODE="666" RUN+="/usr/bin/g410-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c33a", MODE="666" RUN+="/usr/bin/g413-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c342", MODE="666" RUN+="/usr/bin/g512-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c33c", MODE="666" RUN+="/usr/bin/g513-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c333", MODE="666" RUN+="/usr/bin/g610-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c338", MODE="666" RUN+="/usr/bin/g610-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c331", MODE="666" RUN+="/usr/bin/g810-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c337", MODE="666" RUN+="/usr/bin/g810-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c33f", MODE="666" RUN+="/usr/bin/g815-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c32b", MODE="666" RUN+="/usr/bin/g910-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c335", MODE="666" RUN+="/usr/bin/g910-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c339", MODE="666" RUN+="/usr/bin/gpro-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", 
ATTRS{idProduct}=="c336", MODE="666" RUN+="/usr/bin/g213-led -p 
/etc/g810-led/profile"
+-ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="046d", 

Bug#1024890: ntcard - build-dependencies unsatisfiable on 32-bit.

[Andreas Tille]

Hi Peter,

Am Sun, Nov 27, 2022 at 02:30:15PM + schrieb Peter Michael Green:
> Package: ntcard
> Version: 1.2.2+dfsg-4
> Severity: serious
> 
> ntcard build-depends on libnthash-dev which is no longer available on 32-bit
> architectures.
> 
> There are in general 3 potential soloutions for this (in roughly descending
> order of preference)
> 
> 1. Fix your build-dependencies so they are once again available on all
> release architectures.
> 2. Eliminate the build-dependencies in question, either generally or on
> those specific architectures.

Both it not possible.

> 3. Declare your package unsupported on 32-bit architectures and file a
> removal bug with the ftpmasters.

For what architecture should we file a removal bug?  The package was
never released on 32 bit architectures so I see no point in bothering
ftpmaster.

> I do not know which are pratical in the case of your particular package.

As far as I know its a frequently used method to add Build-Depends that
are not available for a certain architecture to prevent autobuilders
from building those packages under these architectures.  If I would
explicitly restrict the architectures of nthash it would need manual
intervention if libbtllib-dev might become available also for 32 bit
(which is probably not the case - but at least in theory this is the
reason to *not* provide a list of supported architectures).

Could you please give any reason which backs up your choice "serious"
for this bug report?  IMHO the package is perfectly OK and the bug
should be closed.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1024998: g810-led: Security risk: Leaves /dev/input/event* with read and write permissions for all users

[Stephen Kitt]

On Wed, 30 Nov 2022 06:59:41 +0100, Salvatore Bonaccorso 
wrote:
> The issue got CVE-2022-46338 assigned by MITRE.
> 
> Stephen, the issue is marked no-dsa for bullseye, but a fix might go
> still trough the upcoming point release (scheduled for 17th december).

Thanks, I’ll submit a stable update.

Regards,

Stephen


pgpsjkR9gwwEH.pgp
Description: OpenPGP digital signature

Bug#1023020: cmark-gfm: FTBFS on s390x

[Keith Packard]

Scott Talbert  writes:

> @Keith, do you have time to upload this patch?  Unfortunately, this is 
> blocking a large number of packages from migrating to testing. 
> Alternatively, any objections to an NMU?

I didn't get to this today, and might not until thursday or
friday. Happy for your to NMU if you like. 

-- 
-keith


signature.asc
Description: PGP signature

Bug#1025136: cryptsetup: crypttab(5) encrypted swap example causes warnings

[Owen T. Heisler]

Package: cryptsetup
Version: 2:2.3.7-1+deb11u1
Severity: minor
X-Debbugs-Cc: wri...@owenh.net

Hello,

The crypttab(5) man page has an example labeled "Encrypted swap device"
that should be updated so it does not print warnings.


## Summary

The example should be updated to this (add "plain", remove "hash=sha1"):

cswap /dev/sda6 /dev/urandom plain,cipher=aes-xts-plain64,size=256,swap

Instead of this:

cswap /dev/sda6 /dev/urandom cipher=aes-xts-plain64,size=256,hash=sha1,swap


## Justification

Otherwise, cryptsetup prints these warnings:

```
# cryptdisks_start cswap
Starting crypto disk...
cryptsetup: WARNING: cswap: couldn't determine device type, assuming default 
(plain).
cswap (starting)...
WARNING: The --hash parameter is being ignored in plain mode with keyfile 
specified.
cswap (started)...done.
```


Thank you for your work on cryptsetup.

Owen

Bug#1025080: It is on raspberry pi 4

[Pierre Couderc]

Certainly, you are right Ross.

In fact the error could be limited to rasp os. I did omit this important 
point in my report !


I did solve the problem by installing dbus-x11. So now dbus is started.

I cannot retrieve the exact words but the message was about :

Enlightenment does not start because dbus is not started.

I start it  when the error existed and now too, by filling .xinitrc and 
manual startx after manual login.

Bug#1024821: q2templates: FTBFS/autopkgtest fail with pandas 1.5

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/qiime2/q2templates/issues/50

Hi Rebecca,

thanks again for working on pandas.  Since I consider it not sensible to
delay the pandas transition due to this bug I could imagine to exclude
(or better fix ourselves if possible) that test if we do not get a
timely response from upstream.

Thanks again for all your work
   Andreas.

-- 
http://fam-tille.de

Bug#1025135: libcoap2: Do not ship in bookworm

[Carsten Schoenert]

Source: libcoap2
Version: 4.2.1-1
Severity: serious

The API version 2 of libcoap was given up long ago and is replaced by API
v3. The last version for v2 was released on 2019.
Thus no upstream development and no updates will happen for this
package and we should not ship libcoap2 packages in bookworm onward.

There is a replacement avaialable - users should switch to libcoap3.

https://tracker.debian.org/pkg/libcoap3

Regards
Carsten

Bug#1025049: asymptote: Error in shipout3

[picca]

Le 2022-11-29 23:46, Hilmar Preuße a écrit :

Am 29.11.2022 um 10:02 teilte Picca Frédéric-Emmanuel mit:


Hello,

I imagine that the zzz1.asy file is my B_b3_y.asy, right ?

if so, something must be different between your environment and mine.

I use the latest unstable with gostscript 10

and you ?

Is it possible to have a more informative debug message than this one ?


 shipout3(prefix,f,preview ? nativeformat() : format,
 ^


thanks for your help.

Frederic

Bug#1024920: libgpg-error: support the noudeb build profile

[Andreas Metzler]

Control: tags -1 pending

On 2022-11-27 Helmut Grohne  wrote:
> Source: libgpg-error
[...]
> libgpg-error builds a udeb package. It would be nice to be able to opt
> out of building it via the noudeb build profile. I'm attaching a patch
> for your convenience.

Commited to GIT. (Trivial change in salsa "debian" namespace.)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


signature.asc
Description: PGP signature

Bug#1024820: emperor: FTBFS/autopkgtest fail with pandas 1.5

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/biocore/emperor/issues/810

Hi Rebecca,

thanks a lot for working on the pandas migration.  I think, if we
do not get a timely response from upstream and do not have any
idea to fix this single test failure ourselves, we could exclude
this test for the moment and set the bug severity to important.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1025129: elpi: Please add support for "riscv64" arch

[julien . puydt]

Hi,

Le mercredi 30 novembre 2022 à 00:30 +0100, Manuel A. Fernandez
Montecelo a écrit :
> Source: elpi
> Version: 1.16.7-2
> Severity: wishlist
> Tags: ftbfs patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org
> 
> Hi,
> 
> Please enable this architecture, with the patch attached or an
> equivalent.
> 
> I built it locally on hardware, it built fine just by enabling the
> architecture
> in debian/control, and increasing the timeout.
> 
> I only tried with doubling the current timeot, maybe it can do with
> significantly less time, but 600 from longer_timeout.patch is already
> much
> higher than the original 90.  But if you want I can try and try to
> get a more
> accurate limit.
> 
> 
> Thanks and cheers.

I'm going to apply your changes (I already checked them on a porterbox
and committed to salsa) ; but since there's an ongoing big transition,
I'll wait until that has passed.

There's also a new elpi upstream version I'll want to package, so I
expect in a week or so I'll be able to ask for a transition to the
release team and your change will go in.

Thanks for your help,

J.Puydt

Bug#1024998: g810-led: Security risk: Leaves /dev/input/event* with read and write permissions for all users

[Salvatore Bonaccorso]

Control: retitle -1 g810-led: Security risk: Leaves /dev/input/event* with read 
and write permissions for all users (CVE-2022-46338)

On Mon, Nov 28, 2022 at 03:45:16PM +0100, Xavi Drudis Ferran wrote:
> Package: g810-led
> Version: 0.4.2-2.1
> Severity: critical
> Tags: patch upstream security
> Justification: root security hole
> X-Debbugs-Cc: xdru...@tinet.cat, Debian Security Team 
> 
> 
> Dear Maintainer,
> 
> I hesitate to file as critical, but I came across a bug report in
> upstream that looked serious enough since it would allow all local
> processes to eavesdrop on keyboard input, including passwords, etc. I
> haven't tried an exploit, but it seemed better to just restrict
> /dev/input/event* permissions to those of other event dev files.
> 
> Without this patch, I can read /dev/input/event2 and /dev/input/event3 as a
> normal user. I see bytes in /dev/input/event2 when typing as a normal
> user and also typing in another terminal (Konsole) typing as
> root. event3 only shows the characters typed by the normal user.
> 
> With the patch I can't read /dev/input/event* as a normal user.
> 
> And the bug is publically reported upstream (some 10 days ago).
> 
>* What led up to the situation?
> 
> Reviewing upstream bugs, found https://github.com/MatMoul/g810-led/issues/293
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Nothing really. I wrote the patch, rebuilt, and observed the
> permissions were fixed. My keyboard seems to work both with and
> without the patch (needs a kernel with CONFIG_HIDRAW), when calling
> g810-led as root. As normal user it doesn't work (both with or without
> patch), due to no permission for /dev/hidraw2.
> 
> It should really be fixed upstream, but maybe it's worth fixing meanwhile
> or removing the package temporarily ?

The issue got CVE-2022-46338 assigned by MITRE.

Stephen, the issue is marked no-dsa for bullseye, but a fix might go
still trough the upcoming point release (scheduled for 17th december).

Regards,
Salvatore

Bug#1023954: WX assertion failure within the raw importer

[Andreas Metzler]

On 2022-11-13 Michael Deegan  wrote:
> Package: hugin
> Version: 2021.0.0+dfsg-3
> Severity: normal

> The raw file importer triggers an assertion after selecting the raw importer
> (dcraw, in my case) to use:

> ASSERT INFO:
> ./src/common/sizer.cpp(2267): assert "CheckSizerFlags(!((flags) & 
> (wxALIGN_RIGHT)))" failed in DoInsert(): wxALIGN_RIGHT will be ignored in 
> this sizer: only vertical alignment flags can be used in horizontal sizers
[...]

Hello Michael,

do you still see this with 2022.0~beta1+dfsg-1?

TIA, cu Andreas

Bug#1025134: ITP: golang-github-mdlayher-ethtool -- Go library to control the Linux ethtool generic netlink interface

[Daniel Swarbrick]

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

* Package name: golang-github-mdlayher-ethtool
  Version : 0.0~git20220830.0e16326-1
  Upstream Author : Matt Layher 
* URL : https://github.com/mdlayher/ethtool
* License : Expat
  Programming Lang: Go
  Description : Go library to control the Linux ethtool generic netlink 
interface

Go library to control the Linux ethtool generic netlink interface. For more
information, see https://docs.kernel.org/networking/ethtool-netlink.html

This package is a required build-dependency of prometheus-node-exporter >=
1.5.0.

I will co-maintain this package as a member of the Debian Go Packaging
Team.

Bug#982140: ITP: fuzzel -- Wayland-native application launcher

[Peter Colberg]

On Mon, Nov 28, 2022 at 12:21:13PM -0500, Antoine Beaupré wrote:
> So this is now in unstable, but blocked from migrating because it was a
> binary upload.
> 
> I'm happy to do a new source-only upload, but are there other changes
> you have pending we could bundle up in there?

Thanks, yes, I have pushed fuzzel 1.8.2-2 [1] which resolves a FTBFS
due to a recent change in the fcft Debian package. There had already
been a failed attempt [2] to rebuild on amd64. (Are these automatic
after a new package enters the archive, or manually triggered?)

[1] 
https://salsa.debian.org/swaywm-team/fuzzel/-/commit/c4885f626cdfb9ce2ca26afa46fdcce76f309b1c
[2] 
https://buildd.debian.org/status/fetch.php?pkg=fuzzel=amd64=1.8.2-1%2Bb1=1669472282=0

Thanks,
Peter

Bug#1002956: New debdiff

[Alex Vandiver]

On Sat, 06 Aug 2022 19:09:05 +0100 "Adam D. Barratt"
 wrote:
> +  * Stop moving mv /etc/rabbitmq/rabbitmq.conf 
> /etc/rabbitmq/rabbitmq-env.conf.
>
> This could do with an explanation as to _why_ this move should not be
> happening.

I believe this is https://bugs.debian.org/943699

> +   if ! [ -e /var/lib/rabbitmq/.erlang.cookie ] ; then
> +   OLD_UMASK=$(umask)
> +   umask 077; openssl rand -base64 -out 
> /var/lib/rabbitmq/.erlang.cookie 42
> +   umask ${OLD_UMASK}
> +   else
> +   # This matches an Erlang generated cookie file: 20 upper case 
> chars
> +   if grep -q -E '^[A-Z]{20}$' /var/lib/rabbitmq/.erlang.cookie 
> ; then
> +   OLD_UMASK=$(umask)
> +   umask 077; openssl rand -base64 -out 
> /var/lib/rabbitmq/.erlang.cookie 42
> +   umask ${OLD_UMASK}
> +   if [ ""$(ps --no-headers -o comm 1) = "systemd" ] ; 
> then
> +   if systemctl is-active --quiet 
> rabbitmq-server.service ; then
> +   systemctl restart 
> rabbitmq-server.service
> [...]
> +Since 3.9.8-3, the rabbitmq-server node will use openssl to generate a
> +cryptographically-secure cookie during first installation, mitigating
> +this vulnerability.
> +
> +Servers which installed a prior version, and are upgrading to 3.9.8-3
> +or higher, ARE STILL VULNERABLE, as the package will not regenerate
> +the secret if it exists already.  This is because the secret is
> +designed to be shared between nodes in a cluster, and thus
> +regenerating it would break existing clusters.
>
> This seems to be inaccurate. The latter block quoted above specifically
> *does* regenerate an existing secret if it deems it to be not "good
> enough", so far as I can tell?

The README.debian changes are out of date with the code, yes.  The
warnings in README.debian, I believe, date from when that
documentation was a compromise solution, rather than fixing existing
weak magic cookies.  Since the code now does address those, the README
should be updated accordingly.  The changelog might also merit a
warning that this may break clustered installs which share a weak
magic cookie, similar to the note in the initial mail of
https://bugs.debian.org/1004513

 - Alex

Bug#1024496: qiskit-terra: FTBFS with Python 3.11 as a supported version

[Bo YU]

Source: qiskit-terra
Followup-For: Bug #1024496

It seems like upstream has fixed the issue:

https://github.com/Qiskit/qiskit-terra/commit/75d66dd8ba34627addc4914eafa38775fc74ca92

But from #1008625, upgrading it maybe need more dependencies, this will
cost more time.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008625


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1025133: cdebconf: task selection is ignored with d-i in speech synthesis mode

[Arnaud Rebillout]

Package: cdebconf
Version: 0.265
Severity: normal
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: sthiba...@debian.org

Dear Maintainer,

Short story: task selection is ignored in speech synthesis mode. This is
due to a regression in the cdebconf text frontend. The issue is easily
fixed, and I propose the following patch:
https://salsa.debian.org/installer-team/cdebconf/-/merge_requests/18

Longer story: the issue is easy to reproduce, just fire the debian
installer (daily build), select speech synthesis install, and when comes
the time to select the tasks, select something that is not the default.
For example, I select '1 4 10 11 12', and then pretty much nothing gets
installed. After reboot, there is just a console. `dpkg -l | wc -l`
tells me that 256 packages are installed. No desktop environment.

It's possible to see the issue with `DEBCONF_DEBUG=.` on the kernel
cmdline. The offending part of the syslog:

  Nov 30 00:36:23 debconf: --> GET tasksel/first
  Nov 30 00:36:23 debconf: <-- 0
  Nov 30 00:36:23 in-target: debconf (developer): < (passthrough) 0
  Nov 30 00:36:23 in-target: debconf (developer): Got "" for tasksel/first

The second line shouldn't be empty.

I CC Samuel, as he reworked the text frontend lately, it will be
straightforward for him to review and ack my patch (or fix it
differently, at your preference Samuel).

The issue was originally reported against Kali Linux:


Thanks!

Arnaud

Bug#1025132: firmware-linux: Missing firmware for Intel AX201

[TeoCol]

Package: firmware-linux
Version: 20221109-2
Severity: normal
X-Debbugs-Cc: teodoro777.coluc...@live.com

Dear Maintainer,

After performing a clean install of debian testing, installing the proprietary
firmware, everything works fine, except bluetooth.
This is caused by lack of firmware to handle the device.
Indeed dmesg reports:
"[ 5.655154] Bluetooth: hci0: Failed to load Intel firmware file
intel/ibt-0040-4150.sfi (-2)"
As far as I've found, the drivers are present upstream:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-
firmware.git/tree/intel.
Hope this can help.

Regards
Teo




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

Kernel: Linux 6.0.0-4-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 firmware-linux depends on:
ii  firmware-linux-free 20200122-1
ii  firmware-linux-nonfree  20221109-2

Versions of packages firmware-linux recommends:
ii  amd64-microcode  3.20220411.1
ii  intel-microcode  3.20220809.1

firmware-linux suggests no packages.

-- no debconf information

Bug#1025131: apt-cacher-cleanup does not work

[Robert Luberda]

Package: apt-cacher
Version: 1.7.27
Severity: important

The "Encode embedded underscores in URLs when building filenames"
change introduced in 1.7.27 broke apt-cacher-cleanup.pl: it does 
not clean *.deb files at all, as stored file names such as
 adduser%5f3.127%5fall.deb
 adduser%5f3.128%5fall.deb
 adduser%5f3.129%5fall.deb
do no longer match to the $package_files_regexp.

Regards
robert



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

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

Versions of packages apt-cacher depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  distro-info-data   0.56
ii  ed 1.18-1
ii  init-system-helpers1.64
ii  libdpkg-perl   1.21.9
ii  libfilesys-df-perl 0.92-7+b1
ii  libio-interactive-perl 1.023-2
ii  libio-interface-perl   1.09-2+b2
ii  libipc-sharelite-perl  0.17-4+b7
ii  libnetaddr-ip-perl 4.079+dfsg-2+b1
ii  libsys-syscall-perl0.25-7
ii  libwww-curl-perl   4.17-8+b1
ii  libwww-perl6.67-1
ii  lsb-base   11.5
ii  perl   5.36.0-4
ii  sysvinit-utils [lsb-base]  3.05-6
ii  update-inetd   4.51

Versions of packages apt-cacher recommends:
ii  libberkeleydb-perl0.64-2+b1
ii  libio-compress-lzma-perl  2.201-1

Versions of packages apt-cacher suggests:
pn  libfreezethaw-perl   
ii  libio-socket-inet6-perl  2.73-1

-- Configuration Files:
/etc/apt-cacher/apache.conf changed [not included]
/etc/apt-cacher/apt-cacher.conf changed [not included]
/etc/cron.d/apt-cacher changed [not included]

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/share/apt-cacher/apt-cacher-cleanup.pl (from 
apt-cacher package)
debsums: changed file /usr/share/apt-cacher/lib/apt-cacher.pl (from apt-cacher 
package)

Bug#1023020: cmark-gfm: FTBFS on s390x

[Scott Talbert]

On Tue, 29 Nov 2022, Chris Hofstaedtler wrote:


* Sebastian Ramacher  [221129 11:21]:

Source: cmark-gfm
Version: 0.29.0.gfm.6-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=cmark-gfm=s390x=0.29.0.gfm.6-2=1666810004=0

--- expected HTML
+++ actual HTML
@@ -7,15 +7,15 @@
 mailto:scyt...@pokemon.com;>scyt...@pokemon.com/mailto:beedr...@pokemon.com;>beedr...@pokemon.com
 mailto:scyt...@pokemon.com;>mailto:scyt...@pokemon.com
 This is a mailto:scyt...@pokemon.com;>mailto:scyt...@pokemon.com
-mailto:scyt...@pokemon.com;>mailto:scyt...@pokemon.com.
+mailto:mailto:scyt...@pokemon.com;>scyt...@pokemon.com.


This is caused by an out-of-bounds read on a memory buffer, which
seems to be masked by stack layout on little-endian archs(?).

PR for upstream is here:
https://github.com/github/cmark-gfm/pull/296/files

I've verified on zelenka.d.o this fixes the build failure.


Thanks for the fix, Chris!  I was trying to look into this myself earlier.

@Keith, do you have time to upload this patch?  Unfortunately, this is 
blocking a large number of packages from migrating to testing. 
Alternatively, any objections to an NMU?


Thanks,
Scott

Bug#1025130: linux: Apple macbook pro 2015 SD card reader not working

[Alexander Prokoshev]

Package: src:linux
Version: 5.10.149-2
Severity: normal
File: linux
Tags: upstream
X-Debbugs-Cc: alexander.prokos...@gmail.com

Dear Maintainer,

I installed Debian onto 13" MacBook Pro (2015)

There is no SD card reader visible in lsusb's or lspci's output.

I tried to restart the computer and turn it on and off with no visible result.

In MacOS on the same laptop, the reader just works.


-- Package-specific info:
** Version:
Linux version 5.10.0-19-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.149-2 (2022-10-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-19-amd64 
root=UUID=efa132a9-0db6-4a9d-8041-148aa972ff72 ro quiet

** Tainted: OE (12288)
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[5.487433] snd_hda_codec_cirrus hdaudioC1D0:dig-out=0x21/0x0
[5.487434] snd_hda_codec_cirrus hdaudioC1D0:inputs:
[5.487436] snd_hda_codec_cirrus hdaudioC1D0:  Internal Mic=0x1c
[5.487437] snd_hda_codec_cirrus hdaudioC1D0:  Mic=0x18
[5.523194] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1b.0/sound/card1/input14
[5.523241] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1b.0/sound/card1/input15
[5.523286] input: HDA Intel PCH SPDIF as 
/devices/pci:00/:00:1b.0/sound/card1/input16
[5.622306] facetimehd :02:00.0: ISP woke up after 0ms
[5.622313] facetimehd :02:00.0: Number of IPC channels: 7, queue size: 
44865
[5.623921] iTCO_vendor_support: vendor-support=0
[5.666971] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[5.667021] iTCO_wdt: unable to reset NO_REBOOT flag, device disabled by 
hardware/BIOS
[5.682200] facetimehd :02:00.0: Firmware requested heap size: 3072kb
[5.692150] facetimehd :02:00.0: ISP second int after 0ms
[5.692155] facetimehd :02:00.0: Channel description table at 0080
[5.702619] facetimehd :02:00.0: magic value:  after 0 ms
[5.702623] facetimehd :02:00.0: Enabling interrupts
[5.702766] FWMSG: 
[5.702851] FWMSG: - APOLLO-ISP-APPLE 

[5.702869] FWMSG: 
[5.702895] FWMSG:   Restart count : 0
[5.702964] FWMSG:   Platform : mode = TARGET, ID = 0x, HW = 
00020018.
[5.703009] FWMSG:   System Clock : 2 Hz
[5.703040] FWMSG:   Processor mode : SUPERVISOR
[5.703076] FWMSG:   Cache architecture type : SEPARATE
[5.703104] FWMSG:   Cache type : WRITEBACK
[5.703136] FWMSG:   Data Cache Line : 32 [0x20]
[5.703164] FWMSG:   Boot arguments entries : 2
[5.703195] FWMSG: : 0x 0x
[5.703239] FWMSG:   Physical memory base : 0x [TLB base 0x0016]
[5.703274] FWMSG:   Main memory :   base : 0x
[5.703323] FWMSG:   size : 8388608 [0x0080] [8.0 MB]
[5.703370] FWMSG:   Extra heap :base : 0x2080b000 [phy = 0x0080b000]
[5.703416] FWMSG:   size : 3145728 [0x0030] [3.0 MB]
[5.703460] FWMSG:   Shared window : base : 0x0080 [static wiring]
[5.703509] FWMSG:   size : 125829120 [0x0780] [120.0 MB]
[5.703541] FWMSG:   Shared memory : base : 0x0080
[5.703591] FWMSG:   size : 260046848 [0x0f80] [248.0 MB]
[5.703645] FWMSG:   TEXT : 1421992 [0x15b2a8] - text 667256, cstring  
38749, const 715528
[5.703695] FWMSG:   DATA : 8076 [0x1f8c] - data 0, bss 460, common 1452, 
noinit 6144
[5.703733] FWMSG:   Heap free space : 10002626 [0x0098a0c2]
[5.703767] FWMSG:   Heap allocated space : 94656 [0x000171c0]
[5.703818] FWMSG:   Disclaimer : Copyright (c) APPLE Inc. All Rights 
Reserved.
[5.703854] FWMSG:   Application : adc [release]
[5.703889] FWMSG:   Linked on : Jul 25 2015 - 08:48:55
[5.703919] FWMSG:   Release : S2ISP-01.43.00
[5.703946] FWMSG:   H4ISPAPPLE : 11536
[5.703970] FWMSG:   H4ISPCD : 4081
[5.703993] FWMSG:   ffw : 4143
[5.704035] FWMSG:   Tool-chain : iPhone OS - 7.0.3 [clang/clang++]
[5.704051] FWMSG: 
[5.704110] FWMSG: 
---
[5.704129] FWMSG: 
[5.747833] audit: type=1400 audit(1669766380.623:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=535 
comm="apparmor_parser"
[5.749671] audit: type=1400 audit(1669766380.623:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=538 
comm="apparmor_parser"
[5.749677] audit: type=1400 audit(1669766380.623:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=538 
comm="apparmor_parser"
[5.749680] audit: type=1400 audit(1669766380.623:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" 

Bug#1025025: ImportError: cannot import name 'Application' from 'cleo'

[Emmanuel Arias]

Hi,

Thanks for the report.

I'm working in the new upstream release of poetry. As you mentioned this 
will be fixed.


Fyi, poetry-core and python-cleo are ready.

Cheers,

--
Emmanuel



OpenPGP_0xFA9DEC5DE11C63F1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023205: request to backport memtest86

[Matt Taggart]

Fabio Fantoni writes...

> I didn't think about that. I thought new upstream releases are only
> done for special packages which otherwise have no security support
> like Firefox or PHP
>
> But I'll do that now.

This bug is #1023205 but I note there has been no response so far.

I would like to be able to use the new 6.00-1 version in stable as the 
existing version there does not work on many systems, modern but also 
even those 5+ years old. I think there is a good argument for including 
in a stable update, but either way can we get a decision and have it 
available in stable proposed updates or backports soon?


Thanks,

--
Matt Taggart
m...@lackof.org

Bug#1025129: elpi: Please add support for "riscv64" arch

[Manuel A. Fernandez Montecelo]

Source: elpi
Version: 1.16.7-2
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org

Hi,

Please enable this architecture, with the patch attached or an equivalent.

I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, and increasing the timeout.

I only tried with doubling the current timeot, maybe it can do with
significantly less time, but 600 from longer_timeout.patch is already much
higher than the original 90.  But if you want I can try and try to get a more
accurate limit.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru elpi-1.16.7/debian/changelog elpi-1.16.7/debian/changelog
--- elpi-1.16.7/debian/changelog2022-10-26 09:11:53.0 +
+++ elpi-1.16.7/debian/changelog2022-11-29 17:27:58.0 +
@@ -1,3 +1,10 @@
+elpi (1.16.7-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo   Tue, 29 Nov 2022 17:27:58 
+
+
 elpi (1.16.7-2) unstable; urgency=medium
 
   * Limit the architectures where the package builds,
diff -Nru elpi-1.16.7/debian/control elpi-1.16.7/debian/control
--- elpi-1.16.7/debian/control  2022-10-26 09:11:53.0 +
+++ elpi-1.16.7/debian/control  2022-11-29 17:27:58.0 +
@@ -26,7 +26,7 @@
 Homepage: https://github.com/LPCIC/elpi
 
 Package: libelpi-ocaml
-Architecture: amd64 arm64 i386 ppc64el ppc64 sh4
+Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4
 Depends: ${misc:Depends}, ${ocaml:Depends}, ${shlibs:Depends}
 Provides: ${ocaml:Provides}
 Recommends: ocaml-findlib
@@ -38,7 +38,7 @@
  This package provides the runtime files.
 
 Package: libelpi-ocaml-dev
-Architecture: amd64 arm64 i386 ppc64el ppc64 sh4
+Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4
 Depends: ${misc:Depends}, ${ocaml:Depends}, ${shlibs:Depends}
 Provides: ${ocaml:Provides}
 Recommends: ocaml-findlib
@@ -50,7 +50,7 @@
  This package provides the dev files.
 
 Package: elpi
-Architecture: amd64 arm64 i386 ppc64el ppc64 sh4
+Architecture: amd64 arm64 i386 ppc64el ppc64 riscv64 sh4
 Depends: libelpi-ocaml (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
diff -Nru elpi-1.16.7/debian/patches/longer_timeout.patch 
elpi-1.16.7/debian/patches/longer_timeout.patch
--- elpi-1.16.7/debian/patches/longer_timeout.patch 2022-10-26 
09:11:53.0 +
+++ elpi-1.16.7/debian/patches/longer_timeout.patch 2022-11-29 
17:27:58.0 +
@@ -2,14 +2,16 @@
 Author: Julien Puydt
 Forwarded: Debian-specific
 
 elpi.orig/Makefile
-+++ elpi/Makefile
-@@ -24,7 +24,7 @@
+Index: elpi-1.16.7/Makefile
+===
+--- elpi-1.16.7.orig/Makefile
 elpi-1.16.7/Makefile
+@@ -24,7 +24,7 @@ help:
  INSTALL=_build/install/default
  BUILD=_build/default
  SHELL:=/usr/bin/env bash
 -TIMEOUT=90.0
-+TIMEOUT=600.0
++TIMEOUT=1200.0
  PWD=$(shell pwd)
  RUNNERS=\
dune \

Bug#1025099: plocate: autofs pruning doesn't seem to work

[Steinar H. Gunderson]

On Tue, Nov 29, 2022 at 03:04:01PM -0800, Ross Vandegrift wrote:
> Interesting - stat -f does the same, and it always returns nfs.  Here's
> a lame idea: /proc/mounts knows it's actually autofs...

Most of this logic is inherited from mlocate's updatedb, though not all.
It may be fixable or it may not; I'd really need to check. But it really
sounds like one should be able to stat() something without bad things
happening :-) I guess as a workaround, you can ask systemd to sandbox away
the mount for updatedb?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1025099: plocate: autofs pruning doesn't seem to work

[Ross Vandegrift]

On Tue, Nov 29, 2022 at 09:27:26PM +0100, Steinar H. Gunderson wrote:
> On Tue, Nov 29, 2022 at 11:31:39AM -0800, Ross Vandegrift wrote:
> >> Subject: Bug#1025099: plocate: autofs pruning doesn't seem to work
> > That subject wasn't too clear- updatedb.plocate does not index the
> > remote filesystem, it just triggeres the automount unnecessarily.
> 
> I don't think that's possible to avoid; the directory must be stat()-ed
> to get to know what type of filesystem it is, and I guess that would trigger
> the mount?

Interesting - stat -f does the same, and it always returns nfs.  Here's
a lame idea: /proc/mounts knows it's actually autofs...

But if there's no non-hacky way to filter out unmounted autofs mounts
early, I'm not sure this is worth fixing.  The only impact is delayed
updates when e.g. I'm not home and so the nfs won't mount.  Shortening
the mount timeout should help with that.

> I guess it's an interesting question why it even knows how to enter that
> directory, if it's not mounted; are you running with ghost on?

I'm using a systemd automount unit.  There's no autofs config or ghost
option, but the effect is similar:
  systemd-1 on /mnt/storage type autofs
  vanvanmojo.lan:/mnt/storage on /mnt/storage type nfs4

The first is created when the unit is started, the second after
automounting is triggered.

Ross

Bug#1025049: asymptote: Error in shipout3

[Hilmar Preuße]

Am 29.11.2022 um 10:02 teilte Picca Frédéric-Emmanuel mit:

Hi,

sorry I'm failing to reproduce the issue. For me that command line works:

hille@sid-amd64:~/devel/TeXLive$ asy -config "" -d -render=4 -f png -o
zzz1.png zzz1.asy
hille@sid-amd64:~/devel/TeXLive$ ls -l zzz1.*
-rw-r--r-- 1 hille hille   812 Nov 29 21:55 zzz1.asy
-rw-r--r-- 1 hille hille 16444 Nov 29 23:42 zzz1.eps
-rw-r--r-- 1 hille hille 16663 Nov 29 23:45 zzz1.png

H.


while working on the hkl package I found that asy doe snot compile anymore my 
files.

/usr/bin/asy -config "" -d -render=4 -f png -o 3S+1D.png 3S+1D.asy
 shipout3(prefix,f,preview ? nativeformat() : format,
 ^
/usr/share/asymptote/three.asy: 2896.13: runtime: /usr/bin/asy -config "" -d 
-render=4 -f png -o B_b3_y.png B_b3_y.asy
 shipout3(prefix,f,preview ? nativeformat() : format,
 ^
/usr/share/asymptote/three.asy: 2896.13: runtime: /usr/bin/asy -config "" -d 
-render=4 -f png -o B_a.png B_a.asy
 shipout3(prefix,f,preview ? nativeformat() : format,
 ^
/usr/share/asymptote/three.asy: 2896.13: runtime: /usr/bin/asy -config "" -d 
-render=4 -f png -o B_b.png B_b.asy
 shipout3(prefix,f,preview ? nativeformat() : format,
 ^



--
sigfault

Bug#1025056: transition: numerical library transition: hypre / petsc / slepc / sundials

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Drew

On 2022-11-29 12:16:55 +0100, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: Anton Gladky 
> 
> We'd like to update the numerical library stack in time for the new
> stable release.
> 
> Affected libraries are
> 
> hypre2.25.0 -> 2.26.0
> petsc/slepc3.17 -> 3.18
> sundials  5.8.0 -> 6.4.1
> 
> Autotransitions are already generated:
> https://release.debian.org/transitions/html/auto-hypre.html
> https://release.debian.org/transitions/html/auto-petsc.html   
> https://release.debian.org/transitions/html/auto-slepc.html
> https://release.debian.org/transitions/html/auto-sundials.html
> 
> Most of the dependent packages are under our control
> (Debian Science Team), octave is the main one outside our team.
> 
> Updates have built fine in experimental and dependent
> packages are building successfully against them.
> 
> Anton Gladky will upload the sundials update.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1025128: debhelper: dh_installinit, dh_installsystemd: Add ability to dynamically choose enable/start in postinst

[Richard Hansen]

Package: debhelper
Version: 13.11.1
Severity: wishlist

Currently the `--no-enable` and `--no-start` options can be passed to
`dh_installinit` and `dh_installsystemd` to control whether a daemon is enabled
or started during `postinst`.  For my use case, this is not flexible enough; I
want to be able to decide whether to enable/start the service after debconf has
collected answers from the user.

Details of my use case: I maintain ddclient, which can be used either as a
daemon or single shot via a hook (e.g., `/etc/ppp/ip-up.d/ddclient` or
`/etc/dhcp/dhclient-exit-hooks.d/ddclient`).  debconf asks the user how they
would like to run ddclient, and `postinst` enables the daemon depending on the
answer.  Because `dh_installinit` and `dh_installsystemd` currently require the
decision to be made at package build time, I have some ugly hacks in place to
make it work:

https://salsa.debian.org/debian/ddclient/-/blob/f701932aa76bbedc5d1765786eff9653b6d0e212/debian/postinst#L118-169
https://salsa.debian.org/debian/ddclient/-/blob/f701932aa76bbedc5d1765786eff9653b6d0e212/debian/prerm#L12-26
https://salsa.debian.org/debian/ddclient/-/blob/f701932aa76bbedc5d1765786eff9653b6d0e212/debian/control#L27-33
https://salsa.debian.org/debian/ddclient/-/blob/f701932aa76bbedc5d1765786eff9653b6d0e212/debian/ddclient.lintian-overrides

The need to maintain the hacks have resulted in minor bugs, for example:

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

If the decision to enable/start the service could be delayed to `postinst`, then
I could remove the hacks.

Possible solution:
  * Add an `--enable=func` option to `dh_installinit` and `dh_installsystemd`.
The code generated for the `#DEBHELPER#` magic comment in `postinst` would
then use the return value of `func` to control whether the service is
enabled.  `func` would default to `true` unless `--no-enable` was passed, in
which case it would default to `false`.
  * Similarly, add a `--start=func` option that controls whether the service is
started.
  * Add `--stop=func` for `prerm` that controls whether the service is stopped
when the package is removed.  (Even better: Unconditionally stop the service
when the package is removed even if `--no-start` is passed.)


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

Kernel: Linux 5.15.0-41-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND, 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: unable to detect

Versions of packages debhelper depends on:
ii  autotools-dev20220109.1
ii  dh-autoreconf20
ii  dh-strip-nondeterminism  1.13.0-1
ii  dpkg 1.21.9+b1
ii  dpkg-dev 1.21.9
ii  dwz  0.14+20220924-2
ii  file 1:5.41-4
ii  libdebhelper-perl13.11.1
ii  libdpkg-perl 1.21.9
ii  man-db   2.11.1-1
ii  perl 5.36.0-4
ii  po-debconf   1.0.21+nmu1

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202204

-- no debconf information


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020695: [Pkg-openssl-devel] Bug#1020695: failure to compute digest: md4 and rmd160

[Richard B. Kreckel]

IMO, this bug can be closed. There's been the decision by the OpenSSL 
Managment Board to reinstate RIPEMD160 (and only that) to the default 
providers in release 3.0.7.


The other algorithm, MD4 is unsafe and remains in the legacy provider.

References:
OMC decision: 


ChangeLog: 

  -richy.

Bug#1024425: python-pysam ftbfs with python3.11 reduced severity

[Étienne Mollier]

Control: severity -1 important

Hi,

I just uploaded python-pysam 0.20 with python3-dev support only
for the time being.  This can be raised later on when python3.11
becomes the default, or a last time when python3.10 is to be
dropped.

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


signature.asc
Description: PGP signature

Bug#1012063: cofoja: diff for NMU version 1.3-4.1

[Adrian Bunk]

Control: tags 1012063 + patch
Control: tags 1012063 + pending

Dear maintainer,

I've prepared an NMU for cofoja (versioned as 1.3-4.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru cofoja-1.3/debian/changelog cofoja-1.3/debian/changelog
--- cofoja-1.3/debian/changelog	2018-11-29 23:20:57.0 +0200
+++ cofoja-1.3/debian/changelog	2022-11-29 23:29:31.0 +0200
@@ -1,3 +1,10 @@
+cofoja (1.3-4.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Backport upstream fix for FTBFS with OpenJDK 17. (Closes: #1012063)
+
+ -- Adrian Bunk   Tue, 29 Nov 2022 23:29:31 +0200
+
 cofoja (1.3-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru cofoja-1.3/debian/patches/0001-java9-doesn-t-need-tools.jar.patch cofoja-1.3/debian/patches/0001-java9-doesn-t-need-tools.jar.patch
--- cofoja-1.3/debian/patches/0001-java9-doesn-t-need-tools.jar.patch	1970-01-01 02:00:00.0 +0200
+++ cofoja-1.3/debian/patches/0001-java9-doesn-t-need-tools.jar.patch	2022-11-29 23:29:31.0 +0200
@@ -0,0 +1,33 @@
+From a832cc817a3e5a3c3b5ac99b5cf5183f2c987ebb Mon Sep 17 00:00:00 2001
+From: "Chris West (Faux)" 
+Date: Wed, 23 Aug 2017 14:46:11 +0100
+Subject: java9 doesn't need tools.jar
+
+---
+ build.xml | 8 +++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/build.xml b/build.xml
+index 3410f53..e891a96 100644
+--- a/build.xml
 b/build.xml
+@@ -209,9 +209,15 @@
+ 
+   
+ 
+-  
++  
++
++  
++
++  
+ 
++  
+ 
++  
+ 
+ 
+Date: Thu, 24 Aug 2017 20:58:09 +0100
+Subject: Add configure message if tools.jar is not needed
+
+---
+ build.xml | 15 ++-
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/build.xml b/build.xml
+index e891a96..308fcec 100644
+--- a/build.xml
 b/build.xml
+@@ -30,6 +30,10 @@
+ 
+   
+ 
++  
++
++  
++
+   
+   
+   
+@@ -201,7 +205,12 @@
+ 
+   
+ 
+-
++
++  
++
++
++  
++
+ 
+   
+ 
+@@ -209,10 +218,6 @@
+ 
+   
+ 
+-  
+-
+-  
+-
+   
+ 
+   
+-- 
+2.30.2
+
diff -Nru cofoja-1.3/debian/patches/0003-Switch-to-if-unless-set-instead-of-true-for-conditio.patch cofoja-1.3/debian/patches/0003-Switch-to-if-unless-set-instead-of-true-for-conditio.patch
--- cofoja-1.3/debian/patches/0003-Switch-to-if-unless-set-instead-of-true-for-conditio.patch	1970-01-01 02:00:00.0 +0200
+++ cofoja-1.3/debian/patches/0003-Switch-to-if-unless-set-instead-of-true-for-conditio.patch	2022-11-29 23:29:31.0 +0200
@@ -0,0 +1,47 @@
+From fe6d2ac03741ed6722c13b8011b4ae323d05 Mon Sep 17 00:00:00 2001
+From: Nhat Minh Le 
+Date: Thu, 24 Aug 2017 21:49:41 +0100
+Subject: Switch to if/unless:set instead of :true for  variables
+
+---
+ build.xml | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/build.xml b/build.xml
+index 308fcec..f8f5593 100644
+--- a/build.xml
 b/build.xml
+@@ -205,10 +205,10 @@
+ 
+   
+ 
+-
++
+   
+ 
+-
++
+   
+ 
+ 
+@@ -316,7 +316,7 @@
+   
+   
+   
+-  
++  
+ 
+   
+ 
+@@ -334,7 +334,7 @@
+   
+ 
+   
+-  
++  
+ 
+   
+ 
+-- 
+2.30.2
+
diff -Nru cofoja-1.3/debian/patches/0004-Add-add-opens-for-masked-internal-com.sun.tools-APIs.patch cofoja-1.3/debian/patches/0004-Add-add-opens-for-masked-internal-com.sun.tools-APIs.patch
--- cofoja-1.3/debian/patches/0004-Add-add-opens-for-masked-internal-com.sun.tools-APIs.patch	1970-01-01 02:00:00.0 +0200
+++ cofoja-1.3/debian/patches/0004-Add-add-opens-for-masked-internal-com.sun.tools-APIs.patch	2022-11-29 23:29:31.0 +0200
@@ -0,0 +1,85 @@
+From b62618fa472e3f885622f51181256c540e8e8b86 Mon Sep 17 00:00:00 2001
+From: Nhat Minh Le 
+Date: Thu, 24 Aug 2017 21:51:07 +0100
+Subject: Add --add-opens for masked internal com.sun.tools APIs in Java 9
+
+---
+ build.xml  | 30 +++---
+ default.properties |  1 +
+ 2 files changed, 24 insertions(+), 7 deletions(-)
+
+diff --git a/build.xml b/build.xml
+index f8f5593..540c689 100644
+--- a/build.xml
 b/build.xml
+@@ -34,6 +34,15 @@
+ 
+   
+ 
++  
++
++  
++  
++
++  
++
++  
++
+   
+   
+   
+@@ -80,8 +89,14 @@
+   
+ 
+   
+-
++
+   
++  
++  
++  
++  
+ 
+   
+ 
+@@ -203,19 +218,20 @@
+ 
+ 
+ 
+-  
++  
+ 
+ 
+-  
++  
+ 
+ 
+-  
++  
++  
+ 
+ 
+-  
++  
+ 
+-
+-
++
++
+   
+ 
+   
+diff --git a/default.properties b/default.properties
+index ba01f4a..7d413d0 100644
+--- a/default.properties
 b/default.properties
+@@ -13,3 +13,4 @@ debug=true
+ 
+ ## Location of the JDK 'tools.jar' or 'classes.jar' (on Mac OS X).
+ tools.jar=${java.home}/../lib/tools.jar
++add-opens=true
+-- 
+2.30.2
+
diff -Nru 

Bug#1010345: ansible: python3-resolvelib >= 0.6.0 breaks Ansible

[Gregor Riepl]

Hi Lee,

can you still reproduce this bug? AFAICS this was fixed in the 2.13.3 
upload.


I couldn't find the original requirements.yml that produced the error, 
but I tested a similar file with Ansible 2.13.4, and it worked fine.


Additionally, I'll tighten the package dependencies so this issue will 
be more apparent in the future.


Thanks, I appreciate it! Hopefully there will be a more stable 
resolvelib soon that doesn't cause these problems any more.


By the way, what's the reason for the disparate versioning in Ansible 
and the ansible package? Why is Ansible 2.13.4 packaged as 6.4.0+dfsg-1?


Regards,
Gregor

Bug#1016359: ovmf: does not recognise SCSI controllers

[dann frazier]

On Tue, Nov 29, 2022 at 04:47:58PM +0100, Vincent Danjean wrote:
>   Hi,
> 
>   I can confirm that virtio-scsi does not work anymore
> (and that this is indeed really annoying).

It looks like upstream changed the default to disabled ahead of stable202208:

commit 57783adfb579da32b1eeda77b2bec028a5e0b7b3
Author: Michael D Kinney 
Date:   Tue Jul 26 12:40:00 2022 -0700

OvmfPkg: Change default to disable MptScsi and PvScsi

I suppose we could override that and turn them back on - but that
implies doing so without upstream support.

Bug#1025126: python-taskflow: (autopkgtest) needs update for python3.11: MismatchError

[Paul Gevers]

Source: python-taskflow
Version: 5.0.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-taskflow fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-taskflowfrom testing5.0.0-2
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

==
FAIL: 
taskflow.tests.unit.test_utils_iter_utils.IterUtilsTest.test_while_is_not

taskflow.tests.unit.test_utils_iter_utils.IterUtilsTest.test_while_is_not
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):
  File 
"/tmp/autopkgtest-lxc.96kwtgri/downtmp/build.Po9/src/taskflow/tests/unit/test_utils_iter_utils.py", 
line 144, in test_while_is_not

self.assertEqual(['a'],
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 
393, in assertEqual

self.assertThat(observed, matcher, message)
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 
480, in assertThat

raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = ['a']
actual= ['a',
 'b',
 'c',
 'd',
 'e',
 'f',
 'g',
 'h',
 'i',
 'j',
 'k',
 'l',
 'm',
 'n',
 'o',
 'p',
 'q',
 'r',
 's',
 't',
 'u',
 'v',
 'w',
 'x',
 'y',
 'z']


--
Ran 1719 tests in 50.317s

FAILED (failures=1, skipped=92)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025127: golang-github-prometheus-exporter-toolkit: CVE-2022-46146

[Salvatore Bonaccorso]

Source: golang-github-prometheus-exporter-toolkit
Version: 0.8.1-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for
golang-github-prometheus-exporter-toolkit.

CVE-2022-46146[0]:
| Prometheus Exporter Toolkit is a utility package to build exporters.
| Prior to versions 0.7.2 and 0.8.2, i someone has access to a
| Prometheus web.yml file and users' bcrypted passwords, they can bypass
| security by poisoning the built-in authentication cache. Versions
| 0.7.2 and 0.8.2 contain a fix for the issue. There is no workaround,
| but attacker must have access to the hashed password to use this
| functionality.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-46146
https://www.cve.org/CVERecord?id=CVE-2022-46146
[1] 
https://github.com/prometheus/exporter-toolkit/security/advisories/GHSA-7rg2-cxvp-9p7p

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1025125: ruby-sinatra: CVE-2022-45442: Reflected File Download attack

[Salvatore Bonaccorso]

Source: ruby-sinatra
Version: 2.2.2-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for ruby-sinatra.

CVE-2022-45442[0]:
| Sinatra is a domain-specific language for creating web applications in
| Ruby. An issue was discovered in Sinatra 2.0 before 2.2.3 and 3.0
| before 3.0.4. An application is vulnerable to a reflected file
| download (RFD) attack that sets the Content-Disposition header of a
| response when the filename is derived from user-supplied input.
| Version 2.2.3 and 3.0.4 contain patches for this issue.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-45442
https://www.cve.org/CVERecord?id=CVE-2022-45442
[1] https://github.com/sinatra/sinatra/security/advisories/GHSA-2x8x-jmrp-phxw
[2] 
https://github.com/sinatra/sinatra/commit/1808bcdf3424eab0c659ef2d0e85579aab977a1a
 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1025124: python-sushy: (autopkgtest) needs update for python3.11: AssertionError: expected call not found

[Paul Gevers]

Source: python-sushy
Version: 4.3.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-sushy fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-sushy   from testing4.3.0-2
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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


==
FAIL: 
sushy.tests.unit.test_connector.ConnectorOpTestCase.test_access_error_basic_auth

sushy.tests.unit.test_connector.ConnectorOpTestCase.test_access_error_basic_auth
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):

  File "/usr/lib/python3.11/unittest/mock.py", line 1369, in patched
return func(*newargs, **newkeywargs)
   ^
  File 
"/tmp/autopkgtest-lxc.71ai3cya/downtmp/build.UmE/src/sushy/tests/unit/test_connector.py", 
line 554, in test_access_error_basic_auth

mock_log.assert_called_once_with(
  File "/usr/lib/python3.11/unittest/mock.py", line 214, in 
assert_called_once_with

return mock.assert_called_once_with(*args, **kwargs)
   ^
  File "/usr/lib/python3.11/unittest/mock.py", line 945, in 
assert_called_once_with

return self.assert_called_with(*args, **kwargs)
   
  File "/usr/lib/python3.11/unittest/mock.py", line 933, in 
assert_called_with

raise AssertionError(_error_message()) from cause
AssertionError: expected call not found.
Expected: warning("We have encountered an AccessError when using 'basic' 
authentication. %(err)s", {'err': 'HTTP GET 
http://redfish/v1/SessionService returned code HTTPStatus.FORBIDDEN. 
unknown error Extended information: none'})
Actual: warning("We have encountered an AccessError when using 'basic' 
authentication. %(err)s", {'err': 'HTTP GET 
http://redfish/v1/SessionService returned code 403. unknown error 
Extended information: none'})



--
Ran 574 tests in 2.995s

FAILED (failures=1)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025122: python-stone: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'

[Paul Gevers]

Source: python-stone
Version: 3.3.1-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-stone fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-stone   from testing3.3.1-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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

=== FAILURES 
===
__ TestGeneratedPython.test_alias_validators 
___


self = testMethod=test_alias_validators>


def setUp(self):
# Sanity check: stone must be importable for the compiler 
to work

importlib.import_module('stone')
# Compile spec by calling out to stone
p = subprocess.Popen(
[sys.executable,
 '-m',
 'stone.cli',
 'python_types',
 'output',
 '-',
 '--',
 '--package',
 'output'],
stdin=subprocess.PIPE,
stderr=subprocess.PIPE)
_, stderr = p.communicate(
input=(test_spec + test_ns2_spec).encode('utf-8'))
if p.wait() != 0:

  raise AssertionError('Could not execute stone tool: %s' %

 stderr.decode('utf-8'))
E   AssertionError: Could not execute stone tool: 
/usr/lib/python3/dist-packages/stone/cli.py:8: DeprecationWarning: the 
imp module is deprecated in favour of importlib and slated for removal 
in Python 3.12; see the module's documentation for alternative uses

E import imp  # pylint: disable=deprecated-module
E   Traceback (most recent call last):
E File "", line 198, in _run_module_as_main
E File "", line 88, in _run_code
E File "/usr/lib/python3/dist-packages/stone/cli.py", line 
380, in 

E   api = main()
E ^^
E File "/usr/lib/python3/dist-packages/stone/cli.py", line 
250, in main

E   api = specs_to_ir(specs, debug=debug,
E ^^^
E File 
"/usr/lib/python3/dist-packages/stone/frontend/frontend.py", line 55, in 
specs_to_ir

E   route_whitelist_filter=route_whitelist_filter).generate_IR()
E  ^
E File 
"/usr/lib/python3/dist-packages/stone/frontend/ir_generator.py", line 
297, in generate_IR

E   self._populate_type_attributes()
E File 
"/usr/lib/python3/dist-packages/stone/frontend/ir_generator.py", line 
694, in _populate_type_attributes
E   data_type = self._resolve_type(env, 
alias._ast_node.type_ref)
E 
^
E File 
"/usr/lib/python3/dist-packages/stone/frontend/ir_generator.py", line 
1159, in _resolve_type

E   data_type = self._instantiate_data_type(
E   
E File 
"/usr/lib/python3/dist-packages/stone/frontend/ir_generator.py", line 
1077, in _instantiate_data_type
E   argspec = inspect.getargspec(data_type_class.__init__) 
# noqa: E501 # pylint: disable=deprecated-method,useless-suppression

E ^^
E   AttributeError: module 'inspect' has no attribute 
'getargspec'. Did you mean: 'getargs'?


test/test_python_gen.py:838: AssertionError
___ TestGeneratedPython.test_aliases 
___


self = 

def setUp(self):
# Sanity check: stone must be importable for the compiler 
to work

importlib.import_module('stone')
# Compile spec by calling out to stone
p = subprocess.Popen(
[sys.executable,
 '-m',
 'stone.cli',
 'python_types',
 'output',

Bug#1025123: qemu: CVE-2022-4172: erst: undefined-behavior in memcpy in write_erst_record

[Salvatore Bonaccorso]

Source: qemu
Version: 1:7.1+dfsg-2
Severity: important
Tags: security upstream
Forwarded: https://gitlab.com/qemu-project/qemu/-/issues/1268
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for qemu.

CVE-2022-4172[0]:
| An integer overflow and buffer overflow issues were found in the ACPI
| Error Record Serialization Table (ERST) device of QEMU in the
| read_erst_record() and write_erst_record() functions. Both issues may
| allow the guest to overrun the host buffer allocated for the ERST
| memory device. A malicious guest could use these flaws to crash the
| QEMU process on the host.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-4172
https://www.cve.org/CVERecord?id=CVE-2022-4172
[1] https://gitlab.com/qemu-project/qemu/-/issues/1268
[2] 
https://gitlab.com/qemu-project/qemu/-/commit/defb70980f6bed36100b74e84220f1764c0dd544
 

Regards,
Salvatore

Bug#1025121: python-stack-data: (autopkgtest) needs update for python3.11: AssertionError

[Paul Gevers]

Source: python-stack-data
Version: 0.5.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-stack-data fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-stack-data  from testing0.5.0-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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

=== FAILURES 
===
 test_variables 



def test_variables():
options = Options(before=1, after=0)
assert repr(options) == ('Options(after=0, before=1, ' +
 'blank_lines=,' +
 ' include_signature=False, ' +
 'max_lines_per_piece=6, 
pygments_formatter=None)')

def foo(arg, _arg2: str = None, *_args, **_kwargs):
y = 123986
str(y)
x = {982347298304}
str(x)
return (
FrameInfo(inspect.currentframe(), options),
arg,
arg,
)[0]
frame_info = foo('this is arg')
assert sum(line.is_current for line in frame_info.lines) == 1
body = frame_info.scope.body
tup = body[-1].value.value.elts
call = tup[0]

  assert frame_info.executing.node == call

E   AssertionError: assert None == 
E+  where None = 0x7f3677c694d0>.node
E+where 0x7f3677c694d0> = FrameInfo('/tmp/autopkgtest-lxc.0v1rnt08/downtmp/autopkgtest_tmp/tests/test_core.py', 
line 219, code foo>).executing


tests/test_core.py:233: AssertionError
_ test_example 
_


def test_example():
from .samples.example import bar
result = bar()
print(result)

  assert result == """\

bar at line 27
--
  25 | def bar():
  26 | names = {}
  27 > exec("result = foo()", globals(), 
names)

  28 | return names["result"]
names = {}
 at line 1
--
foo at line 20
--
   6 | def foo():
(...)
   8 | lst = [1]
  10 | lst.insert(0, x)
  11 | lst.append(
  12 | [
  13 | 1,
(...)
  18 | 6
  19 | ][0])
  20 > result = print_stack(
  21 |  )
  22 | return result
[
1,
2,
3,
4,
5,
6
][0] = 1
lst = [1, 1, 1]
x = 1
"""
E   assert 'bar at line ... \nx = 1 \n\n' == 'bar at line ... \nx = 
1 \n\n'

E Skipping 82 identical leading characters in diff, use -v to show
E -  27 > exec("result = foo()", globals(), 
names)
E ?   -- 
  ---

E +  27 > exec("result = foo()", globals(), names)
E 28 | return names["result"]
E   names = {} E   ...
E E ...Full output truncated (34 lines hidden), use 
'-vv' to show


tests/test_core.py:578: AssertionError
- Captured stdout call 
-

bar at line 27
--
  25 | def bar():
  26 | names = {}
  27 > exec("result = foo()", globals(), names)
  28 | return names["result"]
names = {}
 at line 1
--

foo at line 20
--
   6 | def foo():
(...)
   8 | lst = [1]
  10 | lst.insert(0, x)
  11 | lst.append(
  12 | [
  13 | 1,
(...)
  18 | 6
  19 | ][0])
  20 > result = print_stack(
  21 |  )
  22 | return result
[
1,
2,
3,
4,
5,
6
][0] = 1 lst = 

Bug#1025120: libetpan: CVE-2022-4121: Null Pointer Dereference STATUS Response

[Salvatore Bonaccorso]

Source: libetpan
Version: 1.9.4-3
Severity: important
Tags: security upstream
Forwarded: https://github.com/dinhvh/libetpan/issues/420
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libetpan.

CVE-2022-4121[0]:
| Null pointer dereference in mailimap_mailbox_data_status_free in
| low-level/imap/mailimap_types.c

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-4121
https://www.cve.org/CVERecord?id=CVE-2022-4121
[1] https://github.com/dinhvh/libetpan/issues/420

Regards,
Salvatore

Bug#1025119: python-ratelimiter: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'

[Paul Gevers]

Source: python-ratelimiter
Version: 1.2.0.post0-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-ratelimiter fails in testing when that autopkgtest is run with 
the binary packages of python3-defaults from unstable. It passes when 
run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-ratelimiter from testing1.2.0.post0-3
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

Testing with python3.11:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/ratelimiter.py", line 36, in 


class RateLimiter(object):
  File "/usr/lib/python3/dist-packages/ratelimiter.py", line 127, in 
RateLimiter

__aexit__ = asyncio.coroutine(__exit__)
^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you 
mean: 'coroutines'?

autopkgtest [23:15:36]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025118: python-pytest-subtests: (autopkgtest) needs update for python3.11: AssertionError

[Paul Gevers]

Source: python-pytest-subtests
Version: 0.8.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-pytest-subtests fails in testing when that autopkgtest is run 
with the binary packages of python3-defaults from unstable. It passes 
when run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-pytest-subtests from testing0.8.0-2
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-pytest-subtests/28750729/log.gz

=== FAILURES 
===
__ TestSubTest.test_simple_terminal_normal[unittest] 
___


self = 
simple_script = 
local('/tmp/pytest-of-debci/pytest-0/test_simple_terminal_normal2/test_simple_terminal_normal.py')
testdir = local('/tmp/pytest-of-debci/pytest-0/test_simple_terminal_normal2')>

runner = 'unittest'

@pytest.mark.parametrize("runner", ["unittest", "pytest-normal", 
"pytest-xdist"])

def test_simple_terminal_normal(self, simple_script, testdir, runner):
if runner == "unittest":
result = testdir.run(sys.executable, simple_script)

  result.stderr.fnmatch_lines(

[
"FAIL: test_foo (__main__.T) [custom] (i=1)",
"AssertionError: 1 != 0",
"FAIL: test_foo (__main__.T) [custom] (i=3)",
"AssertionError: 1 != 0",
"Ran 1 test in *",
"FAILED (failures=2)",
]
)
E   Failed: nomatch: 'FAIL: test_foo (__main__.T) [custom] (i=1)'
E   and: 'FF'
E   and: 
'=='

E   and: 'FAIL: test_foo (__main__.T.test_foo) [custom] (i=1)'
E   and: 
'--'

E   and: 'Traceback (most recent call last):'
E   and: '  File 
"/tmp/pytest-of-debci/pytest-0/test_simple_terminal_normal2/test_simple_terminal_normal.py", 
line 8, in test_foo'

E   and: 'self.assertEqual(i % 2, 0)'
E   and: 'AssertionError: 1 != 0'
E   and: ''
E   and: 
'=='

E   and: 'FAIL: test_foo (__main__.T.test_foo) [custom] (i=3)'
E   and: 
'--'

E   and: 'Traceback (most recent call last):'
E   and: '  File 
"/tmp/pytest-of-debci/pytest-0/test_simple_terminal_normal2/test_simple_terminal_normal.py", 
line 8, in test_foo'

E   and: 'self.assertEqual(i % 2, 0)'
E   and: 'AssertionError: 1 != 0'
E   and: ''
E   and: 
'--'

E   and: 'Ran 1 test in 0.001s'
E   and: ''
E   and: 'FAILED (failures=2)'
E   remains unmatched: 'FAIL: test_foo (__main__.T) [custom] (i=1)'

/tmp/autopkgtest-lxc.agke3g8v/downtmp/autopkgtest_tmp/tests/test_subtests.py:142: 
Failed
- Captured stdout call 
-
running: /usr/bin/python3.11 
/tmp/pytest-of-debci/pytest-0/test_simple_terminal_normal2/test_simple_terminal_normal.py

 in: /tmp/pytest-of-debci/pytest-0/test_simple_terminal_normal2
- Captured stderr call 
-

FF
==
FAIL: test_foo (__main__.T.test_foo) [custom] (i=1)
--
Traceback (most recent call last):
  File 
"/tmp/pytest-of-debci/pytest-0/test_simple_terminal_normal2/test_simple_terminal_normal.py", 
line 8, in test_foo

self.assertEqual(i % 2, 0)
AssertionError: 1 != 0

==
FAIL: test_foo 

Bug#1024999: Please consider to build with LTO enabled

[Mike Gabriel]

Hi Gunnar,

On  Di 29 Nov 2022 18:18:40 CET, Gunnar Hjalmarsson wrote:


On 2022-11-29 01:52, Gunnar Hjalmarsson wrote:

The goal is to make the source possible to autosync on the Ubuntu
side, so your package updates are reflected also in Ubuntu without
any manual intervention.


Just wanted to let you know that the goal was met. :)

https://launchpad.net/ubuntu/+source/maliit-framework/2.3.0-3.2

--
Cheers,
Gunnar


thanks + great to hear!

Mike
--

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

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



pgphHG150slaf.pgp
Description: Digitale PGP-Signatur

Bug#1025099: plocate: autofs pruning doesn't seem to work

[Steinar H. Gunderson]

On Tue, Nov 29, 2022 at 11:31:39AM -0800, Ross Vandegrift wrote:
>> Subject: Bug#1025099: plocate: autofs pruning doesn't seem to work
> That subject wasn't too clear- updatedb.plocate does not index the
> remote filesystem, it just triggeres the automount unnecessarily.

I don't think that's possible to avoid; the directory must be stat()-ed
to get to know what type of filesystem it is, and I guess that would trigger
the mount?

I guess it's an interesting question why it even knows how to enter that
directory, if it's not mounted; are you running with ghost on?

/* Steinar */
-- 
Homepage: https://www.sesse.net/

Bug#1025117: python-pyramid: (autopkgtest) needs update for python3.11: 'Translations' object has no attribute 'lgettext'

[Paul Gevers]

Source: python-pyramid
Version: 2.0+dfsg-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-pyramid fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-pyramid from testing2.0+dfsg-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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

=== FAILURES 
===
___ TestTranslations.test_ldgettext 



self = 

def test_ldgettext(self):
t = self._makeOne()

  self.assertEqual(t.ldgettext('messages', 'foo'), b'Voh')


tests/test_i18n.py:426: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = , domain = 'messages', message = 'foo'

def ldgettext(self, domain, message):
"""Like ``lgettext()``, but look the message up in the specified
domain.
"""

  return self._domains.get(domain, self).lgettext(message)

E   AttributeError: 'Translations' object has no attribute 'lgettext'

/usr/lib/python3/dist-packages/pyramid/i18n.py:342: AttributeError
___ TestTranslations.test_ldngettext 
___


self = 

def test_ldngettext(self):
t = self._makeOne()

  self.assertEqual(t.ldngettext('messages', 'foo1', 'foos1', 1), b'Voh1')


tests/test_i18n.py:441: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = , domain = 'messages', singular = 'foo1'
plural = 'foos1', num = 1

def ldngettext(self, domain, singular, plural, num):
"""Like ``lngettext()``, but look the message up in the specified
domain.
"""

  return self._domains.get(domain, self).lngettext(singular, plural, num)

E   AttributeError: 'Translations' object has no attribute 'lngettext'

/usr/lib/python3/dist-packages/pyramid/i18n.py:360: AttributeError


OpenPGP_signature
Description: OpenPGP digital signature

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

[Paul Gevers]

Source: python-pybedtools
Version: 0.9.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-pybedtools fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-pybedtools  from testing0.9.0-2
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

Testing with python3.11:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pybedtools/__init__.py", line 
16, in 

from . import contrib
  File "/usr/lib/python3/dist-packages/pybedtools/contrib/__init__.py", 
line 3, in 

from . import venn_maker
  File 
"/usr/lib/python3/dist-packages/pybedtools/contrib/venn_maker.py", line 
11, in 

from pybedtools import helpers
  File "/usr/lib/python3/dist-packages/pybedtools/helpers.py", line 12, 
in 

import pysam
  File "/usr/lib/python3/dist-packages/pysam/__init__.py", line 5, in 


from pysam.libchtslib import *
ModuleNotFoundError: No module named 'pysam.libchtslib'
autopkgtest [23:15:21]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025115: python-phx-class-registry: (autopkgtest) needs update for python3.11: python3.11: command not found

[Paul Gevers]

Source: python-phx-class-registry
Version: 3.0.5-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-phx-class-registry fails in testing when that autopkgtest is run 
with the binary packages of python3-defaults from unstable. It passes 
when run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-phx-class-registry from testing3.0.5-3
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-phx-class-registry/28750380/log.gz

[*] testing on python3.11:
bash: line 1: python3.11: command not found
autopkgtest [23:15:16]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024589: dislocker: FTBFS with ruby3.1: mv: cannot stat '/<>/debian/tmp/usr/lib/libdislocker*': No such file or directory

[Lucas Kanashiro]

Hi Michael,

First of all, thanks for taking a look at this bug.

Em 25/11/2022 14:06, Michael Prokop escreveu:

Thanks for doing this! I tried to reproduce it with only the
following change applied:

| --- debian/control
| +++ debian/control
| @@ -7,7 +7,7 @@ Build-Depends: cmake,
| debhelper-compat (=13),
| libfuse-dev | libfuse-hurd-dev,
| libmbedtls-dev,
| -   ruby-dev
| +   ruby-dev (>= 1:3.1~0)

But it works fine for me when building this in a cowbuilder
experimental environment on amd64.


I got the build failure using sbuild, in a unstable chroot with 
experimental enabled. To check if this is not an issue with my build 
environment, I also tried to build it inside an unstable lxd container 
with experimental enabled and I got the same build failure.



So quoting from your *full* build log:

| Install the project...
| /usr/bin/cmake -P cmake_install.cmake
| -- Install configuration: "None"
| -- Installing: /<>/debian/tmp/usr/lib64/libdislocker.so.0.7.2
| -- Installing: /<>/debian/tmp/usr/lib64/libdislocker.so.0.7
| -- Installing: /<>/debian/tmp/usr/lib64/libdislocker.so
| -- Installing: /<>/debian/tmp/usr/bin/dislocker-fuse
| -- Set runtime path of "/<>/debian/tmp/usr/bin/dislocker-fuse" to 
""
| -- Installing: 
/<>/debian/tmp/usr/share/man/man1/dislocker-fuse.1.gz
| -- Installing: /<>/debian/tmp/usr/bin/dislocker-file
| -- Set runtime path of "/<>/debian/tmp/usr/bin/dislocker-file" to 
""
| -- Installing: 
/<>/debian/tmp/usr/share/man/man1/dislocker-file.1.gz
| -- Installing: /<>/debian/tmp/usr/bin/dislocker-metadata
| -- Set runtime path of "/<>/debian/tmp/usr/bin/dislocker-metadata" to 
""
| -- Installing: /<>/debian/tmp/usr/bin/dislocker-bek
| -- Set runtime path of "/<>/debian/tmp/usr/bin/dislocker-bek" to 
""
| -- Installing: /<>/debian/tmp/usr/bin/dislocker-find
| -- Installing: 
/<>/debian/tmp/usr/share/man/man1/dislocker-find.1.gz
| make[1]: Leaving directory '/<>'
|debian/rules override_dh_install-arch
| make[1]: Entering directory '/<>'
| dh_install
| mv /<>/debian/tmp/usr/lib/libdislocker* \
|/<>/debian/libdislocker0.7/usr/lib/
| mv: cannot stat '/<>/debian/tmp/usr/lib/libdislocker*': No such 
file or directory

So that feels like a problem between /usr/lib64 vs /usr/lib on your
system?

My experimental environment has merged-usr layout:

| # ls -la /var/cache/pbuilder/base-exp-amd64.cow/
| total 300
| drwxr-xr-x 18 root root   4096 Nov 25 17:02 .
| drwxr-xr-x 24 root root   4096 Nov 25 17:03 ..
| -rw-r--r--  1 root root 232304 Nov 25 17:02 .ilist
| lrwxrwxrwx  1 root root  7 Sep 19 08:53 bin -> usr/bin
| drwxr-xr-x  2 root root   4096 Jan 14  2018 boot
| drwxr-xr-x  2 root root   4096 Jul 13  2018 build
| drwxr-xr-x  4 root root   4096 Nov 25 17:02 dev
| drwxr-xr-x 32 root root   4096 Nov 25 17:02 etc
| drwxr-xr-x  2 root root   4096 Jan 14  2018 home
| lrwxrwxrwx  1 root root  7 Sep 19 08:53 lib -> usr/lib
| lrwxrwxrwx  1 root root  9 Sep 19 08:53 lib32 -> usr/lib32
| lrwxrwxrwx  1 root root  9 Sep 19 08:53 lib64 -> usr/lib64
| lrwxrwxrwx  1 root root 10 Sep 19 08:53 libx32 -> usr/libx32
| [...]

Might this be related?


In my lxd container I have a similar layout:

# ls -la /
total 68
drwxr-xr-x   17 root   root 4096 Nov 21 06:15 .
drwxr-xr-x   17 root   root 4096 Nov 21 06:15 ..
lrwxrwxrwx    1 root   root    7 Nov 21 06:06 bin -> usr/bin
drwxr-xr-x    2 root   root 4096 Oct  3 21:30 boot
drwxr-xr-x    8 root   root  500 Nov 21 20:01 dev
drwxr-xr-x   79 root   root 4096 Nov 21 21:00 etc
drwxr-xr-x    3 root   root 4096 Nov 21 20:39 home
lrwxrwxrwx    1 root   root    7 Nov 21 06:06 lib -> usr/lib
lrwxrwxrwx    1 root   root    9 Nov 21 06:06 lib32 -> usr/lib32
lrwxrwxrwx    1 root   root    9 Nov 21 06:06 lib64 -> usr/lib64
lrwxrwxrwx    1 root   root   10 Nov 21 06:06 libx32 -> usr/libx32
drwxr-xr-x    2 root   root 4096 Nov 21 06:06 media
drwxr-xr-x    2 root   root 4096 Nov 21 06:06 mnt
drwxr-xr-x    2 root   root 4096 Nov 21 06:06 opt
dr-xr-xr-x 1264 nobody nogroup 0 Nov 21 20:01 proc
drwx--    7 root   root    12288 Nov 29 20:26 root
drwxr-xr-x   11 root   root  320 Nov 21 20:20 run
lrwxrwxrwx    1 root   root    8 Nov 21 06:06 sbin -> usr/sbin
drwxr-xr-x    2 root   root 4096 Nov 21 06:06 srv
dr-xr-xr-x   13 nobody nogroup 0 Nov 21 20:01 sys
drwxrwxrwt   11 root   root    12288 Nov 29 20:26 tmp
drwxr-xr-x   14 root   root 4096 Nov 21 06:06 usr
drwxr-xr-x   11 root   root 4096 Nov 21 06:06 var

I am not sure if this is the cause of the build failure.

--
Lucas Kanashiro

Bug#1025114: python-parameterized: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'

[Paul Gevers]

Source: python-parameterized
Version: 0.8.1-5
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-parameterized fails in testing when that autopkgtest is run with 
the binary packages of python3-defaults from unstable. It passes when 
run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-parameterized   from testing0.8.1-5
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

==
ERROR: test suite for '/usr/lib/python3/dist-packages/parameterized/test.py'>

--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 228, in run
self.tearDown()
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 351, in 
tearDown

self.teardownContext(ancestor)
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 367, in 
teardownContext

try_run(context, names)
  File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run
inspect.getargspec(func)
^^
AttributeError: module 'inspect' has no attribute 'getargspec'

--
Ran 96 tests in 0.045s

FAILED (SKIP=1, errors=1)
autopkgtest [23:15:24]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025113: O: asunder -- graphical audio CD ripper and encoder

[Andreas Rönnquist]

Package: wnpp
Severity: normal
Control: affects -1 src:asunder

I intend to orphan the asunder package. Upstream has no interest in migrating
to GTK3, and will keep maintaining the current GTK2 version. Because of this,
my interest in the package is minimal - see #967259 [1]. (This could
theoretically change if upstream changes their mind regarding GTK3, but it
seems very unlikely [2]). There is a GTK3 port that seems to work just
fine [3], but I don't want to become the sole upstream of it. I might
look at another implementation in another language though...

The package description is:
 Asunder is a graphical Audio CD ripper and encoder. It can be used to
 save tracks from Audio CDs. Main features:
 .
  * Supports WAV, MP3, Ogg Vorbis, FLAC, and Wavpack audio files
  * Uses CDDB to name and tag each track
  * Can encode to multiple formats in one session
  * Creates M3U playlists
  * Allows for each track to be by a different artist
  * Does not require a specific desktop environment (just GTK+)

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967259
2: https://littlesvr.ca/bugs/show_bug.cgi?id=59
3: https://gitlab.gnome.org/Salamandar/asunder

Bug#1025112: python-os-win: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'

[Paul Gevers]

Source: python-os-win
Version: 5.7.1-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-os-win fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-os-win  from testing5.7.1-2
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-os-win/28750378/log.gz

==
FAIL: 
os_win.tests.unit.test_utilsfactory.TestHyperVUtilsFactory.test_utils_public_signatures

os_win.tests.unit.test_utilsfactory.TestHyperVUtilsFactory.test_utils_public_signatures
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):
  File 
"/tmp/autopkgtest-lxc.f4g2jevo/downtmp/build.Pwx/src/os_win/tests/unit/test_utilsfactory.py", 
line 167, in test_utils_public_signatures

self.assertPublicAPISignatures(base_class, tested_class)
  File 
"/tmp/autopkgtest-lxc.f4g2jevo/downtmp/build.Pwx/src/os_win/tests/unit/test_utilsfactory.py", 
line 189, in assertPublicAPISignatures

baseargs = inspect.getargspec(basemethods[name])
   ^^
AttributeError: module 'inspect' has no attribute 'getargspec'


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025111: python-omegaconf: (autopkgtest) needs update for python3.11: mutable default for field params is not allowed

[Paul Gevers]

Source: python-omegaconf
Version: 2.2.2-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-omegaconf fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-omegaconf   from testing2.2.2-2
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

+ 
PYTHONPATH=/tmp/autopkgtest-lxc.4vq75_au/downtmp/build.XHu/src/debian/tmp/usr/lib/python3/dist-packages 
http_proxy=127.0.0.1:9 https_proxy=127.0.0.9:9 HTTP_PROXY=127.0.0.1:9 
HTTPS_PROXY=127.0.0.1:9 PYTHON=python3.11 python3.11 -m pytest tests -v
ImportError while loading conftest 
'/tmp/autopkgtest-lxc.4vq75_au/downtmp/build.XHu/src/tests/conftest.py'.

tests/__init__.py:96: in 
@dataclass
/usr/lib/python3.11/dataclasses.py:1220: in dataclass
return wrap(cls)
/usr/lib/python3.11/dataclasses.py:1210: in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash,
/usr/lib/python3.11/dataclasses.py:958: in _process_class
cls_fields.append(_get_field(cls, name, type, kw_only))
/usr/lib/python3.11/dataclasses.py:815: in _get_field
raise ValueError(f'mutable default {type(f.default)} for field '
E   ValueError: mutable default 'tests.ConcretePlugin.FoobarParams'> for field params is not allowed: 
use default_factory

autopkgtest [23:15:46]: test unittests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025110: python-novaclient: (autopkgtest) needs update for python3.11: conflicting subparser

[Paul Gevers]

Source: python-novaclient
Version: 2:18.1.0-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-novaclient fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-novaclient  from testing2:18.1.0-2
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

==
FAIL: 
novaclient.tests.unit.test_shell.TestLoadVersionedActions.test_load_actions_with_versioned_args

novaclient.tests.unit.test_shell.TestLoadVersionedActions.test_load_actions_with_versioned_args
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):

  File "/usr/lib/python3.11/unittest/mock.py", line 1369, in patched
return func(*newargs, **newkeywargs)
   ^
  File 
"/tmp/autopkgtest-lxc.8wmmwvjy/downtmp/build.5yv/src/novaclient/tests/unit/test_shell.py", 
line 920, in test_load_actions_with_versioned_args

shell._find_actions(subparsers, fake_actions_module,
  File 
"/tmp/autopkgtest-lxc.8wmmwvjy/downtmp/build.5yv/src/novaclient/shell.py", 
line 450, in _find_actions

subparser = subparsers.add_parser(
^^
  File "/usr/lib/python3.11/argparse.py", line 1197, in add_parser
raise ArgumentError(self, _('conflicting subparser: %s') % name)
argparse.ArgumentError: argument : conflicting subparser: 
another-fake-action



==
FAIL: 
novaclient.tests.unit.test_shell.TestLoadVersionedActions.test_load_versioned_actions

novaclient.tests.unit.test_shell.TestLoadVersionedActions.test_load_versioned_actions
--
testtools.testresult.real._StringException: Traceback (most recent call 
last):
  File 
"/tmp/autopkgtest-lxc.8wmmwvjy/downtmp/build.5yv/src/novaclient/tests/unit/test_shell.py", 
line 800, in test_load_versioned_actions

shell._find_actions(subparsers, fake_actions_module,
  File 
"/tmp/autopkgtest-lxc.8wmmwvjy/downtmp/build.5yv/src/novaclient/shell.py", 
line 450, in _find_actions

subparser = subparsers.add_parser(
^^
  File "/usr/lib/python3.11/argparse.py", line 1197, in add_parser
raise ArgumentError(self, _('conflicting subparser: %s') % name)
argparse.ArgumentError: argument : conflicting subparser: 
another-fake-action


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025109: python-memory-profiler: (autopkgtest) needs update for python3.11: cannot import name 'coroutine' from 'asyncio'

[Paul Gevers]

Source: python-memory-profiler
Version: 0.60-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-memory-profiler fails in testing when that autopkgtest is run 
with the binary packages of python3-defaults from unstable. It passes 
when run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-memory-profiler from testing0.60-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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-memory-profiler/28750375/log.gz

Testing with python3.11:
python3.11 -m memory_profiler test/test_func.py
Traceback (most recent call last):
  File "", line 198, in _run_module_as_main
  File "", line 88, in _run_code
  File "/usr/lib/python3/dist-packages/memory_profiler.py", line 10, in 


from asyncio import coroutine, iscoroutinefunction
ImportError: cannot import name 'coroutine' from 'asyncio' 
(/usr/lib/python3.11/asyncio/__init__.py)

make: *** [Makefile:6: test] Error 1
autopkgtest [23:14:56]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025108: python-marshmallow-dataclass: (autopkgtest) needs update for python3.11: ValueError: mutable default for field data is not allowed

[Paul Gevers]

Source: python-marshmallow-dataclass
Version: 8.5.8-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-marshmallow-dataclass fails in testing when that autopkgtest is 
run with the binary packages of python3-defaults from unstable. It 
passes when run with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-marshmallow-dataclass from testing8.5.8-3
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-marshmallow-dataclass/28750374/log.gz

=== FAILURES 
===
_ TestClassSchema.test_final_infers_type_from_default 
__


self = testMethod=test_final_infers_type_from_default>


def test_final_infers_type_from_default(self):
# @dataclasses.dataclass
class A:
data: Final = "a"
# @dataclasses.dataclass
class B:
data: Final = A()
# NOTE: This workaround is needed to avoid a Mypy crash.
# See: 
https://github.com/python/mypy/issues/10090#issuecomment-865971891

if not TYPE_CHECKING:
A = dataclasses.dataclass(A)

  B = dataclasses.dataclass(B)


tests/test_class_schema.py:242: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3.11/dataclasses.py:1220: in dataclass

return wrap(cls)
/usr/lib/python3.11/dataclasses.py:1210: in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash,
/usr/lib/python3.11/dataclasses.py:958: in _process_class
cls_fields.append(_get_field(cls, name, type, kw_only))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _
cls = 'tests.test_class_schema.TestClassSchema.test_final_infers_type_from_default..B'>

a_name = 'data', a_type = typing.Final, default_kw_only = False

def _get_field(cls, a_name, a_type, default_kw_only):
# Return a Field object for this field name and type. 
ClassVars and
# InitVars are also returned, but marked as such (see 
f._field_type).
# default_kw_only is the value of kw_only to use if there isn't 
a field()

# that defines it.
# If the default value isn't derived from Field, then it's 
only a

# normal default value.  Convert it to a Field().
default = getattr(cls, a_name, MISSING)
if isinstance(default, Field):
f = default
else:
if isinstance(default, types.MemberDescriptorType):
# This is a field in __slots__, so it has no default value.
default = MISSING
f = field(default=default)
# Only at this point do we know the name and the type.  Set 
them.

f.name = a_name
f.type = a_type
# Assume it's a normal field until proven otherwise.  We're 
next

# going to decide if it's a ClassVar or InitVar, everything else
# is just a normal field.
f._field_type = _FIELD
# In addition to checking for actual types here, also check for
# string annotations.  get_type_hints() won't always work for us
# (see https://github.com/python/typing/issues/508 for example),
# plus it's expensive and would require an eval for every string
# annotation.  So, make a best effort to see if this is a ClassVar
# or InitVar using regex's and checking that the thing referenced
# is actually of the correct type.
# For the complete discussion, see 
https://bugs.python.org/issue33453

# If typing has not been imported, then it's impossible for any
# annotation to be a ClassVar.  So, only look for ClassVar if
# typing has been imported by any module (not necessarily cls's
# module).
typing = sys.modules.get('typing')
if typing:
if (_is_classvar(a_type, typing)
or (isinstance(f.type, str)
and _is_type(f.type, cls, typing, typing.ClassVar,
  

Bug#1025107: python-limits: (autopkgtest) needs update for python3.11: AssertionError

[Paul Gevers]

Source: python-limits
Version: 2.7.0-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-limits fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-limits  from testing2.7.0-3
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.mnkehych/downtmp/autopkgtest_tmp/memcached_storage.py", 
line 12, in 
assert True == fixed_window.hit(one_per_second, "test_namespace", 
"foo")

AssertionError
autopkgtest [23:14:41]: test python3-tests



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025106: python-icecream: (autopkgtest) needs update for python3.11: ValueError: not enough values to unpack (expected 2, got 1)

[Paul Gevers]

Source: python-icecream
Version: 2.1.3-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-icecream fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-icecreamfrom testing2.1.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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

FFF.EE.EFEFFEEF.E.FF.FFFEFE
==
ERROR: testComments (tests.test_icecream.TestIceCream.testComments)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 291, in testComments

assert lineIsContextAndTime(err.getvalue())
   
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 115, in lineIsContextAndTime

context, time = line.split(' at ')
^
ValueError: not enough values to unpack (expected 2, got 1)

==
ERROR: testComplicated (tests.test_icecream.TestIceCream.testComplicated)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 308, in testComplicated

assert lineIsContextAndTime(err.getvalue().splitlines()[0])
   
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 115, in lineIsContextAndTime

context, time = line.split(' at ')
^
ValueError: not enough values to unpack (expected 2, got 1)

==
ERROR: testContextAbsPathMultiLine 
(tests.test_icecream.TestIceCream.testContextAbsPathMultiLine)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 502, in testContextAbsPathMultiLine

assert lineIsAbsPathContext(firstLine)
   ^^^
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 142, in lineIsAbsPathContext

int(lineNumber) > 0 and
^^^
ValueError: invalid literal for int() with base 10: ' Failed to access 
the underlying source code for analysis. Was ic() invoked'


==
ERROR: testDifferentName 
(tests.test_icecream.TestIceCream.testDifferentName)

--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 323, in testDifferentName

assert lineIsContextAndTime(err.getvalue())
   
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 115, in lineIsContextAndTime

context, time = line.split(' at ')
^
ValueError: not enough values to unpack (expected 2, got 1)

==
ERROR: testFormat (tests.test_icecream.TestIceCream.testFormat)
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/tests/test_icecream.py", 
line 511, in testFormat

"""comment"""; noop(); s = ic.format(  # noqa
   ^^
  File 
"/tmp/autopkgtest-lxc.hwa09bp6/downtmp/build.H96/src/icecream/icecream.py", 
line 225, in format

out = self._format(callFrame, *args)
  

Bug#1025105: python-hypothesis: (autopkgtest) needs update for python3.11: AssertionError

[Paul Gevers]

Source: python-hypothesis
Version: 6.36.0-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-hypothesis fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-hypothesis  from testing6.36.0-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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

ImportError while loading conftest 
'/tmp/autopkgtest-lxc.t_1nxhv7/downtmp/build.qdA/src/hypothesis-python/tests/conftest.py'.

tests/conftest.py:39: in 
assert sys.version_info.releaselevel == "alpha"
E   AssertionError
autopkgtest [23:14:38]: test command1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014662: cloud-initramfs-growroot: Initramfs hook does not include `flock` command

[Shane Frasier]

Dear Maintainer,

I am seeing exactly this same issue in Kali Linux, which uses the Debian
Bullseye package.  This is causing our AMIs (which use the official Kali
AMI as the base) to fail to boot.

Thank you,
Shane Frasier

On Sun, 10 Jul 2022 11:25:41 +1000 undef  wrote:
>
> Package: cloud-initramfs-growroot
> Version: 0.18.debian8
> Severity: important
> Tags: upstream
> X-Debbugs-Cc: debian@undef.tools
>
> Dear Maintainer,
>
> As part of the standard Mobian install proceedure, we use
> cloud-initramfs-growroot to expand the root partition on the device.
> Recent installs have been failing to resize with the following (debug)
> output:
> ```
> + growpart /dev/mmcblk0 2
> + out='failed [flock:127] flock -x 9
> /sbin/growpart: line 714: flock: not found
> FAILED: Error while obtaining exclusive lock on /dev/mmcblk0'
> + echo 'GROWROOT: WARNING: resize failed: failed [flock:127] flock -x 9
> /sbin/growpart: line 714: flock: not found
> FAILED: Error while obtaining exclusive lock on /dev/mmcblk0'
> GROWROOT: WARNING: resize failed: failed [flock:127] flock -x 9
> /sbin/growpart: line 714: flock: not found
> FAILED: Error while obtaining exclusive lock on /dev/mmcblk0
> + udevadm settle --timeout 30
> ```
>
> I believe this issue is solved upstream where the hook has been
> re-written
> (
https://git.launchpad.net/cloud-initramfs-tools/tree/growroot/hooks/growroot#n12
).
>
> Without updating to the latest upstream version, simply adding
> `copy_exec /bin/flock /bin` to the growroot hook also solves the issue.
>
> Thank you for your consideration.
>
>
> -- System Information:
> Debian Release: bookworm/sid
>APT prefers testing
>APT policy: (500, 'testing')
> Architecture: arm64 (aarch64)
>
> Kernel: Linux 5.18.7-rockchip (SMP w/6 CPU threads)
> Kernel taint flags: TAINT_CRAP, TAINT_UNSIGNED_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages cloud-initramfs-growroot depends on:
> pn  cloud-utils  
> ii  fdisk2.38-4
> ii  initramfs-tools  0.141
> ii  util-linux   2.38-4
>
> cloud-initramfs-growroot recommends no packages.
>
> cloud-initramfs-growroot suggests no packages.
>

Bug#1025104: krita: segfault on exit

[Jakub Wilk]

Package: krita
Version: 1:5.1.3+dfsg-1

krita segfaults every time I exit from it.

Backtrace:

#0  0x0151 in  ()
#1  0xf488c3ae in KoColorProfileStorage::Private::~Private() (this=0x5713ae40, 
__in_chrg=) at ./libs/pigment/KoColorProfileStorage.cpp:42
#2  0xf488a2d3 in 
QScopedPointerDeleter::cleanup(KoColorProfileStorage::Private*)
 (pointer=0x5713ae40) at /usr/include/i386-linux-gnu/qt5/QtCore/qscopedpointer.h:52
#3  
QScopedPointerDeleter::cleanup(KoColorProfileStorage::Private*)
 (pointer=0x5713ae40) at /usr/include/i386-linux-gnu/qt5/QtCore/qscopedpointer.h:52
#4  QScopedPointer >::~QScopedPointer() 
(this=0x57021e84, __in_chrg=) at 
/usr/include/i386-linux-gnu/qt5/QtCore/qscopedpointer.h:107
#5  KoColorProfileStorage::~KoColorProfileStorage() (this=0x57021e84, 
__in_chrg=) at ./libs/pigment/KoColorProfileStorage.cpp:56
#6  0xf4881ce7 in KoColorSpaceRegistry::Private::~Private() (this=0x57021e70, 
__in_chrg=) at ./libs/pigment/KoColorSpaceRegistry.cpp:42
#7  KoColorSpaceRegistry::~KoColorSpaceRegistry() (this=0xf4aeff90 <(anonymous 
namespace)::Q_QGS_s_instance::innerFunction()::holder>, __in_chrg=) 
at ./libs/pigment/KoColorSpaceRegistry.cpp:232
#8  0xf4881f08 in Holder::~Holder() (this=0xf4aeff90 <(anonymous 
namespace)::Q_QGS_s_instance::innerFunction()::holder>, __in_chrg=) 
at ./libs/pigment/KoColorSpaceRegistry.cpp:39
#9  0xf503bb5b in __run_exit_handlers (status=0, listp=0xf521d4a0 
<__exit_funcs>, run_list_atexit=true, run_dtors=true) at ./stdlib/exit.c:89
#10 0xf503bcb1 in __GI_exit (status=0) at ./stdlib/exit.c:143
#11 0xf50232a1 in __libc_start_call_main (main=main@entry=0x5655aaa0 , argc=argc@entry=1, argv=argv@entry=0xd634) at 
../sysdeps/nptl/libc_start_call_main.h:74
#12 0xf5023358 in __libc_start_main_impl (main=0x5655aaa0 , 
argc=1, argv=0xd634, init=0x0, fini=0x0, rtld_fini=0xf7fcd820 <_dl_fini>, 
stack_end=0xd62c) at ../csu/libc-start.c:381
#13 0x5655ede7 in _start ()


-- System Information:
Architecture: i386

Versions of packages krita depends on:
ii  krita-data1:5.1.3+dfsg-1
ii  libc6 2.36-6
ii  libexiv2-27   0.27.5-4
ii  libfftw3-double3  3.3.8-2
ii  libgcc-s1 12.2.0-9
ii  libgif7   5.2.1-2.5
ii  libgsl27  2.7.1+dfsg-3+b1
ii  libheif1  1.13.0-1
ii  libimath-3-1-29   3.1.5-1+b1
ii  libjpeg62-turbo   1:2.1.2-1+b1
ii  libjxl0.7 0.7.0-6
ii  libkf5completion5 5.100.0-1
ii  libkf5configcore5 5.100.1-1
ii  libkf5configgui5  5.100.1-1
ii  libkf5coreaddons5 5.100.0-1
ii  libkf5crash5  5.100.0-1
ii  libkf5guiaddons5  5.100.0-3
ii  libkf5i18n5   5.100.0-1
ii  libkf5itemviews5  5.100.0-1
ii  libkf5widgetsaddons5  5.100.0-2
ii  libkf5windowsystem5   5.100.0-1
ii  libkseexpr4   4.0.4.0-4
ii  libkseexprui4 4.0.4.0-4
ii  liblcms2-22.13.1-1+b1
ii  libmypaint-1.5-1  1.6.0-2
ii  libopencolorio2.1 2.1.2+dfsg1-4+b1
ii  libopenexr-3-1-30 3.1.5-4
ii  libopenjp2-7  2.5.0-1
ii  libpng16-16   1.6.39-1
ii  libpoppler-qt5-1  22.08.0-2.1
ii  libpython3.10 3.10.8-3
ii  libqt5core5a  5.15.6+dfsg-4
ii  libqt5dbus5   5.15.6+dfsg-4
ii  libqt5gui55.15.6+dfsg-4
ii  libqt5multimedia5 5.15.6-2
ii  libqt5network55.15.6+dfsg-4
ii  libqt5printsupport5   5.15.6+dfsg-4
ii  libqt5qml55.15.6+dfsg-2
ii  libqt5quick5  5.15.6+dfsg-2
ii  libqt5quickwidgets5   5.15.6+dfsg-2
ii  libqt5sql55.15.6+dfsg-4
ii  libqt5sql5-sqlite 5.15.6+dfsg-4
ii  libqt5svg55.15.6-2
ii  libqt5widgets55.15.6+dfsg-4
ii  libqt5x11extras5  5.15.6-2
ii  libqt5xml55.15.6+dfsg-4
ii  libquazip5-1  0.9.1-3
ii  libraw20  0.20.2-2+b1
ii  libstdc++612.2.0-9
ii  libtiff5  4.4.0-6
ii  libwebp7  1.2.2-2+b2
ii  libx11-6  2:1.8.1-2
ii  zlib1g1:1.2.13.dfsg-1

--
Jakub Wilk

Bug#1025103: python-h2: (autopkgtest) needs update for python3.11: AssertionError

[Paul Gevers]

Source: python-h2
Version: 4.1.0-3
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-h2 fails in testing when that autopkgtest is run with the binary 
packages of python3-defaults from unstable. It passes when run with only 
packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-h2  from testing4.1.0-3
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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

=== FAILURES 
===
 TestEventReprs.test_remotesettingschanged_repr 



self = 

def test_remotesettingschanged_repr(self):
"""
RemoteSettingsChanged has a useful debug representation.
"""
e = h2.events.RemoteSettingsChanged()
e.changed_settings = {
h2.settings.SettingCodes.INITIAL_WINDOW_SIZE:
h2.settings.ChangedSetting(
h2.settings.SettingCodes.INITIAL_WINDOW_SIZE, 
2**16, 2**15

),
}
>   assert repr(e) == (
""setting=SettingCodes.INITIAL_WINDOW_SIZE, 
original_value=65536, "

"new_value=32768)}>"
)
E   AssertionError: assert '' == 
''

E Skipping 54 identical leading characters in diff, use -v to show
E - g(setting=SettingCodes.INITIAL_WINDOW_SIZE, 
original_value=65536, new_value=32768)}>

E ?   
E + g(setting=4, original_value=65536, new_value=32768)}>
E ?   ^

test/test_events.py:210: AssertionError
_ TestEventReprs.test_streamreset_repr 
_


self = 

def test_streamreset_repr(self):
"""
StreamEnded has a useful debug representation.
"""
e = h2.events.StreamReset()
e.stream_id = 919
e.error_code = h2.errors.ErrorCodes.ENHANCE_YOUR_CALM
e.remote_reset = False
>   assert repr(e) == (
""
)
E   AssertionError: assert '' == 
''
E - error_code:ErrorCodes.ENHANCE_YOUR_CALM, remote_reset:False>
E ? 


E + 
E ?^^

test/test_events.py:252: AssertionError
 TestEventReprs.test_settingsacknowledged_repr 
_


self = 

def test_settingsacknowledged_repr(self):
"""
SettingsAcknowledged has a useful debug representation.
"""
e = h2.events.SettingsAcknowledged()
e.changed_settings = {
h2.settings.SettingCodes.INITIAL_WINDOW_SIZE:
h2.settings.ChangedSetting(
h2.settings.SettingCodes.INITIAL_WINDOW_SIZE, 
2**16, 2**15

),
}
>   assert repr(e) == (
""setting=SettingCodes.INITIAL_WINDOW_SIZE, 
original_value=65536, "

"new_value=32768)}>"
)
E   AssertionError: assert '' == 
''

E Skipping 53 identical leading characters in diff, use -v to show
E - g(setting=SettingCodes.INITIAL_WINDOW_SIZE, 
original_value=65536, new_value=32768)}>

E ?   
E + g(setting=4, original_value=65536, new_value=32768)}>
E ?   ^

test/test_events.py:287: AssertionError
___ TestEventReprs.test_connectionterminated_repr[None-None] 
___


self = 
additional_data = None, data_repr = 'None'

@pytest.mark.parametrize("additional_data,data_repr", [
(None, "None"),
(b'some data', "736f6d652064617461")
])
def test_connectionterminated_repr(self, additional_data, data_repr):
"""
ConnectionTerminated has a useful debug representation.
"""
e = h2.events.ConnectionTerminated()
e.error_code = h2.errors.ErrorCodes.INADEQUATE_SECURITY
e.last_stream_id = 33
e.additional_data = additional_data
>   assert repr(e) == (

Bug#1025102: python-gbulb: (autopkgtest) needs update for python3.11: module 'asyncio' has no attribute 'coroutine'

[Paul Gevers]

Source: python-gbulb
Version: 0.6.1-0.1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: needs-update
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:python3-defaults

Dear maintainer(s),

We are in the transition of adding python3.11 as a supported Python 
version [0]. With a recent upload of python3-defaults the autopkgtest of 
python-gbulb fails in testing when that autopkgtest is run with the 
binary packages of python3-defaults from unstable. It passes when run 
with only packages from testing. In tabular form:


   passfail
python3-defaults   from testing3.10.6-3
python-gbulb   from testing0.6.1-0.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 python3-defaults 
to testing [1]. https://docs.python.org/3/whatsnew/3.11.html lists 
what's new in Python3.11, it may help to identify what needs to be updated.


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

Paul

[0] https://bugs.debian.org/1021984
[1] https://qa.debian.org/excuses.php?package=python3-defaults

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

Testing with python3.11:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/gbulb/__init__.py", line 1, in 


from .glib_events import *
  File "/usr/lib/python3/dist-packages/gbulb/glib_events.py", line 227, 
in 

class GLibBaseEventLoop(_BaseEventLoop, GLibBaseEventLoopPlatformExt):
  File "/usr/lib/python3/dist-packages/gbulb/glib_events.py", line 320, 
in GLibBaseEventLoop

@asyncio.coroutine
 ^
AttributeError: module 'asyncio' has no attribute 'coroutine'. Did you 
mean: 'coroutines'?

autopkgtest [23:14:08]: test autodep8-python3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025101: rust-zstd-safe: Disabling std feature disables code

[Christopher Hoskin]

Source: rust-zstd-safe
Version: 5.0.2-1
Severity: normal

Dear Maintainer,

I'm trying to build the elan package[1] against lib-rust-zstd and I'm running 
into errors like the following:
```
error[E0277]: the trait bound `Vec<_>: WriteBuf` is not satisfied
   --> 
/usr/share/cargo/registry/elan-1.4.2/debian/cargo_registry/zstd-0.11.2/src/bulk/compressor.rs:135:39
|
135 | self.compress_to_buffer(data,  buffer)?;
|  --   ^^^ the trait `WriteBuf` is 
not implemented for `Vec<_>`
|  |
|  required by a bound introduced by this call
|
```
I think this is because the WriteBuf implementation for Vec<_> in the 
rust-zstd-safe Debian package is disabled by the `std` feature flag [2].

Is there a way you could get rust-zstd-safe to use the Debian libzstd without 
disabling this code that elan depends upon?

(N.B. Hitherto I have patched out zstd support in elan [3], but the lean
community are now depending on zstd support, so the elan package is useless
without it.)

Thanks,

Christopher Hoskin

[1] https://tracker.debian.org/pkg/elan
[2] https://sources.debian.org/src/rust-zstd-safe/5.0.2-1/src/lib.rs/#L1273
[3] 
https://salsa.debian.org/debian/elan/-/blob/debian/latest/debian/patches/0002-Revert-feat-support-tar.zst-archives.patch


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

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

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


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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

Bug#937049: mini-buildd: Python2 removal in sid/bullseye

[Bastian Germann]

Why don't you move the experimental to unstable now?
The unstable mini.buildd version is not usable but is now the last reverse 
dependency of python-setuptools
(sphinx and nuitka only have it as optional alternatives).

Bug#1025099: plocate: autofs pruning doesn't seem to work

[Ross Vandegrift]

Control: retitle -1 autofs mount triggered in spite of pruning

On Tue, Nov 29, 2022 at 11:24:03AM -0800, Ross Vandegrift wrote:
> Subject: Bug#1025099: plocate: autofs pruning doesn't seem to work

That subject wasn't too clear- updatedb.plocate does not index the
remote filesystem, it just triggeres the automount unnecessarily.

Ross

Bug#1025100: src:racon: fails to migrate to testing for too long: Build-Depends not available on 32 bits

[Paul Gevers]

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

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:racon has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package failed to build from 
source on 32 bits architectures, and since than the build dependency 
isn't even available anymore there. You either need to fix 
libthread-pool-dev on 32 bits architectures or have racon binaries 
removed from the architectures where libthread-pool-dev doesn't build.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1025099: plocate: autofs pruning doesn't seem to work

[Ross Vandegrift]

Package: plocate
Version: 1.1.17-2
Severity: normal
X-Debbugs-Cc: rvandegr...@debian.org

Hello,

I noticed that an autofs mount is being triggered by updatedb.plocate:
 systemd[1]: mnt-storage.automount: Got automount request for /mnt/storage, 
triggered by 63669 (updatedb.plocat)

It looks like the bind mount checking is involved.  Here's the --debug-pruning
output:

$ sudo journalctl -fu mnt-storage.automount &
$ mount | grep storage
systemd-1 on /mnt/storage type autofs 
(rw,relatime,fd=55,pgrp=1,timeout=600,minproto=5,maxproto=5,direct,pipe_ino=14748)
$ sudo updatedb.plocate --debug-pruning
conf_block:
prune_bind_mounts\000
1\000
\000
prunefs\000
AFS\000
AUTOFS\000
BINFMT_MISC\000
CEPH\000
CGROUP\000
CGROUP2\000
CIFS\000
CODA\000
CONFIGFS\000
CURLFTPFS\000
DEBUGFS\000
DEVFS\000
DEVPTS\000
DEVTMPFS\000
ECRYPTFS\000
FTPFS\000
FUSE.CEPH\000
FUSE.CRYFS\000
FUSE.ENCFS\000
FUSE.GLUSTERFS\000
FUSE.GOCRYPTFS\000
FUSE.GVFSD-FUSE\000
FUSE.MFS\000
FUSE.RCLONE\000
FUSE.ROZOFS\000
FUSE.SSHFS\000
FUSECTL\000
FUSESMB\000
HUGETLBFS\000
ISO9660\000
LUSTRE\000
LUSTRE_LITE\000
MFS\000
MQUEUE\000
NCPFS\000
NFS\000
NFS4\000
OCFS\000
OCFS2\000
PROC\000
PSTORE\000
RPC_PIPEFS\000
SECURITYFS\000
SHFS\000
SMBFS\000
SYSFS\000
TMPFS\000
TRACEFS\000
UDEV\000
UDF\000
USBFS\000
\000
prunenames\000
\000
prunepaths\000
/home/.ecryptfs\000
/media\000
/tmp\000
/var/lib/ceph\000
/var/lib/os-prober\000
/var/lib/schroot\000
/var/spool\000
\000

---
Rebuilding bind_mount_paths:
 `/sys' (22 on 28) is `/' of `sysfs' (0:20), type `sysfs'
 `/proc' (23 on 28) is `/' of `proc' (0:21), type `proc'
 `/dev' (24 on 28) is `/' of `udev' (0:5), type `devtmpfs'
 `/dev/pts' (25 on 24) is `/' of `devpts' (0:22), type `devpts'
 `/run' (26 on 28) is `/' of `tmpfs' (0:23), type `tmpfs'
 `/' (28 on 1) is `/' of `/dev/mapper/root' (254:0), type `ext4'
 `/sys/kernel/security' (29 on 22) is `/' of `securityfs' (0:6), type 
`securityfs'
 `/dev/shm' (30 on 24) is `/' of `tmpfs' (0:25), type `tmpfs'
 `/run/lock' (31 on 26) is `/' of `tmpfs' (0:26), type `tmpfs'
 `/sys/fs/cgroup' (32 on 22) is `/' of `cgroup2' (0:27), type `cgroup2'
 `/sys/fs/pstore' (33 on 22) is `/' of `pstore' (0:28), type `pstore'
 `/sys/firmware/efi/efivars' (34 on 22) is `/' of `efivarfs' (0:29), type 
`efivarfs'
 `/sys/fs/bpf' (35 on 22) is `/' of `bpf' (0:30), type `bpf'
 `/proc/sys/fs/binfmt_misc' (37 on 23) is `/' of `systemd-1' (0:31), type 
`autofs'
 `/dev/hugepages' (38 on 24) is `/' of `hugetlbfs' (0:32), type `hugetlbfs'
 `/dev/mqueue' (39 on 24) is `/' of `mqueue' (0:19), type `mqueue'
 `/sys/kernel/debug' (40 on 22) is `/' of `debugfs' (0:7), type `debugfs'
 `/sys/kernel/tracing' (41 on 22) is `/' of `tracefs' (0:12), type `tracefs'
 `/sys/kernel/config' (42 on 22) is `/' of `configfs' (0:33), type `configfs'
 `/sys/fs/fuse/connections' (43 on 22) is `/' of `fusectl' (0:34), type 
`fusectl'
 `/run/credentials/systemd-sysusers.service' (67 on 26) is `/' of `ramfs' 
(0:35), type `ramfs'
 `/run/credentials/systemd-tmpfiles-setup-dev.service' (69 on 26) is `/' of 
`ramfs' (0:36), type `ramfs'
 `/run/credentials/systemd-sysctl.service' (71 on 26) is `/' of `ramfs' (0:37), 
type `ramfs'
 `/efi' (82 on 28) is `/' of `systemd-1' (0:38), type `autofs'
 `/mnt/storage' (100 on 28) is `/' of `systemd-1' (0:39), type `autofs'
 `/boot' (103 on 28) is `/' of `/dev/sda1' (8:1), type `vfat'
 `/run/credentials/systemd-tmpfiles-setup.service' (135 on 26) is `/' of 
`ramfs' (0:40), type `ramfs'
 `/proc/sys/fs/binfmt_misc' (106 on 37) is `/' of `binfmt_misc' (0:41), type 
`binfmt_misc'
 `/run/rpc_pipefs' (182 on 26) is `/' of `sunrpc' (0:44), type `rpc_pipefs'
 `/run/user/1000' (252 on 26) is `/' of `tmpfs' (0:55), type `tmpfs'
 `/run/user/1000/doc' (259 on 252) is `/' of `portal' (0:50), type `fuse.portal'
 `/efi' (815 on 82) is `/' of `/dev/sda1' (8:1), type `vfat'
Matching bind_mount_paths:
 => adding `/efi' (duplicate of mount point `/boot')
...done
Checking whether filesystem `/boot' is excluded:
 `/sys', type `sysfs'
 => type matches, dir `/sys'
 `/proc', type `proc'
 => type matches, dir `/proc'
 `/dev', type `devtmpfs'
 => type matches, dir `/dev'
 `/dev/pts', type `devpts'
 => type matches, dir `/dev/pts'
 `/run', type `tmpfs'
 => type matches, dir `/run'
 `/', type `ext4'
 `/sys/kernel/security', type `securityfs'
 => type matches, dir `/sys/kernel/security'
 `/dev/shm', type `tmpfs'
 => type matches, dir `/dev/shm'
 `/run/lock', type `tmpfs'
 => type matches, dir `/run/lock'
 `/sys/fs/cgroup', type `cgroup2'
 => type matches, dir `/sys/fs/cgroup'
 `/sys/fs/pstore', type `pstore'
 => type matches, dir `/sys/fs/pstore'
 `/sys/firmware/efi/efivars', type `efivarfs'
 `/sys/fs/bpf', type `bpf'
 `/proc/sys/fs/binfmt_misc', type `autofs'
 => type matches, dir `/proc/sys/fs/binfmt_misc'
 `/dev/hugepages', type `hugetlbfs'
 => type matches, dir `/dev/hugepages'
 `/dev/mqueue', type `mqueue'
 => type matches, dir `/dev/mqueue'
 `/sys/kernel/debug', type `debugfs'
 => type matches, 

Bug#1025098: ruby-acme-client fails to rebuild on updating ruby-faraday

[Vinay]

Package: ruby-acme-client
Version: 2.0.9-1
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of 
ruby-acme-client  fails

here is the log of the failed rebuild


┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-acme-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"acme-client\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (>= 0.17, < 
2.0.0) among 96 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-acme-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/<>/debian/ruby-acme-client/usr/share/rubygems-integration/all/specifications/acme-client-2.0.9.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (>= 0.17, < 2.0.0) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-acme-client/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
abbrev (default: 0.1.0)

Bug#1025097: ruby-asana fails to rebuild after new upstream of ruby-faraday

[Vinay]

Package: ruby-asana
Version: 0.10.13-1
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of ruby-asana  fails
here is the log of the failed rebuild


┌──┐
│ Install Rubygems integration 
metadata    │

└──┘

generating gemspec at 
/<>/debian/ruby-asana/usr/share/rubygems-integration/all/specifications/asana-0.10.13.gemspec

/usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner

┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-asana/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"asana\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (>= 0.8, < 
2.0) among 103 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-asana/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/usr/share/rubygems-integration/all/specifications/oauth2-1.4.4.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1417:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (>= 0.8, < 2.0) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-asana/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1417:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
abbrev (default: 0.1.0)
base64 (default: 0.1.0)
benchmark (default: 0.1.1)
bigdecimal (default: 3.0.0)
bue:1:in `'

Bug#1025096: nanoc: FTBFS in bullseye, and will also FTBFS in bookworm next year

[Santiago Vila]

Package: src:nanoc
Version: 4.11.23-1
Severity: serious
Tags: ftbfs, patch

Dear maintainer:

During a rebuild of all packages in bullseye I noticed that this package 
does not build from source anymore:


  1) Nanoc::Core has up-to-date version information
 Failure/Error: expect(described_class.version_information).to 
match(/–#{current_year} /)


   expected "Nanoc 4.11.23 © 2007–2021 Denis Defreyne.\nRunning 
ruby 2.7.4 (2021-07-07) on x86_64-linux-gnu with RubyGems 3.2.5.\n" to 
match /–2022 /

   Diff:
   @@ -1,2 +1,3 @@
   -/–2022 /
   +Nanoc 4.11.23 © 2007–2021 Denis Defreyne.
   +Running ruby 2.7.4 (2021-07-07) on x86_64-linux-gnu with 
RubyGems 3.2.5.



This happens because there is a test which expects the current year to 
be equal to 2021, which naturally fails now that we are in 2022, and 
will fail forever from now on.


I include a trivial patch to disable the test in bullseye.

Note also that the current version in testing/unstable also has the bug 
in "latent state", as it will fail from 2023 onwards. To check this, try 
building the package after setting current_year to 2023 as in 
poc.diff.txt and you will see what happens next year.


Thanks.

[ p.s. I'm having a dejavu. Didn't I report something like this a few 
years ago? ]--- a/nanoc-core/spec/nanoc/core_spec.rb
+++ b/nanoc-core/spec/nanoc/core_spec.rb
@@ -3,8 +3,8 @@
 require 'nanoc/version'
 
 describe Nanoc::Core do
-  it 'has up-to-date version information' do
-current_year = Date.today.year
-expect(described_class.version_information).to match(/–#{current_year} /)
-  end
+#  it 'has up-to-date version information' do
+#current_year = Date.today.year
+#expect(described_class.version_information).to match(/–#{current_year} /)
+#  end
 end
--- a/nanoc-core/spec/nanoc/core_spec.rb
+++ b/nanoc-core/spec/nanoc/core_spec.rb
@@ -4,7 +4,7 @@ require 'nanoc/version'
 
 describe Nanoc::Core do
   it 'has up-to-date version information' do
-current_year = Date.today.year
+current_year = 2023
 expect(described_class.version_information).to match(/–#{current_year} /)
   end
 end

Bug#1025069: pipewire: audio broken, only says Dummy Output (on plain bookworm install)

[Patrice Duroux]

Hi,

I think it would be a shame to come to this: package conflict.

This means that on the same system, their users must exclusively use one same
software and sometimes leaving the decision to the root users (who may also
disagree themselves).
Ideally, it would be even more powerful Debian proposal if, in such a case,
users run whatever in parallel (and without pushing the problem to the container
side). I know that it is not always possible but to consider it is a (big) plus
to me. It also facilite comparison: one time with pulseaudio, one time with
pipewire, without the installing/purging danse. 

A documentation and/or a simple setting command to run that solves is a better
way to my opinion. Could a management script and making the switch be helpful?

Regards,
Patrice

On Tue, 29 Nov 2022 17:51:07 +0100 =?UTF-8?B?RHlsYW4gQcOvc3Np?=
 wrote:
> Hi,
> 
> Le mar. 29 nov. 2022 à 15:51, Hans-Christoph Steiner  a écrit :
> >
> > hans@delbin ~$ sudo journalctl | grep wire
> > ...
> > Nov 26 22:54:40 delbin wireplumber[1092]: stopped by signal: Terminated
> > Nov 26 22:54:40 delbin wireplumber[1092]: disconnected from pipewire
> >
> 
> > Versions of packages pipewire depends on:
> > ...
> > ii  pulseaudio    16.1+dfsg1-2+b1
> 
> I suspect it is a conflict between pulseaudio and pipewire-pulse and a
> duplicate of
> https://bugs.debian.org/1021530
> 
> Can you check if the pulseaudio service is running? If so, can you try
> to disable (and mask)
> pulseaudio service and socket and restart pipewire, pipewire-pulse and
> wireplumber
> services? These steps are describe at https://wiki.debian.org/PipeWire
> 
> If you are facing this conflict, you can also just remove the
> pulseaudio package. It looks
> like I really have to mark pipewire-pulse in conflict with pulseaudio.
> 
> Best,
> Dylan
> 
> 

Bug#1025095: ruby-azure-storage-common fails to rebuild after new upstream of ruby-faraday

[Vinay]

Package: ruby-azure-storage-common
Version: 2.0.1-5 


Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of 
ruby-azure-storage-common  fails

here is the log of the failed rebuild

┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-azure-storage-common/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"azure-storage-common\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (~> 1.0) among 
101 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-azure-storage-common/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/<>/debian/ruby-azure-storage-common/usr/share/rubygems-integration/all/specifications/azure-storage-common-2.0.1.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (~> 1.0) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-azure-storage-common/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'

Bug#1025094: ruby-behance fails to rebuild after new upstream of ruby-faraday

[Vinay]

Package: ruby-behance
Version:  0.6.1-4
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of ruby-behance  fails
here is the log of the failed rebuild


/usr/bin/ruby3.0 -S gem build --config-file /dev/null --verbose 
/tmp/d20221127-92714-fvg3fe/gemspec

Failed to load /dev/null because it doesn't contain valid YAML hash
WARNING:  licenses is empty, but is recommended.  Use a license 
identifier from

http://spdx.org/licenses or 'Nonstandard' for a nonstandard license.
WARNING:  description and summary are identical
WARNING:  open-ended dependency on faraday (>= 0.15) is not recommended
  if faraday is semantically versioned, use:
    add_runtime_dependency 'faraday', '~> 0.15'
WARNING:  open-ended dependency on faraday_middleware (>= 0.12.2) is not 
recommended

  if faraday_middleware is semantically versioned, use:
    add_runtime_dependency 'faraday_middleware', '~> 0.12', '>= 0.12.2'
WARNING:  See https://guides.rubygems.org/specification-reference/ for help
  Successfully built RubyGem
  Name: behance
  Version: 0.6.1
  File: behance-0.6.1.gem
/usr/bin/ruby3.0 -S gem install --config-file /dev/null --verbose 
--local --verbose --no-document --ignore-dependencies --install-dir 
debian/ruby-behance/usr/share/rubygems-integration/all 
/tmp/d20221127-92714-fvg3fe/behance-0.6.1.gem

Failed to load /dev/null because it doesn't contain valid YAML hash
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance.rb
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance/client.rb
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance/collections.rb
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance/creatives_to_follow.rb
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance/fields.rb
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance/project.rb
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance/user.rb
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance/version.rb
/<>/debian/ruby-behance/usr/share/rubygems-integration/all/gems/behance-0.6.1/lib/behance/wips.rb
Successfully installed behance-0.6.1
1 gem installed
cd debian/ruby-behance/usr/share/rubygems-integration/all
rm -rf bin
rm -rf build_info
rm -rf cache
rm -rf doc
rm -rf extensions
rmdir plugins
cd gems/behance-0.6.1
rm -f
chmod 644 lib/behance/client.rb lib/behance/collections.rb 
lib/behance/creatives_to_follow.rb lib/behance/fields.rb 
lib/behance/project.rb lib/behance/user.rb lib/behance/version.rb 
lib/behance/wips.rb lib/behance.rb

find lib/ -type d -empty -delete
cd -
cd -
dh_installchangelogs -pruby-behance /<>/CHANGELOG.md upstream
/usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner

┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-behance/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"behance\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:2248:in 
`raise_if_conflicts': Unable to activate faraday_middleware-1.0.0, 
because faraday-2.7.1 conflicts with faraday (~> 1.0) (Gem::ConflictError)
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1379:in 
`activate'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1417:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

Bug#1025080: enlightenment does not start

[Ross Vandegrift]

Control: tags -1 moreinfo

Hi Pierre,

I think you've misdiagnosed the problem.  How are you starting
enlightenment, and what error messages are you getting?  Also, please
provide the output of `dpkg -l dbus*` from your system.

enlightenment already has:
  Depends: default-dbus-session-bus | dbus-session-bus
See #836090 and the linked mailing list post for details on why this is
the right way to depend on dbus.

Ross

On Tue, Nov 29, 2022 at 06:05:41PM +0100, Pierre Couderc wrote:
> Package: enlightenment
> 
> Version: 0.24.2
> 
> Enlightenment does not start because dbus is not started.
> 
> dbus-x11 should be a dependency in case no session manager is used.
> 
> I recommend a enlightenment-x11 package or including x11 in enlightenment as
> nobody uses wayland...
> 
> Pierre Couderc
> 
> 

Bug#1025093: ruby-diaspora-federation fails to rebuild after new upstream of ruby-faraday

[Vinay]

Package: ruby-diaspora-federation
Version:  0.2.7-1
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of 
ruby-diaspora-federation  fails

here is the log of the failed rebuild

dpkg-buildpackage
-

Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot
dpkg-buildpackage: info: source package ruby-diaspora-federation
dpkg-buildpackage: info: source version 0.2.7-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Daniel Leidert 


 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean --buildsystem=ruby --with ruby
   dh_auto_clean -O--buildsystem=ruby
    dh_ruby --clean
   dh_autoreconf_clean -O--buildsystem=ruby
   dh_clean -O--buildsystem=ruby
 debian/rules binary
dh binary --buildsystem=ruby --with ruby
   dh_update_autotools_config -O--buildsystem=ruby
   dh_autoreconf -O--buildsystem=ruby
   dh_auto_configure -O--buildsystem=ruby
    dh_ruby --configure
   dh_auto_build -O--buildsystem=ruby
    dh_ruby --build
   dh_auto_test -O--buildsystem=ruby
    dh_ruby --test
   create-stamp debian/debhelper-build-stamp
   dh_testroot -O--buildsystem=ruby
   dh_prep -O--buildsystem=ruby
   dh_auto_install --destdir=debian/ruby-diaspora-federation/ 
-O--buildsystem=ruby

    dh_ruby --install /<>/debian/ruby-diaspora-federation
/usr/bin/ruby3.0 -S gem build --config-file /dev/null --verbose 
/tmp/d20221127-111310-i9dn91/gemspec

Failed to load /dev/null because it doesn't contain valid YAML hash
  Successfully built RubyGem
  Name: diaspora_federation
  Version: 0.2.7
  File: diaspora_federation-0.2.7.gem
/usr/bin/ruby3.0 -S gem install --config-file /dev/null --verbose 
--local --verbose --no-document --ignore-dependencies --install-dir 
debian/ruby-diaspora-federation/usr/share/rubygems-integration/all 
/tmp/d20221127-111310-i9dn91/diaspora_federation-0.2.7.gem

Failed to load /dev/null because it doesn't contain valid YAML hash
ERROR:  Error installing 
/tmp/d20221127-111310-i9dn91/diaspora_federation-0.2.7.gem:
    diaspora_federation-0.2.7 requires Ruby version ~> 2.1. The current 
ruby version is 3.0.4.
/usr/lib/ruby/vendor_ruby/gem2deb.rb:54:in `run': /usr/bin/ruby3.0 -S 
gem install --config-file /dev/null --verbose --local --verbose 
--no-document --ignore-dependencies --install-dir 
debian/ruby-diaspora-federation/usr/share/rubygems-integration/all 
/tmp/d20221127-111310-i9dn91/diaspora_federation-0.2.7.gem 
(Gem2Deb::CommandFailed)
    from /usr/lib/ruby/vendor_ruby/gem2deb/gem_installer.rb:213:in 
`run_gem'
    from /usr/lib/ruby/vendor_ruby/gem2deb/gem_installer.rb:121:in 
`block in install_files_and_build_extensions'

    from /usr/lib/ruby/vendor_ruby/gem2deb/gem_installer.rb:69:in `each'
    from /usr/lib/ruby/vendor_ruby/gem2deb/gem_installer.rb:69:in 
`install_files_and_build_extensions'

    from /usr/lib/ruby/vendor_ruby/gem2deb/installer.rb:28:in `build'
    from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:54:in `block in 
install'

    from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:52:in `each'
    from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:52:in `install'
    from /usr/lib/ruby/vendor_ruby/gem2deb/dh_ruby.rb:161:in `install'
    from /usr/bin/dh_ruby:89:in `'
dh_auto_install: error: dh_ruby --install 
/<>/debian/ruby-diaspora-federation returned exit code 1

make: *** [debian/rules:8: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2


Build finished at 2022-11-27T19:04:00Z

Finished



+--+
| Cleanup |
+--+

Purging /<>
Not cleaning session: cloned chroot in use
E: Build failure (dpkg-buildpackage died)

Bug#1023787: transition: liblxqt

[Paul Gevers]

Hi ChangZhuo,

On 29-11-2022 06:29, ChangZhuo Chen (陳昌倬) wrote:

Please help to
migrate libfm-qt in new queue [0] so that we can prepare the migration.


That's not under our control. You'll need to talk to ftp-master 
(typically a note with explanation on IRC helps).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1014136: golang-mongodb-mongo-driver FTBFS due to failing tests

[Guillem Jover]

Control: tag -1 moreinfo unreproducible

On Thu, 2022-06-30 at 13:25:36 -0500, William 'jawn-smith' Wilson wrote:
> Package: golang-mongodb-mongo-driver
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu kinetic ubuntu-patch

> There was already a patch in this package to skip tests that require
> a running mongodb instance. The latest upstream release added more
> tests with this requirement, so I added logic to skip them to the
> already existing patch
> 
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Resolve FTBFS by Skiping more tests that require a running mongodb 
> instance

I have no mongodb running and when building there's no build failure,
so I think I'm not understanding what this is trying to fix? This
definitely does not FTBFS in Debian.

Thanks,
Guillem

Bug#1025092: ruby-faraday-middleware fails to rebuild after updating ruby-faraday

[Vinay]

Package: ruby-faraday-middleware
Version:  1.0.0-2
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of 
ruby-faraday-middleware fails

here is the log of the failed rebuild

┌──┐
│ Install Rubygems integration 
metadata    │

└──┘

generating gemspec at 
/<>/debian/ruby-faraday-middleware/usr/share/rubygems-integration/all/specifications/faraday_middleware-1.0.0.gemspec

/usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner

┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-faraday-middleware/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"faraday_middleware\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (~> 1.0) among 
114 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-faraday-middleware/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/<>/debian/ruby-faraday-middleware/usr/share/rubygems-integration/all/specifications/faraday_middleware-1.0.0.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (~> 1.0) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-faraday-middleware/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

Bug#1025091: toot: Posting toots with media attachment fails

[gregor herrmann]

Package: toot
Version: 0.29.0-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I don't manage to post a toot with a photo:


% toot post -m ~/tmp/whatever.png -d "Some description" -p "My CW" -l deu 
--debug
Uploading media: /home/gregoa/tmp/whatever.png
DEBUG:toot:>>> POST https://chaos.social/api/v1/media
DEBUG:toot:>>> HEADERS: {('User-Agent', 'toot/0.29.0'), ('Authorization', 
'***CENSORED***')}
DEBUG:toot:>>> DATA:{'description': 'Some description'}
DEBUG:toot:>>> FILES:   {'file': <_io.BufferedReader 
name='/home/gregoa/tmp/whatever.png'>}
DEBUG:urllib3.connectionpool:Starting new HTTPS connection (1): chaos.social:443
DEBUG:urllib3.connectionpool:https://chaos.social:443 "POST /api/v1/media 
HTTP/1.1" 200 None
DEBUG:toot:<<< 
DEBUG:toot:<<< 
b'{"id":"109428449579345798","type":"image","url":"https://assets.chaos.social/media_attachments/files/109/428/449/579/345/798/original/426857e54bb13ae8.png","preview_url":"https://assets.chaos.social/media_attachments/files/109/428/449/579/345/798/small/426857e54bb13ae8.png","remote_url":null,"preview_remote_url":null,"text_url":null,"meta":{"original":{"width":630,"height":552,"size":"630x552","aspect":1.141304347826087},"small":{"width":512,"height":449,"size":"512x449","aspect":1.1403118040089086}},"description":"Some
 description","blurhash":"U5SY?ax]?cxu~qWBIUjFcsjF?HbIn%ayxukW"}'
Traceback (most recent call last):
  File "/usr/bin/toot", line 33, in 
sys.exit(load_entry_point('toot==0.29.0', 'console_scripts', 'toot')())
  File "/usr/lib/python3/dist-packages/toot/console.py", line 588, in main
run_command(app, user, command_name, args)
  File "/usr/lib/python3/dist-packages/toot/console.py", line 570, in 
run_command
return fn(app, user, parsed_args)
  File "/usr/lib/python3/dist-packages/toot/commands.py", line 103, in post
args.text = "\n".join(m['text_url'] for m in uploaded_media)
TypeError: sequence item 0: expected str instance, NoneType found


As far as I can guess from the debug output, toot expects something
in text_url the but reply from the server contains "text_url":null


chaos.social runs mastodon v4.0.2 (but I seem to remember seeing this
also before the upgrade).


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmOGTylfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgaCfhAAo8mjY7WG5YscVqBi8QJefRwQeJNJuyXhW8ImG5UwaZ7M3sbMFAdmIgz2
KCFKFfLOXj4yKgZflatlJ9gb9Z5+mrQ2ogvZ6Vy69yEyN3APUjO7CDsNIZV1b1VA
A7rdnVGREphN1TTscrzmiO5cWPBUJeYNNuoqAvXz0+dZOSvzEyDgHWVdh9b6oLvQ
T+OW9BH46EHc7yjPYgP07V5WW07k3XXcRZ6+ljmgWU6CLQbS9RFJ1tshEEcf9RMq
t/dbDj0RT5PBDmE3PfS2GCeNVGRXNYWvwhDFGFt2+7etgoyjqmQAsJbq5goqKiGa
T1eaC1418frnr/cHkhuAbdB8Xf8bJCxrpFanlquYqtxYJQjbhVNj+mdaETIIP+xH
LcOJbb+1kPcj97T8LaDf8XpNH0lDUF/m468PkksbfuD1IMZZAMjqeqaH4+IJQ1rB
Loy4J5tHUu6kCFO7chSiNThjRrhE8zdaUNFzubbhup5ZdV56v2o7CdiuLJYF4rxF
LT8+jXsMcYmO3h7UuHHbtk2tfrcvbhBQqg8XlrMYVkXMUYvhaFz2dhYRnlISeHrE
34BrXVi8bd3T3D1A3R0CV2KmGuP6w2x7bHyXADnSDzWmc2BIdeNEs9tjvbx2QPGj
j54dPDT0zrB/E/82Hb6a/uXJ7Bifv6IZ6gY0h8rvfW+L4bUj9qs=
=Net+
-END PGP SIGNATURE-

Bug#1025090: ruby-gh fails to rebuild on updating ruby-faraday

[Vinay]

Package: ruby-gh
Version:  0.18.0-4
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of ruby-gh fails
here is the log of the failed rebuild

┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-gh/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"gh\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (~> 1.0) among 
119 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-gh/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/<>/debian/ruby-gh/usr/share/rubygems-integration/all/specifications/gh-0.18.0.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (~> 1.0) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-gh/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'

Bug#1025089: ruby-github-api fails to rebuild after updating ruby-faraday

[Vinay]

Package: ruby-github-api
Version:  0.19.0-1
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of ruby-github-api 
fails

here is the log of the failed rebuild

┌──┐
│ Install Rubygems integration 
metadata    │

└──┘

generating gemspec at 
/<>/debian/ruby-github-api/usr/share/rubygems-integration/all/specifications/github_api-0.19.0.gemspec
dh_installchangelogs -pruby-github-api /<>/CHANGELOG.md 
upstream

/usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner

┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-github-api/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"github_api\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (< 2, >= 0.8) 
among 107 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-github-api/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/<>/debian/ruby-github-api/usr/share/rubygems-integration/all/specifications/github_api-0.19.0.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (< 2, >= 0.8) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-github-api/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'

Bug#1025088: ruby-googleauth fails to rebuild after updating

[Vinay]

Package: ruby-googleauth
Version:  0.13.0-3
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of ruby-googleauth 
fails

here is the log of the failed rebuild



GEM_PATH=/<>/debian/ruby-googleauth/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"googleauth\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (>= 0.17.3, < 
2.0) among 136 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-googleauth/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/<>/debian/ruby-googleauth/usr/share/rubygems-integration/all/specifications/googleauth-0.13.0.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (>= 0.17.3, < 2.0) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-googleauth/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
abbrev (default: 0.1.0)

Bug#1025087: ruby-google-cloud-env fails to rebuild after

[Vinay]

Package: ruby-google-cloud-env
Version:   1.3.2-1
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of 
ruby-google-cloud-env fails

here is the log of the failed rebuild


┌──┐
│ Install files │
└──┘

install -d 
/<>/debian/ruby-google-cloud-env/usr/lib/ruby/vendor_ruby
install -D -m644 /<>/lib/google/cloud/env/version.rb 
/<>/debian/ruby-google-cloud-env/usr/lib/ruby/vendor_ruby/google/cloud/env/version.rb
install -D -m644 /<>/lib/google/cloud/env.rb 
/<>/debian/ruby-google-cloud-env/usr/lib/ruby/vendor_ruby/google/cloud/env.rb
install -D -m644 /<>/lib/google-cloud-env.rb 
/<>/debian/ruby-google-cloud-env/usr/lib/ruby/vendor_ruby/google-cloud-env.rb


┌──┐
│ Install Rubygems integration 
metadata    │

└──┘

generating gemspec at 
/<>/debian/ruby-google-cloud-env/usr/share/rubygems-integration/all/specifications/google-cloud-env-1.3.2.gemspec
dh_installchangelogs -pruby-google-cloud-env 
/<>/CHANGELOG.md upstream

/usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner

┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-google-cloud-env/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"google-cloud-env\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (< 2.0, >= 
0.17.3) among 96 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-google-cloud-env/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/<>/debian/ruby-google-cloud-env/usr/share/rubygems-integration/all/specifications/google-cloud-env-1.3.2.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (< 2.0, >= 0.17.3) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-google-cloud-env/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'

Bug#1025086: sudoku: diff for NMU version 1.0.5-2.1

[Boyuan Yang]

Package: sudoku
Version: 1.0.5-2
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for sudoku (versioned as 1.0.5-2.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru sudoku-1.0.5/debian/changelog sudoku-1.0.5/debian/changelog
--- sudoku-1.0.5/debian/changelog   2015-04-28 17:02:13.0 -0400
+++ sudoku-1.0.5/debian/changelog   2022-11-29 13:06:19.0 -0500
@@ -1,3 +1,13 @@
+sudoku (1.0.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/menu: Dropped per tech-ctte decision.
+  * debian/control: Fix invalid Vcs-* fields.
+  * debian/control: Replace transitional package libncurses5-dev
+with real package libncurses-dev.
+
+ -- Boyuan Yang   Tue, 29 Nov 2022 13:06:19 -0500
+
 sudoku (1.0.5-2) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru sudoku-1.0.5/debian/control sudoku-1.0.5/debian/control
--- sudoku-1.0.5/debian/control 2015-04-19 03:14:36.0 -0400
+++ sudoku-1.0.5/debian/control 2022-11-29 13:06:18.0 -0500
@@ -2,11 +2,11 @@
 Section: games
 Priority: optional
 Maintainer: Peter Spiess-Knafl 
-Build-Depends: debhelper (>= 9), libncurses5-dev, librsvg2-bin, imagemagick
+Build-Depends: debhelper (>= 9), libncurses-dev, librsvg2-bin, imagemagick
 Standards-Version: 3.9.6
 Homepage: https://github.com/cinemast/sudoku
-Vcs-Git: git://anonscm.debian.org/collab-maint/sudoku.git
-Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/sudoku.git
+Vcs-Git: https://salsa.debian.org/debian/sudoku.git
+Vcs-Browser: https://salsa.debian.org/debian/sudoku
 
 Package: sudoku
 Architecture: any
diff -Nru sudoku-1.0.5/debian/menu sudoku-1.0.5/debian/menu
--- sudoku-1.0.5/debian/menu2015-04-18 19:03:32.0 -0400
+++ sudoku-1.0.5/debian/menu1969-12-31 19:00:00.0 -0500
@@ -1,7 +0,0 @@
-?package(sudoku):needs="text" \
-section="Games/Strategy" \
-title="Sudoku" \
-longtitle="Sudoku - console based figure puzzle" \
-command="/usr/games/sudoku" \
-icon="/usr/share/pixmaps/sudoku.xpm"
-


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

Bug#1025085: ruby-google-cloud-translate breaks after updating ruby-faraday

[Vinay]

Package: ruby-google-cloud-translate
Version:  1.3.0-2
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of 
ruby-google-cloud-translate fails

here is the log of the failed rebuild

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 sbuild-build-depends-main-dummy : Depends: ruby-googleauth (< 0.10.0) 
but 0.13.0-3 is to be installed

E: Unable to correct problems, you have held broken packages.
apt-get failed.
E: Package installation failed
Not removing build depends: cloned chroot in use

Setup apt archive
-

Merged Build-Depends: dose-distcheck
Filtered Build-Depends: dose-distcheck
dpkg-deb: building package 'sbuild-build-depends-dose3-dummy' in 
'/<>/apt_archive/sbuild-build-depends-dose3-dummy.deb'.

Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [586 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [1310 B]
Get:5 copy:/<>/apt_archive ./ Packages [1378 B]
Fetched 3274 B in 0s (0 B/s)
Reading package lists...
Get:1 file:/<>/resolver-pT0rDw/apt_archive ./ InRelease
Ign:1 file:/<>/resolver-pT0rDw/apt_archive ./ InRelease
Get:2 file:/<>/resolver-pT0rDw/apt_archive ./ Release [577 B]
Get:2 file:/<>/resolver-pT0rDw/apt_archive ./ Release [577 B]
Get:3 file:/<>/resolver-pT0rDw/apt_archive ./ Release.gpg
Ign:3 file:/<>/resolver-pT0rDw/apt_archive ./ Release.gpg
Reading package lists...
Reading package lists...

Install dose3 build dependencies (apt-based resolver)
-

Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  dose-distcheck
The following NEW packages will be installed:
  dose-distcheck sbuild-build-depends-dose3-dummy
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 1066 kB/1067 kB of archives.
After this operation, 4362 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian unstable/main amd64 dose-distcheck 
amd64 7.0.0-1+b1 [1066 kB]

debconf: delaying package configuration, since apt-utils is not installed
Fetched 1066 kB in 1s (1259 kB/s)
Selecting previously unselected package dose-distcheck.
(Reading database ... 12569 files and directories currently installed.)
Preparing to unpack .../dose-distcheck_7.0.0-1+b1_amd64.deb ...
Unpacking dose-distcheck (7.0.0-1+b1) ...
Selecting previously unselected package sbuild-build-depends-dose3-dummy.
Preparing to unpack 
.../sbuild-build-depends-dose3-dummy_0.invalid.0_amd64.deb ...

Unpacking sbuild-build-depends-dose3-dummy (0.invalid.0) ...
Setting up dose-distcheck (7.0.0-1+b1) ...
Setting up sbuild-build-depends-dose3-dummy (0.invalid.0) ...
(I)Doseparse: Parsing and normalizing...
(I)Dose_deb: Parsing Packages file -...
(I)Dose_common: total packages 67732
(I)Dose_applications: Cudf Universe: 67732 packages
(I)Dose_applications: --checkonly specified, consider all packages as 
background packages

(I)Dose_applications: Solving...
output-version: 1.2
native-architecture: amd64
report:
 -
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  status: broken
  reasons:
   -
    missing:
 pkg:
  package: sbuild-build-depends-main-dummy
  version: 0.invalid.0
  architecture: amd64
  unsat-dependency: ruby-googleauth:amd64 (< 0.10.0)

background-packages: 67731
foreground-packages: 1
total-packages: 67732
broken-packages: 1

+--+
| Cleanup |
+--+

Purging /<>
Not cleaning session: cloned chroot in use
E: Package build dependencies not satisfied; skipping

Bug#1025084: ruby-graphlient fails to rebuild after updating ruby-faraday to upstream

[Vinay]

Package: ruby-graphlient
Version:  0.5.0-3
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of ruby-graphlient 
fails

here is the log of the failed rebuild

cd gems/graphlient-0.5.0
rm -f
chmod 644 lib/graphlient/adapters/http/adapter.rb 
lib/graphlient/adapters/http/faraday_adapter.rb 
lib/graphlient/adapters/http/http_adapter.rb 
lib/graphlient/adapters/http.rb lib/graphlient/adapters.rb 
lib/graphlient/client.rb lib/graphlient/errors/client_error.rb 
lib/graphlient/errors/connection_failed_error.rb 
lib/graphlient/errors/error.rb lib/graphlient/errors/execution_error.rb 
lib/graphlient/errors/faraday_server_error.rb 
lib/graphlient/errors/graphql_error.rb 
lib/graphlient/errors/http_options_error.rb 
lib/graphlient/errors/http_server_error.rb 
lib/graphlient/errors/server_error.rb 
lib/graphlient/errors/timeout_error.rb lib/graphlient/errors.rb 
lib/graphlient/extensions/query.rb lib/graphlient/extensions.rb 
lib/graphlient/query.rb lib/graphlient/schema.rb 
lib/graphlient/version.rb lib/graphlient.rb

find lib/ -type d -empty -delete
cd -
cd -
dh_installchangelogs -pruby-graphlient /<>/CHANGELOG.md 
upstream

/usr/bin/ruby3.0 /usr/bin/gem2deb-test-runner

┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-graphlient/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.0.0:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"graphlient\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:2248:in 
`raise_if_conflicts': Unable to activate faraday_middleware-1.0.0, 
because faraday-2.7.1 conflicts with faraday (~> 1.0) (Gem::ConflictError)
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1379:in 
`activate'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1417:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
abbrev (default: 0.1.0)
activesupport (6.1.7)
addressable (2.8.0)

Bug#1025083: bullseye-pu: package omnievents/1:2.6.2-5.1+deb11u1

[Guilherme de Paula Xavier Segundo]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: guilherme@gmail.com


[ Reason ]
This is not a regression, but a discovered bug.

omnievents enables CORBA applications to communicate through asynchronous
broadcast channels rather than direct method calls.

omnievents-doc is a package that can be installed as a suggestion of
omnievents containing the documentation of package, but which cannot be fully
used due to broken symlink.

[ Impact ]
If not approved, the package documentation cannot be used in its entirety.

[ Tests ]
The package has been tested in stable, testing and unstable versions. Tests
using pipuparts were made using '--fail-on-broken-symlinks' option and after
the correction the problem was no longer found.

The command used in the test was:

# piuparts --fail-on-broken-symlinks omnievents-doc_2.6.2-5.1+deb11u1_all.deb

[ Risks ]
This is a trivial change, no risks.

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

[ Changes ]
The fix was made in the debian/control file by adding the 'libjs-jquery'
dependency to the 'omnievents-doc' package.
Please, see the debdiff.

[ Other info ]
No more information.
diff -Nru omnievents-2.6.2/debian/changelog omnievents-2.6.2/debian/changelog
--- omnievents-2.6.2/debian/changelog   2021-01-09 07:59:32.0 -0300
+++ omnievents-2.6.2/debian/changelog   2022-11-28 17:20:30.0 -0300
@@ -1,3 +1,12 @@
+omnievents (1:2.6.2-5.1+deb11u1) bullseye; urgency=medium
+
+  * debian/control: Added 'libjs-jquery' as a dependency of 'omnievents-doc'
+to fix broken symlinks that prevent reading part of the documentation.
+.
+Closes: #989339
+
+ -- Guilherme de Paula Xavier Segundo   Mon, 28 Nov 
2022 17:20:30 -0300
+
 omnievents (1:2.6.2-5.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru omnievents-2.6.2/debian/control omnievents-2.6.2/debian/control
--- omnievents-2.6.2/debian/control 2016-07-23 17:11:03.0 -0300
+++ omnievents-2.6.2/debian/control 2022-11-28 17:20:30.0 -0300
@@ -45,7 +45,8 @@
 Package: omnievents-doc
 Architecture: all
 Section: doc
-Depends: ${misc:Depends}
+Depends: ${misc:Depends},
+ libjs-jquery
 Description: omniORB event service documentation
  This package contains omniEvents manual and doxygen generated documentation.
  .

Bug#1025082: ruby-oauth2 rebuild fails after new upstream of ruby-faraday

[Vinay]

Package: ruby-oauth2
Version:  1.4.4-1
Severity: important

Dear Maintainer,

While updating ruby-faraday to new upstream, rebuild of ruby-oauth2 fails
here is the log of the failed rebuild


┌──┐
│ Checking Rubygems dependency resolution on 
ruby3.0   │

└──┘

GEM_PATH=/<>/debian/ruby-oauth2/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0 
ruby3.0 -e gem\ \"oauth2\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1413:in `rescue in 
block in activate_dependencies': Could not find 'faraday' (>= 0.8, < 
2.0) among 125 total gem(s) (Gem::MissingSpecError)
Checked in 
'GEM_PATH=/<>/debian/ruby-oauth2/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
at: 
/<>/debian/ruby-oauth2/usr/share/rubygems-integration/all/specifications/oauth2-1.4.4.gemspec, 
execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1410:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'
/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:313:in `to_specs': 
Could not find 'faraday' (>= 0.8, < 2.0) - did find: [faraday-2.7.1] 
(Gem::MissingSpecVersionError)
Checked in 
'GEM_PATH=/<>/debian/ruby-oauth2/usr/share/rubygems-integration/all:/var/lib/gems/3.0.0:/usr/local/lib/ruby/gems/3.0.0:/usr/lib/ruby/gems/3.0.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.0.0:/usr/share/rubygems-integration/3.0.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.0.0' 
, execute `gem env` for more information
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1411:in 
`block in activate_dependencies'

    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in `each'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1399:in 
`activate_dependencies'
    from /usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1381:in 
`activate'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `block 
in gem'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in 
`synchronize'
    from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_gem.rb:68:in `gem'

    from -e:1:in `'

Bug#1010371: gav: Source moved to GitHub

[Bastian Germann]

Control: retitle -1 gav: New upstream version available

I have updated the package to contain a watch file that scans the GitHub 
project.
There is a new release available. Please import it.

Bug#1024136: 798672 – Preferences are not saved nor loaded, ERROR g_settings_new_full: assertion 'schema != NULL' failed

[scar]

We found the problem upstream!

See [1] <#1>, especially Comments 5-7[2] <#2>, and the patch[3] <#3>.


1. https://bugs.gnucash.org/show_bug.cgi?id=798672

2. https://bugs.gnucash.org/show_bug.cgi?id=798672#c5

3. 
https://github.com/Gnucash/gnucash/commit/98251d59a6e6940efae2001a1e619c08828c8738

Bug#1025081: dnsdist: Please add support for "riscv64" arch

[Manuel A. Fernandez Montecelo]

Source: dnsdist
Version: 1.7.3-1
Severity: wishlist
Tags: ftbfs patch
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: m...@debian.org, debian-ri...@lists.debian.org

Hi,

Please enable this architecture, with the patch attached or an equivalent.

I built it locally on hardware, it built fine just by enabling the architecture
in debian/control, no other changes needed.


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
diff -Nru dnsdist-1.7.3/debian/changelog dnsdist-1.7.3/debian/changelog
--- dnsdist-1.7.3/debian/changelog  2022-11-01 22:35:46.0 +
+++ dnsdist-1.7.3/debian/changelog  2022-11-28 21:45:40.0 +
@@ -1,3 +1,10 @@
+dnsdist (1.7.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add support for riscv64 arch
+
+ -- Manuel A. Fernandez Montecelo   Mon, 28 Nov 2022 21:45:40 
+
+
 dnsdist (1.7.3-1) unstable; urgency=medium
 
   * New upstream version 1.7.3
diff -Nru dnsdist-1.7.3/debian/control dnsdist-1.7.3/debian/control
--- dnsdist-1.7.3/debian/control2022-11-01 22:35:46.0 +
+++ dnsdist-1.7.3/debian/control2022-11-28 21:45:40.0 +
@@ -31,7 +31,7 @@
 Rules-Requires-Root: no
 
 Package: dnsdist
-Architecture: amd64 arm64 mips64el ppc64el s390x
+Architecture: amd64 arm64 mips64el ppc64el riscv64 s390x
 Pre-Depends: ${misc:Pre-Depends}
 Depends: adduser,
  ${misc:Depends},