Bug#990871: zfs-linux: periodic-trim should deal with SATA SSD with protocol > 3.0

[Aron Xu]

Package: src:zfs-linux
Version: 2.0.3-3
Severity: normal

periodic-trim's current behavior only deals with NVMe-only pools, to
be more clear this means all SSDs in the pool are using NVMe protocol.
This is not sufficient since there are many new SATA SSDs that come
with protocol version > 3.0.

For reference:

=== START OF INFORMATION SECTION ===
Model Family: Sandisk SATA Cloudspeed Max and GEN2 ESS SSDs
Device Model: SDLF1CRR-019T-1HA1
Serial Number: A028D942
LU WWN Device Id: 5 001173 101148678
Firmware Version: ZR11RPA1
User Capacity: 1,920,383,410,176 bytes [1.92 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: Solid State Device
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sat Jul 10 13:08:52 2021 CST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF INFORMATION SECTION ===
Device Model: Samsung SSD 870 QVO 8TB
Serial Number: S5SSNF0R400589B
LU WWN Device Id: 5 002538 f4147f25e
Firmware Version: SVQ01B6Q
User Capacity: 8,001,563,222,016 bytes [8.00 TB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is: SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sat Jul 10 13:06:12 2021 CST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Bug#990870: RFS: libfilezilla/0.30.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libfilezilla
   Version : 0.30.0-1
   Upstream Author : Tim Kosse 
 * URL : https://lib.filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/libfilezilla
   Section : libs

It builds those binary packages:

  libfilezilla15 - build high-performing platform-independent programs (runtime 
lib)
  libfilezilla-dev - build high-performing platform-independent programs 
(development)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.30.0-1.dsc

Changes since the last upload:

 libfilezilla (0.30.0-1) experimental; urgency=medium
 .
   * Team upload
   * New upstream version 0.30.0
   * Soname bump rename package to libfilezilla15

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

Instagram: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#990868: inxi -sysinfo

[Brian Falco]

I just done a quick inxi on a live mxlinux-cd.

[code]
System: Host:  Kernel: 4.19.0-16-amd64 x86_64 bits: 64 compiler: gcc v: 
8.3.0
parameters: BOOT_IMAGE=/antiX/vmlinuz quiet splasht nosplash
Desktop: Xfce 4.14.2 tk: Gtk 3.24.5 info: xfce4-panel wm: xfwm4 dm: LightDM 
1.26.0
Distro: MX-19.4_x64 patito feo March 31 2021 base: Debian GNU/Linux 10 (buster)
Machine: Type: Laptop System: LENOVO product: 20FMS0W32L v: ThinkPad T460 
serial: 
Chassis: type: 10 serial: 
Mobo: LENOVO model: 20FMS0W32L v: SDK0J40705 WIN serial:  UEFI: LENOVO
v: R06ET69W (1.43 ) date: 01/08/2020
Battery: ID-1: BAT1 charge: 38.2 Wh condition: 41.2/47.5 Wh (87%) volts: 
11.7/10.8
model: SANYO 45N1767 type: Li-ion serial:  status: Discharging
CPU: Topology: Dual Core model: Intel Core i5-6300U bits: 64 type: MT MCP arch: 
Skylake
family: 6 model-id: 4E (78) stepping: 3 microcode: D6 L2 cache: 3072 KiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 19968
Speed: 600 MHz min/max: 400/3000 MHz Core speeds (MHz): 1: 600 2: 600 3: 600 4: 
602
Vulnerabilities: Type: itlb_multihit status: KVM: Split huge pages
Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT 
vulnerable
Type: mds mitigation: Clear CPU buffers; SMT vulnerable
Type: meltdown mitigation: PTI
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl and seccomp
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer 
sanitization
Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW,
STIBP: conditional, RSB filling
Type: srbds status: Vulnerable: No microcode
Type: tsx_async_abort mitigation: Clear CPU buffers; SMT vulnerable
Graphics: Device-1: Intel HD Graphics 520 vendor: Lenovo Skylake GT2 driver: 
i915 v: kernel
bus ID: 00:02.0 chip ID: 8086:1916
Display: x11 server: X.Org 1.20.4 driver: modesetting unloaded: fbdev,vesa
resolution: 1366x768~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 520 (Skylake GT2) v: 4.5 Mesa 
18.3.6
compat-v: 3.0 direct render: Yes
Audio: Device-1: Intel Sunrise Point-LP HD Audio vendor: Lenovo driver: 
snd_hda_intel
v: kernel bus ID: 00:1f.3 chip ID: 8086:9d70
Sound Server: ALSA v: k4.19.0-16-amd64
Network: Device-1: Intel Ethernet I219-LM vendor: Lenovo driver: e1000e v: 
3.2.6-k port: efa0
bus ID: 00:1f.6 chip ID: 8086:156f
IF: eth0 state: down mac: 
Device-2: Intel Wireless 8260 driver: iwlwifi v: kernel port: efa0 bus ID: 
04:00.0
chip ID: 8086:24f3
IF: wlan0 state: down mac: 
Drives: Local Storage: total: 476.05 GiB used: 25.0 MiB (0.0%)
ID-1: /dev/sda vendor: Western Digital model: WDS480G2G0A-00JH30 size: 447.14 
GiB
block size: physical: 512 B logical: 512 B speed: 6.0 Gb/s serial:  
rev: 
scheme: GPT
ID-2: /dev/sdb type: USB vendor: Verbatim model: STORE N GO size: 28.91 GiB
block size: physical: 512 B logical: 512 B serial:  rev: PMAP scheme: 
MBR
Partition: ID-1: / raw size: N/A size: 12.35 GiB used: 25.0 MiB (0.2%) fs: 
overlay
source: ERR-102
Sensors: System Temperatures: cpu: 27.5 C mobo: N/A
Fan Speeds (RPM): cpu: 0
Repos: No active apt repos in: /etc/apt/sources.list
Active apt repos in: /etc/apt/sources.list.d/debian-stable-updates.list
1: deb http://deb.debian.org/debian buster-updates main contrib non-free
Active apt repos in: /etc/apt/sources.list.d/debian.list
1: deb http://deb.debian.org/debian buster main contrib non-free
2: deb http://deb.debian.org/debian-security buster/updates main contrib 
non-free
Active apt repos in: /etc/apt/sources.list.d/mx.list
1: deb http://mxrepo.com/mx/repo/ buster main non-free
No active apt repos in: /etc/apt/sources.list.d/various.list
Info: Processes: 194 Uptime: 1m Memory: 15.53 GiB used: 545.4 MiB (3.4%) Init: 
SysVinit
v: 2.93 runlevel: 5 default: 5 Compilers: gcc: 8.3.0 alt: 8 Shell: 
quick-system-in
running in: quick-system-in inxi: 3.0.36

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

t460-inxi
Description: Binary data

Bug#990849: dpkg-dev: dpkg-buildpackage fails trying multifile optimization with dwz on aarch64 and armv71

[Niels Thykier]

Guillem Jover:
> [...]
> On Fri, 2021-07-09 at 08:52:18 +, Dennis Bijwaard wrote:
>> Package: dpkg-dev
>> Version: 1.19.7
>> Severity: normal
>>
>> Dear all,
>>
>> [...]
>>
>> I found a work-around to at least create a package on these machines
>> using DEB_BUILD_OPTIONS=nostrip, but the package remains quite big. A regular
>> strip on the binaries does reduce them a bit, this could be an
>> alternative when dwz fails. Alternatively, it would be great if there
>> was an option to disable multifile option of dwz via e.g. DEB_BUILD_OPTIONS. 
>> Or is there already an easy way to pass the --no-dwz-multifile option to
>> dh_dzw when invoked via dpkg-buildpackage?
>>
>> Below is the trace of the failing dpkg-buildpackage.
>>
>> Kind regards
>> Dennis
>>
>> [...]


Hi Dennis,

>From memory, this bug has been fixed in bullseye (the up coming version
of Debian).  I urge you to retry with debhelper AND dwz from from
buster-backports[1] (or bullseye), which combined should solve this
issue for you on buster.
  In most cases, it should be a "simple" matter of adding backports to
your sources list and updating the version constraints on debhelper in
the Build-Depends field of debian/control (debhelper from backports
depends on the backports version of dwz) plus restarting the build
process - including the part of installing build-dependencies.
  If my starting points above are not sufficient guidance, then please
do consider asking for help in the #packaging IRC channel on
irc.debian.org with the details of your concrete situation.


If using backports (or bullseye) is not an option to you, then you can
deploy workarounds such as injecting a dwz in PATH that overrides the
default dwz or use the DH_EXTRA_ADDONS environment to load a custom
dh-addon that passes --no-dwz-multifile to dh_dwz.
  There might be concrete challenges in how you need to deploy them.  If
you are using a chroot (e.g., sbuild or pbuilder), you would have to
implement it _inside_ the chroot to have any effect (rather than
directly on your host system).  Again, I recommend the #packaging
channel from irc.debian.org if my short starting points above are
insufficient.

Thanks,
~Niels

PS: I have recommended the #packaging channel since I assumed you were
building the deb without intention to upload it to the Debian archive.
  If you are looking to upload it to the Debian archive, you should ask
in #debian-mentors instead.  But if so, please be advised that all
packages for the Debian archive will be introduced via unstable and
people in #debian-mentors will ask you to first ensure that your package
builds in unstable rather than in stable(-backports).

[1]: https://backports.debian.org/

Bug#990869: mirror submission for mirror.unair.ac.id

[Networking DSID Universitas Airlangga]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.unair.ac.id
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Networking DSID Universitas Airlangga 
Country: ID Indonesia




Trace Url: http://mirror.unair.ac.id/debian/project/trace/
Trace Url: http://mirror.unair.ac.id/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.unair.ac.id/debian/project/trace/mirror.unair.ac.id

Bug#990829: dh_missing: check doc installations (other dh_install*)

[Niels Thykier]

Control: tags -1 moreinfo

Drew Parsons:
> Package: debhelper
> Version: 13.3.4
> Severity: normal
> 
> dh_missing reports an error if files in debian/tmp have not been
> installed.  But it seems to only check installation by dh_install.
> 
> If doc files in debian/tmp are installed using dh_installdocs (e.g. by
> setting debian/package.docs), then dh_missing marks these doc files as
> "not-installed".
> 
> It would make sense for dh_missing to check files installed via the
> other debhelper install tools, not only dh_install (any of the
> dh_install* tools I guess).
> 
> [...]
> 

Hi,

dh_missing already does this but requires support from the other
dh-tools (see #972724 for details). The dh_installdocs tool _does_ its
part in registering the files it installs.

Given you are reporting this bug, I assume you got into a situation
where it does not work for you.  But the bug report does not not provide
context of your concrete situation, so I can only wonder what has gone
wrong. My best guess is that the package has the "wrong" file name in
the .docs file.
  A common example is to use "src/.../doc-file" rather than
"usr/share/.../doc-file", which can make dh_missing report an "false
issue" if doc-file ends up being compressed by dh_compress.

However, I hope you will follow up with additional details - including a
concrete debian directory (link to web browable git is fine) as well as
a build log.  Without this, the bug is not actionable for me.

Thanks,
~Niels

Bug#986410: autopkg tests don't run with the same dependencies as during the build

[Étienne Mollier]

Hi Matthias,

Matthias Klose, on 2021-04-05:
> On 4/5/21 3:30 PM, Andreas Tille wrote:
> > On Mon, Apr 05, 2021 at 02:46:41PM +0200, Matthias Klose wrote:
> >> The autopkg tests don't run with the same dependencies as during the 
> >> build. Just
> >> noticed because the python3-renderpm dependency seems to be necessary with 
> >> the
> >> reportlab package from experimental.
> >>
> >> But in general, please run the autopkg tests with the same packages as done
> >> during the build.
> > 
> > Could you please be more verbose.  The Build-Depends and Depends string
> > do not do any specific version specification.  Python3-reportlab was
> > added to Depends since it is really needed while python3-renderpm is
> > fine as "Suggests".  Which change would you recommend to solve that bug?
> 
> please re-read. This is not about package dependencies or suggestions. All the
>  build dependencies should be added as autopkg test dependencies to
> test the same stuff you test during the build, unless there's a specific 
> reason
> not to do so.

One of the uses we have of autopkgtest, among other things, is
to check that there are no missing dependencies in the packages;
so I think that is one reason why the  build
dependencies are missing.  In biopython context, the package
might have different behavior, depending on available tools on
the machine.  So I agree it makes good sense to have testings
with different combinations of packages installed on the target
system.  I actually implemented a second test, in addition to
the existing one, which includes all the test check
dependencies, and which should make it in an upcoming update,
after bullseye release.

The only concern I have is the maintainability of a full_suite
test, since there are no needs-build-deps restrictions, and I
don't really expect it would happen, since deprecation of
needs-recommends (IIUC, it caused problems of reproducibility of
issues in autopkgtests).  However, it might also highlight newer
missing tools when proceeding to upgrades, so this might be a
non-problem.  Any ways, this package has a lot of reverse
dependencies, so we might be better off having too many tests
than not enough.

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


signature.asc
Description: PGP signature

Bug#990862: infinipath-psm: reproducible builds: Embedded timestamps in libpsm_infinipath.so

[Vagrant Cascadian]

On 2021-07-09, Vagrant Cascadian wrote:
> On 2021-07-09, Vagrant Cascadian wrote:
>> diff --git a/buildflags.mak b/buildflags.mak
>> index 34fdf1c..3e25649 100644
>> --- a/buildflags.mak
>> +++ b/buildflags.mak
>> @@ -96,3 +96,11 @@ endif
>>  CFLAGS += $(BASECFLAGS) $(if $(filter $(CC),gcc),-Wno-strict-aliasing) \
>>  $(if $(PSM_VALGRIND:0=),-DPSM_VALGRIND,-DNVALGRIND)
>>  
>> +# Use SOURCE_DATE_EPOCH for build date, falling back to current time
>> +# https://reproducible-builds.org/docs/source-date-epoch/
>> +DATE_FMT="+'%F %R'"
>> +ifdef FIXME_SOURCE_DATE_EPOCH
>
> ^^^ OopS! that was my debugging attempt to make sure it works when
> SOURCE_DATE_EPOCH is not set.
>
> It *should* be:
>
>   ifdef SOURCE_DATE_EPOCH
>
>> +BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 
>> 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null 
>> || date -u "$(DATE_FMT)")
>> +else
>> +BUILD_DATE ?= $(shell date "$(DATE_FMT)")
>> +endif
>
> Will send updated patch...

Corrected patch attached. Sorry for the mixup!


live well,
  vagrant
From 88b66063c5f02ba48f2fc9cfa2ae6cc42c950cc8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 9 Jul 2021 15:13:24 +
Subject: [PATCH] Use the build date from SOURCE_DATE_EPOCH if set, falling
 back to current time.

https://reproducible-builds.org/docs/source-date-epoch/
---
 Makefile   | 2 +-
 buildflags.mak | 8 
 ipath/Makefile | 2 +-
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index d79c4bd..64d6f6b 100644
--- a/Makefile
+++ b/Makefile
@@ -270,7 +270,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
 # file around.  Generate it such that the ident command can find it
 # and strings -a | grep InfiniPath does a reasonable job as well.
 ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
-	date +'char psmi_infinipath_revision[] ="$$""Date: %F %R ${rpm_extra_description}InfiniPath $$";' > ${lib_build_dir}/_revision.c
+	printf 'char psmi_infinipath_revision[] ="$$""Date: %s ${rpm_extra_description} InfiniPath $$";\n' "$(BUILD_DATE)" > ${lib_build_dir}/_revision.c
 	$(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
 	$(CC) $(LDFLAGS) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared -Wl,--unique='*fastpath*' \
 		${${TARGLIB}-objs} _revision.o -L$(build_dir)/ipath $(LDLIBS)
diff --git a/buildflags.mak b/buildflags.mak
index 34fdf1c..be40c40 100644
--- a/buildflags.mak
+++ b/buildflags.mak
@@ -96,3 +96,11 @@ endif
 CFLAGS += $(BASECFLAGS) $(if $(filter $(CC),gcc),-Wno-strict-aliasing) \
 	$(if $(PSM_VALGRIND:0=),-DPSM_VALGRIND,-DNVALGRIND)
 
+# Use SOURCE_DATE_EPOCH for build date, falling back to current time
+# https://reproducible-builds.org/docs/source-date-epoch/
+DATE_FMT="+'%F %R'"
+ifdef SOURCE_DATE_EPOCH
+BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u "$(DATE_FMT)")
+else
+BUILD_DATE ?= $(shell date "$(DATE_FMT)")
+endif
diff --git a/ipath/Makefile b/ipath/Makefile
index 8c2cc6e..e627b3d 100644
--- a/ipath/Makefile
+++ b/ipath/Makefile
@@ -70,7 +70,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
 # file around.  Generate it such that the ident command can find it
 # and strings -a | grep InfiniPath does a reasonable job as well.
 ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
-	date +'static __attribute__ ((unused)) char __psc_infinipath_revision[] ="$$""Date: %F %R ${rpm_extra_description}InfiniPath $$";' > _revision.c
+	printf 'static __attribute__ ((unused)) char __psc_infinipath_revision[] ="$$""Date: %s ${rpm_extra_description}InfiniPath $$";\n' "$(BUILD_DATE)" > _revision.c
 	$(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
 	$(CC) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared \
 		-Wl,--unique='*fastpath*' \
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#740503: Medal Supplier.

[top to]

Hello,
Good day.
We are manufacturers of all kinds of MEDAL in China.
If you are interested.kindly reply to know more about us and contact us for 
your order.
We deliver worldwide at the cheapest prices.

Also we have our own professional designers to meet any of your requirements.
Sincerely,
Andy

Bug#987441: Suggest bug 990016; easy to fix for D-I, and hits specific server boards hard

[cropper]

Might I suggest bug #990016 for the D-I urgency list; many of my server boards 
have ASPEED drivers and I've been surprised how sometimes this bites me and 
sometimes not.

Please consider fixing this before releasing the production installer for 
Bullseye.

Thank you.

Bug#990867: shim-helpers-arm64-signed: post-install script fails with 'error exit status 1'

[Diederik de Haas]

Package: shim-helpers-arm64-signed
Version: 1+15.4+6
Severity: important

Running 'aptitude safe-upgrade' on my Bullseye/Sid/Experimental system
fails:

Unpacking shim-unsigned (15.4-6) over (15.4-5) ...
Preparing to unpack .../3-shim-helpers-arm64-signed_1+15.4+6_arm64.deb ...
Unpacking shim-helpers-arm64-signed (1+15.4+6) over (1+15.4+5) ...
Preparing to unpack .../4-shim-signed-common_1.37+15.4-6_all.deb ...
Unpacking shim-signed-common (1.37+15.4-6) over (1.36+15.4-5) ...
Preparing to unpack .../5-shim-signed_1.37+15.4-6_arm64.deb ...
Unpacking shim-signed:arm64 (1.37+15.4-6) over (1.36+15.4-5) ...
Setting up libuv1:arm64 (1.40.0-2) ...
Setting up shim-signed-common (1.37+15.4-6) ...
No DKMS packages installed: not changing Secure Boot validation state.
Setting up udev (249-1) ...
Setting up python3-urllib3 (1.26.5-1~exp1) ...
Setting up shim-unsigned (15.4-6) ...
Setting up shim-helpers-arm64-signed (1+15.4+6) ...
Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot.
grub-install: warning: efivarfs_set_variable: failed to open 
/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c for 
writing: Read-only file system.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: 
Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only file 
system.
dpkg: error processing package shim-helpers-arm64-signed (--configure):
 installed shim-helpers-arm64-signed package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of shim-signed:arm64:
 shim-signed:arm64 depends on shim-helpers-arm64-signed (>= 1+15.4+2); however:
  Package shim-helpers-arm64-signed is not configured yet.

dpkg: error processing package shim-signed:arm64 (--configure):
 dependency problems - leaving unconfigured
Setting up systemd (249-1) ...
Setting up systemd-timesyncd (249-1) ...
Setting up systemd-sysv (249-1) ...
Setting up libpam-systemd:arm64 (249-1) ...
Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-5.10.47-rock64-5-g0df86ccf5feb
W: Possible missing firmware /lib/firmware/renesas_usb_fw.mem for built-in 
driver xhci_pci
W: Possible missing firmware /lib/firmware/r8a779x_usb3_v3.dlmem for built-in 
driver xhci_plat_hcd
W: Possible missing firmware /lib/firmware/r8a779x_usb3_v2.dlmem for built-in 
driver xhci_plat_hcd
W: Possible missing firmware /lib/firmware/r8a779x_usb3_v1.dlmem for built-in 
driver xhci_plat_hcd
W: Possible missing firmware /lib/firmware/nvidia/tegra194/xusb.bin for 
built-in driver xhci_tegra
W: Possible missing firmware /lib/firmware/nvidia/tegra186/xusb.bin for 
built-in driver xhci_tegra
W: Possible missing firmware /lib/firmware/nvidia/tegra210/xusb.bin for 
built-in driver xhci_tegra
W: Possible missing firmware /lib/firmware/nvidia/tegra124/xusb.bin for 
built-in driver xhci_tegra
I: The initramfs will attempt to resume from /dev/sda1
I: (UUID=d97f0a17-fc61-403c-92f3-af5e2a7b33f8)
I: Set the RESUME variable to override this.
Processing triggers for libc-bin (2.31-12) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for dbus (1.13.18-2) ...
Errors were encountered while processing:
 shim-helpers-arm64-signed
 shim-signed:arm64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up shim-helpers-arm64-signed (1+15.4+6) ...
Installing for arm64-efi platform.
grub-install: warning: Cannot set EFI variable Boot.
grub-install: warning: efivarfs_set_variable: failed to open 
/sys/firmware/efi/efivars/Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c for 
writing: Read-only file system.
grub-install: warning: _efi_set_variable_mode: ops->set_variable() failed: 
Read-only file system.
grub-install: error: failed to register the EFI boot entry: Read-only file 
system.
dpkg: error processing package shim-helpers-arm64-signed (--configure):
 installed shim-helpers-arm64-signed package post-installation script 
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of shim-signed:arm64:
 shim-signed:arm64 depends on shim-helpers-arm64-signed (>= 1+15.4+2); however:
  Package shim-helpers-arm64-signed is not configured yet.

dpkg: error processing package shim-signed:arm64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 shim-helpers-arm64-signed
 shim-signed:arm64

If the issue is in grub/grub-efi-arm64, feel free to reassign.

I've had this problem before and at some point found a fix/workaround,
but I wasn't smart enough to write that down. 
I know that now every aptitude safe-upgrade will give me this error :-/

 $ ls -l /sys/firmware/efi/efivars/
total 0
-rw-r--r-- 1 root root   5  1 jul 23:55 
AuditMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 124  1 jul 23:55 
Boot-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   6  1 jul 23:55 

Bug#990866: unblock: postgresql-13/13.3-1

[Christoph Berg]

> 
> [ Checklist ]
>   [x] attach debian/ diff against the package in testing

Now for real.

Christoph
diff --git a/debian/changelog b/debian/changelog
index 2f18705..38aedbf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,47 @@
+postgresql-13 (13.3-1) unstable; urgency=medium
+
+  * New upstream version.
+
++ Prevent integer overflows in array subscripting calculations (Tom Lane)
+
+  The array code previously did not complain about cases where an array's
+  lower bound plus length overflows an integer.  This resulted in later
+  entries in the array becoming inaccessible (since their subscripts could
+  not be written as integers), but more importantly it confused subsequent
+  assignment operations.  This could lead to memory overwrites, with
+  ensuing crashes or unwanted data modifications. (CVE-2021-32027)
+
++ Fix mishandling of junk columns in INSERT ... ON CONFLICT ... UPDATE
+  target lists (Tom Lane)
+
+  If the UPDATE list contains any multi-column sub-selects (which give
+  rise to junk columns in addition to the results proper), the UPDATE path
+  would end up storing tuples that include the values of the extra junk
+  columns. That's fairly harmless in the short run, but if new columns are
+  added to the table then the values would become accessible, possibly
+  leading to malfunctions if they don't match the datatypes of the added
+  columns.
+
+  In addition, in versions supporting cross-partition updates, a
+  cross-partition update triggered by such a case had the reverse problem:
+  the junk columns were removed from the target list, typically causing an
+  immediate crash due to malfunction of the multi-column sub-select
+  mechanism. (CVE-2021-32028)
+
++ Fix possibly-incorrect computation of UPDATE ... RETURNING outputs for
+  joined cross-partition updates (Amit Langote, Etsuro Fujita)
+
+  If an UPDATE for a partitioned table caused a row to be moved to another
+  partition with a physically different row type (for example, one with a
+  different set of dropped columns), computation of RETURNING results for
+  that row could produce errors or wrong answers.  No error is observed
+  unless the UPDATE involves other tables being joined to the target
+  table. (CVE-2021-32029)
+
+  * Mark libio-pty-perl and libipc-run-perl as . (Closes: #988121)
+
+ -- Christoph Berg   Tue, 11 May 2021 22:10:35 +0200
+
 postgresql-13 (13.2-1) unstable; urgency=medium
 
   * New upstream version.
diff --git a/debian/control b/debian/control
index ee5acf8..8913183 100644
--- a/debian/control
+++ b/debian/control
@@ -20,8 +20,8 @@ Build-Depends:
  gdb ,
  gettext,
  libicu-dev,
- libio-pty-perl,
- libipc-run-perl,
+ libio-pty-perl ,
+ libipc-run-perl ,
  libkrb5-dev,
  libldap2-dev,
  libpam0g-dev | libpam-dev,
diff --git a/debian/rules b/debian/rules
index c115945..e70a10e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -76,6 +76,7 @@ COMMON_CONFIGURE_FLAGS= \
   $(SELINUX_FLAGS) \
   $(SPINLOCK_FLAGS) \
   MKDIR_P='/bin/mkdir -p' \
+  PROVE='/usr/bin/prove' \
   TAR='/bin/tar' \
   XSLTPROC='xsltproc --nonet' \
   CFLAGS='$(CFLAGS)' \

Bug#990857: [Pkg-javascript-devel] Bug#990857: Bug#990857: node-millstone: autopkgtest failure

[Jérémy Lal]

Le ven. 9 juil. 2021 à 22:57, Yadd  a écrit :

>
>
> Le 9 juillet 2021 19:32:21 GMT+02:00, "Jérémy Lal"  a
> écrit :
> >Le ven. 9 juil. 2021 à 15:39, Gianfranco Costamagna <
> >locutusofb...@debian.org> a écrit :
> >
> >> Source: node-millstone
> >> Version: 0.6.19-4
> >> Severity: serious
> >>
> >> Hello, for some reasons the autopkgtest is now failing due to:
> >> Uncaught Error: Unable to download '
> >> http://upload.wikimedia.org/wikipedia/commons/7/72/Cup_of_coffee.svg'
> for
> >> 'style.mss' (server returned 429)
> >>
> >
> >Ough !
> >Are tests supposed to download stuff from internet ?
> >
> >Jérémy
>
> Yes, it's the goal of this package (autopkgtest tagged with needs-internet)


Bummer
429 Too Many Requests

Bug#990818: rtags: flaky autopkgtest: regularly times out after 2:47 h

[danilovdenis]

On Thu, 8 Jul 2021 12:39:43 +0200 Paul Gevers  wrote:
> Source: rtags
> Version: 2.38-3
> Severity: serious
> Tags: bulleye-ignore
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky timeout
> 
> Dear maintainer(s),
> 
> Your package has an autopkgtest, great. However, due to glibc reporting
> a regression, I looked into the history of your autopkgtest [1] and I
> noticed it fails regularly on ppc64el (and I spotted a similar failure
> on i386). I copied some of the output at the bottom of this report. It
> hits the autopkgtest time out after 2hours and 47 minutes. Successful
> runs pass in a couple of minutes.
> 
> Because the unstable-to-testing migration software now blocks on
> regressions in testing, flaky tests, i.e. tests that flip between
> passing and failing without changes to the list of installed packages,
> are causing people unrelated to your package to spend time on these
> tests.
> 
> Don't hesitate to reach out if you need help and some more information
> from our infrastructure.
> 
> Paul
> 
> [Release team member hat on: as we are so late in the freeze, I don't
> want this bug to kick your package out of bulleye. Hence, the
> bulleye-ignore tag.]
> 
> [1] https://ci.debian.net/packages/r/rtags/testing/ppc64el/
> 
> https://ci.debian.net/data/autopkgtest/testing/ppc64el/r/rtags/13432732/log.gz
> 
> autopkgtest [01:18:38]: test run-test: [---
> = test session starts
> ==
> platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0
> -- /usr/bin/python3
> cachedir: .pytest_cache
> rootdir: /tmp/autopkgtest-lxc.5r1qzd3h/downtmp/build.A6f/src
> collecting ... collected 14 items
> 
> tests/automated/test_misc.py::test_location[InlineConstructorWrongTarget] 
> PASSED
> tests/automated/test_misc.py::test_location[ClassTemplatesMultipleTU] PASSED
> tests/automated/test_misc.py::test_location[OneTU] PASSED
> tests/automated/test_misc.py::test_location[ClassTemplates] PASSED
> tests/automated/test_misc.py::test_location[MetaPrograms] PASSED
> tests/automated/test_misc.py::test_location[ForwardDeclaration] PASSED
> tests/automated/test_misc.py::test_location[AnonymousUnion] PASSED
> tests/automated/test_misc.py::test_location[FunctionTemplates] PASSED
> tests/automated/test_misc.py::test_location[MultipleTU] PASSED
> tests/automated/test_misc.py::test_location[FunctionPointerField] PASSED
> tests/automated/test_misc.py::test_parse[Parsing] PASSED
> tests/automated/test_misc.py::test_completion[Completion] PASSED
> tests/automated/test_misc.py::test_output[PrintIncludePathOutput]
> autopkgtest [04:05:18]: ERROR: timed out on command "su -s /bin/bash
> debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||

Bug#990866: unblock: postgresql-13/13.3-1

[Christoph Berg]

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

Please unblock package postgresql-13

[ Reason ]
The new version fixes CVE-2021-32027 CVE-2021-32028 CVE-2021-32029,
and other bugs.

[ Tests ]
PG itself has an extensive testsuite running at build and autopkgtest
time, and the postgresql-common testsuite is also running on the
package.

[ Risks ]
I had thought the package would migrate by itself and hence had not
followed up. There is one crashing bug in 13.2 exposed by the 13.3
testsuite that just made me aware the migration hasn't happened yet:

SELECT i, to_char(i * interval '1mon', 'rm'),
  to_char(i * interval '1mon', 'RM')
FROM generate_series(-13, 13) i;

[ Checklist ]
  [x] all debian/ changes are documented in the d/changelog
  [x] I reviewed all debian/ changes and I approve them
  [x] attach debian/ diff against the package in testing

[ Other info ]
New PostgreSQL upstream versions are waived by the security team, so
this new version would have been acceptable for bullseye-security
which should make it acceptable for bullseye as well.

unblock postgresql-13/13.3-1

Christoph


signature.asc
Description: PGP signature

Bug#990818: rtags: flaky autopkgtest: regularly times out after 2:47 h

[Denis Danilov]

Hi Paul,

> a regression, I looked into the history of your autopkgtest [1] and I
> noticed it fails regularly on ppc64el (and I spotted a similar failure
> on i386). I copied some of the output at the bottom of this report. It
> hits the autopkgtest time out after 2hours and 47 minutes. Successful
> runs pass in a couple of minutes.

indeed, there are sporadic failures, mostly on ppc64el, but also on amd64.

> tests/automated/test_misc.py::test_output[PrintIncludePathOutput]
> autopkgtest [04:05:18]: ERROR: timed out on command "su -s /bin/bash

they all fail (by timeout) on the same test "PrintIncludePathOutput".
I will try to check and debug corresponding code in rtags daemon/client.

Denis

Bug#990865: lxml: remove python3-lxml from Build-Depends

[Sebastian Ramacher]

Source: lxml
Version: 4.6.3+dfsg-0.1
Severity: normal
Tags: patch
X-Debbugs-Cc: sramac...@debian.org

The latest lxml upload introduced a build dependency on itself to build
the documentation. The attached patch fixes that.

Cheers
-- 
Sebastian Ramacher
diff -Nru lxml-4.6.3+dfsg/debian/changelog lxml-4.6.3+dfsg/debian/changelog
--- lxml-4.6.3+dfsg/debian/changelog2021-06-26 19:40:37.0 +0200
+++ lxml-4.6.3+dfsg/debian/changelog2021-07-07 22:20:51.0 +0200
@@ -1,3 +1,10 @@
+lxml (4.6.3+dfsg-0.2) UNRELEASED; urgency=medium
+
+  * Only build documentation for the default Python version
+  * Build documentation for the currently built version of lxml
+
+ -- Sebastian Ramacher   Wed, 07 Jul 2021 22:20:51 +0200
+
 lxml (4.6.3+dfsg-0.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru lxml-4.6.3+dfsg/debian/control lxml-4.6.3+dfsg/debian/control
--- lxml-4.6.3+dfsg/debian/control  2021-06-26 19:40:37.0 +0200
+++ lxml-4.6.3+dfsg/debian/control  2021-07-07 22:20:47.0 +0200
@@ -9,7 +9,6 @@
   python3-setuptools (>= 0.6.29),
   python3-bs4,
   python3-html5lib,
-  python3-lxml ,
   cython3, cython3-dbg,
   python3-sphinx-autoapi,
 X-Python-Version: all
diff -Nru lxml-4.6.3+dfsg/debian/rules lxml-4.6.3+dfsg/debian/rules
--- lxml-4.6.3+dfsg/debian/rules2021-06-26 19:40:37.0 +0200
+++ lxml-4.6.3+dfsg/debian/rules2021-07-07 22:20:51.0 +0200
@@ -20,12 +20,14 @@
 build-indep: build
 build: build3-stamp
 
-build3-stamp: $(PY3VERS:%=build3-python%) $(PY3VERS:%=dbg-build3-python%)
+build3-stamp: $(PY3VERS:%=build3-python%) $(PY3VERS:%=dbg-build3-python%) 
doc-build3-python$(PY3VER)
touch $@
 build3-python%: prebuild
python$* setup.py build
+   touch $@
+doc-build3-python$(PY3VER): build3-python$(PY3VER)
 ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
-   python$* doc/mkhtml.py doc/html . $(UPSTREAMVER)
+   PYTHONPATH=$(call py_builddir, $(PY3VER)) python$(PY3VER) doc/mkhtml.py 
doc/html . $(UPSTREAMVER)
 endif
touch $@
 dbg-build3-python%: prebuild


signature.asc
Description: PGP signature

Bug#990857: [Pkg-javascript-devel] Bug#990857: Bug#990857: node-millstone: autopkgtest failure

[Yadd]

Le 9 juillet 2021 19:32:21 GMT+02:00, "Jérémy Lal"  a écrit :
>Le ven. 9 juil. 2021 à 15:39, Gianfranco Costamagna <
>locutusofb...@debian.org> a écrit :
>
>> Source: node-millstone
>> Version: 0.6.19-4
>> Severity: serious
>>
>> Hello, for some reasons the autopkgtest is now failing due to:
>> Uncaught Error: Unable to download '
>> http://upload.wikimedia.org/wikipedia/commons/7/72/Cup_of_coffee.svg' for
>> 'style.mss' (server returned 429)
>>
>
>Ough !
>Are tests supposed to download stuff from internet ?
>
>Jérémy

Yes, it's the goal of this package (autopkgtest tagged with needs-internet)

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#989837: aircrack-ng: install script dcrack

[Samuel Henrique]

Hello Sophie,

Sorry I missed this bug report before the freeze, I believe that is a good idea.

I think you now have access to the repos under our team, so feel free
to push changes to any package I maintain without consulting me
(unless you want to check something first).

I will also take care of this issue soon (after the freeze) if you
don't get to it before myself.

Thanks,

-- 
Samuel Henrique 

Bug#990035: less dies with double free

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look and could reproduce the issue.

It seems this got already fixed upstream in [1].
Also a related upstream issue exists [2].

A package built with this patch applied does
not show the fault.

Kind regards,
Bernhard


[1] https://github.com/gwsw/less/commit/520e5c6ea362
[2] https://github.com/gwsw/less/issues/78

# Bullseye/testing amd64 qemu VM 2021-07-09


echo "set enable-bracketed-paste off" >> /etc/inputrc; bash


apt update
apt dist-upgrade

apt install systemd-coredump mc git gdb valgrind rr less-dbgsym fakeroot
apt build-dep less



mkdir /home/benutzer/source/less/orig -p
cd/home/benutzer/source/less/orig
apt source less
cd







dmesg > file

cat file |less
s
/tmp
D
s
/tmp
double free or corruption (fasttop)
Abgebrochen (Speicherabzug geschrieben)


# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Fri 2021-07-09 16:24:39 CEST984 0 0   6 present   /usr/bin/less

# journalctl -e

# coredumpctl gdb 984
   PID: 984 (less)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Fri 2021-07-09 16:24:39 CEST (2min 12s ago)
  Command Line: less
Executable: /usr/bin/less
 Control Group: /user.slice/user-1000.slice/session-1.scope
  Unit: session-1.scope
 Slice: user-1000.slice
   Session: 1
 Owner UID: 1000 (benutzer)
   Boot ID: a8a996b571bb4da1b0927f2faa539137
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.less.0.a8a996b571bb4da1b0927f2faa539137.984.162584067900.zst
   Message: Process 984 (less) of user 0 dumped core.

Stack trace of thread 984:
#0  0x7ff6b9082ce1 raise (libc.so.6 + 0x3bce1)
#1  0x7ff6b906c537 abort (libc.so.6 + 0x25537)
#2  0x7ff6b90c5768 n/a (libc.so.6 + 0x7e768)
#3  0x7ff6b90cca5a n/a (libc.so.6 + 0x85a5a)
#4  0x7ff6b90cdd55 n/a (libc.so.6 + 0x86d55)
#5  0x557a43e773ab n/a (less + 0x143ab)
#6  0x557a43e78bda n/a (less + 0x15bda)
#7  0x557a43e6d97b n/a (less + 0xa97b)
#8  0x557a43e6ef9f n/a (less + 0xbf9f)
#9  0x557a43e677fe n/a (less + 0x47fe)
#10 0x7ff6b906dd0a __libc_start_main (libc.so.6 + 0x26d0a)
#11 0x557a43e6788a n/a (less + 0x488a)

GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
...
Core was generated by `less'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
(gdb) set width 0
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7ff6b906c537 in __GI_abort () at abort.c:79
#2  0x7ff6b90c5768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7ff6b91d3e2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7ff6b90cca5a in malloc_printerr (str=str@entry=0x7ff6b91d61c8 "double 
free or corruption (fasttop)") at malloc.c:5347
#4  0x7ff6b90cdd55 in _int_free (av=0x7ff6b9205b80 , 
p=0x557a45a52b10, have_lock=0) at malloc.c:4266
#5  0x557a43e773ab in ?? ()
#6  0x557a43e78bda in ?? ()
#7  0x557a43e6d97b in ?? ()
#8  0x557a43e6ef9f in ?? ()
#9  0x557a43e677fe in ?? ()
#10 0x7ff6b906dd0a in __libc_start_main (main=0x557a43e674e0, argc=1, 
argv=0x7ffc862ed9c8, init=, fini=, 
rtld_fini=, stack_end=0x7ffc862ed9b8) at ../csu/libc-start.c:308
#11 0x557a43e6788a in ?? ()


export DEBUGINFOD_URLS="https://debuginfod.debian.net;


Core was generated by `less'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
Download failed: Das Argument ist ungültig.  Continuing without source file 
./signal/../sysdeps/unix/sysv/linux/raise.c.
50  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7ff6b906c537 in __GI_abort () at abort.c:79
#2  0x7ff6b90c5768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7ff6b91d3e2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7ff6b90cca5a in malloc_printerr (str=str@entry=0x7ff6b91d61c8 "double 
free or corruption (fasttop)") at malloc.c:5347
#4  0x7ff6b90cdd55 in _int_free (av=0x7ff6b9205b80 , 
p=0x557a45a52b10, have_lock=0) at malloc.c:4266
#5  0x557a43e773ab in opt_o (type=, s=0x557a43e8eee0 
 "/tmp") at optfunc.c:118
#6  0x557a43e78bda in toggle_option (o=0x557a43e8db80 , 
lower=, s=, s@entry=0x557a43e8eee0  
"/tmp", how_toggle=) at option.c:446
#7  0x557a43e6d97b in exec_mca () at command.c:262
#8  0x557a43e6ef9f in mca_char (c=10) at command.c:635
#9  commands () 

Bug#990826: lollypop: Segmentation fault - cannot start lollypop

[Andreas Ronnquist]

On Thu, 8 Jul 2021 20:20:35 + Amr Ibrahim
 wrote:
> On Thu, 2021-07-08 at 21:45 +0200, Andreas Ronnquist wrote:
> > Thanks for your report - Could you please try to reproduce when
> > running lollypop from a terminal using "lollypop -d"? It should give
> > more useful debugging information.
> 
> 
> Thanks for your reply. The debug log is attached.
> 

Thanks - I am sorry to say that I cannot reproduce the segfault with
the file you provided -

Could you please try to debug it using gdb? - This might give more
useful information.

In short, install the debug package of lollypop (I am suspecting that
the problem is in some other package though) -

run lollypop in gdb as 

gdb lollypop

and when it crashes you'll get back to gdb, and there get a backtrace
with the command -

bt full

this would give a better backtrace, and probably reveal if the problem
is in lollypop or in some library.

For more details, you can see

https://wiki.debian.org/HowToGetABacktrace

best
/Andreas

Bug#990861: prboom-plus: No secret found sound in Freedoom

[Andrew]

Package: prboom-plus
Version: 2:2.6um-1
Severity: normal
X-Debbugs-Cc: andrew.pin...@tutanota.com

Dear Maintainer,


Secret found! sound only works for non-free Doom data, not Freedoom.

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

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

Versions of packages prboom-plus depends on:
ii  libc6   2.31-12
ii  libdumb11:0.9.3-6+b3
ii  libfluidsynth2  2.1.7-1.1
ii  libgcc-s1   10.2.1-6
ii  libgl1  1.3.2-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libmad0 0.15.1b-10
ii  libpcre32:8.39-13
ii  libportmidi01:217-6
ii  libsdl2-2.0-0   2.0.14+dfsg2-3
ii  libsdl2-image-2.0-0 2.0.5+dfsg1-2
ii  libsdl2-mixer-2.0-0 2.0.4+dfsg1-3
ii  libsdl2-net-2.0-0   2.0.1+dfsg1-4+b1
ii  libstdc++6  10.2.1-6
ii  libvorbisfile3  1.3.7-1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages prboom-plus recommends:
pn  freedoom | game-data-packager  

Versions of packages prboom-plus suggests:
ii  ffmpeg  7:4.3.2-0+deb11u2

-- no debconf information

Bug#980982: New upstream version 2.0.18

[LeJacq, Jean Pierre]

Hello Javier,

There has been several releases of flawfinder,  Version 2.01.8 released 
2021-06-25 is the latest at the time of this report.

-- 
JP


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

Bug#860763: policy.xml contrasts with documentation

[Douglas Perkins]

As a desktop user who has used ImageMagick for years, right now it's 
quite surprising because I can't format shift.  Converting a JPG to a 
PDF, for example, is (or was) an ordinary well-documented way of using 
the software.  Is it reasonable to expect all desktop users to edit a 
root configuration file to get the behavior they always had, behavior 
that is consistent with the program's official documentation?


Alternatively, if the current restrictive policy.xml is considered 
reasonable or necessary, it should be better documented. Because the 
policy.xml restrictions make everyday format shifting impossible, it is 
important to clearly indicate in the error message that (a) the package 
no longer works like it always did, and (b) how the desktop user can get 
things working again.

Bug#988516: uploaded

[Geert Stappers]

FYI

Packaging is done.
Upload did happen.

URL https://ftp-master.debian.org/new/kanjidraw_0.2.3-1.html is
a deep link to the NEW queue.

 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#990863: [Pkg-electronics-devel] Bug#990863: libserialport0: libserialport tries to use termiox on bullseye, and fails to open serial ports

[Jonathan McDowell]

On Fri, Jul 09, 2021 at 05:55:52PM +0100, Tim Small wrote:
> Package: libserialport0
> Version: 0.1.1-3+b1
> Severity: important
> Tags: upstream patch
> X-Debbugs-Cc: t...@seoss.co.uk
> 
> Serial port open seems to fail on bullseye.  Strace output follows:
> 
> 1512868 openat(AT_FDCWD, "/dev/ttyACM0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 9
> 1512868 ioctl(9, TCGETS, {B9600 opost isig icanon echo ...}) = 0
> 1512868 ioctl(9, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS]) = 0
> 1512868 ioctl(9, TCGETX, 0x55cd7cc80df0) = -1 ENOTTY (Inappropriate ioctl for 
> device)
> 1512868 close(9)= 0
> 1512868 write(2, "sr: ", 4) = 4
> 1512868 write(2, "serial-libsp: Error opening port"..., 71) = 71
> 1512868 write(2, "No devices found.\n", 18) = 18
> 
> Applying upstream commit 6f9b03e597ea fixes the issue.  I tested this
> with:
> 
> /usr/local/bin/sigrok-cli --driver=rdtech-tc:conn=/dev/ttyACM0 --continuous
> 
> Patch here:
> 
> https://github.com/sigrokproject/libserialport/commit/6f9b03e597ea7200eb616a4e410add3dd1690cb1
> 
> I suspect that libserialport0 will fail to open all serial ports on
> bullseye without this fix, so this bug may unfortunately be RC?

It looks like the kernel broke this in the v5.10.37 update
(eef2158b0c44baa8cd9855091b1d99a35e16afdb), which hit
unstable towards the end of May. Not clear why this was backported to
the stable tree but I guess fixing libserialport is going to be the
easier solution.

J.

-- 
] https://www.earth.li/~noodles/ []  Minorities are the foundation of  [
]  PGP/GPG Key @ the.earth.li[]  society.  [
] via keyserver, web or email.   [][
] RSA: 4096/0x94FA372B2DA8B985   [][

Bug#990857: [Pkg-javascript-devel] Bug#990857: node-millstone: autopkgtest failure

[Jérémy Lal]

Le ven. 9 juil. 2021 à 15:39, Gianfranco Costamagna <
locutusofb...@debian.org> a écrit :

> Source: node-millstone
> Version: 0.6.19-4
> Severity: serious
>
> Hello, for some reasons the autopkgtest is now failing due to:
> Uncaught Error: Unable to download '
> http://upload.wikimedia.org/wikipedia/commons/7/72/Cup_of_coffee.svg' for
> 'style.mss' (server returned 429)
>

Ough !
Are tests supposed to download stuff from internet ?

Jérémy

Bug#990864: Please consider upgrading to a more recent release

[Ryan Kavanagh]

Package: lpr
Severity: wishlist

Please consider upgrading to a more recent release of lpr. The current
snapshot is from 2008 (over 13 years ago), and lpr development has
continued upstream. This includes various bug fixes, e.g., those listed
in the following commit logs:
https://cvsweb.openbsd.org/src/usr.sbin/lpr/lpc/cmds.c
https://cvsweb.openbsd.org/src/usr.sbin/lpr/common_source/startdaemon.c

Best,
Ryan

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

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

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#990852: nicotine-plus appears to be maintained again: upgrade to latest version

[Kip Warner]

On Fri, 2021-07-09 at 13:05 +0200, boyska wrote:
> Package: nicotine
> Severity: normal
> 
> Dear Maintainer,

Hey Boyska,

> I see that updates to the nicotine package are pretty low, and it has
> even been removed from unstable.
> However, I see activity on  
> https://github.com/nicotine-plus/nicotine-plus
> and it seems to me that nicotine should now support gtk3
> 
> So I think that removing the package from the repositories is not the
> only choice; upgrading to new version with modern dependencies should
> be 
> possible. It would be fantastic if you could do that!

I've actually been trying to write Josselin a number of times since
June 2020 about this, but I haven't managed to get a substantive
response yet. I'm not sure if he's still the Debian maintainer or if he
is gone now.

Fortunately the project has been resurrected and is actively
maintained. It's even Debianized for a stable and unstable PPA. But
that's not much help to Debian users if they don't know about it
because we can't get it back into the respository.

-- 
Kip Warner -- Senior Software Engineer
OpenPGP signed/encrypted mail preferred
https://www.thevertigo.com


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

Bug#749646: x11-xserver-utils depends on cpp

[Michael Prokop]

Hi,

* Michael Gilbert [Tue Jul 21, 2015 at 11:20:04PM -0400]:

> > The packages x11-xserver-utils and x11-apps both depend on cpp. Since
> > these are "miscellaneous assortment of X applications" and not
> > development tools, I think they should not depend on cpp.

> Here is a trivial patch that makes it possible for the user to choose
> (as a non-default option) to exclude cpp packages from xorg using
> systems, at the cost of possibly breaking xrdb.

I'd very much appreciate, if that patch (which moves cpp from
Depends to Recommends) could be considered for inclusion.

xrdb *seems* to work for me also without cpp available, and it also
supports a `-nocpp` option and also supports specifying a
preprocessor of custom choice via `-cpp `.

x11-xserver-utils requires only ~523 kB of disk space, while cpp and
its cpp-10 pulls in >26 MB of disk space, which is quite notable
e.g. for live systems. :-/

regards
-mika-


signature.asc
Description: Digital signature

Bug#990863: libserialport0: libserialport tries to use termiox on bullseye, and fails to open serial ports

[Tim Small]

Package: libserialport0
Version: 0.1.1-3+b1
Severity: important
Tags: upstream patch
X-Debbugs-Cc: t...@seoss.co.uk

Serial port open seems to fail on bullseye.  Strace output follows:

1512868 openat(AT_FDCWD, "/dev/ttyACM0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 9
1512868 ioctl(9, TCGETS, {B9600 opost isig icanon echo ...}) = 0
1512868 ioctl(9, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS]) = 0
1512868 ioctl(9, TCGETX, 0x55cd7cc80df0) = -1 ENOTTY (Inappropriate ioctl for 
device)
1512868 close(9)= 0
1512868 write(2, "sr: ", 4) = 4
1512868 write(2, "serial-libsp: Error opening port"..., 71) = 71
1512868 write(2, "No devices found.\n", 18) = 18

Applying upstream commit 6f9b03e597ea fixes the issue.  I tested this
with:

/usr/local/bin/sigrok-cli --driver=rdtech-tc:conn=/dev/ttyACM0 --continuous

Patch here:

https://github.com/sigrokproject/libserialport/commit/6f9b03e597ea7200eb616a4e410add3dd1690cb1

I suspect that libserialport0 will fail to open all serial ports on
bullseye without this fix, so this bug may unfortunately be RC?

Cheers,

Tim.



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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
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 libserialport0 depends on:
ii  libc6  2.31-12

libserialport0 recommends no packages.

libserialport0 suggests no packages.

-- no debconf information
>From 6f9b03e597ea7200eb616a4e410add3dd1690cb1 Mon Sep 17 00:00:00 2001
From: Karl Palsson 
Date: Fri, 11 Jun 2021 17:07:09 +
Subject: [PATCH] HACK: don't even check for termiox

termiox was removed from linux in e0efb3168d34
Some more information available in 
https://www.spinics.net/lists/linux-serial/msg41926.html

Attempting to use the termiox ioctls on more modern kernels results in
"Inappropriate IOCTL" errors.

While the "right" solution might be to remove the termiox code from the
linux path, simply not checking for termiox builds a libserialport that
functions on modern linux kernels.

Signed-off-by: Karl Palsson 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b1af16f..a26b851 100644
--- a/configure.ac
+++ b/configure.ac
@@ -112,7 +112,7 @@ AC_SYS_LARGEFILE
 AC_TYPE_SIZE_T
 
 # Check for specific termios structures.
-AC_CHECK_TYPES([struct termios2, struct termiox],,,
+AC_CHECK_TYPES([struct termios2],,,
[[#include ]])
 AC_CHECK_MEMBERS([struct termios.c_ispeed, struct termios.c_ospeed,
struct termios2.c_ispeed, struct termios2.c_ospeed],,,
-- 
2.30.2

Bug#990678: budgie-desktop: Software windows don't display correctly, move badly or stay on the screen after being shut

[Pascal]

Package: budgie-desktop
Version: 10.5.2-3
Followup-For: Bug #990678
X-Debbugs-Cc: pascal.mart...@gmx.fr

Dear Maintainer,

For information, that window bug reappeared in MPV, even though the window
animations button in budgie desktop settings is turned off. Since last time I
have restarted my system. Maybe I followed your advice too quickly and
trustfully, or something changed with the system restart, or I didn't wait
enough time for the bug to appear, I don't know.

So that bug in MPV (the window can't be moved, and you see an invisible frame
moving instead with a kind of panicky blinking of the distorted MPV window)
always appears after having been in fullscreen and after there has been a very
short blinking of say ~10% of the horizontal upper-part screen. This blinking
(which seems very linked to the bug) appears around 5 seconds after fullscreen
(on my PC).

Cordially,
Pascal.


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

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

Versions of packages budgie-desktop depends on:
ii  budgie-core  10.5.2-3
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-2
ii  gir1.2-budgie-1.010.5.2-3
ii  gnome-control-center 1:3.38.4-1
ii  gnome-menus  3.36.0-1
ii  network-manager-gnome1.20.0-3

Versions of packages budgie-desktop recommends:
ii  budgie-desktop-view  1.1.1-1

Versions of packages budgie-desktop suggests:
ii  gnome-terminal  3.38.3-1
ii  nautilus3.38.2-1
pn  slick-greeter   

Bug#990862: infinipath-psm: reproducible builds: Embedded timestamps in libpsm_infinipath.so

[Vagrant Cascadian]

On 2021-07-09, Vagrant Cascadian wrote:
> diff --git a/buildflags.mak b/buildflags.mak
> index 34fdf1c..3e25649 100644
> --- a/buildflags.mak
> +++ b/buildflags.mak
> @@ -96,3 +96,11 @@ endif
>  CFLAGS += $(BASECFLAGS) $(if $(filter $(CC),gcc),-Wno-strict-aliasing) \
>   $(if $(PSM_VALGRIND:0=),-DPSM_VALGRIND,-DNVALGRIND)
>  
> +# Use SOURCE_DATE_EPOCH for build date, falling back to current time
> +# https://reproducible-builds.org/docs/source-date-epoch/
> +DATE_FMT="+'%F %R'"
> +ifdef FIXME_SOURCE_DATE_EPOCH

^^^ OopS! that was my debugging attempt to make sure it works when
SOURCE_DATE_EPOCH is not set.

It *should* be:

  ifdef SOURCE_DATE_EPOCH

> +BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 
> 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || 
> date -u "$(DATE_FMT)")
> +else
> +BUILD_DATE ?= $(shell date "$(DATE_FMT)")
> +endif

Will send updated patch...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#990862: infinipath-psm: reproducible builds: Embedded timestamps in libpsm_infinipath.so

[Vagrant Cascadian]

Source: infinipath-psm
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in libpsm_infinipath.so.*:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/infinipath-psm.html

  ./usr/lib/libpsm1/libpsm_infinipath.so.1.16

  $Date:·2022-07-17·21:34·InfiniPath·$
  vs.
  $Date:·2021-06-15·17:13·InfiniPath·$

The attached patch fixes this by changing buildflags.mak to set a
BUILD_DATE variable, which uses SOURCE_DATE_EPOCH for the current value
if set, falling back to the current time/date; two Makefiles are also
adjusted to use BUILD_DATE instead of calling "date" directly.

  https://reproducible-builds.org/docs/source-date-epoch/


With this patch applied, infinipath-psm should be reproducible on
tests.reproducible-builds.org in the testing (currently bullseye) suite,
where build paths are not varied. In the unstable/experimental suites,
varied build paths trigger other issues which could use further
exploration.


Thanks for maintaining infinipath-psm!


live well,
  vagrant
From d9ce27e80d5b0d7028ac20136017147f49a780f4 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 9 Jul 2021 15:13:24 +
Subject: [PATCH] Use the build date from SOURCE_DATE_EPOCH if set, falling
 back to current time.

https://reproducible-builds.org/docs/source-date-epoch/
---
 Makefile   | 2 +-
 buildflags.mak | 8 
 ipath/Makefile | 2 +-
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index d79c4bd..64d6f6b 100644
--- a/Makefile
+++ b/Makefile
@@ -270,7 +270,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
 # file around.  Generate it such that the ident command can find it
 # and strings -a | grep InfiniPath does a reasonable job as well.
 ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
-	date +'char psmi_infinipath_revision[] ="$$""Date: %F %R ${rpm_extra_description}InfiniPath $$";' > ${lib_build_dir}/_revision.c
+	printf 'char psmi_infinipath_revision[] ="$$""Date: %s ${rpm_extra_description} InfiniPath $$";\n' "$(BUILD_DATE)" > ${lib_build_dir}/_revision.c
 	$(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
 	$(CC) $(LDFLAGS) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared -Wl,--unique='*fastpath*' \
 		${${TARGLIB}-objs} _revision.o -L$(build_dir)/ipath $(LDLIBS)
diff --git a/buildflags.mak b/buildflags.mak
index 34fdf1c..3e25649 100644
--- a/buildflags.mak
+++ b/buildflags.mak
@@ -96,3 +96,11 @@ endif
 CFLAGS += $(BASECFLAGS) $(if $(filter $(CC),gcc),-Wno-strict-aliasing) \
 	$(if $(PSM_VALGRIND:0=),-DPSM_VALGRIND,-DNVALGRIND)
 
+# Use SOURCE_DATE_EPOCH for build date, falling back to current time
+# https://reproducible-builds.org/docs/source-date-epoch/
+DATE_FMT="+'%F %R'"
+ifdef FIXME_SOURCE_DATE_EPOCH
+BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "$(DATE_FMT)" 2>/dev/null || date -u "$(DATE_FMT)")
+else
+BUILD_DATE ?= $(shell date "$(DATE_FMT)")
+endif
diff --git a/ipath/Makefile b/ipath/Makefile
index 8c2cc6e..e627b3d 100644
--- a/ipath/Makefile
+++ b/ipath/Makefile
@@ -70,7 +70,7 @@ ${TARGLIB}.so.${MAJOR}: ${TARGLIB}.so.${MAJOR}.${MINOR}
 # file around.  Generate it such that the ident command can find it
 # and strings -a | grep InfiniPath does a reasonable job as well.
 ${TARGLIB}.so.${MAJOR}.${MINOR}: ${${TARGLIB}-objs}
-	date +'static __attribute__ ((unused)) char __psc_infinipath_revision[] ="$$""Date: %F %R ${rpm_extra_description}InfiniPath $$";' > _revision.c
+	printf 'static __attribute__ ((unused)) char __psc_infinipath_revision[] ="$$""Date: %s ${rpm_extra_description}InfiniPath $$";\n' "$(BUILD_DATE)" > _revision.c
 	$(CC) -c $(BASECFLAGS) $(INCLUDES) _revision.c -o _revision.o
 	$(CC) -o $@ -Wl,-soname=${TARGLIB}.so.${MAJOR} -shared \
 		-Wl,--unique='*fastpath*' \
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990860: ITP: golang-github-smallstep-nosql -- abstraction layer for data persistency written in go

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-smallstep-nosql
  Version : 0.3.6-1
  Upstream Author : Smallstep
* URL : https://github.com/smallstep/nosql
* License : Apache-2.0
  Programming Lang: Go
  Description : abstraction layer for data persistency written in go
  Currently this library provides following implementations:
  - BoltDB (https://github.com/etcd-io/bbolt) etcd fork.
  - Badger
  - MariaDB/MySQL

Bug#971332: alsa-plugins: uses deprecated libavresample

[Diederik de Haas]

On 2020-09-28 23:51:47 +0200 Sebastian Ramacher  wrote:
> Source: alsa-plugins
> Version: 1.2.2-2
> Usertags: libavresample-removal
> Control: block 971318 by -1
> 
> alsa-plugins currently Build-Depends or Depends on libavresample-dev.
> The ffmpeg developers consider libavresample as obsolete and replaced
> the library with libswresample. Please switch alsa-plugins to use
> libswresample.
> 
> Note that this switch will require changes if alsa-plugins doesn't
> already have support for libsvresample.

https://git.alsa-project.org/?p=alsa-plugins.git;a=commit;h=8a3c0d795fbef5700c8cedcc82c6a337170c76ee
This commit fixes that problem and was committed about 3 weeks ago, but 
release v1.2.5 is from 5 weeks ago, so probably not part of it.

I'm very much looking forward to having this bug fixed has been impossible 
for me to upgrade to ffmpeg 4.4 (in experimental) without removing alsa-plugins
which in turn would require the removal of pulseaudio.
Very likely because of this, it's also blocks the auto-ffmpeg transition:
https://release.debian.org/transitions/html/auto-ffmpeg.html


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

Bug#990859: Memory leak making desktop unusable after few weeks of uptime

[Faidon Liambotis]

Package: marco
Version: 1.24.1-2
Severity: grave
Tags: patch

marco >= 1.23.2 has a memory/pixmap leak in the workspace switcher OSD,
that makes the desktop slower over time, and after a few weeks of
uptime, downright unusable. The effects can be observed using "xrestop",
where the Pxms column rises on every workspace switch.

I experienced this bug, and had to run "marco --replace" every 2-3 weeks
to mitigate. I started digging and found someone else also reported it
upstream[1], with the same symptoms.

I tracked down the root cause, and provided a fix that can be found as
PR #688[2]. This went through code review and some amendements, with the
final version merged into master a few minutes ago[3].

The commit in question applies cleanly on top of 1.24.1-2. It's pretty
small and fairly obvious.

IMHO this should be backported, and we should not release bullseye
without this fix in place.

Thanks!
Faidon

1: https://github.com/mate-desktop/marco/issues/685
2: https://github.com/mate-desktop/marco/issues/688
3: 
https://github.com/mate-desktop/marco/commit/8f204678be6d888ad1d2904e28af1aa9f2ad8e11

Bug#989624: golang-github-klauspost-cpuid-dev: Outdated package

[Peymaneh Nejad]

Hi,

small reminder on this.

We'd proceed as mentioned the coming week then :)

kind regards,
Peymaneh

Bug#990156: [debian-mysql] Bug#990156: mariadb-server-10.3: Service configuration fails package upgrade

[Faustin Lammler]

Hi Chris!

I am not able to reproduce this, here are the steps I am using:

- start a systemd podman debian 10 container;
| $ podman run --name sys-test --rm -d fauust/docker-systemd:debian-10
| $ podman exec -it sys-test bash

- activate debian snapshot repo (to install old mariadb-server version
  10.3.27-0+deb10u1);
| # echo "deb http://snapshot.debian.org/archive/debian/20210105 buster 
main">/etc/apt/sources.list

- install mariadb-server 10.3.27-0+deb10u1, start it and check;
| # apt update && apt install mariadb-server -y
| # systemctl start mariadb && mariadb
| Welcome to the MariaDB monitor.  Commands end with ; or \g.
| Your MariaDB connection id is 15
| Server version: 10.3.27-MariaDB-0+deb10u1 Debian 10
|
| Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
|
| Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

- stop mariadb and test the upgrade:
| # systemctl stop mariadb
| # echo "deb http://deb.debian.org/debian buster main">/etc/apt/sources.list
| # apt update && apt upgrade -y

- verify that mariadb is not started, start it and check the version:
| # systemctl status mariadb
| ● mariadb.service - MariaDB 10.3.29 database server
|Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor 
preset: enabled)
|Active: inactive (dead) since Fri 2021-07-09 14:23:31 UTC; 1min 17s ago
|  Docs: man:mysqld(8)
|https://mariadb.com/kb/en/library/systemd/
|  Main PID: 1268 (code=exited, status=0/SUCCESS)
|Status: "MariaDB server is down"
|   CPU: 998ms
| # systemctl start mariadb && mariadb
| Welcome to the MariaDB monitor.  Commands end with ; or \g.
| Your MariaDB connection id is 8
| Server version: 10.3.29-MariaDB-0+deb10u1 Debian 10
|
| Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
|
| Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

Can you please provide some information about the context and guide me
so I could try to reproduce this?

Also, I don't see how it could influence, but as you seem to be on arm
platform, maybe we should try to reproduce it on this architecture?

Regards,

-- 
Faustin


signature.asc
Description: PGP signature

Bug#990858: dask: reproducible builds: embeds build user home directory in html documentation

[Vagrant Cascadian]

Package: dask
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The home directory is embedded in html documentation:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/dask.html

  /usr/share/doc/python-dask-doc/html/configuration.html

  ... 
['/etc/dask',·'/usr/etc/dask',·'/nonexistent/first-build/.config/dask',·'/nonexistent/first-build/.dask']
 ...
vs.
  ... 
['/etc/dask',·'/usr/etc/dask',·'/nonexistent/second-build/.config/dask',·'/nonexistent/second-build/.dask']
 ...


The attached patch fixes this by modifying dask/config.py to not expand
the tilde to the user home dir.

While the patch does make the documentation reproducible, it needs some
run-time testing to ensure that dask works correctly with the patch
applied (e.g. the configuration is checked for in the user's
~/.config/dask and ~/.dask directories)! Someone familiar with dask
should test this before applying the patch!

If it causes issues, taking a deeper look into fixing this in the
documentation will be needed.


With this patch applied, dask should become reproducible in the
tests.reproducible-builds.org infrastructure.


Thanks for maintaining dask!


live well,
  vagrant
From ae0387f269e043a094938e4c71d56b3b03099085 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Fri, 9 Jul 2021 13:40:56 +
Subject: [PATCH] dask/config.py: do not expand tilde with home directory

The home directories to search for should not be embedded when
generating the documentation, as it embeds the home directory of the
build user.

Ideally, this would be expanded at run-time, but not when building the
documentation.
---
 debian/patches/series  |  1 +
 debian/patches/use-tilde-homedir.patch | 26 ++
 2 files changed, 27 insertions(+)
 create mode 100644 debian/patches/use-tilde-homedir.patch

diff --git a/debian/patches/series b/debian/patches/series
index 9b7a15e..c6e478a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@ use-local-intersphinx.patch
 use-local-reference-yaml.patch
 js-yaml.patch
 use-youtube-nocookie.patch
+use-tilde-homedir.patch
diff --git a/debian/patches/use-tilde-homedir.patch b/debian/patches/use-tilde-homedir.patch
new file mode 100644
index 000..6403e7c
--- /dev/null
+++ b/debian/patches/use-tilde-homedir.patch
@@ -0,0 +1,26 @@
+From: Vagrant Cascadian 
+Date: Fri Jul  9 05:22:39 UTC 2021
+Subject: do not expand tilde with home directory
+
+The home directories to search for should not be embedded when
+generating the documentation, as it embeds the home directory of the
+build user.
+
+Ideally, this would be expanded at run-time, but not when building the
+documentation.
+
+diff --git a/dask/config.py b/dask/config.py
+index 27d8492..8dbcfa7 100644
+--- a/dask/config.py
 b/dask/config.py
+@@ -15,8 +15,8 @@ no_default = "__no_default__"
+ paths = [
+ os.getenv("DASK_ROOT_CONFIG", "/etc/dask"),
+ os.path.join(sys.prefix, "etc", "dask"),
+-os.path.join(os.path.expanduser("~"), ".config", "dask"),
+-os.path.join(os.path.expanduser("~"), ".dask"),
++os.path.join("~", ".config", "dask"),
++os.path.join("~", ".dask"),
+ ]
+ 
+ if "DASK_CONFIG" in os.environ:
-- 
2.32.0



signature.asc
Description: PGP signature

Bug#990857: node-millstone: autopkgtest failure

[Gianfranco Costamagna]

Source: node-millstone
Version: 0.6.19-4
Severity: serious

Hello, for some reasons the autopkgtest is now failing due to:
Uncaught Error: Unable to download 
'http://upload.wikimedia.org/wikipedia/commons/7/72/Cup_of_coffee.svg' for 
'style.mss' (server returned 429)

Can you please have a look?

See e.g.
https://ci.debian.net/packages/n/node-millstone/unstable/amd64/
https://ci.debian.net/data/autopkgtest/unstable/amd64/n/node-millstone/13493238/log.gz

thanks

Gianfranco

Bug#990440: debianutils: manage /etc/shells declaratively using triggers

[Helmut Grohne]

Hi Guillem,

Thank you for the review.

On Fri, Jul 09, 2021 at 02:23:31PM +0200, Guillem Jover wrote:
> I'm wondering whether tying the pathname to a Debian specific package
> name might make a possible "standardization" or adoption by say other
> distributions or upstream harder? Perhaps a more generic name would
> leave the door open to such adoption, so that upstreams could ship
> those files directly f.ex.?

I'm not opposed. My intention here was to avoid stepping on other
peoples' toes.

> > +   realshell=$(dpkg-realpath --root "$ROOT" "$line")
> 
> Not sure how desirable this would be, but if DPKG_ROOT is set in the
> caller environment, but the caller did not specify --root for this
> program, then DPKG_ROOT will not be taken into account by
> dpkg-realpath, as this unconditionally overrides it. Perhaps this
> program should be defaulting ROOT to DPKG_ROOT?

This actually is intentional. I figured that there was only one
legitimate caller of this tool in maintainer scripts and that one caller
could easily pass --root explicitly. Therefore, I intentionally did not
add DPKG_ROOT support to the tool itself. DPKG_ROOT in tools always
feels a little magic to me, so I err on being explicit when feasible.

> > +   if [ "$line" != "$realshell" ]; then
> > +   PKG_SHELLS="$PKG_SHELLS$realshell#"
> > +   fi
> > +   done < "$f"
> > +done
> 
> Doesn't seem to handle an interrupted invocation by removing staged
> files for in-between steps for the shells and state files.

Leaving tempfiles around when interrupted seems fair enough to me.
Existing tempfiles are truncated. What kind of practical issue do you
see here?

> Isn't this missing the filesystem existence check for the shell to
> handle local admin additions and the default fragment default cases,
> as described in the algorithm?

I didn't understand the need for the existence check, so I left it out.
Do you envision partially unpacked packages here? I ruled that out as
too unrealistic. If an admin adds a non-existent shell, who am I to
remove it?

> I've just skimmed over this algo (and run out of time now), but it does
> not match directly to the one proposed on the list so I'll have to think
> about this a bit more. :)

Yeah, what I sold as your proposal is actually slightly different. Seems
to work anyhow. :)

> I think this is missing sync'ing the containing directories too.

Agreed. Though given that other tools don't sync maybe it doesn't really
matter that much. Also sync should do the right thing.

> Perhaps move or add the file descriptions to a FILES section?

Reasonable request.

Helmut

Bug#990856: ITP: tandem-genotypes -- compare lengths of duplications in DNA sequences

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: tandem-genotypes -- compare lengths of duplications in DNA 
sequences
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: tandem-genotypes
  Version : 1.8.2
  Upstream Author : Martin C. Frith 
* URL : https://github.com/mcfrith/tandem-genotypes
* License : GPL-3.0
  Programming Lang: Python
  Description : compare lengths of duplications in DNA sequences
 Only a fraction of the DNA in the human genome (and that of other species
 that are not optimised for the speed of their replication like viruses)
 are coding for genes. Other parts may be binding to transcription factors
 or direct the expression of genes in other ways - these other bits may
 not be fully understood, and parts may indeed be "junk", but this is
 only until we find a clinical feature to be statistically associated
 with something statistically noteworthy in the DNA sequences.
 .
 Features that somehow seem informative when looking at the DNA are
 whatever does not look like random. This tool looks at a special case
 of repeats - short regions that are duplicated, i.e. they appear as a
 tandem. When these repeats are longer, then these would be referred as
 microsatellites.
 .
 When interested in structural variations, within a family/population or
 to compare cancer tissue with benign samples, you may also want to look
 at these repeats. This software determines the lengths (and changes to
 the lenghts) across samples and knows how to present this graphically.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/tandem-genotypes

Bug#990855: sudo: enable python plugin support

[Michael Prokop]

Package: sudo
Version: 1.9.6-1~exp2
Severity: wishlist

Hi,

since sudo v1.9.0 it's possible to write sudo plugins in Python 3,
see e.g. https://blog.sudo.ws/posts/2020/01/whats-new-in-sudo-1.9-python/

This requires to build the package with --enable-python though,
to provide the according python_plugin.so.

Thanks for consideration!

regards
-mika-


signature.asc
Description: Digital signature

Bug#988696: installation-reports: No network management in LXDE task

[Holger Wansing]

Hi,

Andreas Tille  wrote (Fri, 2 Jul 2021 10:28:07 +0200):
> Hi,
> 
> I have tried
> 
> 
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2-live+nonfree/amd64/iso-hybrid/debian-live-blsy-DI-rc2-amd64-lxde+nonfree.iso
> 
> for another installation - but network-manager keeps on missing.  This is
> true for the generic Debian text installer as well as the installer from
> Live system.  I consider it an important thing to fix for the upcoming
> release.

I don't see your point here.
network-manager does not get installed, yes. 
But connman-gtk does, right? (as evaluated before)


BTW: installing via live system (Calamaris installer) is a completely
different thing, compared to the debian-installer.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#990440: debianutils: manage /etc/shells declaratively using triggers

[Guillem Jover]

Hi!

On Tue, 2021-06-29 at 08:01:49 +0200, Helmut Grohne wrote:
> Package: debianutils
> Version: 4.11.2
> Severity: wishlist
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap

> We've had a discussion on the expectations on /etc/shells on
> d-devel@l.d.o recently. You can find the entry point at:
> https://lists.debian.org/ymjtirkqbjdjy...@alf.mars

Thanks for handling and implementing this! :)

> As a result of the discussion, we propose that client packages can
> replace their add-shell invocations with adding a file
> /usr/share/debianutils/shells.d/$PKG containing the shells to be added.

I'm wondering whether tying the pathname to a Debian specific package
name might make a possible "standardization" or adoption by say other
distributions or upstream harder? Perhaps a more generic name would
leave the door open to such adoption, so that upstreams could ship
those files directly f.ex.?


> diff --minimal -Nru debianutils-4.11.2/update-shells 
> debianutils-4.11.2+nmu1/update-shells
> --- debianutils-4.11.2/update-shells  1970-01-01 01:00:00.0 +0100
> +++ debianutils-4.11.2+nmu1/update-shells 2021-06-28 20:14:17.0 
> +0200
> @@ -0,0 +1,144 @@

> +# Check whether hashset $1 contains element $2.
> +hashset_contains() {
> + case "$1" in
> + *"#$2#"*) return 0 ;;
> + *) return 1 ;;
> + esac
> +}
> +
> +log() {
> + if [ "$VERBOSE" = 1 ]; then
> + echo "$*"
> + fi
> +}
> +
> +ROOT=
> +VERBOSE=0
> +NOACT=0
> +
> +while [ $# -gt 0 ]; do
> + case "$1" in
> + --help)
> + cat < +usage: $0 [options]
> +
> + --no-actDo not move the actual update into place
> + --verbose   Be more verbose
> + --root DIR  Operate on the given chroot, defaults to /
> +EOF
> + exit 0
> + ;;
> + --no-act)
> + NOACT=1
> + ;;
> + --root)
> + shift
> + if [ "$#" -lt 1 ]; then
> + echo "missing argument to --root" 1>&2
> + exit 1
> + fi
> + ROOT=$1
> + ;;
> + --verbose)
> + VERBOSE=1
> + ;;
> + *)
> + echo "unrecognized option $1" 1>&2
> + exit 1
> + ;;
> + esac
> + shift
> +done
> +
> +PKG_DIR="$ROOT/usr/share/debianutils/shells.d"
> +STATE_FILE="$ROOT/var/lib/shells.state"
> +ETC_FILE="$ROOT/etc/shells"
> +NEW_ETC_FILE="$ETC_FILE.tmp"
> +NEW_STATE_FILE="$STATE_FILE.tmp"
> +
> +PKG_SHELLS='#'
> +LC_COLLATE=C.UTF-8  # glob in reproducible order
> +for f in "$PKG_DIR/"*; do
> + [ "$f" = "$PKG_DIR/*" ] && break
> + while IFS='#' read -r line _; do
> + [ -n "$line" ] || continue
> + PKG_SHELLS="$PKG_SHELLS$line#"
> + realshell=$(dpkg-realpath --root "$ROOT" "$line")

Not sure how desirable this would be, but if DPKG_ROOT is set in the
caller environment, but the caller did not specify --root for this
program, then DPKG_ROOT will not be taken into account by
dpkg-realpath, as this unconditionally overrides it. Perhaps this
program should be defaulting ROOT to DPKG_ROOT?

> + if [ "$line" != "$realshell" ]; then
> + PKG_SHELLS="$PKG_SHELLS$realshell#"
> + fi
> + done < "$f"
> +done

Doesn't seem to handle an interrupted invocation by removing staged
files for in-between steps for the shells and state files.

> +STATE_SHELLS='#'
> +if [ -e "$STATE_FILE" ] ; then
> + while IFS='#' read -r line _; do
> + [ -n "$line" ] && STATE_SHELLS="$STATE_SHELLS$line#"
> + done < "$STATE_FILE"
> +fi
> +
> +cleanup() {
> + rm -f "$NEW_ETC_FILE" "$NEW_STATE_FILE"
> +}
> +trap cleanup EXIT
> +
> +: > "$NEW_ETC_FILE"
> +ETC_SHELLS='#'
> +while IFS= read -r line; do
> + shell=${line%%#*}
> + # copy all comment lines, packaged shells and local additions
> + if [ -z "$shell" ] ||
> + hashset_contains "$PKG_SHELLS" "$shell" ||
> + ! hashset_contains "$STATE_SHELLS" "$shell"; then
> + echo "$line" >> "$NEW_ETC_FILE"
> + ETC_SHELLS="$ETC_SHELLS$shell#"

Isn't this missing the filesystem existence check for the shell to
handle local admin additions and the default fragment default cases,
as described in the algorithm?

> + else
> + log "removing shell $shell"
> + fi
> +done < "$ETC_FILE"
> +
> +: > "$NEW_STATE_FILE"
> +saved_IFS=$IFS
> +IFS='#'
> +set -f
> +# shellcheck disable=SC2086 # word splitting intended, globbing disabled
> +set -- ${PKG_SHELLS###}
> +set +f
> +IFS=$saved_IFS
> +for shell; do
> + echo "$shell" >> "$NEW_STATE_FILE"
> + # add shells that are neither already present nor locally removed
> + if ! hashset_contains "$ETC_SHELLS" "$shell" &&
> + 

Bug#990853: Problem with Directory directive

[Yadd]

Le 09/07/2021 à 13:12, Stadtsholte, Ingo a écrit :
> Package: apache2
> 
> Version: 2.4.38-3+deb10u4
> 
>  
> 
> After minor updating my Apache Installation to the above Version,
> AuthType in Directory directive only affects to DirectoryIndex, not to
> all other files/subdirectories
> 
>  
> 
> 
> 
>   AuthType GSSAPI
> 
>   require valid-user
> 
>   DirectoryIndex index.php
> 
> 
> 
>  
> 
> Authentication works when I call https://myserver/ 
> but do not work anymore when I call https://myserver/index.php
> 

Hi,

it's not a bug, use  when using an external file handler
(like php-fpm)

> Other problems I had after that update: I had to enable some modules via
> a2enmod. 3 weeks earlier the modules were automatically enabled and the
> AuthType works for the whole directory

Could you give more details ?

Bug#743553: information: rsyslog: build omudpspoof module

[Magnus Persson]

Hi,

I believe that I have a use for the omudpspoof module.

I have a number of sites using debian hosts configured as routers. These 
use dynamic routing. Logs are sent to a server in one of the sites by 
udp for archive and analysis purposes. Separate log files are generated 
based on sending host. Temporary changes in routing result in split log 
files. This makes automatic analysis more difficult. Sending log traffic 
with the source set to an "inside" ip would solve this.


Pleasy advise if you want me to elaborate further or if I can be of 
other assistance. Thank you for you work on maintaining this package.


Regards
Magnus

Bug#990853: Problem with Directory directive

[Stadtsholte, Ingo]

Package: apache2
Version: 2.4.38-3+deb10u4

After minor updating my Apache Installation to the above Version, AuthType in 
Directory directive only affects to DirectoryIndex, not to all other 
files/subdirectories


  AuthType GSSAPI
  require valid-user
  DirectoryIndex index.php


Authentication works when I call https://myserver/ but do not work anymore when 
I call https://myserver/index.php

Other problems I had after that update: I had to enable some modules via 
a2enmod. 3 weeks earlier the modules were automatically enabled and the 
AuthType works for the whole directory

Hope you can help


Aktuelles finden Sie auch auf https://www.olb.de und 
https://www.facebook.com/olb.bank

Oldenburgische Landesbank AG
Vorsitzender des Aufsichtsrates: Axel Bartsch
Vorstand: Dr. Wolfgang Klein, Vorsitzender; Stefan Barth, stellv. Vorsitzender; 
Marc Ampaw; Peter Karst; Karin Katerbau; Dr. Rainer Polster
Sitz der Gesellschaft und Registergericht: Oldenburg (Oldb), HR-Nummer: HRB 3003


smime.p7s
Description: S/MIME cryptographic signature

Bug#990519: RFS: sentry-python/1.1.0-2 -- new version of Python SDK for Sentry.io

[Emmanuel Arias]

Hi,

On Fri, Jul 9, 2021 at 7:52 AM Eberhard Beilharz  wrote:

> Hi,
>
> I bumped debhelper-compat and added team upload.
>
> Unfortunately I don't have time to get familiar with autopkgtests and
> add that.
>

np, this isn't block, but it's always a good idea :)

Also, you can add the package in #debian-python topic.

>
> Thanks,
>
>  Eberhard
>
> Emmanuel Arias wrote on 08.07.21 20:52:
> > Hello,
> >
> > I loooked it and perhaps you can bump debhelper-compat to 13. Also,
> > maybe it's a good idea add autopkgtests tests.
> >
> > Also you missed * Team upload. line in d/changelog.
> >
> >
> > Cheers,
> > eamanu
>

Bug#990849: dpkg-dev: dpkg-buildpackage fails trying multifile optimization with dwz on aarch64 and armv71

[Guillem Jover]

Control: reassign -1 debhelper

Hi!

This is not a dpkg issue, but it is debhelper related, reassigning and
leaving context.

On Fri, 2021-07-09 at 08:52:18 +, Dennis Bijwaard wrote:
> Package: dpkg-dev
> Version: 1.19.7
> Severity: normal
> 
> Dear all,
> 
> When I use dpkg-buildpackage -us -uc on different machines, it sometimes
> fails to create packages during multifile optimization, at least on
> armv71 and aarch64 machines for packaging 3 golang executables. The
> same package is created without problems on x86_64. The golang binaries 
> are copied using a debian/install file (failed to get dh_golang working).
> 
> I found a work-around to at least create a package on these machines
> using DEB_BUILD_OPTIONS=nostrip, but the package remains quite big. A regular
> strip on the binaries does reduce them a bit, this could be an
> alternative when dwz fails. Alternatively, it would be great if there
> was an option to disable multifile option of dwz via e.g. DEB_BUILD_OPTIONS. 
> Or is there already an easy way to pass the --no-dwz-multifile option to
> dh_dzw when invoked via dpkg-buildpackage?
> 
> Below is the trace of the failing dpkg-buildpackage.
> 
> Kind regards
> Dennis
> 
>...
>dh_link -O--builddirectory=. -O--buildsystem=makefile
>dh_strip_nondeterminism -O--builddirectory=. -O--buildsystem=makefile
>dh_compress -O--builddirectory=. -O--buildsystem=makefile
> cd debian/sst-goflow
> chmod a-x usr/share/doc/sst-goflow/changelog
> gzip -9nf usr/share/doc/sst-goflow/changelog
> cd '/home/dennis/work/lv-sensor-sw/flowprocessing/golang'
>dh_fixperms -O--builddirectory=. -O--buildsystem=makefile
> find debian/sst-goflow ! -type l -a -true -a -true -print0 
> 2>/dev/null | xargs -0r chmod go=rX,u+rw,a-s
> find debian/sst-goflow/usr/share/doc -type f -a -true -a ! -regex 
> 'debian/sst-goflow/usr/share/doc/[^/]*/examples/.*' -print0 2>/dev/null | 
> xargs -0r chmod 0644
> find debian/sst-goflow/usr/share/doc -type d -a -true -a -true 
> -print0 2>/dev/null | xargs -0r chmod 0755
> find debian/sst-goflow -type f \( -name '*.so.*' -o -name '*.so' -o 
> -name '*.la' -o -name '*.a' -o -name '*.js' -o -name '*.css' -o -name 
> '*.scss' -o -name '*.sass' -o -name '*.jpeg' -o -name '*.jpg' -o -name 
> '*.png' -o -name '*.gif' -o -name '*.cmxs' -o -name '*.node' \) -a -true -a 
> -true -print0 2>/dev/null | xargs -0r chmod 0644
> find debian/sst-goflow/usr/bin -type f -a -true -a -true -print0 
> 2>/dev/null | xargs -0r chmod a+x
>dh_missing -O--builddirectory=. -O--buildsystem=makefile
>dh_dwz -O--builddirectory=. -O--buildsystem=makefile
> install -d debian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu
> dwz -q 
> -mdebian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug 
> -M/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug -- 
> debian/sst-goflow/usr/bin/rtd_dsp debian/sst-goflow/usr/bin/rtd_influxdb 
> debian/sst-goflow/usr/bin/rtd_web
> dwz: Too few files for multifile optimization
> objcopy --compress-debug-sections 
> debian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug
> objcopy: 
> 'debian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug': No 
> such file
> dh_dwz: objcopy --compress-debug-sections 
> debian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug 
> returned exit code 1
> make[1]: *** [debian/rules:17: binary] Error 2
> make[1]: Leaving directory 
> '/home/dennis/work/lv-sensor-sw/flowprocessing/golang'
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2
> make: *** [Makefile:29: deb] Error 2
> 
> 
> 
> -- Package-specific info:
> System tainted due to merged-usr-via-symlinks.
> 
> -- System Information:
> Debian Release: 10.8
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: arm64 (aarch64)
> Foreign Architectures: armhf
> 
> Kernel: Linux 5.10.12-rockchip64 (SMP w/4 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages dpkg-dev depends on:
> ii  binutils  2.31.1-16
> ii  bzip2 1.0.6-9.2~deb10u1
> ii  libdpkg-perl  1.19.7
> ii  make  4.2.1-1.2
> ii  patch 2.7.6-3+deb10u1
> ii  perl  5.28.1-6+deb10u1
> ii  tar   1.30+dfsg-6
> ii  xz-utils  5.2.4-1
> 
> Versions of packages dpkg-dev recommends:
> ii  build-essential  12.6
> ii  fakeroot 1.23-1
> ii  gcc [c-compiler] 4:8.3.0-1
> ii  gcc-8 [c-compiler]   8.3.0-6
> ii  gnupg2.2.12-1+deb10u1
> ii  gnupg2   

Bug#990852: nicotine-plus appears to be maintained again: upgrade to latest version

[boyska]

Package: nicotine
Severity: normal

Dear Maintainer,
I see that updates to the nicotine package are pretty low, and it has 
even been removed from unstable.
However, I see activity on https://github.com/nicotine-plus/nicotine-plus
and it seems to me that nicotine should now support gtk3

So I think that removing the package from the repositories is not the 
only choice; upgrading to new version with modern dependencies should be 
possible. It would be fantastic if you could do that!

Bug#990851: ITP: nano-snakemake -- detection of structural variants in genome sequencing data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: nano-snakemake -- detection of structural variants in genome 
sequencing data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: nano-snakemake
  Version : 1.0+git20200224.ff11b35
  Upstream Author : Wouter De Coster
* URL : https://github.com/wdecoster/nano-snakemake
* License : Expat
  Programming Lang: Python
  Description : detection of structural variants in genome sequencing data
 To "have a genetic variation" may mean many different things. Technically
 most straight forward to investigate are changes to single positions in
 the long DNA chains - every chromosome is a single polymer of nucleic acids.
 This is also what we have most data from for many diseases.
 .
 But sometimes, DNA that looks completely the same when looking at short reads
 at the time (and not feeling lucky), the position looked at may be inverted
 on the chromosome. Or it may be a copy of the original site and not a "real"
 single-nucleotide polymorphism (SNP). Or it may have translocated to
 another chromosome.
 .
 These are examples for structural changes to the DNA. Individuals may never
 notice them. Or there may be a higher chances to develop a disease or it may
 affect fertility. Technologies like the Nanopore have emerged that can read
 longer segments of the DNA, so one can see multiple copies of the same gene
 in the same read or at least can assemble the DNA fragments read in a way to
 then align the reads non-ambiguously and support the analysis of such
 copy-number variations (CNVs).
 .
 This snakemake pipeline on nanopore whole genome sequencing data provides
 a complete structural variant analysis. Steps implemented and tools
 wrapped comprise:
  * fast: minimap2 alignment with Sniffles and SVIM SV calling
  * precise: ngmlr alignment with Sniffles SV calling
  * minimap2: minimap2 alignment with Sniffles, SVIM, NanoSV and npInv SV 
calling
  * minimap2_pbsv: minimap2 alignment with pbsv-specific parameters with
pbsv, SVIM, NanoSV and npInv SV calling
  * ngmlr: ngmlr with Sniffles, NanoSV, SVIM and npInv SV calling
  * last-prepare: create a LAST index and train aligner parameters using 
last-train
  * last: LAST alignment with tandem-genotypes STR calling

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

Bug#990519: RFS: sentry-python/1.1.0-2 -- new version of Python SDK for Sentry.io

[Eberhard Beilharz]

Hi,

I bumped debhelper-compat and added team upload.

Unfortunately I don't have time to get familiar with autopkgtests and 
add that.


Thanks,

    Eberhard

Emmanuel Arias wrote on 08.07.21 20:52:

Hello,

I loooked it and perhaps you can bump debhelper-compat to 13. Also,
maybe it's a good idea add autopkgtests tests.

Also you missed * Team upload. line in d/changelog.


Cheers,
eamanu

Bug#988696: installation-reports: No network management in LXDE task

[Andreas Tille]

Hi,

On Fri, Jul 09, 2021 at 10:53:09AM +0200, Holger Wansing wrote:
> 
> I don't see your point here.
> network-manager does not get installed, yes. 
> But connman-gtk does, right? (as evaluated before)

My point is that I as a user do not find any icon in the tray to bring
up a network connection.  I need to admit I'm not an lxde user and
install these machines for others (who also have no Linux experience).
I know network-manager and once the app is started I can easily bring
up the network.

So please change my bug report into:  No idea how to configure network
easily after fresh lxde install.
 
> BTW: installing via live system (Calamaris installer) is a completely
> different thing, compared to the debian-installer.

Yes, that's clear.  However, I guess also the lxde metapackage is
involved here.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Bug#990850: linux-image-5.10.0-8-amd64: mcba_usb doesn't work

[Yasushi SHOJI]

Package: src:linux
Version: 5.10.46-1
Severity: normal
X-Debbugs-Cc: none, Yasushi SHOJI 

Dear Maintainer,

With linux-image-5.10.0-8-amd64, Microchip CAN BUS Analyzer does not
work with mcba_usb device driver.

The same device works with linux-image-5.10.0-7-amd64:

> Jul 09 17:46:58 leno kernel: usb 1-6: USB disconnect, device number 8
> Jul 09 17:46:58 leno kernel: mcba_usb 1-6:1.0 can0: device disconnected
> Jul 09 17:46:58 leno kernel: device can0 left promiscuous mode
> Jul 09 17:47:00 leno kernel: usb 1-6: new full-speed USB device number 12 
> using xhci_hcd
> Jul 09 17:47:00 leno kernel: usb 1-6: New USB device found, idVendor=04d8, 
> idProduct=0a30, bcdDevice= 2.00
> Jul 09 17:47:00 leno kernel: usb 1-6: New USB device strings: Mfr=1, 
> Product=2, SerialNumber=3
> Jul 09 17:47:00 leno kernel: usb 1-6: Product: Microchip CAN BUS Analyzer
> Jul 09 17:47:00 leno kernel: usb 1-6: Manufacturer: Microchip Technology Inc.
> Jul 09 17:47:00 leno kernel: mcba_usb 1-6:1.0 can0: PIC CAN version 2.3
> Jul 09 17:47:00 leno kernel: mcba_usb 1-6:1.0 can0: PIC USB version 2.0
> Jul 09 17:47:00 leno kernel: mcba_usb 1-6:1.0: Microchip CAN BUS Analyzer 
> connected
> Jul 09 17:47:08 leno kernel: IPv6: ADDRCONF(NETDEV_CHANGE): can0: link 
> becomes ready

Please let me know if you need more info.

Best,
--
 yashi

-- Package-specific info:
attached

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

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=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-8-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-8-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-8-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-efi-amd64  2.04-19
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-8-amd64 is related to:
ii  firmware-amd-graphics 20210315-2
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20210315-2
pn  firmware-libertas 
ii  firmware-linux-nonfree20210315-2
ii  firmware-misc-nonfree 20210315-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20210315-2
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.46-1 (2021-06-24)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 
root=UUID=c9054a70-0b95-44c7-806d-6dd5d6225151 ro quiet

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

** Kernel log:
[7.968768] usbcore: registered new interface driver usbserial_generic
[7.968776] usbserial: USB Serial support registered for generic
[7.973599] usbcore: registered new interface driver ftdi_sio
[7.973616] usbserial: USB Serial support registered for FTDI USB Serial 
Device
[7.973680] ftdi_sio 1-1.3.2.2:1.0: FTDI USB Serial Device converter detected
[7.973705] usb 1-1.3.2.2: Detected FT2232C
[7.975991] usb 1-1.3.2.2: FTDI USB Serial Device converter now attached to 
ttyUSB0
[7.976253] ftdi_sio 1-1.3.2.2:1.1: FTDI USB Serial Device converter detected
[7.976318] usb 1-1.3.2.2: Detected FT2232C
[7.976618] usb 1-1.3.2.2: FTDI USB Serial Device converter now attached to 
ttyUSB1
[8.263341] audit: type=1400 audit(1625821110.310:34): apparmor="DENIED" 
operation="capable" profile="libvirtd" pid=810 comm="daemon-init" capability=17 
 capname="sys_rawio"
[8.542100] rfkill: input handler disabled
[9.512441] e1000e :00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: Rx/Tx
[9.512527] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s31f6: link becomes ready
[   10.687617] wlp3s0: authenticate with 18:ec:e7:50:2c:a9
[   10.699499] wlp3s0: send auth to 18:ec:e7:50:2c:a9 (try 1/3)
[   10.705346] wlp3s0: 

Bug#990848: libre0.1: ships /usr/lib//libre.so.0

[Andreas Beckmann]

Package: libre0.1
Version: 2.0.1-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files.

The package was renamed because the SONAME changed, therefore it should
no longer ship the old SONAME link.

Also the changelog entry is misleading:

   * add binary package libre1 (replacing libre0)
 to reflect SONAME change

The new binary package is libre0.1, not libre1
and it is not really "replacing" libre0

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libre0.1_2.0.1-1~exp1_amd64.deb ...
  Unpacking libre0.1:amd64 (2.0.1-1~exp1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libre0.1_2.0.1-1~exp1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libre.so.0', which is also in 
package libre0:amd64 1.1.0-1
  Errors were encountered while processing:
   /var/cache/apt/archives/libre0.1_2.0.1-1~exp1_amd64.deb


cheers,

Andreas
# Partial distribution upgrade
# * install sid: libre0 (1.1.0-1)
# * pick experimental: libre0.1 (2.0.1-1~exp1)

0m0.0s INFO: 
--
0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of 
this logfile.
0m0.0s INFO: FAQ available at https://wiki.debian.org/piuparts/FAQ
0m0.0s INFO: The FAQ also explains how to contact us in case you think piuparts 
is wrong.
0m0.0s INFO: 
--
0m0.0s INFO: piuparts version 1.0.1~202107042316~0.95-51114-g7ed4b9d58 starting 
up.
0m0.0s INFO: Command line arguments: /srv/piuparts/sbin/piuparts 
--no-upgrade-test --warn-on-leftovers-after-purge --skip-logrotatefiles-test 
--scriptsdir /etc/piuparts/scripts/ --tmpdir /tmp/piupartss/dose --mirror 
http://ftp.de.debian.org/debian --basetgz 
/srv/piuparts/slave/basetgz/sid_amd64.tar.gz -d sid -i /etc/nsswitch.conf 
--log-file /tmp/tmp.KOB3e3UZ7y --scriptsdir /tmp/tmp.5noagG7wAB --apt hello
0m0.0s INFO: Running on: Linux zam378 5.10.40 #1 SMP Mon May 31 11:35:20 CEST 
2021 x86_64
0m0.0s DEBUG: Created temporary directory /tmp/piupartss/dose/tmpS2ggoW
0m0.0s DEBUG: Unpacking /srv/piuparts/slave/basetgz/sid_amd64.tar.gz into 
/tmp/piupartss/dose/tmpS2ggoW
0m0.0s DEBUG: Starting command: ['eatmydata', 'tar', '-C', 
'/tmp/piupartss/dose/tmpS2ggoW', '-zxf', 
'/srv/piuparts/slave/basetgz/sid_amd64.tar.gz']
0m2.2s DEBUG: Command ok: ['eatmydata', 'tar', '-C', 
'/tmp/piupartss/dose/tmpS2ggoW', '-zxf', 
'/srv/piuparts/slave/basetgz/sid_amd64.tar.gz']
0m2.2s DEBUG: Starting command: ['mount', '-t', 'proc', 'proc', 
'/tmp/piupartss/dose/tmpS2ggoW/proc']
0m2.2s DEBUG: Command ok: ['mount', '-t', 'proc', 'proc', 
'/tmp/piupartss/dose/tmpS2ggoW/proc']
0m2.2s DEBUG: Starting command: ['mount', '-t', 'devpts', '-o', 
'newinstance,noexec,nosuid,gid=5,mode=0620,ptmxmode=0666', 'devpts', 
'/tmp/piupartss/dose/tmpS2ggoW/dev/pts']
0m2.2s DEBUG: Command ok: ['mount', '-t', 'devpts', '-o', 
'newinstance,noexec,nosuid,gid=5,mode=0620,ptmxmode=0666', 'devpts', 
'/tmp/piupartss/dose/tmpS2ggoW/dev/pts']
0m2.2s DEBUG: Starting command: ['mount', '-o', 'bind', 
'/tmp/piupartss/dose/tmpS2ggoW/dev/pts/ptmx', 
'/tmp/piupartss/dose/tmpS2ggoW/dev/ptmx']
0m2.2s DEBUG: Command ok: ['mount', '-o', 'bind', 
'/tmp/piupartss/dose/tmpS2ggoW/dev/pts/ptmx', 
'/tmp/piupartss/dose/tmpS2ggoW/dev/ptmx']
0m2.2s DEBUG: Starting command: ['mount', '-o', 'bind', '/dev/pts/26', 
'/tmp/piupartss/dose/tmpS2ggoW/dev/console']
0m2.3s DEBUG: Command ok: ['mount', '-o', 'bind', '/dev/pts/26', 
'/tmp/piupartss/dose/tmpS2ggoW/dev/console']
0m2.3s DEBUG: Starting command: ['mount', '-t', 'tmpfs', '-o', 'size=65536k', 
'tmpfs', '/tmp/piupartss/dose/tmpS2ggoW/dev/shm']
0m2.3s DEBUG: Command ok: ['mount', '-t', 'tmpfs', '-o', 'size=65536k', 
'tmpfs', '/tmp/piupartss/dose/tmpS2ggoW/dev/shm']
0m2.3s DEBUG: Starting command: ['mount', '-t', 'sysfs', '-o', 
'nosuid,nodev,noexec', 'sysfs', '/tmp/piupartss/dose/tmpS2ggoW/sys']
0m2.3s DEBUG: Command ok: ['mount', '-t', 'sysfs', '-o', 'nosuid,nodev,noexec', 
'sysfs', '/tmp/piupartss/dose/tmpS2ggoW/sys']
0m2.3s DEBUG: sources.list:
  deb http://ftp.de.debian.org/debian sid main
  deb http://ftp.de.debian.org/debian sid contrib
  deb http://ftp.de.debian.org/debian sid non-free
0m2.4s DEBUG: Created policy-rc.d and chmodded it.
0m2.4s DEBUG: Created resolv.conf.
0m2.4s DEBUG: Copying scriptsdir /etc/piuparts/scripts/ to 
/tmp/piupartss/dose/tmpS2ggoW/tmp/scripts/
0m2.4s DEBUG: Copying scriptsdir /tmp/tmp.5noagG7wAB to 
/tmp/piupartss/dose/tmpS2ggoW/tmp/scripts/
0m2.4s INFO: Running scripts post_chroot_unpack
0m2.4s DEBUG: Starting command: ['chroot', '/tmp/piupartss/dose/tmpS2ggoW', 
'tmp/scripts/post_chroot_unpack_allow_unauthenticated']
0m2.4s DEBUG: Command 

Bug#990849: dpkg-dev: dpkg-buildpackage fails trying multifile optimization with dwz on aarch64 and armv71

[Dennis Bijwaard]

Package: dpkg-dev
Version: 1.19.7
Severity: normal

Dear all,

When I use dpkg-buildpackage -us -uc on different machines, it sometimes
fails to create packages during multifile optimization, at least on
armv71 and aarch64 machines for packaging 3 golang executables. The
same package is created without problems on x86_64. The golang binaries 
are copied using a debian/install file (failed to get dh_golang working).

I found a work-around to at least create a package on these machines
using DEB_BUILD_OPTIONS=nostrip, but the package remains quite big. A regular
strip on the binaries does reduce them a bit, this could be an
alternative when dwz fails. Alternatively, it would be great if there
was an option to disable multifile option of dwz via e.g. DEB_BUILD_OPTIONS. 
Or is there already an easy way to pass the --no-dwz-multifile option to
dh_dzw when invoked via dpkg-buildpackage?

Below is the trace of the failing dpkg-buildpackage.

Kind regards
Dennis

   ...
   dh_link -O--builddirectory=. -O--buildsystem=makefile
   dh_strip_nondeterminism -O--builddirectory=. -O--buildsystem=makefile
   dh_compress -O--builddirectory=. -O--buildsystem=makefile
cd debian/sst-goflow
chmod a-x usr/share/doc/sst-goflow/changelog
gzip -9nf usr/share/doc/sst-goflow/changelog
cd '/home/dennis/work/lv-sensor-sw/flowprocessing/golang'
   dh_fixperms -O--builddirectory=. -O--buildsystem=makefile
find debian/sst-goflow ! -type l -a -true -a -true -print0 2>/dev/null 
| xargs -0r chmod go=rX,u+rw,a-s
find debian/sst-goflow/usr/share/doc -type f -a -true -a ! -regex 
'debian/sst-goflow/usr/share/doc/[^/]*/examples/.*' -print0 2>/dev/null | xargs 
-0r chmod 0644
find debian/sst-goflow/usr/share/doc -type d -a -true -a -true -print0 
2>/dev/null | xargs -0r chmod 0755
find debian/sst-goflow -type f \( -name '*.so.*' -o -name '*.so' -o 
-name '*.la' -o -name '*.a' -o -name '*.js' -o -name '*.css' -o -name '*.scss' 
-o -name '*.sass' -o -name '*.jpeg' -o -name '*.jpg' -o -name '*.png' -o -name 
'*.gif' -o -name '*.cmxs' -o -name '*.node' \) -a -true -a -true -print0 
2>/dev/null | xargs -0r chmod 0644
find debian/sst-goflow/usr/bin -type f -a -true -a -true -print0 
2>/dev/null | xargs -0r chmod a+x
   dh_missing -O--builddirectory=. -O--buildsystem=makefile
   dh_dwz -O--builddirectory=. -O--buildsystem=makefile
install -d debian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu
dwz -q 
-mdebian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug 
-M/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug -- 
debian/sst-goflow/usr/bin/rtd_dsp debian/sst-goflow/usr/bin/rtd_influxdb 
debian/sst-goflow/usr/bin/rtd_web
dwz: Too few files for multifile optimization
objcopy --compress-debug-sections 
debian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug
objcopy: 
'debian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug': No 
such file
dh_dwz: objcopy --compress-debug-sections 
debian/sst-goflow/usr/lib/debug/.dwz/aarch64-linux-gnu/sst-goflow.debug 
returned exit code 1
make[1]: *** [debian/rules:17: binary] Error 2
make[1]: Leaving directory 
'/home/dennis/work/lv-sensor-sw/flowprocessing/golang'
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
make: *** [Makefile:29: deb] Error 2



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

-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.12-rockchip64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dpkg-dev depends on:
ii  binutils  2.31.1-16
ii  bzip2 1.0.6-9.2~deb10u1
ii  libdpkg-perl  1.19.7
ii  make  4.2.1-1.2
ii  patch 2.7.6-3+deb10u1
ii  perl  5.28.1-6+deb10u1
ii  tar   1.30+dfsg-6
ii  xz-utils  5.2.4-1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.6
ii  fakeroot 1.23-1
ii  gcc [c-compiler] 4:8.3.0-1
ii  gcc-8 [c-compiler]   8.3.0-6
ii  gnupg2.2.12-1+deb10u1
ii  gnupg2   2.2.12-1+deb10u1
ii  gpgv 2.2.12-1+deb10u1
pn  libalgorithm-merge-perl  

Versions of packages dpkg-dev suggests:
pn  debian-keyring  

-- no debconf information

Bug#990847: xtensor-blas-dev: missing Breaks+Replaces: libxtensor-blas-dev (<< 0.19)

[Andreas Beckmann]

Package: xtensor-blas-dev
Version: 0.19.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../xtensor-blas-dev_0.19.1-1_amd64.deb ...
  Unpacking xtensor-blas-dev:amd64 (0.19.1-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/xtensor-blas-dev_0.19.1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/include/xflens/cxxblas/LICENSE', which is also in 
package libxtensor-blas-dev:amd64 0.18.0-2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/xtensor-blas-dev_0.19.1-1_amd64.deb


cheers,

Andreas
# Partial distribution upgrade
# * install sid: libxtensor-blas-dev (0.18.0-2)
# * pick experimental: xtensor-blas-dev (0.19.1-1)

0m0.0s INFO: 
--
0m0.0s INFO: To quickly glance what went wrong, scroll down to the bottom of 
this logfile.
0m0.0s INFO: FAQ available at https://wiki.debian.org/piuparts/FAQ
0m0.0s INFO: The FAQ also explains how to contact us in case you think piuparts 
is wrong.
0m0.0s INFO: 
--
0m0.0s INFO: piuparts version 1.0.1~202107042316~0.95-51114-g7ed4b9d58 starting 
up.
0m0.0s INFO: Command line arguments: /srv/piuparts/sbin/piuparts 
--no-upgrade-test --warn-on-leftovers-after-purge --skip-logrotatefiles-test 
--scriptsdir /etc/piuparts/scripts/ --tmpdir /tmp/piupartss/dose --mirror 
http://ftp.de.debian.org/debian --basetgz 
/srv/piuparts/slave/basetgz/sid_amd64.tar.gz -d sid -i /etc/nsswitch.conf 
--log-file /tmp/tmp.a6VkZQjc5b --scriptsdir /tmp/tmp.WaeUqNUe9r --apt hello
0m0.0s INFO: Running on: Linux zam378 5.10.40 #1 SMP Mon May 31 11:35:20 CEST 
2021 x86_64
0m0.0s DEBUG: Created temporary directory /tmp/piupartss/dose/tmpLCPKvy
0m0.0s DEBUG: Unpacking /srv/piuparts/slave/basetgz/sid_amd64.tar.gz into 
/tmp/piupartss/dose/tmpLCPKvy
0m0.0s DEBUG: Starting command: ['eatmydata', 'tar', '-C', 
'/tmp/piupartss/dose/tmpLCPKvy', '-zxf', 
'/srv/piuparts/slave/basetgz/sid_amd64.tar.gz']
0m1.6s DEBUG: Command ok: ['eatmydata', 'tar', '-C', 
'/tmp/piupartss/dose/tmpLCPKvy', '-zxf', 
'/srv/piuparts/slave/basetgz/sid_amd64.tar.gz']
0m1.6s DEBUG: Starting command: ['mount', '-t', 'proc', 'proc', 
'/tmp/piupartss/dose/tmpLCPKvy/proc']
0m1.7s DEBUG: Command ok: ['mount', '-t', 'proc', 'proc', 
'/tmp/piupartss/dose/tmpLCPKvy/proc']
0m1.7s DEBUG: Starting command: ['mount', '-t', 'devpts', '-o', 
'newinstance,noexec,nosuid,gid=5,mode=0620,ptmxmode=0666', 'devpts', 
'/tmp/piupartss/dose/tmpLCPKvy/dev/pts']
0m1.7s DEBUG: Command ok: ['mount', '-t', 'devpts', '-o', 
'newinstance,noexec,nosuid,gid=5,mode=0620,ptmxmode=0666', 'devpts', 
'/tmp/piupartss/dose/tmpLCPKvy/dev/pts']
0m1.7s DEBUG: Starting command: ['mount', '-o', 'bind', 
'/tmp/piupartss/dose/tmpLCPKvy/dev/pts/ptmx', 
'/tmp/piupartss/dose/tmpLCPKvy/dev/ptmx']
0m1.7s DEBUG: Command ok: ['mount', '-o', 'bind', 
'/tmp/piupartss/dose/tmpLCPKvy/dev/pts/ptmx', 
'/tmp/piupartss/dose/tmpLCPKvy/dev/ptmx']
0m1.7s DEBUG: Starting command: ['mount', '-o', 'bind', '/dev/pts/26', 
'/tmp/piupartss/dose/tmpLCPKvy/dev/console']
0m1.8s DEBUG: Command ok: ['mount', '-o', 'bind', '/dev/pts/26', 
'/tmp/piupartss/dose/tmpLCPKvy/dev/console']
0m1.8s DEBUG: Starting command: ['mount', '-t', 'tmpfs', '-o', 'size=65536k', 
'tmpfs', '/tmp/piupartss/dose/tmpLCPKvy/dev/shm']
0m1.8s DEBUG: Command ok: ['mount', '-t', 'tmpfs', '-o', 'size=65536k', 
'tmpfs', '/tmp/piupartss/dose/tmpLCPKvy/dev/shm']
0m1.8s DEBUG: Starting command: ['mount', '-t', 'sysfs', '-o', 
'nosuid,nodev,noexec', 'sysfs', '/tmp/piupartss/dose/tmpLCPKvy/sys']
0m1.8s DEBUG: Command ok: ['mount', '-t', 'sysfs', '-o', 'nosuid,nodev,noexec', 
'sysfs', '/tmp/piupartss/dose/tmpLCPKvy/sys']
0m1.8s DEBUG: sources.list:
  deb http://ftp.de.debian.org/debian sid main
  deb http://ftp.de.debian.org/debian sid contrib
  deb http://ftp.de.debian.org/debian sid non-free
0m1.8s DEBUG: Created policy-rc.d and chmodded it.
0m1.8s DEBUG: Created resolv.conf.
0m1.8s DEBUG: Copying scriptsdir /etc/piuparts/scripts/ to 
/tmp/piupartss/dose/tmpLCPKvy/tmp/scripts/
0m1.8s DEBUG: Copying scriptsdir /tmp/tmp.WaeUqNUe9r to 
/tmp/piupartss/dose/tmpLCPKvy/tmp/scripts/
0m1.8s INFO: Running scripts post_chroot_unpack
0m1.8s DEBUG: Starting command: ['chroot', '/tmp/piupartss/dose/tmpLCPKvy', 
'tmp/scripts/post_chroot_unpack_allow_unauthenticated']
0m1.8s DEBUG: Command ok: ['chroot', 

Bug#990313: Updated package thorvg

[Michal Maciola]

Hello Timo,

Just uploaded a fixed package.
Please kindly find it for your review.

Cheers,
Michal

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Andreas Beckmann]

On 09/07/2021 09.12, Otto Kekäläinen wrote:

Weird. I renamed the test and extended it bit to have logging and be
uniform in general, and now it passes (without your patch):
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1748275

I was expecting that adding the new step in Salsa-CI would show
failure, and then adding your patch would fix it. I'll try to switch
from apt-get to apt and see if this problem occurs only with apt, but
not apt-get.


I'm trying to find again some of the failures I encountered in my
piuparts instance... (they were all solved by testing with the patched
mariadb-10.5 + galera-4 packages)

You could try installing in buster default-mysql-server + roundcube-core
(still looking for "easier" ones)

Upgrading that to buster yields for me
(even without --install-recommends)

...
  The following packages will be REMOVED:
***default-mysql-server*** libapache2-mod-php7.3 mariadb-client-10.3
mariadb-client-core-10.3 mariadb-server-10.3 php7.3-cli php7.3-common
php7.3-intl php7.3-json php7.3-mbstring php7.3-mysql php7.3-opcache
php7.3-readline php7.3-xml
  The following NEW packages will be installed:
gcc-10-base libapache2-mod-php7.4 libapt-pkg6.0 libbpf0 libcrypt1 libffi7
libgcc-s1 libhogweed6 libicu67 liblua5.3-0 libmariadb3 libmd0 libnettle8
libnsl2 libonig5 libperl5.32 libreadline8 libtirpc-common libtirpc3
libxxhash0 logsave mailcap mariadb-client mariadb-client-10.5
mariadb-client-core-10.5 media-types perl-modules-5.32 php7.4-cli
php7.4-common php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql
php7.4-opcache php7.4-readline php7.4-xml
  The following packages have been kept back:
***roundcube-core roundcube-mysql***
  The following packages will be upgraded:
...

Andreas

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Andreas Beckmann]

On 09/07/2021 08.37, Andreas Beckmann wrote:

On 09/07/2021 07.27, Otto Kekäläinen wrote:

In the meantime you might want to think about the galera-4 branch
990708 because Salsa-CI shows it regressed:
https://salsa.debian.org/mariadb-team/galera-4/-/jobs/1744367


That should solve itself once the mariadb fix gets uploaded.


I've enabled problem resolver debugging for the upgrade job:

Investigating (0) galera-4:amd64 < none -> 26.4.8-2+salsaci @un uN Ib >
Broken galera-4:amd64 Breaks on galera-3:amd64 < 25.3.25-2 -> 25.3.33-1 @ii umU > 
(< 26.4)
  Considering galera-3:amd64 0 as a solution to galera-4:amd64 0
  Holding Back galera-4:amd64 rather than change galera-3:amd64
Investigating (0) mariadb-server-10.5:amd64 < none -> 1:10.5.10-2 @un uN Ib >
Broken mariadb-server-10.5:amd64 Depends on galera-4:amd64 < none | 26.4.8-2+salsaci 
@un uH > (>= 26.4)
  Considering galera-4:amd64 0 as a solution to mariadb-server-10.5:amd64 0
  Holding Back mariadb-server-10.5:amd64 rather than change galera-4:amd64

Once the mariadb fix is available, the scores should move 1 point in favor
of galera-4 (probably galera-3: -1, galera-4: 0) and this should be solved.

Looks like the changelog bump was not needed, since there is the
+salsaci suffix, but I wasn't sure beforehand which package version
was going to be tested.

Andreas

Bug#990846: ITP: golang-github-go-piv-piv-go -- Keys and certificates for YubiKeys, written in Go

[Taowa]

Package: wnpp
Severity: wishlist
Owner: Taowa 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-go-piv-piv-go
  Version : 1.8.0-1
  Upstream Author : Eric Chiang
* URL : https://github.com/go-piv/piv-go
* License : Apache-2.0
  Programming Lang: Go
  Description : Keys and certificates for YubiKeys, written in Go

 A Go YubiKey PIV implementation
 .
 YubiKeys implement the PIV specification for managing smart card
 certificates.  This applet is a simpler alternative to GPG for managing
 asymmetric keys on a YubiKey.

This is an rdep for yubikey-agent (#969181).

-- 
Taowa (they)
people.debian.org/~taowa
LOC FN35EL

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Otto Kekäläinen]

Weird. I renamed the test and extended it bit to have logging and be
uniform in general, and now it passes (without your patch):
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/jobs/1748275

I was expecting that adding the new step in Salsa-CI would show
failure, and then adding your patch would fix it. I'll try to switch
from apt-get to apt and see if this problem occurs only with apt, but
not apt-get.

Bug#990845: ITP: golang-github-gopasspw-pinentry -- Pinentry client in Go

[Taowa]

Package: wnpp
Severity: wishlist
Owner: Taowa 

* Package name: golang-github-gopasspw-pinentry
  Version : 0.0.2-1
  Upstream Author : Gopass Authors
* URL : https://github.com/gopasspw/pinentry
* License : Expat
  Programming Lang: Go
  Description : Pinentry client in Go

 Pinentry client in Go

This pinentry library from gopass is an rdep of yubikey-agent (#969181).

-- 
Taowa (they)
people.debian.org/~taowa
LOC FN35EL

Bug#988909: Please make sure lintian-brush will migrate to testing (Was: routine-update is marked for autoremoval from testing)

[Andreas Tille]

Hi Jelmer,

its only four days left to get lintian-brush migrating.  You definitely
need to do some action.

Kind regards
Andreas.

On Fri, Jul 09, 2021 at 04:39:03AM +, Debian testing autoremoval watch 
wrote:
> routine-update 0.0.6 is marked for autoremoval from testing on 2021-07-13
> 
> It (build-)depends on packages with these RC bugs:
> 988909: lintian-brush: autopkgtest failure and FTBFS
>  https://bugs.debian.org/988909
> 
> 
> 
> This mail is generated by:
> https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
> 
> Autoremoval data is generated by:
> https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Andreas Beckmann]

On 09/07/2021 06.50, Otto Kekäläinen wrote:

..but this easily gets too verbose. Ideally apt had a mode that if it
fails, it would output a proper error message with a "trace", but in
normal cases stays short and sweet not to clutter the logs too much.


In the current scenario apt does not fail, it just takes a "suboptimal" 
decision: removing the package we are interested in. You would want a 
trace here, too.


Do you read the successful logs? Does it really matter that they are 
"too verbose"?
Similarily buildd logs should be as verbose as possible, s.t. there is 
hopefully enough information to investigate failures if the only thing 
being available is the logfile.


Andreas

Bug#990708: [debian-mysql] Bug#990708: mariadb-server-10.5: upgrade problems due to galera-3 -> galera-4 switch

[Andreas Beckmann]

On 09/07/2021 07.27, Otto Kekäläinen wrote:

In the meantime you might want to think about the galera-4 branch
990708 because Salsa-CI shows it regressed:
https://salsa.debian.org/mariadb-team/galera-4/-/jobs/1744367


That should solve itself once the mariadb fix gets uploaded.

Andreas