Bug#974949: systray-mdstat: fails to start with org.freedesktop.DBus.Error.ServiceUnknown

[Francesco Poli]

On Tue, 17 Nov 2020 01:30:19 +0100 Axel Beckert wrote:

> Hi Francesco,

Hi Axel!
Thanks for your prompt reply.

> 
> Axel Beckert wrote:
> > Francesco Poli (wintermute) wrote:
> > >   $ systray-mdstat &
> > >   [1] 64881
> > >   $ org.freedesktop.DBus.Error.ServiceUnknown: The name 
> > > org.freedesktop.Notifications was not provided by any .service files
> 
> Seems to be a missing dependency on notification-daemon.

I have notification-daemon installed on my system:

  $ apt policy notification-daemon
  notification-daemon:
Installed: 3.20.0-4
Candidate: 3.20.0-4
Version table:
   *** 3.20.0-4 800
  800 http://deb.debian.org/debian testing/main amd64 Packages
  500 http://deb.debian.org/debian unstable/main amd64 Packages
  100 /var/lib/dpkg/status

Hence, I would say that adding a dependency on notification-daemon
won't change anything...

> 
> I though wonder how the 1.1.0 version then worked without. :-)

notification-daemon was already installed.



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp7GgpjvCHAX.pgp
Description: PGP signature

Bug#972454: Bug confirmed on arm64 as well

[Jan Huijsmans]

Hi,

Was preparing a report for this bug when I found it already logged.

Yesterday I found this issue as wel on arm64.

Solution:

Build 3.11 from source.

Attachement:

make.log

---

Jan Huijsmans  huysm...@koffie.nu

... cannot activate /dev/brain, no response from main coffee server
DKMS make.log for xtables-addons-3.9 for kernel 5.9.0-2-arm64 (aarch64)
Tue Nov 17 08:02:58 CET 2020
make: Entering directory '/usr/src/linux-headers-5.9.0-2-arm64'
make -C /usr/src/linux-headers-5.9.0-2-arm64 -f /usr/src/linux-headers-5.9.0-2-common/Makefile modules
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\
echo >&2;			\
echo >&2 "  ERROR: Kernel configuration is invalid.";		\
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;			\
/bin/false)
make -f /usr/src/linux-headers-5.9.0-2-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.9/build/extensions \
single-build= \
need-builtin=1 need-modorder=1
make -f /usr/src/linux-headers-5.9.0-2-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.9/build/extensions/ACCOUNT \
 \
need-builtin= \
need-modorder=1
make -f /usr/src/linux-headers-5.9.0-2-common/scripts/Makefile.build obj=/var/lib/dkms/xtables-addons/3.9/build/extensions/pknock \
 \
need-builtin= \
need-modorder=1
   gcc-10 -Wp,-MMD,/var/lib/dkms/xtables-addons/3.9/build/extensions/.compat_xtables.o.d -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/10/include -I/usr/src/linux-headers-5.9.0-2-common/arch/arm64/include -I./arch/arm64/include/generated -I/usr/src/linux-headers-5.9.0-2-common/include -I./include -I/usr/src/linux-headers-5.9.0-2-common/arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I/usr/src/linux-headers-5.9.0-2-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-5.9.0-2-common/include/linux/kconfig.h -include /usr/src/linux-headers-5.9.0-2-common/include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DCC_USING_PATCHABLE_FUNCTION_ENTRY -DKASAN_SHADOW_SCALE_SHIFT=3 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -fno-asynchronous-
 unwind-tables -Wno-psabi -mabi=lp64 -mbranch-protection=pac-ret+leaf+bti -Wa,-march=armv8.4-a -DARM64_ASM_ARCH='"armv8.4-a"' -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g -fpatchable-function-entry=2 -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=/usr/src/linux-headers-5.9.0-2-common/= -Wno-packed-not-aligned -m
 stack-protector-guard=sysreg -mstack-protector-guard-
reg=sp_el0 -mstack-protector-guard-offset=1272  -DMODULE  -DKBUILD_BASENAME='"compat_xtables"' -DKBUILD_MODNAME='"compat_xtables"' -c -o /var/lib/dkms/xtables-addons/3.9/build/extensions/compat_xtables.o /var/lib/dkms/xtables-addons/3.9/build/extensions/compat_xtables.c
   gcc-10 -Wp,-MMD,/var/lib/dkms/xtables-addons/3.9/build/extensions/.xt_CHAOS.o.d -nostdinc -isystem /usr/lib/gcc/aarch64-linux-gnu/10/include -I/usr/src/linux-headers-5.9.0-2-common/arch/arm64/include -I./arch/arm64/include/generated -I/usr/src/linux-headers-5.9.0-2-common/include -I./include -I/usr/src/linux-headers-5.9.0-2-common/arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I/usr/src/linux-headers-5.9.0-2-common/include/uapi -I./include/generated/uapi -include /usr/src/linux-headers-5.9.0-2-common/include/linux/kconfig.h -include /usr/src/linux-headers-5.9.0-2-common/include/linux/compiler_types.h -D__KERNEL__ -mlittle-endian -DCC_USING_PATCHABLE_FUNCTION_ENTRY -DKASAN_SHADOW_SCALE_SHIFT=3 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mgeneral-regs-only -DCONFIG_CC_HAS_K_CONSTRAINT=1 -fno-asynchronous-unwind
 -tables -Wno-psabi -mabi=lp64 -mbranch-protection=pac-ret+leaf+bti -Wa,-march=armv8.4-a -DARM64_ASM_ARCH='"armv8.4-a"' -DKASAN_SHADOW_SCALE_SHIFT=3 -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation 

Bug#974959: dynare: reproducible builds: autotools generated files contain variable paths and data

[Vagrant Cascadian]

Source: dynare
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge buildpath randomness
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

In files shipped in dynare, build paths, binary paths and data in
arbitrary order are embedded in a shipped Makefile and data
autom4te.cache/requests file:

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

/usr/src/matlab/dynare-matlab/mex/sources/Makefile contains build paths
(e.g. /build/1st/dynare-4.6.2/ vs. /build/2/dynare-4.6.2/2nd/) and when
built on a usrmerge system vs. a non-usermerge system, binary paths that
vary (e.g. /bin/grep vs. /usr/bin/grep).

/usr/src/matlab/dynare-matlab/mex/build/matlab/autom4te.cache/requests
contains what appears to be the same information but in an undefined
order varies between builds.

I *think* these files would need to be regenerated in order to be used
by the end-user, as the build paths or binary paths embedded in them may
not match the system on which they would be used. If that is correct,
the attached patch removes these files using a debian/rules dh_install
override.


live well,
  vagrant
From 6eb2e4c4bd27441a0039eec4704f526de033045d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 17 Nov 2020 03:03:57 +
Subject: [PATCH 2/2] debian/rules: Remove Makefile and autom4te.cache/requests
 in dh_install override.

These files contain build-specific information and need to be
regenerated when used anyways.
---
 debian/rules | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/rules b/debian/rules
index c77220d..5d0839e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -31,6 +31,13 @@ override_dh_auto_test:
 execute_before_dh_auto_clean:
 	-[ -f Makefile ] && echo -e "distclean:\n\t-rm -f Makefile" > mex/build/matlab/Makefile
 
+override_dh_install:
+	dh_install
+	# Remove auto-generated files which cause reproducibility
+	# issues and need to be regenerated to use.
+	rm -f debian/dynare-matlab/usr/src/matlab/dynare-matlab/mex/sources/Makefile
+	rm -f debian/dynare-matlab/usr/src/matlab/dynare-matlab/mex/build/matlab/autom4te.cache/requests 
+
 execute_after_dh_installdocs-indep:
 	cp -dR doc/manual/build/html/ debian/dynare-doc/usr/share/doc/dynare/dynare.html
 
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#974958: lintian-brush: debian-watch-file-old-format: don't run for native packages without watch files

[Paul Wise]

Package: lintian-brush
Version: 0.86
Severity: normal
Usertags: crash

Whilst preparing an apt-listchanges NMU (a native package without a
watch file), I got an error from debian-watch-file-old-format, it looks
like it always expects the watch file to be present, but that is
unlikely for native packages.

apt-listchanges (master=) $ lintian-brush 
No changes made.


Some fixer scripts failed to run: {'debian-watch-file-old-format'}. Run with 
--verbose for details.

apt-listchanges (master=) $ lintian-brush --verbose |& grep -A3 
debian-watch-file-old-format
Fixer 'debian-watch-file-old-format' failed to run.
Script /usr/share/lintian-brush/fixers/debian-watch-file-old-format.py failed 
with exit code: 1
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/lintian_brush/__init__.py", line 287, in 
run
exec(code, global_vars)
  File "/usr/share/lintian-brush/fixers/debian-watch-file-old-format.py", line 
12, in 
if editor.watch_file.version >= WATCH_FILE_LATEST_VERSION:
AttributeError: 'NoneType' object has no attribute 'version'

apt-listchanges (master=) $ ls debian/watch
ls: cannot access 'debian/watch': No such file or directory

apt-listchanges (master=) $ cat debian/source/format 
3.0 (native)

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.4
ii  python3  3.8.6-1
ii  python3-breezy   3.1.0-6
ii  python3-debian   0.1.38
ii  python3-debmutate0.14
ii  python3-distro-info  0.24
ii  python3-dulwich  0.20.2-1
ii  python3-iniparse 0.4-3
ii  python3-ruamel.yaml  0.16.12-2

Versions of packages lintian-brush recommends:
ii  decopy   0.2.4.4-0.1
ii  dos2unix 7.4.1-1
ii  gpg  2.2.20-1
ii  libdebhelper-perl13.2.1
ii  lintian  2.102.0
pn  python3-asyncpg  
ii  python3-bs4  4.9.3-1
ii  python3-levenshtein  0.12.0-5+b2
ii  python3-pyinotify0.9.6-1.3
ii  python3-toml 0.10.1-1

Versions of packages lintian-brush suggests:
pn  breezy-debian  
ii  gnome-pkg-tools0.21.2
ii  po-debconf 1.0.21
pn  postgresql-common  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#974957: dynare: reproducible builds: PDFs contain date of build

[Vagrant Cascadian]

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

Several PDFs shipped in dynare packages embed the build date:

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

  ./usr/share/doc/dynare/gsa.pdf.gz
  7 October·29,·20207   December·2,·2021


The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

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


live well,
  vagrant
From 0049faf101dad15076b360c7dfaba4c51f24f980 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 16 Nov 2020 23:42:45 +
Subject: [PATCH 1/2] debian/rules: Set FORCE_SOURCE_DATE=1 in order for
 texlive to respect SOURCE_DATE_EPOCH for reproducible timestamps.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 2977853..c77220d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,9 @@ include /usr/share/octave/debian/defs.make
 include /usr/share/dpkg/pkg-info.mk
 export DEB_VERSION_UPSTREAM
 
+# Needed for texlive to respect SOURCE_DATE_EPOCH when setting date
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@ --with sphinxdoc,elpa
 
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#860372: hp-search-mac: please make the build reproducible

[Ola Lundqvist]

Hi Chris

Thank you for the reminder. It turns out that I did update it 3 years ago
but forgot to upload. Doing that now.

// Ola

On Wed, 2 Sep 2020 at 01:03, Chris Lamb  wrote:

> Chris Lamb wrote:
>
> > Would you consider applying this patch and uploading?
>
> Friendly ping on this? Seems like there hasn't been any update on this bug
> in
> 971 days now (!).
>
>
> Regards,
>
> --
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
|  o...@inguza.como...@debian.org|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
 ---

Bug#974955: Ignore this report because of wrong patch attached

[MICHIMURA Tadao]

Hi!

Please ignore this bug report, because I had attached wrong patch on the report.
I already submited another bug report with correct patch.

Thanks,
//Tadao

Bug#974956: solid-pop3d crashes on connecting from ipv6 client

[michi]

Package: solid-pop3d
Version: 0.15-30
Severity: important
Tag: patch,ipv6

The solid-pop3d daemon process crashes (segmentation faults) when a client 
connect to the daemon via ipv6 protocol.

Because the 'ntopbuff' variable in standalone.c is too small buffer size.
The 'inet_ntop' main page says the buffer size must be at least 
INET6_ADDRSTRLEN bytes long.
However the 'ntopbuff' is only 24 bytes long.

The following is the patch.


--- standalone.c.orig   2000-05-01 05:56:21.0 +0900
+++ standalone.c2020-11-17 14:36:27.411167044 +0900
@@ -87,7 +87,7 @@

 int main(int argc, char **argv) {
 #ifdef SPIPV6
-   char ntopbuff[24];
+   char ntopbuff[INET6_ADDRSTRLEN];
union sp_sockaddr address;
 #else
struct sockaddr_in address;

//EndOfMessage
/

Bug#974888: growlight: Reproducibly segfaults on pressing F1

[Nick Black]

The segfault at shutdown has been resolved.

See: https://github.com/dankamongmen/growlight/issues/106

This fix will be in 1.2.19, which I am about to cut.

Bug#974561: src:mshr: autopkgtest times out on i386

[Drew Parsons]

Source: mshr
Followup-For: Bug #974561

Confirmed, mshr.UnitSphereMesh has completely lost the plot on i386,
can't even complete mshr.UnitSphereMesh(4).

That is a sad and sorry state for mshr.  But mshr itself is deprecated
(not actively maintained, upstream generally recommends a combination
of gmsh and meshio), so not really worth putting the resources in to
get to the bottom of the stall in mshr.UnitSphereMesh on i386.

All other arches run mshr.UnitSphereMesh fine (even armhf), and all
other tests and demos pass fine.

Recommended workaround for i386 users who want a UnitSphereMesh is to
use a deathstar instead.

For debci, I'll just skip test-meshes on i386.

Bug#974955: solid-pop3d crashes on connecting from ipv6 client

[michi]

Package: solid-pop3d
Version: 0.15-30
Severity: important
Tag: patch,ipv6

The solid-pop3d daemon process crashes (segmentation faults) when a client 
connect to the daemon via ipv6 protocol.

Because the 'ntopbuff' variable in main.c is too small buffer size.
The 'inet_ntop' main page says the buffer size must be at least 
INET6_ADDRSTRLEN bytes long.
However the 'ntopbuff' is only 100 bytes long.

The following is the patch.

--- main.c.orig 2000-05-13 22:18:40.0 +0900
+++ main.c  2020-11-17 13:36:45.941701101 +0900
@@ -1008,7 +1008,7 @@
struct hostent *hentname;
 #endif
 #ifdef SPIPV6
-   char ntopbuff[100];
+   char ntopbuff[INET6_ADDRSTRLEN];
 #endif
 #endif

//EOM

Bug#941447: (No Subject)

[David Tucker]

Upstream bug: https://github.com/pypa/pipenv/issues/4144

Bug#974954: ftp.debian.org: package jupyter-notebook_4.2.3-4+deb9u1 upload REJECTED

[Abhijith PA]

Package: ftp.debian.org
Severity: important


"python-notebook_4.2.3-4+deb9u1_all.deb: Built-Using refers to non-existing 
source package backbone (= 1.3.3~dfsg-1)"

I tried to upload jupyter-notebook to stretch-security as part of LTS.
But package rejected to due to above reason. Please move required
source packages onto security-master for accepting jupyter-notebook. 

I've forwarded the rejected mail to ftpmaster@d.o and pinged on IRC as
well. Apologies if this is redundant.

--abhijith 

Bug#974218: node-requirejs: Please embed typescript definitions

[Xavier]

Le 14/11/2020 à 12:14, László Böszörményi (GCS) a écrit :
> Hi,
> 
> On Wed, Nov 11, 2020 at 2:39 PM Xavier Guimard  wrote:
>> Package: node-requirejs
> [...]
>> to avoid version conflicts, JS team decided to remove typescript
>> definitions (node-typescript-types) and embed them directly in the
>> relevant packages.
>>
>> node-requirejs isn't under JS Team umbrella, so we can't do it for
>> @types/requirejs. But we need to synchronize this work (needs to
>> repack node-typescript-types and add a "Breaks" in your package).
>> Could you do it or give us its maintenance?
>  If you ask me, feel free to take over. But please note that recent
> uploads are done by Georges. You should get his permission first as
> well.
> 
> Regards,
> Laszlo/GCS

Hi Georges,

do you agree ?

Bug#974953: RM: pyresample [mips64el mipsel s390x] -- ROM; Dependencies not available

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org

Please remove pyresample from mips64el, mipsel, and s390x.

numcodecs (a transitive dependency via zarr) is not available on those 
architectures.

Kind Regards,

Bas

Bug#974918: libnotcurses2,libnotcurses++2: missing Breaks+Replaces: libnotcurses1/libnotcurses++1 (>= 2)

[Nick Black]

I've just uploaded 2.0.4+dfsg.1-3, which I believe fixes this
issue. It ought be available within a few hours. I believe that
the version constraints could have been tightened to (>= 2.0.4),
but I didn't see this as adding particularly much value. Thanks
as always for filing these bugs, Andreas! You're the real MVP.

Bug#974900: Fwd: Bug#974900: dash removes trailing slash from script arguments

[Herbert Xu]

Andrej Shadura  wrote:
> 
> this is another bug report I have received.

This is a bug in glob(3).  Please dup and reassign to libc6.  There
is a patch in the queue to disable glob by default again.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#974428: in.telnetd crashes on running Nessus security scan

[Nachiketa Prachanda]

On Wed, 11 Nov 2020 21:17:40 +0530 parameswaran krishnamurthy 
 wrote:

> Package: telnetd
> Version: 0.17-41
> Severity: serious
>
>
> Problem Statement:
>
> The in.telnetd process is seen to crash on running Nessus security scan.
>
> in.telnetd version:
> telnetd_0.17-41_amd64.deb (Debian stretch image)
>
> /etc/inetd.conf:
> telnet stream tcp6 nowait telnetd /usr/sbin/tcpd /usr/sbin/in.telnetd
>
> Possible root cause:
>
> The telnetd process invokes netflush() to flush() data
>
> root@OS10:# #154080 0x7f681f34a8d9 in _IO_new_do_write (fp=,
> data=, to_do=1350) at fileops.c:502
> root@OS10:# #154081 0x7f681f348978 in _IO_new_file_sync
> (fp=0x55a7d9b45150) at fileops.c:882
> root@OS10:# #154082 0x7f681f33e03c in __GI__IO_fflush
> (fp=0x55a7d9b45150) at iofflush.c:40
> root@OS10:# #154083 0x55a7d97f95a0 in netflush () at utility.c:325
> root@OS10:# #154084 0x55a7d97f95d6 in ttloop () at utility.c:81
> root@OS10:# #154085 0x55a7d97f5c55 in getterminaltype
> (name=0x7ffe09676c70 "") at telnetd.c:484
> root@OS10:# #154086 doit (who_len=16, who=0x7ffe09676bf0) at 
telnetd.c:722

> root@OS10:# #154087 main (argc=, argv=, env=) at telnetd.c:402
>
> 2)Error is encountered while flushing.This results in invocation of
> cleanup function
>
> oot@OS10:# #154071 0x7f681f34c4cc in _IO_flush_all_lockp
> (do_lock=do_lock@entry=0) at genops.c:792
> root@OS10:# #154072 0x7f681f34c695 in _IO_cleanup () at genops.c:957
> root@OS10:# #154073 0x7f681f30c8e3 in __run_exit_handlers
> (status=0, listp=, run_list_atexit=run_list_atexit@entry=true,
> run_dtors=run_dtors@entry=true) at exit.c:96
> root@OS10:# #154074 0x7f681f30c99a in __GI_exit (status=) at 
exit.c:105

> root@OS10:# #154075 0x55a7d97f8fd2 in cleanup (sig=sig@entry=0) at
> sys_term.c:736
> root@OS10:# #154076 0x55a7d97f92d0 in netwritebuf () at utility.c:288
> root@OS10:~# #154077 0x55a7d97f94be in netwrite (cookie=,
>
> 3)The cleanup function invokes exit(0), which in turn trigger flushing
> again. The flushing encounters the error again ,resulting in
> continuous loop.
>
> root@OS10:# #154070 0x7f681f34a8d9 in _IO_new_do_write (fp=,
> data=, to_do=1350) at fileops.c:502
> root@OS10:# #154071 0x7f681f34c4cc in _IO_flush_all_lockp
> (do_lock=do_lock@entry=0) at genops.c:792
> root@OS10:# #154072 0x7f681f34c695 in _IO_cleanup () at genops.c:957
> root@OS10:# #154073 0x7f681f30c8e3 in __run_exit_handlers
> (status=0, listp=, run_list_atexit=run_list_atexit@entry=true,
> run_dtors=run_dtors@entry=true) at exit.c:96
> root@OS10:# #154074 0x7f681f30c99a in __GI_exit (status=) at 
exit.c:105


Noticed the same. Attached a patch to fix this issue.


Description: Infinite recursion on cleanup.
 This is haappening from the handling from "Abort Output"
 command. This causes flushing of "netfile", which in turn
 calls fflush. In this case, the netwritebuf() also fails
 to write the iovec. That in turns calls cleanup(0). This
 leads to another call to fflush() from the atexit handler,
 causing a recursion that never ends as writev() in netwrtebuf()
 keeps on failing.
 
 Fix by chekcing the return from netwritebuf and return error
 to the caller.

Author: Nachiketa Prachanda 
Comment: Fix infinite recursion on cleanup
Forwarded: no
Last Update: 2020-11-16

--- a/telnetd/utility.c
+++ b/telnetd/utility.c
@@ -236,7 +236,7 @@
doclear--;
 }  /* end of netclear */
 
-static void
+static int
 netwritebuf(void)
 {
struct iovec *vector;
@@ -247,11 +247,11 @@
int ltrailing = trailing;
 
if (!listlen)
-   return;
+   return 0;
 
vector = malloc(listlen * sizeof(struct iovec));
if (!vector) {
-   return;
+   return -1;
}
 
len = listlen - (doclear & ltrailing);
@@ -284,9 +284,12 @@
free(vector);
 
if (n < 0) {
-   if (errno != EWOULDBLOCK && errno != EINTR)
-   cleanup(0);
-   return;
+   if (errno != EWOULDBLOCK && errno != EINTR) {
+   syslog(LOG_INFO, "telnetd:%s:%d:errno=%d\n", __func__, 
__LINE__, errno);
+   return -1;
+   /* cleanup(0); */
+   }
+   return 0;
}
 
len = n + skip;
@@ -312,6 +315,7 @@
}
 
skip = len;
+   return 0;
 }
 
 /*
@@ -1247,7 +1251,8 @@
ret += l;
}
 
-   netwritebuf();
+   if (netwritebuf() < 0)
+   return -1;
return ret;
 }
 

Bug#974888: growlight: Reproducibly segfaults on pressing F1

[Nick Black]

Regarding your request to document 'H', I hope you'll find this
commit most pleasing: 
https://github.com/dankamongmen/growlight/commit/899881ddd3cd1839fad01963c70ecb2faf17be71
This will be present in 1.2.19.

Bug#974951: RFP: Marker — A gtk3 markdown editor

[Marek Ľach]

package: Marker
severity: wishlist

description: A markdown editor written with GTK3.

license: GPLv3
source code: https://github.com/fabiocolacio/Marker

Bug#956454: gmsh: Gmsh segfaults at startup

[Thomas V.]

Package: gmsh
Version: 4.6.0+ds1-1
Followup-For: Bug #956454

Dear Maintainer,

Gmsh segfaults at startup, even for systems without the radeon driver (I am
using nouveau). Here is a transcript:

$ gmsh
Segmentation fault

Running gdb reports the error in:
Thread 1 "gmsh" received signal SIGSEGV, Segmentation fault.
0x766e516e in XFillRectangle () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6

and the backtrace is:
#0  0x766e516e in XFillRectangle () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#1  0x768bed9a in Fl_Graphics_Driver::rectf(int, int, int, int) () from 
/usr/lib/x86_64-linux-gnu/libfltk.so.1.3
#2  0x77612a05 in drawContextFltkStringTexture::queueString::flush() () 
from /usr/lib/x86_64-linux-gnu/libgmsh.so.4.6
#3  0x775f4092 in openglWindow::draw() () from 
/usr/lib/x86_64-linux-gnu/libgmsh.so.4.6
#4  0x769439f5 in Fl_Gl_Window::flush() () from 
/usr/lib/x86_64-linux-gnu/libfltk_gl.so.1.3
#5  0x76848117 in Fl::flush() () from 
/usr/lib/x86_64-linux-gnu/libfltk.so.1.3
#6  0x76849170 in Fl::wait(double) () from 
/usr/lib/x86_64-linux-gnu/libfltk.so.1.3
#7  0x7684924d in Fl::check() () from 
/usr/lib/x86_64-linux-gnu/libfltk.so.1.3
#8  0x76f4d988 in Msg::Direct(char const*, ...) () from 
/usr/lib/x86_64-linux-gnu/libgmsh.so.4.6
#9  0x775c428d in FlGui::instance(int, char**, bool, void (*)(char 
const*, ...)) () from /usr/lib/x86_64-linux-gnu/libgmsh.so.4.6
#10 0x76f3c8d8 in GmshFLTK(int, char**) () from 
/usr/lib/x86_64-linux-gnu/libgmsh.so.4.6
#11 0x76f3dafb in GmshMainFLTK(int, char**) () from 
/usr/lib/x86_64-linux-gnu/libgmsh.so.4.6
#12 0x76990cca in __libc_start_main (main=0x5050 , 
argc=1, argv=0x7fffde88, init=, 
fini=, rtld_fini=, stack_end=0x7fffde78) 
at ../csu/libc-start.c:308
#13 0x508a in _start ()

Best Regards,
Thomas

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 gmsh depends on:
ii  libc6 2.31-4
ii  libgmsh4  4.6.0+ds1-1

Versions of packages gmsh recommends:
ii  gmsh-doc  4.6.0+ds1-1

gmsh suggests no packages.

-- no debconf information

Bug#974952: libcoarrays-dev: Can not install libcoarrays-dev with multiarch

[Nobuhiro Iwamatsu]

Package: libcoarrays-dev
Version: 2.4.0-2
Severity: important

Dear Maintainer,

libcoarrays-dev can not install with multiarch.
When I run it, I get the following error:


```
$ sudo apt-get install --no-install-recommends --no-install-suggests 
libcoarrays-dev:arm64
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libcoarrays-dev:arm64 : Depends: gfortran:arm64 (>= 6.1-1) but it is
 not going to be installed
E: Unable to correct problems, you have held broken packages.
```

This is also a issue on unstable.
Could you check and fix this issue?

Best regards,
  Nobuhiro

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

Kernel: Linux 5.8.0-1-amd64 (SMP w/32 CPU threads)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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

Bug#763631: less: -j option yields n-1 spurious lines before the file when going to line 1

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/gwsw/less/issues/93

I can reproduce the bug with upstream's master branch.

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

Bug#763631: less: -j option yields n-1 spurious lines before the file when going to line 1

[Vincent Lefevre]

Control: tags -1 - patch

On 2020-11-17 02:07:08 +0100, Vincent Lefevre wrote:
> I've attached a simple patch. The idea is that the line number for
> the A_GOLINE command must not be smaller than the -j value, except
> when this value is larger than the screen height (this is probably
> an unexpected case, but it is correctly handled by my patch).

Actually this is not that simple. There is a confusion between
logical lines and physical lines, so that this patch does not
work well when the file starts with long lines (longer than the
width of the terminal).

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

Bug#974945: Acknowledgement (xsane: Resolution of saved images does not match scan resolution)

[Reuben Thomas]

Having looked into this further, I think this may be a bug in the
proprietary lexmark_nscan backend: it provides an option --scan-resolution,
which is available in "Standard options", but (I am guessing) not the
standard "resolution" option. Therefore, xsane can't tell that it supports
different resolutions.

Feel free to close this bug, therefore.

-- 
https://rrt.sc3d.org

Bug#974945: xsane: Resolution of saved images does not match scan resolution

[Reuben Thomas]

Package: xsane
Version: 0.999-8ubuntu2
Severity: minor

The resolution of saved PNMs is hardwired to 72dpi. Is there a good reason
for that? If not, I would be happy to prepare a patch that sets the
resolution of the PNM to the scan resolution.

Similarly, and perhaps it is the same problem, it would be good if the
preview showed 100% at the same size regardless of the scan resolution.

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

Kernel: Linux 5.4.0-52-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xsane depends on:
ii  libc6   2.31-0ubuntu9.1
ii  libgimp2.0  2.10.18-1
ii  libglib2.0-02.64.3-1~ubuntu20.04.1
ii  libgtk2.0-0 2.24.32-4ubuntu4
ii  libjpeg88c-2ubuntu8
ii  liblcms2-2  2.9-4
ii  libpng16-16 1.6.37-2
ii  libsane 1.0.29-0ubuntu5.2
ii  libtiff54.1.0+git191117-2build1
ii  sensible-utils  0.0.12+nmu1
ii  xsane-common0.999-8ubuntu2
ii  zlib1g  1:1.2.11.dfsg-2ubuntu1.2

Versions of packages xsane recommends:
ii  cups-client2.3.1-9ubuntu1.1
ii  firefox [www-browser]  82.0.3+build1-0ubuntu0.20.04.1
ii  links [www-browser]2.20.2-1
ii  lynx [www-browser] 2.9.0dev.5-1
ii  w3m [www-browser]  0.5.3-37

Versions of packages xsane suggests:
ii  gimp 2.10.18-1
ii  gocr 0.52-3
ii  gv   1:3.7.4-2
pn  hylafax-client | mgetty-fax  
ii  tesseract-ocr4.1.1-2build2

-- no debconf information

Bug#763631: less: -j option yields n-1 spurious lines before the file when going to line 1

[Vincent Lefevre]

Control: found -1 551-2
Control: tags -1 patch

On 2014-10-01 16:15:52 +0200, Vincent Lefevre wrote:
> When the -j option is used with a value larger than 1 (the purpose of
> this option), n-1 spurious lines appear before the file when going to
> line 1. For instance, type:
> 
>   printf "Line %d\n" `seq 200` | less -Mj3
> 
> and in "less", type < to go to the beginning of the file (line 1).
> One gets:
> 
> ~
> ~
> Line 1
> Line 2
> Line 3
> Line 4
> Line 5
> Line 6
> [...]
> 
> Though the specification of -j says that the target (line 1) should
> appear here at the third line of the terminal, giving empty context
> lines is useless.

I've attached a simple patch. The idea is that the line number for
the A_GOLINE command must not be smaller than the -j value, except
when this value is larger than the screen height (this is probably
an unexpected case, but it is correctly handled by my patch).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Avoid spurious empty lines before the beginning of the file
 Such lines otherwise occur with option -j and using '<' to go to the
 beginning of the file.
Author: Vincent Lefevre 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763631
Last-Update: 2020-11-17

--- less-551-a/command.c2019-06-11 20:12:01 +0200
+++ less-551-b/command.c2020-11-17 01:21:06 +0100
@@ -1418,8 +1418,8 @@
/*
 * Go to line N, default beginning of file.
 */
-   if (number <= 0)
-   number = 1;
+   if (number < jump_sline)
+   number = jump_sline < sc_height ? jump_sline : 
sc_height;
cmd_exec();
jump_back(number);
break;

Bug#974949: systray-mdstat: fails to start with org.freedesktop.DBus.Error.ServiceUnknown

[Axel Beckert]

Hi Francesco,

Axel Beckert wrote:
> Francesco Poli (wintermute) wrote:
> >   $ systray-mdstat &
> >   [1] 64881
> >   $ org.freedesktop.DBus.Error.ServiceUnknown: The name 
> > org.freedesktop.Notifications was not provided by any .service files

Seems to be a missing dependency on notification-daemon.

I though wonder how the 1.1.0 version then worked without. :-)

Anyway, will fix it, but maybe no more this night.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#974949: systray-mdstat: fails to start with org.freedesktop.DBus.Error.ServiceUnknown

[Axel Beckert]

Hi Francesco,

Francesco Poli (wintermute) wrote:
>   $ systray-mdstat &
>   [1] 64881
>   $ org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.Notifications was not provided by any .service files
>   
>   [1]+  Exit 11 systray-mdstat
> 
> This seems to render the package unusable.

Thanks for the bug report! This looks like there's still a dependency
missing for the new backend. Probably something related to D-Bus.

> Please investigate and fix the bug.

For sure! :-)

Thanks again!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#954794: New packages must not declare themselves Essential

[Jonathan Nieder]

Hi,

Sean Whitton wrote:
> On Mon 16 Nov 2020 at 04:12AM +01, Guillem Jover wrote:
> > On Sat, 2020-11-07 at 13:30:13 -0700, Sean Whitton wrote:

>>> Could I ask you to explain your wanting to reduce the Essential set for
>>> the sake of small installation size in more detail, including some
>>> numbers, please?  It would be good to get to the bottom of Bill's worry
>>> about this change, but in addition, I would like to see a stronger
>>> positive case.
>>
>> I'm not sure about Josh, but I think the main reasons for wanting to
>> reduce the essential set are:
>>
>>   - Making chroots/containers slimmer, which can have a substantial
>> impact when needing lots of them, where even few MiB can make a
>> difference.
>>   - Making bootstrapping (build and installation) in general easier,
>> even though for the former these packages also need to then
>> be ideally removed from the build-essential set too.
>
> Thank you for this, but I was hoping for some more specifics.  For
> example, what are some examples of large Essential: yes packages that
> might actually, in practice, be removable?

See https://wiki.debian.org/Proposals/EssentialOnDiet: an example is
e2fsprogs, which is ~2.1 MiB.  (You might not consider that large, but
when you multiply that by "every Debian installation everywhere", it
adds up.)

https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=nonessentiale2fsprogs;users=helm...@debian.org
shows that people are already adding explicit dependencies on it,
which means that
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954794;msg=111 is
the de facto policy / what people believe policy to say.  (Which is a
surprise to me, but it's a useful signal.)

Thanks,
Jonathan

Bug#973459: uim: FAIL: test-composer.scm

[Takatsugu Nokubi]

On Sat, 31 Oct 2020 21:52:30 +0300 Dmitry Shachnev  wrote:
> Control: unblock 972278 by -1
> > It built for me on abel, which is exactly the same hardware as the
> > buildds where it failed.
> >
> > This makes it feel more like a generic race condition that only happened
> > to hit here than an armel-specific bug.
>
> Indeed, after the second retry uim built fine.

I had checked the source, but I couldn't find the reason from the
source code only.

> | See test2/test-suite.log

I need the test2/test-suite.log file, so I had tried to reproduce it
on abel twice, but
I couldn't get the error, just succeeded.

Can I get the test2/test-suite.log file from anywhere?

Bug#954794: New packages must not declare themselves Essential

[Sean Whitton]

Hello,

On Mon 16 Nov 2020 at 04:12AM +01, Guillem Jover wrote:

> On Sat, 2020-11-07 at 13:30:13 -0700, Sean Whitton wrote:
>> Could I ask you to explain your wanting to reduce the Essential set for
>> the sake of small installation size in more detail, including some
>> numbers, please?  It would be good to get to the bottom of Bill's worry
>> about this change, but in addition, I would like to see a stronger
>> positive case.
>
> I'm not sure about Josh, but I think the main reasons for wanting to
> reduce the essential set are:
>
>   - Making chroots/containers slimmer, which can have a substantial
> impact when needing lots of them, where even few MiB can make a
> difference.
>   - Making bootstrapping (build and installation) in general easier,
> even though for the former these packages also need to then
> be ideally removed from the build-essential set too.

Thank you for this, but I was hoping for some more specifics.  For
example, what are some examples of large Essential: yes packages that
might actually, in practice, be removable?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#974950: vim-scripts: missing vim-addon-manager registry file

[Antonio Terceiro]

Package: vim-scripts
Version: 20201113
Severity: grave
Justification: renders package unusable

The new vim-scripts breaks existing usage with vim-addon-manager.

It is missing the vim-addon-manager registry file, and moving the files
around breaks existing users. We might want the file reorganization and
require users to re-install their addons, but the lack of the registry
file makes it unusable with vim-addon-manager (which so far is the
documented way of using vim-scripts).

Thanks for your work maintaining vim and related packages.

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

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

vim-scripts depends on no packages.

Versions of packages vim-scripts recommends:
ii  vim2:8.2.1913-1+b1
ii  vim-addon-manager  0.5.10
ii  vim-gtk3 [vim] 2:8.2.1913-1+b1

Versions of packages vim-scripts suggests:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-13
ii  libtemplate-perl 2.27-1+b3
pn  perlsgml 

-- no debconf information


signature.asc
Description: PGP signature

Bug#974172: libmutter-7-0: Cannot unlock screen with Wayland on arm64, keybard and mouse unresponsive

[Evan McGinnis]

Hi Galí, Simon

I observed this issue as well and have bisected it.

https://salsa.debian.org/gnome-team/mutter/-/commit/209b1ba3

209b1ba383f59e1b398d3331d9fd9fcb7f0284a1

seems to be the culprit

Anything before that commit functions properly on my aarch64 machine.

PS. sorry for the resend-- forgot to include the mailing list


- Hal

Bug#974918: libnotcurses2,libnotcurses++2: missing Breaks+Replaces: libnotcurses1/libnotcurses++1 (>= 2)

[Nick Black]

Confirmed, fixing now. I'll upload 2.0.4+dfsg.1-3 with this fix
present shortly (probably this evening). Thanks once again for
the heads-up, and sorry for the mistake!

Bug#241060: hercules: doesn't handle ^Z

[Philipp Kern]

On Tue, Mar 30, 2004 at 04:55:10PM +0200, Matthias Urlichs wrote:
> While hercules is interruptible by pressing ^Z, some things are a
> bit ugly:
> 
> - - it doesn't reset terminal colors, i.e. the shell prompt is
>   yellow-on-red when I do that;
> 
> - - after resuming, line editing doesn't work any more, and  doesn't
>   switch screens.

I can confirm that this is still the case with a contemporary 3.13 Hercules
build. 

Kind regards
Philipp Kern

Bug#949767: clblas: *gemm wrong answers in out-of-order queues

[Witold Baryluk]

Source: clblas
Followup-For: Bug #949767
X-Debbugs-Cc: witold.bary...@gmail.com

Hi,

any progress on this?

Is this something that the upstream should look into maybe?

Thanks,
Witold


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

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

Bug#974946: lintian fails hard with disabled changelog-should-mention-nmu tag in vendor profile

[Michael Prokop]

Hi Felix,

* Felix Lechner [Mon Nov 16, 2020 at 02:36:20PM -0800]:
> On Mon, Nov 16, 2020 at 2:24 PM Michael Prokop  wrote:

> > ... then lintian 2.101.0 + 2.101.0~bpo10+1 fails hard with:

> If you are using backports, why not switch your profile over to:

> Disable-Tags: no-nmu-in-changelog

> I think that might work on both 2.101.0 + 2.101.0~bpo10+1.

2.101.0 + 2.101.0~bpo10+1 are pretty much the same version. ;)

But "Disable-Tags: no-nmu-in-changelog" then fails hard with e.g.
lintian v2.15.0 from Debian/buster, due to:

| Unknown tag "no-nmu-in-changelog" in profile "example/main" at 
/usr/share/perl5/Lintian/Profile.pm line 474.

Quoting myself from my initial bugreport:

| I'm all for cleaning up, though it would be nice to have backwards
| compatibility for such changes. Otherwise it's impossible to use
| such a lintian profile on e.g. buster and bullseye systems at the
| same time.

regards
-mika-


signature.asc
Description: Digital signature

Bug#969917: trimage: Trimage crashes with 10 or more png images

[Witold Baryluk]

Control: severity -1 important

Bug#974428: in.telnetd crashes on running Nessus security scan

[Nachiketa Prachanda]

On Thu, 12 Nov 2020 09:33:42 +0530 parameswaran krishnamurthy 
 wrote:

> The same crash is observed in the following package too.
>
> package: telnetd-ssl
> version: 0.17.41+0.2-3.2+b1
>

this is an infinite recursion during exit. a patch is attached.

Description: Infinite recursion on cleanup.
 This is haappening from the handling from "Abort Output"
 command. This causes flushing of "netfile", which in turn
 calls fflush. In this case, the netwritebuf() also fails
 to write the iovec. That in turns calls cleanup(0). This
 leads to another call to fflush() from the atexit handler,
 causing a recursion that never ends as writev() in netwrtebuf()
 keeps on failing.
 
 Fix by chekcing the return from netwritebuf and return error
 to the caller.

Author: Nachiketa Prachanda 
Comment: Fix infinite recursion on cleanup
Forwarded: no
Last Update: 2020-11-16

--- a/telnetd/utility.c
+++ b/telnetd/utility.c
@@ -236,7 +236,7 @@
 	doclear--;
 }  /* end of netclear */
 
-static void
+static int
 netwritebuf(void)
 {
 	struct iovec *vector;
@@ -247,11 +247,11 @@
 	int ltrailing = trailing;
 
 	if (!listlen)
-		return;
+		return 0;
 
 	vector = malloc(listlen * sizeof(struct iovec));
 	if (!vector) {
-		return;
+		return -1;
 	}
 
 	len = listlen - (doclear & ltrailing);
@@ -284,9 +284,11 @@
 	free(vector);
 
 	if (n < 0) {
-		if (errno != EWOULDBLOCK && errno != EINTR)
-			cleanup(0);
-		return;
+		if (errno != EWOULDBLOCK && errno != EINTR) {
+			syslog(LOG_INFO, "telnetd:%s:%d:errno=%d\n", __func__, __LINE__, errno);
+			return -1;
+		}
+		return 0;
 	}
 
 	len = n + skip;
@@ -312,6 +314,7 @@
 	}
 
 	skip = len;
+	return 0;
 }
 
 /*
@@ -1247,7 +1250,8 @@
 		ret += l;
 	}
 
-	netwritebuf();
+	if (netwritebuf() < 0)
+		return -1;
 	return ret;
 }
 

Bug#971182: go-mtpfs: FTBFS: src/github.com/hanwen/go-mtpfs/main.go:68:11: undefined: fuse.NewLockingRawFileSystem

[Witold Baryluk]

Package: go-mtpfs
Version: 0.0~git20180209.d6f8f3c-1+b1
Followup-For: Bug #971182
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

this is fixed upstream for almost 2 years.

https://github.com/hanwen/go-mtpfs/commit/cc0483c1f8c18ecd1a2a9db55964c6dc7089bd34#diff-2873f79a86c0d8b3335cd7731b0ecf7dd4301eb19a82ef7a1cba7589b5252261

Including the 1.0.0 tag.

Probably worth updating the pacakge to 1.0.0 or to newest master branch, i.e. 
at commit 42254b1935eb89625d0c8b61bb8128db2cd3c22f

Cheers,
Witold


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

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

Versions of packages go-mtpfs depends on:
ii  libc6 2.31-4
ii  libusb-1.0-0  2:1.0.23-2

go-mtpfs recommends no packages.

go-mtpfs suggests no packages.

-- no debconf information

Bug#886419: systray-mdstat: complains at startup, despite everything appears to be fine

[Francesco Poli]

On Mon, 16 Nov 2020 04:32:37 +0100 Axel Beckert wrote:

[...]
> Just uploaded 1.2.0-1 to Debian Unstable. I closed this bug report as
> I strongly suspect that your issues are gone with using different
> backend libraries for notifications now.
> 
> Please try out and check if that's really the case. If not, please
> reopen with details about how the issue manifests now with the new
> release.

I've just tried the new version: it fails to start.
I reported the issue in a separate bug report...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp1A_HA4goeF.pgp
Description: PGP signature

Bug#974949: systray-mdstat: fails to start with org.freedesktop.DBus.Error.ServiceUnknown

[Francesco Poli (wintermute)]

Package: systray-mdstat
Version: 1.2.0-1
Severity: grave
Justification: renders package unusable

Hello,
I've just given the new version from unstable a try.

It seems to completely fail to start:

  $ systray-mdstat &
  [1] 64881
  $ org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Notifications was not provided by any .service files
  
  [1]+  Exit 11 systray-mdstat

This seems to render the package unusable.
I am setting grave severity accordingly: this should prevent migration
to testing, until the bug is fixed.

Please investigate and fix the bug.
Thanks!


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

Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
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 systray-mdstat depends on:
ii  libdesktop-notify-perl  0.05-2
ii  libfile-sharedir-perl   1.118-1
ii  libgtk3-perl0.037-1
ii  libtry-tiny-perl0.30-1
ii  perl5.30.3-4

systray-mdstat recommends no packages.

Versions of packages systray-mdstat suggests:
ii  fbpanel 7.0-4+b1
pn  smart-notifier  

-- no debconf information

Bug#974946: lintian fails hard with disabled changelog-should-mention-nmu tag in vendor profile

[Felix Lechner]

Hi Michael,

On Mon, Nov 16, 2020 at 2:24 PM Michael Prokop  wrote:
>
> ... then lintian 2.101.0 + 2.101.0~bpo10+1 fails hard with:

If you are using backports, why not switch your profile over to:

Disable-Tags: no-nmu-in-changelog

I think that might work on both 2.101.0 + 2.101.0~bpo10+1.

Kind regards,
Felix Lechner

Bug#928037: mailcap(5): please document security considerations about %-escapes

[Marriott NZ]

On Sat, 14 Nov 2020 08:47:53 +0900, Charles Plessy wrote:
> Rejoice !  I just split the package into two:

I didn't know you were considering this back in 2019, I just saw the message on 
debian-devel, and I'm glad you decided to split.

> So you should be able to remove mailcap easily.

In the mean time, is there a way to deactivate automatic generation of 
/etc/mailcap on stable? Is /etc/update-mime.conf intended for things like that?
Even in the future, if I could do that I wouldn't be barred from installing 
packages depending on "mailcap".

I was not aware of the discussion taking place in #964723 about moving away 
from mailcap which may also be relevant here.
Personally my only concern is the ability to permanently deactivate all default 
rules, be it mailcap or xdg-open or whatever.
Neither my file manager nor my mail user agent has a notion of type/program 
associations whatsoever, so I generally don't care. But sometimes I'm forced to 
use some program that digs up and runs a mailcap rule I didn't write, which 
annoys me to no end (security aside).

I look forward to hearing your view on the main issue (documenting unspecified 
things about mailcap).

Thanks.

Bug#974948: dolfin: FTBFS against boost_1.74

[Anton Gladky]

Package: dolfin
Version: 2019.2.0~git20200629.946dbd3-5
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. One of failures is this:

/<>/dolfin/geometry/IntersectionConstruction.cpp:442:24: 
eg‘min_element’ is not a member of ‘std’; did you mean ‘tuple_element’?
  442 |   const auto it = std::min_element(oo.begin(), oo.end());
  |^~~


It is planned to push boost_1.74 as the default version in Debian/Bullseye.

I have started to work on a fix for that. I will prepare MR when it is ready.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/dolfin_2019.2.0~git20200629.946dbd3-3_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+y+l0RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wbBuQ/+KmU7WNDdN0E2JnpxETnXkvYWHkbAoN+4
jdwHL7k3NtAVzlEgy6/0XfIEUjuJyS2VZcnEietY1EzWG7V2aSMJ12Njcu8itiZG
1Pt/sftEyICjvtMAI1Jhi13n7Yba7fTi29I56cUE6m2C+cctvxT9UBTEt35eXxOt
hsvmx0BwP8Cke9U/QCrGcylIx15SqqgSMeO7yElXvhxPRo48fxYSLjtpZcgyw8O4
Ws+r7CstpOOcDTtL4M9j57xC6W0Q3pFlSAEcoo7PznDD7dU9/1K0P2PhAoYPxEVo
LK6o6BNELIfvOaklacfkRn4AHzGKcQ1T9KudS1NB43cXkPdKcHHDYSuJFNmL2wdk
fdZYN2FHmNolIHVWxqf3ruDJ47qFss7Nq/Lrr1FfbXtHAgO0MG8pzX/qlYqamoLb
ffpalHKJLkisF18XwJ5bFKetL0DeqVaqAuT8H4OwOv8uFHil/gAcUuM6AJCrVKFM
4aZ9XoT3lwWvTeu6O0ZAdoOlm0z6Aq0k5WSbR3G2w7MZndG7iIDB3OuYkmDJxh4I
3UMTQ2AC/1JJF+prLeRwEp2byMvKrNkm5OJjqHDE/t8CaHKtunQ9Jyf6J/vdshVK
+arLVoWgZgh+E471O0+SI5PoTUz7g+sVzV2N7ftOUJFVoyP/eY+JSuc9U/nLymex
H5ALfUNUyTM=
=J7LX
-END PGP SIGNATURE-

Bug#974947: dolfin: FTBFS against boost_1.74

[Anton Gladky]

Package: dolfin
Version: 2019.2.0~git20200629.946dbd3-5
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. One of failures is this:

/<>/dolfin/geometry/IntersectionConstruction.cpp:442:24: 
eg‘min_element’ is not a member of ‘std’; did you mean ‘tuple_element’?
  442 |   const auto it = std::min_element(oo.begin(), oo.end());
  |^~~


It is planned to push boost_1.74 as the default version in Debian/Bullseye.

I have started to work on a fix for that. I will prepare MR when it is ready.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/dolfin_2019.2.0~git20200629.946dbd3-3_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+y++gRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYnaA/9HAAD51ai7GXnjaWMWgu4tbqYfWOJLgGV
7FNBbSbwdpGjAhPXIu8XcT7d8TqDddOaTU5DRQENlKJIDCJgqa8QhGvjXfOGsbKY
4vAWYivi0BT8BvuLgHwX9AieEr/206uNVXDEO986WHEYUKE3VDtyQlI4MGuhV1Hg
5V1C9mmwCzoqdunU8hIFa9tHHjiC+xyoK2HZJEoMMeyrPlWv1E90PdUO0xswXUmi
ctsmwVrRzQvdm5JkmHWI1AVFhwhgIsnWSb3BmT4ew+/wbKkDkrRrOavPs6sZrivE
/cXD7hmbTaxcB7nsOYqUZf8UVj2Ho6stsX2Qdd8yHNoqbYsT4/hlK/8KP2z7X+YP
vGsZiDRfZWO+dHzI/hrzL+cnvgU3dUwxAorknpzFGQpNkgTeeggOnTWBrPwGqC4H
mh3i8+RGRUhktITnrVQ2f78mnANeNBqz/Q3+B16AaoetOMBF4FRkW15zQ2qRmjzQ
q8yLy66FWS/9VIxwcbaieXE2p6QHCEiCCsWZAnWS1HNRjKk+cQN0Nnj92EiAsUWx
EV5rV3ZZCWBqp/i+fgUygN/aEPequxJfn95L3HtnH9GaYDUsD59NZccbRZk9Ltsl
TxXMyC8VPUt1yiIa16GdYeLinxj8YQFyEpP9/XnE7VrSGCQk0ylcMaMBDhQByZAM
bejmfLPFoD4=
=k2yA
-END PGP SIGNATURE-

Bug#974946: lintian fails hard with disabled changelog-should-mention-nmu tag in vendor profile

[Michael Prokop]

Package: lintian
Version: 2.101.0
Severity: important

Hi,

using the following lintian profile:

, [ /etc/lintian/profiles/example or 
~/.lintian/profiles/example/main.profile ]
| Profile: example/main
| Extends: debian/main
| Disable-Tags: changelog-should-mention-nmu
`

... then lintian 2.101.0 + 2.101.0~bpo10+1 fails hard with:

, [ example run ]
| % lintian --profile=example example_0.42.dsc
| Unknown tags in profile example/main: changelog-should-mention-nmu at 
/usr/share/lintian/bin/../lib/Lintian/Profile.pm line 612.
| Lintian::Profile::read_profile(Lintian::Profile=HASH(0x558b15a7e538), 
"example") called at /usr/share/lintian/bin/../lib/Lintian/Profile.pm line 283
| Lintian::Profile::load(Lintian::Profile=HASH(0x558b15a7e538), 
"example", ARRAY(0x558b15b0f4c8), HASH(0x558b15b7c6b0)) called at 
/usr/bin/lintian line 614
| % echo $?
| 255
`

AFAICT this issue is caused by the commit:

| "Mass-rename tags for consistency according to the RFC, with some latitude. 
(Closes: #922544)"
| commit bab2ca64e407e81bbcf625ad8ae945f60f7dcffa
| 
https://salsa.debian.org/lintian/lintian/-/commit/bab2ca64e407e81bbcf625ad8ae945f60f7dcffa

I'm all for cleaning up, though it would be nice to have backwards
compatibility for such changes. Otherwise it's impossible to use
such a lintian profile on e.g. buster and bullseye systems at the
same time.

regards
-mika-


signature.asc
Description: Digital signature

Bug#928037: mailcap(5): please document security considerations about %-escapes

[Marriott NZ]

> It very possibly might. Would you be interested in opening one? The
> information you have given here might be enough.

Can do, but I'll wait for Charles comments.

> Again, it would be nice to report that.

Agreed, but I'm unfamiliar with Thunderbird and I don't use it, so I think I'll 
pass.
I just tried to look up some information as requested in #950319.

> However, at least there must be a documented
> way how things should be implemented to be safe. Only then can we start
> to successfully file actual security-bugs against packages that don't
> follow that rule

That was my intention, and I still want to do it.
Sorry for going a little off topic about disabling mailcap, but while we plan 
for better things I need to find a way to "fix" my boxes right now, and I can't 
think of another place to ask.

Bug#974870: libgdk-pixbuf2.0-dev: Plans for Xlib API deprecation

[Eduard Bloch]

Hallo,
* Simon McVittie [Sun, Nov 15 2020, 11:51:25PM]:

Thanks for the insights!

> However, it might be good to get the framework for this in place before
> the Debian 11 freeze, which would look like this:
>
> * source: gdk-pixbuf
>   - binary: libgdk-pixbuf-2.0-0
>   - binary: libgdk-pixbuf-2.0-dev
>   - binary: libgdk-pixbuf-xlib-2.0-0
>   - binary: libgdk-pixbuf-xlib-2.0-dev
>   - transitional binary: libgdk-pixbuf2.0-0
> + Depends: libgdk-pixbuf-2.0-0, libgdk-pixbuf-xlib-2.0-0
>   - transitional binary: libgdk-pixbuf2.0-dev
> + Depends: libgdk-pixbuf-2.0-dev, libgdk-pixbuf-xlib-2.0-dev
>
> (That'll require a trip through NEW, of course.)

Okay, sounds like a plan. I guess you will take the lead from here?
Feel free to use this bug report as anchor.

I cannot promise to have enough resources to support on that, though, I
only came along because an upstream project where I collaborate was
stormed by Gentoo users where deprecation process is apparently harsher.

> Then we can do a mass-bug-filing for packages that actively use the -xlib
> sub-library, and (perhaps later) a lower-severity mass-bug-filing for
> packages that build-depend on libgdk-pixbuf2.0-dev but should ideally
> only B-D on libgdk-pixbuf-2.0-dev.

XMAS time becoming a good candidate for a such rollout then?

> > maybe there should be even a warning of some kind printed
> > through pkg-config or GCC warnings (although this is bad, of course,
> > would break -Werror using packages).
>
> I don't *think* we can issue warnings from pkg-config, although there
> might be a mechanism available that I'm not aware of. Do you know of such
> a mechanism?

Not really, sorry. Looked around and couldn't find much useful. We could
invent some new hack here, like extension of FindPkgConfig.cmake (for
cmake users) but all that feels like an evil kludge.

> We can't issue compiler warnings and simultaneously not issue compiler
> warnings, we have to choose whichever is the lesser evil.

Yes. Too much warning is bad, not enough is equally bad.

> If packages in Debian are using -Werror for release builds, I personally
> think that's a packaging bug, because any new gcc release with better
> (or just different!) optimizations or diagnostics can start issuing new
> warnings that would break those packages; so I don't think it would be
> terrible to break them. It would probably be better to break them after
> the Debian 11 release so that people get an entire release cycle to fix
> them, though.

Agreed. Warnings from headers could be used as ultima ratio but only
THEN.

Best regards,
Eduard.

Bug#974944: mailman3-web won't allow single quote in postorius password

[peterc]

Package: mailman3-web
Version: 0+20180916-8
Severity: normal

Dear Maintainer,

I ran 
   dpkg-reconfigure mailman3-web
and created the Postorius superuser, using a password with a quotation mark
in it.
Instead of initialising the user, it threw a python exception:

I think the setup should sanitise its arguments a bit better.


Traceback (most recent call last):
  File "/usr/bin/django-admin", line 21, in 
management.execute_from_command_line()
  File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 364, in execute_from_command_line
utility.execute()
  File "/usr/lib/python3/dist-packages/django/core/management/__init__.py", 
line 356, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
283, in run_from_argv
self.execute(*args, **cmd_options)
  File "/usr/lib/python3/dist-packages/django/core/management/base.py", line 
330, in execute
output = self.handle(*args, **options)
  File 
"/usr/lib/python3/dist-packages/django/core/management/commands/shell.py", line 
95, in handle
exec(options['command'])
  File "", line 1
from django.contrib.auth.models import User;   
User.objects.filter(username='seL4').delete();   
User.objects.create_superuser('seL4',   'root@localhost', 'a dog's 
life')


^
SyntaxError: invalid syntax


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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3   2.0.11+deb10u1
ii  debconf [debconf-2.0]  1.5.71
ii  lsb-base   10.2019051400
ii  node-less  1.6.3~dfsg-3
ii  python33.7.3-1
ii  python3-django-hyperkitty  1.2.2-1
ii  python3-django-postorius   1.2.4-1
ii  python3-psycopg2   2.7.7-1
ii  python3-whoosh 2.7.4+git6-g9134ad92-4
ii  sassc  3.5.0-1
ii  ucf3.0038+nmu1
ii  uwsgi  2.0.18-1
ii  uwsgi-plugin-python3   2.0.18-1

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.4.38-3+deb10u4

Versions of packages mailman3-web suggests:
ii  postgresql  11+200+deb10u4

-- debconf information excluded

Bug#974943: lightdm-gtk-greeter 2.0.8-2 fails to start at boot

[Denis Dupeyron]

Package: lightdm-gtk-greeter
Version: 2.0.8-2
Severity: important
X-Debbugs-Cc: denis.dupey...@gmail.com

Dear Maintainer,

After updating from lightdm-gtk-greeter 2.0.8-1 to 2.0.8-2 lightdm fails to
start at boot.

journalctl -b -1 -u lightdm.service
-- Logs begin at Sun 2020-09-27 21:25:17 MDT, end at Mon 2020-11-16 13:52:50
MST. --
Nov 16 10:26:13 X1 systemd[1]: Starting Light Display Manager...
Nov 16 10:26:13 X1 systemd[1]: Started Light Display Manager.
Nov 16 10:26:13 X1 lightdm[461]: Error getting user list from
org.freedesktop.Accounts:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Accounts was not provided by any .service files
Nov 16 10:26:13 X1 systemd[1]: lightdm.service: Main process exited,
code=exited, status=1/FAILURE
Nov 16 10:26:13 X1 systemd[1]: lightdm.service: Failed with result 'exit-code'.
Nov 16 10:26:13 X1 systemd[1]: lightdm.service: Scheduled restart job, restart
counter is at 1.
Nov 16 10:26:13 X1 systemd[1]: Stopped Light Display Manager.
Nov 16 10:26:13 X1 systemd[1]: Starting Light Display Manager...
Nov 16 10:26:13 X1 systemd[1]: Started Light Display Manager.
Nov 16 10:26:14 X1 lightdm[534]: Error getting user list from
org.freedesktop.Accounts:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Accounts was not provided by any .service files
Nov 16 10:26:14 X1 systemd[1]: lightdm.service: Main process exited,
code=exited, status=1/FAILURE
Nov 16 10:26:14 X1 systemd[1]: lightdm.service: Failed with result 'exit-code'.
Nov 16 10:26:14 X1 systemd[1]: lightdm.service: Scheduled restart job, restart
counter is at 2.
Nov 16 10:26:14 X1 systemd[1]: Stopped Light Display Manager.
Nov 16 10:26:14 X1 systemd[1]: Starting Light Display Manager...
Nov 16 10:26:14 X1 systemd[1]: Started Light Display Manager.
Nov 16 10:26:14 X1 lightdm[556]: Error getting user list from
org.freedesktop.Accounts:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Accounts was not provided by any .service files
Nov 16 10:26:14 X1 systemd[1]: lightdm.service: Main process exited,
code=exited, status=1/FAILURE
Nov 16 10:26:14 X1 systemd[1]: lightdm.service: Failed with result 'exit-code'.
Nov 16 10:26:14 X1 systemd[1]: lightdm.service: Scheduled restart job, restart
counter is at 3.
Nov 16 10:26:14 X1 systemd[1]: Stopped Light Display Manager.
Nov 16 10:26:14 X1 systemd[1]: Starting Light Display Manager...
Nov 16 10:26:14 X1 systemd[1]: Started Light Display Manager.
Nov 16 10:26:14 X1 lightdm[563]: Error getting user list from
org.freedesktop.Accounts:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Accounts was not provided by any .service files
Nov 16 10:26:14 X1 systemd[1]: lightdm.service: Main process exited,
code=exited, status=1/FAILURE
Nov 16 10:26:14 X1 systemd[1]: lightdm.service: Failed with result 'exit-code'.
Nov 16 10:26:15 X1 systemd[1]: lightdm.service: Scheduled restart job, restart
counter is at 4.
Nov 16 10:26:15 X1 systemd[1]: Stopped Light Display Manager.
Nov 16 10:26:15 X1 systemd[1]: Starting Light Display Manager...
Nov 16 10:26:15 X1 systemd[1]: Started Light Display Manager.
Nov 16 10:26:15 X1 lightdm[571]: Error getting user list from
org.freedesktop.Accounts:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.freedesktop.Accounts was not provided by any .service files
Nov 16 10:26:15 X1 systemd[1]: lightdm.service: Main process exited,
code=exited, status=1/FAILURE
Nov 16 10:26:15 X1 systemd[1]: lightdm.service: Failed with result 'exit-code'.
Nov 16 10:26:15 X1 systemd[1]: lightdm.service: Scheduled restart job, restart
counter is at 5.
Nov 16 10:26:15 X1 systemd[1]: Stopped Light Display Manager.
Nov 16 10:26:15 X1 systemd[1]: lightdm.service: Start request repeated too
quickly.
Nov 16 10:26:15 X1 systemd[1]: lightdm.service: Failed with result 'exit-code'.
Nov 16 10:26:15 X1 systemd[1]: Failed to start Light Display Manager.
Nov 16 10:26:15 X1 systemd[1]: lightdm.service: Triggering OnFailure=
dependencies.
Nov 16 10:26:15 X1 systemd[1]: lightdm.service: Failed to enqueue OnFailure=
job, ignoring: Unit plymouth-quit.service not found.

cat /var/log/lightdm/lightdm.log.old
[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.26.0, UID=0 PID=548
[+0.00s] DEBUG: Loading configuration dirs from
/usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from
/usr/share/lightdm/lightdm.conf.d/01_debian.conf
[+0.00s] DEBUG: Loading configuration dirs from
/usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Registered seat module local
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: 

Bug#974942: git: parallel building of documentation causes missing content

[Vagrant Cascadian]

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

When the documentation is built in parallel, it can lead to missing
content in manpages and other documentation:

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

The attached patch to debian/rules works around this by disabling
parallel building of the documentation.

live well,
  vagrant
From 417fcff6c34188a1c5dfa49ae0e6bbb61baf3bff Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 16 Nov 2020 20:52:45 +
Subject: [PATCH] debian/rules: Disable parallel build for documentation.

Building the documentation in parallel can result in missing content
in manpages and other documentation files.
---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index aac0c2b14e..e213ee8ff8 100755
--- a/debian/rules
+++ b/debian/rules
@@ -82,9 +82,9 @@ override_dh_auto_test-arch:
 
 override_dh_auto_build-indep: build-stamp
 	# git-man, git-doc
-	$(MAKE) -CDocumentation man $(DOCS) $(DOC_OPTS)
+	$(MAKE) -CDocumentation man $(DOCS) $(DOC_OPTS) -j1
 	# git-mediawiki
-	$(MAKE) -Ccontrib/mw-to-git all $(OPTS)
+	$(MAKE) -Ccontrib/mw-to-git all $(OPTS) -j1
 
 override_dh_auto_test-indep:
 
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#960450: ocl-icd: add support for OpenCL 3.0

[Andreas Beckmann]

Followup-For: Bug #960450
Control: found -1 2.2.13-1

Hi,

there seems to be something missing, clinfo reports this:

[...]
ICD loader properties
  ICD loader Name OpenCL ICD Loader
  ICD loader Vendor   OCL Icd free software
  ICD loader Version  2.2.13
  ICD loader Profile  OpenCL 3.0
NOTE:   your OpenCL library declares to support OpenCL 3.0,
but it seems to support up to OpenCL 2.2 only.

Andreas

Bug#972334: severity

[Sebastian Ramacher]

On 2020-11-14 23:16:15 +0100, Sylvestre Ledru wrote:
> severity 972334 normal
> 
> thanks
> 
> Hello
> 
> As this isn't a new regression (it didn't work before), I am lowering the
> severity to allow migration.

Technically, it's a regression (it introduces a new failing test in
testing):

Issues preventing migration:
autopkgtest for dolfin/2019.2.0~git20200629.946dbd3-3: amd64: Pass, arm64: 
Pass, armhf: Ignored failure, i386: Pass, ppc64el: Pass
autopkgtest for llvm-toolchain-11/1:11.0.0-5: amd64: Pass, arm64: Pass, armhf: 
Test in progress, i386: Regression ♻ , ppc64el: Test in progress (will not be 
considered a regression)

to unblock postgresql-13 and the perl transtion, I've added a hint so that 
llvm-toolchain-11 for now.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#921624: kmail: Crash during/after filtering inbox, probably related to Qt WebEngine integration

[antony . coulson]

Hello,

Just to let you know, this is still happening.

My setup:
Operating System: Debian GNU/Linux 10
KDE Plasma Version: 5.14.5
Qt Version: 5.11.3
KDE Frameworks Version: 5.54.0
Kernel Version: 4.19.0-12-amd64
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6400 CPU @ 2.70GHz
Memory: 7.7 GiB of RAM

If you require any further information, please let me know.

Regards,
Antony


On Thu, 07 Feb 2019 13:08:17 +0100 Martin Steigerwald  
wrote:
> Package: kmail
> Version: 4:18.08.3-1
> Severity: important
> Tags: upstream
> 
> Dear Sandro,
> 
> Better late than never, I managed to report the KMail crashes during/after
> filtering inbox upstream. See:
> 
> Bug 404052 - Crash during/after filtering inbox, probably related to Qt 
WebEngine integration
> https://bugs.kde.org/404052
> 
> This may or may not be a packaging related issue.
> 
> Thanks,
> Martin
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (200, 
'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.0.0-rc4-tp520 (SMP w/4 CPU cores; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de 
(charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages kmail depends on:
> ii  akonadi-server   4:18.08.3-2
> ii  kdepim-runtime   4:18.08.3-1
> ii  kio  5.54.1-1
> ii  libc62.28-6
> ii  libgcc1  1:8.2.0-17
> ii  libgpgmepp6  1.12.0-6
> ii  libkf5akonadiagentbase5  4:18.08.3-2
> ii  libkf5akonadicontact54:18.08.3-1
> ii  libkf5akonadicore5abi2   4:18.08.3-2
> ii  libkf5akonadimime5   4:18.08.3-1
> ii  libkf5akonadisearch-bin  4:18.08.3-1
> ii  libkf5akonadisearch-plugins  4:18.08.3-1
> ii  libkf5akonadisearchdebug54:18.08.3-1
> ii  libkf5akonadisearchpim5  4:18.08.3-1
> ii  libkf5akonadiwidgets5abi14:18.08.3-2
> ii  libkf5bookmarks5 5.54.0-1
> ii  libkf5calendarcore5abi2  4:18.08.3-1
> ii  libkf5calendarutils5 4:18.08.3-1
> ii  libkf5codecs55.54.0-1
> ii  libkf5completion55.54.0-1
> ii  libkf5configcore55.54.0-1
> ii  libkf5configgui5 5.54.0-1
> ii  libkf5configwidgets5 5.54.0-1
> ii  libkf5contacts5  4:18.08.3-1
> ii  libkf5coreaddons55.54.0-1
> ii  libkf5crash5 5.54.0-1
> ii  libkf5dbusaddons55.54.0-1
> ii  libkf5followupreminder5  4:18.08.3-1

Bug#974899: libdatetime-timezone-perl: Inconsistent Olson versions within Timezone data

[NetValue Support]

Hi

We're seeing Bug#974899 too, a nightly report from a Stretch machine now 
includes over thirteen thousand lines of this:


Loaded DateTime::TimeZone::Pacific::Auckland, which is from a different version 
(2020d) of the Olson database than this installation of DateTime::TimeZone 
(2019c).


--
James Clark
NetValue Limited
Level 1, SouthBloc, 19 Knox Street, Hamilton
P 0800 876 321 |  W https://www.netvalue.nz/

Bug#974940: src:xserver-xorg-video-ati: fails to migrate to testing for too long: FTBFS on mips*el

[Paul Gevers]

Source: xserver-xorg-video-ati
Version: 1:19.1.0-1
Severity: serious
Control: close -1 1:19.1.0-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:xserver-xorg-video-ati in its current version in unstable has been
trying to migrate for 60 days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#974941: src:r-cran-tidyr: fails to migrate to testing for too long: Depends on r-cran-cpp11 which is not migrating

[Paul Gevers]

Source: r-cran-tidyr
Version: 1.1.0-1
Severity: serious
Control: close -1 1.1.2-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:r-cran-tidyr
in its current version in unstable has been trying to migrate for 60
days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#931597: transmission: Lift 1024 open files limit

[Moritz Mühlenhoff]

On Mon, Jul 08, 2019 at 08:32:15AM -0400, Sandro Tosi wrote:
> Thanks Vitaly,
> 
> On Mon, Jul 8, 2019 at 1:30 AM Vitaly Potyarkin  wrote:
> > I have submitted this patch upstream several months ago, but the upstream
> > development is rather slow and nobody reacted to my pull request yet. I 
> > suggest
> > adding this fix to the Transmission package in Debian because it is (a) 
> > simple
> > enough and (b) would make a lot of users happy.
> 
> still i would prefer for the upstream maintainers to chime in, before
> diverging in Debian.

Vitaly's patch got merged in 2da97b25fa43948fb24014535e880efed1a2fbdf.

I've smoketested a local build with that commit on top of 3.00-1 and it's
working fine for me (can't test with > 1024 torrents ATM, though). Not sure
if a new upstream release is planned before the freeze, but otherwise it
would be nice to cherrypick that into Bullseye :-)

Cheers,
Moritz

Bug#974737: transition: botan

[GCS]

On Sun, Nov 15, 2020 at 10:11 PM Sebastian Ramacher
 wrote:
> Control: tags -1 + confirmed
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-botan.html
>
> On 2020-11-14 13:37:03 +0100, László Böszörményi wrote:
> > Last botan 2.x release (botan version 3 is a new upstream project) is
> > in experimental. It would be good to have it for Bullseye. The only
> > one reverse dependency is Thunderbird which builds fine with this
> > version as well.
>
> Please go ahead
 Uploaded and it was built already.

Cheers,
Laszlo/GCS

Bug#974890: mp3gain: dies on startup, complaining of missing ASan runtime

[Stefan Fritsch]

Am 16.11.20 um 09:44 schrieb Salvatore Bonaccorso:

On Mon, Nov 16, 2020 at 04:14:30AM +0100, Adam Borowski wrote:

Package: mp3gain
Version: 1.6.2-1+b1
Severity: important

Trying to run mp3gain results in:
==23813==ASan runtime does not come first in initial library list;
you should either link runtime to your application or manually
preload it with LD_PRELOAD.


Interestingly, I don't get this message. Same version, also amd64. But I 
saw that message when running mp3gain under valgrind without the LD_PRELOAD.



And indeed, invoking it as:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.6 mp3gain -p -a *mp3
does the trick.


It looks that back in 2014 this was added to mitigate the stack
buffer overflows from #740268.

But as far I understand, compiling with ASAN was not recommended to be
in general used as hardening measure, there were reports back in 2016
as

https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html
https://www.openwall.com/lists/oss-security/2016/02/17/9

That said I do not know if that is still an issue as per today, but
raising this question on topic.


I noticed that too when filing #973932. Some other links said ASAN has 
both false positives and false negatives when used together with 
FORTIFY_SOURCE:


https://github.com/google/sanitizers/issues/247

I agree that mp3gain should disable ASAN when #973932 is fixed.

Bug#973100: prometheus-postfix-exporter: FTBFS: src/github.com/alecthomas/kingpin/i18n_init.go:13:2: cannot find package "github.com/nicksnyder/go-i18n/i18n" in any of:

[Martina Ferrari]

Hi Anthony et al,

Sorry for the very late response!!

On 29/10/2020 19:38, Anthony Fok wrote:

> Anyhow, I am working on fixing the current situation, and here is the plan:

This all looks good (I think you have already implemented it?), and
thank you very much for taking care of this!

-- 
Martina Ferrari (Tina)

Bug#974939: machine does not boot

[Toni]

Package: src:linux
Version: 4.19.152-1
Severity: critical


Hi,

with the two latest kernels, linux-image-4.19.0-12-amd64 and
linux-image-4.19.0-11-amd64, my machine does not boot, the reason being
that something with cryptsetup is amiss. I used to be asked for a
passphrase, but using these two kernels, I'm not, and the machine just
cycles trying to find the root partition. I am now running the -10
kernel again, which I would like to get off of. I've tried recovery mode
without any success.

On the console, after dmesg, these three lines repeat ad nauseum:

mdadm: No arrays found in config file or automatically
  Volume group "ev0" not found
  Cannot process volume group ev0
mdadm: No arrays found in config file or automatically
  Volume group "ev0" not found
  Cannot process volume group ev0


I think this bug is critical, since I can't get to anything with this
state of the machine.


The disk configuration is pretty straightforward:

git:(master*)$ lsblk 
NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
nvme0n1 259:00 953.9G  0 disk  
├─nvme0n1p1 259:10 238.4M  0 part  
├─nvme0n1p2 259:20   3.5G  0 part  
├─nvme0n1p3 259:30   953M  0 part  /boot
└─nvme0n1p4 259:40 949.2G  0 part  
  └─nvme0n1p4_crypt 253:00 949.2G  0 crypt 
├─ev0-swap  253:10  29.8G  0 lvm   [SWAP]
├─ev0-root  253:20 789.4G  0 lvm   /


There is one other (data) partition, but that's it for what the system
has.


Cheers,
Toni




-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Precision 5530
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: 1.13.0
board_vendor: Dell Inc.
board_name: 0X78C1
board_version: A02

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core Processor Host 
Bridge/DRAM Registers [8086:3ec4] (rev 07)
Subsystem: Dell 8th Gen Core Processor Host Bridge/DRAM Registers 
[1028:087d]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller (x16) 
[8086:1901] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 630 
(Mobile) [8086:3e9b] (prog-if 00 [VGA controller])
Subsystem: Dell UHD Graphics 630 (Mobile) [1028:087d]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Skylake 
Processor Thermal Subsystem [8086:1903] (rev 07)
Subsystem: Dell Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor 
Thermal Subsystem [1028:087d]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device

00:08.0 System peripheral [0880]: Intel Corporation Skylake Gaussian Mixture 
Model [8086:1911]
Subsystem: Dell Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core 
Processor Gaussian Mixture Model [1028:087d]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:12.0 Signal processing controller [1180]: Intel Corporation Cannon Lake PCH 
Thermal Controller [8086:a379] (rev 10)
Subsystem: Dell Cannon Lake PCH Thermal Controller [1028:087d]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: intel_pch_thermal
Kernel modules: intel_pch_thermal

00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH USB 3.1 xHCI 
Host Controller [8086:a36d] (rev 10) (prog-if 30 [XHCI])
Subsystem: Dell Cannon Lake PCH USB 3.1 xHCI Host Controller [1028:087d]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 

Bug#957470: FTBFS Bugs in Debian revdeps dahdi-tools and libpri

[Bernhard Schmidt]

Hi Tzafrir,
>>
>> could you have a look at Bug#957117 and #957470? They are causing
>> Asterisk to be removed from testing.
> 
> Uploaded a fix for dahdi-tools. As for libpri: this is basically using
> index from data[0] that is the end of the header.
> 
> My "fix" is to silence those checks (see patches). There hopefully seems
> to be some upstream work, but I'm not sure how long it would take.

Sorry to bug you again, but those bugs still affect unstable (libpri fix
was never uploaded and dahdi-tools FTBFS on armel/mipsel).

With the freeze upcoming I fear we have to remove dahdi support at some
time. Note that this would involve dropping the asterisk-dahdi binary
package, so a reintroduction would need a trip through NEW.

Bernhard

Bug#974938: gnupg: export-minimal very slow

[Kurt Roeckx]

Package: gnupg
Version: 2.2.20-1

Hi,

When I do gnupg --export, I get the result in 0.3 seconds.

If I do --export --export-options export-minimal, it takes 14
seconds.


Kurt

Bug#974937: evince: crashes then runs

[Nicolas Patrois]

Package: evince
Version: 3.38.0-2
Severity: normal

Dear Maintainer,

When I open a file in evince, evince crashes. I read this in the logs:
nov. 16 20:33:38 nicolas.home kernel: pool-evince[16278]: segfault at fdd4
ip 004de186 sp afbfa034 error 5 in evince[4cd000+3a000]
nov. 16 20:33:38 nicolas.home kernel: Code: 89 34 24 89 44 24 1c e8 b8 08 ff ff
8b 54 24 1c 89 14 24 50 6a 00 6a 00 56 e8 06 19 ff ff 83 c4 20 ff 77 08 ff 77
04 89 c6 50  75 14 e8 52 06 ff ff 89 34 24 e8 b2 3f ff ff 58 5a 6a 01 ff 74

Then, I can re-open evince and read the file without crash.

Yours,



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.7.0-1-686-pae (SMP w/3 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=fr_FR:fr:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  evince-common3.38.0-2
ii  gconf-gsettings-backend [gsettings-backend]  3.2.6-6
ii  gsettings-desktop-schemas3.38.0-2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-4
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libevdocument3-4 3.38.0-2
ii  libevview3-3 3.38.0-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libglib2.0-0 2.66.2-1
ii  libgnome-desktop-3-193.38.1-2
ii  libgtk-3-0   3.24.23-2
ii  libnautilus-extension1a  3.38.1-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libsecret-1-00.20.3-1
ii  shared-mime-info 2.0-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1

Versions of packages evince suggests:
ii  gvfs   1.46.1-1
ii  nautilus-sendto3.8.6-3
ii  poppler-data   0.4.10-1
ii  unrar-nonfree [unrar]  3.3.6-2

-- no debconf information

Bug#974172: libmutter-7-0: Cannot unlock screen with Wayland on arm64, keybard and mouse unresponsive

[Gali Drudis-Sole]

On Fri, Nov 13, 2020 at 1:54 PM Simon McVittie  wrote:

> Control: retitle -1 libmutter-7-0: Cannot unlock screen with Wayland on
> arm64, keybard and mouse unresponsive
>
> On Thu, 12 Nov 2020 at 00:20:03 +0100, Gali Drudis-Sole wrote:
> > On Wed, 11 Nov, 2020 at 10:32, Simon McVittie  wrote:
> > This works fine for me, and presumably other GNOME users, so there
> must be
> > something specific to your system that is relevant.
> >
> > Good. I hope to find it.
>
> One elephant in the room is that you're on an arm64 system, which is
> certainly unusual for a GNOME desktop. We've had a report on IRC that
> another arm64 user (with a different GPU) is seeing a similar bug.
>

Great. That looks like a good starting point.


> > Nov 11 23:04:29 mobian gsd-usb-protect[2319]: Error calling USBGuard
> DBus to
> > change the protection after a screensaver event:
> > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
> org.usbguard1
> > was not provided by any .service files
>
> This is not a problem and can safely be ignored.
>
> > Nov 11 23:04:29 mobian gnome-shell
> > [2141]: Bogus presentation time 0 travelled back in time, using current
> time.
>
> This might indicate a problem, I'm not sure.
>
> > Sorry, that was my error when reporting the bug. Version 3.38.0-2 DOES
> WORK,
> > but upgrading to the current testing version (3.38-1.2) DOES NOT WORK.
>
> Does 3.38.1-3 from experimental make any difference? That version has the
> latest changes from the upstream gnome-3-38 branch, which will be released
> in 3.38.2 at some point.
>

I've upgraded libmutter-7-0 and mutter-common to 3.38.1-3 from
experimental, but there was no difference. The screen can be unlocked if it
is not blanked, but it cannot be unlocked after blanking.


> If 3.38.1-3 doesn't solve this, since you've been able to narrow this
> down to two relatively close versions, it would be useful for someone
> with appropriate hardware (I don't have this) to do a `git bisect`
> between the good version and the bad version, to isolate which specific
> change made this regress - that would make it a lot more likely that
> someone can figure out the root cause.
>

I will give it a try.


>
> smcv
>


-- 
Galí Drudis Solé
  gal...@gmail.com

Bug#661193: Fékkstu skilaboðin mín?

[Elvis Edorh]

Bug#974936: cantata : scans directory outside of its configuration

[Erwan David]

Package: cantata
Version: 2.4.2.ds1-1
Severity: normal

For each automount point in /mnt, I get regularly

Nov 16 18:36:45 maine-ocean systemd[1]: mnt-nas.automount: Got automount 
request for /mnt/nas, triggered by 6664 (cantata)

It seems, that cantata scans every directory inside /mnt
My configuration does not mention /mnt, And I'd rather not have programs trigger
automounting like this.


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

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

Versions of packages cantata depends on:
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-2
ii  libavcodec58  10:4.3.1-dmo3
ii  libavformat58 10:4.3.1-dmo3
ii  libavutil56   10:4.3.1-dmo3
ii  libc6 2.31-4
ii  libcddb2  1.3.2-6+b1
ii  libcdparanoia03.10.2+debian-13+b1
ii  libebur128-1  1.2.4-2
ii  libgcc-s1 10.2.0-16
ii  libmpg123-0   1.26.3-1
ii  libmtp9   1.1.17-3
ii  libmusicbrainz5cc2v5  5.1.0+git20150707-10
ii  libqt5core5a  5.15.1+dfsg-2
ii  libqt5dbus5   5.15.1+dfsg-2
ii  libqt5gui55.15.1+dfsg-2
ii  libqt5multimedia5 5.15.1-2
ii  libqt5network55.15.1+dfsg-2
ii  libqt5sql55.15.1+dfsg-2
ii  libqt5sql5-sqlite 5.15.1+dfsg-2
ii  libqt5svg55.15.1-2
ii  libqt5widgets55.15.1+dfsg-2
ii  libqt5xml55.15.1+dfsg-2
ii  libstdc++610.2.0-16
ii  libtag1v5 1.11.1+dfsg.1-3
ii  libudev1  246.6-2
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages cantata recommends:
ii  liburi-perl   5.05-1
ii  perl-base [libio-socket-ip-perl]  5.30.3-4

Versions of packages cantata suggests:
ii  media-player-info  24-2
ii  mpd1:0.22.3-dmo1

-- no debconf information

Bug#974704: [pcp] Bug#974704: pcp: FTBFS on some archs: Cannot find (any matches for) "usr/lib/pcp/pmdas/infiniband[...]

[Dominic Hargreaves]

On Mon, Nov 16, 2020 at 04:49:07PM +1100, Nathan Scott wrote:
> Hi Dom,
> 
> On Sun, Nov 15, 2020 at 7:01 AM Dominic Hargreaves  wrote:
> >
> > On Sat, Nov 14, 2020 at 12:35:04AM +, Dominic Hargreaves wrote:
> > > This package FTBFS on the architectures which don't have bpftrace as a
> > > dependency since:
> >
> > ...
> >
> > Also, if you do do another upload, please can you do a source-only
> > upload or make sure that you build on an up-to-date sid (the upload
> > on Wednesday was built against perl 5.30 on amd64).
> 
> We always do source-only uploads, except in this case where we
> were explicitly requested by ftp-masters to do a binary upload as
> it introduced a new sub-package.

Ah, okay, that makes sense. I hadn't realised we had two conflicting
policies here... :(

> Thanks for the NMU, please feel free to reduce it from 4 days to
> less if that helps - I'll ensure a version of your patch gets included
> in the next upstream release.

Thanks! I'll reschedule that now.

(Please CC me in replies).

Best
Dominic

Bug#974888: growlight: Reproducibly segfaults on pressing F1

[Axel Beckert]

Hi Nick,

Nick Black wrote:
> i just wanted to say that this bug report is of the highest
> quality,

Actually, I'm not completely happy with its quality.

Despite seeing lines like

  [1]10878 segmentation fault (core dumped)  ./growlight

I fail to find those core dumps. :-(

They should be under /var/crash//, but those directories are
empty and I don't understand why.

I think this is also the reason why I only was able to get such a very
short gdb backtrace (from running growlight under gdb directly) in the
initial bug report.

> Axel, and i will study it closely as soon as i'm off work.

No hurry. I think it's an annyoing bug (as crashes are always), but so
far it doesn't seem to cause more than annoyance for the user. So I
don't consider it an urgent issue.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#974757: The "-no-frame" option no longer works with qemu-system-* in Debian 10.

[bakhelit]

Thanks for correcting my understanding of the "-no-frame" option 
situation. In that case feel free to close the bug. I will test the 
"-full-screen" option more and report the problems in a separate bug.


Regards
Bakhelit

Bug#974935: RFP: golang-github-ncabatoff-fakescraper -- scrape Prometheus metrics from inside the app

[Guillem Jover]

Package: wnpp
Severity: wishlist

* Package name: golang-github-ncabatoff-fakescraper
  Version : 0.0~git20201102.4b37ba6-1
  Upstream Author : Nick Cabatoff
* URL : https://github.com/ncabatoff/fakescraper
* License : https://github.com/ncabatoff/fakescraper/issues/2
  Programming Lang: Go
  Description : scrape Prometheus metrics from inside the app

 Intended when writing Prometheus exporters and wanting to test them
 from the command line. This avoids needing to start the daemon, run curl
 to fetch the metrics, then kill it.


This is a dependency for prometheus-process-exporter, which was previously
vendored and got unvendored upstream. I've got the packaging which I'll
provide as an MR once this bug has been filed.

The upstream repo has no license, and I've submitted an issue to get
that clarified, but that is not so different from the current situation
where that package is vendored and it does not contain an explicit
license anyway. Of course I don't expect this to be uploaded until that
issue has been resolved.

Thanks,
Guillem

Bug#974888: growlight: Reproducibly segfaults on pressing F1

[Nick Black]

i just wanted to say that this bug report is of the highest
quality, Axel, and i will study it closely as soon as i'm off
work. i'm disappointed that you're seeing these failures, but
i'm also confident that i can knock them down.

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.

Bug#974934: RFP: golang-github-ncabatoff-go-seq -- sequence Go values to allow sorting them

[Guillem Jover]

Package: wnpp
Severity: wishlist

* Package name: golang-github-ncabatoff-go-seq
  Version : 0.0~git20180805.b08ef85-1
  Upstream Author : Nick Cabatoff
* URL : https://github.com/ncabatoff/go-seq
* License : Expat
  Programming Lang: Go
  Description : sequence Go values to allow sorting them

 This package is intended to allow ordering (most) values via reflection,
 much like go-cmp allows comparing values for equality.
 .
 This is helpful when trying to write Less() methods for sorting
 structures.
 .
 Notable unsupported types include the builtin complex type, channels,
 functions, and maps with non-string keys. Pointers can be ordered if
 their underlying types can be ordered.


This is a dependency for prometheus-process-exporter, which was previously
vendored and got unvendored upstream. I've got the packaging which I'll
provide as an MR once this bug has been filed.

Thanks,
Guillem

Bug#974888: growlight: Reproducibly segfaults on pressing F1

[Axel Beckert]

Hi Nick,

Nick Black wrote:
> I believe this bug has been fixed, but am not certain. I was
> able to reproduce a crash pretty trivially, but it didn't have
> anything to do with pressing F1 (which I was able to do just
> fine, if growlight started correctly).

H. The readline rltty.c patch you sent me (and mentioned at the
end of your mail, sounded as if you found an issue elsewhere? But it
is unrelated?

> The root cause of the segfault I was running into was a /proc/mounts
> larger than a page, and a broken function for reading such files.
> The broken function left us with an empty mount map, which led to
> problems.

I'm quite sure I had not that issue. Mostly because I had tons of
block devices shown by growlight. Especially now that I have seen
https://github.com/dankamongmen/growlight/issues/103, I don't think I
had any of the output there, sorry. (Still on Kernel 5.7.10, btw.)

Nevertheless my /proc/mounts is not that small:

$ wc /proc/mounts
49 294 3730 /proc/mounts

But IIRC, a page is like 4k or so. So it's still below it, right?

> I've mapped F1 to 'H' so that it now toggles the Help screen.

Ok, so I tried Shift-H: And indeed, there is a help box. Yay!

(Would be great to put at least _that_ key binding in the man page,
maybe all shown by it. Would have helped me a lot and would also avoid
data loss by trying out keybindings as I see that some of them are
really dangerous to just try out. I hope I didn't do any damage to my
system.)

I'm not sure what all I did before and after displaying the help, but
I got it segfaulting again, but I got it segfaulting on exit by
pressing "q":

10814 renders, 5.29s total (138.86µs min, 21.41ms max, 489.17µs avg)
1.57MiB total (0.00B min, 589.12KiB max, 0.149KiB avg)
2044.3 theoretical FPS, 0 failed renders
RGB emits:elides: def 85490:60740 fg 87196:1773 bg 61:1782
 Elide rates: 41.54% 1.99% 96.69%
Cell emits:elides: 148073/88710387 (99.83%)
free(): double free detected in tcache 2
[1]22757 abort (core dumped)  growlight
growlight  21.05s user 0.10s system 8% cpu 3:57.44 total

I did at least the following, but nothing of that again caused it to
segfault, so I currently can't reproduce that crash:

* making the uxterm fullsize using my window manager (i3)
* then displaying the help window by pressing Shift-H
* then undoing fullsize again (the help window vanished)
* pressing H again (nothing happened)
* pressing H yet again (help window is there again)
* making the uxterm fullsize again (help window is about at middle
  height)
* undoing fullsize again
* maybe some more fullsizing again and undoing, don't remember.
* Pressing "q" for exiting.

> If you have the time and inclination, I'd be indebted were you
> to test from growlight head, and see if your problem is still
> there.

Did that.

> If you can't, that's perfectly understandable,

Well, yes and no. :-)

Yes, I can't reproduce the originally reported issue by pressing F1.
F1 now shows the help. Yes! Thanks!

Buut: The originally reported issue (crash by segfault) is still
there if I press another (unassigned) F-key like e.g. F2. Tried all
F-keys from F2 to F12 and it segfaults on all of those — after
checking the help that this won't damage my system. :-)

So this is probably a more generic issue.

> While I was there, I also fixed an issue that was causing
> growlight-readline to segfault out under certain scenarios, which
> led to a bug report + patch for libreadline (never thought I'd
> manage one of those).

Hehe.

> Thank you for this report, Axel, and your patience!

You're welcome!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#974588: [ovs-dev] Bug#974588: openvswitch: DPDK 20.11 support and transition for bullseye

[Ilya Maximets]

On 11/13/20 11:46 PM, Thomas Goirand wrote:
> On 11/13/20 6:54 PM, Ilya Maximets wrote:
>> On 11/13/20 1:47 PM, Thomas Goirand wrote:
>>> On 11/12/20 5:09 PM, Luca Boccassi wrote:
 Source: openvswitch
 Version: 2.13.0+dfsg1-12
 Severity: normal
 X-Debbugs-CC: pkg-dpdk-de...@lists.alioth.debian.org 
 christian.ehrha...@canonical.com
 Tags: bullseye

 Dear Openvswitch Maintainers,
>>
>> Hi, Luca and Thomas.
>>

 We are scoping the src:dpdk 19.11 -> 20.11 transition. If possible,
 we'd really like to go to bullseye with the latest upstream LTS, as
 19.11 is EOL at the end of next year.

 OVS support for DPDK 20.11 will be released upstream in v2.15, which is
 due for release on February 15 [1].
 Bullseye transition freeze is on January 12 [2], so the dates
 don't align very well.
>>
>> >From the upstream OVS perspective feature freeze usually happens on
>> January 15.  After this point only bug fixes (under normal conditions)
>> could be accepted.  Unfortunately, as it always happens, last few days
>> before the feature freeze might be hot in terms of accepting big number
>> of new features.  We could try adjusting these dates if January 12 is
>> a critical hard deadline, so the feature-list will be stable to the date.
>> Let me now if you need this kind of measures from the upstream OVS.
>> We can discuss.
>>

 So we are looking to formulate a plan that you can agree with, to sort
 this out.

 Based on experience, what Ubuntu usually does to meet release deadlines
 is to upload from git earlier than the release, so that all major
 incompatibilities can be sorted. And then after the freeze, once the
 release is officially out, do a final upgrade to the released version -
 since a similar enough version was uploaded from git, and at the end of
 a release cycle it's mostly bug fixes that land upstream, such an
 upload is acceptable.

 So we'd like to propose the following ideas:

 - between now and December: upload v2.14, to minimize the later jump
 - by the first week of January: upload 2.15~git from the tip of the
 master branch to experimental
 - stabilize and sort eventual build issues
 - upload dpdk 20.11 and ovs 2.15~git to unstable
 - upload 2.15 proper in February as a bug fix upload to unstable

 What do you think? Does this sound like a workable plan?

 We are of course happy to help - Ubuntu will go through the exact same
 process for 21.04, so a lot of the work is "shared".

 Thank you!
>>>
>>> Hi Luca,
>>>
>>> I wouldn't mind going for this kind of plan, however, I would really not
>>> like uploading a version which isn't final from the upstream point of
>>> view. So we would have to get the release team approve for a late upload
>>> of OVS 2.15. Note that I'm really not happy with the current state of
>>> OVS in Buster, which isn't usable right now (I've been using the tip of
>>> the git branch for 2.10.0 in production, not what's in Buster that often
>>> crashes). I don't want this to happen again.
>>>
>>> Please get the release team in the loop, therefore, and make them
>>> pre-approve such a plan, by opening a bug with them.
>>>
>>> Also, I would very much like to have OVS and OVN being packaged and
>>> maintained on both Ubuntu and Debian the same way. I would very much
>>> like if this could happen, because maintaining OVS is hard, and I really
>>> feel alone doing it. Your thoughts?
>>
>> I'm not very familiar with debian/ubuntu packaging process for OVS and OVN,
>> but if there is something that we can do from the upstream side to help, e.g.
>> by accepting some patches or streamlining release processes, let me know.
>> We clearly have a communication gap between upstream OVS and maintainers of
>> packages in distributions.
>>
>> Best regards, Ilya Maximets.
> 
> Hi Ilya,
> 
> Thanks for getting involved in the discussion.
> 
> What I'm worried, is if somehow, the latest OVS breaks OpenStack
> Victoria, which will be the OpenStack release for Bullseye. Can you
> assure me that it wont break it?

I don't think that we have any destructive/incompatible changes planned.
Also, IIRC, upstream OpenStack CI had a job to test with OVS master branch
(I need to recheck that).  So, I hope that we could catch issues early, if any.

Best regards, Ilya Maximets.

Bug#632785: Education & Career Fairs Kelowna 2020 Visitors Info List

[Lucy Diaz]

Hello
Hope you and your family are safe !!

Myself Lucy Diaz, Business Analyst of Inside data view.
We would like to follow-up with you for the below mentioned exhibition 
attendees' s database.


Expo details

Education & Career Fairs Kelowna
24 Nov 2020
Trinity Church, Kelowna, Canada
Visitors=3127

Data base contains:

  *   Contact Name
  *   Email Address
  *   Phone No
  *   Title, Company Name
  *   URL/Website
  *   City
  *   Country



We await your interest to obtain the above-mentioned database. Please feel free 
to write us and we can come up with an attractive price for you.

Kindly let us know your thoughts, so we can send you more information on same.

Best Regards,
Lucy Diaz
Business Analyst

Bug#974933: RM: testinfra -- ROM; renamed to pytest-testinfra

[Baptiste Beauplat]

Package: ftp.debian.org
Severity: normal

Please remove testinfra, renamed to pytest-testinfra.

Note: This package is only present in unstable and has no rdeps.

More info:
 Rename info: https://bugs.debian.org/973653
 Recent maintainer change: https://bugs.debian.org/971591

--
Baptiste Beauplat - lyknode




OpenPGP_signature
Description: OpenPGP digital signature

Bug#974852: [Pkg-netmeasure-discuss] Bug#974852: flent: should recommend iperf

[Toke Høiland-Jørgensen]

Jonas Smedegaard  writes:

> flent prefer the nonfree netperf as backend,
> but can use iperf for some of its tests.
>
> Please recommend iperf.

Unfortunately the iperf support is not anywhere close to being on par
with what we can do with netperf, due to missing features in iperf. So
not sure it'll help the users much to recommend iperf?

Bug#974931: Package gopls

[Shengjing Zhu]

Source: golang-golang-x-tools
Severity: wishlist
X-Debbugs-Cc: z...@debian.org

Hi,

I intent to package gopls, the Go language server.

Should it be a separate package, or add it to golang-golang-x-tools?
The golang-golang-x-tools package is already 186 MB, so I prefer adding a new
package. For normal users, the gopls is enough. Through the LSP(language server
protocol), it can format, refactor, fix import, auto-complete, etc.

Shengjing Zhu

Bug#974854: [Pkg-netmeasure-discuss] Bug#974854: flent: please relax to recommend (not depend on) python3-pyqt5

[Toke Høiland-Jørgensen]

Jonas Smedegaard  writes:

> flent provides both console and GUI tools in same project.
> The GUI tool is coded to fail gracefully if python3-pyqt5 is unavailable.
>
> Please relax to recommend (not depend on) python3-pyqt5,
> allowing installation on a headless system without pulling in ~400MB
> of unused packages.

Erm, the package already has python3-pyqt5 as a 'recommends'?

IIRC 'apt' will default to installing recommends, though, so you'll need
to use --no-install-recommends to avoid pulling those in...

Bug#931225: Please make Classic style the default

[Ian Jackson]

Hi.  I filed this bug about 18 months ago.  Guillem wrote

> [changing the defualt] This feels a bit too drastic,

and proposed

> I assume a MR for the CSS as proposed in the referenced bug might
> help move this, but I notice the theming is not included in the git
> repo at , and
> there's a MR about that already too, which would need to be solved
> first
> . :)

Thanks to Guillem for these illuminating comments.

Unfortunately, evidently no-one in the past year and a half has had
the effort and attention to fix our custom theme.  Working on the
custom theme is not a thing that I have the effort or inclination to
do.

If those who really dislike the Classic theme find it too ugly, then I
think it would be reasonable to expect those people to maintain that
theme.  That includes fixing serious defects in a reasonable time.

So I think the right decision would be to change the default theme to
Classic, until the bugs in the custom theme are fixed.

As I say, the formatting bugs in the current theme are very severe.

Sorry,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#974613: acme: wrong homepage + possible new version

[Gürkan Myczko]

> On Nov 16, 2020, at 18:00, Davide Prina  wrote:
> 
> Hi Gürkan,

Hi Davide

> 
> On 16/11/20 08:03, Gürkan Myczko wrote:
> 
>>> https://sourceforge.net/projects/acme-crossass/
> 
>>> I think also that there is a new version 0.97
>> Indeed, however were you able to download the source? I can only find a 
>> mac+windows release of that version.
> 
> I don't have notice that...
> 
> here there is the source
> https://sourceforge.net/p/acme-crossass/code-0/HEAD/tree/trunk/src/
> 
> but there is no tags/branches...
> 
> I think you must find the commit used for issuing the 0.97 version
> 
> but looking at the history you can understand what commit you must take
> https://sourceforge.net/p/acme-crossass/code-0/310/log/?path=/trunk
> 
> This file tell you the last version and the date
> https://sourceforge.net/p/acme-crossass/code-0/HEAD/tree/trunk/src/version.h#l12
> 
> so I think the commit is [r306]
> 

I think that will do:

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

> Ciao
> Davide

Bug#974136: FTBFS on non-x86

[kurt]

Hello Christian,

November 10, 2020 8:22 AM, "Christian Ehrhardt" 
 wrote:

> Package: netgen
> Version: 6.2.2006+dfsg-1
> 
> Hi,
> 
> I was seeing today that netgen is an FTBFS on all but x86.
> 
> I was tracking this down a bit and wanted to share the insight and links with 
> you.
> 

Thanks so much for looking into this, I've been stuck on it for quite some 
time. I tested adding the commit you linked in [6] as a patch, and it looks 
like that takes care of things, so I should have an upload ready soon.

Bug#974613: acme: wrong homepage + possible new version

[Davide Prina]

Hi Gürkan,

On 16/11/20 08:03, Gürkan Myczko wrote:


https://sourceforge.net/projects/acme-crossass/



I think also that there is a new version 0.97


Indeed, however were you able to download the source? I can only find a 
mac+windows release of that version.


I don't have notice that...

here there is the source
https://sourceforge.net/p/acme-crossass/code-0/HEAD/tree/trunk/src/

but there is no tags/branches...

I think you must find the commit used for issuing the 0.97 version

but looking at the history you can understand what commit you must take
https://sourceforge.net/p/acme-crossass/code-0/310/log/?path=/trunk

This file tell you the last version and the date
https://sourceforge.net/p/acme-crossass/code-0/HEAD/tree/trunk/src/version.h#l12

so I think the commit is [r306]

Ciao
Davide

Bug#972085: gtkam: Build-Depends on libexif-gtk, which is moving to GTK3

[Adrian Bunk]

On Mon, Oct 12, 2020 at 11:04:42PM +1100, Hugh McMaster wrote:
>...
> libexif-gtk is moving to GTK3 in response to #967573.
> 
> gtkman also only supports GTK2, which means it blocks the introduction of
> libexif-gtk built on GTK3.
>...

What is the point of moving libexif-gtk to GTK3 when the only package 
using it does not support it?

This sounds like a mistake that should be reverted.

> Thank you

cu
Adrian

Bug#937940: python-nemu: Python2 removal in sid/bullseye

[Martina Ferrari]

Thanks for the reminder, and sorry again for having these packages so
abandoned. I will give it a try before the freeze, and if not, I should
just remove them all.


On 31/08/2020 19:55, Moritz Mühlenhoff wrote:
> On Fri, Mar 27, 2020 at 11:57:00PM +0100, Moritz Mühlenhoff wrote:
>> On Fri, Aug 30, 2019 at 07:42:40AM +, Matthias Klose wrote:
>>> Package: src:python-nemu
>>> Version: 0.3.1-1
>>> Severity: normal
>>> Tags: sid bullseye
>>> User: debian-pyt...@lists.debian.org
>>> Usertags: py2removal
>>>
>>> Python2 becomes end-of-live upstream, and Debian aims to remove
>>> Python2 from the distribution, as discussed in
>>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>>
>> Hi Martina,
>> given that you're also the upstream of python-nemu, are you planning
>> to port it to Python 3 or should it be removed?
> 
> Gentle ping
> 
> Cheers,
> Moritz
>  
> 

-- 
Martina Ferrari (Tina)

Bug#974930: ITP: golang-mvdan-gofumpt -- A stricter gofmt

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-mvdan-gofumpt
  Version : 0.0~git20201107.a024667-1
  Upstream Author : Daniel Martí
* URL : https://github.com/mvdan/gofumpt
* License : BSD-3-clause
  Programming Lang: Go
  Description : A stricter gofmt

Enforce a stricter format than gofmt, while being backwards compatible.
That is, gofumpt is happy with a subset of the formats that gofmt is happy with.

The tool is a modified fork of gofmt, so it can be used as a drop-in 
replacement.

Dependency of gopls.

Bug#974929: ITP: golang-mvdan-xurls -- Extract urls from text

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-mvdan-xurls
  Version : 2.2.0-1
  Upstream Author : Daniel Martí
* URL : https://github.com/mvdan/xurls
* License : BSD-3-clause
  Programming Lang: Go
  Description : Extract urls from text

Extract urls from text using regular expressions.

Dependency of gopls.

Bug#974928: ITP: golang-github-thedevsaddam-gojsonq -- A simple Go package to Query over JSON/YAML/XML/CSV Data

[Martina Ferrari]

Package: wnpp
Severity: wishlist
Owner: Martina Ferrari 

* Package name: golang-github-thedevsaddam-gojsonq
  Version : 2.5.2-1
  Upstream Author : Saddam H
* URL : https://github.com/thedevsaddam/gojsonq
* License : Expat
  Programming Lang: Go
  Description : A simple Go package to query over JSON data (library)

 A simple Go package to query over JSON data. It provides a simple,
 elegant, and fast ODM-like API to access and query JSON documents.
 .
 It can also work with YAML, XML, and CSV documents if provided with a
 suitable decoder as explained in
 https://github.com/thedevsaddam/gojsonq/wiki/How-to-use-YAML,-XML,-CSV.

This package is a dependency for mqtt2prometheus.

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Niko Tyni]

On Fri, Nov 13, 2020 at 08:48:19PM +0100, Sven Joachim wrote:
> On 2020-11-13 18:23 +0100, Niels Thykier wrote:
> 
> > Control: reassign -1 perl-base
> > Control: affects -1 upgrade-reports
> > Control: severity -1 grave
> >
> > Hi Perl team,
> >
> > I have reassigned this bug to perl because perl-base being essential
> > must remain functional during an upgrade and AFAICT perl-base fails in
> > this case here.
> >
> > If it is a direct linkage, then you might be needing a Pre-Depends.  If
> > it is an indirect linkage then I am not sure how to fix it. :-/
> 
> I don't think perl-base is doing anything wrong here, it already uses
> Pre-Depends.  AFAICS the problem is that libcrypt.so.1 can temporarily
> go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the
> assumption that binaries from essential packages are always usable.

Indeed. As perl-base isn't upgraded yet at that point, there's nothing
we can do on that side.

Apparently the new libc6 is still considered to satisfy the old perl-base
pre-dependency even when it (libc6) is only unpacked and its dependencies
are not yet satisfied. This seems similar to this paragraph from Debian
policy, section 7.2:

When a package declaring a pre-dependency is about to be unpacked
the pre-dependency can be satisfied if the depended-on package
is either fully configured, or even if the depended-on package(s)
are only in the “Unpacked” or the “Half-Configured” state,
provided that they have been configured correctly at some point
in the past (and not removed or partially removed since). In this
case, both the previously-configured and currently “Unpacked”
or “Half-Configured” versions must satisfy any version clause
in the Pre-Depends field.

The libc6 package has been configured correctly in the past, when
it still contained libcrypt1.

As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1
for one release cycle, so that libc6 cannot be unpacked before libcrypt1
is fully installed.

Another option might be to have the new libc6 Conflict with old versions
of Essential:yes packages that need libcrypt1, forcing those Essential:yes
packages to get upgraded first. A quick check based on libcrypt1 reverse
dependencies in sid shows perl-base, login and util-linux. I'm not sure
if this list is exhaustive, though.

The first option looks less intrusive to me.

Disclaimer: I haven't tested any of this :)
-- 
Niko Tyni   nt...@debian.org

Bug#974927: ITP: tinyexr -- C++ library to load and save OpenEXR images

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org, t...@gaussglocke.de

* Package name: tinyexr
  Version : 1.0.0
  Upstream Author : Syoyo Fujita
* URL : https://github.com/syoyo/tinyexr
* License : BSD-3-Clause
  Programming Lang: C++
  Description : C++ library to load and save OpenEXR images

TinyEXR is a small library to load and save OpenEXR images. It supports
the version 1 format and version 2 multi-part images, and it has partial
support for version 2 deep images.

TinyEXR is a dependency for Filament (bug #974734), and it is also
embedded in a few other packages (renderdoc, mame, godot, goxel, love),
which indicates that it should be packaged properly.

Bug#974903: dgit: add a generic way to update a package to a new upstream version

[Ian Jackson]

Hi.

Félix Sipma writes ("Bug#974903: dgit: add a generic way to update a package to 
a new upstream version"):
> When I work on other (teams) packages, it is, most of the time, because 
> I need a lib to be updated to a new version to be able to update 
> another package.
> 
> It would be great to have a simple generic way to update a package cloned 
> with "dgit clone".

Yes.

>[ many runes elided ]

I'm afraid I see problem with your approach: it makes a large number
of assumptions about the way the package git repository is managed,
and what workflow the team uses.  The workflow and git branch
structure you are relying on is common but by no means universal.

Unfortunately I don't think it is possible to do the right thing in
the completely general case.  It may, however, be possible to
recognise this common structurem and work with it.[1]

I'm kind of hesitant to do this in /usr/bin/dgit.  It's rather outside
dgit's existing competences and I wouldn't like to add a lot of
assumptions to dgit.

I think this would perhaps be best done as a separate script.  Perhaps
it could live in devscripts, but I would be very happy to host it in
src:dgit.

Hosting it in src:dgit would allow/require you to fit its test cases
into the existing dgit test framework (which might be a boon or a
bastard, depending on your point of view).

You might also want to check out
  https://wiki.debian.org/GitPackagingSurvey
(see the note about formatting - you will want to log into the wiki
and set your theme to Classic).

Realistically I'm afraid I'm not likely to have effort myself to work
on this idea of yours, but I'm happy to advise, review, enable etc.
Beware of getting too enthusiastic or you may find I invite you to be
a co-maintainer :-).

Regards,
Ian.

[1] Thsi would have been much easier to do automatically if my
tag2upload scheme had not been blocked by ftpmaster.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#791362: perl: build timezone affects LOCALTIME_{MIN,MAX}

[Niko Tyni]

Control: submitter -1 !
Control: severity -1 minor
Control: tag -1 upstream

On Sat, Nov 14, 2020 at 05:27:26PM +, Dominic Hargreaves wrote:

> I'm struggling to see the practical problem with having the timezone
> vary LOCALTIME_{MIN,MAX} (other than reproducibility, which AIUI has
> already been addressed).

I'm not aware of any practical problems here. I suspect nothing
uses $Config{sLOCALTIME_max} et al.

Reproducibility has been addressed in a Debian-specific way.  Ideally,
it would be fixed upstream so that the build result would be reproducible
regardless of the build timezone (which we are currently overriding.)

> I don't agree with the starting point that
> an environment variable shouldn't be able to influence the contents
> of the binary (this is clearly a very common and necessary pattern).

I think it depends on the environment variable and its main purpose.
Something like BUILD_BZIP2 does and should influence the result, that's
what it's there for. But what's the use for encoding the local timezone
into the binaries? Binaries can be copied between hosts in different time
zones (our buildd results certainly are), users connect to hosts from
different time zones, and even hosts (think laptops) can move between
time zones.

I don't really mind closing this, it's just a minor detail and I obviously
haven't got around to doing anything about it so far. But I do think
the current TZ=UTC solution is more a workaround than a fix.

I'm updating the metadata at least, feel free to close if you're not
convinced :)
-- 
Niko

Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Limonciello, Mario]

> -Original Message-
> From: Matteo Settenvini  On Behalf Of Matteo Settenvini
> Sent: Saturday, November 14, 2020 7:35
> To: 973...@bugs.debian.org
> Subject: Bug#973715: fwupd-amd64-signed holding off fwupd update results in
> segfaulting binary
> 
> The problem suddenly become worse.
> 
> Now that fwupd 1.5.1 has landed in sid, and some dependencies
> apparently changed, the fwupd-amd64-signed package holding off fwupd
> upgrade and forcing it to stay at version 1.4.6-2, is breaking the
> system:
> 
> nov 14 14:29:52 rosebud kernel: fwupd[11192]: segfault at 8 ip
> 56035dbcc548 sp 7ffddfa64b00 error 4 in
> fwupd[56035dbaf000+2]
> nov 14 14:29:52 rosebud kernel: Code: c7 44 24 08 00 00 00 00 66 2e 0f
> 1f 84 00 00 00 00 00 48 8b 11 8b 44 24 10 be 01 00 00 00 4c 8b 34 c2>
> nov 14 14:29:52 rosebud systemd[1]: fwupd.service: Main process exited,
> code=killed, status=11/SEGV
> 
> This goes away after uninstalling the fwupd-amd64-signed package and
> installing fwupd 1.5.1, but of course on a system with SecureBoot
> enabled, this is not helping much if you have pending BIOS updates.
> 
> Cheers,
> Matteo

1.5.1-1 won't migrate to testing as other issues came up with non-x86
architectures.  I've uploaded a 1.5.1-2 this morning that should hopefully
sort those out.

As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
It needs to be done when 1.5.1-2 is ready to migrate.  If there is another
problem that comes up (say autopkgtest fails, or some other arch still fails)
then we'll probably need to do a 1.5.1-3 and then kick it off.

Bug#974926: cacti zoom bug

[Matus UHLAR - fantomas]

Package: cacti
Version: 0.8.8h+ds1-10+deb9u1

when trying to zoom a graph, bug in cacti causes it to ignore zoom because
of timestamp too high.

the original cacti ignores timestamp bigger than 16, however we've
been there already:

% date -d @16
Sun Sep 13 14:26:40 CEST 2020

cacti bug explained:

https://github.com/Cacti/cacti/issues/3797

attaching patch for cacti 0.8.8h in stretch


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
(R)etry, (A)bort, (C)ancer
--- /usr/share/cacti/site/graph_image.php.orig	2013-08-07 04:31:19.0 +0200
+++ /usr/share/cacti/site/graph_image.php	2020-09-30 15:58:57.439931128 +0200
@@ -60,12 +60,12 @@
 $graph_data_array = array();
 
 /* override: graph start time (unix time) */
-if (!empty($_GET["graph_start"]) && $_GET["graph_start"] < 16) {
+if (!empty($_GET["graph_start"]) && $_GET["graph_start"] < 26) {
 	$graph_data_array["graph_start"] = $_GET["graph_start"];
 }
 
 /* override: graph end time (unix time) */
-if (!empty($_GET["graph_end"]) && $_GET["graph_end"] < 16) {
+if (!empty($_GET["graph_end"]) && $_GET["graph_end"] < 26) {
 	$graph_data_array["graph_end"] = $_GET["graph_end"];
 }
 
--- /usr/share/cacti/site/graph_xport.php.orig	2018-10-23 09:32:19.407796822 +0200
+++ /usr/share/cacti/site/graph_xport.php	2020-10-23 09:32:55.536128501 +0200
@@ -53,12 +53,12 @@
 /*  */
 
 /* override: graph start time (unix time) */
-if (!empty($_GET["graph_start"]) && is_numeric($_GET["graph_start"]) && $_GET["graph_start"] < 16) {
+if (!empty($_GET["graph_start"]) && is_numeric($_GET["graph_start"]) && $_GET["graph_start"] < 26) {
 	$graph_data_array["graph_start"] = get_request_var("graph_start");
 }
 
 /* override: graph end time (unix time) */
-if (!empty($_GET["graph_end"]) && is_numeric($_GET["graph_end"]) && $_GET["graph_end"] < 16) {
+if (!empty($_GET["graph_end"]) && is_numeric($_GET["graph_end"]) && $_GET["graph_end"] < 26) {
 	$graph_data_array["graph_end"] = get_request_var("graph_end");
 }
 

Bug#974899: libdatetime-timezone-perl: Inconsistent Olson versions within Timezone data

[gregor herrmann]

On Mon, 16 Nov 2020 09:35:02 +, Ben Smithurst wrote:

> Package: libdatetime-timezone-perl
> Version: 1:2.09-1+2020d
> Severity: important
> 
> Dear Maintainer,
> 
> There seems to be an internally inconsistency in this package in that
> the Olson versions defined in timezones are inconsistent:
> 
> % dpkg -L libdatetime-timezone-perl | xargs grep olson_version 2>/dev/null | 
> cut -d' ' -f3 | sort | uniq -c
>   2
> 175 {'2019c'}
> 185 {'2020d'}
> 
> This leads to warnings appearing:
> 
> Loaded DateTime::TimeZone::Europe::London, which is from a different version 
> (2020d) of the Olson database than this installation of DateTime::TimeZone 
> (2019c).

Hi Ben,

thanks for your bug report!

The version of libdatetime-timezone-perl this bug is reported against
(in stretch(-security)) is not maintained by the package maintainers
but by the LTS team. I'm cc'ing their list and the uploader of
1:2.09-1+2020d.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Supertramp: My Kind Of Lady


signature.asc
Description: Digital Signature

Bug#974925: actor-framework: Please provide a backport for buster

[Sascha Steinbiss]

Source: actor-framework
Severity: wishlist

Dear Maintainer,

in order to build VAST 
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970505)
for buster, I would like to request a backport of version 0.17.6. If you
are not interested in doing it, I'd also be happy to upload such a
backport. Just asking before... :)

Cheers
Sascha