Bug#968427: Variables declared without extern in cairo_ocaml.h cause FTBFS

[Stéphane Glondu]

Source: libcairo2-ocaml-dev
Severity: serious
Tags: ftbfs
Control: affects -1 why3 lablgtk3

Dear Maintainer,

/usr/lib/ocaml/cairo2/cairo_ocaml.h declares variables without extern,
causing multiple definitions if this file is included in multiple .c
files, which is an error with gcc-10. This causes lablgtk3 (which
includes cairo_ocaml.h) to have multiple definitions, which in turn
causes why3 to FTBFS.

Cheers,

-- 
Stéphane


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

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

Bug#968426: ITP: tensorpipe -- A tensor-aware point-to-point communication primitive for machine learning

[Mo Zhou]

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

* Package name: tensorpipe
  Upstream Author : pytorch developers
* URL : https://github.com/pytorch/tensorpipe
* License : BSD
  Programming Lang: C++
  Description : A tensor-aware point-to-point communication primitive for 
machine learning

New PyTorch dependency. required by pytorch 1.6.0

Bug#961300: New upstream available

[Evgeni Golov]

Hi,

sorry I somehow forgot to answer this mail. Migrating to Salsa and giving you 
access so you can update and upload seems like a good idea, especially as I am 
currently not using thinkfan myself. Will do so in the next few days and ping 
you!

Thanks
Evgeni

On May 22, 2020 9:45:39 PM UTC, Lee Garrett  wrote:
>Package: thinkfan
>Version: 0.9.3-2
>Severity: wishlist
>
>Hi Evgeni,
>
>upstream has released 1.1 of thinkfan last month, and it would be great to
>package it for Debian, as it fixes the issue of changing hwmon names between
>reboots.
>
>I'm currently fixing up the package myself, so if you migrate the git repo to
>salsa I could send a PR your way. Let me know if you're interested.
>
>Greets,
>Lee
>
>-- System Information:
>Debian Release: bullseye/sid
>  APT prefers testing
>  APT policy: (990, 'testing'), (500, 'unstable')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.6.14 (SMP w/8 CPU cores; PREEMPT)
>Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
>LANGUAGE=en_US:en (charmap=UTF-8)
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>LSM: AppArmor: enabled
>
>Versions of packages thinkfan depends on:
>ii  init-system-helpers  1.57
>ii  libatasmart4 0.19-5
>ii  libc62.30-8
>
>thinkfan recommends no packages.
>
>thinkfan suggests no packages.
>
>-- Configuration Files:
>/etc/thinkfan.conf changed [not included]
>
>-- no debconf information

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Bug#961584: lxc-stop fails with exit code 1

[Harald Dunkel]

PS, just to be sure: You do have mounted cgroupv2 on the Docker
host and in the Docker container?

Bug#968425: mount cgroupv2 by default, similar to systemd

[Harald Dunkel]

Package: initscripts
Version: 2.96-4
Severity: wishlist

To reduce friction between systemd and "non-systemd" systems I
would suggest to mount croupv2 very early at boot time, similar
to systemd.

Could be added next to /proc and /sys in mountkernfs.sh.


Background of this story is: systemd uses cgroupv2 by default,
if possible. Running in a container this has weird side effects,
if the host hasn't properly initialized cgroupv1 or cgroupv2. See

https://github.com/lxc/lxc/issues/3520

for example. Best way out of this (IMHO) is to make cgroupv2 the
default.

Of course I can add a line to /etc/fstab (as I can do for /proc and
/sys), but this approach is error-prone.


Regards
Harri

Bug#968262: lintian: spare-manual-page misses .so targets

[Ross Vandegrift]

On Wed, Aug 12, 2020 at 07:45:22PM -0700, Felix Lechner wrote:
> On Wed, Aug 12, 2020 at 7:17 PM Ross Vandegrift  
> wrote:
> >
> > Is that unusual or incorrect?'.
> 
> I cannot answer that. From Lintian's perspective, there is no
> executable for the manual page, and that is how the tag works.

I see.  It might be nice if the tag said "lintian cannot confirm this page is
useful, since there's no binary with the same name.  If no links point to it,
it should probably be removed." But if I'm the only one to run into this this,
it's not worth the change.  I'll ignore or override.

> As a side note, I am not sure how helpful terminology-helpers.1 is.
> Why don't you just link to the main manual page terminology.1 and add
> a section about the helpers there?

I agree it's thin.  I'd rather not combine it with terminology.1 - as a user, I
often find combined manpages difficult to navigate.  But I agree more details
would be good.

> Hope this was helpful.

Very, and thanks for the feedback!

Ross

Bug#968424: Makefile.flext hard codes the build architecture pkg-config

[Helmut Grohne]

Package: pd-flext-dev
Version: 0.6.1-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:pd-xsample

pd-xsample fails to cross build from source, because it uses the build
architecture pkg-config. It does so via using Makefile.flext, where it
is hard coded. Please make pkg-config substitutable. I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru pd-flext-0.6.1/debian/Makefile.flext 
pd-flext-0.6.1/debian/Makefile.flext
--- pd-flext-0.6.1/debian/Makefile.flext2020-03-25 10:11:51.0 
+0100
+++ pd-flext-0.6.1/debian/Makefile.flext2020-08-15 06:52:02.0 
+0200
@@ -32,14 +32,15 @@
 endif
 
 SRCDIR ?= .
+PKG_CONFIG ?= pkg-config
 
 lib.name = $(NAME)
 
 $(NAME).class.sources = $(addprefix $(SRCDIR)/, $(SRCS))
 
-cflags += $(INCPATH) $(DEFS) $(shell pkg-config --cflags pd-flext) $(UFLAGS)
+cflags += $(INCPATH) $(DEFS) $(shell $(PKG_CONFIG) --cflags pd-flext) $(UFLAGS)
 ldflags += $(LIBPATH)
-ldlibs += $(shell pkg-config --libs pd-flext) $(LIBS)
+ldlibs += $(shell $(PKG_CONFIG) --libs pd-flext) $(LIBS)
 
 ifeq (,$(findstring debug,$(MAKECMDGOALS)))
 cflags += $(OFLAGS)
diff --minimal -Nru pd-flext-0.6.1/debian/README.Debian 
pd-flext-0.6.1/debian/README.Debian
--- pd-flext-0.6.1/debian/README.Debian 2020-03-25 10:11:51.0 +0100
+++ pd-flext-0.6.1/debian/README.Debian 2020-08-15 06:52:02.0 +0200
@@ -14,4 +14,8 @@
 
 This requires the pd-lib-builder package to be installed.
 
+In a Debian package build, you should invoke make via dh_auto_build:
+
+dh_auto_build --buildsystem=makefile -- -f 
/usr/share/pd-flext/dev/Makefile.flext
+
  -- IOhannes m zmölnig (Debian/GNU)   Tue, 01 Nov 2016 
23:49:16 +0100
diff --minimal -Nru pd-flext-0.6.1/debian/changelog 
pd-flext-0.6.1/debian/changelog
--- pd-flext-0.6.1/debian/changelog 2020-03-25 10:11:51.0 +0100
+++ pd-flext-0.6.1/debian/changelog 2020-08-15 06:52:02.0 +0200
@@ -1,3 +1,10 @@
+pd-flext (0.6.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Make pkg-config substitutable in Makefile.flext. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 15 Aug 2020 06:52:02 +0200
+
 pd-flext (0.6.1-1) unstable; urgency=medium
 
   * New upstream version 0.6.1

Bug#968422: xjdic FTCBFS: hard codes the build architecture compiler

[Helmut Grohne]

Source: xjdic
Version: 24-11
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xjdic fails to cross build from source, because debian/rules hard codes
the build architecture compiler as gcc. Please use a cross compiler when
appropriate. A simple way to do so is letting dpkg's buildtools.mk
initialize $(CC). I'm attaching a patch for your convenience.

Helmut
diff -u xjdic-24/debian/changelog xjdic-24/debian/changelog
--- xjdic-24/debian/changelog
+++ xjdic-24/debian/changelog
@@ -1,3 +1,10 @@
+xjdic (24-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk supply a C compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 15 Aug 2020 06:31:17 +0200
+
 xjdic (24-11) unstable; urgency=medium
 
   * Thanks to Frederic Briere for all the following patches
diff -u xjdic-24/debian/rules xjdic-24/debian/rules
--- xjdic-24/debian/rules
+++ xjdic-24/debian/rules
@@ -5,6 +5,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+-include /usr/share/dpkg/buildtools.mk
 CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
@@ -41,7 +42,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) CC="gcc $(CPPFLAGS) $(CFLAGS) $(LDFLAGS)"
+   $(MAKE) CC="$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS)"
#/usr/bin/docbook-to-man debian/test-s.sgml > test-s.1
cp -f xjdic24.inf xjdic24.txt
touch build-stamp

Bug#968423: utalk FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: utalk
Version: 1.0.1.beta-8.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

utalk fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
utalk cross buildable. Please consider applying the attached patch.

Helmut
diff -u utalk-1.0.1.beta/debian/changelog utalk-1.0.1.beta/debian/changelog
--- utalk-1.0.1.beta/debian/changelog
+++ utalk-1.0.1.beta/debian/changelog
@@ -1,3 +1,10 @@
+utalk (1.0.1.beta-8.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 15 Aug 2020 06:34:36 +0200
+
 utalk (1.0.1.beta-8.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u utalk-1.0.1.beta/debian/rules utalk-1.0.1.beta/debian/rules
--- utalk-1.0.1.beta/debian/rules
+++ utalk-1.0.1.beta/debian/rules
@@ -12,8 +12,7 @@
 build-indep: build-stamp
 build-stamp:
dh_testdir
-   # Add here commands to compile the package.
-   $(MAKE)
+   dh_auto_build
touch build-stamp
 
 clean:

Bug#968421: sane-airscan FTCBFS: build architecture build tools

[Helmut Grohne]

Source: sane-airscan
Version: 0.99.13-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

sane-airscan fails to cross build from source for two reasons.

The first is using the build architecture pkg-config. The upstream
Makefile hard codes the build architecture pkg-config despite setting up
the standard PKG_CONFIG variable. All it needs to do here is use the
variable to pick up the correct pkg-config passed by dh_auto_build.

It also passes -s to install, which causes the build architecture strip
to be invoked. Beyond breaking cross compilation, this breaks generation
of -dbgsym packages and DEB_BUILD_OPTIONS=nostrip. It is best practice
to defer all stripping to dh_strip, which does the right thing. While
the upstream build system supports a way of avoiding that (passing an
empty STRIP variable), it would be nice if it would also support the
standard debhelper way. dh_auto_install passes an INSTALL that never
strips (even if requested via -s). Alternatively, adding an
override_dh_auto_install passing STRIP= to would also do.

Please consider applying the attached patch to fix all mentioned issues.

Helmut
--- sane-airscan-0.99.13.orig/Makefile
+++ sane-airscan-0.99.13/Makefile
@@ -21,6 +21,7 @@
 MANDIR	= /usr/share/man/
 PKG_CONFIG = /usr/bin/pkg-config
 STRIP 	= -s
+INSTALL = install
 
 # These variables are not intended to be user-settable
 OBJDIR  = objs/
@@ -42,11 +43,11 @@
 OBJ	= $(addprefix $(OBJDIR), $(SRC:.c=.o))
 
 # Obtain CFLAGS and LDFLAGS for dependencies
-deps_CFLAGS		:= $(foreach lib, $(DEPS_COMMON), $(shell pkg-config --cflags $(lib)))
-deps_CFLAGS		+= $(foreach lib, $(DEPS_CODECS), $(shell pkg-config --cflags $(lib)))
+deps_CFLAGS		:= $(foreach lib, $(DEPS_COMMON), $(shell $(PKG_CONFIG) --cflags $(lib)))
+deps_CFLAGS		+= $(foreach lib, $(DEPS_CODECS), $(shell $(PKG_CONFIG) --cflags $(lib)))
 
-deps_LIBS 		:= $(foreach lib, $(DEPS_COMMON), $(shell pkg-config --libs $(lib))) -lm
-deps_LIBS_CODECS 	:= $(foreach lib, $(DEPS_CODECS), $(shell pkg-config --libs $(lib)))
+deps_LIBS 		:= $(foreach lib, $(DEPS_COMMON), $(shell $(PKG_CONFIG) --libs $(lib))) -lm
+deps_LIBS_CODECS 	:= $(foreach lib, $(DEPS_CODECS), $(shell $(PKG_CONFIG) --libs $(lib)))
 
 # Compute CFLAGS and LDFLAGS for backend and tools
 #
@@ -89,13 +90,13 @@
 	mkdir -p $(DESTDIR)$(PREFIX)$(BINDIR)
 	mkdir -p $(DESTDIR)$(PREFIX)$(CONFDIR)
 	mkdir -p $(DESTDIR)$(PREFIX)$(CONFDIR)/dll.d
-	install $(STRIP) -D -t $(DESTDIR)$(PREFIX)$(BINDIR) $(DISCOVER)
+	$(INSTALL) $(STRIP) -D -t $(DESTDIR)$(PREFIX)$(BINDIR) $(DISCOVER)
 	cp -n airscan.conf $(DESTDIR)$(PREFIX)$(CONFDIR)
 	cp -n dll.conf $(DESTDIR)$(PREFIX)$(CONFDIR)/dll.d/airscan
-	install $(STRIP) -D -t $(DESTDIR)$(PREFIX)$(LIBDIR)/sane $(BACKEND)
+	$(INSTALL) $(STRIP) -D -t $(DESTDIR)$(PREFIX)$(LIBDIR)/sane $(BACKEND)
 	mkdir -p $(DESTDIR)$(PREFIX)/$(MANDIR)/man5
-	install -m 644 -D -t $(DESTDIR)$(PREFIX)$(MANDIR)/man1 $(MAN_DISCOVER)
-	install -m 644 -D -t $(DESTDIR)$(PREFIX)$(MANDIR)/man5 $(MAN_BACKEND)
+	$(INSTALL) -m 644 -D -t $(DESTDIR)$(PREFIX)$(MANDIR)/man1 $(MAN_DISCOVER)
+	$(INSTALL) -m 644 -D -t $(DESTDIR)$(PREFIX)$(MANDIR)/man5 $(MAN_BACKEND)
 	[ "$(COMPRESS)" = "" ] || $(COMPRESS) -f $(DESTDIR)$(PREFIX)$(MANDIR)/man1/$(MAN_DISCOVER)
 	[ "$(COMPRESS)" = "" ] || $(COMPRESS) -f $(DESTDIR)$(PREFIX)$(MANDIR)/man5/$(MAN_BACKEND)
 

Bug#968420: ruby-bunny: FTBFS due to faulty testcase

[Sergio Durigan Junior]

Source: ruby-bunny
Version: 2.14.4-3
Severity: serious
Tags: ftbfs sid

I've just noticed that ruby-bunny FTBFS when building using a pristine
schroot on sbuild:

--8<---cut here---start->8---
Waiting for pid file '/tmp/d20200814-17660-k3x0b6/mnesia/bunny.pid' to appear

  ##  ##  RabbitMQ 3.8.5
  ##  ##
  ##  Copyright (c) 2007-2020 VMware, Inc. or its affiliates.
  ##  ##
  ##  Licensed under the MPL 1.1. Website: https://rabbitmq.com

  Doc guides: https://rabbitmq.com/documentation.html
  Support:https://rabbitmq.com/contact.html
  Tutorials:  https://rabbitmq.com/getstarted.html
  Monitoring: https://rabbitmq.com/monitoring.html

  Logs: /tmp/d20200814-17660-k3x0b6/log/bu...@paluero.log
/tmp/d20200814-17660-k3x0b6/log/bunny@paluero_upgrade.log

  Config file(s): /tmp/d20200814-17660-k3x0b6/rabbitmq.conf

  Starting broker... completed with 4 plugins.
Error: operation wait on node bunny@paluero timed out. Timeout value used: 1
rake aborted!
command failed: ["/usr/lib/rabbitmq/bin/rabbitmqctl", "wait", 
"/tmp/d20200814-17660-k3x0b6/mnesia/bunny.pid"]
/<>/debian/ruby-tests.rake:53:in `run'
/<>/debian/ruby-tests.rake:62:in `start_rabbitmq_server'
/<>/debian/ruby-tests.rake:75:in `block in '
/usr/share/rubygems-integration/all/gems/rake-13.0.1/exe/rake:27:in `'
Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby2.7" failed. Exiting.
dh_auto_install: error: dh_ruby --install /<>/debian/ruby-bunny 
returned exit code 1
make[1]: *** [debian/rules:10: override_dh_auto_install] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:6: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
--8<---cut here---end--->8---

If we try to build in a container/VM using dpkg-buildpackage and a
non-root user, the error happens even earlier:

--8<---cut here---start->8---
Waiting for pid file '/tmp/d20200814-28938-5mzc2m/mnesia/bunny.pid' to appear
23:47:37.895 [error] 

23:47:37.899 [error] BOOT FAILED
BOOT FAILED
23:47:37.899 [error] ===
===
23:47:37.900 [error] ERROR: distribution port 25672 in use by rabbit@magical-boa
ERROR: distribution port 25672 in use by rabbit@magical-boa
23:47:37.900 [error] 

23:47:38.902 [error] Supervisor rabbit_prelaunch_sup had child prelaunch 
started with rabbit_prelaunch:run_prelaunch_first_phase() at undefined exit 
with reason {dist_port_already_used,25672,"rabbit","magical-boa"} in context 
start_error
23:47:38.903 [error] CRASH REPORT Process <0.153.0> with 0 neighbours exited 
with reason: 
{{shutdown,{failed_to_start_child,prelaunch,{dist_port_already_used,25672,"rabbit","magical-boa"}}},{rabbit_prelaunch_app,start,[normal,[]]}}
 in application_master:init/4 line 138
{"Kernel pid 
terminated",application_controller,"{application_start_failure,rabbitmq_prelaunch,{{shutdown,{failed_to_start_child,prelaunch,{dist_port_already_used,25672,\"rabbit\",\"magical-boa\"}}},{rabbit_prelaunch_app,start,[normal,[]]}}}"}
Kernel pid terminated (application_controller) 
({application_start_failure,rabbitmq_prelaunch,{{shutdown,{failed_to_start_child,prelaunch,{dist_port_already_used,25672,"rabbit","magical-boa"}}},{rabbi

Crash dump is being written to: erl_crash.dump...done
Error: operation wait on node bunny@magical-boa timed out. Timeout value used: 
1
rake aborted!
command failed: ["/usr/lib/rabbitmq/bin/rabbitmqctl", "wait", 
"/tmp/d20200814-28938-5mzc2m/mnesia/bunny.pid"]
/home/sergio/ruby-bunny/debian/ruby-tests.rake:53:in `run'
/home/sergio/ruby-bunny/debian/ruby-tests.rake:62:in `start_rabbitmq_server'
/home/sergio/ruby-bunny/debian/ruby-tests.rake:75:in `block in '
/usr/share/rubygems-integration/all/gems/rake-13.0.1/exe/rake:27:in `'
Tasks: TOP => default
(See full trace by running task with --trace)
ERROR: Test "ruby2.7" failed. Exiting.
dh_auto_install: error: dh_ruby --install 
/home/sergio/ruby-bunny/debian/ruby-bunny returned exit code 1
--8<---cut here---end--->8---

There are a few problems with the testcase:

- As stated above, it can't run under as a non-root user.  For example,
  this won't work:

def start_rabbitmq_server
  fork do
exec('/usr/lib/rabbitmq/bin/rabbitmq-server')
  end

  pidfile = File.join($tmpdir, 'mnesia', 'bunny.pid')
  run('/usr/lib/rabbitmq/bin/rabbitmqctl', 'wait', pidfile)

  run('./bin/ci/before_build')
end

- The file "bunny.pid" isn't (always) named like that.  Here, for
  example, it's named "bunny@${HOST}.pid".  This will break the
  following code:

pidfile = File.join($tmpdir, 'mnesia', 'bunny.pid')
run('/usr/lib/rabbitmq/bin/rabbitmqctl', 'wait', pidfile)

- It tries to "pkill epmd", which also won't work when run as non-root.

It seems to me like this test should be executed by autopkgtest, because
the o

Bug#965209: ITP: php-gettext-languages -- gettext languages with plural rules

[James Valleroy]

Correction to above information: php-gettext-languages ships four JSON data 
files.
- languages
- scripts
- territories
- plurals

Only plurals is from the cldr-core data (in supplemental folder). The other 3 
are from cldr-localenames-modern/main.

So only 1 of the 4 files could be generated from unicode-cldr-core package. We 
would need a "unicode-cldr-localenames" package for the others.



signature.asc
Description: OpenPGP digital signature

Bug#966499: unicode-cldr-core: Please generate JSON data file also

[James Valleroy]

On Fri, 14 Aug 2020 09:44:58 -0400 James Valleroy  wrote:
> On Fri, 14 Aug 2020 06:59:05 -0400 James Valleroy  
> wrote:
> > I found a git repository for converting the data to JSON [1], along with 
> > instructions on how to use it [2]. However, the cldr-localenames package is 
> > not available on npm, and I didn't figure out how to rebuild it yet.
> > 
> > But I found another repository [3], in which I can simply run "npm 
> > install", and it downloads the XML data and converts it to JSON. The 
> > resulting data is very close to what is shipped in php-getttext-languages, 
> > and should be fine for my purposes.
> > 
> > [1] https://github.com/unicode-cldr/cldr-json
> > [2] http://cldr.unicode.org/development/updating-codes/updating-json-data
> > [3] https://github.com/rxaviers/cldr-data-npm
> 
> My bad, [3] is not converting the data. It is downloading the data already in 
> JSON format from multiple repositories under https://github.com/unicode-cldr. 
> The list of URLs that it downloads is here:
> https://github.com/rxaviers/cldr-data-npm/blob/master/urls.json
> 

The JSON data is converted using the cldr-json repository, but it also relies 
on Java libraries from 
https://github.com/unicode-org/cldr/tree/master/tools/java.



signature.asc
Description: OpenPGP digital signature

Bug#968416: lintian: Gives ridiculous warning about spelling in overrides file

[Felix Lechner]

Hi Robert,

On Fri, Aug 14, 2020 at 4:36 PM Robert Luberda  wrote:
>
> lintian started to show the following ridiculous warning about
> spelling in a line that is supposed to explain why lintian is
> wrong with its "typo in manual page" warning.

First off, you are seeing too many warnings. Most of the spelling tags
will be reduced to 'info' severities next week. Here is the full list:

tags/s/spelling-error-in-binary.desc:Severity: info
tags/s/spelling-error-in-changelog.desc:Severity: warning
tags/s/spelling-error-in-copyright.desc:Severity: info
tags/s/spelling-error-in-description.desc:Severity: warning
tags/s/spelling-error-in-description-synopsis.desc:Severity: warning
tags/s/spelling-error-in-doc-base-abstract-field.desc:Severity: warning
tags/s/spelling-error-in-doc-base-title-field.desc:Severity: warning
tags/s/spelling-error-in-news-debian.desc:Severity: warning
tags/s/spelling-error-in-patch-description.desc:Severity: warning
tags/s/spelling-error-in-readme-debian.desc:Severity: warning
tags/s/spelling-error-in-rules-requires-root.desc:Severity: warning
tags/s/spelling-in-override-comment.desc:Severity: warning

We'll try to address the line number too, although many of our line
references are approximate (as are those in the coding universe). I am
not sure why you spent so much time. Your override file is only three
lines long. [1]

More than likely, your confusion was caused by the fact that the
offending phrase also appeared in line 3, but that line is not an
override comment.

Aside from those observations, there is an underlying false positive.
We may ultimately turn off the multi-word part of spell check for
override comments, or perhaps require that spaces are used instead of
word breaks. We are in touch with our chief spell checker to find the
best solution for you.

Thanks to Paul Wise for these suggestions!

[1] https://sources.debian.org/src/super/3.30.1-1/debian/lintian-overrides/

> what's the point of checking spelling there?

Like most of our tags, this one is based on user suggestions. Being a
checking tool, Lintian tends to check more rather than less. It is
always better to ignore our tags instead of getting frustrated. We are
trying to make Lintian more accurate and helpful for everyone.

We also do not know how common an issue is when a tag is implemented.
In the future, we hope to derive a diagnostic power from comparing
false positives (as indicated by overrides) to the overall prevalence
in the archive. That will help us drop tags that are annoying rather
than helpful, for Debian contributors as a whole.

> And BTW. are you going
> to check spelling of comments in source code files as well? I'm pretty
> sure you can find a lot of spelling typos there...

I am sorry but we do not plan to implement your suggestion. You may be
correct that there are lots of typos in code comments but that task is
too complicated for us.

Patches are welcome.

Kind regards
Felix Lechner

Bug#964458: checkinstall: causes segfault of cmake

[Bernhard Übelacker]

Dear Maintainer,
tried to have a look and it seems that installwatch.so's
initialize function was not yet called.

Attached are some details and a patch trying to call initialize
just before the call to true_xstat64.

Another patch would add a build-id to the shared object, so
the build process can create a debug symbol package.

Kind regards,
Bernhard


Location just before we end up with eip=0:
  (rr) reverse-stepi
  0xb7edd1d8 in __xstat64 (version=, pathname=, 
info=) at installwatch.c:3731
  3731result=true_xstat64(version,pathname,info);
  1: x/i $pc
  => 0xb7edd1d8 <__xstat64+88>:   jmp*%eax

  (rr) print true_xstat64
  $1 = (int (*)(int, const char *, struct stat64 *)) 0x0
Description: Force initialize for xstat64

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/964458
Forwarded: no
Last-Update: 2020-08-15

Index: checkinstall-1.6.2+git20170426.d24a630/installwatch/installwatch.c
===
--- checkinstall-1.6.2+git20170426.d24a630.orig/installwatch/installwatch.c
+++ checkinstall-1.6.2+git20170426.d24a630/installwatch/installwatch.c
@@ -3728,6 +3728,8 @@ int __xstat64(int version,const char *pa
 	  /* We were asked to work in "real" mode */
 	if( !(__instw.gstatus & INSTW_INITIALIZED) ||
 	!(__instw.gstatus & INSTW_OKWRAP) ) {
+		if (!true_xstat64)
+			initialize();
 		result=true_xstat64(version,pathname,info);
 		return result;
 	}
Description: Add build-id to enable automatic generation of dbgsym package.

Author: Bernhard Übelacker 
Forwarded: no
Last-Update: 2020-08-15

Index: checkinstall-1.6.2+git20170426.d24a630/installwatch/Makefile
===
--- checkinstall-1.6.2+git20170426.d24a630.orig/installwatch/Makefile
+++ checkinstall-1.6.2+git20170426.d24a630/installwatch/Makefile
@@ -16,7 +16,7 @@ LIBDIR=$(PREFIX)/lib
 all: installwatch.so
 
 installwatch.so: installwatch.o
-	ld -znow -shared -o installwatch.so installwatch.o -ldl -lc
+	ld -znow -shared --build-id -o installwatch.so installwatch.o -ldl -lc
 
 installwatch.o: installwatch.c localdecls.h
 	gcc $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) -Wall -c -g -D_GNU_SOURCE -DPIC -fPIC -D_REENTRANT -DVERSION=\"$(VERSION)\" installwatch.c

# Unstable i386 qemu VM 2020-08-14

apt update
apt dist-uprade


apt install systemd-coredump gdb git fakeroot mc checkinstall libgnutls30-dbgsym
apt build-dep libgnutls30
apt build-dep rr
apt build-dep checkinstall


echo 1 > /proc/sys/kernel/perf_event_paranoid



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



# unfortunately no checkinstall-dbgsym package available ...

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

cd /home/benutzer/source/checkinstall
cp orig try1 -a
cd try1/checkinstall-1.6.2+git20170426.d24a630/
DEB_BUILD_OPTIONS=nostrip dpkg-buildpackage

dpkg -i 
/home/benutzer/source/checkinstall/try1/checkinstall_1.6.2+git20170426.d24a630-2_i386.deb







mkdir /home/benutzer/source/rr/git -p
cd/home/benutzer/source/rr/git
git clone https://github.com/mozilla/rr.git
cd

cd /home/benutzer/source/rr/git/rr/
mkdir obj && cd obj
cmake ../rr
make -j4








touch CMakeLists.txt
cmake .
installwatch cmake .


$ installwatch cmake .

INFO : Using a default root directory : /tmp/tmp.2yZ1I6G54F

/usr/bin/installwatch: Zeile 338:  3465 Speicherzugriffsfehler  (Speicherabzug 
geschrieben) "$@"


dmesg:
[Sa Aug 15 01:32:54 2020] cmake[3465]: segfault at 0 ip  sp bfd2951c 
error 14 in cmake[4bf000+1]
[Sa Aug 15 01:32:54 2020] Code: Bad RIP value.


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sat 2020-08-15 01:32:55 CEST   3465  1000  1000  11 present   /usr/bin/cmake



root@debian:~# coredumpctl gdb 3465
...
Core was generated by `cmake .'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0xb6a59c13 in ?? () from /usr/lib/i386-linux-gnu/libgnutls.so.30
#2  0xb6a6d535 in ?? () from /usr/lib/i386-linux-gnu/libgnutls.so.30
#3  0xb6a3f990 in ?? () from /usr/lib/i386-linux-gnu/libgnutls.so.30
#4  0xb7f3be9c in call_init (l=, argc=argc@entry=2, 
argv=argv@entry=0xbfd29694, env=0xbfd296a0) at dl-init.c:72
#5  0xb7f3bfa2 in call_init (env=0xbfd296a0, argv=0xbfd29694, argc=2, 
l=) at dl-init.c:30
#6  _dl_init (main_map=, argc=2, argv=0xbfd29694, 
env=0xbfd296a0) at dl-init.c:119
#7  0xb7f2c0fa in _dl_start_user () from /lib/ld-linux.so.2


(gdb) bt
#0  0x in ?? ()
#1  0xb6a59c13 in stat64 (__statbuf=, __path=0xb6b572bb 
"/etc/gnutls/config") at /usr/include/i386-linux-gnu/sys/stat.h:455
#2  _gnutls_update_system_priorities () at ../../lib/priority.c:1309
#3  0xb6a6d535 in _gnutls_global_init (constructor=constructor@entry=1) at 
../../lib/global.c:3

Bug#968418: ecj depends on java-wrappers but does not have them as a dependency

[Sergey Lisov]

Package: ecj
Version: 3.16.0-1
Severity: important

Dear Maintainer,

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

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

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


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.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 ecj depends on:
ii  libecj-java   3.16.0-1
ii  openjdk-11-jre-headless [java8-runtime-headless]  11.0.8+10-1~deb10u1
ii  openjdk-8-jre-headless [java8-runtime-headless]   8u222-b10-1~deb9u1

ecj recommends no packages.

Versions of packages ecj suggests:
ii  ant  1.10.5-2

-- no debconf information

Bug#968417: netkit-ftp-ssl: Please backport ftp-ssl to buster

[William Blough]

Package: netkit-ftp-ssl
Severity: wishlist


Hi,

Since ftp-ssl did not make it into buster, there do not appear to be any
command line ftp clients in buster that support ssl/tls.

Please consider backporting ftp-ssl to buster in order to allow
encrypted ftp sessions.

Thanks!

Bug#907576: . ITP: dream --A Software Digital Radio Mondiale

[GMiller]

Hello Christoph

BTW I made a new GPG. My old GPG is about expired and references the old Email. 
If I understand correctly the package must be signed before I push it.

I am reading through various documents on the upload procedure. One problem I 
see is that dput is expecting a changes file, when of course since compilation 
failed I don't have one yet. The normal procedure only uploads changes and a 
few others. In this case you may want access to all my original directory 
structure, etc (its about 29MB). I don't see any command switches that seem to 
apply to this case. I may be off in the wrong direction. Any suggestions on 
where to look?

73

Garie wb9awa

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

Bug#968416: lintian: Gives ridiculous warning about spelling in overrides file

[Robert Luberda]

Package: lintian
Version: 2.88.0
Severity: normal

While preparing a new upload of the super package, I noticed that 
lintian started to show the following ridiculous warning about 
spelling in a line that is supposed to explain why lintian is 
wrong with its "typo in manual page" warning.

W: super: spelling-in-override-comment typo-in-manual-page (line 3) "allow to" 
"allow one to"


Here is the full content of lintian-overrides:

super: setuid-binary usr/bin/super 4755 root/root
# "...changes root's default setting from default-allow to default-deny..."
super: spelling-error-in-manpage usr/share/man/man5/super.tab.5.gz allow to 
allow one to


Please note that the warning is talking about "(line 3)" while the
actual problem lies in line 2. I've lost some time to discover this.

But to be honest. I have no idea, why lintian even checks spelling of the
overrides files. The files are not supposed to be read by regular users,
so what's the point of checking spelling there? And BTW. are you going
to check spelling of comments in source code files as well? I'm pretty
sure you can find a lot of spelling typos there...


Regards,
robert


Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (990, 'unstable-debug'), (990, 'unstable'), (990, 'testing'), 
(990, 'stable'), (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Bug#946035: spyder: RFH: needs Build-Depends: python-language-server

[Pablo Mestre]

Hi,

I open an ITP to python-language-server
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963605 but in the
process I dicover I need to package python-jsonrpc-server
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964497

Now im stuck with some issues with the test module, and I'm not sre how
im can solve. Would be helpful an extra hand to go forward.

Here the repositpory on salsa
https://salsa.debian.org/elMor3no-guest/python-jsonrpc-server

Regards

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.

Bug#968415: susv4: Setting up susv4 fails

[Boyd Stephen Smith Jr.]

Package: susv4
Version: 7.20180621
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

- ---8<---
Setting up susv4 (7.20180621) ...
Fetching file...
- --2020-08-14 17:15:44--  
http://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2
Resolving pubs.opengroup.org (pubs.opengroup.org)... 52.32.134.144, 
54.202.59.160
Connecting to pubs.opengroup.org (pubs.opengroup.org)|52.32.134.144|:80... 
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: 
https://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2 
[following]
- --2020-08-14 17:15:45--  
https://pubs.opengroup.org/onlinepubs/9699919799/download/susv4-2018.tar.bz2
Connecting to pubs.opengroup.org (pubs.opengroup.org)|52.32.134.144|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 3730770 (3.6M) [application/x-bzip2]
Saving to: ‘/tmp/tmp.FdMJjFVTQS/susv4-2018.tar.bz2’

susv4-2018.tar.bz2  
100%[==>]
   3.56M  5.55MB/sin 0.6s

2020-08-14 17:15:46 (5.55 MB/s) - ‘/tmp/tmp.FdMJjFVTQS/susv4-2018.tar.bz2’ 
saved [3730770/3730770]

Verifying SHA512 checksum...
dpkg: error processing package susv4 (--configure):
 installed susv4 package post-installation script subprocess returned error 
exit status 1
- --->8---

- -- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (850, 
'proposed-updates'), (700, 'testing'), (500, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-10-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages susv4 depends on:
ii  bzip2  1.0.6-9.2~deb10u1
ii  wget   1.20.1-1.1

susv4 recommends no packages.

susv4 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHQEARECADQWIQTFhn3a8g2plxzZYyjnmmovsbVAWQUCXzcOARYcYnNzQGlndWFu
YXN1aWNpZGUubmV0AAoJEOeaai+xtUBZwccAniYl09PczqhFQWld2bfi97r7dPTA
AJ4ykaerojHpsL86oLM0AysFY05qHQ==
=Viuf
-END PGP SIGNATURE-

Bug#968413: failes to build on ppc64el with binutils 2.35

[Thadeu Lima de Souza Cascardo]

Source: oss4
Followup-For: Bug #968413

Patch is attached.

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.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
diff -Nru oss4-4.2-build2017/debian/changelog 
oss4-4.2-build2017/debian/changelog
--- oss4-4.2-build2017/debian/changelog 2019-01-08 20:51:07.0 -0200
+++ oss4-4.2-build2017/debian/changelog 2020-08-14 19:03:06.0 -0300
@@ -1,3 +1,10 @@
+oss4 (4.2-build2017-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build on ppc64el with binutils 2.35 (Closes: #968413)
+
+ -- Thadeu Lima de Souza Cascardo   Fri, 14 Aug 2020 
19:03:06 -0300
+
 oss4 (4.2-build2017-1) unstable; urgency=low
 
   [ Sébastien Noel ]
diff -Nru 
oss4-4.2-build2017/debian/patches/libsalsa_drop_ppc64_specific_workaround_for_versioned_symbols.patch
 
oss4-4.2-build2017/debian/patches/libsalsa_drop_ppc64_specific_workaround_for_versioned_symbols.patch
--- 
oss4-4.2-build2017/debian/patches/libsalsa_drop_ppc64_specific_workaround_for_versioned_symbols.patch
   1969-12-31 21:00:00.0 -0300
+++ 
oss4-4.2-build2017/debian/patches/libsalsa_drop_ppc64_specific_workaround_for_versioned_symbols.patch
   2020-08-14 18:44:27.0 -0300
@@ -0,0 +1,54 @@
+Description: Drop ppc64-specific workaround for versioned symbols
+ Based on a patch by Breno Leitao applied to the original file from
+ alsa-lib.
+ oss4 started failing to build on ppc64el with binutils 2.35 because it
+ was setting an undefined symbol as the default version. It was doing that
+ in order to support dot-symbols/function descriptors on ppc, which is not
+ used by userspace ABI since a while, and not supported with ABIv2, the one
+ used by ppc64el, at all.
+Author: Thadeu Lima de Souza Cascardo 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1891565
+Last-Update: 2020-08-14
+---
+Index: oss4-4.2-build2010/lib/libsalsa/alsa-symbols.h
+===
+--- oss4-4.2-build2010.orig/lib/libsalsa/alsa-symbols.h
 oss4-4.2-build2010/lib/libsalsa/alsa-symbols.h
+@@ -29,19 +29,10 @@
+ #define INTERNAL_CONCAT2_2(Pre, Post) Pre##Post
+ #define INTERNAL(Name) INTERNAL_CONCAT2_2(__, Name)
+ 
+-#ifdef __powerpc64__
+-# define symbol_version(real, name, version)  \
+-  __asm__ (".symver " #real "," #name "@" #version);  \
+-  __asm__ (".symver ." #real ",." #name "@" #version)
+-# define default_symbol_version(real, name, version)  \
+-  __asm__ (".symver " #real "," #name "@@" #version); \
+-  __asm__ (".symver ." #real ",." #name "@@" #version)
+-#else
+ # define symbol_version(real, name, version) \
+   __asm__ (".symver " #real "," #name "@" #version)
+ # define default_symbol_version(real, name, version) \
+   __asm__ (".symver " #real "," #name "@@" #version)
+-#endif
+ 
+ #ifdef USE_VERSIONED_SYMBOLS
+ #define use_symbol_version(real, name, version) \
+@@ -50,17 +41,9 @@
+   default_symbol_version(real, name, version)
+ #else
+ #define use_symbol_version(real, name, version)   /* nothing */
+-#ifdef __powerpc64__
+-#define use_default_symbol_version(real, name, version) \
+-  __asm__ (".weak " #name);   \
+-  __asm__ (".weak ." #name);  \
+-  __asm__ (".set " #name "," #real);  \
+-  __asm__ (".set ." #name ",." #real)
+-#else
+ #define use_default_symbol_version(real, name, version) \
+   __asm__ (".weak " #name); \
+   __asm__ (".set " #name "," #real)
+ #endif
+-#endif
+ 
+ #endif /* __ALSA_SYMBOLS_H */
diff -Nru oss4-4.2-build2017/debian/patches/series 
oss4-4.2-build2017/debian/patches/series
--- oss4-4.2-build2017/debian/patches/series2019-01-08 19:48:00.0 
-0200
+++ oss4-4.2-build2017/debian/patches/series2020-08-14 18:44:34.0 
-0300
@@ -20,3 +20,4 @@
 502_linux_io.patch
 reproducible-build.patch
 503_glibc_2.28.patch
+libsalsa_drop_ppc64_specific_workaround_for_versioned_symbols.patch

Bug#968413: failes to build on ppc64el with binutils 2.35

[Thadeu Lima de Souza Cascardo]

Source: oss4
Version: 4.2-build2017-1
Severity: serious
Tags: patch

/tmp/ccGBTa5R.s: Assembler messages:
/tmp/ccGBTa5R.s: Error: invalid attempt to declare external version name as 
default in symbol
`.snd_pcm_hw_params_set_rate_near@@ALSA_0.9.0rc4'

oss4 started failing to build on ppc64el with binutils 2.35 because it
was setting an undefined symbol as the default version. It was doing that
in order to support dot-symbols/function descriptors on ppc, which is not
used by userspace ABI since a while, and not supported with ABIv2, the one
used by ppc64el, at all.

As this header comes from alsa, I looked at its history and, for different
reasons, it has been fixed there already. So, sending a patch based on that one
here to fix the build.

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.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

Bug#966515: scons: Some upstream sources are missing

[Ben Hutchings]

On Thu, 2020-07-30 at 06:17 -0700, Bill Deegan wrote:
> Ok
> 
> Can you check the 4.0.1 tarballs and see if they provide in each what you
> need?
> We completely reimplemented packaging in 4.0.0

I can't find a scons-src tarball for 4.0.1.

Ben.

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom

Bug#911560: Testing Various delays

[Jonas Smedegaard]

Quoting Nicolas Dufresne (2020-08-14 22:07:11)
> I've then set the RX delay too, to 4, and could notice a very minimal 
> improvement, 8.5 MB/s upload. Now the issue is that these are all 
> terrible results for a gigabit ethernet. There must be other issues 
> around. But a delay of 4 at least makes it usable (at around 100Mb/s).

Did you try setting RX delay to _other_ values?

Seems from adjustments of other hardware that don't need not be equal.


 - Jonas

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

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

signature.asc
Description: signature

Bug#911560: Testing Various delays

[Jonas Smedegaard]

Quoting Nicolas Dufresne (2020-08-14 22:07:11)
> Follow up:
> 
> I've tested download rate with a 125MB file over tftp. Even though 
> tftp code (or tftp itself?) is inefficient I could repeat the 
> following:
> 
> Delay   | 2   | 3   | 4   |  5  |
> ---
> Mb/s| 2.0 | 2.1 | 2.7 | 2.1 |
> Timeouts| 5   | 4   | 1   | 4   |
> 
> The timeouts are the number of time u-boot pinted a T during the
> transfer. I've also attempted some test form Linux side, and notice
> some asymmetry, 9.7 MB/s download, and 7.8 MB/s upload. That was with
> the same file with scp.
> 
> I've then set the RX delay too, to 4, and could notice a very minimal
> improvement, 8.5 MB/s upload. Now the issue is that these are all
> terrible results for a gigabit ethernet. There must be other issues
> around. But a delay of 4 at least makes it usable (at around 100Mb/s).
> 
> Le vendredi 14 août 2020 à 14:26 -0400, Nicolas Dufresne a écrit :
> > As asked over IRC, I have tested various TX_DELAY on Lime2 rev K.
> > 
> > - 2, 3, and 4 was good enough to succeed a DHCP handshake.
> > 
> > - 0 and 1 made the request to never be seen over the network.
> > 
> > An obvious next step would be to test again with large file transfer,
> > perhaps a kernel image. I will report back.

Thanks a lot for these tests.  Really helpful!

There _are_ other limiting factors than ethernet speed involved - I do 
not know what maximum to expect on this kind of board, however.


 - Jonas

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

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

signature.asc
Description: signature

Bug#968412: photoflow FTBFS: incompatible compiler options

[Helmut Grohne]

Source: photoflow
Version: 0.2.8+git20200114-1
Severity: important
Tags: ftbfs patch

photoflow fails to build from source on !x86, because it passes
x86-specific compiler options. These should only be present on x86.
Please consider applying the attached patch to make it build elsewhere.

Helmut
--- photoflow-0.2.8+git20200114.orig/src/CMakeLists.txt
+++ photoflow-0.2.8+git20200114/src/CMakeLists.txt
@@ -1,12 +1,26 @@
+SET(GMIC_FLAGS "-Dgmic_build -Dcimg_use_vt100 -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -fpermissive")
 IF(MINGW)
-  SET(GMIC_FLAGS "-std=gnu++14 -march=nocona -mno-sse3 -mtune=generic -Dgmic_build -Dcimg_use_vt100 -Dgmic_is_parallel -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -fno-ipa-sra -fpermissive")
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -std=gnu++14 -Dgmic_is_parallel -fno-ipa-sra")
 ELSEIF(APPLE)
   #SET(GMIC_FLAGS "-DPF_DISABLE_GMIC -std=c++11 -Wno-error=c++11-narrowing -Dgmic_build -W  -Dcimg_use_vt100 -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -Dcimg_use_fftw3_singlethread -fpermissive")
-  SET(GMIC_FLAGS "-march=nocona -mno-sse3 -mtune=generic -Dgmic_build -Dcimg_use_vt100 -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -Dcimg_use_fftw3_singlethread -fpermissive")
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -Dcimg_use_fftw3_singlethread")
   #SET(GMIC_FLAGS "-Wno-error=c++11-narrowing -Dgmic_build -Dcimg_use_vt100 -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -Dcimg_use_fftw3_singlethread -fpermissive")
 ELSE(MINGW)
-  SET(GMIC_FLAGS "-std=gnu++14 -march=nocona -mno-sse3 -mtune=generic -Wno-error=narrowing -Dgmic_build -Dcimg_use_vt100 -Dgmic_is_parallel -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -fno-ipa-sra -fpermissive")
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -std=gnu++14 -Wno-error=narrowing -Dgmic_is_parallel -fno-ipa-sra")
 ENDIF(MINGW)
+include(CheckCCompilerFlag)
+check_c_compiler_flag(-no-sse3 HAVE_NO_SSE3)
+IF(HAVE_NO_SSE3)
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -no-sse3")
+ENDIF()
+check_c_compiler_flag(-march=nocona HAVE_MARCH_NOCONA)
+IF(HAVE_MARCH_NOCONA)
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -march=nocona")
+ENDIF()
+check_c_compiler_flag(-mtune=generic HAVE_MTUNE_GENERIC)
+IF(HAVE_MTUNE_GENERIC)
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -mtune=generic")
+ENDIF()
 
 set(COMPILE_FLAGS " ${GMIC_FLAGS} -I${CMAKE_SOURCE_DIR}/src/dt -DLIBRAW_NODLL -DINSTALL_PREFIX='\"${INSTALL_PREFIX}\"' ")
 IF(APPLE)

Bug#968411: lvm2 FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: lvm2
Version: 2.03.09-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lvm2 fails to cross build from source, because it hard codes the build
architecture pkg-config in a few places. Please consider applying the
attached patch to always use the correctly detected host architecture
pkg-config. After applying it, lvm2 becomes cross buildable.

Helmut
--- lvm2-2.03.09.orig/configure.ac
+++ lvm2-2.03.09/configure.ac
@@ -1288,8 +1288,8 @@
 dnl -- Check for selinux
 if test "$SELINUX" = yes; then
 	AC_DEFINE([HAVE_SELINUX], 1, [Define to 1 to include support for selinux.])
-	SELINUX_LIBS="$(pkg-config --libs libselinux)"
-	SELINUX_LIBS_STATIC="$(pkg-config --libs --static libselinux)"
+	SELINUX_LIBS="$($PKG_CONFIG --libs libselinux)"
+	SELINUX_LIBS_STATIC="$($PKG_CONFIG --libs --static libselinux)"
 fi
 
 
@@ -1551,6 +1551,9 @@
 AC_MSG_RESULT($interface)
 
 
+PKG_CHECK_MODULES([LIBSYSTEMD],[libsystemd],[HAVE_LIBSYSTEMD=yes],[HAVE_LIBSYSTEMD=no])
+
+
 read DM_LIB_VERSION < "$srcdir"/VERSION_DM 2>/dev/null || DM_LIB_VERSION=Unknown
 AC_DEFINE_UNQUOTED(DM_LIB_VERSION, "$DM_LIB_VERSION", [Library version])
 
@@ -1625,6 +1628,7 @@
 AC_SUBST(FSADM_PATH)
 AC_SUBST(BLKDEACTIVATE)
 AC_SUBST(HAVE_LIBDL)
+AC_SUBST(HAVE_LIBSYSTEMD)
 AC_SUBST(HAVE_REALTIME)
 AC_SUBST(HAVE_VALGRIND)
 AC_SUBST(INTL)
--- lvm2-2.03.09.orig/daemons/lvmlockd/Makefile.in
+++ lvm2-2.03.09/daemons/lvmlockd/Makefile.in
@@ -15,8 +15,6 @@
 top_srcdir = @top_srcdir@
 top_builddir = @top_builddir@
 
-USE_SD_NOTIFY=yes
-
 SOURCES = lvmlockd-core.c
 
 ifeq ("@BUILD_LOCKDSANLOCK@", "yes")
@@ -44,9 +42,9 @@
 LIBS += $(RT_LIBS) $(DAEMON_LIBS) $(PTHREAD_LIBS)
 
 
-ifeq ($(USE_SD_NOTIFY),yes)
-	CFLAGS += $(shell pkg-config --cflags libsystemd) -DUSE_SD_NOTIFY
-	LIBS += $(shell pkg-config --libs libsystemd)
+ifeq ($(HAVE_LIBSYSTEMD),yes)
+	CFLAGS += $(LIBSYSTEMD_CFLAGS) -DUSE_SD_NOTIFY
+	LIBS += $(LIBSYSTEMD_LIBS)
 endif
 
 lvmlockd: $(OBJECTS) $(top_builddir)/libdaemon/client/libdaemonclient.a \
--- lvm2-2.03.09.orig/make.tmpl.in
+++ lvm2-2.03.09/make.tmpl.in
@@ -75,6 +75,8 @@
 BLKID_LIBS = @BLKID_LIBS@
 SYSTEMD_LIBS = @SYSTEMD_LIBS@
 VALGRIND_CFLAGS = @VALGRIND_CFLAGS@
+LIBSYSTEMD_CFLAGS = @LIBSYSTEMD_CFLAGS@
+LIBSYSTEMD_LIBS = @LIBSYSTEMD_LIBS@
 USE_TRACKING = @USE_TRACKING@
 
 # Setup directory variables

Bug#968402: Cannot connect in WPA3-sae mode, using WPA2-psk instead

[Jean-Michel Pouré]

Package: network-manager
Version: 1.26.0-1

wpasupplicant   2:2.9.0-13

Dear Maintainer,

When trying to connect to OpenWRT access point running in WPA2/WPA3
compatibility mode, I can only connect in WPA2-psk, not WPA3-sae. 

Connecting in WPA3 from Mac OS X works.

Using nmtui or Network-Manager I need to edit connection settings to
WPA/WPA2 mode. Then Network-Manager claims to connect in WPA3, but I
doubt it is WPA3 as my seeings are only for WPA/WPA2.

The problem was also described here on GITLAB Network-manager:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/172

It was fixed ten months ago in 1.20.2 but the problem remains.

Kind regards,

Bug#968410: python3-setuptools: ModuleNotFoundError: No module named '_distutils_hack'

[Christian Kastner]

Package: python3-setuptools
Version: 49.3.1-1
Severity: grave
Justification: Package is unusable

The most recent upload broke something badly, setuptools can no longer
be imported:

$ python3 -c 'import setuptools'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 8, in 

import _distutils_hack.override  # noqa: F401
ModuleNotFoundError: No module named '_distutils_hack'


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

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

Versions of packages python3-setuptools depends on:
ii  python33.8.2-3
ii  python3-distutils  3.8.5-1
ii  python3-pkg-resources  49.3.1-1

python3-setuptools recommends no packages.

Versions of packages python3-setuptools suggests:
pn  python-setuptools-doc  

-- debconf-show failed

Bug#907878: xrdp: gnome session asks permission for colord

[Marc Dunivan]

I confirm, this still exists in Debian 10 (Buster).  Debian Desktop 
GNOME3...xRDP package seems to be missing PolicyKit configuration files for 
GNOME3 shell.
I also wish to add that org.freedesktop.packagekit.system-sources-refresh 
should be added to this list.  There are also other PolicyKit configurations 
related to using GNOME Control Center.

Additionally,  GNOME Keyring isn't getting unlocked with PAM.

sudo bash -c "cat > /etc/pam.d/xrdp-sesman" <

Bug#968409: simplescreenrecorder: Upstream Release 0.4.2 Available

[Barak A. Pearlmutter]

Package: simplescreenrecorder
Version: 0.3.11-1+b1
Severity: normal
X-Debbugs-Cc: none, Barak A. Pearlmutter 

Upstream version 0.4.2 has been released.  I've taken the liberty of
forking the maintenance repo on salsa

https://salsa.debian.org/bap/simplescreenrecorder

and pushed a trial packaging there, which seems to work.  I also filed
merge requests on salsa, because that's what kids do these days.

Cheers,

--Barak

Bug#968408: ITP: ruby-unparser -- Generate equivalent source for parser gem AST nodes.

[Cocoa]

package: ruby-unparser
Severity: wishlist
Owner: 'Cocoa'

*Package Name  : ruby-unparser
 Version   : 0.4.7-1
 Upstream Author   : Markus Schirp mailto:m...@schirp-dso.com>>
*URL   :https://github.com/mbj/unparser  

*License   : MIT
*Description   : Generate equivalent source for parser gem AST nodes.

Bug#911560: Testing Various delays

[Nicolas Dufresne]

Follow up:

I've tested download rate with a 125MB file over tftp. Even though tftp
code (or tftp itself?) is inefficient I could repeat the following:

Delay   | 2   | 3   | 4   |  5  |
---
Mb/s| 2.0 | 2.1 | 2.7 | 2.1 |
Timeouts| 5   | 4   | 1   | 4   |

The timeouts are the number of time u-boot pinted a T during the
transfer. I've also attempted some test form Linux side, and notice
some asymmetry, 9.7 MB/s download, and 7.8 MB/s upload. That was with
the same file with scp.

I've then set the RX delay too, to 4, and could notice a very minimal
improvement, 8.5 MB/s upload. Now the issue is that these are all
terrible results for a gigabit ethernet. There must be other issues
around. But a delay of 4 at least makes it usable (at around 100Mb/s).

Le vendredi 14 août 2020 à 14:26 -0400, Nicolas Dufresne a écrit :
> As asked over IRC, I have tested various TX_DELAY on Lime2 rev K.
> 
> - 2, 3, and 4 was good enough to succeed a DHCP handshake.
> 
> - 0 and 1 made the request to never be seen over the network.
> 
> An obvious next step would be to test again with large file transfer,
> perhaps a kernel image. I will report back.
> 
> regards,
> Nicolas
> 

Bug#968407: ITP: ruby-morpher -- Data transformation algebra with optional tracked evaluation.

[Cocoa]

package: ruby-morpher
Severity: wishlist
Owner: 'Cocoa'

*Package Name  : ruby-morpher
 Version   : 0.2.6-1
 Upstream Author   : Markus Schirp mailto:m...@schirp-dso.com>>
*URL   :https://github.com/mbj/morpher  

*License   : MIT
*Description   : Morpher is a data transformation algebra with optional 
tracked evaluation.

Bug#530604: checkrestart can use /run/reboot-required to check for a new kernel

[Kenyon Ralph]

This is even simpler to check for now. Kernel packages create
/run/reboot-required and add their package name to
/run/reboot-required.pkgs, so you can just check for those files. I
would welcome an enhancement to checkrestart that said something about
these files, so that you know from checkrestart's output when you're not
running the latest kernel that you have installed.



pEpkey.asc
Description: application/pgp-keys

Bug#968365: /usr/bin/freshclam: Ignores DatabaseCustomURL unless --update-db=custom is specified

[Sebastian Andrzej Siewior]

On 2020-08-13 17:21:04 [+0200], Stephan Jänecke wrote:
> starting with version 0.102.3 freshclam ignores DatebaseCustomURL
> options.

Are you sure about the versions? I've been looking at the changes
0.102.2..0.102.3 and there is nothing the freshclam area. That option
appears to be there. It might have happen earlier when they switched to
libcurl instead of doing their own http…

> As this option is used to specify custom paths to update databases on
> our local mirror, updates fail after upgrading from version 0.101.4.

okay. Then it is a 0.101 -> 0.102 kind of thing.

> Let me give you an example. Instead of downloading the database from
> `http://update.dfn-cert.de/av-sigs/clamav/db/main.cvd` freshclam will
> try `https://update.dfn-cert.de/main.cvd` and fail.
…
> Looking at the code I figured out that freshclam can be motivated to honour
> the values in DatabaseCustomURL options. Once I specified the executable
> parameter `--update-db=custom` freshclam happily updated the databases
> from the custom paths.
…
> Now I'm wondering: is my site incorrectly specifying custom database
> paths using `DatabaseCustomURL` and the breakage on update has been
> intentionally introduced by upstream? If so, what would be the correct
> way to introduce custom paths?

It sounds like you want to use PrivateMirror. But then you don't have
same path so it probably won't work. I don't know.

You have
DatabaseMirror = "update.dfn-cert.de"

set which means it will look for

   update.dfn-cert.de/main.cvd
   update.dfn-cert.de/daily.cvd

so it works as expected so far. You have also set DatabaseCustomURL so
it should look additionally for

   update.dfn-cert.de/av-sigs/clamav/db/main.cvd

Now the fact that it does not might have something to do with the part
that it fails while looking for update.dfn-cert.de/main.cvd. But from
looking at the code (in this heat) it should do so.

By using "--update-db=custom" then you limit the download to the custom
URL only which is what you specify with DatabaseCustomURL. This skips
the download of main/daily/bytecode.

> Or did I indeed find a bug?

Maybe something that was not planned. It might be possible that your
custom URL contained the 'main.cvd' file which then overwrote the
'main.cvd' from the official mirror. Now it does it no longer and would
in your case download the main.cvd twice.
If you could verify the part with PrivateMirror then I/you could open a
bug with upstream asking what the recommended way is to use a private
mirror with a different hierarchy. This is what you intend to do I
guess.

> Best regards,
> 
> Stephan Jänecke

Sebastian

Bug#966215: mystiq: Please also enable build on other architectures

[Boyuan Yang]

Hi Pablo,

在 2020-08-14星期五的 13:35 -0300，Pablo Mestre写道：
> Hi Boyuan,
> 
> Sorry fo the late on the reply. I upate the repoitory and solve the
> bug.
> 
> Now im waiting for a DD upload the binary.

I just sponsored your package from the git packaging repository. Next
time if you are looking for a package sponsor other than me, please
consider opening a RFS bug as described at 
https://wiki.debian.org/DebianMentorsFaq since I may not always be
available for reviewing your package.

Also please let me know if you are willing to maintain package mystiq
in Debian's backports repository; you may find detailed information at 
https://backports.debian.org/ . If you prepare a proper packaging
branch in your packaging repo, I can help to sponsor this bpo upload so
that users of Debian 10 can make use of package mystiq as well.

Thanks,
Boyuan Yang


> El 8/14/20 a las 11:31 AM, Boyuan Yang escribió:
> > X-Debbugs-CC: pmdc...@gmail.com
> > 
> > On Tue, 28 Jul 2020 14:28:05 -0300 Pablo Mestre 
> > wrote:
> > > Hi,
> > > 
> > > I will check this and update the package.
> > > 
> > > Thanks for the notice.
> > Hi Pablo,
> > 
> > Is there any progress on it? I believe the fix would be just a one-
> > liner change by replacing "amd64" with "any".
> > 
> > Let me know if you need help applying this change. I can also
> > provide a
> > non-maintainer upload if you find it okay.
> > 

Bug#968405: ITP: ruby-anima -- Initialize object attributes via attributes hash

[cocoa1231]

package: ruby-anima Severity: wishlist Owner: 'Cocoa'  
(mailto:cocoa1...@disroot.org) *Package Name : ruby-anima Version : 0.3.1-1 
Upstream Author : Markus Schirp mailto:m...@schirp-dso.com)> *URL : https://github.com/mbj/anima 
(https://github.com/mbj/anima) *License : MIT *Description : Simple library to 
declare read only attributes on value-objects that are initialized via 
attributes hash.

Bug#968406: ITP: ruby-anima -- Initialize object attributes via attributes hash

[Cocoa]

package: ruby-anima
Severity: wishlist
Owner: 'Cocoa'

*Package Name  : ruby-anima
 Version   : 0.3.1-1
 Upstream Author   : Markus Schirp mailto:m...@schirp-dso.com>>
*URL   :https://github.com/mbj/anima  

*License   : MIT
*Description   : Simple library to declare read
 only attributes on value-objects that are initialized via 
attributes hash.

Bug#968327: systemtap: FTBFS: uses %lu to print rlim_t which can be unsigned long long though

[Thorsten Glaser]

Frank Ch. Eigler dixit:

>We merged an embiggened version of your patch to upstream master, thanks!

Thank you!

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs

[Sudip Mukherjee]

Hi Itaï,

On Tue, Aug 11, 2020 at 1:54 PM Itaï BEN YAACOV  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Itaï BEN YAACOV 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: auctex-12
>   Version : 12.2
>   Upstream Author : GNU Project
> * URL : https://www.gnu.org/software/auctex/
> * License : GPL v3
>   Description : AUCTeX version 12, LaTeX environment for Emacs
>
> Hello,
>
> This is not truly an ITP but a request for guidance.

ITP is truly not the right one for this. And this should be merged with #896844.

> auctex v11.91 already exists in Debian, and has not been updated since
> 2018 despite bug reports requesting that.  Specifically, the preview-latex
> feature no longer works due to changes in ghostscript, which is solved in
> upstream.

Looks like there are multiple users who are saying its unusable.

>
> The relevant bug #896844 was filed in Apr 2018, the maintainer said "I'll
> work on it" and nothing ever happened since, depite numerous follow-ups to
> the bug.  I tried to contact him directly in early 2020, getting no useful
> reply, except that he considers that he is still maintaining the package.
>
> I am not a Debian developper, but am able to package (in fact I have packaged
> auctex v12 for personal use).
>
> What should / can be done in this case ?

You have auctex/12.2-0.4 which doesn't make sense for Debian. So,
create a package for auctex/12.2-0.1, also add the fix for #951973 to
it. And then take a look at https://mentors.debian.net/ about how to
upload and find a sponsor.


-- 
Regards
Sudip

Bug#968404: liblxc1 is hardwired to systemd or cgroupv1

[Harald Dunkel]

Package: liblxc1
Version: 1:4.0.2-1

Apparently I have to install either systemd or cgroupfs-mount for
liblxc1. Since cgroupfs-mount doesn't support cgroupv2 (#959021, set
to wontfix), I am stuck. A line like

cgroup2 /sys/fs/cgroup  cgroup2 defaults

in /etc/fstab would do.

Do you think it would be possible to move "cgroupfs-mount | systemd"
to Recommends for liblxc1 (if it can't be dropped altogether)?


Regards
Harri

Bug#911560: Testing Various delays

[Nicolas Dufresne]

As asked over IRC, I have tested various TX_DELAY on Lime2 rev K.

- 2, 3, and 4 was good enough to succeed a DHCP handshake.

- 0 and 1 made the request to never be seen over the network.

An obvious next step would be to test again with large file transfer,
perhaps a kernel image. I will report back.

regards,
Nicolas

Bug#968382: element-desktop: /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied

[Reiner Herrmann]

Control: forwarded -1 https://github.com/netblue30/firejail/issues/3586

On Fri, Aug 14, 2020 at 07:57:00PM +0200, Hans-Christoph Steiner wrote:
> Adding this to element-desktop.profile made the Permission denied error
> go away, but it still didn't start:
> 
> whitelist /var/lib/flatpak/exports/share/dconf/profile/user
> 
> 
> So it seems the /dev/shm error is the notable one. I tried adding
> "ignore nodbus" at the end of element-desktop.profile, at the beginning
> of element-desktop.profile, and both. None of those changed the /dev/shm
> error. And Element never started.

Hm, that is weird, as I also have the same error about /dev/shm, but for
me element is starting (at least it shows a tray icon, and I can open
the main window; though it stays white (probably for a different reason
as it behaves the same without firejail)).

I initially had the problem that the tray icon was not shown because of
nodbus, maybe due to some other reason your WM/DE does not show the tray
icon...

Otherwise I'm currently out of ideas where the problem could be.

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#968397: dpkg: package bug script exits with 256 on reportbug

[Guillem Jover]

Control: found -1 1.20.1

Hi!

On Fri, 2020-08-14 at 10:00:23 -0400, The Wanderer wrote:
> Package: dpkg
> Version: 1.20.5
> Severity: normal

> When I attempt to file a bug report against dpkg with reportbug, I get
> the following output:
> 
> 
> The package bug script /usr/share/bug/dpkg exited with an error status
> (return code = 256). Do you still want to file a report? [y|N|q|?]?

Oh, so I guess this is due to you not having a tainted usr-merged system
and the readlink failing, due to some recent refactoring. I'll fix that.

> It is not clear whether this reflects a problem that will manifest
> itself in the resulting bug report, but at the minimum, it is clearly
> suboptimal UX. If it does reflect a real problem, that problem should be
> fixed; if it does not, it should be streamlined so that this notice does
> not appear in routine bug-report attempts.

This would be reportbug noticing that the bug script failed and
reporting that.

> As things stand, I have another bug report which I would like to file
> (which might belong either to dpkg or to locales-all, or even somewhere
> else I can't identify at a glance, but I think fits dpkg as the most
> likely candidate) which is on hold because of this.

I assume that until the problem has been fixed in the bug-script, just
replying 'y' would do.

> I'm not sure where to look on my system for anything that might be
> contributing to the problem; I've already checked the script itself, and
> tried running various commands and scripts based on what I find there,
> without reproducing the 256 exit code as of yet. If there's anything I
> can do to help track this down, don't hesitate to ask.

The 256 would usually come from the return code of something like a
system() call (originally from something like wait(2)), where the code
would need to mask the value to get the actual command's exit status.

Thanks,
Guillem

Bug#968382: element-desktop: /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied

[Hans-Christoph Steiner]

Adding this to element-desktop.profile made the Permission denied error
go away, but it still didn't start:

whitelist /var/lib/flatpak/exports/share/dconf/profile/user


So it seems the /dev/shm error is the notable one. I tried adding
"ignore nodbus" at the end of element-desktop.profile, at the beginning
of element-desktop.profile, and both. None of those changed the /dev/shm
error. And Element never started.

Bug#968403: numbers.test fails on i386

[Matthias Klose]

Package: src:guile-3.0
Version: 3.0.4-1
Severity: serious
Tags: sid bullseye

only seen on i386, not on other architectures.

[...]
Running numbers.test
FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: (130.0 
10/7)
FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: (130.0
-10/7)
FAIL: numbers.test: Number-theoretic division: floor/: mixed types: (130.0 10/7)
FAIL: numbers.test: Number-theoretic division: floor/: mixed types: (-130.0 
-10/7)
FAIL: numbers.test: Number-theoretic division: ceiling/: mixed types: (130.0 
-10/7)
FAIL: numbers.test: Number-theoretic division: ceiling/: mixed types: (-130.0 
10/7)
FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0 
10/7)
FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0 
-10/7)
FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (-130.0 
10/7)
FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (-130.0
-10/7)

Bug#968372: sylpheed: crash on startup

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce it inside a i386 VM and found the crash
happens in [1], when it tries to dereference the "state".

This state is retrieved from the renderer of type _PangoRendererPrivate.


I tried to follow where this state is last set and found
this memory is last written in location [2].

But here this memory is used as _GdkPangoRendererPrivate,
which looks quite different.


Kind regards,
Bernhard



[1]
(rr) bt
#0  0xb7391ebf in handle_line_state_change 
(part=PANGO_RENDER_PART_OVERLINE, renderer=0x10470c0) at 
../pango/pango-renderer.c:315
#1  pango_renderer_part_changed (renderer=0x10470c0, 
part=PANGO_RENDER_PART_OVERLINE) at ../pango/pango-renderer.c:1414
#2  0xb7392194 in pango_renderer_set_alpha (renderer=0x10470c0, 
part=PANGO_RENDER_PART_OVERLINE, alpha=0) at ../pango/pango-renderer.c:1357
#3  0xb7392335 in pango_renderer_default_prepare_run (renderer=0x10470c0, 
run=0xf55a98) at ../pango/pango-renderer.c:1525
#4  0xb756b7cd in gdk_pango_renderer_prepare_run (renderer=0x10470c0, 
run=0xf55a98) at ../../../../gdk/gdkpango.c:456
#5  0xb73925f9 in pango_renderer_prepare_run (run=0xf55a98, 
renderer=0x10470c0) at ../pango/pango-renderer.c:1435
#6  pango_renderer_draw_layout_line (renderer=0x10470c0, line=0xf50e08, 
x=34816, y=51200) at ../pango/pango-renderer.c:611
...

(rr) list
296 handle_line_state_change (PangoRenderer  *renderer,
297   PangoRenderPart part)
298 {
299   LineState *state = renderer->priv->line_state;
...
314
315   if (part == PANGO_RENDER_PART_OVERLINE &&
316   state->overline != PANGO_OVERLINE_NONE)
317 {


https://sources.debian.org/src/pango1.0/1.46.0-1/pango/pango-renderer.c/#L315


[2]
(rr) bt
#0  gdk_pango_renderer_prepare_run (renderer=0x10470c0, run=0xf55a98) at 
../../../../gdk/gdkpango.c:443
#1  0xb73925f9 in pango_renderer_prepare_run (run=0xf55a98, 
renderer=0x10470c0) at ../pango/pango-renderer.c:1435
#2  pango_renderer_draw_layout_line (renderer=0x10470c0, line=0xf50e08, 
x=34816, y=51200) at ../pango/pango-renderer.c:611
#3  0xb739301d in pango_renderer_draw_layout (renderer=0x10470c0, 
layout=0xf379f0, x=34816, y=37888) at ../pango/pango-renderer.c:197
...

(rr) list
441   if (embossed != gdk_renderer->priv->embossed)
442 {
443   gdk_renderer->priv->embossed = embossed;
444   changed = TRUE;
445 }

https://sources.debian.org/src/gtk+2.0/2.24.32-4/gdk/gdkpango.c/#L443

# Unstable i386 qemu VM 2020-08-14

apt update
apt dist-uprade


apt install systemd-coredump sddm xserver-xorg openbox xterm gdb git sylpheed 
sylpheed-dbgsym libgtk2.0-0-dbgsym libglib2.0-0-dbgsym libpango-1.0-0-dbgsym
apt build-dep rr


echo 1 > /proc/sys/kernel/perf_event_paranoid




mkdir /home/benutzer/source/libpango-1.0-0/orig -p
cd/home/benutzer/source/libpango-1.0-0/orig
apt source libpango-1.0-0
cd

mkdir /home/benutzer/source/libgtk2.0-0/orig -p
cd/home/benutzer/source/libgtk2.0-0/orig
apt source libgtk2.0-0
cd





$ export DISPLAY=:0
$ sylpheed 
Speicherzugriffsfehler (Speicherabzug geschrieben)


# dmesg
...
[   29.789450] sylpheed[992]: segfault at 2d ip b73e0ebf sp bf890760 error 4 in 
libpango-1.0.so.0.4600.0[b73bd000+29000]
[   29.789458] Code: c4 10 83 c4 1c 5b 5e 5f 5d c3 90 8b 4e 18 85 c9 7e 79 8b 
46 20 8b 78 44 85 ff 74 4f 83 fd 02 74 7a 83 fd 04 0f 85 b1 00 00 00 <8b> 47 2c 
89 44 24 08 85 c0 74 36 8b 4f 40 8b 57 30 c7 47 2c 00 00


# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Fri 2020-08-14 18:33:29 CEST992  1000  1000  11 present   /usr/bin/sylpheed

# coredumpctl gdb 992
   PID: 992 (sylpheed)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Fri 2020-08-14 18:33:29 CEST (2min 10s ago)
  Command Line: sylpheed
Executable: /usr/bin/sylpheed
 Control Group: /user.slice/user-1000.slice/session-6.scope
  Unit: session-6.scope
 Slice: user-1000.slice
   Session: 6
 Owner UID: 1000 (benutzer)
   Boot ID: 4c238d8aaaba40d19b8c886c81502ce0
Machine ID: 45f49504b47f4e5690bc479adf67aa5b
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.sylpheed.1000.4c238d8aaaba40d19b8c886c81502ce0.992.1597422809.zst
   Message: Process 992 (sylpheed) of user 1000 dumped core.

Stack trace of thread 992:
#0  0xb73e0ebf pango_renderer_part_changed 
(libpango-1.0.so.0 + 0x2debf)
#1  0xb73e1194 pango_renderer_set_alpha 
(libpango-1.0.so.0 + 0x2e194)
#2  0xb73e1335 n/a (libpango-1.0.so.0 + 0x2e335)
#3  0xb75ba7cd n/a (libgdk-x11-2.0.so.0 + 0x247cd)
#4  0xb73e15f9 pango_renderer_draw_layout_line 
(libpango-1.0.so.0 + 0x2e5f9)

Bug#968327: systemtap: FTBFS: uses %lu to print rlim_t which can be unsigned long long though

[Frank Ch. Eigler]

Hi -

> +  * debian/patches/rlim_t.patch: fix FTBFS: bad rlim_t assumptions
> +
> + -- Thorsten Glaser   Thu, 13 Aug 2020 04:03:51 +0200

We merged an embiggened version of your patch to upstream master, thanks!

- FChE

Bug#968371: Info received (Bug#968371: Acknowledgement (mailman3: NNTP Gateway'ing fails and causes message to not go out via email either))

[Athanasius]

  It was only 3 commits necessary to fix this, but one of them needs
further adjustment.

  The upstream commits in question are:


59d8b47c432e43ce463cbb4a7aec649415d08702
e4d9e5202158f9b32bb985167d7dedd9e9edc263
05d608645cfa47f7150585663e9f2d6aa5688db2

But e4d9e5202158f9b32bb985167d7dedd9e9edc263 then runs into an extra
problem where the Debian INN2 doesn't like header wrapping when a post
is being made in READER mode.  This might itself be an INN2 bug.
RFC 3977 section A.1 does say that header wrapping should work over
NNTP, but perhaps READER mode counts as nn*r*p instead and follows
different rules?

So I've instead ended up using a tweaked patch that forces the
max_line_length to 'None' for no wrapping.

I've attached the three extra patch files that I'm now using.

-- 
- Athanasius = Athanasius(at)miggy.org / https://miggy.org/
  GPG/PGP Key: https://miggy.org/gpg-key
   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
commit 59d8b47c432e43ce463cbb4a7aec649415d08702
Author: Mark Sapiro 
Date:   Sun Jun 23 01:52:23 2019 +

Removed the last remnants of the mailing list attribute nntp_host.

diff --git a/src/mailman/core/tests/test_pipelines.py b/src/mailman/core/tests/test_pipelines.py
index 7c87c4877..7ce778134 100644
--- a/src/mailman/core/tests/test_pipelines.py
+++ b/src/mailman/core/tests/test_pipelines.py
@@ -180,7 +180,6 @@ testing
 # Set up NNTP.
 self._mlist.gateway_to_news = True
 self._mlist.linked_newsgroup = 'testing'
-self._mlist.nntp_host = 'news.example.com'
 # Process the email.
 process(self._mlist, self._msg, {},
 pipeline_name='default-posting-pipeline')
diff --git a/src/mailman/docs/NEWS.rst b/src/mailman/docs/NEWS.rst
index ba8d7cdf9..bace916c7 100644
--- a/src/mailman/docs/NEWS.rst
+++ b/src/mailman/docs/NEWS.rst
@@ -18,6 +18,12 @@
 =
 (2019-02-22)
 
+Debian Cherry-Pick
+--
+
+* The last remnants of the mailing list attribute ``nntp_host`` have been
+  removed.  (Closes #611)
+
 Command line
 
 * The ``mailman import21`` command properly converts all acceptable_aliases
diff --git a/src/mailman/handlers/docs/nntp.rst b/src/mailman/handlers/docs/nntp.rst
index 72bcb35f0..233bbd255 100644
--- a/src/mailman/handlers/docs/nntp.rst
+++ b/src/mailman/handlers/docs/nntp.rst
@@ -44,12 +44,11 @@ Neither are digests ever gated to the newsgroup.
 []
 
 However, other posted messages get gated to the newsgroup via the nntp queue.
-The list owner can set the linked newsgroup and the nntp host that its
-messages are gated to.
+The list owner can set the linked newsgroup.  The nntp host that messages are
+gated to is a global configuration.
 ::
 
 >>> mlist.linked_newsgroup = 'comp.lang.thing'
->>> mlist.nntp_host = 'news.example.com'
 >>> handler.process(mlist, msg, {})
 >>> messages = get_queue_messages('nntp')
 >>> len(messages)
diff --git a/src/mailman/handlers/to_usenet.py b/src/mailman/handlers/to_usenet.py
index 4e66b8e99..3dbf91bf1 100644
--- a/src/mailman/handlers/to_usenet.py
+++ b/src/mailman/handlers/to_usenet.py
@@ -50,8 +50,6 @@ class ToUsenet:
 error = []
 if not mlist.linked_newsgroup:
 error.append('no newsgroup')
-if not mlist.nntp_host:
-error.append('no NNTP host')
 if error:
 log.error('NNTP gateway improperly configured: %s',
   COMMASPACE.join(error))
diff --git a/src/mailman/styles/base.py b/src/mailman/styles/base.py
index 92168ed97..e95423484 100644
--- a/src/mailman/styles/base.py
+++ b/src/mailman/styles/base.py
@@ -92,7 +92,6 @@ class BasicOperation:
 mlist.dmarc_moderation_notice = ''
 mlist.dmarc_wrapped_message_text = ''
 # NNTP gateway
-mlist.nntp_host = ''
 mlist.linked_newsgroup = ''
 mlist.gateway_to_news = False
 mlist.gateway_to_mail = False
commit e4d9e5202158f9b32bb985167d7dedd9e9edc263
Author: Mark Sapiro 
Date:   Thu Jun 27 15:52:58 2019 +

Fixed nntp runner to use BytesIO rather than StringIO.

diff --git a/src/mailman/docs/NEWS.rst b/src/mailman/docs/NEWS.rst
index 33920ec8d..2f6f041a4 100644
--- a/src/mailman/docs/NEWS.rst
+++ b/src/mailman/docs/NEWS.rst
@@ -23,6 +23,8 @@
 
 * The last remnants of the mailing list attribute ``nntp_host`` have been
   removed.  (Closes #611)
+* Fixed the nntp runner which was calling the ``nntplib.NNTP.post()`` method
+  with a string object instead of bytes.  (Closes #613)
 
 Command line
 
diff --git a/src/mailman/runners/nntp.py b/src/mailman/runners/nntp.py
index 36ef2e3a1..580d22ff9 100644
--- a/src/mailman/runners/nntp.py
+++ b/src/mailman/runners/nntp.py
@@ -23,7 +23,7 @@ import socket
 import logging
 import nntplib
 
-from io import StringIO
+from io import BytesIO
 from mailman.config import config
 from mailman.core

Bug#966020: Fixed in 3.9.0

[Daniel Leidert]

This has been fixed upstream by version 3.9.0
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966020

Uploading this will also fix #961194.

Regards, Daniel
-- 
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#966087: libreoffice-writer: Cannot save file: General input/output error

[frydo bugdeb]

I seriously believe your "32bit computer" is a 64bit-able computer where
one didn't install/maintain it properly by (re)installing it with  a 64
bit *operating system*.

Definitely not.


> libreoffice calc saves files, but I have a file for which I got a
> message that some attributes could not be read (but I don't know how
> to find which ones).

Any specialities? File System? If you know that you have a file there
you can probably give more information?

I forgot to add that this error appears while loading file.

I have no idea if I can join a file with my message, but I try here to join one.
It is not minimal, but it's very small.


> This error does not appear on my 64bit computer.

Another reason to use something sensible.

Things begin to be hard for 32bit computers...


file.ods
Description: application/vnd.oasis.opendocument.spreadsheet

Bug#966215: mystiq: Please also enable build on other architectures

[Pablo Mestre]

Hi Boyuan,

Sorry fo the late on the reply. I upate the repoitory and solve the bug.

Now im waiting for a DD upload the binary.

Regards,

Pablo

El 8/14/20 a las 11:31 AM, Boyuan Yang escribió:
> X-Debbugs-CC: pmdc...@gmail.com
>
> On Tue, 28 Jul 2020 14:28:05 -0300 Pablo Mestre 
> wrote:
>> Hi,
>>
>> I will check this and update the package.
>>
>> Thanks for the notice.
> Hi Pablo,
>
> Is there any progress on it? I believe the fix would be just a one-
> liner change by replacing "amd64" with "any".
>
> Let me know if you need help applying this change. I can also provide a
> non-maintainer upload if you find it okay.
>
-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.




signature.asc
Description: OpenPGP digital signature

Bug#966217: mystiq: Consider having package team-maintained in Debian Multimedia Team

[Pablo Mestre]

Hi Boyuan,

Sorry fo the late on the reply. I upate the repoitory and solve the bug.

Now im waiting for a DD upload the binary.

Regards,

Pablo

El 7/24/20 a las 4:21 PM, Boyuan Yang escribió:
> Source: mystiq
> Version: 20.03.23-1
> Severity: wishlist
>
> Dear Debian mystiq package maintainer,
>
> I believe mystiq is worthwhile to be team-maintained under Debian Multimedia
> Team (https://wiki.debian.org/DebianMultimedia). You may further read this
> Debian Wiki page on how the Multimedia Team works.
>
> If you are willing to have this package team-maintained in the multimedia-
> team, you are welcome to put "Debian Multimedia Maintainers <
> debian-multime...@lists.debian.org>" into the maintainer field or the
> uploaders field in your package. There is no need to further move the git
> packaging repo on Salsa GitLab since the current git repo can be made to be
> grant write permission to the multimedia-team members if necessary.
>
> Thanks,
> Boyuan Yang

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.




signature.asc
Description: OpenPGP digital signature

Bug#962972: firmware-realtek: missing files in 20200619-1

[Michał Mirosław]

Package: firmware-realtek
Version: 20200619-1

In newer source tar there are firmware files for more chips than what is
packed into deb. Eg rtl8153a-3.fw is missing.

$ dpkg -l firmware-realtek
[...]
ii  firmware-realtek 20200619-1   all  Binary firmware for Realtek 
wired/wifi/BT adapters

$ tar tJf firmware-nonfree_20200619.orig.tar.xz|grep rtl_nic/rtl|wc -l
28

$ ls /lib/firmware/rtl_nic/|wc -l
24

Best Regards
Michał Mirosław

Bug#968396: wireguard-dkms: kernel module fails to build

[Thomas K.]

Package: wireguard-dkms
Version: 0.0.20200128-1
Severity: normal

root@rpi4:~# dpkg-reconfigure wireguard-dkms
--
Deleting module version: 0.0.20200128
completely from the DKMS tree.
--
Done.
Loading new wireguard-0.0.20200128 DKMS files...
It is likely that 5.4.51-v7l+ belongs to a chroot's host
Building for 5.4.51+, 5.4.51-v7+, 5.4.51-v7l+ and 5.4.51-v8+
Building initial module for 5.4.51+
Error! Bad return status for module build on kernel: 5.4.51+ (armv7l)
Consult /var/lib/dkms/wireguard/0.0.20200128/build/make.log for more
information.

root@rpi4:~# cat /var/lib/dkms/wireguard/0.0.20200128/build/make.log
DKMS make.log for wireguard-0.0.20200128 for kernel 5.4.51+ (armv7l)
Fri 14 Aug 2020 03:02:58 PM EEST
make: Entering directory '/usr/src/linux-headers-5.4.51+'
  AR  /var/lib/dkms/wireguard/0.0.20200128/build/built-in.a
  CC [M]  /var/lib/dkms/wireguard/0.0.20200128/build/main.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20200128/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20200128/build/device.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20200128/build/peer.o
In file included from /var/lib/dkms/wireguard/0.0.20200128/build/noise.c:10:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h: In function
‘wg_reset_packet’:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h:100:2: error:
implicit declaration of function ‘skb_reset_tc’; did you mean
‘skb_reserve’? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~
  skb_reserve
In file included from /var/lib/dkms/wireguard/0.0.20200128/build/device.c:6:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h: In function
‘wg_reset_packet’:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h:100:2: error:
implicit declaration of function ‘skb_reset_tc’; did you mean
‘skb_reserve’? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~
  skb_reserve
In file included from /var/lib/dkms/wireguard/0.0.20200128/build/peer.c:8:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h: In function
‘wg_reset_packet’:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h:100:2: error:
implicit declaration of function ‘skb_reset_tc’; did you mean
‘skb_reserve’? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~
  skb_reserve
In file included from /var/lib/dkms/wireguard/0.0.20200128/build/main.c:9:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h: In function
‘wg_reset_packet’:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h:100:2: error:
implicit declaration of function ‘skb_reset_tc’; did you mean
‘skb_reserve’? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~
  skb_reserve
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266:
/var/lib/dkms/wireguard/0.0.20200128/build/main.o] Error 1
make[1]: *** Waiting for unfinished jobs
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266:
/var/lib/dkms/wireguard/0.0.20200128/build/peer.o] Error 1
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266:
/var/lib/dkms/wireguard/0.0.20200128/build/device.o] Error 1
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266:
/var/lib/dkms/wireguard/0.0.20200128/build/noise.o] Error 1
make: *** [Makefile:1709: /var/lib/dkms/wireguard/0.0.20200128/build]
Error 2
make: Leaving directory '/usr/src/linux-headers-5.4.51+'

root@rpi4:~# uname -a
Linux rpi4 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l
GNU/Linux
root@rpi4:~# apt show libc6 | grep ^Version
Version: 2.28-10+rpi1

TBH, I'm not sure if it's right that I've submitted the bug here. Since
it's a "Raspbian" system.

-- 
Thomas K.
https://pebkac.gr

Bug#968226: Build-Depends-If-Available

[Wouter Verhelst]

On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> 
> > -policy: this is a question that has come up before
> > (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another
> > example that springs to mind, but I'm pretty sure there are more), so I
> > think we should document in Policy that a) buildd only looks at the
> > first dependency in alternative build-dependencies, and b) why this is
> > the case.
> 
> Policy already says:
> 
> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit
> the use of alternative dependencies, these are not normally used by
> the Debian autobuilders. To avoid inconsistency between repeated
> builds of a package, the autobuilders will default to selecting the
> first alternative, after reducing any architecture-specific
> restrictions for the build architecture in question. While this may
> limit the usefulness of alternatives in a single release, they can
> still be used to provide flexibility in building the same package
> across multiple distributions or releases, where a particular
> dependency is met by differently named packages.
> 
> in 7.1.  However, it's hidden in a footnote.  Perhaps we should make it
> more prominant (and make it clear that it's normative), and tweak the
> wording.

Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
(probably after debconf though)

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#968401: partman-efi version 85: fstab/efi is missing the executable flag

[Pete Batard]

Package: partman-efi
Severity: important
Tags: d-i

Logging a bug against this, since it's a rather important issue.

https://salsa.debian.org/installer-team/partman-efi/-/commit/1a096e6ede94cce8e5272e31946a506ae7f611e7.patch 
had the rather unfortunate side effect of removing the +x attribute from 
fstab/efi.


Combined with finish.d/20mount_partitions using a loop that checks for 
the executable flag before running the scripts from fstab.d:


for i in /lib/partman/fstab.d/*; do
[ -x "$i" ] || continue
$i
done |

this effectively means that fstab/efi is no longer executed.

A patch has been submitted in:
https://salsa.debian.org/installer-team/partman-efi/-/merge_requests/2

Regards,

/Pete

Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )

[Bernhard Übelacker]

Dear Maintainer,

encountered again such a crash of a bash that was started
while the old libc6 was installed, then installed a libc6 update,
and then the "old" bash crashed after a tab completion.

libc6:amd64 (2.30-8, 2.31-3)
bash:amd64 (5.0-6, 5.0-7)

Kind regards,
Bernhard


$ cp log*** stack smashing detected ***:  terminated
Connection to ... closed.

# coredumpctl gdb
   PID: 4738 (bash)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Fri 2020-08-14 17:50:14 CEST (37s ago)
  Command Line: -bash
Executable: /usr/bin/bash

Stack trace of thread 4738:
#0  0x7f4c0d38e781 n/a 
(/usr/lib/x86_64-linux-gnu/libc-2.30.so (deleted) + 0x3b781)
#1  0x7f4c0d45fd7d n/a 
(/usr/lib/x86_64-linux-gnu/libc-2.30.so (deleted) + 0x10cd7d)

Bug#968375: scottfree: Crashes when restoring save file

[Bernhard Übelacker]

Dear Maintainer,
this fault is caused by a wrong format in a call to fscanf.

Attached a patch to fix this and remove two other warnings.

Kind regards,
Bernhard

# Bullseye/testing amd64 qemu VM 2020-08-14


apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm unzip mc fakeroot 
quilt gdb rr scottfree scottfree-dbgsym
apt build-dep scottfree

echo 1 > /proc/sys/kernel/perf_event_paranoid



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


wget 
http://www.ifarchive.org/if-archive/scott-adams/games/scottfree/AdamsGames.zip
unzip AdamsGames.zip -d AdamsGames
cd AdamsGames/



##


export DISPLAY=:0
scottfree adv01.dat


Tell me what to do ? SAVE GAME
OK
Filename: test.sav

Saved.

Tell me what to do ? QUIT
I've stored 0  treasures.  On a scale of 0 to 100, that rates 0 .
The game is now over.



##


$ scottfree adv01.dat test.sav
*** stack smashing detected ***:  terminated
 Abgebrochen (Speicherabzug 
geschrieben)




$ gdb -q --args scottfree adv01.dat test.sav
Reading symbols from scottfree...Reading symbols from 
/usr/lib/debug/.build-id/41/565267f3552c9b645ec125e201ac393874a90f.debug...done.
done.
(gdb) directory /home/benutzer/source/scottfree/orig/scottfree-1.14
Source directories searched: 
/home/benutzer/source/scottfree/orig/scottfree-1.14:$cdir:$cwd
(gdb) run
Starting program: /usr/games/scottfree adv01.dat test.sav
*** stack smashing detected ***:  terminated

 Program received signal 
SIGABRT, Aborted.

  __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77dcd535 in __GI_abort () at abort.c:79
#2  0x77e24508 in __libc_message (action=, 
fmt=fmt@entry=0x77f2f07b "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:181
#3  0x77eb580d in __GI___fortify_fail_abort 
(need_backtrace=need_backtrace@entry=false, msg=msg@entry=0x77f2f059 "stack 
smashing detected") at fortify_fail.c:28
#4  0x77eb57c2 in __stack_chk_fail () at stack_chk_fail.c:29
#5  0x73e3 in LoadGame (name=) at ScottCurses.c:708
#6  0x5812 in main (argc=3, argv=0x7fffe578) at 
ScottCurses.c:1393
(gdb) up
#1  0x77dcd535 in __GI_abort () at abort.c:79
79  abort.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
#2  0x77e24508 in __libc_message (action=, 
fmt=fmt@entry=0x77f2f07b "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:181
181 ../sysdeps/posix/libc_fatal.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
#3  0x77eb580d in __GI___fortify_fail_abort 
(need_backtrace=need_backtrace@entry=false, msg=msg@entry=0x77f2f059 "stack 
smashing detected") at fortify_fail.c:28
28  fortify_fail.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
#4  0x77eb57c2 in __stack_chk_fail () at stack_chk_fail.c:29
29  stack_chk_fail.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
#5  0x73e3 in LoadGame (name=) at ScottCurses.c:708
warning: Source file is more recent than executable.
708 }




##


$ rr scottfree adv01.dat test.sav
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/scottfree-0'.
*** stack smashing detected ***:  terminated
 Abgebrochen



$ rr replay /home/benutzer/.local/share/rr/scottfree-0
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/games/scottfree...Reading symbols from 
/usr/lib/debug/.build-id/41/565267f3552c9b645ec125e201ac393874a90f.debug...done.
done.
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Remote debugging using 127.0.0.1:4913
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/.build-id/f2/5dfd7b95be4ba386fd71080accae8c0732b711.debug...done.
done.
0x7f5521117090 in _start () from /li

Bug#968219: ITP: openpbs -- An HPC workload manager and job scheduler for desktops, clusters, and clouds.

[Wouter Verhelst]

On Tue, Aug 11, 2020 at 03:28:30AM +, Mo Zhou wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Mo Zhou 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: openpbs
>   Version : 20.0.1
>   Upstream Author : Name 
> * URL : http://www.example.org/
> * License : AGPL-3
>   Programming Lang: C, python, shell
>   Description : An HPC workload manager and job scheduler for desktops, 
> clusters, and clouds.
> 
> I'm wondering why it is absent in debian.

My guess: slurm and gridengine exist in Debian and are "good enough",
whereas PBS has been going through some upstream switches/forks a few
times over the past few years?

Could be my misunderstanding though.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#709820: [dictd] Lacks IPv6 support

[Kevin Otte]

New upstream release now has support for IPv6.

https://sourceforge.net/projects/dict/files/dictd/dictd-1.13.0/

  dictd:
 * add support for IPv6 (the default is IPv4)
- Add global configuration option "address_family" and
   command line options --address-family
- Options "listen_to" and --listen-to accepts host name
   in addition to IP address, "*" means "bind to all interfaces".

  dict:
 * add support for IPv6.
- New command line options -4 and -6.
- dict + dict:// URL: add support for IPv6 address
   surrounded by [ and ] symbols

Bug#968400: cockpit-ws: Warning on upgrades

[Cesare Leonardi]

Package: cockpit-ws
Version: 225-1
Severity: normal

Hello.
For several cockpit releases, on every package upgrade there are two
repeated messages:
--
Setting up cockpit-ws (225-1) ...
Warning: The home dir /nonexisting you specified can't be accessed: No such 
file or directory
The system user `cockpit-ws' already exists. Exiting.
Warning: The home dir /nonexisting you specified can't be accessed: No such 
file or directory
The system user `cockpit-wsinstance' already exists. Exiting.
--

Leaving behind the cockpit-ws user already exists message (I guess it
could be silenced with a test), the /nonexisting warning is what caught
my attention. Not because it doesn't exists but because Debian seems to
use a similar but different path for the same purpose. For example on
my system I see that:
--
# cat /etc/passwd | grep nonexist
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:118:65534::/nonexistent:/bin/false
debian-h2o:x:119:135::/nonexistent:/usr/sbin/nologin
tcpdump:x:121:140::/nonexistent:/usr/sbin/nologin
libvirtdbus:x:999:999::/nonexistent:/usr/sbin/nologin
cockpit-ws:x:117:131::/nonexisting:/usr/sbin/nologin
cockpit-wsinstance:x:125:142::/nonexisting:/usr/sbin/nologin
--

Look, here cockpit is the only one using /nonexisting as home path.
I don't know if there are any Debian policies talking about this path
and its usage but from what I see, cockpit seems to deviate from the
rest of the system.

Cesare.


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

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

Versions of packages cockpit-ws depends on:
ii  adduser 3.118
ii  glib-networking 2.64.3-2
ii  libc6   2.31-3
ii  libcrypt1   1:4.4.16-1
ii  libglib2.0-02.64.4-1
ii  libgnutls30 3.6.14-2+b1
ii  libgssapi-krb5-21.17-10
ii  libjson-glib-1.0-0  1.4.4-2
ii  libkrb5-3   1.17-10
ii  libpam0g1.3.1-5
ii  libsystemd0 246-2
ii  openssl 1.1.1g-1
ii  systemd 246-2

cockpit-ws recommends no packages.

Versions of packages cockpit-ws suggests:
pn  sssd-dbus  

-- no debconf information

Bug#934395:

[sylvia]

Beste, ik schreef je voordat het me verbaast dat je niet reageerde, schrijf
me nu alstublieft terug

Bug#968399: pyxdg ftbfs, test failure

[Matthias Klose]

Package: src:pyxdg
Version: 0.26-3
Severity: serious
Tags: sid bullseye

seen in unstable, in the build, and in the autopkg tests:

[...]
==
ERROR: test_rule_from_node (test-menu-rules.RulesTest)
--
Traceback (most recent call last):
  File
"/packages/tmp/pyxdg-0.26/.pybuild/cpython3_3.8_xdg/build/test/test-menu-rules.py",
line 166, in test_rule_from_node
rule = parser.parse_rule(root)
  File "/packages/tmp/pyxdg-0.26/.pybuild/cpython3_3.8_xdg/build/xdg/Menu.py",
line 768, in parse_rule
return Rule(type, tree)
  File "/packages/tmp/pyxdg-0.26/.pybuild/cpython3_3.8_xdg/build/xdg/Menu.py",
line 421, in __init__
self.code = compile(self.expression, '', 'eval')
ValueError: Name node can't be used with 'False' constant

--
Ran 55 tests in 2.178s

FAILED (errors=1)
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd
/packages/tmp/pyxdg-0.26/.pybuild/cpython3_3.8_xdg/build; python3.8 -m nose -v 
test
dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8
returned exit code 13
make: *** [debian/rules:7: build] Error 25

Bug#968398: ITP: stegcracker -- steganography brute-force tool

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: stegcracker
  Version : 2.0.9
  Upstream Author : Luke Paris (Paradoxis) 
* URL : https://github.com/Paradoxis/StegCracker
* License : Expat
  Programming Lang: Python
  Description : steganography brute-force tool

StegCracker is steganography brute-force utility to uncover hidden data inside
files.

Bug#966215: mystiq: Please also enable build on other architectures

[Boyuan Yang]

X-Debbugs-CC: pmdc...@gmail.com

On Tue, 28 Jul 2020 14:28:05 -0300 Pablo Mestre 
wrote:
> Hi,
> 
> I will check this and update the package.
> 
> Thanks for the notice.

Hi Pablo,

Is there any progress on it? I believe the fix would be just a one-
liner change by replacing "amd64" with "any".

Let me know if you need help applying this change. I can also provide a
non-maintainer upload if you find it okay.

-- 
Regards,
Boyuan Yang


> El 7/24/20 a las 4:15 PM, Boyuan Yang escribió:
> > Source: mystiq
> > Version: 20.03.23-1
> > Severity: minor
> >
> > Dear Debian mystiq maintainer,
> >
> > Thanks for maintaining package mystiq in Debian. I noticed that
this software
> > was instructed to only build on amd64 architecture. Ideally this
package
> > should be built on any architecture currently supported by Debian,
not only
> > limited to amd64. Is there any specific need in the package that
can only be
> > achieved on amd64?
> >
> > If the software can function well on other hardware architectures,
please
> > consider enabling build for them. This can be done by using
"Architecture:
> > any" instead of "Architecture: amd64" in debian/control file.
> >
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
>   ⣾⠁⢠⠒⠀⣿⡁  --
>   ⢿⡄⠘⠷⠚⠋   https://debian.org
>   ⠈⠳⣄  Debian, the universal operating system.
> 
> 


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

Bug#962668: same error

[Michael Meier]

I've got exactly the same error (the one with the surrogates not 
allowed) with way too many PDFs. Already since months, always using the 
newest calibre version in testing.

Now I've just installed the official version as described in
https://calibre-ebook.com/download_linux
and that version does the conversion without any problems. So the 
problem must be in the debian package.

Bug#968295: Resolution

[Andrew]

Downloaded Debian LiveCD image (debian-10.5.0-amd64-xfce-CD-1.iso from 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/)


Boot to Debian LiveCD -> (Advanced Mode) -> Graphical Rescue Mode

Skip network setup (I did not have drivers for my hardware, we'll be 
copying the files on USB stick needed to fix) -> proceed to mount 
partitions providing the LVM Passphrase for Full Disk Encryption.


Select the "acerv3-575t-vg/root" to mount a shell too, ensure to select 
"yes" to mount the "/boot" partition.


Successfully logged into my root file system /dev/acerv3-575t-vg/root 
via live CD in rescue mode & mounted the seperate /boot partition, am 
sitting on a shell with /dev/acerv3-575t-vg/root mounted on "/"




#checking packages

dpkg -l cryptsetup lvm2

#result:
#dpkg-query: error: failed to open package info file 
'/var/lib/dpkg/status' for reading: no such file or directory


#(my /var /tmp /home are seperate LV of the VG acerv3-575t-vg)

#had to issue "mount -a" to mount the other LV's (/var /tmp /home).


#now doing
dpkg -l cryptsetup lvm2
#returns results:
# rc cryptsetup 2:2.1.0-5+deb10u2 all
# ii lvm2 2.03.02-3 amd64

#(ii indicator for lvm2 indicates its  rc indicator for cryptsetup 
indicates !
#must seek to reinstall cyptsetup, but also cryptsetup-initramfs (both 
packages) since issue is on boot as well! with intrafamfs prompt at boot 
time.


#ok; so you're pulling the metapackage that pulls cryptsetup-initramfs
#the latter is what you need for initramfs support; if you missed it, no 
chances of booting!
#(the separation across packages is $debian_version-dependent, hence my 
suggesting install cryptsetup, which pulls what is required)


#get full URL to download package files from official source

apt-get download --print-uris cryptsetup
apt-get download --print-uris cryptsetup-initramfs

#above retrives (server, path, filename, including the relevant version 
and architecture, among other things)


apt-get -f install

#returns results:  0 upgraded, 0 newly installed, 0 to remove and 46 not 
upgraded


#Ready to move on to reinstall cryptsetup & cryptsetup-initramfs (both 
are necessary)
#copied the *.deb files to usb stick formatted as FAT, plugged it in 
then did "lsblk" to view its assignment (/dev/sdb1) and mounted "mount 
/dev/sdb1 /media/usb"


cd /media/usb
dpkg -i cryptsetup-initramfs_2.1.0-5+deb10u2_all.deb 
cryptsetup_2.1.0-5+deb10u2_all.deb

#results,
#dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
#dpkg: error: 1 expected program not found in PATH or not executable

#echo $PATH    =    /sbin:/usr/sbin:/bin:/usr/bin
#checking dpkg
dpkg -V dpkg
#returns errors could not find 'start-stop-daemon'

#(issue) /sbin/ is missing file 'start-stop-daemon' obtained it with 
some online help and copied it with 755 permission, rebooted live CD



#After reboot, retried install cryptsetup and cryptsetup-initramfs

#after copying start-stop-daemon, and fixing its permission and reboot 
liveCD

dpkg -V dpkg
#returns to prompt, no error this time.

#re-attempt install again
dpkg -i cryptsetup-initramfs_2.1.0-5+deb10u2_all.deb 
cryptsetup_2.1.0-5+deb10u2_all.deb


#this time executed without failures (generating /boot/initrd.img-* ... )

#next
lsinitramfs /boot/initrd.img-4.19.0-9-amd64|grep cryptsetup

#returns valid result:
# /usr/lib/cryptsetup   /usr/lib/cryptsetup/askpass   /functions 
/usr/lib/x86_64-linux-gnu/libcryptsetup.so.12 *.so.12.4.0 and 
usr/sbin/cryptsetup


then ran 'update-initramfs -u -k a' then 'update-grub'

Rebooted after all this and all was well, the prompt for passphrase 
returned and was able to login, was told would not be a bad idea to 
install and run debsums so I took that advice and found some other items 
which FAILED which will pursue necessary fixing now...


MAJOR credit goes to the team at https://debamax.com/ as their 
assistance has provided me the knowledge and details required for above 
fixes and to find out that /sbin/start-stop-daemon was missing and 
causing my inability to reinstall or query the installation packages to 
begin with to check their status. Appreciate their help & patience with 
me, I am forever grateful!


The issue is resolved!

Bug#965057: guile OOM test failures on ppc64el

[Matthias Klose]

On 8/14/20 11:33 AM, Matthias Klose wrote:
> I'm now NMUing both guile-2.2 and guile-3.0 to just ignore the test results on
> ppc64el, without closing the bug reports.  It's blocking the gcc-10 migration 
> to
> testing.

now, the NMUs fail with the same OOM error on armhf (3.0) and armhf/i386 (2.2)
as well... Maybe just don't run the OOM tests, instead of ignoring the test 
results?

Bug#968397: dpkg: package bug script exits with 256 on reportbug

[The Wanderer]

Package: dpkg
Version: 1.20.5
Severity: normal

Dear Maintainer,

When I attempt to file a bug report against dpkg with reportbug, I get
the following output:


The package bug script /usr/share/bug/dpkg exited with an error status
(return code = 256). Do you still want to file a report? [y|N|q|?]?


It is not clear whether this reflects a problem that will manifest
itself in the resulting bug report, but at the minimum, it is clearly
suboptimal UX. If it does reflect a real problem, that problem should be
fixed; if it does not, it should be streamlined so that this notice does
not appear in routine bug-report attempts.

As things stand, I have another bug report which I would like to file
(which might belong either to dpkg or to locales-all, or even somewhere
else I can't identify at a glance, but I think fits dpkg as the most
likely candidate) which is on hold because of this.

I'm not sure where to look on my system for anything that might be
contributing to the problem; I've already checked the script itself, and
tried running various commands and scripts based on what I find there,
without reproducing the 256 exit code as of yet. If there's anything I
can do to help track this down, don't hesitate to ask.


-- Package-specific info:

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

Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-3
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  3.1-2
ii  tar  1.30+dfsg-7
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.10
pn  debsig-verify  

-- no debconf information

Bug#966499: unicode-cldr-core: Please generate JSON data file also

[James Valleroy]

On Fri, 14 Aug 2020 06:59:05 -0400 James Valleroy  wrote:
> I found a git repository for converting the data to JSON [1], along with 
> instructions on how to use it [2]. However, the cldr-localenames package is 
> not available on npm, and I didn't figure out how to rebuild it yet.
> 
> But I found another repository [3], in which I can simply run "npm install", 
> and it downloads the XML data and converts it to JSON. The resulting data is 
> very close to what is shipped in php-getttext-languages, and should be fine 
> for my purposes.
> 
> [1] https://github.com/unicode-cldr/cldr-json
> [2] http://cldr.unicode.org/development/updating-codes/updating-json-data
> [3] https://github.com/rxaviers/cldr-data-npm

My bad, [3] is not converting the data. It is downloading the data already in 
JSON format from multiple repositories under https://github.com/unicode-cldr. 
The list of URLs that it downloads is here:
https://github.com/rxaviers/cldr-data-npm/blob/master/urls.json



signature.asc
Description: OpenPGP digital signature

Bug#964908: tomcat9/9.0./37-3 in buster backports

[Adrian Heath]

Do you know when this fix will appear in the Buster backports repository?

Thank you in advance

Bug#968394: gnome-shell: No UI option to switch between users even when there are multiple non-system user accounts

[Simon McVittie]

Control: reassign -1 libaccountsservice 0.6.55-1
Control: affects -1 + gnome-shell
Control: severity -1 serious
Control: tags -1 + pending

On Fri, 14 Aug 2020 at 13:10:18 +0100, Simon McVittie wrote:
> At least part of the problem (possibly the whole problem, I'm not sure
> yet) is that accountsservice since version 0.6.55 was accidentally
> compiled without systemd-logind support, so it can't tell us that the
> system can switch users, because it doesn't know.

This seems to be the root cause of the gnome-shell issue. Fixing
accountsservice gives me a nice "Switch User..." option just below "Log
Out", and an icon in the lower right corner of the lock screen with the
same effect.

This is a small part of gnome-shell's functionality, but a large part
of what accountsservice is meant to do, so I'm considering this to be
release-critical for accountsservice.

Thanks for the reminder to look into this,
smcv

Bug#964181: linux-image-4.19.0-9-amd64: Unable to get battery status

[Bernhard Übelacker]

Dear Maintainer,
this bug sounds similar to this one:
https://bugs.debian.org/927163

Kind regards,
Bernhard

Bug#949003: Doesn't work on 64 bit architectures

[Stéphane Glondu]

For me, slirp:amd64 does not crash, but does not work either (with User
Mode Linux). Installing slirp:i386 on an amd64 system works.


Cheers,

-- 
Stéphane

Bug#966087: libreoffice-writer: Cannot save file: General input/output error

[Rene Engelhard]

Hi,

so it might definitely be 32bit only. As I feared. Unfortunately
LibreOffice upstream does not support 32bit anymore, so anything bad can
sneak in there.

Am 14.08.20 um 10:56 schrieb frydo bugdeb:
> I have the same exact error.
> I am using a 32bit computer too.
>
> I have no problem with my 64bit computer with the same configuration.
>
I seriously believe your "32bit computer" is a 64bit-able computer where
one didn't install/maintain it properly by (re)installing it with  a 64
bit *operating system*.

> You don't even need to write anything in the document.
> Only save file, and the error occurs, with those lu9017o81.tmp empty
> files created in the repertory you want to save the file in.

And I already said in a i386 VM it just works for me. I actually tested
on 32 bits.

> libreoffice calc saves files, but I have a file for which I got a
> message that some attributes could not be read (but I don't know how
> to find which ones).

Any specialities? File System? If you know that you have a file there
you can probably give more information?

> This error does not appear on my 64bit computer.

Another reason to use something sensible.


Regards,


Rene

Bug#968149: mysql-router-dbgsym,mysql-server-core-8.0-dbgsym: file conflict due to shared build-id

[Robie Basak]

Thank you for the report.

On Sun, Aug 09, 2020 at 09:48:13PM +0200, Andreas Beckmann wrote:
> This is likely caused by the corresponding binary packages shipping
> identical binaries (or librariesi, ...) with different names.

Looks like this is because this file is shipped in both mysql-router
and mysql-server-core:

/usr/lib/mysql/private/libprotobuf-lite.so.*
/usr/lib/mysql-router/libprotobuf-lite.so.*


signature.asc
Description: PGP signature

Bug#880107: [RSVP] Re: Bug#880107: heimdall-flash: cannot flash RECOVERY on Samsung Note 3 (SM-N9005, hlte)

[Nicholas D Steeves]

Hi Thorsten!

On Tue, Aug 04, 2020 at 02:34:01PM +, Thorsten Glaser wrote:
> Hi Nicholas,
> 
> >Re-sending this bug update to your debian.org address, because
> >t...@mirbsd.de emitted the following during the last attempt
> 
> yes, this is an issue with Googlemail not honouring internet
> standards; nn-submitter@b.d.o is a generic fallback in case
> you can’t figure out a different eMail address.
>

Agreed, googlemail has plenty of issues, but the submitter for this
bug is t...@mirbsd.de (unreachable), while t...@debian.org (reachable).
So it looks to me like this bug fell through the cracks during the
process of changing submitter of your bugs from the former to the
latter.  I could be wrong of course; that's just what it looks like to
me :-)  P.S. This situation is also a good motivation for maintainers
who use self-hosted email to work towards DD: eg, then users who
aren't familiar with advanced BTS use can follow-up on bugs, and reach
the pkg's maintainer, because the debian.org address forwards it.

BTW, why did you use -quiet?  Was that an ideological decision?

> >Would you please test 1.4.2+dfsg-1 currently available in testing and
> >unstable?  I can provide a buster-backport for testing purposes if
> 
> I can do that, but it’ll probably take me some days, first I
> need to find that device… (and something to flash).
>

Thanks, much appreciated!  I'm guessing that by now your device could
use a TWRP upgrade, so maybe that?

> I use sid, so no backporting needed.
>

Wonderful :-)

> Thanks!
>

You're welcome!

> Stéphane, I actually don’t block Googlemail, they’re just too utterly
> stupid to successfully deliver to me (or anyone else using Greylisting
> and not whitelisting their ranges). Same for a few other providers such
> as Hotmail. Some spammers (Yahoo) I do block.

It sounds like your greylist could benefit from SPF Record
updates--either supervised, or automatic, as you prefer.


Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#968394: gnome-shell: No UI option to switch between users even when there are multiple non-system user accounts

[Simon McVittie]

Control: reassign -1 gnome-shell,libaccountsservice0
Control: found -1 gnome-shell/3.36.4-1
Control: found -1 accountsservice/0.6.55-1

On Fri, 14 Aug 2020 at 11:44:58 +0100, Simon McVittie wrote:
> I was looking into this myself recently. The "Switch User" menu item (also
> known as "fast user switching") is *meant* to show up in the system menu,
> near "Log Out", when there is more than one local user available and
> the OS can switch between sessions; but that information is getting lost
> somewhere in the path systemd-logind -> accountsservice -> gnome-shell.

At least part of the problem (possibly the whole problem, I'm not sure
yet) is that accountsservice since version 0.6.55 was accidentally
compiled without systemd-logind support, so it can't tell us that the
system can switch users, because it doesn't know. I'm trying to fix
that now.

smcv

Bug#882145: asterisk: pjsip show history causes segmentation fault

[Benoit Panizzon]

Hi Bernie

> Benoit, are you using IPv6? If yes,
> https://issues.asterisk.org/jira/browse/ASTERISK-28854 could be the
> culprit.

Well, why should I use that old legacy phased out ipv4 protocol? :-)

Thank you for the update!

-Benoît-

Bug#937695: python-defaults: Python2 removal in sid/bullseye

[Matthias Klose]

Control: tags -1 + wontfix

2.7.18-2 did remove the unversioned python packages.  This version of the
package should ship with bullseye, once it migrates.

Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs

[Nicholas D Steeves]

Hi,

Itaï BEN YAACOV  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Itaï BEN YAACOV 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: auctex-12
>   Version : 12.2
>   Upstream Author : GNU Project
> * URL : https://www.gnu.org/software/auctex/
> * License : GPL v3
>   Description : AUCTeX version 12, LaTeX environment for Emacs
>
> Hello,
>
> This is not truly an ITP but a request for guidance.
> auctex v11.91 already exists in Debian, and has not been updated since
> 2018 despite bug reports requesting that.  Specifically, the preview-latex
> feature no longer works due to changes in ghostscript, which is solved in
> upstream.
>

At this point the package is a candidate for salvaging.  Davide, are you
aware of this?

https://wiki.debian.org/PackageSalvaging

> The relevant bug #896844 was filed in Apr 2018, the maintainer said "I'll
> work on it" and nothing ever happened since, depite numerous follow-ups to
> the bug.  I tried to contact him directly in early 2020, getting no useful
> reply, except that he considers that he is still maintaining the package.
>

Good to hear, I guess he isn't complete MIA :-) Davide, please reply to
bugs, because it looks like you don't care about Auctex anymore.

> I am not a Debian developper, but am able to package (in fact I have packaged
> auctex v12 for personal use).
>
> What should / can be done in this case ?
>

The best case would be for Davide to resume maintenance of this
package.  Failing that it can be salvaged.

Itaï, please note that because none of the bugs are release critical
(RC), the objective is not to NMU (non maintainer upload) to fix bugs,
nor to package the latest upstream version; it is for the package to be
well-maintained.  Have you read all the new contributor documentation,
and is your intent to contribute to Auctex long-term?


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#968049: Failed to kill unit rsyslog.service: Input/output error

[Michael Biebl]

Control: reassign -1 lxc
Control: retitle -1 ghost service PIDs in LXC containers
Control: forwarded -1 https://github.com/lxc/lxc/issues/3520

Thanks for taking this issue upstream and getting to the bottom of it.
Given the feedback, this is apparently an LXC issue and Lennart does not
intend to change how this issue is handled (ignoring such cases or
changing the log message), so there doesn't remain anything to do on the
Debian systemd side.
I'm thus going to reassign the issue to lxc and marking the issue as
forwarded.

What follows is a verbatim copy of your lxc bug report (so the Debian
LXC maintainers have some context):






root@il08:~# cat /etc/debian_version
10.5
root@il08:~# lxc-start --version
4.0.4
root@il08:~# lxc-checkconfig
LXC version 4.0.4
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-5.6.0-0.bpo.2-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
newuidmap is not installed
newgidmap is not installed
Network namespace: enabled

--- Control groups ---
Cgroups: enabled

Cgroup v1 mount points:
/sys/fs/cgroup/cpuset
/sys/fs/cgroup/cpu
/sys/fs/cgroup/cpuacct
/sys/fs/cgroup/blkio
/sys/fs/cgroup/memory
/sys/fs/cgroup/devices
/sys/fs/cgroup/freezer
/sys/fs/cgroup/net_cls
/sys/fs/cgroup/perf_event
/sys/fs/cgroup/net_prio
/sys/fs/cgroup/pids
/sys/fs/cgroup/rdma

Cgroup v2 mount points:


Cgroup v1 systemd controller: missing
Cgroup v1 clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled, loaded
Macvlan: enabled, not loaded
Vlan: enabled, not loaded
Bridges: enabled, loaded
Advanced netfilter: enabled, loaded
CONFIG_NF_NAT_IPV4: missing
CONFIG_NF_NAT_IPV6: missing
CONFIG_IP_NF_TARGET_MASQUERADE: enabled, not loaded
CONFIG_IP6_NF_TARGET_MASQUERADE: enabled, not loaded
CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled, loaded
CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled, not loaded
FUSE (for use with lxcfs): enabled, not loaded

--- Checkpoint/Restore ---
checkpoint restore: enabled
CONFIG_FHANDLE: enabled
CONFIG_EVENTFD: enabled
CONFIG_EPOLL: enabled
CONFIG_UNIX_DIAG: enabled
CONFIG_INET_DIAG: enabled
CONFIG_PACKET_DIAG: enabled
CONFIG_NETLINK_DIAG: enabled
File capabilities:

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

root@il08:~# uname -a
Linux il08.ac.aixigo.de 5.6.0-0.bpo.2-amd64 #1 SMP Debian
5.6.14-2~bpo10+1 (2020-06-09) x86_64 GNU/Linux
root@il08:~# cat /proc/self/cgroup
13:name=systemd:/
12:rdma:/
11:pids:/
10:perf_event:/
9:net_prio:/
8:net_cls:/
7:memory:/
6:freezer:/
5:devices:/
4:cpuset:/
3:cpuacct:/
2:cpu:/
1:blkio:/
0::/
root@il08:~# cat /proc/1/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs
rw,nosuid,relatime,size=8043192k,nr_inodes=2010798,mode=755 0 0
devpts /dev/pts devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=1612620k,mode=755 0 0
/dev/sda1 / ext4 rw,noatime 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
pstore /sys/fs/pstore pstore rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=6580660k 0 0
/dev/sda4 /export ext4 rw,noatime 0 0
cgroup /sys/fs/cgroup tmpfs rw,relatime,size=12k,mode=755 0 0
cgroup /sys/fs/cgroup/cpuset cgroup
rw,relatime,cpuset,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuset,clone_children
0 0
cgroup /sys/fs/cgroup/cpu cgroup
rw,relatime,cpu,release_agent=/run/cgmanager/agents/cgm-release-agent.cpu 0
0
cgroup /sys/fs/cgroup/cpuacct cgroup
rw,relatime,cpuacct,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuacct
0 0
cgroup /sys/fs/cgroup/blkio cgroup
rw,relatime,blkio,release_agent=/run/cgmanager/agents/cgm-release-agent.blkio
0 0
cgroup /sys/fs/cgroup/memory cgroup
rw,relatime,memory,release_agent=/run/cgmanager/agents/cgm-release-agent.memory
0 0
cgroup /sys/fs/cgroup/devices cgroup
rw,relatime,devices,release_agent=/run/cgmanager/agents/cgm-release-agent.devices
0 0
cgroup /sys/fs/cgroup/freezer cgroup
rw,relatime,freezer,release_agent=/run/cgmanager/agents/cgm-release-agent.freezer
0 0
cgroup /sys/fs/cgroup/net_cls cgroup
rw,relatime,net_cls,release_agent=/run/cgmanager/agents/cgm-release-agent.net_cls
0 0
cgroup /sys/fs/cgroup/perf_event cgroup
rw,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event
0 0
cgroup /sys/fs/cgroup/net_prio cgroup
rw,relatime,net_prio,release_agent=/run/cgmanager/agents/cgm-release-agent.net_prio
0 0
cgroup /sys/fs/cgroup/pids cgroup
rw,relatime,pids,release_agent=/run/cgmanager/agents/cgm-release-agent.pids
0 0
cgroup /sys/fs/cgroup/rdma cgroup
rw,relatime,rdma,release_agent=/run/cgmanager/agents/cgm-release-age

Bug#952593: Debian RT - please install libgd-perl in wolkenstein.debian.org

[Laura Arjona Reina]

Hello DSA

Thanks for installing liblocale-codes-perl in wolkenstein.

Sorry to bother again, we're still facing build errors in www-master
with Debian 10 (error text below), it seems that the package libgd-perl
is also needed.

I'm attaching a patch for the debian.org-www-master.debian.org
dependencies including the new dependency.

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona


wml -q -D CUR_YEAR=2020 -o UNDEFuEN:devel-manuals.en.html@g+w
devel-manuals.wml
ePerl:Error: Perl parsing error (interpreter rc=2)

 Contents of STDERR channel: -
Can't locate GD.pm in @INC (you may need to install the GD module) (@INC
contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
/usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28
/usr/share/perl/5.28 /usr/local/lib/site_perl) at /tmp/wml.11796.tmp1
line 197.
BEGIN failed--compilation aborted at /tmp/wml.11796.tmp1 line 197.
--
From 3e2b75df84a1ff86118302000dbbef7faccaa177 Mon Sep 17 00:00:00 2001
From: Laura Arjona Reina 
Date: Fri, 14 Aug 2020 13:20:42 +0200
Subject: [PATCH] Install libgd-perl in www-master, needed to build
 /doc/devel-manuals in Debian 10 buster

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 15561ab..ec13686 100644
--- a/debian/control
+++ b/debian/control
@@ -281,6 +281,7 @@ Depends: debiandoc-sgml,
 	latex-cjk-chinese,
 	ldap-utils,
 	libcgi-pm-perl,
+	libgd-perl,
 	libemail-address-perl,
 	libintl-perl,
 	liblocale-codes-perl,
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#960047: [Pkg-phototools-devel] Bug#960047: darktable: Superfluous dependencies

[David Bremner]

astian  writes:

> Control: found -1 3.2.1-2
>
> What's the problem with fixing this? It's a one-liner FFS.
>

The problem is a lack of time and motivation. You are not helping with
either by sending such messages.

d

Bug#968339: Accept

[Vasyl Gello]

Control: owner -1 !

Hi Gianfranco!

Thanks for reporting this! I will investigate the issue and file it upstream.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#901612: ifupdown-extra: Patch confirmed

[Vincent van Adrighem]

Package: ifupdown-extra
Version: 0.27
Followup-For: Bug #901612

Dear Maintainer,

We are also impacted by this bug. On boot, static routes are not added.
After applying the patch mentioned in the previous comment,
this works fine.

We investigated the newer package in current stable (0.28) and did not find a 
fix for our
problem in there, so it still applies to 0.28 as well. We plan to upgrade in 
the next few weeks.

Is there any reason not to apply (a modified version of) the patch?

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

Kernel: Linux 4.9.0-13-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ifupdown-extra depends on:
ii  bind9-host [host]1:9.10.3.dfsg.P4-12.3+deb9u6
ii  curl 7.52.1-5+deb9u11
ii  dpkg 1.18.25
ii  host 1:9.10.3.dfsg.P4-12.3+deb9u6
ii  iproute2 4.9.0-1+deb9u1
ii  iputils-arping   3:20161105-1
ii  iputils-ping [ping]  3:20161105-1
ii  net-tools1.60+git20161116.90da8a0-1
ii  netcat-traditional [netcat]  1.10-41+b1

Versions of packages ifupdown-extra recommends:
ii  ethtool  1:4.8-1+b1
ii  ndisc6   1.0.3-3

ifupdown-extra suggests no packages.

-- Configuration Files:
/etc/network/routes changed [not included]

-- no debconf information

-- 
*
*


This message may contain information that is not intended for you. If 
you are not the addressee or if this message was sent to you by mistake, 
you are requested to inform the sender and delete the message. Connectis 
accepts no liability for damage of any kind resulting from the risks 
inherent in the electronic transmission of messages.

Bug#968395: Stretch update of {{ package }}?

[Markus Frosch]

Hi Emilio,

On Fri, 2020-08-14 at 12:40 +0200, Emilio Pozuelo Monfort wrote:
> The Debian LTS team would like to fix the security issues which are
> currently open in the Stretch version of {{ package }}:
> 

I'm not aware of any security issues with Terminator.

Not sure why went wrong here, apart from the template rendering.

Cheers
Markus
-- 
lazyfro...@debian.org
https://lazyfrosch.de

Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

[Steve McIntyre]

On Fri, Aug 14, 2020 at 12:08:59PM +0100, Janek Stolarek wrote:
>Please disregard my last email completely - fault on my side. Secure Boot 
>works as expected.

ACK, no worries.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#968383: marked as done (interimap: fails to work with Dovecot v2.3.11: ERROR: 0 bytes read (got EOF))

[Guilhem Moulin]

On Fri, 14 Aug 2020 at 09:33:03 +, Debian Bug Tracking System wrote:
>> All my 5 interimap profiles stopped working when security fix was applied
>> for my local Dovecot install was applied.
> 
> False alarm: Turned out to be a change in dovecot configuration files 
> incompatible with my accessing it via tunnel.
> 
> Revealed by manually running the underlying doveadm command.

Thanks for the update, Jonas!  Mind sharing what you had to change in
Dovecot?  1:2.3.11.3+dfsg1-1 doesn't break the test suite, so maybe you
have a setup it'd be worth having test covering for.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

[Janek Stolarek]

Please disregard my last email completely - fault on my side. Secure Boot works 
as expected.

Janek

Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

[Janek Stolarek]

Hi guys,

I believe the fix for this bug introduced a security regression that I only 
noticed just now. 
Recall how I was able to test whether Secure Boot is enabled:

[root@skynet : ~] dmesg | grep secu
[0.00] secureboot: Secure boot enabled

Here's what I get now:

[root@skynet : ~]  dmesg | grep secu
[0.00] secureboot: Secure boot could not be determined (mode 0)

This happens both on kernel 5.6 (used when I reported the bug originally) and 
5.7. I wanted to 
double-check that this is due to the fix in grub but the old packages are no 
longer in the repo 
so I can't downgrade to test. Googling points me to similar past bug in GRUB:

https://bugzilla.redhat.com/show_bug.cgi?id=1418360

and the suggestion there is that "failure detect secure boot status causes the 
kernel to disable a 
number of security checks" which makes this a security issue. There'a also a 
lot of technical 
discussion that I don't follow but it probably will make more sense to you.

Should I file a separate bug report for this?

Janek

Bug#966499: unicode-cldr-core: Please generate JSON data file also

[James Valleroy]

I found a git repository for converting the data to JSON [1], along with 
instructions on how to use it [2]. However, the cldr-localenames package is not 
available on npm, and I didn't figure out how to rebuild it yet.

But I found another repository [3], in which I can simply run "npm install", 
and it downloads the XML data and converts it to JSON. The resulting data is 
very close to what is shipped in php-getttext-languages, and should be fine for 
my purposes.

[1] https://github.com/unicode-cldr/cldr-json
[2] http://cldr.unicode.org/development/updating-codes/updating-json-data
[3] https://github.com/rxaviers/cldr-data-npm




signature.asc
Description: OpenPGP digital signature

Bug#911560: Tests for GMAC_TX_DELAY = ... with RevC A20 OLinuxino Lime 2

[Jonas Smedegaard]

Quoting Dieter (2020-08-14 09:03:22)
> On 08/08/2020 14:48, Jonas Smedegaard wrote:
> > Whoa, setting master/slave mode was implemented only since Linux 
> > v5.7: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649
> > 
> > Corresponding userspace support was introduced in ethtool v5.8: 
> > https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d
> > 
> > Ethtool v5.8 is not yet in Debian - was released upstream only 4 
> > days ago. Sorry, I thought master/slave was same as MDI/MDI-X, but 
> > those are independent: The former is which end provides clock 
> > source, then latter is which wires are used: 
> > https://en.wikipedia.org/wiki/Gigabit_Ethernet#1000BASE-T
> > 
> > According to 
> > https://www.speedguide.net/articles/network-adapter-optimization-3449 
> > when auto-negotiated "multi-port devices such as switches become the 
> > master when connected to a single port device. If both ends are 
> > multi-port devices, the one with higher seed bits becomes the 
> > master."
> > 
> > That seems to indicate that you should reliably put the device in 
> > slave mode by simply plugging it into a gigabit switch.  Still not 
> > sure how to force master mode (other than at the other end run Linux 
> > 5.7 and compile and use ethtool 5.8), as the above does not tell 
> > which end "wins" when both are single-port devices.
> 
> Thanks for the information.
> Since ethtool 5.8 is now available, i can install debian unstable on the
> laptop and test different combinations.

Yes - I was excited too seeing that package update appear today

I filed a bugreport requesting an update which possibly helped speed 
this up, but maybe it would have been done by now regardless.


> >> u-boot with FORCE_MASTER and TX-Delay 4:
> >> Same as above.
> >>
> >>
> >> u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK
> > 
> > Ohhh, good point - I totally missed that detail!
> > 
> > Seems more optimal to enable CONFIG_PHY_MICREL_KSZ9031.
> > 
> > Would be helpful if you could test...
> > 
> >   * CONFIG_PHY_MICREL_KSZ9031 instead of CONFIG_PHY_MICREL
> >   * enabling both CONFIG_PHY_REALTEK and CONFIG_PHY_MICREL_KSZ9031
> >   * above, with various values for TX-Delay
> 
> Yes, i can test that!

Thanks!

To be honest, I could test this myself as well - I do have those boards 
lying around, but some of them are in active use, and I keep finding 
other things more important/exciting, so really appreciate your help 
here!

Another benefit of this being done between the two of us is that we get 
the details more carefully laid out and documented.  At least for me it 
has been an eye-opener in just how complex a seemingly simple "LIME2 is 
flaky at high speeds" turns out to be, if we wanna do better than "then 
just avoid those flaky modes".


> >> Good performance with TX-Delay = [3,4].
> >> The results with TX-Delay = 2 could not be reproduced.
> >>
> >>
> >> Summed up: TX-delay = 3/4 seems useful for the Micrel phy.
> >> With TX-delay = 0, no connection was possible at all.
> > 
> > I would expect TX-delay = 0 to behave same as TX-delay not set at 
> > all - is that your experience as well?
> 
> To be honest, i did not disable the configuration, as i always started 
> from A20-OLinuXino..._defconfig, and there the Delay is set to 0 by 
> default.
> 
> But i just checked, if the line with GMAC_TX_DELAY is commented out in
> the config, make will ask for a value, 0 being the default.
> -> Yes, TX-Delay 0 is equal to this config not being set at all.

Thanks for confirming!


> >> Do you know what the switch regarding PHY_MICREL or PHY_REALTEK 
> >> does?
> >> Is this possibly only used in u-boot, and therefore irrelevant as 
> >> soon as linux boots?
> > 
> > those switches enable code chunks in u-boot.  My (vague!) 
> > understanding is that some but not all such code chunks does some 
> > initialization of hardware chips, and that Linux may or may not do 
> > its own (re)initialization of same bits.
> > 
> > In other words: Possibly - it depends... :-)
> 
> I see, in that case i would suppose that network functionality in 
> u-boot might depend on the compiled in drivers.

Yeah - except it is not really "drivers" in u-boot.


> Likely independent of network functionality when the OS is brought up.

Cold-booting u-boot is certainly independent of Linux.

But Warm-booting u-boot after rebooting from a loaded Linux is *not* 
independent of Linux.

Neither is Linux loaded from u-boot independent of u-boot.


> I arrived at this conclusion, as u-boot without the MICREL Phy has 
> working ethernet in Linux with the TX-Delay being set.

Imagine Micrel PHY needs pins X and Y enabled to work well, and u-boot 
sets X and flips Y, and Linux flips X and sets Y.

Cold-booting u-boot would fail, but then loading Linux would work.

Rebooting into u-boot from working linux would fail.

Rebooting into u-boot from failing u-boot would work.

Cold-booting u-boot, rebooting u

Bug#968394: gnome-shell: No UI option to switch between users even when there are multiple non-system user accounts

[Simon McVittie]

On Fri, 14 Aug 2020 at 16:01:52 +0530, Chandra Sekar wrote:
> There is no option in the status menu to switch to another user on the
> system. There is no option to login as another user on the lock screen
> either.

Workaround, assuming you are using gdm3:

* lock your screen (Super+L, where Super is usually the Windows logo key)
* press Ctrl+Alt+F1 to get back to the gdm greeter
* log in as another user there

I was looking into this myself recently. The "Switch User" menu item (also
known as "fast user switching") is *meant* to show up in the system menu,
near "Log Out", when there is more than one local user available and
the OS can switch between sessions; but that information is getting lost
somewhere in the path systemd-logind -> accountsservice -> gnome-shell.

The "Switch User" menu item is more or less equivalent to locking the
screen, waiting for it to lock, and switching to the gdm greeter.

There is meant to be an equivalent item on the lock screen, but, again,
the information that says it should appear is getting lost somewhere.

smcv

Bug#968395: Stretch update of {{ package }}?

[Emilio Pozuelo Monfort]

Package: terminator
Severity: grave
Tags: security

Dear maintainer(s),

The Debian LTS team would like to fix the security issues which are
currently open in the Stretch version of {{ package }}:
{%- if cve -%}
{% for entry in cve %}
https://security-tracker.debian.org/tracker/{{ entry }}
{%- endfor -%}
{%- else %}
https://security-tracker.debian.org/tracker/source-package/{{ package }}
{%- endif %}

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of {{ package }} updates
for the LTS releases.

Thank you very much.

{{ sender }},
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/dla-needed.txt

Bug#968394: gnome-shell: No UI option to switch between users even when there are multiple non-system user accounts

[Chandra Sekar]

Package: gnome-shell
Version: 3.36.4-1
Severity: normal
X-Debbugs-Cc: chandru...@gmail.com

Dear Maintainer,

There is no option in the status menu to switch to another user on the
system. There is no option to login as another user on the lock screen
either.

There are multiple non-system user accounts on the machine and I'm
logged into the laptop locally (not a remote connection). In such a
scenario, I expect an option to switch between users without having to
log out of the current user's session.

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  evolution-data-server3.36.4-1
ii  gir1.2-accountsservice-1.0   0.6.55-2
ii  gir1.2-atspi-2.0 2.36.0-3
ii  gir1.2-freedesktop   1.64.1-1
ii  gir1.2-gcr-3 3.36.0-2
ii  gir1.2-gdesktopenums-3.0 3.36.1-1
ii  gir1.2-gdm-1.0   3.36.2-1
ii  gir1.2-geoclue-2.0   2.5.6-1
ii  gir1.2-glib-2.0  1.64.1-1
ii  gir1.2-gnomebluetooth-1.03.34.1-1
ii  gir1.2-gnomedesktop-3.0  3.36.4-1
ii  gir1.2-gtk-3.0   3.24.20-1
ii  gir1.2-gweather-3.0  3.36.0-1
ii  gir1.2-ibus-1.0  1.5.22-5
ii  gir1.2-mutter-6  3.36.4-1
ii  gir1.2-nm-1.01.26.0-1
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.44.7-4
ii  gir1.2-polkit-1.00.105-29
ii  gir1.2-rsvg-2.0  2.48.7-1
ii  gir1.2-soup-2.4  2.70.0-1
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.64.3-1
ii  gnome-backgrounds3.36.0-1
ii  gnome-settings-daemon3.36.1-1
ii  gnome-shell-common   3.36.4-1
ii  gsettings-desktop-schemas3.36.1-1
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-3
ii  libcairo21.16.0-4
ii  libecal-2.0-13.36.4-1
ii  libedataserver-1.2-243.36.4-1
ii  libgcr-base-3-1  3.36.0-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libgirepository-1.0-11.64.1-1
ii  libgjs0g 1.64.3-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.64.4-1
ii  libglib2.0-bin   2.64.4-1
ii  libgnome-autoar-0-0  0.2.4-2
ii  libgnome-desktop-3-193.36.4-1
ii  libgraphene-1.0-01.10.2-1
ii  libgstreamer1.0-01.16.2-2
ii  libgtk-3-0   3.24.20-1
ii  libical3 3.0.8-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-6-03.36.4-1
ii  libnm0   1.26.0-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpolkit-agent-1-0  0.105-29
ii  libpolkit-gobject-1-00.105-29
ii  libpulse-mainloop-glib0  13.0-5
ii  libpulse013.0-5
ii  libsecret-1-00.20.3-1
ii  libsystemd0  246-2
ii  libwayland-server0   1.18.0-1
ii  libx11-6 2:1.6.10-3
ii  libxfixes3   1:5.0.3-2
ii  mutter   3.36.4-1
ii  python3  3.8.2-3

Versions of packages gnome-shell recommends:
ii  bolt  0.9-1
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.36.2-1
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.36.4-1
ii  gnome-menus   3.36.0-1
ii  gnome-user-docs   3.36.2-1
ii  ibus  1.5.22-5
ii  iio-sensor-proxy  3.0-1
ii  switcheroo-control2.1-1
ii  unzip 6.0-25

Versions of packag

Bug#965308: jackd won't start

[Simon McVittie]

On Fri, 14 Aug 2020 at 10:51:46 +0200, Arnaldo Pirrone wrote:
> I would like to point out that the error is not showing up any more after the
> updates, now the error is different

It seems it's now failing to open the configured ALSA PCM devices (which
probably also shouldn't happen?). From the strace output, it seems the
configured ALSA devices doesn't exist in /dev/snd:

> strace -efile jackd -d alsa
...
> openat(AT_FDCWD, "/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 
> ENOENT (File o directory non esistente)
> stat("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=9623, ...}) 
> = 0
> openat(AT_FDCWD, "/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = 6
> openat(AT_FDCWD, "/dev/snd/controlC0", O_RDWR|O_CLOEXEC) = 6
> openat(AT_FDCWD, "/dev/snd/pcmC0D0c", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 
> ENOENT (File o directory non esistente)
> ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to 
> capture-only mode

That seems like a completely different failure mode.

smcv