Bug#993287: "apt-get install" doesn't preserve autoinstall status of upgraded packages

[Esa Peuha]

On Mon, Aug 30, 2021 at 2:06 PM David Kalnischkies
 wrote:
>
> On Mon, Aug 30, 2021 at 11:27:47AM +0300, Esa Peuha wrote:
> > what has happened until recently. However, since apt 2.3.3 foo will be
> > marked as manually installed, which seems to be an unintended change.
>
> What makes you believe apt before 2.3.3 behaved differently?

Maybe apt didn't, but apt-get certainly did; I tested this by
downloading several versions of apt and libapt-pkg6.0 from
snapshot.debian.org and installing them on a live system. The
difference I see in apt-get is between 2.3.2 and 2.3.3.

> I tried with 2.3.2 and 1.3 (= the first release with CMake buildsystem)
> and both exhibit the behaviour you describe as an unintended change…
> (attached is a testcase akin to what Julian described were in both
> blocks the second apt-mark showmanual call fails as foo is now manual)

That test uses apt instead of apt-get, though. I never use apt myself,
so I didn't even think of finding out what it does.

Bug#956283: installation-reports: kinda successful installation, but issues with firmware

[Bob McGowan]

Package: installation-reports
Followup-For: Bug #956283
X-Debbugs-Cc: ramjr0...@gmail.com

Installation and reboot completed successfully, but running the new system 
failed on login to the GUI, due to
missing firmware.

I needed to install two firmware packages in order to successfully login 
through the GUI:

  firmware-amd-graphics
  firmware-misc-nonfree


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux beholder 5.10.0-8-amd64 #1 SMP Debian 5.10.46-3 (2021-07-28) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Root Complex [1022:15d0]
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:18f1]
lspci -knn: 00:00.2 IOMMU [0806]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 IOMMU [1022:15d1]
lspci -knn: Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
IOMMU [1022:15d1]
lspci -knn: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
lspci -knn: 00:01.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:01.7 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 PCIe GPP Bridge [6:0] [1022:15d3]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Family 17h (Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
lspci -knn: 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus A [1022:15db]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Internal PCIe GPP Bridge 0 to Bus B [1022:15dc]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus 
Controller [1022:790b] (rev 61)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:18f1]
lspci -knn: 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH 
LPC Bridge [1022:790e] (rev 51)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:18f1]
lspci -knn: 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Device 24: Function 0 [1022:15e8]
lspci -knn: 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Device 24: Function 1 [1022:15e9]
lspci -knn: 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Device 24: Function 2 [1022:15ea]
lspci -knn: 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Device 24: Function 3 [1022:15eb]
lspci -knn: 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Device 24: Function 4 [1022:15ec]
lspci -knn: 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Device 24: Function 5 [1022:15ed]
lspci -knn: 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Device 24: Function 6 [1022:15ee]
lspci -knn: 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] 
Raven/Raven2 Device 24: Function 7 [1022:15ef]
lspci -knn: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU117M 
[GeForce GTX 1650 Mobile / Max-Q] [10de:1f91] (rev a1)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:10cf]
lspci -knn: 01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:10fa] 
(rev a1)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:10cf]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
lspci -knn: Subsystem: ASUSTeK Computer Inc. Device [1043:208f]
lspci -knn: Kernel driver in use: r8169
lspci -knn: Kernel modules: r8169
lspci -knn: 03:00.0 Non-Volatile memory controller [0108]: Intel Corporation 
SSD 660P Series [8086:f1a8] (rev 03)
lspci -knn: DeviceName: Onboard LAN Brodcom
lspci -knn: Subsystem: Intel Corporation Device [8086:390d]
lspci -knn: Kernel driver in use: nvme
lspci -knn: Kernel modules: nvme

Bug#993346: pytest-mock: please upgrade to latest upstream release

[Sandro Tosi]

Source: pytest-mock
Severity: important
X-Debbugs-Cc: jpu...@debian.org

Hello,
pytest-mock is severely outdated, and the latest version of python-anyio
requires at least version 1.11.1 (due to how the code was reorganized in that
version, see commit 4a661d53656cd9935f776f92a6bc2dc3ee97f642).

Please upgrade pytest-mock to the latest version; if you're short on time,
please let me know and i can take care of the upgrade & upload.

Regards,
Sandro


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

Kernel: Linux 5.10.0-8-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#993341: libusbguard0 has no -dev counterpart (which is needed for building usbguard-notifier)

[KOLANICH]

Package: libusbguard0
Version: 1.0.0+ds-2

Bug#993340: libqt5xml5 has no -dev counterpart (which is needed for libkf5texteditor-dev )

[KOLANICH]

Package: qtbase-opensource-src
Version: 5.15.2+dfsg-10

Bug#993334: gdal: FTBFS: configure.ac: error: required file 'config.rpath' not found

[Sebastiaan Couwenberg]

Control: tags -1 upstream pending
Control: forwarded -1 https://github.com/OSGeo/gdal/issues/4341

On 8/30/21 11:22 PM, Niko Tyni wrote:
> This package fails to build from source on current sid.
> 
>>From a build log:
> 
>configure.ac:5590: warning: The macro `AC_CHECKING' is obsolete.
>configure.ac:5590: You should run autoupdate.
>./lib/autoconf/general.m4:2499: AC_CHECKING is expanded from...
>configure.ac:5590: the top level
>configure.ac:6030: warning: AC_OUTPUT should be used without arguments.
>configure.ac:6030: You should run autoupdate.
>configure.ac: error: required file 'config.rpath' not found
>dh_autoreconf: error: autoreconf -f -i returned exit code 1
>make: *** [debian/rules:100: build] Error 25
>dpkg-buildpackage: error: debian/rules build subprocess returned exit 
> status 2

This is a know issue, and a workaround has already been committed in git.

The recent removal of the deprecated RPC support in glibc created an
issue in libdap [0] and ogdi-dfsg [1] which both cause gdal to FTBFS
too. These need to be fixed as well before a new upload of gdal can happen.

[0] https://bugs.debian.org/993016
[1] https://github.com/libogdi/ogdi/issues/20

Kind Regards,

Bas

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

Bug#980136: ITP: zutty -- high-end terminal for low-end systems

[Sergio Cipriano]

retitle 980136 ITP: zutty -- high-end terminal for low-end systems

owner 980136 !

--
Cheers,
Sérgio Cipriano.

Bug#993345: debhelper: Regression: Undefined subroutine ::Debhelper::Buildsystem::cmake::get_buildoption

[Boyuan Yang]

Package: debhelper
Version: 13.5
Severity: grave
X-Debbugs-CC: ni...@thykier.net

A regression appears when upgrading from debhelper/13.4.1 to debhelper/13.5:

% dh_auto_test --buildsystem=cmake
Undefined subroutine ::Debhelper::Buildsystem::cmake::get_buildoption
called at /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm line 175.

See https://buildd.debian.org/status/package.php?p=wbxml2 for real example.

-- 
Thanks,
Boyuan Yang


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

Bug#337086: provide a link to the Debian Security Manual

[Marco Villegas]

It seems like the mentioned link[1] is not working anymore, and looking
around a bit it seems to be at [2] now instead.

I was thinking about the right place to add the link to.
Even if there are some sections related to security, namely _Security
uploads_ and _Handling security-related bugs_, they are only
tangentially related to the contents for the linked resource.

Hence, instead of adding it to an existing section, I have created a new
one inside the _Best Packaging Practices_ section. This could also be
useful if more information about security, or other links are wanted to
be added in the future. The change is available at [3].

1: http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html
2: https://www.debian.org/doc/manuals/securing-debian-manual/ch09.en.html
3: https://salsa.debian.org/debian/developers-reference/-/merge_requests/30

-Marco

Bug#993177: RFS: dtkwidget/5.5.17.1-1~exp1 -- dtkwidget-examples is generated by dtkwidget

[Adam Borowski]

On Tue, Aug 31, 2021 at 09:12:52AM +0800, clay stan wrote:
> Adam Borowski  于2021年8月30日周一 下午4:17写道：
> > On Sat, Aug 28, 2021 at 08:12:20PM +0800, clay stan wrote:
> > >  * Package name: dtkwidget
> > >Version : 5.5.17.1-1~exp1
> >
> > >  dtkwidget (5.5.17.1-1~exp1) experimental; urgency=medium
> > >  .
> > >* New upstream version 5.5.17.1.
> >
> > Alas, this one needs its symbols updated.
> 
> Are there any problems with the current symbols?
> Compared with the previous version - 5.4.1-1~exp1, I have updated the
> symbols file
> And Lintian did not report any problems with symbols when I compiled it.

Looks like your version of symbols is ok for gcc-10, but will fail for
gcc-11.  I guess we can worry once gcc default is bumped.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#993339: Package: reprotest Debian Salsa reprotest fails due to different compile times

[Christopher Talbot]

Hello!

Thank you for responding so fast.

On Mon, 2021-08-30 at 18:00 -0700, Vagrant Cascadian wrote:
> On 2021-08-30, Christopher Talbot wrote:
> > Debian Salsa seems to fail reprotest due to different compile
> > times.
> ...
> > One recent example is here:
> > https://salsa.debian.org/DebianOnMobile-team/vvmd/-/pipelines/283265
> > 
> > When looking at the debs with diffoscope, I get example output like
> > below (it happens with several files, I only included one for
> > brevity):
> > 
> > -drwxr-xr-x   0 root (0) root (0)    0 2021-08-
> > 30
> > 22:22:16.00 ./
> > │ │ │ -drwxr-xr-x   0 root (0) root (0)    0
> > 2021-
> > 08-30 22:22:15.00 ./usr/
> > │ │ │ -drwxr-xr-x   0 root (0) root (0)    0
> > 2021-
> > 08-30 22:22:16.00 ./usr/bin/
> > │ │ │ --rwxr-xr-x   0 root (0) root (0)   119928
> > 2021-
> > 08-30 22:22:16.00 ./usr/bin/vvmd
> ...
> > 08-30 22:22:24.00 ./usr/
> > │ │ │ +drwxr-xr-x   0 root (0) root (0)    0
> > 2021-
> > 08-30 22:22:25.00 ./usr/bin/
> > │ │ │ +-rwxr-xr-x   0 root (0) root (0)   119928
> > 2021-
> > 08-30 22:22:25.00 ./usr/bin/vvmd
> 
> > In osk-sdl, it seemed to be fixed by running it a day later.
> > https://salsa.debian.org/DebianOnMobile-team/osk-sdl/-/jobs/1821885
> 
> Hrm. That sounds suspicious...
> 
> I'm unable to reproduce this locally with reprotest against a vvmd or
> osk-sdl git checkout. Maybe this has something to do with how salsaci
> is
> setting up the directory... ? Maybe it unpacks the .orig.tar.* in
> some
> way that alters the timestamps?
> 
> But that *should* be fixed by dpkg's SOURCE_DATE_EPOCH handling when
> it
> generates the .deb ... hrm.
> 
> Maybe when the job was first run, SOURCE_DATE_EPOCH was set to a date
> later than the file unpack times (e.g. maybe due to timezone?)... and
> thus wouldn't clamp the timestamps ... that might explain re-running
> the
> job later suceeding.
> 
> 
> live well,
>   vagrant

Unfortunately, I do not know enough about reprotest to know what causes
it.

On a hunch, I also decided to rerun reprotest, and it worked this time:

https://salsa.debian.org/DebianOnMobile-team/vvmd/-/pipelines/283265

So it seems to be some sort of time/date dependent bug?

Respectfully,
Chris Talbot

Bug#993343: OpenLDAP 2.5 FTBFS on GNU/Hurd: MAXPATHLEN undeclared

[Ryan Tandy]

Source: openldap
Version: 2.5.5+dfsg-1~exp1
Severity: important
Tags: upstream ftbfs help
Forwarded: https://bugs.openldap.org/show_bug.cgi?id=9658

https://buildd.debian.org/status/fetch.php?pkg=openldap=hurd-i386=2.5.5%2Bdfsg-1%7Eexp1=1623486618=0

libtool: compile:  cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c 
request.c  -fPIC -DPIC -o .libs/request.o
In file included from ldap-int.h:119,
from request.c:53:
request.c: In function 'ldap_dump_connection':
../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in 
this function)
 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH="))
 | ^~
request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN'
 859 |charfrom[LDAP_IPADDRLEN];
 | ^~
../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported 
only once for each function it appears in
 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH="))
 | ^~
request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN'
 859 |charfrom[LDAP_IPADDRLEN];
 | ^~
Makefile:435: recipe for target 'request.lo' failed
make[2]: *** [request.lo] Error 1

I confirmed locally that current git master is still affected.

It's well-known that GNU/Hurd doesn't provide MAXPATHLEN.
https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL

I don't have the bandwidth to work on this myself. It would be great if 
someone from the Hurd community could look at it.


thanks
Ryan

Bug#993177: RFS: dtkwidget/5.5.17.1-1~exp1 -- dtkwidget-examples is generated by dtkwidget

[clay stan]

Adam Borowski  于2021年8月30日周一 下午4:17写道：
>
> On Sat, Aug 28, 2021 at 08:12:20PM +0800, clay stan wrote:
> >  * Package name: dtkwidget
> >Version : 5.5.17.1-1~exp1
>
> >  dtkwidget (5.5.17.1-1~exp1) experimental; urgency=medium
> >  .
> >* New upstream version 5.5.17.1.
>
> Alas, this one needs its symbols updated.

Are there any problems with the current symbols?
Compared with the previous version - 5.4.1-1~exp1, I have updated the
symbols file
And Lintian did not report any problems with symbols when I compiled it.

Regards,
--
  clay stan

>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
> ⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
> ⠈⠳⣄

Bug#993339: Package: reprotest Debian Salsa reprotest fails due to different compile times

[Vagrant Cascadian]

On 2021-08-30, Christopher Talbot wrote:
> Debian Salsa seems to fail reprotest due to different compile times.
...
> One recent example is here:
> https://salsa.debian.org/DebianOnMobile-team/vvmd/-/pipelines/283265
>
> When looking at the debs with diffoscope, I get example output like
> below (it happens with several files, I only included one for brevity):
>
> -drwxr-xr-x   0 root (0) root (0)0 2021-08-30
> 22:22:16.00 ./
> │ │ │ -drwxr-xr-x   0 root (0) root (0)0 2021-
> 08-30 22:22:15.00 ./usr/
> │ │ │ -drwxr-xr-x   0 root (0) root (0)0 2021-
> 08-30 22:22:16.00 ./usr/bin/
> │ │ │ --rwxr-xr-x   0 root (0) root (0)   119928 2021-
> 08-30 22:22:16.00 ./usr/bin/vvmd
...
> 08-30 22:22:24.00 ./usr/
> │ │ │ +drwxr-xr-x   0 root (0) root (0)0 2021-
> 08-30 22:22:25.00 ./usr/bin/
> │ │ │ +-rwxr-xr-x   0 root (0) root (0)   119928 2021-
> 08-30 22:22:25.00 ./usr/bin/vvmd

> In osk-sdl, it seemed to be fixed by running it a day later.
> https://salsa.debian.org/DebianOnMobile-team/osk-sdl/-/jobs/1821885

Hrm. That sounds suspicious...

I'm unable to reproduce this locally with reprotest against a vvmd or
osk-sdl git checkout. Maybe this has something to do with how salsaci is
setting up the directory... ? Maybe it unpacks the .orig.tar.* in some
way that alters the timestamps?

But that *should* be fixed by dpkg's SOURCE_DATE_EPOCH handling when it
generates the .deb ... hrm.

Maybe when the job was first run, SOURCE_DATE_EPOCH was set to a date
later than the file unpack times (e.g. maybe due to timezone?)... and
thus wouldn't clamp the timestamps ... that might explain re-running the
job later suceeding.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#993331: JPEG2000/JP2 support missing

[Norbert Preining]

Hi Manuel,

thanks for your report and detailed explanations.

On Mon, 30 Aug 2021, Manuel Geißer wrote:
> built with JasPer, which would first require packaging the latter in Debian.

Yes, that is the first step. There has been a jasper package back in
Jessie times but it seems it has been removed.

Unfortunately, the qt5-image-formats-plugins sources don't support
openjp2 library, and only accept jasper.

I am not sure whether we want to package jasper here in the Qt/KDE team.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#992028: transition: libidn

[Simon Josefsson]

> That knowledge from observing how the archive and testing migration 
> software is working right now, in theory what we are seeing is a bug.

Great -- I thought it was something I was supposed to know about and
already should have done as part of dropping the binary package and/or
the transition.  I'm happy to not learn any more than this now :)

/Simon

Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file

[Vincent Lefevre]

On 2021-08-30 20:59:21 +0200, Michael Biebl wrote:
> Am 30.08.21 um 18:31 schrieb Vincent Lefevre:
> > $ ls -l /lib/systemd/system/portmap.service
> > lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36 
> > /lib/systemd/system/portmap.service -> rpcbind.service
> > $ ls -L /lib/systemd/system/portmap.service
> > ls: cannot access '/lib/systemd/system/portmap.service': No such file or 
> > directory
> > 
> > This breaks checkrestart:
> 
> This sounds like a bug in checkrestart, fwiw. Does it really have the path
> /lib/systemd/system/portmap.service hard-coded?

No, it seems to read all .service files under /lib/systemd/system,
and failures seem to make the program abort. Perhaps it should
detect dangling symlinks (though I suppose that they are unexpected).

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

Bug#993342: nmu: kraft_0.97-1

[Norbert Preining]

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

Another package that depends on the old 20.08 release of KDE PIM and
thus is in need of binnmu to allow for co-installability.

nmu kraft_0.97-1 . ANY . unstable . -m "Rebuild for KDE PIM 21.08 compatibility"

Bug#992673: libgpuarray: *gemv broken on libclblast

[Rebecca N. Palmer]

There's also this test failure on arm64 (which is at least a crash not a 
wrong answer), again with clblast not clblas.  It probably isn't a new 
problem either: the tests were previously run with clblas only.


(The "regression" on ppc64el is that the test has never been installable 
there and we're no longer ignoring that, i.e. not actually a regression.)


==
ERROR: pygpu.tests.test_blas.test_ger(64, 64, 'float32', 'f', 1, 1, 
True, False)

--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File "/usr/lib/python3/dist-packages/pygpu/tests/test_blas.py", line 
22, in f

func(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pygpu/tests/test_blas.py", line 
192, in ger

gr = gblas.ger(1.0, gX, gY, gA, overwrite_a=overwrite)
  File "pygpu/blas.pyx", line 167, in pygpu.blas.ger
  File "pygpu/blas.pyx", line 55, in pygpu.blas.pygpu_blas_rger
pygpu.gpuarray.GpuArrayException: (b'CLBlastSger(convO(order), M, N, 
alpha, X->buf, offX, incX, Y->buf, offY, incY, A->buf, offA, lda, 
>q, ): Unknown error', 11)

Bug#895222: ITP: howardhinnant-date -- date and time library based on the C++11/14/17 header

[Paul Wise]

On Mon, 30 Aug 2021 22:31:37 +0200 Martin Quinson wrote:

> any progress on this package? It has been a while, so I was wondering
> if you managed to get somewhere with this package. If you have
> something, it'd be great if you could push your work somewhere so that
> we could help you, if needed.

Matthijs has retired from Debian so I suggest you take over the ITP:

https://nm.debian.org/person/matthijs/

There are projects who use this and would like to see it packaged:

https://github.com/pistacheio/pistache/issues/228#issuecomment-908512860

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#992091: python3.9: Add arc-linux-gnu triplet

[Alexey Brodkin]

Hello!

On Wed, 11 Aug 2021 15:34:09 +0300 Alexey Brodkin  
wrote: 
> Source: python3.9 
> Severity: normal 
> Tags: patch upstream 
> 
> Dear Maintainer, 
> 
> There's a new triplet for ARCv2 processors "arc-linux-gnu" 
> defined here https://wiki.debian.org/Multiarch/Tuples. 
> 
> With addition of this triplet to Python3 it becomes buildable for ARC. 
> Attaching a simple diff that implements proposed change. 

Gentle reminder - This is needed for Debian port for ARC.

-Alexey

Bug#992028: transition: libidn

[Simon Josefsson]

Adrian Bunk  writes:

> On Mon, Aug 30, 2021 at 04:03:36PM +0200, Simon Josefsson wrote:
>>...
>> Also, there is an arch:all missing build of libidn, is that a real
>> problem?  Should I do a binary upload to correct it?  I thought
>> source-only uploads was sufficient now.
>
> There are no packages you could upload, see #993294.

Thanks -- for my learning, is there anywhere I could read about that?
Is it always required when removing arch:all packages?

/Simon


signature.asc
Description: PGP signature

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[dann frazier]

On Tue, Aug 31, 2021 at 01:13:40AM +0300, Michael Tokarev wrote:
> dann, can you please add a printf to util/qemu-sockets.c
> before the assert() which is failing, to see what's the
> value of salen? since you can reproduce this..
> I'm still not 100% sure what the actual problem is -
> or _which_ problem it is in particular.
> 
> It is either one byte too large (for the trailing \0)
> or one byte too small (with zero-length sun_path).
> 
> Like this:
> 
> diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
> index f2f3676d1f..89a405476a 100644
> --- a/util/qemu-sockets.c
> +++ b/util/qemu-sockets.c
> @@ -1345,6 +1345,10 @@ socket_sockaddr_to_address_unix(struct 
> sockaddr_storage *sa,
>  SocketAddress *addr;
>  struct sockaddr_un *su = (struct sockaddr_un *)sa;
> 
> +if(!(salen >= sizeof(su->sun_family) + 1 &&
> +   salen <= sizeof(struct sockaddr_un)))
> +  fprintf(stderr, "about to fire assert: salen=%d\n", salen);
> +
>  assert(salen >= sizeof(su->sun_family) + 1 &&
> salen <= sizeof(struct sockaddr_un));

Sure, build in progress...

Bug#993339: Package: reprotest Debian Salsa reprotest fails due to different compile times

[Christopher Talbot]

Package: reprotest

Hello,

Debian Salsa seems to fail reprotest due to different compile times.
This has been tested on multiple different packages that use the
following CIs:

https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml

One recent example is here:
https://salsa.debian.org/DebianOnMobile-team/vvmd/-/pipelines/283265

When looking at the debs with diffoscope, I get example output like
below (it happens with several files, I only included one for brevity):

-drwxr-xr-x   0 root (0) root (0)0 2021-08-30
22:22:16.00 ./
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:15.00 ./usr/
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:16.00 ./usr/bin/
│ │ │ --rwxr-xr-x   0 root (0) root (0)   119928 2021-
08-30 22:22:16.00 ./usr/bin/vvmd
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:15.00 ./usr/lib/
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:15.00 ./usr/lib/systemd/
│ │ │ -drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:15.00 ./usr/lib/systemd/user/
│ │ │ +drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:25.00 ./
│ │ │ +drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:24.00 ./usr/
│ │ │ +drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:25.00 ./usr/bin/
│ │ │ +-rwxr-xr-x   0 root (0) root (0)   119928 2021-
08-30 22:22:25.00 ./usr/bin/vvmd
│ │ │ +drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:24.00 ./usr/lib/
│ │ │ +drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:24.00 ./usr/lib/systemd/
│ │ │ +drwxr-xr-x   0 root (0) root (0)0 2021-
08-30 22:22:24.00 ./usr/lib/systemd/user/
│ │ │  -rw-r--r--   0 root (0) root (0)  602 2021-
08-30 22:15:18.00 ./usr/lib/systemd/user/vvmd.service

There are other examples here:

https://salsa.debian.org/DebianOnMobile-team/mmsd-tng/-pipelines/268364
https://salsa.debian.org/DebianOnMobile-team/osk-sdl/-/pipelines/239174

In osk-sdl, it seemed to be fixed by running it a day later.
https://salsa.debian.org/DebianOnMobile-team/osk-sdl/-/jobs/1821885


-- 
Respectfully,
Chris Talbot

Bug#993211: inn2: ovdb_monitor/server can't start due to missing /run/news

[Russ Allbery]

John Goerzen  writes:

> Hi Russ!  It is good to visit with you again.  Thanks for what you do
> with inn.

Julien does most of the work, but thank you!

> So I should mention why I switched.  I was getting lines like this in the
> news.daily report:

> innd: tradindexed: index inode mismatch for local.test
> ...

>expireover: tradindexed: index inode mismatch for control
>expireover: tradindexed: index inode mismatch for control.cancel
>expireover: tradindexed: index inode mismatch for
>control.checkgroups
> ...

> I am running inn2 inside a Docker container atop zfs.  I believe inodes
> should be internally consistent (eg, tar can properly detect hardlinkes)
> but due to the bind mount (and possibility of running atop a zfs clone
> or whatnot), I suspect -- but have not verified -- that at least st_dev
> if not st_ino also (from stat(2)) are not guaranteed to be consistent
> across restarts.  I'd guess the most common reason for that would be
> st_dev changes due to the bind mount that Docker does.  However, looking
> at the code, I don't think it uses st_dev, so perhaps st_ino is also not
> stable across restarts.  (conjecture at this point)

Yeah, it only uses st_ino because it assumed that (a) st_ino would be
stable, and (b) the data file and index file would always be on the same
device.  I think (b) is correct, but it sounds like (a) may not be
correct.

FWIW, tradindexed uses that inode number as an optimization.  When
expireover rewrites the data file, it does so in a way that changes the
inode number (and updates that field in the index file), which
communicates to any other process such as running nnrpd instances with
open maps that the data file has changed and should be re-opened to pick
up the new data file.  Therefore, these error messages shouldn't result in
any incorrect behavior (I think); it will just make things slower because
the data file may be re-opened unnecessarily even when it hasn't changed.

I'm surprised that a file system doesn't maintain stable st_ino values.
That seems vaguely broken to me, but I'm not sure if anything guarantees
that behavior.

-- 
Russ Allbery (r...@debian.org)  

Bug#993320: RFP: mailmunge -- Mailmunge is a Perl-based email filtering framework that uses Milter

[Dianne Skoll]

Package: wnpp
Severity: wishlist

* Package name: mailmunge
  Version : 3.04
  Upstream Author : Dianne Skoll 
* URL : https://www.mailmunge.org/
* License : GPLv2
  Programming Lang: Perl, C and Tcl
  Description : Mailmunge is a Perl-based email filtering framework that 
uses Milter

Mailmunge is a mail filter based on the Sendmail Milter filtering
protocol and library. This protocol is used by both Sendmail and
Postfix, allowing Mailmunge to work with either MTA.

Mailmunge connects the Milter protocol to a set of Perl worker
processes. This lets you write your mail filtering policies in Perl,
and make use of the wealth of CPAN modules available for dealing with
MIME and email in general.

Mailmunge is a fork of MIMEDefang by the original MIMEDefang author.  It's
C code is pretty similar to MIMEDefang, but the Perl API is much improved
and has much better documentation.

Regards,

Dianne.

Bug#981446: Possible adoption of logcheck

[Jose M Calhariz]

Hi,

I am a user of logckeck as I use on all my machines that I sysadmin
and I maintain some packages on Debian like for example at and amanda.

As now I would like to offer my help to package and fix logcheck as a
learning experience for a possibility in the future to be the
maintainer of logcheck.

Kind regards
Jose M Calhariz


-- 
--
Você faria papel de trouxa? A Betty Faria.


signature.asc
Description: PGP signature

Bug#993338: octave: Setting up octave fails due to missing libGL.so.1

[Witold Baryluk]

Package: octave
Version: 6.2.0-1
Severity: serious
Justification: Policy 3.5
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

when debootstrapping using live-build:

Setting up octave (6.2.0-1) ...
/usr/bin/octave-cli: error while loading shared libraries: libGL.so.1: cannot 
open shared object file: No such file or directory
dpkg: error processing package octave (--configure):
 installed octave package post-installation script subprocess returned error 
exit status 127


Mesa is installed later by apt. Pre-Depends maybe required? Also weird a
bit that octave-cli requires OpenGL.

Regards,
Witold



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

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

Versions of packages octave depends on:
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-17
ii  libfftw3-double33.3.8-2
ii  libfftw3-single33.3.8-2
ii  libfltk-gl1.3   1.3.5-3
ii  libfltk1.3  1.3.5-3
ii  libgcc-s1   11.2.0-3
ii  libgl1  1.3.2-1
ii  libglpk40   5.0-1
ii  liboctave8  6.2.0-1
ii  libportaudio2   19.6.0-1.1
ii  libqhull8.0 2020.2-4
ii  libqscintilla2-qt5-15   2.11.6+dfsg-2
ii  libqt5core5a5.15.2+dfsg-10
ii  libqt5gui5  5.15.2+dfsg-10
ii  libqt5help5 5.15.2-5
ii  libqt5network5  5.15.2+dfsg-10
ii  libqt5printsupport5 5.15.2+dfsg-10
ii  libqt5widgets5  5.15.2+dfsg-10
ii  libqt5xml5  5.15.2+dfsg-10
ii  libsndfile1 1.0.31-2
ii  libstdc++6  11.2.0-3
ii  libsundials-ida45.7.0+dfsg-1
ii  libsundials-sunlinsol2  5.7.0+dfsg-1
ii  libx11-62:1.7.2-1
ii  octave-common   6.2.0-1
ii  texinfo 6.7.0.dfsg.2-6
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages octave recommends:
ii  default-jre-headless   2:1.11-72
ii  epstool3.09-3
ii  gnuplot-x11 [gnuplot-nox]  5.4.1+dfsg1-1
ii  libopenblas0   0.3.17+ds-2
ii  octave-doc 6.2.0-1
ii  pstoedit   3.75-1

Versions of packages octave suggests:
pn  liboctave-dev  

-- no debconf information

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[Michael Tokarev]

dann, can you please add a printf to util/qemu-sockets.c
before the assert() which is failing, to see what's the
value of salen? since you can reproduce this..
I'm still not 100% sure what the actual problem is -
or _which_ problem it is in particular.

It is either one byte too large (for the trailing \0)
or one byte too small (with zero-length sun_path).

Like this:

diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c
index f2f3676d1f..89a405476a 100644
--- a/util/qemu-sockets.c
+++ b/util/qemu-sockets.c
@@ -1345,6 +1345,10 @@ socket_sockaddr_to_address_unix(struct sockaddr_storage 
*sa,
 SocketAddress *addr;
 struct sockaddr_un *su = (struct sockaddr_un *)sa;

+if(!(salen >= sizeof(su->sun_family) + 1 &&
+   salen <= sizeof(struct sockaddr_un)))
+  fprintf(stderr, "about to fire assert: salen=%d\n", salen);
+
 assert(salen >= sizeof(su->sun_family) + 1 &&
salen <= sizeof(struct sockaddr_un));


thank you!

Bug#993337: gcc-11-base: changelog.Debian.gz multiarch inconsistency

[Marc Glisse]

Package: gcc-11-base
Version: 11.2.0-3
Severity: normal

Dear Maintainer,

while upgrading other packages, I got

Preparing to unpack .../0-gcc-11-base_11.2.0-3_mips64el.deb ...
Unpacking gcc-11-base:mips64el (11.2.0-3) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-bFwhF7/0-gcc-11-base_11.2.0-3_mips64el.deb (--unpack):
 trying to overwrite shared '/usr/share/doc/gcc-11-base/changelog.Debian.gz', 
which is different from other instances of package gcc-11-base:mips64el

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'testing'), (400, 'stable'), (50, 'unstable-debug'), 
(50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, ppc64el, mips64el, s390x, armhf

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#992122: golang-github-prometheus-client-golang-dev: new "collectors" package needed for packaging

[Peymaneh Nejad]

gentle ping on this

kind regards,
Peymaneh



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993336: libclass-trait-perl: arch:all but depends on perlapi-5.32.0

[Niko Tyni]

Package: libclass-trait-perl
Version: 0.31-4.1
Severity: serious
Tags: sid bookworm
User: debian-p...@lists.debian.org
Usertags: perl-5.34-transition
X-Debbugs-Cc: Holger Levsen 

It looks like the no-change 0.31-4.1 upload introduced
a regression: despite being arch:all it ships
  /usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Class/Trait/.packlist
which has made debhelper add a dependency on perlapi-5.32.0.

This is broken: the package will become uninstallable when Perl 5.34
(currently in experimental) enters unstable, but it can't be automatically
rebuilt as we don't do arch:all binNMUs.

The reason is a hardcoded reference to the old /usr/lib/perl5 directory
in debian/rules: the packlist file no longer got removed in the rebuild
because it gets installed elsewhere nowadays.

AFAICS when this is fixed, upgrades (even partial) from the current
version should work fine, so we can live with having this in the stable
release.

Copying Holger who did the NMU, but mainly just FYI. I'm sure the
pkg-perl folks can fix this before the Perl 5.34 transition if the
maintainer doesn't.
-- 
Niko Tyni   nt...@debian.org

Bug#961364: xsp: diff for NMU version 4.2-2.3

[Sebastian Ramacher]

Control: tags 961364 + patch

Dear maintainer,

I've prepared an NMU for xsp (versioned as 4.2-2.3). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru xsp-4.2/debian/changelog xsp-4.2/debian/changelog
--- xsp-4.2/debian/changelog	2020-12-28 12:15:15.0 +0100
+++ xsp-4.2/debian/changelog	2021-08-30 23:40:29.0 +0200
@@ -1,3 +1,12 @@
+xsp (4.2-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Clint Adams ]
+  * Use mktemp instead of tempfile (Closes: #961364)
+
+ -- Sebastian Ramacher   Mon, 30 Aug 2021 23:40:29 +0200
+
 xsp (4.2-2.2) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru xsp-4.2/debian/mono-apache-server4.postinst xsp-4.2/debian/mono-apache-server4.postinst
--- xsp-4.2/debian/mono-apache-server4.postinst	2017-04-01 19:32:54.0 +0200
+++ xsp-4.2/debian/mono-apache-server4.postinst	2021-08-30 23:31:56.0 +0200
@@ -34,7 +34,7 @@
 
 case "$1" in
 configure)
-	tempfile=$(/bin/tempfile)
+	tempfile=$(mktemp)
 	
 	db_get monoserver4/monoserver4_restartapache || true
 	daemon_turn_off
diff -Nru xsp-4.2/debian/mono-xsp4.postinst xsp-4.2/debian/mono-xsp4.postinst
--- xsp-4.2/debian/mono-xsp4.postinst	2017-04-01 19:32:54.0 +0200
+++ xsp-4.2/debian/mono-xsp4.postinst	2021-08-30 23:31:56.0 +0200
@@ -82,7 +82,7 @@
 
 case "$1" in
 configure)
-	tempfile=$(/bin/tempfile)
+	tempfile=$(mktemp)
 	
 	# Configure autostart, but don't prevent the init script
 	# from starting it manually.
diff -Nru xsp-4.2/debian/mono-xsp4.postinst.orig xsp-4.2/debian/mono-xsp4.postinst.orig
--- xsp-4.2/debian/mono-xsp4.postinst.orig	1970-01-01 01:00:00.0 +0100
+++ xsp-4.2/debian/mono-xsp4.postinst.orig	2017-04-01 19:32:54.0 +0200
@@ -0,0 +1,122 @@
+#!/bin/bash
+set -e
+
+. /usr/share/debconf/confmodule
+db_version 2.0
+
+xsp4_default="/etc/default/mono-xsp4"
+NAME=mono-xsp4
+DESC="XSP 4 WebServer"
+CFGDIR=/etc/xsp4
+VIRTUALFILE=$CFGDIR/debian.webapp
+
+# create file if it doesn't exist
+if [ ! -e $xsp4_default ]; then
+	cat > $xsp4_default <<-END
+	# Defaults for mono-xsp4, official version
+	# sourced by /etc/init.d/mono-xsp4
+	
+	# Should we start it?
+	start_boot=true
+	
+	# User and group by default
+	user=www-data
+	group=www-data
+	
+	# Default port
+	port=8084
+	address=0.0.0.0
+	
+	# Directory for config files
+	config_files=/etc/xsp4
+	END
+fi
+
+update_port() {
+db_get xsp4/xsp4_port || true
+R=$RET
+echo "Using Mono XSP 4 port: $R"
+sed "s/port=.*/port=$R/g" $xsp4_default > $tempfile
+cp -f $tempfile $xsp4_default
+}
+
+update_bind() {
+db_get xsp4/xsp4_bind || true
+R=$RET
+echo "Binding Mono XSP 4 address: $R"
+sed "s/address=.*/address=$R/g" $xsp4_default > $tempfile
+cp -f $tempfile $xsp4_default
+}
+
+should_start() {
+if [ -e $xsp4_default ]; then
+	. $xsp4_default
+if [ "$start_boot" != "true" ]; then
+	return 1
+fi
+else
+echo "mono-xsp4: Not started, you need a valid and complete $xsp4_default"
+return 1
+fi
+
+if [ ! -e $VIRTUALFILE -o `cat $VIRTUALFILE | wc -l` = "2" ]; then
+	echo "mono-xsp4: Not started, you need asp.net-examples/monodoc-http or an ASP.NET application"
+	return 1
+fi 
+
+if [ -f /var/run/$NAME.pid ]; then
+	# Are we really running xsp4?
+	xsp4_pid=`cat /var/run/$NAME.pid`
+	xsp4_ps=`ps -p $xsp4_pid | wc -l`
+	if [ "$xsp4_ps" != "2" ]; then
+	return 0
+	else
+	return 1
+	fi
+else
+	return 1
+fi
+
+return 1
+}
+
+case "$1" in
+configure)
+	tempfile=$(/bin/tempfile)
+	
+	# Configure autostart, but don't prevent the init script
+	# from starting it manually.
+	autostart="true"
+	db_get xsp4/xsp4_autostart || true
+	if [ "$RET" = "true" ]; then	
+	if [ -x "/etc/init.d/mono-xsp4" ]; then
+		update-rc.d mono-xsp4 defaults > /dev/null 2>&1 || true
+	fi
+	else
+	update-rc.d -f mono-xsp4 remove > /dev/null 2>&1  || true
+	fi
+
+	# If default file exists, configure the port and address
+	if [ -f $xsp4_default ]; then
+	update_port
+	update_bind
+	fi
+
+	mono-xsp4-update
+	if [ "$RET" = "true" ]; then
+	if should_start -a $autostart = "true" ; then
+		if which invoke-rc.d >/dev/null 2>&1; then
+		invoke-rc.d mono-xsp4 start
+		else
+		/etc/init.d/mono-xsp4 start
+		fi
+	fi
+	fi
+
+	rm $tempfile
+	;;
+esac
+
+#DEBHELPER#
+
+exit 0


signature.asc
Description: PGP signature

Bug#993335: libxml-rss-feed-perl: FTBFS with Perl 5.34: t/010_deprecated_methods.t failure

[Niko Tyni]

Source: libxml-rss-feed-perl
Version: 2.212-1.2
Severity: normal
Tags: sid bookworm ftbfs fixed-upstream
User: debian-p...@lists.debian.org
Usertags: perl-5.34-transition

This package fails to build from source with Perl 5.34 (currently in
experimental).

It looks like it regressed with 
https://github.com/Test-More/test-more/issues/870

A test case is

 perl -MTest::More=no_plan -e 'cmp_ok(undef, q(eq), q(), qq(tested))'

which no longer outputs a warning on stderr.

The failing test has since been rewritten upstream.

>From a build log:

  # Looks like you planned 8 tests but ran 6.
  t/010_deprecated_methods.t .. 
  Dubious, test returned 255 (wstat 65280, 0xff00)
  Failed 2/8 subtests 

  Test Summary Report
  ---
  t/010_deprecated_methods.t(Wstat: 65280 Tests: 6 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan.  You planned 8 tests but ran 6.

A full log is available at 

  
http://perl.debian.net/rebuild-logs/perl-5.34-throwaway/libxml-rss-feed-perl_2.212-1.2/libxml-rss-feed-perl_2.212-1.2_amd64-2021-08-30T11:31:45Z.build

-- 
Niko Tyni   nt...@debian.org

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Dirk Eddelbuettel]

On 30 August 2021 at 23:42, Niko Tyni wrote:
| Package: libgsl25
| Version: 2.7+dfsg-2
| Control: affects -1 libmath-gsl-perl
| Severity: serious
| 
| gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest 
regressions:
| 
|not ok 7 - use Math::GSL::Matrix;
|
|#   Failed test 'use Math::GSL::Matrix;'
|#   at t/00-load.t line 14.
|# Tried to use 'Math::GSL::Matrix'.
|# Error:  Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for 
module Math::GSL::Linalg: 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined 
symbol: gsl_linalg_QR_TR_decomp at 
/usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187.
|# � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11.
|# Compilation failed in require at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
|# BEGIN failed--compilation aborted at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
|# Compilation failed in require at t/00-load.t line 14.
|# BEGIN failed--compilation aborted at t/00-load.t line 14.
|ok 8 - use Math::GSL::Poly;
|not ok 9 - use Math::GSL::MatrixComplex;
| 
| It seems that the 2.7 upload broke the ABI of libgsl25 by removing
| the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from
| entering testing because of this regression in libmath-gsl-perl_0.42-1.
| 
| Looks like upstream Math-GSL-0.43 probably no longer references this
| symbol, but it's not in Debian yet and I haven't built and verified that.
| 
| Clearly at least something must be done on the libgsl side. Not sure if
| it needs to restore the symbol or bump its SONAME, or if just a Breaks
| on older libmath-gsl-perl versions is enough. (See policy 8.6.2)

I am not fully sure what they are doing.  They do increment values sometimes,
sometimes they keep them. I mostly just followed along.

We also for a time tried to accomodate lagging Debian packages. I do not
think that that winnable strategy long term.

I could add a versioned breaks for libmath-gsl-perl.  Can you send me a
preferred expression?

| I've also filed the separate bug #993323 about libmath-gsl-perl failing to
| build with GSL 2.7. That should be fixed just by upgrading it to 0.43.

Right.

Dirk

| -- 
| Niko Tyni nt...@debian.org

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#992672: Uploaded dask_2021.08.1+dfsg-1

[Diane Trout]

package: dask
tags: pending
version: 2021.08.1+dfsg-1

I uploaded the new version of dask, and on my computer dask's
autopkgtests pass with python3-scipy 1.7.1.

Diane


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

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[dann frazier]

On Mon, Aug 30, 2021 at 02:38:30PM -0600, dann frazier wrote:
> On Sat, Aug 28, 2021 at 02:53:01PM +0300, Michael Tokarev wrote:
> > On 27.08.2021 23:25, dann frazier wrote:
> > > Package: qemu-system-x86
> > > Version: 1:6.1+dfsg-1
> > > Severity: normal
> > > 
> > > 
> > > A VM that I created with either virt-manager or virtinst sometime ago now
> > > crashes when I attempt to start it under QEMU 6.1.
> > 
> > Lovely.
> > 
> > I can only guess this is due to libvirt's qemu-guest-agent socket, this one:
> > 
> > > -chardev socket,id=charchannel0,fd=43,server=on,wait=off \
> > > -device 
> > > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
> > >  \
> > 
> > Dann, can you please disable the socket/qga to verify?
> > If this is the case this is an impotant issue at least,
> > it should definitely be fixed.
> 
> Thanks for the response Michael. Unfortunately, I'm not able to
> reproduce at the moment. After filing this bug, I looked through git
> logs and, on a hunch, decided to try w/ the following patch reverted:
> 
>   4cfd970ec1 util: fix abstract socket path copy
> 
> That seemed to make the issue go away. Today I restored the archive
> versions of the QEMU packages, and the issue no longer
> reproduces. So now I have to question whether or not that revert was
> significant or purely correlation :(

Aha! It seems that the important difference is whether or not the
virt-manager GUI window for the VM is active. If it is active, the VM
crashes regardless of how it is started (virsh console start/clicking
"play" button). If the GUI is not active, the VM always works.

With this knowledge I am able to confidently say that reverting
4cfd970ec1 *does* reliably avoid the problem.

I was also now able to run the requested test, dropping the
qemu-guest-agent socket. This did not avoid the problem:

2021-08-30 21:10:46.931+: starting up libvirt version: 7.6.0, package: 1 
(Andrea Bolognani  Thu, 19 Aug 2021 21:16:21 +0200), qemu 
version: 6.1.0Debian 1:6.1+dfsg-1, kernel: 5.13.0-trunk-amd64, hostname: 
xps13.dannf
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \
HOME=/var/lib/libvirt/qemu/domain-24-debian10 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-24-debian10/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-24-debian10/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-24-debian10/.config \
/usr/bin/qemu-system-x86_64 \
-name guest=debian10,debug-threads=on \
-S \
-object 
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-24-debian10/master-key.aes"}'
 \
-machine 
pc-q35-5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram
 \
-cpu 
Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hle=off,rtm=off
 \
-m 2048 \
-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":2147483648}' \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid REDACTED \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=39,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot menu=on,strict=on \
-device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
-device pcie-pci-bridge,id=pci.9,bus=pci.8,addr=0x0 \
-device pcie-root-port,port=0x18,chassis=10,id=pci.10,bus=pcie.0,addr=0x3 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/images/debian10.raw","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-3-format","read-only":false,"driver":"raw","file":"libvirt-3-storage"}'
 \
-device 
virtio-blk-pci,bus=pci.4,addr=0x0,drive=libvirt-3-format,id=virtio-disk0,bootindex=1
 \
-blockdev 
'{"driver":"file","filename":"/var/lib/libvirt/images/debian10-seed.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 

Bug#992997: milter-greylist: segfault in libGeoIP

[Sudip Mukherjee]

Hi Bjørn,

On Thu, Aug 26, 2021 at 07:09:40AM +0100, Bjørn Mork wrote:
> Package: milter-greylist
> Version: 4.6.2-3
> Severity: normal
> 
> Seeing lots of these after upgrading til bullseye:
> 
> Aug 23 22:12:23 louie kernel: milter-greylist[192919]: segfault at 28 ip 
> 7fbaf22fe8d9 sp 7fbaee77c670 error 4 in 
> libGeoIP.so.1.6.12[7fbaf22fc000+1b000]
> Aug 23 22:12:23 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 
> 00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 
> ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35
> Aug 24 22:45:40 louie kernel: milter-greylist[217578]: segfault at 28 ip 
> 7fcc2deb78d9 sp 7fcc2a335670 error 4 in 
> libGeoIP.so.1.6.12[7fcc2deb5000+1b000]
> Aug 24 22:45:40 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 
> 00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 
> ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35
> Aug 25 22:10:57 louie kernel: milter-greylist[240196]: segfault at 28 ip 
> 7f525900a8d9 sp 7f5255c89670 error 4 in 
> libGeoIP.so.1.6.12[7f5259008000+1b000]
> Aug 25 22:10:57 louie kernel: Code: 90 e9 6b d8 ff ff 66 66 2e 0f 1f 84 00 00 
> 00 00 00 48 85 f6 0f 84 8f 00 00 00 41 54 49 89 d4 53 48 89 fb 48 89 f7 48 83 
> ec 08 <0f> be 43 28 3c 0c 74 4f 3c 12 74 4b 48 8b 3d cc 26 03 00 48 8d 35
> 
> Doesn't look too good, given that it's probably triggered by mail contents
> somehow.

I just updated the package to latest 4.6.4, can you please try with that
and check if you still get the same problem. If you still the same problem
the a coredump or some way to reproduce the problem will be needed.


--
Regards
Sudip

Bug#993334: gdal: FTBFS: configure.ac: error: required file 'config.rpath' not found

[Niko Tyni]

Source: gdal
Version: 3.2.2+dfsg-2
Severity: serious
Tags: ftbfs sid bookworm

This package fails to build from source on current sid.

>From a build log:

   configure.ac:5590: warning: The macro `AC_CHECKING' is obsolete.
   configure.ac:5590: You should run autoupdate.
   ./lib/autoconf/general.m4:2499: AC_CHECKING is expanded from...
   configure.ac:5590: the top level
   configure.ac:6030: warning: AC_OUTPUT should be used without arguments.
   configure.ac:6030: You should run autoupdate.
   configure.ac: error: required file 'config.rpath' not found
   dh_autoreconf: error: autoreconf -f -i returned exit code 1
   make: *** [debian/rules:100: build] Error 25
   dpkg-buildpackage: error: debian/rules build subprocess returned exit status 
2
 
A full log is available at

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gdal.html

-- 
Niko Tyni   nt...@debian.org

Bug#993052: transition: tracker

[Sebastian Ramacher]

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

On 2021-08-26 20:02:13 -0400, Jeremy Bicha wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: trac...@packages.debain.org
> Severity: normal
> 
> The Debian GNOME team requests permission to do the "tracker"
> transition, updating the library and service from version 2 to version
> 3. All affected packages need sourceful uploads.
> 
> All affected packages are maintained by the Debian GNOME team except
> for grilo-plugins, kylin-burner and netatalk.
> 
> All package updates are staged in experimental except for
> grilo-plugins and netatalk.
> 
> The transition was successfully completed in Ubuntu a month ago.

Please go ahead

Cheers

> 
> https://release.debian.org/transitions/html/auto-tracker.html
> 
> https://salsa.debian.org/berto/grilo-plugins/-/merge_requests/2
> 
> Thank you,
> Jeremy Bicha
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993333: weechat: FTBFS: Target "irc" links to item " use `command -v' in scripts instead

[Niko Tyni]

Source: weechat
Version: 3.0.1-1
Severity: serious
Tags: ftbfs sid bookworm

This package fails to build from source on current sid.

It looks like this regressed with the recent change in debianutils
that made /usr/bin/which output a deprecation warning.

>From a build log:

   -- Found GCRYPT: /usr/bin/which: this version of `which' is deprecated; use 
`command -v' in scripts instead.
   -L/usr/lib/x86_64-linux-gnu -lgcrypt  
   
   [...]
   
   CMake Error at src/plugins/irc/CMakeLists.txt:20 (add_library):
 Target "irc" links to item " use `command -v' in scripts instead.
   
 -L/usr/lib/x86_64-linux-gnu -lgcrypt" which has leading or trailing
 whitespace.  This is now an error according to policy CMP0004.

A full log is available at

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/weechat.html

-- 
Niko Tyni   nt...@debian.org

Bug#993027: transition: knot 3.0 to 3.1

[Sebastian Ramacher]

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

On 2021-08-26 13:45:39 +, Jakub Ružička wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> in order to update knot to latest 3.1.1, its only reverse dependency
> knot-resolver needs to be updated to >= 5.4 which supports new
> knot 3.1 API/ABI.
> 
> I've tested this in experimental - knot-resolver-5.4.1-1 built against
> knot-3.1.1-3. Both packages have autopkgtests as well upstream tests
> enabled.

Please go ahead

Cheers

> 
> Ben file:
> 
> title = "knot";
> is_affected = .depends ~ 
> /\b(libknot12|libzscanner4|libknot11|libzscanner3)\b/;
> is_good = .depends ~ /\b(libknot12|libzscanner4)\b/;
> is_bad = .depends ~ /\b(libknot11|libzscanner3)\b/;
> 
> Thank you.
> 
> 
> Cheers,
> Jakub
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992970: transition: wbxml2

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2021-08-25 14:27:03 -0400, Boyuan Yang wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-CC: debian-scie...@lists.debian.org ti...@debian.org
> Forwarded: https://release.debian.org/transitions/html/auto-wbxml2.html
> 
> Dear Release Team,
> 
> I am looking into starting the transition as shown on
> https://release.debian.org/transitions/html/auto-wbxml2.html . The transition
> is caused by upstream's SONAME bump in the new release.
> 
> For package wbxml2, the only reverse dependency is virtuoso-opensource. I have
> tested that the build for virtuoso-opensource is ok with wbxml2 from
> experimental.

Please go ahead

Cheers

> 
> Example Ben file (the one currently from auto-wbxml2 should be enough):
> 
> title = "wbxml2";
> is_affected = .depends ~ "libwbxml2-0" | .depends ~ "libwbxml2-1";
> is_good = .depends ~ "libwbxml2-1";
> is_bad = .depends ~ "libwbxml2-0";
> 
> 
> Thanks,
> Boyuan Yang



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992868: transition: schroedinger-coordgenlibs

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: retitle -1 
https://release.debian.org/transitions/html/auto-schroedinger-coordgenlibs.html

On 2021-08-24 16:52:08 +0300, Andrius Merkys wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I would like to request a transition slot for schroedinger-coordgenlibs
> (experimental -> unstable) due to soname bump. Current ben tracker [1]
> is fine, ratt successfully rebuilds all reverse build dependencies.

Please go ahead

Cheers

> 
> Thanks,
> Andrius
> 
> [1]
> https://release.debian.org/transitions/html/auto-schroedinger-coordgenlibs.html
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#993016: libdap: Includes rpc/types.h which is no longer provided by libc6-dev

[Aurelien Jarno]

On 2021-08-30 20:15, Sebastiaan Couwenberg wrote:
> On 8/27/21 12:14 PM, Aurelien Jarno wrote:
> > On 2021-08-26 13:27, Bas Couwenberg wrote:
> >> The recent changes in glibc break libdap and its rdeps:
> >>
> >>  In file included from /usr/include/libdap/XDRUtils.h:37,
> >>   from /usr/include/libdap/Sequence.h:50,
> >>   from libdap_headers.h:52,
> >>   from ogr_dods.h:44,
> >>   from ogrdodsdriver.cpp:29:
> >>  /usr/include/libdap/xdr-datatypes.h:16:10: fatal error: rpc/types.h: No 
> >> such file or directory
> >> 16 | #include 
> >>|  ^
> >>
> >> /usr/include/rpc/types.h was provided by libc6-dev in bullseye, but it is 
> >> no longer included in libc6-dev (2.31-17).
> > 
> > The problem is that libdap has proper TI RPC support, but it doesn't
> > export that information properly to libdap.pc and dap-config, sorry
> > about that.
> > 
> > Please find a patch attached to fix that.
> 
> Thanks for the patch, I've prepared an NMU with it applied.
> 
> I can confirm that it fixes the libdap issue breaking the gdal build.
> Unfortunately ecs.h from ogdi-dfsg still includes rpc/rpc.h also
> breaking the gdal build.

It's normal keeps including rpc/rpc.h, but it should get its cflags
updated. It has just been binNMUed today, and with libogdi-dev version
4.1.0+ds-5+b1, I get:

$ /usr/bin/ogdi-config --cflags
-I/usr/include/ogdi -I/usr/include/tirpc
$ pkg-config --cflags ogdi
-I/usr/include/ogdi -I/usr/include/tirpc

So that should be fixed already.

Regards,
Aurelien

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

Bug#993331: JPEG2000/JP2 support missing

[Manuel Geißer]

Package: qt5-image-formats-plugins
Version: 5.15.2-2

It seems that the Debian `qt5-image-formats-plugins` package does not 
support JPEG2000/JP2 images, in spite of this format being supported by 
Qt [1] through the JasPer Image Processing/Coding Tool Kit [2]. This 
results in QImage-based end-user applications such as Gwenview not 
supporting this popular image format, although technically possible.


In order to add JP2 support, `qt5-image-formats-plugins` would need to 
be built with JasPer, which would first require packaging the latter in 
Debian. The Ubuntu repository already contains a package named `jasper`, 
but it does something completely different [3], so the image processing 
JasPer package may need to be named differently.


JasPer used to be affected by security issues [4], but as of the day of 
writing all known CVEs are fixed [5], and JasPer continues to be 
maintained by the original author Michael Adams and contributors [6] 
(latest version 2.0.33 released on 2021-08-01 [7]).


Note that the author of this bug report does not use Debian itself, but 
the Ubuntu-based KDE Neon [8]. However, judging by the list of 
dependencies [9], `qt5-image-formats-plugins` is not built with JasPer 
and thus without JP2 support in Debian. Therefore, this report should 
only be seen as a notification to the Debian packaging team in order to 
promote support for the JP2 format.


[1] 
https://github.com/qt/qtimageformats/blob/dev/src/plugins/imageformats/jp2/qjp2handler.cpp

[2] https://github.com/jasper-software/jasper
[3] https://packages.ubuntu.com/hirsute/jasper
[4] https://github.com/jasper-software/jasper/issues/208
[5] 
https://github.com/jasper-software/jasper/issues/208#issuecomment-665471904

[6] https://github.com/jasper-software/jasper/graphs/contributors
[7] https://github.com/jasper-software/jasper/releases/tag/version-2.0.33
[8] https://bugs.kde.org/show_bug.cgi?id=441673
[9] https://packages.debian.org/bullseye/qt5-image-formats-plugins

Bug#993332: gnumeric: FTBFS: Can't exec "gtkdocize": No such file or directory

[Niko Tyni]

Source: gnumeric
Version: 1.12.48-1
Severity: serious
Tags: ftbfs sid bookworm

This package fails to build from source on current sid.

>From a build log:

  dh_autoreconf --as-needed
  libtoolize: putting auxiliary files in '.'.
  libtoolize: copying file './ltmain.sh'
  libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
  libtoolize: copying file 'm4/libtool.m4'
  libtoolize: copying file 'm4/ltoptions.m4'
  libtoolize: copying file 'm4/ltsugar.m4'
  libtoolize: copying file 'm4/ltversion.m4'
  libtoolize: copying file 'm4/lt~obsolete.m4'
  libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
  You should update your 'aclocal.m4' by running aclocal.
  Can't exec "gtkdocize": No such file or directory at 
/usr/share/autoconf/Autom4te/FileUtils.pm line 293.
  autoreconf: error: gtkdocize failed with exit status: 2
  dh_autoreconf: error: autoreconf -f -i returned exit code 2
  make[1]: *** [debian/rules:33: override_dh_autoreconf] Error 25
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:29: binary-arch] Error 2
  dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2
 
A full log is available for instance at

 
https://buildd.debian.org/status/fetch.php?pkg=gnumeric=mips64el=1.12.48-1%2Bb3=1630062552=0

-- 
Niko Tyni   nt...@debian.org

Bug#993274: machine unbootable after upgrade

[Toni Mueller]

Hi Paul,

On Mon, Aug 30, 2021 at 10:10:12PM +0200, Paul Gevers wrote:
> On 29-08-2021 23:39, Toni Mueller wrote:
> > I am not sure why the upgrade process didn't handle this case, but think
> > the severity of the problem warrants a warning in the release notes.
> 
> Can you give a proposal for some text? After reading the old (closed)
> bug report, it's not clear to me what to warn for exactly as it seems
> that Colin there claims it's a broken configuration on your system.

the system was installed as a standard no-frills Buster system. I
haven't read why Colin thought that's a misconfiguration on the system,
but in my case, there has been no disk change, the system was installed
and then, sometime later, upgraded, which is when the problem occurred.

> Nobody brought it up to the release notes, so nothing was added.

Of course, I can only suggest something after seeing a problem. I would
suggest a text like this:


If your system is configured to boot from a RAID array, eg. MDADM, you
need to take extra precautions. After the upgrade procedure, but before
the reboot, you need to manually ensure that GRUB is properly installed
on all relevant disks. In the case of RAID1 (mirrored disks), do this:

 # lsblk
 sda...
 sdc...   # or sdb

You'll find the boot disks by their partitioning. For this example, it's
sda and sdc. Then run these commands:

 # grub-install /dev/sda
 # grub-install /dev/sdc



The other question is, why did this happen at all? I have previously
upgraded other systems with the same RAID configuration (ie, RAID1 via
mdadm), and can't remember having seen this problem. It would be better
to actually fix the problem, if possible.



Cheers,
Toni

Bug#993330: polymake: FTBFS with Perl 5.34: error: ‘Perl_pp_keys’ was not declared in this scope

[Niko Tyni]

Source: polymake
Version: 4.3-4
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.34-transition

This package fails to build from source with Perl 5.34 (currently
in experimental). I don't presently understand why; I'm not aware of
changes to Perl_pp_keys or Perl_pp_rv2hv. So the root issue might also
be on the Perl side. At least it seems to reliably fail the same way.

From the build log:

   FAILED: 
/<>/build/Opt/lib/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.o
 
 g++ -c -o 
/<>/build/Opt/lib/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.o
 -MMD -MT 
/<>/build/Opt/lib/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.o
 -MF 
/<>/build/Opt/lib/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.o.d
 -fPIC -pipe -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -std=c++14 -ftemplate-depth-200 -fno-strict-aliasing 
-fopenmp -Wshadow -Wlogical-op -Wconversion -Wzero-as-null-pointer-constant 
-Wno-parentheses -Wno-error=unused-function -Wno-stringop-overflow 
-Wno-array-bounds -DPOLYMAKE_WITH_FLINT  -DPOLYMAKE_DEBUG=0 -DNDEBUG -O2 
-I/usr/lib/x86_64-linux-gnu/perl/5.34/CORE -D_REENTRANT -D_GNU_SOURCE -DDEBIAN 
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -DPerlVersion=5340 -Wno-nonnull  
-I/<>/include/core-wrappers -I/<>/include/core 
/<>/build/perlx/5.34.0/x86_64-linux-gnu-thread-multi/RefHash.cc && 
: 'COMPILER_USED=10.3.0'
   /<>/lib/core/src/perl/RefHash.xxs: In function ‘OP* 
pm::perl::glue::{anonymous}::intercept_pp_keys(PerlInterpreter*)’:
   /<>/lib/core/src/perl/RefHash.xxs:385:17: error: ‘Perl_pp_keys’ 
was not declared in this scope; did you mean ‘Perl_pp_akeys’?
 385 |   OP* ret = Perl_pp_keys(aTHX);
 | ^~~~
 | Perl_pp_akeys
   /<>/lib/core/src/perl/RefHash.xxs:393:11: error: ‘Perl_pp_keys’ 
was not declared in this scope; did you mean ‘Perl_pp_akeys’?
 393 |return Perl_pp_keys(aTHX);
 |   ^~~~
 |   Perl_pp_akeys
   /<>/lib/core/src/perl/RefHash.xxs: In function ‘OP* 
pm::perl::glue::{anonymous}::pp_rv2hv_ref_retrieve(PerlInterpreter*)’:
   /<>/lib/core/src/perl/RefHash.xxs:524:14: error: 
‘Perl_pp_rv2hv’ was not declared in this scope; did you mean ‘Perl_pp_rv2sv’?
 524 |OP* ret = Perl_pp_rv2hv(aTHX);
 |  ^
 |  Perl_pp_rv2sv
   /<>/lib/core/src/perl/RefHash.xxs: In function ‘OP* 
pm::perl::glue::{anonymous}::intercept_pp_rv2hv(PerlInterpreter*)’:
   /<>/lib/core/src/perl/RefHash.xxs:549:18: error: 
‘Perl_pp_rv2hv’ was not declared in this scope; did you mean ‘Perl_pp_rv2sv’?
 549 |  PL_op = Perl_pp_rv2hv(aTHX);
 |  ^
 |  Perl_pp_rv2sv

 
A full build log is available at

   
http://perl.debian.net/rebuild-logs/perl-5.34/polymake_4.3-4/polymake_4.3-4+b2_amd64-2021-08-30T08:15:00Z.build

-- 
Niko Tyni   nt...@debian.org

Bug#992280: hdmi doesn't help

[Mike Perrin]

I was wondering if the VGA connection might be part of the problem so I 
tried booting the netinstall iso with the monitor connected through the 
HDMI port. The result was identical to VGA: the selection screen 
appeared perfectly but both the graphical and text install options 
produced a shredded display at 1920x1200.

Bug#993329: libcgal-dev: CGAL/Qt/AlphaShapeGraphicsItem.h in the wrong subpackage?

[Marc Glisse]

Package: libcgal-dev
Version: 5.3-2
Severity: normal

Dear Maintainer,

during a partial upgrade, I got

The following packages will be upgraded:
  libcgal-dev libcgal-dev:i386 libcgal-dev:arm64 libcgal-dev:ppc64el 
libcgal-dev:mips64el libcgal-dev:s390x libcgal-dev:armhf
[...]
Preparing to unpack .../0-libcgal-dev_5.3-2_armhf.deb ...
De-configuring libcgal-dev:s390x (5.2-3) ...
De-configuring libcgal-dev:ppc64el (5.2-3) ...
De-configuring libcgal-dev:mips64el (5.2-3) ...
De-configuring libcgal-dev:i386 (5.2-3) ...
De-configuring libcgal-dev:arm64 (5.2-3) ...
De-configuring libcgal-dev:amd64 (5.2-3) ...
Unpacking libcgal-dev:armhf (5.3-2) over (5.2-3) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-niPV4E/0-libcgal-dev_5.3-2_armhf.deb (--unpack):
 trying to overwrite '/usr/include/CGAL/Qt/AlphaShapeGraphicsItem.h', which is 
also in package libcgal-qt5-dev:mips64el 5.2-3
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)

I am surprised that this header is now in libcgal-dev. If it is there on
purpose, some conflicts/replaces fields might be in order.


-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'testing'), (400, 'stable'), (50, 'unstable-debug'), 
(50, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, ppc64el, mips64el, s390x, armhf

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcgal-dev depends on:
ii  libboost-dev  1.74.0.3
ii  libboost-program-options-dev  1.74.0.3
ii  libboost-system-dev   1.74.0.3
ii  libboost-thread-dev   1.74.0.3
ii  libgmp-dev2:6.2.1+dfsg-1
ii  libmpfr-dev   4.1.0-3
ii  zlib1g-dev1:1.2.11.dfsg-2

libcgal-dev recommends no packages.

Versions of packages libcgal-dev suggests:
ii  libmpfi-dev  1.5.3+ds-5
ii  libntl-dev   11.4.3-1+b1
ii  libtbb-dev   2020.3-1

-- no debconf information

Bug#993328: openscap: FTBFS with Perl 5.34: hardcodes Perl version 5.32

[Niko Tyni]

Source: openscap
Version: 1.3.4-1 
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.34-transition

This package fails to build from source with Perl 5.34 (currently in
experimental). This is because debian/rules hardcodes Perl version
5.32.0.

>From the build log:

   chrpath -d debian/tmp/usr/bin/oscap
   chrpath -d debian/tmp/usr/lib/x86_64-linux-gnu/libopenscap.so.25.3.0
   chrpath -d debian/tmp/usr/lib/x86_64-linux-gnu/libopenscap_sce.so.25.3.0
   chrpath -d debian/tmp/usr/lib/x86_64-linux-gnu/perl5/5.32/openscap_pm.so
   open: No such file or directory
   elf_open: Invalid argument
   make[1]: *** [debian/rules:33: override_dh_auto_install] Error 1
 
A full build log is available at

   
http://perl.debian.net/rebuild-logs/perl-5.34/openscap_1.3.4-1/openscap_1.3.4-1+b1_amd64-2021-08-29T22:29:14Z.build

-- 
Niko Tyni   nt...@debian.org

Bug#993327: golang-github-ajg-form: FTBFS with Go 1.17

[William 'jawn-smith' Wilson]

Package: golang-github-ajg-form
Version: 1.5+git20160822.523a5da-1.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch

Dear Maintainer,

As of Go 1.17, the ';' character is not accepted as a valid separator
by net/http or net/url. This causes some of the tests in this package
to fail during the build. Changing the tests cases that use ';' to use
'&' instead fixes the build failures


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

Build golang-github-ajg-form with Go 1.17

  * Change semicolons to ampersands to enable building with go 1.17
(LP: #1942131)


Thanks for considering the patch.


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

Kernel: Linux 5.11.0-31-generic (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
golang-github-ajg-form-1.5+git20160822.523a5da/debian/patches/change-semicolon-to-ampersand.patch
 
golang-github-ajg-form-1.5+git20160822.523a5da/debian/patches/change-semicolon-to-ampersand.patch
--- 
golang-github-ajg-form-1.5+git20160822.523a5da/debian/patches/change-semicolon-to-ampersand.patch
   1969-12-31 18:00:00.0 -0600
+++ 
golang-github-ajg-form-1.5+git20160822.523a5da/debian/patches/change-semicolon-to-ampersand.patch
   2021-08-30 15:44:10.0 -0500
@@ -0,0 +1,23 @@
+Description: Change ';' to '&' when used as a separator
+ As of Go 1.17, ';' is no longer a valid separator in the net/url
+ and net/http packages. This causes some of the test cases in this
+ package to fail. Since '&' is still valid, we change the test cases
+ to use '&' as a separator instead.
+ See https://golang.org/doc/go1.17#semicolons for more information
+Author: William 'jawn-smith' Wilson
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/golang-github-ajg-form/+bug/1942131
+Applied-Upstream: https://github.com/ajg/form/pull/26
+Last-Update: 2021-08-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/form_test.go
 b/form_test.go
+@@ -126,7 +126,7 @@
+   var T time.Time
+   var U url.URL
+   const canonical = 
`A.0=x=y=z=true=42%2B6.6i=%00%01%02=%03%04%05=6.6=8=7=9%5C.D%5C%5CQ%5C.B.A=P%2FD%5C.D%5C%5CQ%5C.B.B=Q-B=8734=Hello%2C+there.=2013-10-01T07%3A05%3A34.00088Z=http%3A%2F%2Fexample.org%2Ffoo%23bar=11_22=33_44=2006-12-01=42`
+-  const variation = 
`;C=42%2B6.6i;A.0=x;M.Bar=8;F=6.6;A.1=y;R=8734;A.2=z;Zs.0.Qp=33_44;B=true;M.Foo=7;T=2013-10-01T07:05:34.00088Z;E.Bytes1=%00%01%02;Bytes2=%03%04%05;Zs.0.Q=11_22;Zs.0.Z=2006-12-01;M.Qux=9;life=42;S=Hello,+there.;P\.D\\Q\.B.A=P/D;P\.D\\Q\.B.B=Q-B;U=http%3A%2F%2Fexample.org%2Ffoo%23bar;`
++  const variation = 
`=42%2B6.6i=x=8=6.6=y=8734=z=33_44=true=7=2013-10-01T07:05:34.00088Z=%00%01%02=%03%04%05=11_22=2006-12-01=9=42=Hello,+there.\.D\\Q\.B.A=P/D\.D\\Q\.B.B=Q-B=http%3A%2F%2Fexample.org%2Ffoo%23bar&`
+ 
+   for _, c := range []testCase{
+   // Bools
diff -Nru golang-github-ajg-form-1.5+git20160822.523a5da/debian/patches/series 
golang-github-ajg-form-1.5+git20160822.523a5da/debian/patches/series
--- golang-github-ajg-form-1.5+git20160822.523a5da/debian/patches/series
1969-12-31 18:00:00.0 -0600
+++ golang-github-ajg-form-1.5+git20160822.523a5da/debian/patches/series
2021-08-30 15:43:16.0 -0500
@@ -0,0 +1 @@
+change-semicolon-to-ampersand.patch

Bug#989442: Debian: openssl: Add ARC target

[Alexey Brodkin]

On Thu, 3 Jun 2021 19:14:24 + Vineet Gupta  
wrote: 
> Source: openssl 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> This is needed to bootstrap arc port. 
> Patch attached. 

Ping!

-Alexey

Bug#992091: python3.9: Add arc-linux-gnu triplet

[Alexey Brodkin]

On Wed, 11 Aug 2021 15:34:09 +0300 Alexey Brodkin  
wrote: 
> Source: python3.9 
> Severity: normal 
> Tags: patch upstream 
> 
> Dear Maintainer, 
> 
> There's a new triplet for ARCv2 processors "arc-linux-gnu" 
> defined here https://wiki.debian.org/Multiarch/Tuples. 
> 
> With addition of this triplet to Python3 it becomes buildable for ARC. 
> Attaching a simple diff that implements proposed change. 
> 
> -- System Information: 
> Debian Release: bullseye/sid 
>   APT prefers focal-updates 
>   APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 
>'focal-proposed'), (500, 'focal'), (100, 'focal-backports')
> Architecture: amd64 (x86_64) 
> 
> Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores) 
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8) 
> Shell: /bin/sh linked to /usr/bin/dash 
> Init: unable to detect 

Ping!

-Alexey

Bug#989440: Debian: gmp: add support for arc

[Alexey Brodkin]

On Thu, 3 Jun 2021 19:00:30 + Vineet Gupta  
wrote: 
> Source: gmp 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> To bootstrap arc port we need symbols file update in gmp. 
> Patch attached. 

Ping!

-Alexey

Bug#989443: Debian: libffi: update symbols for ARC

[Alexey Brodkin]

On Thu, 3 Jun 2021 19:51:25 + Vineet Gupta  
wrote: 
> Source: libffi 
> Severity: normal 
> Tags: patch 
> 
> Hi, 
> 
> This is needed to bootstrap arc port. 
> Patch attached. 

Ping!

-Alexey

Bug#989444: Debian: jemalloc: add arc support

[Alexey Brodkin]

On Thu, 3 Jun 2021 21:10:28 + Vineet Gupta  
wrote: 
> Update: upstream change has just now been merged. 

Ping!

-Alexey

Bug#993326: jellyfish: FTBFS with Perl 5.34: hardcodes Perl version 5.32

[Niko Tyni]

Source: jellyfish
Version: 2.3.0-11
Severity: normal
User: debian-p...@lists.debian.org
Usertags: perl-5.34-transition

This package fails to build from source with Perl 5.34 (currently in
experimental). This is because debian/rules hardcodes Perl version
5.32.0.

>From the build log:

  make[1]: Entering directory '/<>'
  # Python files are just installed
  rm -rf debian/tmp/usr/lib/python3/dist-packages
  # Necessary Perl files are just installed
  rm -rf debian/tmp/usr/lib/perl/5.32.0
  dh_missing
  dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.a exists in debian/tmp but 
is not installed to anywhere 
  dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.la exists in debian/tmp 
but is not installed to anywhere 
  dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.so exists in debian/tmp 
but is not installed to anywhere 
  dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.so.0 exists in debian/tmp 
but is not installed to anywhere 
  dh_missing: warning: usr/lib/perl/5.34.0/jellyfish.so.0.0.0 exists in 
debian/tmp but is not installed to anywhere 
  dh_missing: error: missing files, aborting
The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: jellyfish (4), jellyfish-examples (0), 
libjellyfish-2.0-2 (0), libjellyfish-2.0-dev (1), libjellyfish-perl (2), 
python3-dna-jellyfish (0)
 * dh_installdocs: jellyfish (3), jellyfish-examples (0), 
libjellyfish-2.0-2 (0), libjellyfish-2.0-dev (0), libjellyfish-perl (0), 
python3-dna-jellyfish (0)
 * dh_installexamples: jellyfish (0), jellyfish-examples (31), 
libjellyfish-2.0-2 (0), libjellyfish-2.0-dev (0), libjellyfish-perl (0), 
python3-dna-jellyfish (0)
 * dh_installman: jellyfish (1), jellyfish-examples (0), 
libjellyfish-2.0-2 (0), libjellyfish-2.0-dev (0), libjellyfish-perl (0), 
python3-dna-jellyfish (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
  make[1]: *** [debian/rules:106: override_dh_missing] Error 25
  make[1]: Leaving directory '/<>'
  make: *** [debian/rules:22: binary-arch] Error 2
  dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2
 
A full build log is available at

  
http://perl.debian.net/rebuild-logs/perl-5.34/jellyfish_2.3.0-11/jellyfish_2.3.0-11+b1_amd64-2021-08-30T07:33:15Z.build

-- 
Niko Tyni   nt...@debian.org

Bug#788411: Please update the patch

[Anton Gladky]

control: tags -1 +moreinfo

Thanks for the patch!

It looks like the symbol-file cannot be applied any more.
Could you please update it, if this bug is still relevant?

If not - please close it. Thanks.

Anton

Bug#993325: ckb-next: No ckb-next-daemon function on systems not running systemd

[avarner]

Package: ckb-next
Version: 0.4.3+dfsg.1-0.1
Severity: important

Dear Maintainer,

ckb-next on first run gives an error message that the daemon is not started. It 
suggests the command `sudo systemctl start ckb-next-daemon` but systemctl is 
not installed, and ckb-next does not depend on whatever package contains 
systemctl.

Please add an entry in /etc/init.d/ for ckb-next-daemon .


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ckb-next depends on:
ii  libc62.31-4
ii  libdbusmenu-qt5-20.9.3+16.04.20160218-2+b1
ii  libgcc-s110.2.1-6
ii  libpulse013.0-5
ii  libqt5core5a 5.15.2+dfsg-4
ii  libqt5dbus5  5.15.2+dfsg-4
ii  libqt5gui5   5.15.2+dfsg-4
ii  libqt5network5   5.15.2+dfsg-4
ii  libqt5widgets5   5.15.2+dfsg-4
ii  libqt5x11extras5 5.11.3-2
ii  libquazip5-1 0.9.1-1
ii  libstdc++6   10.2.1-6
ii  libudev1 241-7~deb10u4
ii  libxcb-ewmh2 0.4.1-1.1
ii  libxcb-screensaver0  1.14-3
ii  libxcb1  1.13.1-2

ckb-next recommends no packages.

ckb-next suggests no packages.

-- no debconf information

Bug#993324: libgsl25: ABI breakage: removed symbol gsl_linalg_QR_TR_decomp

[Niko Tyni]

Package: libgsl25
Version: 2.7+dfsg-2
Control: affects -1 libmath-gsl-perl
Severity: serious

gsl 2.7 broke libmath-gsl-perl on runtime, as seen in the autopkgtest 
regressions:

   not ok 7 - use Math::GSL::Matrix;
   
   #   Failed test 'use Math::GSL::Matrix;'
   #   at t/00-load.t line 14.
   # Tried to use 'Math::GSL::Matrix'.
   # Error:  Can't load 
'/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so' for 
module Math::GSL::Linalg: 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/Math/GSL/Linalg/Linalg.so: undefined 
symbol: gsl_linalg_QR_TR_decomp at 
/usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line 187.
   # � at /usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Linalg.pm line 11.
   # Compilation failed in require at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
   # BEGIN failed--compilation aborted at 
/usr/lib/x86_64-linux-gnu/perl5/5.32/Math/GSL/Matrix.pm line 1210.
   # Compilation failed in require at t/00-load.t line 14.
   # BEGIN failed--compilation aborted at t/00-load.t line 14.
   ok 8 - use Math::GSL::Poly;
   not ok 9 - use Math::GSL::MatrixComplex;

It seems that the 2.7 upload broke the ABI of libgsl25 by removing
the gsl_linalg_QR_TR_decomp symbol. src:gsl is currently blocked from
entering testing because of this regression in libmath-gsl-perl_0.42-1.

Looks like upstream Math-GSL-0.43 probably no longer references this
symbol, but it's not in Debian yet and I haven't built and verified that.

Clearly at least something must be done on the libgsl side. Not sure if
it needs to restore the symbol or bump its SONAME, or if just a Breaks
on older libmath-gsl-perl versions is enough. (See policy 8.6.2)

I've also filed the separate bug #993323 about libmath-gsl-perl failing to
build with GSL 2.7. That should be fixed just by upgrading it to 0.43.
-- 
Niko Tyni nt...@debian.org

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[dann frazier]

On Sat, Aug 28, 2021 at 02:53:01PM +0300, Michael Tokarev wrote:
> On 27.08.2021 23:25, dann frazier wrote:
> > Package: qemu-system-x86
> > Version: 1:6.1+dfsg-1
> > Severity: normal
> > 
> > 
> > A VM that I created with either virt-manager or virtinst sometime ago now
> > crashes when I attempt to start it under QEMU 6.1.
> 
> Lovely.
> 
> I can only guess this is due to libvirt's qemu-guest-agent socket, this one:
> 
> > -chardev socket,id=charchannel0,fd=43,server=on,wait=off \
> > -device 
> > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
> >  \
> 
> Dann, can you please disable the socket/qga to verify?
> If this is the case this is an impotant issue at least,
> it should definitely be fixed.

Thanks for the response Michael. Unfortunately, I'm not able to
reproduce at the moment. After filing this bug, I looked through git
logs and, on a hunch, decided to try w/ the following patch reverted:

  4cfd970ec1 util: fix abstract socket path copy

That seemed to make the issue go away. Today I restored the archive
versions of the QEMU packages, and the issue no longer
reproduces. So now I have to question whether or not that revert was
significant or purely correlation :(

  -dann

Bug#895222: ITP: howardhinnant-date -- date and time library based on the C++11/14/17 header

[Martin Quinson]

Hello Matthijs,

any progress on this package? It has been a while, so I was wondering
if you managed to get somewhere with this package. If you have
something, it'd be great if you could push your work somewhere so that
we could help you, if needed.

Thanks a lot, 
Mt.

-- 
La poésie est la preuve la plus flagrante de l'existence de l'homme.
  -- Gabriel García Márquez


signature.asc
Description: PGP signature

Bug#993323: libmath-gsl-perl: FTBFS: Unsupported GSL version!!! : 2.7

[Niko Tyni]

Source: libmath-gsl-perl
Version: 0.42-1
Severity: serious
Tags: ftbfs sid bookworm fixed-upstream

This package fails to build on current sid.

  Checking for GSL using gsl-config
  Found GSL 2.7 (via gsl-config) installed in /usr
  Checking if x86_64-linux-gnu-gcc supports "-Wall"...yes
  Checking if x86_64-linux-gnu-gcc supports "-Wno-sometimes-uninitialized"...yes
  Checking if x86_64-linux-gnu-gcc supports "-Wno-unused-function"...yes
  Checking if x86_64-linux-gnu-gcc supports "-Wno-unused-value"...yes
  Checking if x86_64-linux-gnu-gcc supports "-Wno-unused-function"...yes
  Checking if x86_64-linux-gnu-gcc supports "-Wno-unused-variable"...yes
  Checking if x86_64-linux-gnu-gcc supports "-Wno-gnu"...yes
  Checking if x86_64-linux-gnu-gcc supports "-g"...Unsupported GSL version!!! : 
2.7 at Build.PL line 80.
  yes
  dh_auto_configure: error: /usr/bin/perl Build.PL --installdirs vendor 
--config "optimize=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" --config "ld=x86_64-linux-gnu-gcc -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z,relro -Wl,-z,now" returned exit code 25
  make: *** [debian/rules:9: binary] Error 25
  dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
2
 
This clearly broke with gsl 2.7+dfsg-2. It's should be fixed upstream
in 0.43.

A complication is that gsl 2.7 also broke libmath-gsl-perl on run time
by removing a symbol. I'll report this separately against libgsl25.
-- 
Niko Tyni   nt...@debian.org

Bug#993274: machine unbootable after upgrade

[Paul Gevers]

Hi Toni,

On 29-08-2021 23:39, Toni Mueller wrote:
> I am not sure why the upgrade process didn't handle this case, but think
> the severity of the problem warrants a warning in the release notes.

Can you give a proposal for some text? After reading the old (closed)
bug report, it's not clear to me what to warn for exactly as it seems
that Colin there claims it's a broken configuration on your system.

Nobody brought it up to the release notes, so nothing was added.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992028: transition: libidn

[Paul Gevers]

Hi

On 30-08-2021 21:34, Adrian Bunk wrote:
> britney (testing migration software) used to be a bit too liberal on 
> letting things migrate, andthere were packages migrating to testing
> despite a binary-all FTBFS (sometimes noone notices for months when a
> -doc package is missing).

That would be bug #887060, the bug report is still open.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#993322: firehol: Firehol delays system startup

[David Jarvie]

Package: firehol
Version: 3.1.7+ds-2
Severity: normal

Dear Maintainer,

At each system boot, Firehol takes a full minute to initialise, and makes the
boot process hang for some of that time.

Looking at the system log (attached), it isn't obvious why Firehol takes just
over
1 minute to complete, or why nothing seems to happen between 19:49:40 and
19:50:08, during which a console message is displayed saying that the boot
process is waiting for Firehol to finish.

The command 'firehol restart' takes very little time to complete once the
system is up and running. This indicates that something is wrong at boot time,
and that Firehol is presumably waiting for something else to complete.

I would have expected Firehol to initialise quickly during boot, and not to
hang the boot process.


I attach the journalctl output, from Firehol start to Firehol completion:


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

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

Versions of packages firehol depends on:
ii  firehol-common   3.1.7+ds-2
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0

Versions of packages firehol recommends:
ii  fireqos  3.1.7+ds-2

Versions of packages firehol suggests:
ii  firehol-doc3.1.7+ds-2
pn  firehol-tools  
pn  ulogd2 

-- Configuration Files:
/etc/default/firehol changed:
START_FIREHOL=YES
WAIT_FOR_IFACE="enp2s0"
FIREHOL_ESTABLISHED_ACTIVATION_ACCEPT=0

/etc/firehol/firehol.conf changed:
version 6
stewjar=192.168.178.100
local="192.168.178.101 192.168.178.102 192.168.178.103"
m2885fw=192.168.178.90
interface4 enp2s0 ethernet
# The default policy is DROP. You can be more polite with REJECT.
# Prefer to be polite on your own clients to prevent timeouts.
policy drop
# Protect from the internet.
protection strong
# The following means that this machine can REQUEST anything via
enp2s0.
client all accept
# Specific services that this machine needs to request via enp2s0.
client multicast accept
client dhcp accept
# Services that this machine offers to local network.
server ping accept src "$local"
server ssh accept src "$local"
server cups accept src "$local"
# Samsung M2885FW printer (needs both client and server)
# The script 'scanner-enable' must be run after Firehol, to fix
# iptables entries to allow SNMP to work properly.
client snmp accept dst $m2885fw
server snmp accept src $m2885fw
server samba accept
# The following enp2s0 server ports are not known by FireHOL:
#  tcp/45485 tcp/49074 tcp/7741 udp/32768 udp/32769 udp/517 udp/518
udp/5353 udp/7741 udp/972
# TODO: If you need any of them, you should define new services.
#   (see Adding Services at the web site - http://firehol.sf.net).
interface usb0 usb
policy accept
Aug 30 19:49:07 desktop systemd[1]: Starting Set console font and keymap...
Aug 30 19:49:07 desktop systemd[1]: Starting Firehol stateful packet filtering 
firewall for humans...
Aug 30 19:49:07 desktop systemd[1]: Starting Tell Plymouth To Write Out Runtime 
Data...
Aug 30 19:49:07 desktop systemd[1]: Condition check resulted in Store a System 
Token in an EFI Variable being skipped.
Aug 30 19:49:07 desktop systemd[1]: Condition check resulted in Commit a 
transient machine-id on disk being skipped.
Aug 30 19:49:07 desktop systemd[1]: Received SIGRTMIN+20 from PID 174 
(plymouthd).
Aug 30 19:49:07 desktop systemd[1]: Finished Tell Plymouth To Write Out Runtime 
Data.
Aug 30 19:49:07 desktop systemd[1]: Finished Set console font and keymap.
Aug 30 19:49:07 desktop systemd[1]: Finished Flush Journal to Persistent 
Storage.
Aug 30 19:49:07 desktop systemd[1]: Starting Create Volatile Files and 
Directories...
Aug 30 19:49:07 desktop systemd[1]: Condition check resulted in Dispatch 
Password Requests to Console Directory Watch being skipped.
Aug 30 19:49:07 desktop systemd[1]: Condition check resulted in Set Up 
Additional Binary Formats being skipped.
Aug 30 19:49:07 desktop systemd[1]: Condition check resulted in Store a System 
Token in an EFI Variable being skipped.
Aug 30 19:49:07 desktop systemd[1]: Condition check resulted in Rebuild 
Hardware Database being skipped.
Aug 30 19:49:07 desktop systemd[1]: Condition check resulted in Commit a 
transient machine-id on disk being skipped.
Aug 30 19:49:07 desktop systemd[1]: Condition check resulted in Platform 
Persistent Storage Archival being skipped.
Aug 30 19:49:08 desktop systemd[1]: Finished Create Volatile Files and 
Directories.
Aug 30 

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[Michael Tokarev]

Btw, which sockets are used by livbirt for qemu-monitor or qga?
May it be too long a pathname?

/mjt

Bug#969409: sendfile: weekly cron job should use mktemp instead of tempfile

[Boyuan Yang]

Control: severity -1 grave

Since tempfile has been removed from debianutils, bumping the severity of this
bug to grave.

I have prepared initial fix in https://salsa.debian.org/debian/sendfile , but
we still need more work to make another QA upload.

Thanks,
Boyuan Yang



On Wed, 2 Sep 2020 10:40:07 +0200 Laurent Bonnaud 
wrote:
> 
> Package: sendfile
> Version: 2.1b.20080616-6
> Severity: normal
> 
> 
> Dear Maintainer,
> 
> each week I receive an e-mail with the following content:
> 
> /etc/cron.weekly/sendfile:
> WARNING: tempfile is deprecated; consider using mktemp instead.
> 
> Could you please update /etc/cron.weekly/sendfile to use mktemp instead of
tempfile?
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>    APT prefers unstable-debug
>    APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.8.0-trunk-amd64 (SMP w/2 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages sendfile depends on:
> ii  libc6 2.31-3
> ii  libdpkg-perl  1.20.5
> ii  libreadline8  8.1~alpha1-1
> ii  openbsd-inetd [inet-superserver]  0.20160825-5
> ii  perl  5.30.3-4
> ii  update-inetd  4.50
> 
> -- 
> Laurent.
> 
> 



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

Bug#992698: meld dies with "Trace/breakpoint trap"

[Bálint Réczey]

Control: tags -1 moreinfo

Hi Harald,

Harald Dunkel  ezt írta (időpont: 2021. aug. 22., V, 15:30):
>
> Package: meld
> Version: 3.20.3-1
>
> All it says is
>
> # meld /etc/auto.misc.ucf-old /etc/auto.misc
> Trace/breakpoint trap

Does it die with the same error with all file comparisons or just on those?
I tried reproducing the problem by comparing a slightly edited version
of /etc/auto.misc with the original file, but meld worked just fine
(on Ubuntu 21.04).

What release/file content triggers the error?

Cheers,
Balint

Bug#992028: transition: libidn

[Adrian Bunk]

On Mon, Aug 30, 2021 at 09:19:07PM +0200, Simon Josefsson wrote:
> Adrian Bunk  writes:
> 
> > On Mon, Aug 30, 2021 at 04:03:36PM +0200, Simon Josefsson wrote:
> >>...
> >> Also, there is an arch:all missing build of libidn, is that a real
> >> problem?  Should I do a binary upload to correct it?  I thought
> >> source-only uploads was sufficient now.
> >
> > There are no packages you could upload, see #993294.
> 
> Thanks -- for my learning, is there anywhere I could read about that?
> Is it always required when removing arch:all packages?

That knowledge from observing how the archive and testing migration 
software is working right now, in theory what we are seeing is a bug.

dak (archive software) does have automatic cruft removal.

For some time it was too eager to remove cruft, so when the package did 
FTBFS on binary-all this often resulted in a round through NEW.

Now it's a bit more cautious, and tends to err on the side of not 
removing enough.

britney (testing migration software) used to be a bit too liberal on 
letting things migrate, andthere were packages migrating to testing
despite a binary-all FTBFS (sometimes noone notices for months when a
-doc package is missing).

Most likely the release team can force libidn into testing right away,
but that's something they have to tell.

> /Simon

cu
Adrian

Bug#638936:

[URGENT]

Hello,
Did you get the previous message I sent to you?
Get back to me over the matter.

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[Michael Tokarev]

Alternatively, a debugging backtrace from the failing run will be
much apprecated, -- the `bt' gdb command after installing
qemu-system-x86's dbgsym package.
Thanks!

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[Michael Tokarev]

30.08.2021 21:04, Günter Frenz wrote:


I can confirm this error, I get the same message in the logs for every
VM I try to start since the update to version 6.1

...> I removed the guest-agent channel from the VM-definition via

virt-manager, but I get the same message in the logs as with the
guest-agent channel.


Hello Günter! Thank you for stepping in.

This assertion failure appears for unix-domain sockets.
In your case the unix-domain socket seems to be the one
used for the qemu monitor, this one (from your config):

 -chardev socket,id=charmonitor,fd=30,server=on,wait=off \
 -mon chardev=charmonitor,id=monitor,mode=control \

so in order to verify this you'll need to reconfigure your
monitor to be something else, not the qga socket like
in the dann's case.

But I begin to have more doubts about this, maybe the
problem is elsewhere.

Can you please check if changing your qemu monitor to
something else will make any difference?

Thank you!

/mjt

Bug#992028: transition: libidn

[Adrian Bunk]

On Mon, Aug 30, 2021 at 04:03:36PM +0200, Simon Josefsson wrote:
>...
> Also, there is an arch:all missing build of libidn, is that a real
> problem?  Should I do a binary upload to correct it?  I thought
> source-only uploads was sufficient now.

There are no packages you could upload, see #993294.

> /Simon

cu
Adrian

Bug#993321: ITP: seqwish -- alignment to variation graph inducer

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: seqwish -- alignment to variation graph inducer
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: seqwish
  Version : 0.7.1
  Upstream Author : Erik Garrison
* URL : https://github.com/ekg/seqwish
* License : MIT
  Programming Lang: C++
  Description : alignment to variation graph inducer
 Seqwish implements a lossless conversion from pairwise alignments
 between sequences to a variation graph encoding the sequences and their
 alignments. As input we typically take all-versus-all alignments, but
 the exact structure of the alignment set may be defined in an
 application specific way. This algorithm uses a series of disk-backed
 sorts and passes over the alignment and sequence inputs to allow the
 graph to be constructed from very large inputs that are commonly
 encountered when working with large numbers of noisy input sequences.
 Memory usage during construction and traversal is limited by the use of
 sorted disk-backed arrays and succinct rank/select dictionaries to
 record a queryable version of the graph.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/seqwish

Bug#989442: [Pkg-openssl-devel] Bug#989442: Debian: openssl: Add ARC target

[Sebastian Andrzej Siewior]

control: found -1 1.1.1g-1
control: tags -1 + pending

On 2021-08-30 19:30:07 [+0200], To Alexey Brodkin wrote:
> On 2021-08-30 16:37:11 [+], Alexey Brodkin wrote:
> > On Thu, 3 Jun 2021 19:14:24 + Vineet Gupta  
> > wrote: 
> > > This is needed to bootstrap arc port. 
> > > Patch attached. 
> > 
> > Ping!
> 
> Urgh. Sorry, thanks for the ping.

I pushed it to the unstable/experimental branch so it will be part of
the next upload.
 https://salsa.debian.org/debian/openssl/-/commits/debian/unstable
 https://salsa.debian.org/debian/openssl/-/commits/debian/experimental

Feel free to yell if something ain't right.

> > -Alexey

Sebastian

Bug#990108: ITP: obs-websocket -- WebSockets API for OBS Studio

[Eriberto Mota]

Thanks for your work Benjamin!

Could you upload it to bullseye-backports when in Testing?

Regards,

Eriberto

Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file

[Michael Biebl]

Am 30.08.21 um 18:31 schrieb Vincent Lefevre:

Package: systemd
Version: 247.9-1
Severity: critical
Justification: breaks unrelated software

systemd provides a dangling symlink:

$ ls -l /lib/systemd/system/portmap.service
lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36 /lib/systemd/system/portmap.service 
-> rpcbind.service
$ ls -L /lib/systemd/system/portmap.service
ls: cannot access '/lib/systemd/system/portmap.service': No such file or 
directory

This breaks checkrestart:


This sounds like a bug in checkrestart, fwiw. Does it really have the 
path /lib/systemd/system/portmap.service hard-coded?






OpenPGP_signature
Description: OpenPGP digital signature

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[Günter Frenz]

Hi all,

attached is the log from the test without guest-agent channel:

Cheers

Günter

-- 
---
Günter Frenz
Börschgasse 16a, D-51143 Köln
(h) gu...@guefz.de, gu...@freenet.de
(w) g.frenz@gso.schule.koeln
---


2021-08-30 17:48:54.103+: starting up libvirt version: 7.6.0, package: 1 
(Andrea
 Bolognani  Thu, 19 Aug 2021 21:16:21 +0200), qemu version: 
6.1.0Deb
ian 1:6.1+dfsg-1, kernel: 5.10.0-8-amd64, hostname: corinnis.midgard
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
HOME='/var/lib/libvirt/qemu/domain-2-debian9 qtiplot' \
XDG_DATA_HOME='/var/lib/libvirt/qemu/domain-2-debian9 qtiplot/.local/share' \
XDG_CACHE_HOME='/var/lib/libvirt/qemu/domain-2-debian9 qtiplot/.cache' \
XDG_CONFIG_HOME='/var/lib/libvirt/qemu/domain-2-debian9 qtiplot/.config' \
/usr/bin/qemu-system-x86_64 \
-name 'guest=debian9 qtiplot,debug-threads=on' \
-S \
-object 
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libv
irt/qemu/domain-2-debian9 qtiplot/master-key.aes"}' \
-machine 
pc-q35-4.2,accel=tcg,usb=off,vmport=off,dump-guest-core=off,memory-backend=
pc.ram \
-cpu 
EPYC,acpi=on,ss=on,monitor=on,hypervisor=on,erms=on,mpx=on,pcommit=on,clwb=on,p
ku=on,la57=on,3dnowext=on,3dnow=on,npt=on,vme=off,fma=off,avx=off,f16c=off,avx2=off,
rdseed=off,sha-ni=off,xsavec=off,fxsr-opt=off,misalignsse=off,3dnowprefetch=off,osvw
=off,topoext=off,nrip-save=off \
-m 8192 \
-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592}' \
-overcommit mem-lock=off \
-smp 4,sockets=4,cores=1,threads=1 \
-uuid c47f4f48-5c6d-482d-bd18-a38819c1f3cd \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=30,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device 
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
 \
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev 
'{"driver":"file","filename":"/data1/virtual-machines/debian9.qcow2","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
 \
-blockdev 
'{"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":null}'
 \
-device 
virtio-blk-pci,bus=pci.4,addr=0x0,drive=libvirt-2-format,id=virtio-disk0,bootindex=1
 \
-device ide-cd,bus=ide.0,id=sata0-0-0,bootindex=2 \
-netdev tap,fd=33,id=hostnet0 \
-device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:a4:bc:bb,bus=pci.1,addr=0x0 
\
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev spicevmc,id=charchannel0,name=vdagent \
-device 
virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 \
-device usb-tablet,id=input0,bus=usb.0,port=1 \
-audiodev id=audio1,driver=none \
-vnc 127.0.0.1:0,audiodev=audio1 \
-device virtio-vga,id=video0,max_outputs=1,bus=pcie.0,addr=0x1 \
-device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b \
-device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0,audiodev=audio1 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \
-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 \
-sandbox 
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
char device redirected to /dev/pts/6 (label charserial0)
qemu-system-x86_64: ../../util/qemu-sockets.c:1348: 
socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 
&& salen <= sizeof(struct sockaddr_un)' failed.
2021-08-30 17:48:54.802+: shutting down, reason=crashed


pgpVppNvgz83k.pgp
Description: Digitale Signatur von OpenPGP

Bug#987830: Linking Ubuntu report

[mooff]

This looks to be the same bug as
https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-455/+bug/1905591,
which has more info and user reports.

A user on IRC reported having this issue too, and their system is one
of the ones that isn't fixed by comment #11 on the Ubuntu issue.

As a result, they are thinking of switching from Debian to Arch, where
it does work with the newer 470 driver.

Thanks

Bug#993308: firefox-esr: You might need to add a libpci3 dependency to ESR 91

[darkspirit]

Package: firefox-esr
Version: 91.0.1esr-1
Severity: important
X-Debbugs-Cc: j...@ikenmeyer.eu

https://bugzilla.mozilla.org/show_bug.cgi?id=1676883 added a dependency on 
libPCI.
It's used to decide whether WebGL and hardware rendering are allowed.
I report this because I remember libpci3 had to be added to the Snap package: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1703142

Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.

[Günter Frenz]

Hi all,

On Sat, 28 Aug 2021 14:53:01 +0300 Michael Tokarev 
wrote:
> On 27.08.2021 23:25, dann frazier wrote:
> > Package: qemu-system-x86
> > Version: 1:6.1+dfsg-1
> > Severity: normal
> > 
> > 
> > A VM that I created with either virt-manager or virtinst sometime
> > ago now crashes when I attempt to start it under QEMU 6.1.

I can confirm this error, I get the same message in the logs for every
VM I try to start since the update to version 6.1

> Lovely.
> 
> I can only guess this is due to libvirt's qemu-guest-agent socket,
> this one:
> 
> > -chardev socket,id=charchannel0,fd=43,server=on,wait=off \
> > -device
> > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
> > \
> 
> Dann, can you please disable the socket/qga to verify?
> If this is the case this is an impotant issue at least,
> it should definitely be fixed.

I removed the guest-agent channel from the VM-definition via
virt-manager, but I get the same message in the logs as with the
guest-agent channel.

Cheers

Günter

-- 
---
Günter Frenz
Börschgasse 16a, D-51143 Köln
(h) gu...@guefz.de, gu...@freenet.de
(w) g.frenz@gso.schule.koeln
---




pgpbCxK9h2s9S.pgp
Description: Digitale Signatur von OpenPGP

Bug#993016: libdap: Includes rpc/types.h which is no longer provided by libc6-dev

[Sebastiaan Couwenberg]

On 8/27/21 12:14 PM, Aurelien Jarno wrote:
> On 2021-08-26 13:27, Bas Couwenberg wrote:
>> The recent changes in glibc break libdap and its rdeps:
>>
>>  In file included from /usr/include/libdap/XDRUtils.h:37,
>>   from /usr/include/libdap/Sequence.h:50,
>>   from libdap_headers.h:52,
>>   from ogr_dods.h:44,
>>   from ogrdodsdriver.cpp:29:
>>  /usr/include/libdap/xdr-datatypes.h:16:10: fatal error: rpc/types.h: No 
>> such file or directory
>> 16 | #include 
>>|  ^
>>
>> /usr/include/rpc/types.h was provided by libc6-dev in bullseye, but it is no 
>> longer included in libc6-dev (2.31-17).
> 
> The problem is that libdap has proper TI RPC support, but it doesn't
> export that information properly to libdap.pc and dap-config, sorry
> about that.
> 
> Please find a patch attached to fix that.

Thanks for the patch, I've prepared an NMU with it applied.

I can confirm that it fixes the libdap issue breaking the gdal build.
Unfortunately ecs.h from ogdi-dfsg still includes rpc/rpc.h also
breaking the gdal build.

@Alastair, when do you expect to upload a new revision of libdap with
this patch? If you don't have time, I can upload the NMU.

Kind Regards,

Bas

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

Bug#990235: RFS: python-pylatexenc/2.10-1 [ITP] -- Simple LaTeX parser providing conversion to/from unicode

[Diego M. Rodriguez]

Control: tags 990235 - moreinfo

Hello Jeroen,

thanks for the review and detailed reply:

On Fri, Aug 27, 2021, at 12:59, Jeroen Ploemen wrote:
> * The lintian hits on the binary pkg deserve an override:

Added two overrides - they are more vague than I would have liked, as it seems 
that the order in which the offending files are displayed in the warnings is 
not deterministic. The other alternative seemed to be adding 3x2 individual 
ones, but resulted in "mismatched-override" warnings.

> * Changelog: just the 'Initial release' line closing the ITP bug will do
>   for a new package.

Fixed the changelog, leaving the "Initial release" line.

> * Control: why the old compat level 12?

Likely it was the one I added when starting packaging a long time ago - bumped 
to 13.

> * Copyright: there's no mention of any copyright later than 2019 held by
>   Philippe Faist, yet grepping the upstream sources shows entries as
>   recent as 2021 for that person.

Thanks for catching these as well. I added explicit lines to d/copyright for 
the files that declare a copyright year different than the one declared in 
LICENSE.txt.

> * Rules: what is the override of dh_auto_clean trying to achieve?

Helping me clean up the package locally in previous iterations :) Removed, as 
indeed it was a leftover.

> * Rules: the help2man target seems to require an installed package in
>   order to succeed. Any way to make this work with just the extracted
>   source package? If not, a comment documenting the requirement would be
>   useful.

I could not find a sensible way to make it work - updated the comment in 
d/rules in the hopes of making it more explicit.

> * Tests: please add non-trivial autopkgtests, based on the upstream
>   testsuite.

Added, thanks again for the example.

> Please remove the moreinfo tag (and CC me directly) once you have an
> updated package ready.

Ditto - hopefully the latest version in salsa is ready for a new review.

Best,
---
Diego M. Rodriguez

Bug#992028: transition: libidn

[Simon Josefsson]

Hi!  With my ui-utilcpp NMU I think the libidn transition should be
complete, please compare:

https://release.debian.org/transitions/html/auto-libidn.html

but the ben rule is wrong so it matches some packages incorrectly.  I'm
not sure about is the clamv reverse dependency, does it have to be
fixed?  If so I can raise the severity and prepare a NMU of it, but on
IRC someone told me the clamav issue is not preventing completion.

Also, there is an arch:all missing build of libidn, is that a real
problem?  Should I do a binary upload to correct it?  I thought
source-only uploads was sufficient now.

/Simon


signature.asc
Description: PGP signature

Bug#993319: nfs-kernel-server: consider to ship exports(5) manpage in nfs-common

[Christoph Anton Mitterer]

Package: nfs-kernel-server
Version: 1:1.3.4-6
Severity: wishlist


Hi.

It may make sense to ship exports(5) manpage in nfs-common as the same file
is also used by other NFS server implementations (e.g. one of them would be
dCache (http://dcache.org/), which provides a pNFS 4.1 server).

And obvisouly one doesn't want to install nfs-kernel-server just to get the
documentation of that single file.

Cheers,
Chris.

Bug#989442: [Pkg-openssl-devel] Bug#989442: Debian: openssl: Add ARC target

[Sebastian Andrzej Siewior]

On 2021-08-30 16:37:11 [+], Alexey Brodkin wrote:
> On Thu, 3 Jun 2021 19:14:24 + Vineet Gupta  
> wrote: 
> > This is needed to bootstrap arc port. 
> > Patch attached. 
> 
> Ping!

Urgh. Sorry, thanks for the ping.

> -Alexey

Sebastian

Bug#993318: bullseye-pu: package golang-1.15/1.15.15-1~deb11u1

[Shengjing Zhu]

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

[ Reason ]
Update golang-1.15 to upstream latest minor release.
The Go upstream has minor release with only important bugfix are backported.
Uptream policy: https://github.com/golang/go/wiki/MinorReleases
> security issues, serious problems with no workaround, and documentation fixes
> are backported

So I'd like to bring the latest minor version to bullseye.

This 1.15.15 version also includes a non-urgent security fix for CVE-2021-36221.

The full issues between 1.15.9(version in bullseye) to 1.15.15

+ Go1.15.10
  https://github.com/golang/go/milestone/204?closed=1
+ Go1.15.11
  https://github.com/golang/go/milestone/208?closed=1
+ Go1.15.12
  https://github.com/golang/go/milestone/209?closed=1
+ Go1.15.13
  https://github.com/golang/go/milestone/215?closed=1
+ Go1.15.14
  https://github.com/golang/go/milestone/217?closed=1
+ Go1.15.15
  https://github.com/golang/go/milestone/220?closed=1

[ Impact ]
Fix many issues which are considered to be important by upstream.

[ Tests ]
Go1.15.15 is in testing for many days and many packages have been built with
this version.
Meanwhile upstream has extensive tests for their minor release.

[ Risks ]
I don't think there's risk.

[ 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 diff is big, so I only paste the diffstat here, and attach a link to the 
full diff.

 VERSION|2 
 debian/changelog   |   20 
 debian/control |4 
 debian/control.in  |4 
 debian/patches/0007-CVE-2021-31525.patch   |   45 --
 debian/patches/0008-CVE-2021-33196.patch   |  124 -
 debian/patches/0009-CVE-2021-33195-1.patch |  369 -
 debian/patches/0010-CVE-2021-33195-2.patch |  111 -
 debian/patches/0011-CVE-2021-33197.patch   |  147 --
 debian/patches/0012-CVE-2021-33198.patch   |  107 
 debian/patches/0013-CVE-2021-34558.patch   |   46 --
 debian/patches/series  |7 
 misc/cgo/testcshared/cshared_test.go   |   97 
 src/archive/zip/reader.go  |   10 
 src/archive/zip/reader_test.go |   59 ++
 src/cmd/cgo/out.go |6 
 src/cmd/compile/internal/gc/escape.go  |7 
 src/cmd/compile/internal/ssa/gen/ARM.rules |  128 ++---
 src/cmd/compile/internal/ssa/gen/ARM64Ops.go   |9 
 src/cmd/compile/internal/ssa/opGen.go  |6 
 src/cmd/compile/internal/ssa/rewriteARM.go |  306 +++---
 src/cmd/compile/internal/ssa/shortcircuit.go   |   18 
 src/cmd/go/go_test.go  |   33 +
 src/cmd/go/internal/load/pkg.go|5 
 src/cmd/go/internal/modcmd/tidy.go |2 
 src/cmd/go/internal/modcmd/vendor.go   |4 
 src/cmd/go/internal/modfetch/cache.go  |   17 
 src/cmd/go/internal/modfetch/fetch.go  |   77 ++-
 src/cmd/go/internal/modload/init.go|6 
 src/cmd/go/internal/modload/load.go|   32 +
 src/cmd/go/testdata/script/list_err_cycle.txt  |   15 
 src/cmd/go/testdata/script/mod_get_missing_ziphash.txt |   55 ++
 src/cmd/go/testdata/script/mod_readonly.txt|6 
 src/cmd/go/testdata/script/mod_tidy_error.txt  |4 
 src/cmd/go/testdata/script/mod_tidy_too_new.txt|   31 +
 src/cmd/go/testdata/script/mod_verify.txt  |7 
 src/cmd/link/internal/arm/asm.go   |   16 
 src/cmd/link/internal/ld/data.go   |   12 
 src/cmd/link/internal/ld/elf.go|2 
 src/cmd/link/internal/ld/lib.go|   11 
 src/cmd/link/internal/ld/macho.go  |2 
 src/cmd/link/internal/loader/loader.go |   12 
 src/cmd/link/internal/ppc64/asm.go |   26 -
 src/crypto/tls/key_agreement.go|6 
 src/database/sql/sql.go|   14 
 src/database/sql/sql_test.go   |   28 +
 src/go.mod |2 
 src/go.sum |4 
 src/internal/poll/copy_file_range_linux.go |   10 
 src/internal/poll/sendfile_bsd.go  |4 
 src/internal/poll/sendfile_linux.go|

Bug#992867: root cause found

[積丹尼 Dan Jacobson]

https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/35#note_1045802

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Ole Tange]

On Mon, Aug 30, 2021 at 3:38 PM Andreas Tille  wrote:
:
> I admit I also considered a wrapper but with a different functionality:
> Simply check whether --citation was used before and if not do so.

If you mean a wrapper similar to this, then that would be a compromise
I can live with:

if [ -t 2 -a ! -e "$HOME/.citation-run" ] ; then
  # Only run if stderr is a terminal (to avoid breaking scripts)
  parallel.real --citation
  touch "$HOME/.citation-run"
fi
parallel.real "$@"

By testing if stderr is redirected this should avoid breaking scripts
(e.g. cron jobs or similar).

To me it would feel similar to a dialog box, where you have to click
"Don't show this again" to continue the first time. This is not that
uncommon in graphical tools, so there is some precedence for this.

I find it less than optimal, but if we can find common ground on that,
it would be a compromise I can live with.


/Ole

Bug#993317: golang-github-checkpoint-restore-go-criu: Please upgrade to upstream version 5.1.0

[Reinhard Tartler]

Source: golang-github-checkpoint-restore-go-criu
Severity: normal

This is needed for podman 3.0:

https://github.com/containers/podman/blob/v3.3.0/go.mod#L10


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

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

Bug#992439: libconfig-model-dpkg-perl: blocks fails autopkgtest with recent licensecheck

[Jonas Smedegaard]

Control: seerity -1 serious

Quoting gregor herrmann (2021-08-20 02:57:28)
> Right, there is e.g.
> https://ci.debian.net/data/autopkgtest/testing/amd64/libc/libconfig-model-dpkg-perl/14728439/log.gz
> with libconfig-model-dpkg-perl/2.147 licensecheck/3.2.11-1 and
> 
> #v+
> not ok 7 - check scikit-learn copyright
> 
> #   Failed test 'check scikit-learn copyright'
> #   at t/scanner/scan-copyright.t line 27.
> # --- t/scanner/examples/scikit-learn.out   Thu Aug 19 00:15:51 2021
> # +++ /tmp/cKnQzIwFn2   Thu Aug 19 14:57:19 2021
> # @@ -2,3 +2,7 @@
> #  Copyright: 2007-2019, The scikit-learn developers.
> #  License: BSD-3-clause
> #  
> # +Files: sklearn/*
> # +Copyright: no-info-found
> # +License: BSD-3-clause
> # +
> #v-

Right, that's the one.


> And I still can't reproduce the failure locally.
[...]
> I wonder if this is some locale/collation issue …
[...]
> Well, uploaded 2.148; I'm doubtful this helps but at least a 
> reproducible output might make it easier to further investigate …

I cannot see how this can be caused by any changes to _documented_ 
interface of licensecheck - e.g. a change to collation would need to be 
handled internally in the testsuite, since licensecheck does not promise 
any specific order.

I am raising severity, since this is blocking licensecheck from entering 
testing.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#993164: proftpd-core: When upgrading from Buster to Bullseyes, the installation of ProFTPd fails

[Hilmar Preuße]

Am 30.08.2021 um 10:16 teilte Andreas Günther mit:

Hi,


I have now deleted everything again

dpkg -r proftpd-core proftpd-basic proftpd-mod-crypto proftpd-mod-wrap

and downloaded all the necessary packages and try to install them in order.
First the package proftpd-core_1.3.7a + dfsg-12_amd64.deb. But that fails
again:

dpkg -i proftpd-core_1.3.7a+dfsg-12_amd64.deb

I would not expect that this works. Your specific proftp configuration 
needs to crypto and the wrap modules so I'd expect that the setup fails, 
b/c they could not be found.


However I still don't understand why the setup fails if they are at 
least in unpacked state.



Vormals nicht ausgewähltes Paket proftpd-core wird gewählt.
(Lese Datenbank ... 44962 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von proftpd-core_1.3.7a+dfsg-12_amd64.deb ...
Entpacken von proftpd-core (1.3.7a+dfsg-12) ...
proftpd-core (1.3.7a+dfsg-12) wird eingerichtet ...
usermod: Keine Änderungen
Synchronizing state of proftpd.service with SysV service script with /lib/
systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable proftpd
Failed to enable unit: Unit file /etc/systemd/system/proftpd.service is
masked.
dpkg: Fehler beim Bearbeiten des Paketes proftpd-core (--install):
  »installiertes proftpd-core-Skript des Paketes post-installation«-
Unterprozess gab den Fehlerwert 1 zurück
Trigger für man-db (2.9.4-2) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
  proftpd-core

I am still convinced that there is something wrong with this package.


--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file

[Vincent Lefevre]

Control: reassign -1 rpcbind 1.2.6-2
Control: retitle -1 rpcbind: missing /lib/systemd/system/rpcbind.service file

Oops, that's from rpcbind. I got confused with
/lib/systemd/system/rpcbind.target, which is provided by systemd.

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

Bug#969206: Info received (redmine: Could not find gem 'rails (~> 5.2.2)' in any of the gem sources listed in your Gemfile)

[Andre Heider]

Just going by the upstream commit history it looks like the initial 
rails>=6 transition is done.


Can we get a pre v5 release experimental package please?

Thanks,
Andre

Bug#993315: bullseye-pu: package im-config/0.46-1+deb11u1

[Shengjing Zhu]

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

[ Reason ]
Two fixes related to Fcitx5, the Chinese/Japanese/Korean input method.
+ 990742
  Fcitx5 should be preferred to Fcitx4. When upgrading from buster, which
  installs Fcitx4 by default, the old version may still around. So when
  both versions installed, the new one should be used.

+ 977203
  The input method related env for Fcitx5 should be "fcitx", not "fcitx5".
  Some property software may not recognize the "fcitx5" env, and results
  poor experience since they may fallback to legacy "xim" mode.

[ Impact ]

Bad input experience.

[ Tests ]
These two changes are already included in testing for some days, and I
have using it daily without problems.

Though I tested the version in testing, the version in testing are
identical to this one, except one non-functional change in bug-script.

[ Risks ]
None, the change is trivial.

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

[ Changes ]

diff -Nru im-config-0.46/debian/changelog im-config-0.46/debian/changelog
--- im-config-0.46/debian/changelog 2020-12-18 17:38:00.0 +0800
+++ im-config-0.46/debian/changelog 2021-08-30 23:54:06.0 +0800
@@ -1,3 +1,17 @@
+im-config (0.46-1+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+
+  [ Gunnar Hjalmarsson ]
+  * Replace "fcitx" with "fcitx5" in IM_CONFIG_PREFERRED_RULE variable
+(closes: #990742)
+
+  [ Shengjing Zhu ]
+  * Change IM_MODULE env for fcitx5 to "fcitx" (closes: #977203,
+LP: #1928360)
+
+ -- Shengjing Zhu   Mon, 30 Aug 2021 23:54:06 +0800
+
 im-config (0.46-1) unstable; urgency=medium
 
   * Team upload
diff -Nru 
im-config-0.46/debian/patches/Change-IM_MODULE-env-for-fcitx5-to-fcitx.patch 
im-config-0.46/debian/patches/Change-IM_MODULE-env-for-fcitx5-to-fcitx.patch
--- 
im-config-0.46/debian/patches/Change-IM_MODULE-env-for-fcitx5-to-fcitx.patch
1970-01-01 08:00:00.0 +0800
+++ 
im-config-0.46/debian/patches/Change-IM_MODULE-env-for-fcitx5-to-fcitx.patch
2021-08-30 23:54:06.0 +0800
@@ -0,0 +1,25 @@
+From: Gunnar Hjalmarsson 
+Date: Mon, 7 Jun 2021 09:29:12 +0200
+Subject: Change IM_MODULE env for fcitx5 to "fcitx"
+
+Closes: #977203
+Origin: https://salsa.debian.org/input-method-team/im-config/-/commit/53d6a32b
+---
+ data/23_fcitx5.rc | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/data/23_fcitx5.rc b/data/23_fcitx5.rc
+index e5e957b..c4a44cc 100644
+--- a/data/23_fcitx5.rc
 b/data/23_fcitx5.rc
+@@ -12,8 +12,8 @@ if [ "$IM_CONFIG_PHASE" = 1 ]; then
+ XMODIFIERS=@im=fcitx
+ 
+ # Let's assume all required modules are installed
+-GTK_IM_MODULE=fcitx5
+-QT_IM_MODULE=fcitx5
++GTK_IM_MODULE=fcitx
++QT_IM_MODULE=fcitx
+ CLUTTER_IM_MODULE=xim
+ 
+ fi
diff -Nru 
im-config-0.46/debian/patches/Replace-fcitx-with-fcitx5-in-IM_CONFIG_PREFERRED_RULE.patch
 
im-config-0.46/debian/patches/Replace-fcitx-with-fcitx5-in-IM_CONFIG_PREFERRED_RULE.patch
--- 
im-config-0.46/debian/patches/Replace-fcitx-with-fcitx5-in-IM_CONFIG_PREFERRED_RULE.patch
   1970-01-01 08:00:00.0 +0800
+++ 
im-config-0.46/debian/patches/Replace-fcitx-with-fcitx5-in-IM_CONFIG_PREFERRED_RULE.patch
   2021-08-30 23:54:06.0 +0800
@@ -0,0 +1,37 @@
+From: Gunnar Hjalmarsson 
+Date: Mon, 16 Aug 2021 22:16:00 +0200
+Subject: Replace "fcitx" with "fcitx5" in IM_CONFIG_PREFERRED_RULE
+
+Closes: #990742
+Origin: https://salsa.debian.org/input-method-team/im-config/-/commit/e35ee1d2
+---
+ default/im-config-Debian | 2 +-
+ default/im-config-Ubuntu | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/default/im-config-Debian b/default/im-config-Debian
+index bb574de..6c53132 100644
+--- a/default/im-config-Debian
 b/default/im-config-Debian
+@@ -30,7 +30,7 @@ CJKV_DEFAULT_DESKTOP="*"
+ CJKV_LOCALES="zh_TW:zh_HK:zh_SG:zh_CN:ja_JP:ko_KR:vi_VN"
+ 
+ # Set locale dependent preferred IM over standard auto mode if not GNOME
+-IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx:zh_TW,fcitx:zh_HK,fcitx:zh_SG,fcitx"
++IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx5:zh_TW,fcitx5:zh_HK,fcitx5:zh_SG,fcitx5"
+ 
+ # User and system wide configuration is normally done via im-config program.
+ # The above IM_CONFIG_PREFERRED_RULE sets locale dependent preferred IM
+diff --git a/default/im-config-Ubuntu b/default/im-config-Ubuntu
+index dfd537c..6ef8373 100644
+--- a/default/im-config-Ubuntu
 b/default/im-config-Ubuntu
+@@ -30,7 +30,7 @@ CJKV_DEFAULT_DESKTOP="LXQt"
+ CJKV_LOCALES="zh_TW:zh_HK:zh_SG:zh_CN:ja_JP:ko_KR:vi_VN"
+ 
+ # Set locale dependent preferred IM over standard auto mode if not GNOME
+-IM_CONFIG_PREFERRED_RULE="zh_CN,fcitx:zh_TW,fcitx:zh_HK,fcitx:zh_SG,fcitx"

Bug#992029: qemu-system-x86: microvm binary has no virtio device emulation

[Michael Tokarev]

Control: tag -1 + confirmed pending

09.08.2021 15:27, Hiroaki Mizuguchi wrote:

Package: qemu-system-x86
Version: 1:5.2+dfsg-11
Severity: wishlist

Dear Maintainer,

qemu-system-x86_64-mircovm binary has no virtio device emulation.
I want to use device emulations on qemu-system-x86_64-microvm,
   virtconsole
   virtio-blk-device
   virtio-net-device
   virtio-balloon-device
   virtio-rng-device

$ qemu-system-x86_64 -device ? |grep virtio | grep -v pci


A side note: please use "-device help" instead of "-device ?" as
you do, since "?" is subject to shell glob expansion and will
surprize you if your current directory will contain a file with
length of the name = 1.

Another side note: you can grep for virtio-bus instead of using
2 grep commands.

...


$ qemu-system-x86_64-microvm -device ? |grep virtio | grep -v pci
name "vhost-user-fs-device", bus virtio-bus
name "virtio-serial-device", bus virtio-bus
name "vhost-user-vsock-device", bus virtio-bus
name "vhost-vsock-device", bus virtio-bus


Yes. This was due to the way how we built the microvm binary.
It is the --without-default-devices configure option -- and as
stated in the configure help text, this option needs another,
--with-devices-foo=bar - to include actual list of devices we
need. And we didn't provide this list..

I reworked this part of the build procedure now and way more
virtio devices will be available in the next upload.

Thank you for the bugreport!

/mjt

Bug#993265: RFS: runit/2.1.2-42 -- system-wide service supervision

[Lorenzo]

On Mon, 30 Aug 2021 05:03:33 +0200
Adam Borowski  wrote:

> On Sun, Aug 29, 2021 at 07:02:49PM +0200, Lorenzo Puliti wrote:
> >  * Package name: runit
> >Version : 2.1.2-42
> 
> >  runit (2.1.2-42) unstable; urgency=medium
> >  .
> >* Release to unstable
> >* getty-run: add hvc0 service, disabled by default:
> >this is usually needed by Xen hypervisor
> >* Add a default-syslog virtual service:
> >to increase portability, services that log to syslog
> >can depend on this rather than on a specific
> >syslog daemon
> >* shutdown.c:
> >- try to fix FTBFS on Hurd (Closes: #992629)
> >- distinguish between halt and shutdown flags:
> >  The -r flag ( as reboot) now only works with shutdown;
> >  Add a -f flag to shutdown (skip fsck next boot);
> >  Add -F flag to shutdown (force fsck next boot);
> >  The -f (as force a shutdown) and -w/--wtmp-only flags now
> >   only work with halt.
> >  (Closes: #992631)
> >- Add a -n flag to halt, to skip sync() before
> > reboot/poweroff; also, always check for runit.nosync flag file
> > before invoking sync()  (Closes: #992641)
> >- make halt '-f' flag a noop when runit is init. This way
> > runit can use its own code to reboot/poweroff the system; users
> >  can still use the long '--force' option to force a shutdown
> >  without signaling the init (Closes: #899246)
> >* Update shutdown(8) manpage
> >* Bump Standards Version to 4.6.0, no change required
> >* Update lintian overrides for 'alternative init but not init.d
> > script'
> 
> Uploaded.

Thanks for the upload Adam :)

> 
> That "default-syslog" that's consists of a 10min sleep looks
> strange...



What I want to be able to do is

'sv start default-syslog  &&  sv check default-syslog  ||  exit 1'

in each service that sends its logs to a syslog deamon.
In order to use the 'sv check' command I need to define a service, a
run file. 
So the check file does the job ( runs through a list of supported
syslogs and return 0 if one is up) and the run file acts like
a timer (wakes up every 10min) that does nothing..
I'm very open to suggestions to improve this!

> 
> 
> Meow!

Lorenzo