Bug#934803: /usr/share/postfix/main.cf.tls: remove smtpd_tls_session_cache_database?

[Trent W. Buck]

Package: postfix
Version: 3.4.5-1
Severity: minor
File: /usr/share/postfix/main.cf.tls

In a fresh Debian 10 with postfix, I didn't recognize these options in main.cf:

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

According to postfix's documentation (http://www.postfix.org/TLS_README.html),
the first option should "generally be left empty" these days (it lists some 
minimum versions).

The second option is "highly recommended", so should stay as-is.

I *think* /etc/postfix/main.cf gets them from /usr/share/postfix/main.cf.tls.
Is there a good reason to leave smtpd_tls_session_cache_database in main.cf.tls?
If not, please remove it.


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), 
(500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#849091: Port to Python 3 and python3-gst-1.0

[Stein Magnus Jodal]

On Wed, Aug 14, 2019 at 10:56:21PM +0200, Thomas Goirand wrote:
> I'm surprised to see no reply from the maintainer(s) when this bug has
> been opened in 2016. This isn't reassuring, and likely to cause the
> package to drop from Debian, especially as the Python team is actively
> doing Python 2 removal.
> 
> Is this transition to Python 3 planned? What does upstream say?

Hi!

I'm both the main upstream maintainer and the packager.

This bug is marked as forwarded to the upstream issue at
https://github.com/mopidy/mopidy/issues/779. That issue is also pinned
to the top of the upstream issues list.

tl;dr: Work porting Mopidy to Python 3 is ongoing. It is not blocked by
any dependencies, it is just plain regular work that needs to be
completed.

-jodal


signature.asc
Description: PGP signature

Bug#934347: dose3 FTBFS with OCaml 4.08.0 (safe strings)

[Stéphane Glondu]

Le 14/08/2019 à 20:32, Ralf Treinen a écrit :
>> Please provide a version of dose3 that works with -safe-string. Note:
>> this can be done before OCaml is updated because the current version in
>> unstable (4.05.0) already supports -safe-strings.
> 
> Thanks for having fixed this. Can you please push -14 onto salsa?

Done. Sorry for the delay.


Cheers,

-- 
Stéphane

Bug#934802: ruby-nokogiri: CVE-2019-5477: command injection vulnerability

[Salvatore Bonaccorso]

Source: ruby-nokogiri
Version: 1.10.3+dfsg1-2
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/sparklemotion/nokogiri/issues/1915

Hi,

The following vulnerability was published for ruby-nokogiri.

CVE-2019-5477[0]:
Command Injection Vulnerability

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-5477
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5477
[1] https://github.com/sparklemotion/nokogiri/issues/1915

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#934801: kubernetes: CVE-2019-11250

[Salvatore Bonaccorso]

Source: kubernetes
Version: 1.7.16+dfsg-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/kubernetes/kubernetes/issues/81114

Hi,

The following vulnerability was published for kubernetes.

CVE-2019-11250[0]:
Bearer tokens are revealed in logs

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11250
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11250
[1] https://github.com/kubernetes/kubernetes/issues/81114

Regards,
Salvatore

Bug#934769: closed by Thomas Goirand (Re: Bug#934769: openvswitch-switch: VPN services faile to start if openvswitch is used in host as primery outgoing port)

[richman10000...@gmail.com]

Hello!
Can you please explain what is uncler in my description?

"If openvswitch is used as_a__main ethernet por__t _on host, any VPN services 
failing to start."

The route on host goes via this Ethernet and openvswitch

On 8/14/2019 11:21 PM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the openvswitch-switch package:

#934769: openvswitch-switch: VPN services faile to start if openvswitch is used 
in host as primery outgoing port

It has been closed by Thomas Goirand .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Thomas Goirand 
 by
replying to this email.

Bug#934758: DKMS module fails to build for linux 5.2.0-2

[Benjamin Kaduk]

severity 934758 important
tags 934758 + fixed-upstream pending
thanks

On Wed, Aug 14, 2019 at 09:53:40AM -0400, Ryan Kavanagh wrote:
> Package: openafs-modules-dkms
> Version: 1.8.2-1
> Severity: grave
> Justification: renders package unusable
> 
> The openafs DKMS module fails to build for Linux kernel 5.2.0-2.
> This renders openafs unusable. I have attached the build log containing
> the error messages, in particular, it seems to have something to do
> with:

Yes, the fast-moving Linux KPIs have changed interfaces used by OpenAFS and
the 1.8.2 in Debian is stale.  I plan to package 1.8.4pre1 this week, which
should take care of this.

Thanks,

Ben

P.S. The 5.2.0 kernel is pretty unusable on my machine for other reasons,
mostly graphics-related, and I had to boot into 4.19.

Bug#934800: ledger-autosync: please update to latest upstream release, Python 3 compatible

[Sandro Tosi]

Package: ledger-autosync
Severity: important

Hello,
at https://gitlab.com/egh/ledger-autosync (new home for this project) they
describe the tool as "ledger-autosync is developed on Linux with ledger 3 and
python 3".

Please upgrade to a python3 compatible version, so that you can drop the
dependency on python-fuzzywuzzy (eventually using python3-fuzzywuzzy), so that
we can drop python-fuzzywuzzy (which is a reverse-dependency of
python-levenshtein, which I maintain).

prio set to important as this is part of the effort of removing python2 from
unstable

Thakns,
Sandro

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

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

Versions of packages ledger-autosync depends on:
pn  hledger | ledger  
ii  python2.7.16-1
ii  python-bs44.7.1-1
pn  python-fuzzywuzzy 
pn  python-ofxclient  
pn  python-ofxparse   
ii  python-pkg-resources  41.0.1-1

ledger-autosync recommends no packages.

ledger-autosync suggests no packages.

Bug#934799: supertuxkart FTBFS (armel, mips, mipsel, m68k, powerpc, sh4): undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'

[Helmut Grohne]

Source: supertuxkart
Version: 1.0-2
Severity: serious
Tags: ftbfs

supertuxkart currently fails to build from source on armel, mips,
mipsel, m68k, powerpc and sh4 with the following error during final
linking:

| /usr/bin/ld: CMakeFiles/supertuxkart.dir/src/graphics/irr_driver.cpp.o: 
undefined reference to symbol '__atomic_load_8@@LIBATOMIC_1.0'

Possibly, -latomic is missing here.

Helmut

Bug#934797: conmon FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: conmon
Version: 0.3.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

conmon fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. After making it
substitutable, conmon cross builds successfully. Please consider
applying the attached patch.

Helmut
--- conmon-0.3.0.orig/Makefile
+++ conmon-0.3.0/Makefile
@@ -3,6 +3,7 @@
 BINDIR ?= ${PREFIX}/bin
 LIBEXECDIR ?= ${PREFIX}/libexec
 GO ?= go
+PKG_CONFIG ?= pkg-config
 PROJECT := github.com/containers/conmon
 
 
@@ -23,10 +24,10 @@
 	$(eval GIT_BRANCH_CLEAN := unknown)
 endif
 
-override LIBS += $(shell pkg-config --libs glib-2.0)
+override LIBS += $(shell $(PKG_CONFIG) --libs glib-2.0)
 
 CFLAGS ?= -std=c99 -Os -Wall -Wextra -Werror
-override CFLAGS += $(shell pkg-config --cflags glib-2.0) -DVERSION=\"$(VERSION)\" -DGIT_COMMIT=\"$(GIT_COMMIT)\"
+override CFLAGS += $(shell $(PKG_CONFIG) --cflags glib-2.0) -DVERSION=\"$(VERSION)\" -DGIT_COMMIT=\"$(GIT_COMMIT)\"
 
 # Conditionally compile journald logging code if the libraries can be found
 # if they can be found, set USE_JOURNALD macro for use in conmon code.
@@ -34,12 +35,12 @@
 # "pkg-config --exists" will error if the package doesn't exist. Make can only compare
 # output of commands, so the echo commands are to allow pkg-config to error out, make to catch it,
 # and allow the compilation to complete.
-ifeq ($(shell pkg-config --exists libsystemd-journal && echo "0" || echo "1"), 0)
-	override LIBS += $(shell pkg-config --libs libsystemd-journal)
-	override CFLAGS += $(shell pkg-config --cflags libsystemd-journal) -D USE_JOURNALD=0
-else ifeq ($(shell pkg-config --exists libsystemd && echo "0" || echo "1"), 0)
-	override LIBS += $(shell pkg-config --libs libsystemd)
-	override CFLAGS += $(shell pkg-config --cflags libsystemd) -D USE_JOURNALD=0
+ifeq ($(shell $(PKG_CONFIG) --exists libsystemd-journal && echo "0" || echo "1"), 0)
+	override LIBS += $(shell $(PKG_CONFIG) --libs libsystemd-journal)
+	override CFLAGS += $(shell $(PKG_CONFIG) --cflags libsystemd-journal) -D USE_JOURNALD=0
+else ifeq ($(shell $(PKG_CONFIG) --exists libsystemd && echo "0" || echo "1"), 0)
+	override LIBS += $(shell $(PKG_CONFIG) --libs libsystemd)
+	override CFLAGS += $(shell $(PKG_CONFIG) --cflags libsystemd) -D USE_JOURNALD=0
 endif
 
 bin/conmon: src/conmon.o src/cmsg.o src/ctr_logging.o src/utils.o | bin

Bug#934798: mrboom FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: mrboom
Version: 4.8-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mrboom fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so is using dh_auto_build. Then
it fails stripping during make install with the wrong strip. Doing so
also breaks DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym
packages. Stripping is best deferred to dh_strip entirely. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru mrboom-4.8/debian/changelog mrboom-4.8/debian/changelog
--- mrboom-4.8/debian/changelog 2019-08-11 11:22:42.0 +0200
+++ mrboom-4.8/debian/changelog 2019-08-15 06:00:02.0 +0200
@@ -1,3 +1,12 @@
+mrboom (4.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Don't strip during make install.
+
+ -- Helmut Grohne   Thu, 15 Aug 2019 06:00:02 +0200
+
 mrboom (4.8-1) unstable; urgency=medium
 
   * New upstream version.
diff --minimal -Nru mrboom-4.8/debian/rules mrboom-4.8/debian/rules
--- mrboom-4.8/debian/rules 2018-02-18 15:01:14.0 +0100
+++ mrboom-4.8/debian/rules 2019-08-15 06:00:02.0 +0200
@@ -14,10 +14,10 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) mrboom LIBSDL2=1
+   dh_auto_build -- mrboom LIBSDL2=1
 
 override_dh_auto_test:
@echo skipping test
 
 override_dh_auto_install:
-   $(MAKE) install DESTDIR=debian/mrboom PREFIX=/usr MANDIR=share/man/man6 
BINDIR=games
+   dh_auto_install -- PREFIX=/usr MANDIR=share/man/man6 BINDIR=games 
STRIP=:

Bug#934796: RM: python-pdftools -- ROM; outdate; Python 2 only; no upstream release in 10+ years

[Sandro Tosi]

Package: ftp.debian.org
Severity: normal

Please remove python-pdftools; sdaps, the only rdep has already been notified
(see #928993).

Bug#874301: libgtop2: diff for NMU version 2.38.0-4.1

[dai]

Control: tags -1 + pending

Dear maintainer,

I've prepared an NMU for libgtop2 (versioned as 2.38.0-4.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E
diff -Nru libgtop2-2.38.0/debian/changelog libgtop2-2.38.0/debian/changelog
--- libgtop2-2.38.0/debian/changelog	2018-12-28 12:58:54.0 +0900
+++ libgtop2-2.38.0/debian/changelog	2019-08-10 21:46:38.0 +0900
@@ -1,3 +1,13 @@
+libgtop2 (2.38.0-4.1) unstable; urgency=medium
+
+  [ HIGUCHI Daisuke (VDR dai) ]
+  * Non-maintainer upload.
+  * Fix FTBFS on kFreeBSD: strlcpy undefined (Closes: #874301)
+- d/p/05_kfreebsd_strlcpy.patch: use strlcpy of FreeBSD's libc.
+- d/rules: add -lbsd to LDFLAGS if kFreeBSD.
+
+ -- HIGUCHI Daisuke (VDR dai)   Sat, 10 Aug 2019 21:46:38 +0900
+
 libgtop2 (2.38.0-4) unstable; urgency=medium
 
   [ Andrea Azzarone ]
diff -Nru libgtop2-2.38.0/debian/patches/05_kfreebsd_strlcpy.patch libgtop2-2.38.0/debian/patches/05_kfreebsd_strlcpy.patch
--- libgtop2-2.38.0/debian/patches/05_kfreebsd_strlcpy.patch	1970-01-01 09:00:00.0 +0900
+++ libgtop2-2.38.0/debian/patches/05_kfreebsd_strlcpy.patch	2019-08-10 21:46:24.0 +0900
@@ -0,0 +1,20 @@
+Description: use strlcpy of FreeBSD's libc
+Author: HIGUCHI Daisuke (VDR dai) 
+Bug-Debian: https://bugs.debian.org/874301
+Last-Update: 2019-08-10
+
+Index: libgtop2-2.38.0/sysdeps/freebsd/netload.c
+===
+--- libgtop2-2.38.0.orig/sysdeps/freebsd/netload.c
 libgtop2-2.38.0/sysdeps/freebsd/netload.c
+@@ -36,6 +36,10 @@
+ #include 
+ #include 
+ 
++#ifdef __FreeBSD__
++#include 
++#endif
++
+ static const unsigned long _glibtop_sysdeps_netload =
+ (1L << GLIBTOP_NETLOAD_IF_FLAGS) +
+ (1L << GLIBTOP_NETLOAD_MTU) +
diff -Nru libgtop2-2.38.0/debian/patches/series libgtop2-2.38.0/debian/patches/series
--- libgtop2-2.38.0/debian/patches/series	2018-12-28 12:58:54.0 +0900
+++ libgtop2-2.38.0/debian/patches/series	2019-08-10 21:46:31.0 +0900
@@ -1,3 +1,4 @@
 03_kfreebsd_installdirs.patch
 04_kfreebsd_version.patch
 mountlist-ignore-snap-squashfs.patch
+05_kfreebsd_strlcpy.patch
diff -Nru libgtop2-2.38.0/debian/rules libgtop2-2.38.0/debian/rules
--- libgtop2-2.38.0/debian/rules	2018-12-28 12:58:54.0 +0900
+++ libgtop2-2.38.0/debian/rules	2019-08-10 21:44:29.0 +0900
@@ -7,6 +7,7 @@
 
 ifeq ($(DEB_HOST_ARCH_OS),kfreebsd)
 CPPFLAGS += $(shell pkg-config --cflags libbsd-overlay)
+LDFLAGS += -lbsd
 endif
 
 %:


signature.asc
Description: PGP signature

Bug#928278: dmeventd: raid1 fails to automatically rebuild when raid_fault_policy="allocate"

[Nick Owens]

i reported this upstream at https://bugzilla.redhat.com/show_bug.cgi?id=1741016.

it is apparently a known outstanding bug but the other bugzilla
entries are private.

Bug#933757: Firefox-esr FTBFS "failed to open: /sbuild-nonexistent/.cargo/.package-cache"

[Mike Hommey]

On Thu, Aug 15, 2019 at 03:16:20AM +0100, peter green wrote:
> So the libvpx transition prompted me to take a look at this, I added some 
> code to debian/rules to create a fake homedir, use it for the build and 
> remove it in the clean target.

https://salsa.debian.org/mozilla-team/firefox/commit/c5bcfb20fde52a1f659270210e4cd40f5f1e8d59

> Unfortunately I then ran into another failure.
> 
> > /firefox-esr/media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc:858:17:
> >  error: âstruct vpx_svc_ref_frame_configâ has no member named âframe_flagsâ
> >  sf_conf.frame_flags[layer_idx] = layer_flags;
> 
> I have no idea what to make of this. My google searches aren't turning up 
> anything useful.

libvpx's API changed.

https://salsa.debian.org/mozilla-team/firefox/commit/f26d0387eea70b2ebceabeb86ec728227199f302

Mike

Bug#933757: Firefox-esr FTBFS "failed to open: /sbuild-nonexistent/.cargo/.package-cache"

[peter green]

So the libvpx transition prompted me to take a look at this, I added some code 
to debian/rules to create a fake homedir, use it for the build and remove it in 
the clean target.

Unfortunately I then ran into another failure.


/firefox-esr/media/webrtc/trunk/webrtc/modules/video_coding/codecs/vp9/vp9_impl.cc:858:17:
 error: âstruct vpx_svc_ref_frame_configâ has no member named âframe_flagsâ
 sf_conf.frame_flags[layer_idx] = layer_flags;


I have no idea what to make of this. My google searches aren't turning up 
anything useful.

Bug#926509: Package orphaned?

[nemo Inis]

On Wed, 14 Aug 2019 21:25:35 -0400 John Scott  wrote:
> On Wednesday, August 14, 2019 9:20:13 PM EDT you wrote:
> > I'm not being snarky here - this is a safety issue.
> How so? It doesn't seem to have any security issues

Quick excerpt from the release notes for the versions unavailable on Debian:

Improve resilience against memory attacks - overwrite memory before free [#3020]
Fix data loss due to not reading all database attachments if duplicates exist 
[#3180]
Fix database deletion when using unsafe saves to a different file system [#2889]
Warn user if deleting entries that are referenced. [#1744]
Linux: Prevent Klipper from storing secrets in clipboard [#1969]

Bug#934446: 回复: Bug#934446: wsjtx: debian/patches/0001-add-start-script.patch no longer used?

[wu jo]

Hi,
i wonder how to unsubscribe from this list.

发件人: Christoph Berg 
发送时间: 2019年8月13日 8:12
收件人: tony mancill ; 934...@bugs.debian.org 
<934...@bugs.debian.org>
主题: Bug#934446: wsjtx: debian/patches/0001-add-start-script.patch no longer 
used?

Re: tony mancill 2019-08-11 <20190811040218.GA22032@lark>
> I was poking around the packaging for wsjtx (because I'm thinking about
> trying my hand at some local modifications) and noticed that
> debian/patches/0001-add-start-script.patch creates a script that isn't
> installed as part of the current wsjtx binary package.  This script must
> have been needed for an older version of WSJT-X.
>
> I believe the patch can be removed from the package.  If I'm mistaken,
> feel free to close this.

Hi Tony,

thanks for spotting that. There's a lot more cruft in that patches
directory, unfortunately...

If you like, we can also give you commit access to the hamradio group.

Christoph

Bug#934721: sbuild: Lintian run via sbuild produces different output than running lintian manually with the same options

[Bill Blough]

I've had a chance to do some more exploration.

Lintian is indeed getting run with a different .changes file than what
is output to screen/disk.

The package build creates a changes file in the temporary 
that contains a Distribution of UNRELEASED.  This happens even if the
distribution is specified with -d.

The .changes file later gets written to BUILD_DIR, with the Distribution
field set to what was specified by -d.

However, lintian is run against the original (Dist: UNRELEASED) .changes
file left in , not the modified version written in BUILD_DIR.

It seems to me that lintian should be run against the modified .changes
file that is provided to the user after the build, rather than the
leftover one in  that is different.


Also, after the new .changes file is written, there's an attempt to delete the
old one in , but it seems to fail silently.  So I assume this
is a bug, rather than an intentional choice. (Also, the variables in
question are very similarly named, so I think it would be an easy
mistake to make).


I've attached a small patch that makes it use the modified .changes file
instead of the unmodified one.  On my system, this makes it behave as I
would expect.  That is, lintian run via sbuild behaves the same way as
lintian run manually, since they're now using the exact same .changes file.


Best regards,
Bill
diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index f5660148..83dc295f 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -1684,7 +1684,7 @@ sub run_lintian {
 my $pipe = $session->pipe_command(
 { COMMAND => \@lintian_command,
   PRIORITY => 0,
-  DIR => $self->get('Build Dir'),
+  DIR => $self->get_conf('BUILD_DIR'),
 	  PIPE => "in"
 });
 if (!$pipe) {

Bug#926509: Package orphaned?

[John Scott]

On Wednesday, August 14, 2019 9:20:13 PM EDT you wrote:
> I'm not being snarky here - this is a safety issue.
How so? It doesn't seem to have any security issues
https://security-tracker.debian.org/tracker/source-package/keepassxc


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

Bug#926509: Package orphaned?

[nemo Inis]

Has this package been orphaned? It seems unlikely that a security tool such as 
a password
manager would lag one year behind upstream's current version?

Should we just call it quit and switch to the upstream AppImage?

I'm not being snarky here - this is a safety issue. A word of reassurance (or 
of any other
news) from the maintainer would be welcome.

Bug#934794: src:haveged: Test failure on arm64

[Nicolas Braud-Santoni]

Package: src:haveged
Version: 1.9.4-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

haveged/1.9.4-1 failed tests on arm64, resulting in a build failure:
  
https://buildd.debian.org/status/fetch.php?pkg=haveged&arch=arm64&ver=1.9.4-1&stamp=1565797076&raw=0

> ../src/haveged -n 16384k -v 1 
> haveged: listening socket at 3
> haveged: Couldn't initialize HAVEGE rng 9
> tot tests(BA8): B:0/1  last entropy estimate 3.63533
> fills: 0, generated: 0 
> make[3]: *** [Makefile:573: check-local] Error 1

Error code 9 is H_NOTESTTOT, i.e. the startup test failed.

This might be due to a random failure, a transient issue on the buildd,
or a legitimate bug  :(

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1UsVkRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MvAJQ/+KfxCIHP7DRccU9xV2bFg349exw2/Lr23
BRLHBVexgQ1ts0bAsnaEJnawdZNKw8uAuHodiScVi8JKPSyIUSdRNoni2Tqi81Dm
6Xx+BEW3ko8DqNAgx5EIw0ylRxgTBRLWcLEbdvpfGYJytqrSLCMxe+94/Y03aZGw
AzPZw7B9px8+hLcbweIdU6u89kjOU1FfHbnhw+0sRlNG0jcHiOtEyRHA0KHNQhin
/esiIdkwNndUiI9WaBEDOn8xP7KvmrS4PeiO9e65ggBDaVj1mCudUkK7WCh0Vvzo
hpZwM2GXkJXRWNd7Tea5/o+JSCkmShO7HW3QcW4Oav63ibj5WJuLdQjP0WpU0gp8
ESJb4iqEpgf78hhLV/vF8clzKIYezm/yxxtx2vhgy1h2m3NCZDVGWF0CNCX+0VaH
kB5lVGNslTOkHlfjyVxoQicRHM4+0hfxcAwaUccvlZ8sO3GySOZaDfVP7KSRWSBF
Lla8bxIFDBCqf9B9FOzet7c5E+kukLIiqXMETW8Is1H397t0SAY4koqnCpJuYFBE
L+fanMEkuWfemaz5p8uMg5LIoWLaOhW2D4USm21w5YEwDkxvU6Hs79tFaoJigAVj
V+A+Q3xmUtpNnM4guLpBo/2qF9+z36h94c0S2a0N2QMXRkOcKNQbI08a1utwzhwH
dFPeMGAuqSA=
=VtgU
-END PGP SIGNATURE-

Bug#934795: mirror submission for debian.andreitudor.ca

[Andrei Tudor]

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

Submission-Type: new
Site: debian.andreitudor.ca
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Andrei Tudor 
Country: CA Canada
Location: Quebec City




Trace Url: http://debian.andreitudor.ca/debian/project/trace/
Trace Url: 
http://debian.andreitudor.ca/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://debian.andreitudor.ca/debian/project/trace/debian.andreitudor.ca

Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging

[brian m. carlson]

On 2019-08-14 at 07:09:19, Philip Withnall wrote:
> In every situation where I’ve seen warnings (compile time, or run time)
> hidden from developers, those warnings have very rarely been fixed.
> Making them visible has increased the number of warnings which have
> been fixed.
> 
> Filing bugs against applications, which point out specific warnings
> which need fixing is, I feel, a much better use of people’s time than
> inventing new and innovative ways to hide those warnings.

I've filed bugs #934790 through #934792 for some of the issues I've
seen. From what I understand of the situation, #934791 and #934792 are
likely bugs in GTK or GDK.

As previously mentioned, I'm happy if GLib learns a way to suppress or
redirect logging and that will meet my needs adequately. However, if
that's not something the GNOME developers want to do, then I'm happy to
keep sending any issues I see with GTK or GDK their way.

I'm also suggesting to maintainers of relevant bugs that
g_return*_if_fail could be patched to not warn to standard error, which
would fix the majority of these issues, and would also be a satisfactory
solution from the GLib side, although GTK would still need some
additional patching.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#931873: texlive-bin: FTBFS on sparc64

[John Paul Adrian Glaubitz]

Package: src:texlive-bin
Followup-For: Bug #931873
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

The attached patch should fix the issue. It just enables the alignment
fixes the code has for ARM and Solaris for Linux on SPARC which means
all machines where the compiler defines "__sparc__".

The most generic approach would be to replace all instances of

( defined(__sun) && defined(__SVR4))

with

defined __sparc

since "__sparc" is defined on both Solaris/SPARC and Linux/SPARC (and
I'm quite confident it's also defined on Free,Open,NetBSD/SPARC).

Testing for "( defined(__sun) && defined(__SVR4))" actually assumes that
Solaris runs on SPARC only which is not the case. Solaris runs on x86
as well and x86 doesn't have these alignment issues. Hence, the proper
way is to detect the architecture and not the opering system.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Fix alignment issues on sparc64
Author: John Paul Adrian Glaubitz 
Last-Update: 2019-08-15

--- texlive-bin-2019.20190605.51237.orig/texk/web2c/luatexdir/luapplib/ppconf.h
+++ texlive-bin-2019.20190605.51237/texk/web2c/luatexdir/luapplib/ppconf.h
@@ -3,7 +3,7 @@
 #define PP_CONF_H
 
 //#include "utilarm.h" // keep in sync
-#if defined __arm__ || defined __ARM__ || defined ARM || defined __ARM || 
defined __arm || defined __ARM_ARCH ||defined __aarch64__ ||( defined(__sun) && 
defined(__SVR4))
+#if defined __arm__ || defined __ARM__ || defined ARM || defined __ARM || 
defined __arm || defined __ARM_ARCH ||defined __aarch64__ ||defined __sparc__ 
||( defined(__sun) && defined(__SVR4))
 #  define ARM_COMPLIANT 1
 #else
 #  define ARM_COMPLIANT 0
--- texlive-bin-2019.20190605.51237.orig/texk/web2c/luatexdir/luapplib/ppheap.c
+++ texlive-bin-2019.20190605.51237/texk/web2c/luatexdir/luapplib/ppheap.c
@@ -15,7 +15,11 @@
 #if defined(__sun) && defined(__SVR4)
 # define PPHEAP_NEED_ALIGNMENT
 #endif
- 
+
+#if defined(__sparc__)
+# define PPHEAP_NEED_ALIGNMENT
+#endif
+
 #ifdef PPHEAP_NEED_ALIGNMENT 
 /* Tests has shown that long double seems to work: */
 /* for 32bit aligned_data has  algn: 64 as ppxref and ppref, */
--- 
texlive-bin-2019.20190605.51237.orig/texk/web2c/luatexdir/luapplib/util/utilarm.h
+++ texlive-bin-2019.20190605.51237/texk/web2c/luatexdir/luapplib/util/utilarm.h
@@ -1,10 +1,10 @@
 #ifndef UTIL_ARM_H
 #define UTIL_ARM_H
 
-#if defined __arm__ || defined __ARM__ || defined ARM || defined __ARM || 
defined __arm || defined __ARM_ARCH ||defined __aarch64__ ||( defined(__sun) && 
defined(__SVR4))
+#if defined __arm__ || defined __ARM__ || defined ARM || defined __ARM || 
defined __arm || defined __ARM_ARCH ||defined __aarch64__ ||defined __sparc__ 
||( defined(__sun) && defined(__SVR4))
 #  define ARM_COMPLIANT 1
 #else
 #  define ARM_COMPLIANT 0
 #endif
 
-#endif
\ No newline at end of file
+#endif

Bug#934793: ITP: nattable -- high-performance SWT data grid

[Vincent Prat]

Package: wnpp
Severity: wishlist

* Package Name  : nattable
  Version               : 1.5.0
  Upstream author   : NatTable developers 
* URL   : https://www.eclipse.org/nattable/
* License   : Eclipse Public License 1.0
  Programming language  : Java
  Description   : high-performace SWT data grid

NatTable is a powerful and flexible SWT table/grid widget that is built to 
handle very large data sets, real-time updates, dynamic styling, and more.
NatTable is a subproject of Nebula.

This package is a dependency of HDFView.

This package will be maintained under the Debian Java Maintainers 
. 

Bug#934792: network-manager-gnome: produce GDK drawing warning

[brian m. carlson]

Package: network-manager-gnome
Version: 1.8.22-2
Severity: minor

nm-applet produces the following warning to standard error:

  (nm-applet:3764): Gdk-CRITICAL **: 02:59:58.580: 
gdk_window_thaw_toplevel_updates: assertion 
'window->update_and_descendants_freeze_count > 0' failed

I suspect this is likely a bug in GTK+ unless nm-applet does a lot of
low-level drawing itself, so feel free to reassign it there.

Other ways to solve this problem could be to compile GDK with
G_DISABLE_CHECKS or to fix GLib not to report to standard error in
g_return_*_if_fail.

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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  dconf-gsettings-backend [gsettings-backend]   0.30.1-2
ii  libatk1.0-0   2.32.0-2
ii  libayatana-appindicator3-10.5.3-4
ii  libc6 2.28-10
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.60.6-2
ii  libgtk-3-03.24.10-1
ii  libjansson4   2.12-1
ii  libmm-glib0   1.10.0-1
ii  libnm01.20.0-1
ii  libnma0   1.8.22-2
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libsecret-1-0 0.18.7-1
ii  libselinux1   2.9-2+b2
ii  mate-polkit [polkit-1-auth-agent] 1.22.0-1
ii  network-manager   1.20.0-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring   3.28.2-5
ii  iso-codes   4.3-1
ii  mate-notification-daemon [notification-daemon]  1.22.0-1
ii  mobile-broadband-provider-info  20190618-2
ii  notification-daemon 3.20.0-4

Versions of packages network-manager-gnome suggests:
ii  network-manager-openconnect-gnome  1.2.4-2
ii  network-manager-openvpn-gnome  1.8.10-1
ii  network-manager-pptp-gnome 1.2.8-2
pn  network-manager-vpnc-gnome 

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#934791: libgtk-3-0: complains when attempting to register already registered client

[brian m. carlson]

Package: libgtk-3-0
Version: 3.24.10-1
Severity: minor

GTK+ produces the following warning when attempting to register a client
with the session manager and the client is already registered:

  (caja:3729): Gtk-WARNING **: 02:59:57.229: Failed to register client: 
GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register 
client

GTK+ should either not attempt to register the client in this case or
should detect that it's already registered and not warn about it to
standard error.

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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.30.1-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.32.0-2
ii  libatk1.0-0  2.32.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcolord2   1.4.3-4
ii  libcups2 2.2.10-6
ii  libepoxy01.5.3-0.1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-4
ii  libfribidi0  1.0.5-3.1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgtk-3-common  3.24.10-1
ii  libharfbuzz0b2.5.3-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  librest-0.7-00.8.1-1
ii  libsoup2.4-1 2.64.2-2
ii  libwayland-client0   1.17.0-1
ii  libwayland-cursor0   1.17.0-1
ii  libwayland-egl1  1.17.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon00.8.2-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 1.10-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin  3.24.10-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs 1.38.1-5
ii  librsvg2-common  2.44.14-1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
ii  ibus-gtk3 1.5.19-4+b1
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-7
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#934790: atril: sometimes prints GLib error message when exiting

[brian m. carlson]

Package: atril
Version: 1.22.1-1
Severity: minor

When running atril from the command line, it sometimes prints the
following error message when it exits:

  (atril:308857): GLib-CRITICAL **: 23:34:21.398: g_source_set_ready_time: 
assertion 'source->priv != NULL' failed

This does not always occur, but occurs most of the time when invoked
with a PDF file from the command line.

If you don't think this message is worth fixing, you can ask the glib2.0
maintainer to compile with G_DISABLE_CHECKS to suppress this warning, or
to patch GLib not to produce warnings to stderr in g_return_*_if_fail.

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

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

Versions of packages atril depends on:
ii  atril-common 1.22.1-1
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk1.0-0  2.32.0-2
ii  libatrildocument31.22.1-1
ii  libatrilview31.22.1-1
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcaja-extension1   1.22.1-1
ii  libgail-3-0  3.24.10-1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.60.6-2
ii  libgtk-3-0   3.24.10-1
ii  libice6  2:1.0.9-2
ii  libjavascriptcoregtk-4.0-18  2.24.3-1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libsecret-1-00.18.7-1
ii  libsm6   2:1.2.3-1
ii  libsoup2.4-1 2.64.2-2
ii  libwebkit2gtk-4.0-37 2.24.3-1
ii  libx11-6 2:1.6.7-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  shared-mime-info 1.10-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages atril recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  dbus-x11 [dbus-session-bus]   1.12.16-1
ii  gvfs  1.38.1-5

Versions of packages atril suggests:
ii  caja  1.22.1-1
ii  poppler-data  0.4.9-2
pn  unrar 

-- no debconf information

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#931591: Buster: upgraded Handbrake crashes on encode with custom preset

[Seth Foley]

Installed gdb, updated sources, installed the two debug symbol packages, 
and ran those commands. (I had not rebooted since the crash on Tuesday.)


The output of coredumpctl is attached.

I also copied the core dump file in case it's wanted later.

Thanks, --SF
sfoley@sethix:~$ sudo coredumpctl gdb 25924
   PID: 25924 (handbrake)
   UID: 1000 (sfoley)
   GID: 1000 (sfoley)
Signal: 11 (SEGV)
 Timestamp: Tue 2019-08-13 16:20:33 PDT (24h ago)
  Command Line: handbrake
Executable: /usr/bin/ghb
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service
  Unit: user@1000.service
 User Unit: gnome-terminal-server.service
 Slice: user-1000.slice
 Owner UID: 1000 (sfoley)
   Boot ID: 230bc3d26d844d41ae54905a3ddce9ac
Machine ID: bcb68a4cfd884e00a8004c20b2fb56e1
  Hostname: sethix
   Storage: 
/var/lib/systemd/coredump/core.handbrake.1000.230bc3d26d844d41ae54905a3ddce9ac.25924.156573843300.lz4
   Message: Process 25924 (handbrake) of user 1000 dumped core.

Stack trace of thread 25962:
#0  0x7f7ce7188fb4 n/a (libc.so.6)
#1  0x7f7cebc47e73 n/a (libavformat.so.58)
#2  0x7f7cebc48102 n/a (libavformat.so.58)
#3  0x7f7cebc48a2e n/a (libavformat.so.58)
#4  0x7f7cebc4d187 n/a (libavformat.so.58)
#5  0x7f7cebc4d1ee avio_open2 (libavformat.so.58)
#6  0x561ecd32d8fd n/a (ghb)
#7  0x561ecd2e4112 n/a (ghb)
#8  0x561ecd317e56 n/a (ghb)
#9  0x561ecd2d607b n/a (ghb)
#10 0x7f7ce9457fa3 start_thread (libpthread.so.0)
#11 0x7f7ce71e04cf __clone (libc.so.6)

Stack trace of thread 25926:
#0  0x7f7ce71d5819 __poll (libc.so.6)
#1  0x7f7ce7479136 n/a (libglib-2.0.so.0)
#2  0x7f7ce74794c2 g_main_loop_run (libglib-2.0.so.0)
#3  0x7f7ce7acb0d6 n/a (libgio-2.0.so.0)
#4  0x7f7ce74a1415 n/a (libglib-2.0.so.0)
#5  0x7f7ce9457fa3 start_thread (libpthread.so.0)
#6  0x7f7ce71e04cf __clone (libc.so.6)

Stack trace of thread 25932:
#0  0x7f7ce71ad720 __nanosleep (libc.so.6)
#1  0x7f7ce71d8874 usleep (libc.so.6)
#2  0x561ecd2cb323 n/a (ghb)
#3  0x561ecd2d607b n/a (ghb)
#4  0x7f7ce9457fa3 start_thread (libpthread.so.0)
#5  0x7f7ce71e04cf __clone (libc.so.6)

Stack trace of thread 25933:
#0  0x7f7ce71ad720 __nanosleep (libc.so.6)
#1  0x7f7ce71d8874 usleep (libc.so.6)
#2  0x561ecd2cb323 n/a (ghb)
#3  0x561ecd2d607b n/a (ghb)
#4  0x7f7ce9457fa3 start_thread (libpthread.so.0)
#5  0x7f7ce71e04cf __clone (libc.so.6)

Stack trace of thread 25925:
#0  0x7f7ce71d5819 __poll (libc.so.6)
#1  0x7f7ce7479136 n/a (libglib-2.0.so.0)
#2  0x7f7ce747925c g_main_context_iteration 
(libglib-2.0.so.0)
#3  0x7f7ce74792a1 n/a (libglib-2.0.so.0)
#4  0x7f7ce74a1415 n/a (libglib-2.0.so.0)
#5  0x7f7ce9457fa3 start_thread (libpthread.so.0)
#6  0x7f7ce71e04cf __clone (libc.so.6)

Stack trace of thread 25924:
#0  0x7f7ce7ce4813 n/a (libpango-1.0.so.0)
#1  0x7f7ce7ce4a18 n/a (libpango-1.0.so.0)
#2  0x7f7ce7ce62e7 pango_itemize_with_base_dir 
(libpango-1.0.so.0)
#3  0x7f7ce7cef40b n/a (libpango-1.0.so.0)
#4  0x7f7ce7cf12a2 n/a (libpango-1.0.so.0)
#5  0x7f7ce81207c1 gtk_text_layout_get_line_display 
(libgtk-3.so.0)
#6  0x7f7ce8121812 n/a (libgtk-3.so.0)
#7  0x7f7ce8101f55 n/a (libgtk-3.so.0)
#8  0x7f7ce811f56e gtk_text_layout_validate_yrange 
(libgtk-3.so.0)
#9  0x7f7ce8130ba3 n/a (libgtk-3.so.0)
#10 0x7f7ce8131733 n/a (libgtk-3.so.0)
#11 0x7f7ce8131b59 n/a (libgtk-3.so.0)
#12 0x7f7ce7d43c08 n/a (libgdk-3.so.0)
#13 0x7f7ce7478dd8 g_main_context_dispatch 
(libglib-2.0.so.0)
#14 0x7f7ce74791c8 n/a (libglib-2.0.so.0)
#15 0x7f7ce747925c g_main_context_iteration 
(libglib-2.0.so.0)
#16 0x7f7ce7a9198d g_application_run (libgio-2.0.so.0)
#17 0x561ecd293162 main (ghb)
#1

Bug#909091: ITP: ocaml-mccs -- Stripped-down version of mccs, a CUDF problem solver, with OCaml bindings

[Nicolas Braud-Santoni]

Control: retitle -1 ITP: ocaml-mccs -- Stripped-down version of mccs, a CUDF 
problem solver, with OCaml bindings
Control: owner -1 !
Control: block 907636 by -1
Control: block 908203 by -1

Hi Ralf,

I started the packaging work while preparing opam/2.0.5-1.
Hopefully I can get this out this week; otherwise, it will likely be after 
CCCamp
(so, end of the month?)


Best,

  nicoo

On Tue, Sep 18, 2018 at 01:40:42PM +0200, Ralf Jung wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: ocaml-mccs
>   Version : 1.1+8
>   Upstream Author : Claude Michel
> * URL : https://github.com/AltGr/ocaml-mccs
> * License : BSD (3-clause), GPL
>   Programming Lang: C++, OCaml
>   Description : Stripped-down version of mccs, a CUDF problem solver, 
> with OCaml bindings
> 
> This is a a stripped-down version of the mccs solver, taken from snapshot 1.1,
> with a binding as an OCaml library, and building with jbuilder.
> 
> This is needed for opam to work without an external solver.
> 


signature.asc
Description: PGP signature

Bug#934655: libglib2.0-0: provide environment variable to suppress or redirect logging

[brian m. carlson]

On 2019-08-14 at 07:09:19, Philip Withnall wrote:
> Sorry, I think you’re conflating two different types of programs here.
> Command line applications like git have very different output
> requirements on stderr/stdout from graphical programs. Command line
> programs don’t normally use GTK, so shouldn’t see any of the warnings
> you mention above. I would be very surprised if command line programs
> using GLib (not GTK) emitted different warnings with different versions
> of GLib. If they do, can you please provide me with concrete examples
> and I can advise you about how to eliminate them.

Lots of people run GTK+ programs from the command line. I do this all
the time, and that's why this is an issue. I agree that many people do
not, but those people who do are often heavy terminal users and this
really bites them.

Debian systems also invoke GUI programs from mailcap files and xdg-open,
both of which are frequently used from the command line and command line
tools.

> GTK and GLib are separate libraries.

They are indeed separate libraries, but they are developed as a set and
are highly intertwined. GTK+ programs use the GLib logging functions for
API misuse warning messages. Other libraries that are used with GTK+
also use these logging functions for the same purpose, which
necessitates a change in GLib, or an agreement by GTK+ and the other UI
libraries about how to honor the user's wishes not to receive these
messages.

If there were a simple solution where GTK+ and Clutter and all of the
other libraries just called something like g_report_api_misuse, then
there could be an environment variable or setting just for that, but I
don't believe such a function exists. Since it's currently impossible to
distinguish between GTK+'s warning messages and other messages, a bigger
hammer is required.

If you're willing to add such a function and allow users to suppress or
redirect the output, I'm happy to reassign this bug to GTK+.

> > Ultimately, I think it's most appropriate to let users decide for
> > themselves if they would like to see non-user-visible issues on their
> > terminal. I'm not even asking for this to be the default, just an
> > option
> > users can turn on.
> 
> If it’s not on by default, almost all users will never find out about
> it. If your argument is that seeing the warnings is only useful for
> developers, then such an option should be on by default and developers
> would have to explicitly turn it off.

I'm not even requesting that they be disabled by default, although I do
feel that they should be. I'm requesting an environment variable users
can set to disable GLib logging while keeping it on by default.
Alternatively, an environment variable directing GLib logging to a file
would meet my needs, provided it supported character specials.

I'd also be happy with just reporting these errors when developer mode
is turned on during the build, or when -Werror is passed as a flag to
the compiler. These are settings that will be turned on in development,
but will not be enabled for non-development uses.

I'm happy to look for solutions that solve the problem for me and all
the other users that are acceptable to upstream.

> Filing bugs against applications, which point out specific warnings
> which need fixing is, I feel, a much better use of people’s time than
> inventing new and innovative ways to hide those warnings.

You seem to have ignored the part of my previous mail where I stated
that this is not an effective solution to the problem. Some projects
have a much longer release cycle than GLib, meaning even the latest
versions of a release may acquire new warnings as new GLib and GTK+
releases come out.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#932524: reportbug: support buster-pu bugs against release.debian.org

[Nicolas Braud-Santoni]

Dear maintainer,

Please find a patch enclosed, which updates the CODENAME2SUITE and 
SUITE2CODENAME
mappings in utils.py, resolving this bug.

The patch is also available as a merge request on salsa.d.o:
  https://salsa.debian.org/reportbug-team/reportbug/merge_requests/26

Best,

  nicoo

On Sat, Jul 20, 2019 at 01:46:44PM +0200, Nicolas Braud-Santoni wrote:
> Package: reportbug
> Version: 7.5.2
> Severity: wishlist
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Dear maintainers,
> 
> I just noticed that, when submitting a bug against release.debian.org,
> reportbug offers an option for stretch-pu, but not buster-pu.
> 
> Please consider updating the template used there (or programatically generate
> it based on the list of current Debian releases).
> 
> 
> Best,
> 
>   nicoo
> 
> - -- Package-specific info:
> ** Environment settings:
> EDITOR="emacsclient"
> PAGER="less"
> DEBEMAIL="ni...@debian.org"
> DEBFULLNAME="Nicolas Braud-Santoni"
> INTERFACE="text"
> 
> ** /home/nicoo/.reportbugrc:
> mode advanced
> ui text
> sign gpg
> no-query-bts
> 
> - -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_US.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages reportbug depends on:
> ii  apt1.8.2
> ii  python33.7.3-1
> ii  python3-reportbug  7.5.2
> ii  sensible-utils 0.0.12
> 
> reportbug recommends no packages.
> 
> Versions of packages reportbug suggests:
> pn  claws-mail   
> ii  debconf-utils1.5.72
> ii  debsums  2.2.3
> pn  dlocate  
> pn  emacs24-bin-common | emacs25-bin-common  
> ii  file 1:5.35-4
> ii  gnupg2.2.13-2
> ii  msmtp-mta [mail-transport-agent] 1.8.3-1
> pn  python3-urwid
> pn  reportbug-gtk
> ii  xdg-utils1.1.3-1
> 
> Versions of packages python3-reportbug depends on:
> ii  apt1.8.2
> ii  file   1:5.35-4
> ii  python33.7.3-1
> ii  python3-apt1.8.4
> ii  python3-debian 0.1.35
> ii  python3-debianbts  2.8.2
> ii  python3-requests   2.21.0-1
> 
> python3-reportbug suggests no packages.
> 
> - -- no debconf information
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl0y/yERHG5pY29vQGRl
> Ymlhbi5vcmcACgkQ5vmO4pLV7MueRQ//dv4r0brpbs8eJ+SktdFHpsDIbq/CX6Gb
> 0MrGQpMGNG+HFb2D3yszxuPCSuXqWK/Gw+ugeWvGrtJK91fCDoMg4xrgIFYtK1SL
> K4FkrY1fdgtUdXQWOcRUbfd8VxsbFmQQRbnAEdQMwjDpWBqvxFjsfFw1AqrdMRE0
> pOdWEoArEAUDA+uon+n4sXlpbdeiCmkc7NiME+7vQznn4/Dy+kPZ4+O1boTSERX4
> x1V7oGt8m5mwTRFxSuuEWdLejuyYVkPhI5y0HCwfZUEdMV9mShCqyPS9cnwBXIbT
> JGEUVwGJ9xdNOgmIe7OuNqjEjI3SUMqdA9pYWdAzkqc1iA/daQ7flRoY53OhWYZv
> cYWYWfWDiDPXBXiqvY+JQucwlW5XLdXF+m1/Go3AUslfRr5dLE9/1IvxRbs0F6k5
> C+vAA9TR0HjwLqlhIFBjorWy9PbKjfjHL71sfuhio3muCW6RM8/fo0/euxef+pCC
> OBLInDLZ6Wt9W7arrLsP86M5pxUK/1H8/dgNcbn9Hld7o2MzYswXnmlZFNkjT6MK
> 8QjsateHvpCjtIDIuERcZamZ7EQ3H7ByuTxXvbFl3oG1nDSTTRBjY/y1eeaib/q/
> 6d6Jb1Wm8tyG6U5bASOiEpstU1nbVDSQ3gsREdyCGG7+Z6cvZJF7s0AOhnhfQnLA
> YBV7oodJKG8=
> =Y8xj
> -END PGP SIGNATURE-
> 
From 44c2e337865dddcc39f8ab976014956a13fb72df Mon Sep 17 00:00:00 2001
From: Nicolas Braud-Santoni 
Date: Thu, 15 Aug 2019 00:40:57 +0200
Subject: [PATCH] utils: Update the CODENAME2SUITE mapping, following Buster's
 release

Closes: #932524
---
 reportbug/utils.py | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/reportbug/utils.py b/reportbug/utils.py
index 545504d..67c775c 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -93,13 +93,14 @@ fhs_directories = ['/', '/usr', '/usr/share', '/var', '/usr/X11R6',
'/usr/man', '/usr/doc', '/usr/bin']
 
 # A map between codenames and suites
-CODENAME2SUITE = {'wheezy': 'oldoldstable',
-'jessie': 'oldstable',
-'stretch': 'stable',
-'buster': 'testing',
-'bullseye': 'next-testing',
-'sid': 'unstable',
-'experimental': 'experimental'}
+CODENAME2SUITE = {'wheezy': 'oldoldoldstable',
+  'jessie': 'oldoldstable',
+  'stretch': 'oldstable',
+  'buster': 'stable',
+  'bullseye': 'testing',
+  'bookworm': 'next-testing',
+

Bug#934789: autopkgtest: test passes when it should fail; looks click and/or apparmor-related

[Antonio Terceiro]

Package: autopkgtest
Version: 5.10
Severity: important

8<8<8<-
$ cat debian/tests/control
Test-Command: false
Depends: dpkg

$ autopkgtest -B . -- lxc --sudo autopkgtest-stable-amd64
autopkgtest [19:08:21]: version 5.10
autopkgtest [19:08:21]: host lemur; command line: /usr/bin/autopkgtest -B . -- 
lxc --sudo autopkgtest-stable-amd64
autopkgtest [19:08:34]: testbed dpkg architecture: amd64
autopkgtest [19:08:35]: testbed running kernel: Linux 5.2.0-2-amd64 #1 SMP 
Debian 5.2.7-1 (2019-08-07)
autopkgtest [19:08:35]:  unbuilt-tree .
autopkgtest [19:08:35]: testing package fake-package version 0.1.0~FIXME-1
autopkgtest [19:08:35]: build not needed
autopkgtest [19:08:35]: test command1: preparing testbed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up autopkgtest-satdep (0) ...
(Reading database ... 12281 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [19:08:37]: Updating AppArmor rules to allow autopilot 
introspection for all clicks (will take a minute)...
sh: 1: cannot create /var/cache/apparmor/click-ap.rules: Directory nonexistent
autopkgtest [19:08:37]: test command1: false
autopkgtest [19:08:37]: test command1: [---
autopkgtest [19:08:38]: test command1: ---]
autopkgtest [19:08:38]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 PASS
autopkgtest [19:08:38]: Restoring click package AppArmor rules
sh: 1: aa-clickhook: not found
autopkgtest [19:08:38]:  summary
command1 PASS
8<8<8<-

notable/weird lines:

autopkgtest [19:08:37]: Updating AppArmor rules to allow autopilot 
introspection for all clicks (will take a minute)...
sh: 1: cannot create /var/cache/apparmor/click-ap.rules: Directory nonexistent

and

sh: 1: cannot create /var/cache/apparmor/click-ap.rules: Directory nonexistent


Running the same test locally with null virtualization (up to date unstable)
does the right thing:

8<8<8<-
$ autopkgtest -B . -- null
autopkgtest [19:29:20]: version 5.10
autopkgtest [19:29:20]: host lemur; command line: /usr/bin/autopkgtest -B . -- 
null
autopkgtest [19:29:20]: testbed dpkg architecture: amd64
autopkgtest [19:29:20]: testbed running kernel: Linux 5.2.0-2-amd64 #1 SMP 
Debian 5.2.7-1 (2019-08-07)
autopkgtest [19:29:20]:  unbuilt-tree .
autopkgtest [19:29:20]: testing package fake-package version 0.1.0~FIXME-1
autopkgtest [19:29:20]: build not needed
autopkgtest [19:29:20]: test command1: preparing testbed
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
autopkgtest [19:29:21]: test command1: false
autopkgtest [19:29:21]: test command1: [---
autopkgtest [19:29:21]: test command1: ---]
autopkgtest [19:29:21]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 1
autopkgtest [19:29:21]:  summary
command1 FAIL non-zero exit status 1
8<8<8<-

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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   1.8.3
ii  libdpkg-perl1.19.7
ii  procps  2:3.3.15-2
ii  python3 3.7.3-1
ii  python3-debian  0.1.35

Versions of packages autopkgtest recommends:
ii  autodep8  0.18

Versions of packages autopkgtest suggests:
ii  lxc   1:3.1.0+really3.0.4-1
pn  lxd   
ii  ovmf  0~20190606.20d2e5a1-2
ii  qemu-efi-aarch64  0~20190606.20d2e5a1-2
ii  qemu-efi-arm  0~20190606.20d2e5a1-2
ii  qemu-system   1:3.1+dfsg-8
ii  qemu-utils1:3.1+dfsg-8
ii  schroot   1.6.10-6+b1
ii  vmdb2 0.13.2+git20190215-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#934788: gst-plugins-good1.0 non-buildd binaries

[peter green]

Package: gst-plugins-good1.0
Version: 1.16.0-2
Severity: serious

The release team have decreed that non-buildd binaries can no longer migrate to 
testing, please make a source-only upload so your package can migrate.

Bug#934034: monkeysphere: FTBFS in stretch

[Chris Lamb]

Dear Niels,

>  1) The current bug metadata suggests it affects sid.  Please ensure the
> bug is resolved in sid (by fixing it in sid or correcting bug
> metadata as appropriate).

I cannot reproduce in buster, sid or experimental and have thus
adjusting the metadata of #934034 to match.

>  2) File an opu (and a separate pu bug if it also affects buster) with
> the full debdiff (including changelog). This ensures that the stable
> release team will get have a look at the issue.

I've filed this as #934775 and further I completely understand the
underlying reasons for insisting on such a process.

> Thanks for considering to fix bugs in stretch.

No problem; thank you for your advice and patient guidance.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org 🍥 chris-lamb.co.uk
   `-

Bug#931560: cups-backend-bjnp: refuses to print with "out of paper" error

[Louis Lagendijk]

hello,
Upstream developer/maintainer here.
Leonardo informed me of this bug, so I investigated the issue. It is
indeed related to the ink level implementation, but I do NOT regard
this as a bug.

Based on the logfile provided:

>From the report in ReadData it has:
CTK:M,IO,/,PBK,IO,/,GY,IO,/,BK,SET,/,C,IO,/,Y,LOW

So:
M: Magenta IO (ink out)
PBK: photo black: IO (ink out)
BK: normal black SET (ok)
C: Cyan: IO (ink out)
Y: Yellow: LOW (low but can still print)

any IO (ink out) value indeed stops the printing. Now I understood that
some(?) printers may continue to print under Windows as long as black
(I assume BK or was it PBK) does not run out, but see below.

When you check the actual levels 

CIR:M=000,PBK=000,GY=000,BK=100,C=000,Y=010;

you will see that most cartridges were empty (M, PBK, C were at 0, only
Y had some ink left. BK was 100% (values are in %), so continuing to
print might be dangerous for the print head UNLESS the printer or the
printer driver knows that it should not use the nozzles for those
colors. You will still get a bad quality printout, probably B/W only if
the printer can handle this on its own, without endangering the print
head.

The windows driver apparently has a way to notify the user and ask for
confirmation. It will quite likely avoid emitting any color info in the
printout, hence there is no danger to the print head.

This avoiding color is something we cannot do within CUPS, as the
backend receives an already rendered image. So I think that solving
this is not desirable (it would be only a one line change, but I am
really reluctant to change it as printing colors when the cartridge may
damage the printhead).

Your bug report caused me to find one real bug though, whereby CUPS
reports an out of paper instead of an out of ink. This will be solved
in the 2.0.3 version, due out later this week

Bug#929949: New upstream version 0.8 available, compatible with python3

[peter green]

Severity 929949 serious
Thanks.


Upstream rolled out a 0.8 version which is finally compatible with
python3, it would be nice to have it uploaded to Debian

The python-monotonic and python-fasteners packages have now dropped support for 
python2, so if duplicity is going to stay around it needs to migrate to python 
3.

Bug#934787: Please switch to Python 3

[Thomas Goirand]

Source: live-wrapper
Version: 0.10
Severity: important

Hi,

We're trying to remove Python 2.x from Bullseye. Please switch this package to
Python 3. I had a quick look into it, and it does seem Py3 ready. Is there
any blocker?

Cheers,

Thomas Goirand (zigo)

Bug#934776: xserver-xorg-video-intel: spelling mistake in package description

[Timo Aaltonen]

On 14.8.2019 19.36, Thorsten Glaser wrote:
> Package: xserver-xorg-video-intel
> Version: 2:2.99.917+git20180925-2
> Severity: wishlist
> 
> Please replace “it’s” (short for “it is”) with “its” (genitive form)
> in the package long Description.
> 
> (That being said, what benefits has the modesetting driver over the
> intel driver viceque versa? I encountered crashes during zooming in
> a map on a website with modesetting, and modesetting has OpenGL 2.x
> only — does a comparison exist? I’m on an IBM X61 with GM965.)

OpenGL 2.1 is what that GPU supports and nothing more, as you can see here:

https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units


-- 
t

Bug#934786: xen-system-amd64: xen host crashes when calling "npm run build" in a vm (reproducible)

[mario]

Package: xen-system-amd64
Version: 4.8.5+shim4.10.2+xsa282-1+deb9u11
Severity: important

hello everyone,

we have a vm with kernel 4.9.0-5-amd64 running dabian oldstable
if we run an "npm run build" on one of the virtual machines, the whole xen-host 
system will restart (reset)
there is no message, neither in the kernel nor in the syslog.

if we update the kernel of the virtual machine to 4.9.0-9-amd64, the problem is 
no longer there and the build runs without errors.

the kernel of the hosts system doesn't matter, even the latest 4.9.0-9-amd64 
doesn't help.

we have a second server (with different hardware) also here i can crash the 
complete xen-server from the vm with all vms that are running.

the whole thing works reproducible by starting "npm run build" on this special 
vm

any idea how we can narrow that down and provide more information???

kind regards
mario



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

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

Versions of packages xen-system-amd64 depends on:
ii  xen-hypervisor-4.8-amd64  4.8.5+shim4.10.2+xsa282-1+deb9u11
ii  xen-utils-4.8 4.8.5+shim4.10.2+xsa282-1+deb9u11

xen-system-amd64 recommends no packages.

xen-system-amd64 suggests no packages.

-- no debconf information

Bug#934453: curl: SSL

[Kurt Roeckx]

On Tue, Aug 13, 2019 at 09:09:35PM +0200, Sebastian Andrzej Siewior wrote:
> Yes, please. As an openssl dev you might have more luck. With a template
> I would ping the ssllabs folks :)

I've opened https://github.com/ssllabs/ssllabs-scan/issues/740

I think they're actually know enough about TLS to know what the
issue is.


Kurt

Bug#849091: Port to Python 3 and python3-gst-1.0

[Thomas Goirand]

Hi,

I'm surprised to see no reply from the maintainer(s) when this bug has
been opened in 2016. This isn't reassuring, and likely to cause the
package to drop from Debian, especially as the Python team is actively
doing Python 2 removal.

Is this transition to Python 3 planned? What does upstream say?

Thomas Goirand (zigo)

Bug#934502: Bug#672361: Bug#934502: lsb-base: avoid '\r' in logging functions

[Vincent Lefevre]

On 2019-08-14 19:21:01 +, Dmitry Bogatov wrote:
> [2019-08-13 16:48] Thorsten Glaser 
> > > Please, change format to following:
> >
> > just run:
> >
> > sudo sh -c 'echo FANCYTTY=0 >>/etc/lsb-base-logging.sh'
> 
> 
> > (On the other hand, now that “most” people, and especially the target
> > group of “fancy” logging, is using systemd instead, perhaps it’s time
> > to remove the fancy code entirely and go back to the classical output
> > entirely?)
> 
> I support this proposal. Any objections, collegues?

I think that there are no big issues with colors (all terminals and
"less" can handle them) and they can be useful to see failures more
easily. Thus I think that they shoud be kept.

/lib/lsb/init-functions.d/20-left-info-blocks is what should be
dropped actually since it involves cursor movements and is not
much useful. Moreover, the output can be wrong when the program
outputs warnings or error messages.

Then bootlogd should not do any filtering.

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

Bug#934264: Please update (4.6.2?) and provide/switch to python3

[Varun Hiremath]

Hi Yaroslav and Andreas,

On Fri, Aug 9, 2019 at 6:57 AM Yaroslav Halchenko 
wrote:

> > Remark: Since it seems the package is not really maintained by the
> > Uploader inside the PAPT team and entering the PAPT team might take a
> > bit longer I'd consider it a sensible step to take over the package to
> > Debian Science team to enable more people an easy access to the
> > repository.  I'm not keen on "nursing" merge requests of grown up
> > Python developers just because these are not part of PAPT team.
>
> well -- I guess that should be cleared up with the PAPT team / original
> uploaders (at least with Varun ?  any objections?)
>

I currently don't have time to work on mayav2 package, but feel free to
move it to Debain Science team repository if it helps with maintaining this
package, I don't have any objections.

Thanks,
Varun

Bug#934784: gnome-calendar: "All day" events are saved with the wrong date

[Webmailadress1]

Package: gnome-calendar
Version: 3.30.1-2
Severity: important

Dear Maintainer,

I recently installed Debian Buster and the gnome-calendar application seems
to behave weirdly with events lasting for a whole day.
Each time I save an existing event with the "all day" box ticked, the event
is saved with a date one day earlier...!

Steps to reproduce:

1. Open gnome-calendar
2. Create a new event. Name the event and make sure the box "All day" is 
checked. Save.
3. The event is displayed one day earlier than expected in the calendar.
4. Open the newly created event by clicking on it.
5. Do not modify anything, just hit the top right button 'Finish'.
6. Again, the event has moved one day earlier than expected.

I would expect that saving an existing event without modifying its date is
a no-op. I would also expect a new event to be saved with the correct date!
This is pretty annoying since almost all my events are "all day" events.

Editing such events directly from Evolution seems to work fine. I'd like to
add that I don't have my Debian connected with any online account
(Google, ...), and especially I didn't set up Evolution to access or send
emails.

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 gnome-calendar depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gsettings-desktop-schemas3.28.1-1
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libdazzle-1.0-0  3.30.2-2
ii  libecal-1.2-19   3.30.5-1
ii  libedataserver-1.2-233.30.5-1
ii  libedataserverui-1.2-2   3.30.5-1
ii  libgeoclue-2-0   2.5.2-1
ii  libglib2.0-0 2.58.3-2
ii  libgoa-1.0-0b3.30.1-2
ii  libgtk-3-0   3.24.5-1
ii  libgweather-3-15 3.28.2-2
ii  libical3 3.0.4-3
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libsoup2.4-1 2.64.2-2

Versions of packages gnome-calendar recommends:
ii  evolution-data-server  3.30.5-1

gnome-calendar suggests no packages.

-- no debconf information

Bug#934785: does not include lis.so driver

[Adam Di Carlo]

Package: lcdproc
Version: 0.5.9-3.1
Severity: normal

The package fails to include the lis.so module.

Which is odd, because I did a local build and lis.so is indeed built
and included with the 'lcdproc' package.

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

Kernel: Linux 4.19.0-5-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_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages lcdproc depends on:
ii  cme   1.029-1
ii  debconf [debconf-2.0] 1.5.71
ii  libc6 2.28-10
ii  libconfig-model-lcdproc-perl  2.052-2
ii  libftdi1  0.20-4
ii  libncurses6   6.1+20181013-2
ii  libtinfo6 6.1+20181013-2
ii  libusb-0.1-4  2:0.1.12-32
ii  libusb-1.0-0  2:1.0.22-2
ii  libx11-6  2:1.6.7-1
ii  lsb-base  10.2019051400
ii  udev  241-5

Versions of packages lcdproc recommends:
ii  lcdproc-extra-drivers  0.5.9-3.1

lcdproc suggests no packages.

-- Configuration Files:
/etc/lcdproc.conf changed [not included]

-- debconf information excluded

Bug#934779: libreoffice: Not read the "About LibreOffice" window contents

[Rene Engelhard]

tag 934779 + moreinfo
thanks

Hi,

On Wed, Aug 14, 2019 at 09:51:33PM +0300, Сергей Фёдоров wrote:
> Debian Release: bullseye/sid
  
>   APT prefers unstable

>   APT policy: (500, 'unstable')
^
> Architecture: i386 (i686)
[...]
> In a 32-bit Debian 10 in the "About LibreOffice" window in the mode "Window" 
> or
 ^^

No, you are definitely not using Debian 10.

You are using what is the development suite for what will become Debian
11 in some years.

Anyways:

> "Maximize" background color why black, so pale gray letters are almost 
> invisible
> on a black background. Light gray background in the lower left corner
> of the window, where black letters are clearly visible, takes only about 10%
> of a window. In a 64-bit Debian 10 if that window takes about a quarter
> of the screen size, you can not see anything at all, if more, then the lower
> left corner of the window begins to appear black letters on a light gray
> background, but not completely.

I can't parse that. What do you want to say? What is your theme? Did you
switch LO to hicontrast or something? What desktop? More information,
please.

At least here in a Debian sid VM (on amd64) in GNOME it looks OK.

Regards,

Rene

Bug#865847: Use reStructuredText for Lintian manual

[Felix Lechner]

Hi Chris,

On Mon, Aug 12, 2019 at 2:09 PM Chris Lamb  wrote:
>
> I would concede that RST might be more suitable for more complex
> requirements indeed.

Ok, I am going to merge this soon. At least it's a step in the right
direction. Let's see if we all can get comfortable with the RST
format.

I am currently writing a brief testing manual. (After that, I hope to
freeze the list of untested tags.) That will be a good experiment from
all sides with respect to the format.

Thank you to Russ for the comment about the policy document. I would
have preferred more consensus; perhaps it is safe to say that we are
all -1 on docbook.

Kind regards,
Felix

Bug#934783: mongodb: CVE-2019-2386

[Salvatore Bonaccorso]

Source: mongodb
Version: 1:3.4.18-2
Severity: grave
Tags: security upstream
Forwarded: https://jira.mongodb.org/browse/SERVER-38984

Hi,

The following vulnerability was published for mongodb.

CVE-2019-2386[0]:
| After user deletion in MongoDB Server the improper invalidation of
| authorization sessions allows an authenticated user's session to
| persist and become conflated with new accounts, if those accounts
| reuse the names of deleted ones. This issue affects: MongoDB Inc.
| MongoDB Server v4.0 versions prior to 4.0.9; v3.6 versions prior to
| 3.6.13; v3.4 versions prior to 3.4.22.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-2386
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2386
[1] https://jira.mongodb.org/browse/SERVER-38984
[2] https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0829

Regards,
Salvatore

Bug#934749: welle.io: some icons & widgets not displayed

[Fab Stz]

Upstream bugreport can be found here :

https://github.com/AlbrechtL/welle.io/issues/387

Bug#931591: Buster: upgraded Handbrake crashes on encode with custom preset

[Bernhard Übelacker]

Hello Seth Foley,
if possible you could now install gdb
and the following debug symbol packages.
The latter are stored in a separate
repository, more details in [1]:

handbrake-dbgsym libavformat58-dbgsym

Then if you have not rebooted since the last
handbrake crash, you can use following commands:

coredumpctl list
coredumpctl gdb 
  bt
  quit

And forward the output again to this bug.

Maybe you want one copy one of the cores in
/var/lib/systemd/coredump/ to a safe place,
because after some time they get automatically deleted.

>From your last output I guess something like in [2]
would be produced.

Unfortunately I have not found any bugreport in
the upstream projects.

What I find in the sources it looks like avio_open2
is called with an invalid pointer in filename later,
but maybe the maintainer know something more...

Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols

[2]
Stack trace of thread 25962:  | 
#0  0x7f7ce7188fb4 n/a (libc.so.6)|
0x732fcfb4 ../sysdeps/x86_64/strspn.S:88
#1  0x7f7cebc47e73 n/a (libavformat.so.58)| 0x77dbbe6e 
0x77dbbe73 in url_find_protocol at src/libavformat/avio.c:255
#2  0x7f7cebc48102 n/a (libavformat.so.58)| 0x77dbc0fd 
0x77dbc102 in ffurl_alloc at src/libavformat/avio.c:295
#3  0x7f7cebc48a2e n/a (libavformat.so.58)| 0x77dbca29 
0x77dbca2e in ffurl_open_whitelist at src/libavformat/avio.c:314
#4  0x7f7cebc4d187 n/a (libavformat.so.58)| 0x77dc1182 
0x77dc1187 in ffio_open_whitelist at src/libavformat/aviobuf.c:1167
#5  0x7f7cebc4d1ee avio_open2 (libavformat.so.58) | 0x77dc11e9 
0x77dc11ee in avio_open2 at src/libavformat/aviobuf.c:1181
#6  0x561ecd32d8fd n/a (ghb)  | 0x5561f8f8 
0x5561f8fd in avformatInit at ../libhb/muxavformat.c:179
#7  0x561ecd2e4112 n/a (ghb)  | 0x555d6110 
0x555d6112 in muxInit at ../libhb/muxcommon.c:649
#8  0x561ecd317e56 n/a (ghb)  | 0x55609e53 
0x55609e56 in do_job at ../libhb/work.c:1758
#9  0x561ecd2d607b n/a (ghb)  | 0x555c8078 
0x555c807b in hb_thread_func at ../libhb/ports.c:867
#10 0x7f7ce9457fa3 start_thread (libpthread.so.0) | 0x755cbfa1 
0x755cbfa3 in start_thread at pthread_create.c:486
#11 0x7f7ce71e04cf __clone (libc.so.6)| 0x733544cd 
0x733544cf ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

# Buster/stable amd64 qemu VM 2019-08-14


apt update
apt dist-upgrade


apt install systemd-coredump gdb mc handbrake handbrake-dbgsym 
libavformat58-dbgsym
apt build-dep handbrake



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

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



gdb -q --args /usr/bin/handbrake

set width 0
set pagination off
directory /home/benutzer/source/handbrake/orig/handbrake-1.2.2+ds1/gtk/src
directory /home/benutzer/source/ffmpeg/orig/ffmpeg-4.1.3/libavformat
directory /home/benutzer/source/handbrake/orig/handbrake-1.2.2+ds1/libhb
set backtrace past-main
display/i $pc
tb main
run
generate-core-file /tmp/core



gdb -q /usr/bin/handbrake --core /tmp/core

set width 0
set pagination off
directory /home/benutzer/source/handbrake/orig/handbrake-1.2.2+ds1/gtk/src
directory /home/benutzer/source/ffmpeg/orig/ffmpeg-4.1.3/libavformat
directory /home/benutzer/source/handbrake/orig/handbrake-1.2.2+ds1/libhb
set backtrace past-main
display/i $pc



benutzer@debian:~$ gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 
'info target' -ex 'quit' 2>&1 | grep -E ".text$"
0x55584fe0 - 0x55624ea1 is .text

gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 'disassemble 
0x55584fe0,0x55624ea1' -ex 'quit' 2>&1 | grep -E "07b " -B1 | 
grep call -A1
# Multiple candidates

gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 'disassemble 
0x55584fe0,0x55624ea1' -ex 'quit' 2>&1 | grep -E "e56 " -B1 | 
grep call -A1
# Multiple candidates

gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 'disassemble 
0x55584fe0,0x55624ea1' -ex 'quit' 2>&1 | grep -E "112 " -B1 | 
grep call -A1
# Multiple candidates

benutzer@debian:~$ gdb -q /usr/bin/handbrake --core /tmp/core --ex 'batch' --ex 
'disassemble 0x55584fe0,0x55624ea1' -ex 'quit' 2>&1 | grep -E 
"avio_open2" -A1
   0x5561f8f8 :   callq  0x55581be0 

   0x5561f8fd :   test   %eax,%eax







Stack trace of thread 25962:  | 
#0  0x7f7ce7188fb4 n/a (libc.so.6)|
0x732fcfb4 ../s

Bug#934749: welle.io: some icons & widgets not displayed

[Fab Stz]

Hello,

I found out that the problem is actually the package "qml-module-org-kde-
qqc2desktopstyle" which is installed with plasma/kde
When one uses that desktop, this package can not be removed. Moreover, this is 
the style that is used as soon as one uses KDE/Plasma
However, when I rename the folder /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/
Controls.2/org.kde.desktop
then I don't have anymore these icon & display issues

Nevertheless it is possible to define environment Variables for Qt Quick 
Controls 2 :)
Thus the workaround for now is to load welle-io with QT_QUICK_CONTROLS_STYLE 
defined

The styles that work best are :
- Universal
- designer

With :
- Material
- Imagine
- Fusion 
there are some issues (with the dropdown list, or colors of text/icons 
depending on background)

With "org.kde.desktop" there are even more issues (that I described initially 
in this bug report)

My current choice is running it with Universal (which can also be themed):
QT_QUICK_CONTROLS_STYLE=Universal welle-io


Other ways to control the QML style are defined here (either in the code 
configuration or through env Variables):
https://doc.qt.io/qt-5/qtquickcontrols2-environment.html
https://doc.qt.io/qt-5/qtquickcontrols2-configuration.html


For reference, the version of qml-module-org-kde-qqc2desktopstyle on my system 
at the time of the report is 5.54.0-1 (currently in buster/stable, testing & 
sid)

Bug#934500: dh-runit: permissions of supervise directory

[Dmitry Bogatov]

[2019-08-12 10:10] Lorenz 
> [...]

> I don't see a strong reason to have persistent supervise directories: the
> files inside are mostly (if not all) not recyclable, bug like #919296
> proves that pre-create files with the porpose of speeding up the start of a
> runsv process doesn't work.

> Moreover, if i recall correcly, Debian's runit already need to rely on /run
> if it wants to become /etc readonly proof.
> Let me know in advance if you are going this way, I will prepare a patch
> for update-service too.

Yes, I go this way.

PS. I am positive I did wrote reply to this mail several days ago. How
did I managed to blackhole it? Hm...
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#922642: possible implementation

[Dmitry Bogatov]

[2019-08-13 10:43] Shengjing Zhu 
> > [2019-08-11 22:54] Shengjing Zhu 
> > > This C patch works for me. But I have another approach now.
> > >
> > > Add following script as /usr/bin/execlineb
> > >
> > > #!/usr/lib/execline/bin/execlineb -S0
> > > /usr/lib/execline/bin/importas -D
> > > /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PATH PATH
> > > /usr/lib/execline/bin/export PATH /usr/lib/execline/bin:${PATH}
> > > /usr/lib/execline/bin/exec -a $0 /usr/lib/execline/bin/execlineb $@
> > >
> > > What do you think?
> >
> > Good, very good. But it will only work on Linux. kFreeBSD does not
> > permit scripts (not ELF binaries) to be used as interpreters.
>
> The first time to know that. But execline currently is only
> (successfully) built on linux.

Okay. Probably you want set 'arch: linux-any' then or re-write
/usr/bin/execlineb script in C, like this:

int main(int argc, char **argv)
{
char *new_argv[argc + 20];
new_argv[0] = "/usr/lib/execline/bin/importas";
new_argv[1] = "/usr/lib/execline/bin/importas";
new_argv[2] = "-D";
// etc.
memcpy(new_argv + ?, argv, argc * sizeof(char*));
execv(new_argv[0], new_argv);
}

I do not have strong opinion, I only use Linux kernel.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#931658: runit-init: Boot hangs with QEMU if openssh-server is installed

[Dmitry Bogatov]

[2019-07-13 08:28] Dmitry Bogatov 
> [2019-07-09 15:11] Lorenz 
> > Il giorno mar 9 lug 2019 alle ore 01:52 Colin Watson 
> > ha scritto:
> > >Is this just another instance of problems with your virtual machine not
> > >having enough entropy (#912616 etc.)?
> >
> > It looks you are right, thanks for the tip!
> >
> > Dmitry, I can pass the test that include openssh-server with a command like
> > (see #912087 message 118)
> >
> > $ autopkgtest ./runit-init_2.1.2-32_all.deb ./runit_2.1.2-32_amd64.deb
> >  ./runit  \
> > -- qemu --qemu-options='-object rng-random,filename=/dev/urandom,id=rng0
> > -device virtio-rng-pci,rng=rng0' \
> > ./debian-unstable.img
>
> Confirmed. Your solution works.
> [...]

> > This rely on the host having enough entropy and i'm not sure how to pass
> > those options to salsa CI
>
> Is it possible to run Qemu on Salsa at all?

It seems there no. I tried to reach DSA, Salsa admins and admins of
ci.debian.org, and got nothing.

So best I have is following patch, that wrap all these complicated qemu
option behind `make -f debian/autopkgtest`. It is still to be run
manually on someone's laptop.

Any better ideas?

From 8477e1de56e5ccd1d4be78704e9298d075a166f9 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 14 Aug 2019 04:47:37 +
Subject: [PATCH] Add manual rule to run autopkgtest

Currently, Debian does not provide infrastructure to run autopkgtests with
{isolation-machine} restriction. Additionally, {switch-init} autopkgtest
requires significant entropy level in virtual machine, so virtual machine must
be started with very specific options.

This change adds new rules into {debian/rules}, intended to be run
manually. These rules create virtual machine image and run autopkgtests with
required virtual image options.

Closes: #931658
---
 debian/rules | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/debian/rules b/debian/rules
index 0e287cf..682a580 100755
--- a/debian/rules
+++ b/debian/rules
@@ -43,3 +43,25 @@ override_dh_installchangelogs:
 override_dh_clean:
rm -rf debian/auto
dh_clean
+
+autopkgtest-image:
+   autopkgtest-build-qemu unstable ../autopkgtest.img
+
+autopkgtest:
+   $(info Running autopkgtest with options to avoid entropy starvation)
+   $(info For more information see #931658)
+ifeq ($(wildcard ../autopkgtest.img),)
+   $(error Qemu image ../autopkgtest.img not found. Run autopkgtest-image 
rule)
+endif
+ifeq ($(wildcard ../runit_$(DEB_VERSION)_$(DEB_BUILD_ARCH).deb),)
+   $(error No binary packages in parent directory. Build package)
+endif
+   autopkgtest\
+   ../runit-init_$(DEB_VERSION)_all.deb   \
+   ../runit_$(DEB_VERSION)_$(DEB_BUILD_ARCH).deb  \
+   .  \
+   -- qemu\
+   --qemu-options='-object rng-random,filename=/dev/urandom,id=rng0 
-device virtio-rng-pci,rng=rng0' \
+   ../autopkgtest.img
+
+PHONY: autopkgtest autopkgtest-image
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#672361: Bug#934502: lsb-base: avoid '\r' in logging functions

[Dmitry Bogatov]

[2019-08-13 16:48] Thorsten Glaser 
> > Please, change format to following:
>
> just run:
>
>   sudo sh -c 'echo FANCYTTY=0 >>/etc/lsb-base-logging.sh'


> (On the other hand, now that “most” people, and especially the target
> group of “fancy” logging, is using systemd instead, perhaps it’s time
> to remove the fancy code entirely and go back to the classical output
> entirely?)

I support this proposal. Any objections, collegues?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#607277: Fw:Mi auguro che la tua giornata di lavoro sia appagante

[bpgm]

Sono rimasto colpito da questo http://ratewhafen1987.blogspot.ru/




Prenditi cura di te,bpgm

Bug#934662: grace: Font mapping breaks with base35 *.t1 fonts

[Drew Parsons]

Package: grace
Version: 1:5.1.25-6
Followup-For: Bug #934662

I can confirm that the fonts in grace have been badly broken for a
month or more now, with the error message "Failed mapping a font"
emitted.

I confirm also that Carlo's patch fixes the problem, restoring fonts
to the expected usability.

This is an important bug for grace, arguably serious. Please apply the
patch as soon as possible. 

Drew

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

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

Versions of packages grace depends on:
ii  fontconfig2.13.1-2
ii  gsfonts   1:8.11+urwcyr1.0.7~pre44-4.4
ii  libc6 2.28-10
ii  libfftw3-double3  3.3.8-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libnetcdf13   1:4.6.2-1
ii  libpng16-16   1.6.37-1
ii  libx11-6  2:1.6.7-1
ii  libxbae4m 4.60.4-7+b11
ii  libxm42.3.8-2
ii  libxmhtml1.1  1.1.10-3
ii  libxmu6   2:1.1.2-2+b3
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1+b3
ii  xterm 348-1

Versions of packages grace recommends:
ii  xfonts-100dpi  1:1.0.4+nmu1
ii  xfonts-75dpi   1:1.0.4+nmu1

Versions of packages grace suggests:
ii  gconf2   3.2.6-5
ii  ghostscript  9.27~dfsg-3
ii  texlive-extra-utils  2019.20190710-1

-- no debconf information

Bug#934782: hardening-runtime: Small typo in provided README.Debian for instruction to disable settings

[Salvatore Bonaccorso]

Package: hardening-runtime
Version: 1
Severity: minor
Control: tags -1 + patch

Hi Yves-Alexis

There is a small typo in the README.Debian for the instruction to
disable the packaging provided settings in /usr/lib/sysctl.d.

Regards,
Salvatore

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From c51a0ec01ec099562ad8ca50aa5f9d985d697179 Mon Sep 17 00:00:00 2001
From: Salvatore Bonaccorso 
Date: Wed, 14 Aug 2019 21:08:02 +0200
Subject: [PATCH] Reverse order of wording to disable settings via symlink

The used symlink is in /etc/sysctl.d (using the same filename) with
target /dev/null to override the settings as provided by the packaging
in /usr/lib/sysctl.d/.

Signed-off-by: Salvatore Bonaccorso 
---
 debian/README.Debian | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/README.Debian b/debian/README.Debian
index 95e4afdb9d8d..5ba3bc764972 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -36,5 +36,5 @@ and systemd-sysctl.service(8) with a configuration file in 
/usr/lib/sysctl.d.
 
 These settings can be overridden by copying the file in /etc/sysctl.d/ (and
 keeping the same filename) and then doing edits. The file can also be
-completely disabled by adding a symlink from /dev/null to /etc/sysctl.d (again
-using the same filename)
+completely disabled by adding a symlink from /etc/sysctl.d (again using
+the same filename) to /dev/null.
-- 
2.23.0.rc1

Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3

[Tobias Frost]

On Wed, Aug 07, 2019 at 07:00:23AM +0100, Olly Betts wrote:
> On Wed, Aug 07, 2019 at 06:14:45AM +0100, Olly Betts wrote:
> > On Wed, Aug 07, 2019 at 06:04:58AM +0100, Olly Betts wrote:
> > > I don't have a hidpi display and don't know if it's possible to simulate
> > > one.  I don't run Gnome either...
> > 
> > Aha, I see in https://trac.wxwidgets.org/ticket/17391 that one can
> > simulate with e.g. GDK_SCALE=2 in the environment.
> 
> Which makes me wonder - can one explicitly set GDK_SCALE=1 to workaround
> the problem when using a hidpi display?  Presumably that results in any
> non-OpenGL content in the window being smaller than ideal, but probably
> it's like that anyway if one sticks with GTK2.

Indeed, that works. And yes, other stuff gets tiny (e.g. buttons and their
icons), but this issue is (still but) less painful than the other…


> Cheers,
> Olly

-- 
tobi

Bug#934781: firmware-iwlwifi: iwl4965: Microcode SW error detected

[Thorsten Glaser]

Package: firmware-iwlwifi
Version: 20190717-1
Severity: normal

My WLAN just crashed, no load (an ssh session and some chat).

Full dmesg (microcode error shown near bootom) follows:

[0.00] microcode: microcode updated early to revision 0xba, date = 
2010-10-03
[0.00] Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-19)) #1 SMP Debian 4.19.37-6 (2019-07-18)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/sda4 
ro rootdelay=5 syscall.x32=y vsyscall=emulate net.ifnames=0 kaslr 
pcie_aspm=force consoleblank=0
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000d2000-0x000d3fff] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xbf6a] usable
[0.00] BIOS-e820: [mem 0xbf6b-0xbf6cbfff] ACPI data
[0.00] BIOS-e820: [mem 0xbf6cc000-0xbf6f] ACPI NVS
[0.00] BIOS-e820: [mem 0xbf70-0xbfff] reserved
[0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed003ff] reserved
[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00023bff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.4 present.
[0.00] DMI: LENOVO 7673AG4/7673AG4, BIOS 7NET30WW (1.11 ) 11/15/2007
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 1995.136 MHz processor
[0.011703] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.011707] e820: remove [mem 0x000a-0x000f] usable
[0.011715] last_pfn = 0x23c000 max_arch_pfn = 0x4
[0.011723] MTRR default type: uncachable
[0.011724] MTRR fixed ranges enabled:
[0.011725]   0-9 write-back
[0.011726]   A-B uncachable
[0.011727]   C-C write-protect
[0.011728]   D-D uncachable
[0.011729]   E-F write-protect
[0.011730] MTRR variable ranges enabled:
[0.011732]   0 base 0C000 mask FC000 uncachable
[0.011734]   1 base 23C00 mask FFC00 uncachable
[0.011735]   2 base 0 mask E write-back
[0.011736]   3 base 2 mask FC000 write-back
[0.011738]   4 base 0BF70 mask 0 uncachable
[0.011739]   5 base 0BF80 mask FFF80 uncachable
[0.011740]   6 disabled
[0.011741]   7 disabled
[0.012744] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.013193] e820: update [mem 0xbf70-0x] usable ==> reserved
[0.013201] last_pfn = 0xbf6b0 max_arch_pfn = 0x4
[0.021443] found SMP MP-table at [mem 0x000f6980-0x000f698f]
[0.027758] Base memory trampoline at [(ptrval)] 97000 size 24576
[0.027765] BRK [0x21ea01000, 0x21ea01fff] PGTABLE
[0.027768] BRK [0x21ea02000, 0x21ea02fff] PGTABLE
[0.027770] BRK [0x21ea03000, 0x21ea03fff] PGTABLE
[0.027823] BRK [0x21ea04000, 0x21ea04fff] PGTABLE
[0.027826] BRK [0x21ea05000, 0x21ea05fff] PGTABLE
[0.028021] BRK [0x21ea06000, 0x21ea06fff] PGTABLE
[0.028042] BRK [0x21ea07000, 0x21ea07fff] PGTABLE
[0.028089] BRK [0x21ea08000, 0x21ea08fff] PGTABLE
[0.028155] BRK [0x21ea09000, 0x21ea09fff] PGTABLE
[0.028176] BRK [0x21ea0a000, 0x21ea0afff] PGTABLE
[0.028197] BRK [0x21ea0b000, 0x21ea0bfff] PGTABLE
[0.028217] BRK [0x21ea0c000, 0x21ea0cfff] PGTABLE
[0.028267] RAMDISK: [mem 0x33f8b000-0x35fbcfff]
[0.028279] ACPI: Early table checksum verification disabled
[0.028358] ACPI: RSDP 0x000F6950 24 (v02 LENOVO)
[0.028364] ACPI: XSDT 0xBF6BD48C 94 (v01 LENOVO TP-7N
1110  LTP )
[0.028372] ACPI: FACP 0xBF6BD600 F4 (v03 LENOVO TP-7N
1110 LNVO 0001)
[0.028378] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Gpe0Block: 64/32 (20180810/tbfadt-569)
[0.028382] ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid 
Address but zero Length: 0x102C/0x0 (20180810/tbfadt-624)
[0.028389] ACPI: DSDT 0xBF6BD9DB 00E206 (v01 LENOVO TP-7N
1110 MSFT 0300)
[0.028394] ACPI: FACS 0xBF6E4000 40
[0.028398] ACPI: FAC

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Simon McVittie]

On Wed, 14 Aug 2019 at 19:41:08 +0100, Mark Hindley wrote:
> I have managed to work around this today. It requires circumventing the 
> systemd
> prerm failure. I am not recommending that as a final solution, but maybe we 
> can
> have another go at asking the systemd maintainers to review it?

Please do; they might have a better idea of how this can work, and
it's them that you'll need to coordinate with for the libsystemd0 and
libelogind0 providers of libsystemd.so.0 to not fight (more than they
have to) anyway.

smcv

Bug#934780: tiff: CVE-2019-14973

[Salvatore Bonaccorso]

Source: tiff
Version: 4.0.10-4
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for tiff.

CVE-2019-14973[0]:
| _TIFFCheckMalloc and _TIFFCheckRealloc in tif_aux.c in LibTIFF through
| 4.0.10 mishandle Integer Overflow checks because they rely on compiler
| behavior that is undefined by the applicable C standards. This can,
| for example, lead to an application crash.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-14973
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14973
[1] https://gitlab.com/libtiff/libtiff/merge_requests/90
[2] 
https://gitlab.com/libtiff/libtiff/commit/1b5e3b6a23827c33acf19ad50ce5ce78f12b3773

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#934132: Processed: #934132: Raise severity to important

[Jonathan Wiltshire]

On Sat, Aug 10, 2019 at 10:55:39AM +0100, Mark Hindley wrote:
> On Fri, Aug 09, 2019 at 02:05:52PM +0100, Jonathan Wiltshire wrote:
> > For the time being, yes, and for the reasons outlined in the initial bug
> > report.
> 
> Those were my (hopefully impartial) summary.
> 
> I also went on to comment on each of the items in detail and explain why they
> were not of sufficient concern to warrant a block. Are there still outstanding
> concerns?

I think your summary is fine. However, this is not my area of expertise and
I'm rather hoping Julien or Ansgar will chime in with an update.

It certainly wouldn't be appropriate for me to remove a block put in place
by someone else without extenuating circumstances.

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#932790: buster-pu: package cacti/1.2.2+ds1-2+deb10u1

[Jonathan Wiltshire]

On Sun, Aug 11, 2019 at 03:09:27PM +0100, Adam D. Barratt wrote:
> On Sun, 2019-08-11 at 14:56 +0100, Jonathan Wiltshire wrote:
> > Control: tag -1 confirmed pending
> > 
> > On Tue, Jul 23, 2019 at 11:38:50AM +0200, Paul Gevers wrote:
> > > After the release of buster, an upgrade issue was reported against
> > > cacti, bug #931702, which has been fixed upstream. I decided to fix
> > > two
> > > additional reported issues at the same time, which can cause loss
> > > of
> > > functionality when upgrading from stretch.
> > 
> > Has been accepted, but for some reason the mail didn't come through
> > setting the tags. Weird.
> 
> The relevant field in the comment file is set to #930942, which
> looks... wrong. :-)

Oh, that would certainly... *ahem*

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#934778: libgsd 1.14.46 available

[Sebastien Bacher]

Package: libgsf
Version: 1.14.45-1 

There is a new version available fixed some warnings and a segfault, it
would be nice to have it uploaded to Debian
http://ftp.acc.umu.se/pub/gnome/sources/libgsf/1.14/libgsf-1.14.46.news

Thanks,

Bug#934779: libreoffice: Not read the "About LibreOffice" window contents

[Сергей Фёдоров]

Package: libreoffice
Version: 1:6.3.0-2
Severity: normal

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

Kernel: Linux 5.2.0-2-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8), 
LANGUAGE=ru_RU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libreoffice depends on:
ii  libreoffice-base1:6.3.0-2
ii  libreoffice-calc1:6.3.0-2
ii  libreoffice-core1:6.3.0-2
ii  libreoffice-draw1:6.3.0-2
ii  libreoffice-impress 1:6.3.0-2
ii  libreoffice-math1:6.3.0-2
ii  libreoffice-report-builder-bin  1:6.3.0-2
ii  libreoffice-writer  1:6.3.0-2
ii  python3-uno 1:6.3.0-2

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-liberation1:1.07.4-10
pn  fonts-liberation2   
ii  fonts-linuxlibertine5.3.0-4
pn  fonts-noto-core 
ii  fonts-noto-mono 20181227-1
pn  fonts-noto-ui-core  
ii  fonts-sil-gentium-basic 1.102-1
ii  libreoffice-java-common 1:6.3.0-2
ii  libreoffice-nlpsolver   0.9+LibO6.3.0-2
ii  libreoffice-report-builder  1:6.3.0-2
ii  libreoffice-script-provider-bsh 1:6.3.0-2
ii  libreoffice-script-provider-js  1:6.3.0-2
ii  libreoffice-script-provider-python  1:6.3.0-2
ii  libreoffice-sdbc-mysql  1:6.3.0-2
ii  libreoffice-sdbc-postgresql 1:6.3.0-2
ii  libreoffice-wiki-publisher  1.2.0+LibO6.3.0-2

Versions of packages libreoffice suggests:
ii  cups-bsd2.2.10-6
ii  default-jre [java6-runtime] 2:1.11-72
ii  firefox-esr 60.8.0esr-1
ii  ghostscript 9.27~dfsg-3
ii  gnupg   2.2.17-3
pn  gpa 
ii  gstreamer1.0-libav  1.16.0-2
ii  gstreamer1.0-plugins-bad1.16.0-2
ii  gstreamer1.0-plugins-base   1.16.0-2
ii  gstreamer1.0-plugins-good   1.16.0-2+b1
ii  gstreamer1.0-plugins-ugly   1.16.0-2
ii  hunspell-en-us [hunspell-dictionary]1:2018.04.16-1
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  imagemagick 8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1
ii  libgl1  1.1.0-1
pn  libreoffice-gnome | libreoffice-kde5
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
ii  libreoffice-librelogo   1:6.3.0-2
pn  libreoffice-officebean  
ii  libsane 1.0.27-3.2
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
ii  mythes-en-us [mythes-thesaurus] 1:6.3.0-1
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-11-jre [java6-runtime]  11.0.4+11-1
ii  openjdk-8-jre [java6-runtime]   8u222-b10-1
pn  pstoedit
pn  unixodbc

Versions of packages libreoffice-core depends on:
ii  fontconfig  2.13.1-2
ii  fonts-opensymbol2:102.11+LibO6.3.0-2
ii  libboost-date-time1.67.01.67.0-13
ii  libboost-locale1.67.0   1.67.0-13
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libclucene-contribs1v5  2.3.3.4+dfsg-1
ii  libclucene-core1v5  2.3.3.4+dfsg-1
ii  libcmis-0.5-5v5 0.5.2-1
ii  libcups22.2.10-6
ii  libcurl3-gnutls 7.65.3-1
ii  libdbus-1-3 1.12.16-1
ii  libdconf1   0.30.1-2
ii  libeot0 0.01-5
ii  libepoxy0   1.5.3-0.1
ii  libexpat1   2.2.7-1
ii  libexttextcat-2.0-0 3.4.5-1
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-4
ii  libgcc1 1:9.1.0-10
ii  libglib2.0-02.60.6-1
ii  libgpgmepp6  

Bug#934662: grace: Font mapping breaks with base35 *.t1 fonts

[Carlo Segre]

I have attached a patch to the /usr/sbin/update-grace-fonts script which 
will provide the kludgy solution described in my original submission.


It is also inserted below

Carlo

--- /usr/sbin/update-grace-fonts~   2018-04-28 12:50:28.0 -0500
+++ /usr/sbin/update-grace-fonts2019-08-14 13:31:38.934916736 -0500
@@ -12,10 +12,15 @@
 my($odir, $cdir) = @_;
 opendir(my $dh, $odir);
 my @files = readdir($dh);
+# New variable
+my $modfilename;
 foreach (@files) {
-   next if (/^\./);
-   recursiveLink("$odir/$_", $cdir) if -d "$odir/$_";
-   symlink("$odir/$_", "$cdir/$_") if -f "$odir/$_";
+next if (/^\./);
+recursiveLink("$odir/$_", $cdir) if -d "$odir/$_";
+# Set file name to new variable, strip ".t1" from end of it if it's there
+$modfilename = $_;
+$modfilename =~ s/\.t1$//;
+symlink("$odir/$_", "$cdir/$modfilename") if -f "$odir/$_";
 }
 closedir($dh);
 }


--
Carlo U. Segre -- Duchossois Leadership Professor of Physics
Directory, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org--- /usr/sbin/update-grace-fonts~   2018-04-28 12:50:28.0 -0500
+++ /usr/sbin/update-grace-fonts2019-08-14 13:31:38.934916736 -0500
@@ -12,10 +12,15 @@
 my($odir, $cdir) = @_;
 opendir(my $dh, $odir);
 my @files = readdir($dh);
+# New variable
+my $modfilename;
 foreach (@files) {
-   next if (/^\./);
-   recursiveLink("$odir/$_", $cdir) if -d "$odir/$_";
-   symlink("$odir/$_", "$cdir/$_") if -f "$odir/$_";
+next if (/^\./);
+recursiveLink("$odir/$_", $cdir) if -d "$odir/$_";
+# Set file name to new variable, strip ".t1" from end of it if it's there
+$modfilename = $_;
+$modfilename =~ s/\.t1$//;
+symlink("$odir/$_", "$cdir/$modfilename") if -f "$odir/$_";
 }
 closedir($dh);
 }

Bug#934777: libexosip2: New upstream version

[Salvatore Bonaccorso]

Source: libexosip2
Severity: normal

Hi

There is a new upstream version for libexosip2 (which is not catched
from debian/watch because of the tarball name changes upstream, with
5.0.0 release they changed from libeXosip2-... to libexosip2-...)

Is the libexosip2 actually still useful to be kept? The version is
severly outdated and at same version since jessie. There are as well
no reverse (build) dependencies on it.

Regards,
Salvatore

Bug#934491: libelogind0: failing to switch from systemd to sysvinit-core/elogind results in libsystemd.so.0 disappearing

[Mark Hindley]

On Tue, Aug 13, 2019 at 07:58:09PM +0100, Mark Hindley wrote:
> Thorsten,
> 
> Thanks for this.
> 
> On Tue, Aug 13, 2019 at 04:46:32PM +0200, Thorsten Glaser wrote:
> > On Sun, 11 Aug 2019, Simon McVittie wrote:
> > 
> > > Found while preparing a test VM to test #923240. Please raise this to
> > > RC severity if you think it is justified - I don't want to create the
> > 
> > I don’t think it’s RC in any of the involved packages (elogind,
> > systemd (shock!), apt) because it’s really a whole-system / package
> > management issue.
> 
> Yes, that is my conclusion after 2 days of trying different things. Certainly
> systemd's prerm failure is pretty brutal. But this happens before any of the
> src:elogind preinsts run, so I can't see a way around it. If anything, it is a
> limitation in apt (although I am not trying to pass the buck here).

I have managed to work around this today. It requires circumventing the systemd
prerm failure. I am not recommending that as a final solution, but maybe we can
have another go at asking the systemd maintainers to review it?

What works for me on a sid VM:

 1) rmdir /run/systemd/system

This is the directory that the systemd prerm checks for.

 2) apt install libpam-elogind systemd-

 3) Immediate reboot with shutdown -r -n

Although systemd as PID 1 no longer functions, all processes are sent
SIGTERM, filesystems are synced and unmounted.

I realise this is not graceful or elegant and I am unsure how safe it is.

Comments?

Perhaps we could ask that the systemd prerm no longer fails but instead prints a
message saying immediate reboot is required and how to achieve it?

Mark

Bug#934518: libebml 1.3.4-1+deb9u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 934518 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libebml
Version: 1.3.4-1+deb9u1

Explanation: apply upstream fixes for heap-based buffer over-reads

Bug#934508: openldap 2.4.44+dfsg-5+deb9u3 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 934508 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: openldap
Version: 2.4.44+dfsg-5+deb9u3

Explanation: security fixes

Bug#934507: openldap 2.4.47+dfsg-3+deb10u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 934507 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: openldap
Version: 2.4.47+dfsg-3+deb10u1

Explanation: security fixes

Bug#934347: dose3 FTBFS with OCaml 4.08.0 (safe strings)

[Ralf Treinen]

On Sat, Aug 10, 2019 at 07:07:33AM +0200, Stéphane Glondu wrote:
> Source: dose3
> Version: 5.0.1-12
> Severity: important
> 
> Dear Maintainer,
> 
> Your package dose3 FTBFS with OCaml 4.08.0 because -safe-string is now
> the default.
> 
> Please provide a version of dose3 that works with -safe-string. Note:
> this can be done before OCaml is updated because the current version in
> unstable (4.05.0) already supports -safe-strings.

Thanks for having fixed this. Can you please push -14 onto salsa?

-Ralf.

Bug#855634: O: libassa -- object-oriented C++ networking library

[Shane McDonald]

Control: retitle -1 ITA: libassa -- object-oriented C++ networking library

I am willing to take on this package.

Bug#934132: Processed: #934132: Raise severity to important

[Mark Hindley]

On Wed, Aug 14, 2019 at 07:22:47PM +0100, Jonathan Wiltshire wrote:
> On Sat, Aug 10, 2019 at 10:55:39AM +0100, Mark Hindley wrote:
> > On Fri, Aug 09, 2019 at 02:05:52PM +0100, Jonathan Wiltshire wrote:
> > > For the time being, yes, and for the reasons outlined in the initial bug
> > > report.
> > 
> > Those were my (hopefully impartial) summary.
> > 
> > I also went on to comment on each of the items in detail and explain why 
> > they
> > were not of sufficient concern to warrant a block. Are there still 
> > outstanding
> > concerns?
> 
> I think your summary is fine. However, this is not my area of expertise and
> I'm rather hoping Julien or Ansgar will chime in with an update.
> 
> It certainly wouldn't be appropriate for me to remove a block put in place
> by someone else without extenuating circumstances.

I quite understand that. Thanks.

I too hope that Julien will engage with this as he placed the manual block.

Thanks.

Mark

Bug#928483: execline: vim syntax highlighting

[Shengjing Zhu]

Control: tags -1 wontfix

On Mon, May 6, 2019 at 3:45 AM Dmitry Bogatov  wrote:
>
>
> Package: execline
> Version: 2.5.0.1-4
> Severity: wishlist
>
> Dear Maintainer,
>
> please consider including (any maybe suggesting upstream) attached vim
> syntax highlighting files.
>
> There seems to be no well-established extension for execline scripts. I
> choosed arbitrary ".ex".

I found there's a public repo[1] named vim-execline, and I created a
RFP[2] for it.

[1] https://github.com/djpohly/vim-execline
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934774

That to say I won't maintain a vim plugin inside the execline debian package.
This should be matained by upstream(execline author or others).

Sorry.

-- 
Shengjing Zhu

Bug#932284: installation-guide: Update docs for apt-setup/localX/key preseeding config

[Holger Wansing]

Control: tags -1 + pending

Moritz Muehlenhoff  wrote:
> Source: installation-guide
> Severity: normal
> 
> apt-setup 1:0.151 slightly changed the implementation of how Secure
> Apt keys are preseeded for local repositories.
> 
> Attached patch updates the existing documentation to reflect that.

Committed, thanks.
Tagging this bug as pending.



Holger


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

Bug#934776: xserver-xorg-video-intel: spelling mistake in package description

[Thorsten Glaser]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20180925-2
Severity: wishlist

Please replace “it’s” (short for “it is”) with “its” (genitive form)
in the package long Description.

(That being said, what benefits has the modesetting driver over the
intel driver viceque versa? I encountered crashes during zooming in
a map on a website with modesetting, and modesetting has OpenGL 2.x
only — does a comparison exist? I’m on an IBM X61 with GM965.)

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.28-10
ii  libdrm-intel1  2.4.97-1
ii  libdrm22.4.97-1
ii  libpciaccess0  0.14-1
ii  libpixman-1-0  0.36.0-1
ii  libudev1   241-7
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb-dri2-0  1.13.1-2
ii  libxcb-dri3-0  1.13.1-2
ii  libxcb-sync1   1.13.1-2
ii  libxcb-util0   0.3.8-3+b2
ii  libxcb11.13.1-2
ii  libxcursor11:1.2.0-2
ii  libxdamage11:1.1.5-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxinerama1   2:1.1.4-2
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxshmfence1  1.3-1
ii  libxss11:1.2.3-1
ii  libxtst6   2:1.2.3-1
ii  libxv1 2:1.0.11-1
ii  libxvmc1   2:1.0.10-1
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.4-1

xserver-xorg-video-intel recommends no packages.

xserver-xorg-video-intel suggests no packages.

Bug#933143: FTBFS, not Django 2.2 ready

[Antonio Terceiro]

On Fri, Jul 26, 2019 at 11:24:50PM +0200, Thomas Goirand wrote:
> Package: python-django-mptt
> Version: 0.8.7-1
> Severity: serious
> Tags: patch
> 
> Hi,
> 
> Please find attached patch to do the Python 2 removal.
> After this patch, your package continues to FTBFS. Please
> get a fix for it.

Thanks for the patch.

The new upstream version works fine with Django 2, but requires a new
dependency (python3-django-js-asset) that was just uploaded to NEW. Once
that hits the archive, a new upstream version will be uploaded.


signature.asc
Description: PGP signature

Bug#884498: Test suite no longer a hindrance to implementation of 'older-source-format'

[Felix Lechner]

Hi,

First of all, let me say that I did not see lamby's patch right away. I
then incorporated lamby's wishlist rating but kept the tag
'older-source-format' name. I could not find anything official that
declared 1.0 deprecated. Proper credit is in the commit messages.

Like the previous patch, the MR warns on 1.0 source formats, except it also
warns on implied 1.0 formats when there is no declaration. I am not sure
which is better. Please let me know:

https://salsa.debian.org/lintian/lintian/merge_requests/247

Kind regards,
Felix Lechner

Bug#934703: keyboard-configuration: debconf localisation for Finnish full of Russian and Spanish prompts

[Holger Wansing]

Hi,

Martin-Éric Racine  wrote:
> Package: keyboard-configuration
> Version: 1.191
> Severity: important
> Tags: l10n
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> The debconf template in keyboard-configuration for Finnish is full of prompts 
> and selectable options written in Russian or Spanish. This is a serious
> usability issue. In cases where a template has not been fully localised, 
> text in the locale C would be expected.

I which environment did you see this?
Did this happen while installing Debian with the debian-installer?

Could you please validate, if you can find those Russian and Spanish strings
in this fi.po file?
https://salsa.debian.org/installer-team/console-setup/blob/master/debian/po/fi.po

(I suspect that file contains correct Finnish, but just to make sure.)


Thanks
Holger




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

Bug#930997: cmake: reprotest's 'setarch linux32 dh_auto_configure' on amd64 results in CMAKE_SYSTEM_PROCESSOR = i386

[Niels Thykier]

Control: tags -1 moreinfo

Simon McVittie:
> On Sun, 14 Jul 2019 at 08:43:25 +0200, Helmut Grohne wrote:
>> [...]
>> Other than that, my general advice would be preferring $CC -dumpmachine
>> over uname -m as it avoids a whole host of problems. Getting there seems
>> like a herculean task though.
> 
> Is -dumpmachine portable among compilers, or is it a GNU'ism? If it's
> specific to gcc, or specific to gcc and compilers like clang that mimic
> gcc, or specific to compilers designed with the GNU/Autoconf vocabulary
> of CPUs in mind, then I can see why upstreams targeting both GNU and
> non-GNU OSs would avoid it.
> 
> As far as I can tell, CMake uses uname -m for its vocabulary of Linux CPUs
> (but see https://bugs.debian.org/930995), so switching to using the CPU
> part of $CC -dumpmachine would be an incompatible change, unless CMake
> had a lookup table to map between GNU CPUs and what uname -m would have
> said on the relevant machine. I think Meson did this better by having an
> explicitly documented table of known CPU names; I would have preferred it
> if Meson had reused GNU's vocabulary of CPU names rather than inventing
> a new one, but it's too late for that.
> 
> Debian::Debhelper::Buildsystem::cmake effectively already does have
> a lookup table to map GNU CPUs to uname -m (it's a list of exceptions
> rather than a complete table, since in practice they usually match),
> but it's currently only used when told to cross-compile, and reprotest's
> builds are "officially" not cross-compiling, even if uname -m would
> indicate otherwise.
> 
> smcv
> 

Hi,

I am not sure I am any wiser on this bug after reading the bug log other
than it looks unactionable to me at the moment (hench the moreinfo tag).

If the conclusion is that debhelper should always pass
-DCMAKE_SYSTEM_PROCESSOR (or/and -DCMAKE_SYSTEM_NAME) then I am happy to
implement that after we confirmed that this is "safe" (doesn't break
every cmake package in sid, etc.).  However, it is not clear to me
whether that is the conclusion we reached.

Thanks,
~Niels

Bug#898284: reprotest: "unshare: unshare failed: Operation non permise"

[Antoni Villalonga]

Package: reprotest
Followup-For: Bug #898284

> > sudo reprotest sl_3.03-17build1.dsc -- schroot stretch
> (Sudo is needed to let build dependencies installed and since I get a
> sem_open: Permission denied otherwise)

I've faced with a simililar error message.
The reason was /dev/shm or /run/shm were not mounted as tmpfs.

Probably related to #778462

> It runs the first build, but when doing the 2nd build with variations I end
> up with the error:
> fuse: unknown option `-q'
> fusermount: failed to unmount /tmp/reprotest.smM4SM/build-experiment-1:
> Invalid argument
> cleanup failed with exit code 1
> 
> (Full output attached as run1.txt)

May be related to the same mounting problem?
I don't know. 

> I wasn't planning on using disoderfs so I turn off that variation:
> > sudo reprotest sl_3.03-17build1.dsc --variations +all,-fileordering --
> schroot stretch

sudo reprotest sl_3.03-17build1.dsc --variations +all,-fileordering -- schroot 
stretch

> Which I tracked down with strace to:
> 
> [pid 15694] unshare(CLONE_NEWUTS|CLONE_NEWUSER)
> = -1 EPERM (Operation not permitted)

Also straced my problem.

util-linux-2.34/sys-utils/unshare.c:431:if (-1 == 
unshare(unshare_flags))

unshare looks fine, CLONE_NEWUTS|CLONE_NEWUSER are used when is invoked with
"-r --uts".

In your execution the unshare command was triggered from reprotest (line 238):
reprotest/build.py-218-# TODO: below only works on linux, of course..
reprotest/build.py-219-if ctx.spec.domain_host.use_sudo:
[...]
reprotest/build.py-232-else:
reprotest/build.py-233-logger.warn("Not using sudo for domain_host; 
your build may fail. See man page for other options.")
reprotest/build.py-234-logger.warn("Be sure to `echo 1 > 
/proc/sys/kernel/unprivileged_userns_clone` if on a Debian system.")
reprotest/build.py-235-if "user_group" in ctx.spec and 
ctx.spec.user_group.available:
reprotest/build.py-236-logger.error("Incompatible variations: 
domain_host.use_sudo False, user_group.available non-empty.")
reprotest/build.py-237-raise ValueError("Incompatible variations; 
check the log for details.")
reprotest/build.py:238:_ = _.prepend_to_build_command(*"unshare -r 
--uts".split(),

So, ctx.spec.domain_host.use_sudo was evaluated to false.

Also nice notes on README:
https://salsa.debian.org/reproducible-builds/reprotest/commit/9b34f0a3044b84c39bd897c47a426256cf0a88b1


I've fixed my problems with this param:
  --variations '+all,domain_host.use_sudo=1'

Hope it helps. In my opinion and understanding this bug should be closed.

Regards,

Bug#931873: texlive-bin: FTBFS on sparc64

[Hilmar Preuße]

Am 14.08.2019 um 12:44 teilte John Paul Adrian Glaubitz mit:
> On 7/29/19 11:49 PM, Hilmar Preuße wrote:

Hi,

>> My account was approved today. Logging in into that fine server however
>> does not work: shortly after I reached the command prompt the connection
>> terminates.
> 
> Try using a different host as jumphost. For some reason, I have connection
> problems when connecting from but connecting from my work machine works
> fine. We haven't found out yet what the problem is.
> 
That works a little better, I could access gcc202:

debuild -b:

dpkg-buildpackage: info: host architecture sparc64
dpkg-checkbuilddeps: error: Unmet build dependencies: libbrotli-dev
libgd-dev libgs-dev libpaper-dev libpotrace-dev (>= 1.11) libteckit-dev
libwoff-dev libxxhash-dev libzzip-dev (>= 0.12)

You could install the BD's for reproduction, however I'm pretty sure I
can't really help here. I'm not a programmer, hence this is out of my
scope. I'd wait if Luigi finds something. If not, I'll tag that bug "help".

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#934747: /usr/bin/rtorrent: rtorrent crashes with error "Could not create download: Info hash already used by another torrent."

[Bernhard Übelacker]

Control: reassign -1 libcurl4 7.65.1-1
Control: affects -1 + rtorrent
Control: tags -1 + upstream fixed-upstream
Control: fixed -1 7.65.3-1


Dear Maintainer,
I just tried to find some more information from the given backtrace.

That I guess would translate to something like below [1],
if it would have been done with a debugger and debug symbols.

These stack looks in the last frames similar to these shown in [2] and [3].
And these seem to get fixed upstream in commit [4]
that is in curl-7_65_2 and above.

So in theory the libcurl4 7.65.3-1 from unstable
might not show these segfaults.

Kind regards,
Bernhard


[1]
rtorrent(+0x11e59) [0x4afe59]  
| 0x00411e54 0x00411e59 in do_panic(int) at main.cc:596:   int stackSize = 
backtrace(stackPtrs, 20);
linux-gate.so.1(__kernel_sigreturn+0) [0xb7f92d7c] 
|0xb7fd4d7c <__kernel_sigreturn>
libcurl.so.4(+0x31640) [0xb7e69640]
|0xb7eab640 in sh_delentry at multi.c:253: dta->sh_entry = 
NULL;
libcurl.so.4(+0x328f2) [0xb7e6a8f2]
| 0xb7eac8ed 0xb7eac8f2 in Curl_multi_closed at multi.c:2397
libcurl.so.4(+0x2f7f7) [0xb7e677f7]
| 0xb7ea97f2 0xb7ea97f7 in Curl_closesocket at connect.c:1347
libcurl.so.4(+0x30612) [0xb7e68612]
| 0xb7eaa60d 0xb7eaa612 in trynextip at connect.c:606
libcurl.so.4(+0x30951) [0xb7e68951]
| 0xb7eaa94c 0xb7eaa951 in Curl_is_connected at connect.c:861
libcurl.so.4(+0x33d5c) [0xb7e6bd5c]
| 0xb7eadd57 0xb7eadd5c in multi_runsingle at multi.c:1509
libcurl.so.4(+0x35205) [0xb7e6d205]
| 0xb7eaf200 0xb7eaf205 in multi_socket at multi.c:2564
libcurl.so.4(curl_multi_socket_action+0x2f) [0xb7e6d3af]   
| 0xb7eaf3aa 0xb7eaf3af in curl_multi_socket_action at multi.c:2677
rtorrent(+0xda370) [0x578370]  
| 0x004da36b 0x004da370 in core::CurlStack::receive_action(core::CurlSocket*, 
int) at curl_stack.cc:95
rtorrent(+0xda68c) [0x57868c]  
| 0x004da687 0x004da68c in core::CurlStack::receive_timeout() at 
curl_stack.cc:171
rtorrent(+0x1341b) [0x4b141b]  
| 0x00413418 0x0041341b in std::function::operator()() const at 
/usr/include/c++/7/bits/std_function.h:706
libtorrent.so.20(_ZN7torrent11thread_base10event_loopEPS0_+0x229) [0xb7d8ec89] 
| 0xb7dd0c83 0xb7dd0c89 in std::function::operator()() const at 
/usr/include/c++/7/bits/std_function.h:706
rtorrent(+0x10b7b) [0x4aeb7b]  
| 0x00410b76 0x00410b7b in main(int, char**) at main.cc:480: 
torrent::thread_base::event_loop(torrent::main_thread());
libc.so.6(__libc_start_main+0xf1) [0xb77e7b41] 
| 0xb7829b3d 0xb7829b41 in __libc_start_main at ../csu/libc-start.c:308
rtorrent(+0x1173b) [0x4af73b]  
| 0x00411736 0x0041173b <_start+44>


[2] https://github.com/curl/curl/issues/3995
[3] https://github.com/curl/curl/issues/4057
[4] https://github.com/curl/curl/commit/4981fae7f158152fca01bddb042231f9f8343d58

# Bullseye/testing i386 qemu VM 2019-08-14


apt update
apt dist-upgrade


apt install systemd-coredump gdb mc rtorrent rtorrent-dbgsym 
libtorrent20-dbgsym libcurl4-dbgsym
apt build-dep rtorrent



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

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



gdb -q --args /usr/bin/rtorrent

set width 0
set pagination off
directory /home/benutzer/source/rtorrent/orig/rtorrent-0.9.7/src
set backtrace past-main
display/i $pc
tb main
run
generate-core-file /tmp/core1



gdb -q /usr/bin/rtorrent --core /tmp/core1

set width 0
set pagination off
directory /home/benutzer/source/rtorrent/orig/rtorrent-0.9.7/src
directory /home/benutzer/source/libcurl4/orig/curl-7.65.1/lib
set backtrace past-main
display/i $pc

b * _start+44
b * __libc_start_main+237
b * main+3654
b * _ZN7torrent11thread_base10event_loopEPS0_+0x223
b * client_perform+280
b * core::CurlStack::receive_timeout+39
b * core::CurlStack::receive_action(core::CurlSocket*, int)+91
b * curl_multi_socket_action+42
b * multi_socket+624
b * multi_runsingle+2103
b * Curl_is_connected+748
b * trynextip+189
b * Curl_closesocket+66
b * Curl_multi_closed+125
b * sh_delentry+48
b * __kernel_sigreturn+0
b * do_panic(int)+164





# From submitter:
rtorrent(+0x11e59) [0x4afe59]  
| 0x00411e54 0x00411e59 in do_panic(int) at main.cc:596:   int stackSize = 
ba

Bug#934775: stretch-pu: package monkeysphere/0.41-1+deb9u1

[Chris Lamb]

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

Dear oldstable release managers,

Please consider monkeysphere (0.41-1+deb9u1) for stretch:
  
  monkeysphere (0.41-1+deb9u1) stretch; urgency=medium
  
* Prevent a FTBFS by updating the tests to accommodate an updated GnuPG in
  stretch now producing a different output. (Closes: #934034)


The full diff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/debian/changelog b/debian/changelog
index d81b43e..73e8634 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+monkeysphere (0.41-1+deb9u1) stretch; urgency=medium
+
+  * Prevent a FTBFS by updating the tests to accommodate an updated GnuPG in
+stretch now producing a different output. (Closes: #934034)
+
+ -- Chris Lamb   Wed, 14 Aug 2019 10:09:00 -0700
+
 monkeysphere (0.41-1) unstable; urgency=medium
 
   * new upstream release
diff --git a/debian/control b/debian/control
index 95750f4..19c4dbb 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
  cpio,
  debhelper (>= 10~),
  dpkg-dev (>= 1.17.14),
- gnupg ,
+ gnupg (>= 2.1.18-8~deb9u4) ,
  gnupg-agent ,
  libassuan-dev,
  libcrypt-openssl-rsa-perl ,
diff --git 
a/debian/patches/0001-Prevent-a-FTBFS-by-updating-the-tests-to-accommodate.patch
 
b/debian/patches/0001-Prevent-a-FTBFS-by-updating-the-tests-to-accommodate.patch
new file mode 100644
index 000..9b10151
--- /dev/null
+++ 
b/debian/patches/0001-Prevent-a-FTBFS-by-updating-the-tests-to-accommodate.patch
@@ -0,0 +1,60 @@
+From: Chris Lamb 
+Date: Wed, 14 Aug 2019 10:16:24 -0700
+Subject: Prevent a FTBFS by updating the tests to accommodate an updated
+ GnuPG in stretch now producing a different output. (Closes: #934034)
+
+---
+ tests/keytrans | 20 ++--
+ 1 file changed, 10 insertions(+), 10 deletions(-)
+
+diff --git a/tests/keytrans b/tests/keytrans
+index fd9a144..5b23a16 100755
+--- a/tests/keytrans
 b/tests/keytrans
+@@ -137,9 +137,9 @@ gpg --list-keys
+ cat >"$TEMPDIR"/expectedout <"$TEMPDIR"/expectedout <"$TEMPDIR"/expectedout <

Bug#934774: RFP: vim-execline -- execline syntax highlighting for vim

[Shengjing Zhu]

Package: wnpp
Severity: wishlist

* Package name: vim-execline
  Version : git HEAD version
  Upstream Author : Devin J. Pohly
* URL : https://github.com/djpohly/vim-execline
* License :
  Programming Lang: Vim script
  Description : execline syntax highlighting for vim

This package adds syntax highlighting supports for execline[1]
script.

[1] https://tracker.debian.org/pkg/execline


signature.asc
Description: PGP signature

Bug#934772: [munin-node] munin-node mysql configuration (mariadb)

[Víctor Martínez]

Package: munin-node
Version: 2.0.49-1
Severity: normal
Tags: patch

--- Please enter the report below this line. ---

Dear maintainer, I recently upgraded to Buster, all was working fine or at
least that was thinking, on all our production machines have found an
unusual amount of warnings on /var/log/syslog: 

Access denied for user 'root'@'localhost' (using password: YES)

Searching the origin of this messagesi, finded that munin was the
culprit, so searching for similar errors found bug #864845 when the solution was
to change:
-env.mysqluser debian-sys-maint
+env.mysqluser root

And looks like the default configuration for munin-node now is that one,
the oposite has worked for me, returning to debian-sys-maint to handle
the request of munin, my machines are running mariadb-server
(10.3.15-1) with mysql_secure_installation, password set for root and no test
db.

My current fix is:
diff -u /home/vicm3/1/etc/munin/plugin-conf.d/munin-node 
/etc/munin/plugin-conf.d/munin-node
--- /home/vicm3/1/etc/munin/plugin-conf.d/munin-node 2019-05-15 
18:21:08.0 -0500
+++ /etc/munin/plugin-conf.d/munin-node 2019-08-14 11:27:37.234767719 -0500
@@ -73,7 +73,7 @@
 [mysql*]
 user root
 env.mysqlopts --defaults-file=/etc/mysql/debian.cnf
-env.mysqluser root
+env.mysqluser debian-sys-maint
 env.mysqlconnection 
DBI:mysql:mysql;mysql_read_default_file=/etc/mysql/debian.cnf

[postfix_mailqueue]

Please check and if it's useful commit.

Best regards.

Mariadb info:

ii  libmariadb3:amd64 1:10.3.15-1
amd64MariaDB database client library
ii  mariadb-client-10.3   1:10.3.15-1
amd64MariaDB database client binaries
ii  mariadb-client-core-10.3  1:10.3.15-1
amd64MariaDB database core client binaries
ii  mariadb-common1:10.3.15-1
all  MariaDB common metapackage
ii  mariadb-server1:10.3.15-1
all  MariaDB database server (metapackage depending on the latest 
version)
ii  mariadb-server-10.3   1:10.3.15-1
amd64MariaDB database server binaries
ii  mariadb-server-core-10.3  1:10.3.15-1
amd64MariaDB database core server files

--- System information. ---
Architecture: 
Kernel:   Linux 4.19.0-5-amd64

Debian Release: 10.0
  500 stable  security.debian.org 
  500 stable  ftp.us.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-==
perl | 5.28.1-6
libnet-server-perl   | 2.009-1
lsb-base(>= 4.1) | 10.2019051400
munin-common   (>= 2.0.49-1) | 2.0.49-1
munin-plugins-core   | 2.0.49-1
netbase  | 5.6


Recommends   (Version) | Installed
==-+-===
gawk   | 1:4.2.1+dfsg-1
munin-plugins-extra| 2.0.49-1
procps | 2:3.3.15-2


Suggests(Version) | Installed
=-+-===
munin | 
munin-plugins-java| 

Bug#934773: ITP: ruby-activerecord-explain-analyze -- ActiveRecord#explain with support for EXPLAIN ANALYZE

[Sruthi Chandran]

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

* Package name: ruby-activerecord-explain-analyze
  Version : 0.1.0
  Upstream Author : Peter Graham
* URL : https://github.com/6/activerecord-explain-analyze
* License : Expat
  Description : ActiveRecord#explain with support for EXPLAIN ANALYZE
 Extends ActiveRecord#explain with support for EXPLAIN ANALYZE and
output formats of JSON, XML, and YAML.
 .
 What's EXPLAIN ANALYZE? PostgreSQL devises a query plan for each query
it receives. Choosing the right plan to match the query structure and
the properties of the data is absolutely critical for good performance,
so the system includes a complex planner that tries to choose good
plans. One can use the EXPLAIN command to see what query plan the
planner creates for any query. With EXPLAIN ANALYZE, EXPLAIN actually
executes the query, and then displays the true row counts and true run
time accumulated within each plan node.



signature.asc
Description: OpenPGP digital signature

Bug#934771: python3.7: Python3 is built with -flto, which breaks debugging of extension modules

[Dima Kogan]

Package: python3.7
Version: 3.7.4-2
Severity: normal

Hi. Currently the build flags the 'sysconfig' module reports for
building extension modules contain '-flto'. Presumably this speeds
something up somewhere, but it breaks debugging: when built this way gdb
isn't able to step through the C code of the extension module. This is a
known and documented side-effect of link-time optimization (see the gcc
manpage, for instance). Can we not do -flto for extension modules? To be
clear, this bug report is about building extension modules, not the
python interpreter itself.

There're a number of sysconfig variables that mention flto:


dima@scrawny:~$ python3 -msysconfig | grep flto

  CFLAGS = "-Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g  
 -fstack-protector-strong -Wformat -Werror=format-security  -g -flto 
-fuse-linker-plugin -ffat-lto-objects"

  PY_BUILTIN_MODULE_CFLAGS = "-Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g   -fstack-protector-strong -Wformat 
-Werror=format-security  -g -flto -fuse-linker-plugin -ffat-lto-objects 
-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter 
-Wno-missing-field-initializers -Wno-cast-function-type 
-Werror=implicit-function-declaration -IObjects -IInclude -IPython -I. 
-I../Include -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPy_BUILD_CORE_BUILTIN"

  PY_CFLAGS = "-Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall 
-g   -fstack-protector-strong -Wformat -Werror=format-security  -g -flto 
-fuse-linker-plugin -ffat-lto-objects"

  PY_CORE_CFLAGS = "-Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 
-Wall -g   -fstack-protector-strong -Wformat -Werror=format-security  -g -flto 
-fuse-linker-plugin -ffat-lto-objects -std=c99 -Wextra -Wno-unused-result 
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-cast-function-type 
-Werror=implicit-function-declaration -IObjects -IInclude -IPython -I. 
-I../Include -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -DPy_BUILD_CORE"

I want to say CFLAGS is the one used for extension modules, but I'm not
100% sure. Is there currently a mechanism for using different flags for
extension modules as opposed to the interpreter guts? If not, I guess
I'm asking for those.

Thanks



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3.7 depends on:
ii  libpython3.7-stdlib  3.7.4-2
ii  mime-support 3.62
ii  python3.7-minimal3.7.4-2

python3.7 recommends no packages.

Versions of packages python3.7 suggests:
ii  binutils2.32.51.20190707-1
ii  python3.7-doc   3.7.4-2
pn  python3.7-venv  

-- no debconf information

Bug#934721: sbuild: Lintian run via sbuild produces different output than running lintian manually with the same options

[Bill Blough]

Hi Josch,

Thanks for taking the time to give that explanation.

In my testing, I observed exactly what you said - using '-d' sets the
Distribution field in the .changes file.  Not using '-d' causes the
Distribution to be populated with the distribution value from the
d/changelog entry

But I feel like there's still an issue, or I'm still not understanding
something correctly.

When sbuild calls lintian, it passes the filename of the .changes file.

If my understanding is correct, using or not using '-d' has already
affected the contents of the .changes file at that point.  Then linitan
runs against that .changes file, and gets all of its information from
there.

So shouldn't running lintian outside of sbuilt using the *exact same*
.changes file produce the same output?

I would think yes, unless-

1) the .changes file passed to lintian is different than the .changes
file written to the log and left on disk after the build

or

2) the output from lintian is somehow altered/modified by sbuild.

Neither of those seem to be the case, but I'm not 100% sure.  However,
either of those could explain the discrepancy.


> 
> Do you see any way sbuild could improve to be less confusing?

I think most of the docs are pretty clear.  But I guess that depends on if
there's really an issue as I suspect, or if I'm just greatly
misunderstanding thing.

I guess I'll let you know once we figure out which one :-)

Best regards,
Bill

Bug#934507: buster-pu: package openldap/2.4.47+dfsg-3+deb10u1

[Ryan Tandy]

On Tue, Aug 13, 2019 at 06:25:13PM +0100, Adam D. Barratt wrote:

Please go ahead; thanks.


Thank you. Uploaded, accepted, and visible on the queue page now.

Bug#934508: stretch-pu: package openldap/2.4.44+dfsg-5+deb9u3

[Ryan Tandy]

On Tue, Aug 13, 2019 at 06:24:32PM +0100, Adam D. Barratt wrote:

Please go ahead.


Thank you. Uploaded, accepted, and visible on the queue page now.

Bug#709975: Add set_sourcedir to Debian::Debhelper::Buildsystem

[Niels Thykier]

On Mon, 27 May 2013 10:29:42 +0200 Mathieu Parent
 wrote:
> Package: debhelper
> Version: 9.20130518
> Severity: whishlist
> X-Debbugs-CC: pkg-php-p...@lists.alioth.debian.org
> 
> Hi Joey,
> 
> For the pkg-php-tools [1] package, which enhance debhelper, I need to
> change the sourcedir when building PECL [2] package.
> 
> [1]: http://anonscm.debian.org/gitweb/?p=pkg-php/pkg-php-tools.git;a=summary
> [2]: http://www.php.net/manual/en/install.pecl.phpize.php
> 
> The wanted workflow on configure:
> - set sourcedir to Foo-0.0.0
> - phpize
> - pass to parent Debian::Debhelper::Buildsystem::autoconf configure()
> - set sourcedir back to top
> 
> The wanted workflow on build:
> - set sourcedir to Foo-0.0.0
> - pass to parent Debian::Debhelper::Buildsystem::autoconf build()
> - set sourcedir back to top
> 
> The wanted workflow on install:
> - set sourcedir to Foo-0.0.0
> - pass to parent Debian::Debhelper::Buildsystem::autoconf install()
> - set sourcedir back to top
> 
> Wanted API:
> - push_sourcedir (with the same checks as in
> Debian::Debhelper::Buildsystem::new())
> - pop_sourcedir
> 
> Or:
> - set_sourcedir (with the same checks as in
> Debian::Debhelper::Buildsystem::new())
> 
> I'm open to any better solution.
> 
> Regards
> --
> Mathieu Parent
> 
> 

Hi Mathieu,

Apologies for the long wait before picking this up.

Since you filed this bug, debhelper has gotten a new model for build
systems that may be relevant to this case.  The described build flows
looks a look existing build generator flows (a la meson+ninja or
cmake+make[1]).

The phppear have some differences to this theme as such debhelper does
not currently support exactly the phppear use-case.  I am hoping we can
come to a solution on that.

If phppear would be converted to generator buildsystem like meson, then
it would probably look something like this (mix-pseudo code, mix real code):


"""
# Remove 'use base "Debian::Debhelper::Buildsystem::autoconf";'
[...]

sub IS_GENERATOR_BUILD_SYSTEM {
return 1;
}

sub SUPPORTED_TARGET_BUILD_SYSTEMS {
return qw(autoconf);
}

sub _get_peardir {
[...]
}

# This sub does *not* exist yet
sub _initialize_target_buildsystem {
my ($this, $target_bs_options, @args) = shift;
$target_bs_options->{'sourcedir'} = $this->_get_peardir;
$target_bs_options->{'builddir'} = $this->_get_peardir;
return $this->SUPER::_initialize_target_buildsystem(
$target_bs_options, @args);
}

sub configure {
my $this=shift;
$this->get_targetbuildsystem->mkdir_builddir;
$this->get_targetbuildsystem->doit_in_builddir('phpize');
return $this->SUPER::configure(@_);
}

[...]
"""
The configure is from your concept description; I realise that the real
phppear build system is "slightly" more complex than that.


The most difficult issue is if you need to extract data to make
_get_peardir work, which may only be available if phppear is a valid
buildsystem for the concrete package.  However, debhelper currently
initializes the target buildsystem immediately and we rely on this
elsewhere in debhelper (e.g. in dh_auto_configure --list).


Just to confirm I got some details correct:
 * Is it correctly understood of me that phppear *conditionally* uses
   autoconf as a generated build system (i.e. there are packages where
   phppear does everything without ever using the autoconf bits)?

 * Is it correctly understood that phppear potentially needs two
   distinct "build directories"?  One for itself and a generated one for
   the autoconf parts?

 * Is the exact name returned by _get_peardir important or just "nice to
   have"?




Finally, a few drive-by remarks after reviewing the phppear build system
(in case they are useful to you):

 * _get_mainpackage looks like an expensive version of $dh{MAINPACKAGE}
   (with some theoretical corner cases where dh_listpackages might give
   you a different result).
   - Is anything preventing you from using $dh{MAINPACKAGE}?

 * If you like to avoid shell, then the complex_doit call can be
   replaced by using doit({stdout => $path}, ...).  Requires buster
   or later (I can dig out the exact version of debhelper if relevant,
   but I did not see any backports for pkg-php-tools, so I assumed it
   was not relevant).


Thanks,
~Niels

[1] Strictly speaking, autoconf should be autoconf+make.  But historical
reasons prevent the split.

Bug#863293: Bug#863255: Please rename/provide libjs-jquery-atwho

[Pirate Praveen]

On Fri, 14 Jun 2019 21:30:32 +0530 Pirate Praveen
 wrote:
> On Thu, 25 May 2017 09:30:05 +1000 Ben Finney 
> wrote: > > […] Also consider providing node-at.js as I may need it for new
> > > version of gitlab (9.x) which depends on all node modules and uses
> > > webpack directly (instead of depending on libjs packages).
> > 
> > This is a separate request, so I'm opening a new bug report based on
> > that request.
> 
> Please review
> https://salsa.debian.org/debian/pkg-jquery-at.js/merge_requests/1
> 

Since there is no response for over 3 months for the merge request, I'm
planning to do an NMU.

I really wonder why this is not maintained under Javascript team though,
it only makes things harder for other people to update and fix a package.

Bug#753653: RFP: tmsu -- command-line file tagging tooI and tag-based virtual filesystem

[Fahad Sadah]

All dependencies are now packaged in Debian 

Bug#934769: openvswitch-switch: VPN services faile to start if openvswitch is used in host as primery outgoing port

[richman1000000]

Package: openvswitch-switch
Version: 2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12
Severity: important



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openvswitch-switch depends on:
ii  kmod26-1
ii  lsb-base10.2019051400
ii  netbase 5.6
ii  openvswitch-common  2.10.0+2018.08.28+git.8ca7c82b7d+ds1-12
ii  procps  2:3.3.15-2
ii  python  2.7.16-1
ii  uuid-runtime2.33.1-0.1

openvswitch-switch recommends no packages.

openvswitch-switch suggests no packages.

-- no debconf information

If openvswitch is used as a main ethernet port on host, any VPN services 
failing to start.
Current workaround is:
1. For openvpn - add "ExecStartPre=sleep 30" to systemd service start 
2. for pppd - run via cron a  script that checks if service pppd is running, 
and starts pppd if it is not. 

Bug#934768: speedtest-cli should depend on ca-certificates

[Daniel Lo Nigro]

Package: speedtest-cli
Version: 2.1.1-2
Severity: normal

Dear Maintainer,

If you try to run speedtest-cli without installing ca-certificates, the 
following error is thrown:

Retrieving speedtest.net configuration...
Cannot retrieve speedtest configuration
ERROR: 

As speedtest-cli is unusable without the CA certificates, it should have a 
dependency on the ca-certificates package.


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

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

Versions of packages speedtest-cli depends on:
ii  python-pkg-resources   41.0.1-1
ii  python33.7.3-1
ii  python3-pkg-resources  41.0.1-1

speedtest-cli recommends no packages.

speedtest-cli suggests no packages.

-- no debconf information