Bug#950000: openjpeg2: CVE-2020-6851

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.3.1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/1228

Hi,

The following vulnerability was published for openjpeg2.

CVE-2020-6851[0]:
| OpenJPEG through 2.3.1 has a heap-based buffer overflow in
| opj_t1_clbl_decode_processor in libopenjp2.so.


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-2020-6851
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-6851
[1] https://github.com/uclouvain/openjpeg/issues/1228

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#949999: ruby-secure-headers: CVE-2020-5217

[Salvatore Bonaccorso]

Source: ruby-secure-headers
Version: 6.1.1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for ruby-secure-headers.

CVE-2020-5217[0]:
| In Secure Headers (RubyGem secure_headers), a directive injection
| vulnerability is present in versions before 3.8.0, 5.1.0, and 6.2.0.
| If user-supplied input was passed into
| append/override_content_security_policy_directives, a semicolon could
| be injected leading to directive injection. This could be used to e.g.
| override a script-src directive. Duplicate directives are ignored and
| the first one wins. The directives in secure_headers are sorted
| alphabetically so they pretty much all come before script-src. A
| previously undefined directive would receive a value even if
| SecureHeaders::OPT_OUT was supplied. The fixed versions will silently
| convert the semicolons to spaces and emit a deprecation warning when
| this happens. This will result in innocuous browser console messages
| if being exploited/accidentally used. In future releases, we will
| raise application errors resulting in 500s. Depending on what major
| version you are using, the fixed versions are 6.2.0, 5.1.0, 3.8.0.


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-2020-5217
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5217

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#949998: ruby-secure-headers: CVE-2020-5216

[Salvatore Bonaccorso]

Source: ruby-secure-headers
Version: 6.1.1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for ruby-secure-headers.

CVE-2020-5216[0]:
| In Secure Headers (RubyGem secure_headers), a directive injection
| vulnerability is present in versions before 3.9.0, 5.2.0, and 6.3.0.
| If user-supplied input was passed into
| append/override_content_security_policy_directives, a newline could be
| injected leading to limited header injection. Upon seeing a newline in
| the header, rails will silently create a new Content-Security-Policy
| header with the remaining value of the original string. It will
| continue to create new headers for each newline. This has been fixed
| in 6.3.0, 5.2.0, and 3.9.0.


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-2020-5216
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-5216

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#949997: cacti: CVE-2020-7237

[Salvatore Bonaccorso]

Source: cacti
Version: 1.2.8+ds1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/Cacti/cacti/issues/3201

Hi,

The following vulnerability was published for cacti.

CVE-2020-7237[0]:
| Cacti 1.2.8 allows Remote Code Execution (by privileged users) via
| shell metacharacters in the Performance Boost Debug Log field of
| poller_automation.php. OS commands are executed when a new poller
| cycle begins. The attacker must be authenticated, and must have access
| to modify the Performance Settings of the product.


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-2020-7237
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7237
[1] https://github.com/Cacti/cacti/issues/3201

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#949996: cacti: CVE-2020-7106

[Salvatore Bonaccorso]

Source: cacti
Version: 1.2.8+ds1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/Cacti/cacti/issues/3191

Hi,

The following vulnerability was published for cacti.

CVE-2020-7106[0]:
| Cacti 1.2.8 has stored XSS in data_sources.php,
| color_templates_item.php, graphs.php, graph_items.php,
| lib/api_automation.php, user_admin.php, and user_group_admin.php, as
| demonstrated by the description parameter in data_sources.php (a raw
| string from the database that is displayed by $header to trigger the
| XSS).


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-2020-7106
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7106
[1] https://github.com/Cacti/cacti/issues/3191

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#949995: hiredis: CVE-2020-7105

[Salvatore Bonaccorso]

Source: hiredis
Version: 0.14.0-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/redis/hiredis/issues/754
Control: found -1 0.14.0-3

Hi,

The following vulnerability was published for hiredis.

CVE-2020-7105[0]:
| async.c and dict.c in libhiredis.a in hiredis through 0.14.0 allow a
| NULL pointer dereference because malloc return values are unchecked.


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-2020-7105
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-7105
[1] https://github.com/redis/hiredis/issues/754

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#949994: mysql-5.7: Security fixes from the January 2020 CPU

[Salvatore Bonaccorso]

Source: mysql-5.7
Version: 5.7.26-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi

See
https://www.oracle.com/security-alerts/cpujan2020.html#AppendixMSQL
for a list of CVEs affecting src:mysql-5.7.

Regards,
Salvatore

Bug#949993: RM: python-publicsuffix -- RoQA; Deprecated by upstream, replaced by python-publicsuffix2

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Upstream has stated that python-publicsuffix should no longer be used.
In Debian, the binary it generates (python3-publicsuffix) has no more
rdepends.  The replacement package, python-publicsuffix2 has migrated to
Testing, so this can go now.

Scott K

Bug#949992: Does not take subprocess down when killed

[martin f krafft]

Package: mime-support
Version: 3.64
Severity: normal
File: /usr/bin/run-mailcap

When run-mailcap is killed (e.g. SIGTERM), the subprocess it spawned 
according to mailcap is left alive. This is due to the use of the 
system(3perl) call. Quite frankly, I think exec() should be used 
instead, as there is no purpose in leaving run-mailcap around. 
However, if that is not possible, please make sure that the 
subprocesses are killed when run-mailcap is killed.

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

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

mime-support depends on no packages.

Versions of packages mime-support recommends:
ii  bzip2 1.0.8-2
ii  file  1:5.38-4
ii  xz-utils  5.2.4-1+b1

mime-support suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#949991: haskell-hledger ftbfs on s390x

[Matthias Klose]

Package: src:haskell-hledger
Version: 1.14.2-1
Severity: serious
Tags: sid bullseye

haskell-hledger ftbfs on s390x

[...]
Dependency installability problem for haskell-hledger on s390x:
haskell-hledger build-depends on missing:
- libghc-hledger-lib-dev:s390x (>= 1.14.1)

Bug#949988: axmail FTCBFS: uses the build architecture compiler as linker

[Helmut Grohne]

Source: axmail
Version: 2.9-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

axmail fails to cross build from source, because it uses the build
architecture compiler as linker via the LD variable. Unfortunately, the
meaning of LD varies widely, so dh_auto_build cannot substitute it. I
propose defaulting it to the compiler variable such that it
automatically gets substituted correctly in most cases while still
leaving room for choosing it manualy. Further more, axmail passes -s to
install which causes it to stip with the wrong strip. Beyond breaking
cross compilation, doing so also breaks DEB_BUILD_OPTIONS=nostrip as
well as generation of -dbgsym packages. It is best to avoid -s entirely
and leave that up to dh_strip. Indeed, debhelper already supports that
by passing a non-stripping install as INSTALL, so all we need to do here
is make install substitutable. Please consider applying the attached
patch.

Helmut
--- axmail-2.9.orig/Makefile
+++ axmail-2.9/Makefile
@@ -2,7 +2,8 @@
 
 MAN_DIR = debian/axmail/usr/share/man
 CC = gcc
-LD = gcc
+LD = $(CC)
+INSTALL ?= install
 # CFLAGS = -O2 -Wstrict-prototypes -g -I../lib
 LIBS = -lcrypt
 MODULES = utils.o config.o adduser.o command.o mailcmd.o mbox.o head.o lock.o axmail.o quit.o
@@ -13,19 +14,19 @@
 install: installbin installconf installhelp
 
 installbin: all
-	install -m 0755 -D -d debian/axmail/usr/sbin
-	install -m 0755 -s -o root -g root axmail	 debian/axmail/usr/sbin
+	$(INSTALL) -m 0755 -D -d debian/axmail/usr/sbin
+	$(INSTALL) -m 0755 -s -o root -g root axmail	 debian/axmail/usr/sbin
 
 installconf:
-	install -m 755  -D -d debian/axmail/etc/ax25
-	install -m 755-o root -g root -d		debian/axmail/etc/ax25
-	install -b -m 644 -o root -g root etc/axmail.conf debian/axmail/etc/ax25
-	install -m 644-o root -g root etc/welcome.txt debian/axmail/etc/ax25
+	$(INSTALL) -m 755  -D -d debian/axmail/etc/ax25
+	$(INSTALL) -m 755-o root -g root -d		debian/axmail/etc/ax25
+	$(INSTALL) -b -m 644 -o root -g root etc/axmail.conf debian/axmail/etc/ax25
+	$(INSTALL) -m 644-o root -g root etc/welcome.txt debian/axmail/etc/ax25
 
 installhelp:
-	install -m 755  -D -d debian/axmail/var/lib/ax25/axmail/help
-	install -m 755-o root -g root -d		  debian/axmail/var/lib/ax25/axmail/help
-	install -m 644-o root -g root etc/help/*.hlp  debian/axmail/var/lib/ax25/axmail/help
+	$(INSTALL) -m 755  -D -d debian/axmail/var/lib/ax25/axmail/help
+	$(INSTALL) -m 755-o root -g root -d		  debian/axmail/var/lib/ax25/axmail/help
+	$(INSTALL) -m 644-o root -g root etc/help/*.hlp  debian/axmail/var/lib/ax25/axmail/help
 
 back:
 	rm -f ../mail.tar.gz

Bug#949989: liblasso3-dev: move lasso.pc to a multiarch location

[Helmut Grohne]

Package: liblasso3-dev
Version: 2.6.0-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:libapache2-mod-auth-mellon

libapache2-mod-auth-mellon fails to cross build from source, becuse it
cannot find lasso.pc. During cross compilation, pkg-config does not
search /usr/lib/pkgconfig. Thus, we need to move the lasso.pc file to a
multiarch location. Please consider applying the attached patch.
Alternatively, please consider passing a multiarch --libdir to
configure. Alternatively, consider using dh_auto_configure at compat
level 9 or higher.

Helmut
diff --minimal -Nru lasso-2.6.0/debian/changelog lasso-2.6.0/debian/changelog
--- lasso-2.6.0/debian/changelog2020-01-19 10:23:50.0 +0100
+++ lasso-2.6.0/debian/changelog2020-01-28 06:26:33.0 +0100
@@ -1,3 +1,10 @@
+lasso (2.6.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move lasso.pc to a multiarch location. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 28 Jan 2020 06:26:33 +0100
+
 lasso (2.6.0-6) unstable; urgency=medium
 
   * d/control: remove unnecessary python build-dependency (closes: #936817)
diff --minimal -Nru lasso-2.6.0/debian/rules lasso-2.6.0/debian/rules
--- lasso-2.6.0/debian/rules2019-11-20 11:01:19.0 +0100
+++ lasso-2.6.0/debian/rules2020-01-28 06:26:31.0 +0100
@@ -9,10 +9,7 @@
 
 # These are used for cross-compiling and for saving the configure script
 # from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
-DEB_TARGET_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
+include /usr/share/dpkg/architecture.mk
 
 ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
 
@@ -128,6 +125,8 @@
dh_installexamples -XCVS
dh_installman
dh_install
+   mkdir $(CURDIR)/debian/liblasso3-dev/usr/lib/$(DEB_HOST_MULTIARCH)
+   mv $(CURDIR)/debian/liblasso3-dev/usr/lib/pkgconfig 
$(CURDIR)/debian/liblasso3-dev/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig
chrpath -d $(CURDIR)/debian/liblasso-perl/$(ARCHLIB)/auto/Lasso/Lasso.so
dh_link
dh_strip

Bug#949990: zita-rev1 FTCBFS: uses a non-standard pkg-config variabel

[Helmut Grohne]

Source: zita-rev1
Version: 0.2.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

zita-rev1 fails to cross build from source, because it uses a
non-standard variable for pkg-config, which isn't substituted by
debhelper. Thus debian/rules sets PKG_CONF=pkg-config and uses the build
architecture one. Please consider initializing it from e.g. dpkg's
buildtools.mk (this patch) or using the standard name PKG_CONFIG that is
properly substituted by dh_auto_build.

Helmut
diff --minimal -Nru zita-rev1-0.2.2/debian/changelog 
zita-rev1-0.2.2/debian/changelog
--- zita-rev1-0.2.2/debian/changelog2020-01-27 22:53:37.0 +0100
+++ zita-rev1-0.2.2/debian/changelog2020-01-28 06:17:15.0 +0100
@@ -1,3 +1,10 @@
+zita-rev1 (0.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass a triplet-prefixed pkg-config. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 28 Jan 2020 06:17:15 +0100
+
 zita-rev1 (0.2.2-1) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru zita-rev1-0.2.2/debian/rules zita-rev1-0.2.2/debian/rules
--- zita-rev1-0.2.2/debian/rules2020-01-27 22:28:57.0 +0100
+++ zita-rev1-0.2.2/debian/rules2020-01-28 06:17:07.0 +0100
@@ -4,7 +4,9 @@
 
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
-export PKG_CONF=pkg-config
+include /usr/share/dpkg/buildtools.mk
+
+export PKG_CONF=$(PKG_CONFIG)
 
 export PREFIX=/usr
 

Bug#949987: liblogger-simple-perl: diff for NMU version 2.0-1.1

[Boyuan Yang]

Control: tags 949987 + patch
Control: tags 949987 + pending

Dear maintainer,

I've prepared an NMU for liblogger-simple-perl (versioned as 2.0-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru liblogger-simple-perl-2.0/debian/changelog liblogger-simple-perl-
2.0/debian/changelog
--- liblogger-simple-perl-2.0/debian/changelog  2019-02-01 08:11:43.0
-0500
+++ liblogger-simple-perl-2.0/debian/changelog  2020-01-28 00:13:15.0
-0500
@@ -1,3 +1,11 @@
+liblogger-simple-perl (2.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * No-change source-only upload to allow testing migration.
+(Closes: #949987)
+
+ -- Boyuan Yang   Tue, 28 Jan 2020 00:13:15 -0500
+
 liblogger-simple-perl (2.0-1) unstable; urgency=low
 
   * Initial release (Closes: 921171).


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

Bug#949725: onedrive: Fails to connect to service

[Kleinert, Bruno]

Am Freitag, den 24.01.2020, 19:38 +0900 schrieb Norbert Preining:

Hi


On Fri, 24 Jan 2020, Bruno Kleinert wrote:

ERROR: OneDrive returned a 'HTTP 401 Unauthorized' - Cannot Initialize Sync


Can you try --logout and then reauthenticate?


Hi Norbert,


many thanks, that fixed it. I'm going to close this bug.


Cheers


Bruno

Bug#949987: liblogger-simple-perl: Please make source-only upload to allow testing migration

[Boyuan Yang]

Source: liblogger-simple-perl
Severity: important
Version: 2.0-1

Dear liblogger-simple-perl maintainer,

Your package only had an initial non-source-only upload. As a result, it will
not migrate to Debian Testing. Please make another source-only upload to allow
testing migration.

-- 
Thanks,
Boyuan Yang


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

Bug#758982:

[valerie dupon]

Hallo

Entschuldigen Sie mich auf diese Art und Weise, Sie zu kontaktieren, ich habe 
gerade Ihr Profil gesehen und ich dachte, Sie sind die richtige Person für 
mich. Kurz gesagt, mein Name ist VALERIE DUPON, französischer Herkunft. Ich 
leide an einer schweren Krankheit, die mich zum sicheren Tod verurteilt, es ist 
Kehlkopfkrebs, und ich habe eine Summe von 900.000 Euro, die ich einer 
Vertrauens- und Ehrlichen Person schenken möchte, damit sie davon Gebrauch 
machen kann. Ich besitze ein rotes Ölimportgeschäft in Belgien, und ich habe 
meine Frau vor 6 Jahren verloren, was mich sehr betroffen hat und ich konnte 
bis jetzt nicht wieder heiraten, wir hatten keine Kinder. Ich möchte diese 
Summe vor meinem Tod zu einem Geschenk machen, denn meine Tage waren die Schuld 
an dieser Krankheit, für die ich keine Heilung hatte, aber eine Beruhigung in 
Belgien, später nicht wissen würde, ob Sie von diesem Geschenk profitieren 
können.

Sie können mich wieder per E-Mail kontaktieren, wenn Sie von meiner Spende 
interessiert sind danke es ist schön, Ihre Nachricht im Gegenzug zu erhalten

Danke, dass du verstanden hast und darauf wartet, dir zu lesen, dass Gott, der 
Vater, dich segnet.

Bug#949267: transition: netcdf

[Sebastiaan Couwenberg]

On 1/27/20 3:59 PM, Sebastiaan Couwenberg wrote:
> On 1/26/20 11:34 AM, Sebastiaan Couwenberg wrote:
>> On 1/25/20 11:34 AM, Sebastiaan Couwenberg wrote:
>>> On 1/24/20 12:54 PM, Sebastiaan Couwenberg wrote:
 On 1/23/20 8:40 AM, Sebastiaan Couwenberg wrote:
> netcdf (1:4.7.3-1) is built & installed on all release architectures,
> please schedule the binNMUs except netcdf-fortan which is currently
> building on the buildds.

 The binNMUs that were scheduled have finished, please schedule the
 remainder of Dependency level 2.
>>>
>>> ferret-vis is done on all release architectures, please schedule the
>>> pyferret.
>>
>> magics++ is done too, cdo & metview can be schedule as well.
> 
> grass is done, qgis can be scheduled.

vtk7 is done too, lammps can be scheduled.

Kind Regards,

Bas

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

Bug#936857: libfreenect: Python2 removal in sid/bullseye

[Sandro Tosi]

> I would have tried going "longer" way, given the age of 0.5.3.  Would
> you have time for it Sandro, or should I try?

if you have spare cycles, i'd prefer if you could have a look at it

Cheers,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#947251: [Python-apps-team] Bug#947251: mypaint: Please build-depend on python-gi in addition to python-gi-dev

[Sandro Tosi]

On Mon, Jan 27, 2020 at 6:57 PM Simon McVittie  wrote:
> The long-term solution is dropping Python 2 (#937099).

there is a new beta version for 2.0.0 that should support python3;
it's in my backlog of activities for py2removal, but if someone wants
to have a go at that, that'd be great

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#940736: Bug#949938: d-feet build depends on the removed pep8 transitional package

[Sandro Tosi]

yep, this is clearly my fault.

i could either reintroduce pep8, or maybe we could have pycodestyle
provide pep8 and that should satisfy the dependencies?

On Mon, Jan 27, 2020 at 6:45 PM Simon McVittie  wrote:
>
> Control: tags 949938 + pending
>
> On Mon, 27 Jan 2020 at 13:21:03 +0200, Adrian Bunk wrote:
> > pep8 is no longer built by src:pep8.
>
> Thanks for reporting this, fix in progress. The pep8 binary package seems
> to have been removed without checking for reverse-dependencies. Affected
> packages:
>
> Checking reverse dependencies...
> # Broken Build-Depends:
> backup2swift: pep8  #949942
> budgie-extras: pep8 I'll open a bug
> byobu: pep8 #949941
> cloud-init: pep8#949940
> custodia: pep8  #949939
> d-feet: pep8#949938
> dirspec: pep8   #949937
> ovirt-guest-agent: pep8 I'll open a bug
> pygobject: pep8 Fix in progress
> python-apt: pep8I'll open a bug; fixed in experimental
> python-cliapp: pep8 #949936
> python-ddt: pep8#949935
> seqdiag: pep8 (>= 1.3)  #949934
> swiftsc: pep8   #949933
> syslog-ng: pep8 #949847
>
> Regards,
> smcv



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#949921: buster-pu: package uim_1.8.8-4+deb10u3

[Takatsugu Nokubi]

On Mon, 27 Jan 2020 15:18:15 +0900 NOKUBI Takatsugu  wrote:
> We uim maintainers had an another probrem #945344.
> The last update registers unusable uim modules.

The last diff lacks some commits, here is a new diff.
https://salsa.debian.org/debian/uim/snippets/386

diff --git a/debian/changelog b/debian/changelog
index 9b9b64b..74ffc2c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+uim (1:1.8.8-4+deb10u3) buster; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ NOKUBI Takatsugu ]
+  * d/libuim-data.postint: add uim-mozc (See #939588)
+
+  [ HIGUCHI Daisuke (VDR dai) ]
+  * d/libuim-data.postint: add uim-chewing
+
+  [ YOSHINO Yoshihito ]
+  * d/libuim-data.postinst: unregister not-installed modules (Closes: #945344).
+The previous upload to fix #939588 caused regression, which has
+accidentally registered some not-installed modules.
+
+ -- YOSHINO Yoshihito   Sun, 12 Jan 2020 19:42:26 +0900
+
 uim (1:1.8.8-4+deb10u2) buster; urgency=medium

   [ HIGUCHI Daisuke (VDR dai) ]
diff --git a/debian/libuim-data.postinst b/debian/libuim-data.postinst
index b0480fd..fd3891e 100755
--- a/debian/libuim-data.postinst
+++ b/debian/libuim-data.postinst
@@ -1,9 +1,19 @@
 #!/bin/sh

+register_module_was_broken=false
+
 register_module() {
 PKGNAME=$1
 MODNAME=$2
-dpkg-query -W -f='${Status}\n' $PKGNAME 2>/dev/null | grep
"not-installed" > /dev/null
+QSTRING=$(dpkg-query -W -f='${Status}\n' $PKGNAME 2>/dev/null)
+if [ $? = "1" ]
+then
+if $register_module_was_broken; then
+uim-module-manager --unregister $MODNAME --path /var/lib/uim
+fi
+return 0
+fi
+echo $QSTRING | grep "not-installed" > /dev/null
 if [ $? = "1" ]
 then
 uim-module-manager --register $MODNAME --path /var/lib/uim
@@ -12,6 +22,17 @@ register_module() {

 case "$1" in
 configure)
+if dpkg --compare-versions "$2" lt-nl "1:1.8.8-4+deb10u2.1" && \
+   dpkg --compare-versions "$2" gt "1:1.8.8-4"; then
+# buster
+register_module_was_broken=true
+fi
+if dpkg --compare-versions "$2" lt-nl "1:1.8.8-6.1~" && \
+   dpkg --compare-versions "$2" gt "1:1.8.8-5~"; then
+# bullseye/sid
+register_module_was_broken=true
+fi
+
if which uim-module-manager >/dev/null 2>&1; then
 register_module uim-anthy anthy-utf8
 register_module uim-byeoru byeoru
@@ -24,6 +45,8 @@ case "$1" in
 register_module uim-skk skk
 register_module uim-tcode tutcode
 register_module uim-viqr viqr
+register_module uim-mozc mozc
+register_module uim-chewing chewing
fi
 ;;

@@ -37,4 +60,4 @@ case "$1" in
 ;;
 esac

-exit 0
\ No newline at end of file
+exit 0

Bug#285551: Lieber Freund (Assalamu Alaikum),

[AISHA GADDAFI]

Lieber Freund (Assalamu Alaikum),

Ich bin vor einer privaten Suche auf Ihren E-Mail-Kontakt gestoßen
Ihre Hilfe. Mein Name ist Aisha Al-Qaddafi, eine alleinerziehende
Mutter und eine Witwe
mit drei Kindern. Ich bin die einzige leibliche Tochter des Spätlibyschen
Präsident (verstorbener Oberst Muammar Gaddafi).

Ich habe Investmentfonds im Wert von siebenundzwanzig Millionen
fünfhunderttausend
United State Dollar ($ 27.500.000.00) und ich brauche eine
vertrauenswürdige Investition
Manager / Partner aufgrund meines aktuellen Flüchtlingsstatus bin ich jedoch
Möglicherweise interessieren Sie sich für die Unterstützung von
Investitionsprojekten in Ihrem Land
Von dort aus können wir in naher Zukunft Geschäftsbeziehungen aufbauen.

Ich bin bereit, mit Ihnen über das Verhältnis zwischen Investition und
Unternehmensgewinn zu verhandeln
Basis für die zukünftige Investition Gewinne zu erzielen.

Wenn Sie bereit sind, dieses Projekt in meinem Namen zu bearbeiten,
antworten Sie bitte dringend
Damit ich Ihnen mehr Informationen über die Investmentfonds geben kann.

Ihre dringende Antwort wird geschätzt. schreibe mir an diese email adresse (
aishagaddafi...@aol.com) zur weiteren Diskussion.

Freundliche Grüße
Frau Aisha Al-Qaddafi
Antwort an: aishagaddafi...@aol.com

Bug#949986: kaddressbook: chokes querying unresponsive LDAP server for eternity

[John Scott]

Package: kaddressbook
Version: 4:19.08.3-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Filing against KAddressBook for now since I don't know what broke.
Steps to reproduce:
 1) do `nc -l -p 1999` to start a dummy LDAP server
 2) in KAddressBook, go to Settings -> Configure KAddressBook... ->
LDAP Server Settings -> Add Host... and then
Host: localhost,  Port: 1999,  LDAP version: 3, and Security either TLS or SSL.

Thereafter the other options don't make a difference, so 3) Query Server
and KAddressBook will hang. The Cancel button won't work, and setting Time 
limit:
prior doesn't make a difference either.

If one stops the dummy server, KAddressBook resumes, otherwise it hangs forever.
gdb gets me the backtrace below.

#0  0x7f47447ccd0f in __GI___poll (fds=0x563ec90f7cb4, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f473edc47b9 in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  ldap_int_select (ld=ld@entry=0x563ec8d06700, timeout=timeout@entry=0x0) at 
os-ip.c:1136
#3  0x7f473edaeced in wait4msg (ld=ld@entry=0x563ec8d06700, 
msgid=msgid@entry=1, all=all@entry=1, timeout=, 
timeout@entry=0x0, result=result@entry=0x7ffc7afecf50) at result.c:315
#4  0x7f473edaff54 in ldap_result (ld=ld@entry=0x563ec8d06700, msgid=1, 
all=all@entry=1, timeout=timeout@entry=0x0, result=result@entry=0x7ffc7afecf50) 
at result.c:120
#5  0x7f473edb31b8 in ldap_extended_operation_s 
(ld=ld@entry=0x563ec8d06700, reqoid=reqoid@entry=0x7f473ec4 
"1.3.6.1.4.1.1466.20037", reqdata=reqdata@entry=0x0, sctrls=sctrls@entry=0x0, 
cctrls=cctrls@entry=0x0, retoidp=retoidp@entry=0x7ffc7afecfb8, 
retdatap=0x7ffc7afecfc0) at extended.c:159
#6  0x7f473edd3d86 in ldap_start_tls_s (ld=0x563ec8d06700, 
serverctrls=serverctrls@entry=0x0, clientctrls=clientctrls@entry=0x0) at 
tls2.c:1050
#7  0x7f47417ccf1f in KLDAP::LdapConnection::connect (this=0x563ec8d3e450) 
at ./src/ldapconnection.cpp:335
#8  0x7f47417d7661 in LdapSearchPrivate::connect (this=0x563ec8a89580) at 
./src/ldapsearch.cpp:186
#9  0x7f47417d9aab in KLDAP::LdapSearch::search 
(this=this@entry=0x7ffc7afed170, url=..., count=count@entry=0) at 
./src/ldapsearch.cpp:312
#10 0x7f47417de8f9 in KLDAP::LdapConfigWidget::Private::sendQuery 
(this=this@entry=0x563ec8ba0370) at ./src/ldapconfigwidget.cpp:377
#11 0x7f47417df11c in KLDAP::LdapConfigWidget::Private::queryDNClicked 
(this=0x563ec8ba0370) at ./src/ldapconfigwidget.cpp:420
#12 0x7f4744d37528 in QtPrivate::QSlotObjectBase::call (a=0x7ffc7afed310, 
r=0x563ec8b653a0, 
this=0x563ec8abb680) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:394
#13 QMetaObject::activate (sender=0x563ec8abb220, signalOffset=, 
local_signal_index=, argv=) at 
kernel/qobject.cpp:3783
#14 0x7f47457fb312 in QAbstractButton::clicked 
(this=this@entry=0x563ec8abb220, _t1=) at 
.moc/moc_qabstractbutton.cpp:312
#15 0x7f47457fb52a in QAbstractButtonPrivate::emitClicked 
(this=0x563ec8abb260) at widgets/qabstractbutton.cpp:414
#16 0x7f47457fc8cf in QAbstractButtonPrivate::click (this=0x563ec8abb260) 
at widgets/qabstractbutton.cpp:407
#17 0x7f47457fca95 in QAbstractButton::mouseReleaseEvent 
(this=0x563ec8abb220, e=0x7ffc7afed880) at widgets/qabstractbutton.cpp:1011
#18 0x7f474574a786 in QWidget::event (this=0x563ec8abb220, 
event=0x7ffc7afed880) at kernel/qwidget.cpp:8965
#19 0x7f4745708c32 in QApplicationPrivate::notify_helper 
(this=this@entry=0x563ec84e60c0, receiver=receiver@entry=0x563ec8abb220, 
e=e@entry=0x7ffc7afed880) at kernel/qapplication.cpp:3700
#20 0x7f47457123e3 in QApplication::notify (this=, 
receiver=0x563ec8abb220, e=0x7ffc7afed880) at kernel/qapplication.cpp:3160
#21 0x7f4744d0ca92 in QCoreApplication::notifyInternal2 
(receiver=0x563ec8abb220, event=0x7ffc7afed880) at 
../../include/QtCore/../../src/corelib/kernel/qobject.h:142
#22 0x7f47457114f3 in QApplicationPrivate::sendMouseEvent 
(receiver=receiver@entry=0x563ec8abb220, event=event@entry=0x7ffc7afed880, 
alienWidget=alienWidget@entry=0x563ec8abb220, nativeWidget=0x7ffc7afee140, 
buttonDown=buttonDown@entry=0x7f4745c2b8d0 , 
lastMouseReceiver=..., spontaneous=true, onlyDispatchEnterLeave=false) at 
kernel/qapplication.cpp:2646
#23 0x7f4745766049 in QWidgetWindow::handleMouseEvent (this=0x563ec8b92750, 
event=0x7ffc7afedd00) at /usr/include/c++/9/bits/atomic_base.h:413
#24 0x7f4745768ed4 in QWidgetWindow::event (event=0x7ffc7afedd00, 
this=0x563ec8b92750) at kernel/qwidgetwindow.cpp:281
#25 QWidgetWindow::event (this=0x563ec8b92750, event=0x7ffc7afedd00) at 
kernel/qwidgetwindow.cpp:224
#26 0x7f4745708c32 in QApplicationPrivate::notify_helper 
(this=this@entry=0x563ec84e60c0, receiver=receiver@entry=0x563ec8b92750, 
e=e@entry=0x7ffc7afedd00) at kernel/qapplication.cpp:3700
#27 0x7f4745712190 in QApplication::notify (this=0x7ffc7aff01d0, 
receiver=0x563ec8b92750, 

Bug#946437: systemd-udevd: event4: Failed to call EVIOCSKEYCODE with scan code 0x70068, and key code 110: Invalid argument

[Vincent Lefevre]

On 2019-12-09 00:31:29 +0100, Vincent Lefevre wrote:
> I've noticed the following error (in red) in the journalctl output:
> 
> Dec 09 00:10:18 zira systemd-udevd[506]: event4: Failed to call EVIOCSKEYCODE 
> with scan code 0x70068, and key code 110: Invalid argument
> 
> This is not new.
> 
> I have a file /etc/udev/hwdb.d/98-apple-keyboard.hwdb with:
> 
> evdev:input:b0003v05ACp0221*
>  KEYBOARD_KEY_70068=insert  # F13: Insert
> 
> and this corresponds to
> 
> Bus 002 Device 005: ID 05ac:0221 Apple, Inc. Aluminum Keyboard (ISO)
> 
> I use the F13 key for Insert, as there is no Insert key on this
> keyboard (this is a Fn key at the usual place of the Insert key
> and the driver honors this specificity).
> 
> I have not seen any side effect of this error, though.

According to the Xorg log[*], the keyboard uses 2 event devices
(in particular, due to that, I get many duplicate lines in this
log file: one for each event device). But the error I get in the
journalctl output is only for the second event device.

[*] The lines from /var/log/Xorg.0.log corresponding to these two
event devices:

[18.667] (II) config/udev: Adding input device Apple, Inc Apple Keyboard 
(/dev/input/event3)
[18.667] (**) Option "Device" "/dev/input/event3"
[18.669] (II) event3  - Apple, Inc Apple Keyboard: is tagged by udev as: 
Keyboard
[18.669] (II) event3  - Apple, Inc Apple Keyboard: device is a keyboard
[18.669] (II) event3  - Apple, Inc Apple Keyboard: device removed
[18.698] (**) Option "config_info" 
"udev:/sys/devices/pci:00/:00:14.0/usb2/2-6/2-6.2/2-6.2:1.0/0003:05AC:0221.0001/input/input9/event3"
[18.700] (II) event3  - Apple, Inc Apple Keyboard: is tagged by udev as: 
Keyboard
[18.700] (II) event3  - Apple, Inc Apple Keyboard: device is a keyboard
[18.701] (II) config/udev: Adding input device Apple, Inc Apple Keyboard 
(/dev/input/event4)
[18.701] (**) Option "Device" "/dev/input/event4"
[18.704] (II) event4  - Apple, Inc Apple Keyboard: is tagged by udev as: 
Keyboard
[18.704] (II) event4  - Apple, Inc Apple Keyboard: device is a keyboard
[18.704] (II) event4  - Apple, Inc Apple Keyboard: device removed
[18.734] (**) Option "config_info" 
"udev:/sys/devices/pci:00/:00:14.0/usb2/2-6/2-6.2/2-6.2:1.1/0003:05AC:0221.0002/input/input10/event4"
[18.736] (II) event4  - Apple, Inc Apple Keyboard: is tagged by udev as: 
Keyboard
[18.736] (II) event4  - Apple, Inc Apple Keyboard: device is a keyboard
[ 16244.494] (II) event3  - Apple, Inc Apple Keyboard: device removed
[ 16244.510] (II) event4  - Apple, Inc Apple Keyboard: device removed
[ 25897.048] (II) event3  - Apple, Inc Apple Keyboard: is tagged by udev as: 
Keyboard
[ 25897.048] (II) event3  - Apple, Inc Apple Keyboard: device is a keyboard
[ 25897.049] (II) event4  - Apple, Inc Apple Keyboard: is tagged by udev as: 
Keyboard
[ 25897.049] (II) event4  - Apple, Inc Apple Keyboard: device is a keyboard
[ 26635.074] (II) event3  - Apple, Inc Apple Keyboard: device removed
[ 26635.094] (II) event4  - Apple, Inc Apple Keyboard: device removed
[ 28690.158] (II) event3  - Apple, Inc Apple Keyboard: is tagged by udev as: 
Keyboard
[ 28690.158] (II) event3  - Apple, Inc Apple Keyboard: device is a keyboard
[ 28690.159] (II) event4  - Apple, Inc Apple Keyboard: is tagged by udev as: 
Keyboard
[ 28690.159] (II) event4  - Apple, Inc Apple Keyboard: device is a keyboard

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

Bug#947847: please install systemd-sysusers using update-alternatives

[Michael Biebl]

Am 27.01.20 um 14:19 schrieb Michael Biebl:
> Am 27.01.20 um 11:18 schrieb Thomas Goirand:
> 
>> It is my view that what you're proposing would be a lot more work for on
>> valid reason. 
> 
> opensysusers as implementation will always lag behind systemd-sysusers
> and/or be incomplete, it might even be incompatible.
> This has the potential to negatively effect a systemd installation
> leading to a less robust system. Those issues will likely be hard to
> diagnose where we as maintainers have to spend time which would be
> better spent elsewhere.
> And all that for what? I don't see a compelling use case why swapping
> out the native reference implementation and running a combination which
> is untested (and unsupported by systemd upstream) would be a good idea.

I'm not subscribed to this bug report, so if the CTTE want's further
feedback on this issue from my side, please CC me.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#946567: Mention of luahbtex in texlive-luatex description

[Norbert Preining]

On Mon, 27 Jan 2020, Faheem Mitha wrote:
> But I have version 2019.20191208-4 installed, and it doesn't contain
> `luahbtex`.

Yes, because luahbtex is at the moment not build from the sources and
TL upstream only ships a few binaries for testing. This will change
with TL 2020.

Best

Norbert

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

Bug#946437: systemd-udevd: event4: Failed to call EVIOCSKEYCODE with scan code 0x70068, and key code 110: Invalid argument

[Vincent Lefevre]

Control: reopen -1
Control: reassign -1 src:linux 5.4.13-1

On 2020-01-28 02:06:17 +0100, Michael Biebl wrote:
> Ok, since this is not caused by a file shipped by udev, I'm closing
> this bug report.

The fact is that there is a bug. I assume that it comes from the
kernel then. And if the user is not supposed to add a udev rule,
then the driver is supposed to provide the Insert key on its side
anyway.

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

Bug#949984: sway: noticed 1.4 release (which may fix some issues I've had)

[Rob Browning]

Rob Browning  writes:

> Package: sway
> Severity: wishlist
>
> Looks like 1.4 has been released (1.3 was apparently skipped), and I
> suspect it might address some of the repeated crashes I've experienced
> when switching monitor inputs and/or plugging/unplugging a thunderbolt
> connection.
>
> Thanks much for the packaging work.

Oh, just happened to notice wlroots in NEW -- suspect you're well
underway.

Thanks again
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#946456: systemd: Provide systemd-sysusers as an independent package

[Michael Biebl]

Hi Emmanuel

On Mon, 09 Dec 2019 11:18:13 +0100 Emmanuel Bourg  wrote:
> Package: systemd
> Version: 244-3
> Severity: wishlist
> 
> Hi,
> 
> Would it be possible to move systemd-sysusers into an independent package?
> That would allow packages to use its declarative user creation syntax even
> on systems where elogind is installed and conflicts with systemd.


The problem with splitting out systemd-sysusers is, that the binary
systemd-sysusers binary links against libsystemd-shared (an internal
system library which changes its soname on every new upstream release).

 $ objdump -x /bin/systemd-sysusers  | grep NEEDED
  NEEDED   libc.so.6
  NEEDED   libsystemd-shared-244.so

Keep in mind that during a dist-upgrade, the systemd-sysusers binary
might be called at arbitrary, it would be quasi-essential.

This complicates matters a lot.

We could move libsystemd-shared from the systemd package to the new
systemd-sysusers package. But this will make the systemd package very
brittle, as the binaries from the systemd package require
libsystemd-shared as well. So not a option, really, as during partial
upgrades, the new systemd-sysuser package might be unpacked with the old
systemd package still being installed (and non functional binaries from
the systemd package).

We could move libsystemd-shared into a separate package, which is
so-versioned, so multiple versions can be installed at the same time
(systemd-shared-XXX), ensuring that during partial upgrades, binaries
continue to work.
This is not a compelling solution either, as this would mean, that on
each new upstream release, we'd have to go through the NEW queue.

Last but not least, we'd have the option to link systemd-sysusers
statically against libsystemd-shared. This would have the downside, that
it significantly increases the size of the binary. So we'd hurt the
overwhelming majority of the Debian users for questionable gain.

Imo, the real problem is, that the elogind package chose an approach
which conflicts with the systemd package. Imo, elogind should be an
addon package, which can be installed alongside systemd (and there would
be no libelogind0 conflicting with libsystemd0).

This boils down to a problem in elogind, which their maintainers need to
figure out. I gave my feedback on this matter in [1].

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923244#20



signature.asc
Description: OpenPGP digital signature

Bug#913062: light-locker: impossible to unlock: black screen, then the lightdm prompt again

[Vincent Lefevre]

On 2020-01-27 19:11:49 +0100, Yves-Alexis Perez wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Mon, 2020-01-27 at 10:54 +0100, Vincent Lefevre wrote:
> > It was the kernel from Debian/unstable at the time I reported the
> > bug, and it still occurred with linux-image-5.4.0-3-amd64 5.4.13-1.
> > 
> > > It's likely related to the *Xorg* driver, which is modesetting.
> > > A workaround has been added in the Linux kernel in unstable.
> > 
> > So it seems that this is not sufficient for me.
> 
> Hmhm ok. Just to check, do you see the “atomic disabled” message in
> the kernel log?

The whole journalctl log does not contain the word "atomic".

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

Bug#949985: Missing build dependency on libegl-dev

[Witold Baryluk]

Package: blender
Version: 2.81.a+dfsg-5
Severity: normal

It looks like blender needs libegl-dev (containing a libEGL.so symlink to
libEGL.so.1 from libegl1 package), to build correctly.

The libegl-dev is suggested by some other packages, during build process,
but it is not explicitly installed.

This makes build fail during cmake stage, for example on alpha and
kfreebsd-i386 archs.

https://buildd.debian.org/status/fetch.php?pkg=cmake=alpha=3.15.4-1=1579830052=0

Regards,
Witold

Bug#948745: ksh2020 vs. ksh93

[Anuradha Weeraman]

On Mon, Jan 27, 2020 at 08:00:08PM +0100, Thorsten Glaser wrote:
> On Fri, 24 Jan 2020, Anuradha Weeraman wrote:
> I had to change some things in src:ksh as well, for better
> coïnstallability, and for upgrading. Let’s hope this passes
> all tests and ftpmasters…

Thanks, looks great.

-- 
Regards
Anuradha

Bug#936857: libfreenect: Python2 removal in sid/bullseye

[Yaroslav Halchenko]

On Mon, 27 Jan 2020, Sandro Tosi wrote:
> in the archive we have 0.5.3, released in 2015; the latest upstream
> release is 0.5.7 which was released in 2017; the first release to
> support python3 is 0.5.4 of 2016.

> I see 2 paths forward:

> 1. (longer) the package gets upgraded to 0.5.7 (with a relative mini
> transition i guess) and that includes adding python3-freenect and drop
> python-freenect
> 2. (shorter) we keep 0.5.3 and we simply drop python-freenect, which
> has 0 reverse dependencies in the archive.

> What do you think it's best here?

I would have tried going "longer" way, given the age of 0.5.3.  Would
you have time for it Sandro, or should I try?

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik

Bug#946996: wireguard-tools: 'wg-quick down' segfaults

[Celejar]

On Thu, 23 Jan 2020 12:16:07 -0500
Daniel Kahn Gillmor  wrote:

> On Thu 2020-01-23 00:01:57 -0500, Celejar wrote:
> > So right after my last email, I upgraded to 1.0.20200121-1, and now I
> > no longer get a segfault. Is there anything further I should do? Should
> > I do a downgrade and try your modification?
> 
> If you don't mind downgrading (just the wireguard-tools package),
> modifying wg-quick as described, and retrying "ifdown wg0", that would
> be useful data to the iptables maintainers, as it should be input that
> produces a segmentation fault -- something that is not supposed to
> happen.
> 
> Then, you can probably upgrade wireguard-tools again and move on :)

I think I'm probably missing something, but lately "ifdown wg0" isn't
segfaulting (even after downgrading back to 1.0.20200102-1) - but it
doesn't seem to be calling iptables-restore at all, but only nft:

~# ifdown wg0
[#] ip -4 rule delete table 51820
[#] ip -4 rule delete table main suppress_prefixlength 0
[#] ip link delete dev wg0
[#] resolvconf -d tun.wg0 -f
[#] nft -f /dev/fd/63

~# apt-cache policy wireguard-tools 
wireguard-tools:
  Installed: 1.0.20200102-1
  Candidate: 1.0.20200121-2
  Version table:
 1.0.20200121-2 500
500 http://deb.debian.org/debian sid/main amd64 Packages
 *** 1.0.20200102-1 100
100 /var/lib/dpkg/status

Celejar

Bug#942293: needrestart: Nagios plugin mode fails when running sysvinit-core on Debian 10

[wirelessduck]

Thanks. I just tested with microcode checking disabled and it runs successfully.

This bug can now be closed.

Bug#886611: needrestart: detect need to reboot due to AMD microcode updates

[Paul Wise]

On Mon, 2020-01-27 at 21:10 +0100, Thomas Liske wrote:

> I was able to add some microcode parsing for AMD (see also 
> https://github.com/liske/needrestart/issues/150). It will be a 
> experimental feature of the upcoming needrestart 3.5 release.

Excellent, thanks for your work on needrestart.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#907635: add .apk as file extension for jar and jarsigner

[Gabriel F. T. Gomes]

Hi, Hugo,

thanks for reaching out.

On Mon, 27 Jan 2020, Hugo Ziviani wrote:
>
> I think this is not exactly a bug.

Are you saying this because you think that this is more like a
reasonable feature that is missing, as opposed to a bug that causes
crashes or wrong output?  If so, I would say that we don't need to care
too much about the words: bug, issue, feature, you-name-it.  These
words are used interchangeably sometimes/by some people.  If not, can
you explain why you think that this is not a bug?

> Could anyone give-me more information if I start upstream or I can
> start from here downstream.

Since it really looks like an upstream bug, I think it would be better
if it was fixed there first.  That way, we won't have to carry a patch
in Debian (which is problematic, since upstream can have a different
judgement on whether this needs fixing or not, which is why I avoid
downstream patches as much as possible), and we will just wait for
upstream to make a new release and the bug will be gone sort of
automatically.

On the other hand, you don't *have* to fix it upstream first.  If you
don't want to fix this upstream, I'll happily accept a patch from you
here in Debian (then I would forward it upstream).  It's really up to
you. :)

Do you have a patch already?
Could you send it to me here (or send it upstream and post a link
here), please?

Thanks again,
Gabriel

Bug#949984: sway: noticed 1.4 release (which may fix some issues I've had)

[Rob Browning]

Package: sway
Severity: wishlist

Looks like 1.4 has been released (1.3 was apparently skipped), and I
suspect it might address some of the repeated crashes I've experienced
when switching monitor inputs and/or plugging/unplugging a thunderbolt
connection.

Thanks much for the packaging work.
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#947251: mypaint: Please build-depend on python-gi in addition to python-gi-dev

[Simon McVittie]

Control: severity -1 serious
Control: tags -1 + ftbfs bullseye sid

On Mon, 23 Dec 2019 at 15:57:14 +, Simon McVittie wrote:
> This bug's severity will be increased to serious if it is still open
> when python-gi-dev's dependency on python-gi is removed in unstable.

Now done.

The short-term solution should be very simple: add python-gi to
Build-Depends. The long-term solution is dropping Python 2 (#937099).

smcv

Bug#945240: evolution: HTML messages become unreadable after changing theme

[Alberto Garcia]

On Mon, Jan 27, 2020 at 05:42:05PM -0600, Michael Catanzaro wrote:

> For Debian, I would backport the Evolution commit regardless of
> whether we decide the WebKit change is a fix or a regression, so
> that Evolution dark mode users can read their mail again.

That's fine with me. I'll follow the upstream WebKit bug anyway.

Berto

Bug#945240: evolution: HTML messages become unreadable after changing theme

[Michael Catanzaro]

On Thu, 9 Jan 2020 13:32:27 +0100 Alberto Garcia  
wrote:
> Backporting that patch to Evolution would certainly solve the 
problem,

> but I wonder if the change of behavior in WebKitGTK 2.26 ("font color
> in iframe not inherited") is a fix and not a regression. I'll try to
> figure that out.

Hi Berto!

For Debian, I would backport the Evolution commit regardless of whether 
we decide the WebKit change is a fix or a regression, so that Evolution 
dark mode users can read their mail again.


For WebKit, let's discuss in 
https://bugs.webkit.org/show_bug.cgi?id=202194 to keep things in one 
place.

Bug#949983: python-apt: Build-Depends on pep8 which has been removed

[Simon McVittie]

Source: python-apt
Version: 1.8.5
Severity: serious
Tags: ftbfs sid bullseye
Control: fixed -1 1.9.1

python-apt Build-Depends on the pep8 transitional package, which has
already been removed (see #940736). This makes python-apt unbuildable
in unstable. Please build-depend on pycodestyle instead, and if necessary
update any build scripts that run the 'pep8' executable so they run
'pycodestyle' instead.

The version in experimental appears to have fixed this already.

smcv

Bug#948855: buster-pu: package iputils/3:20180629-2

[Noah Meyerhans]

Control: tags -1 - moreinfo

On Fri, Jan 24, 2020 at 10:11:38PM +, Adam D. Barratt wrote:
> > I'd like to fix 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947921 in
> > buster.  Ping has some issues coping with explicitly specified source
> > interfaces when pinging DNS names and DNS returns multiple addresses
> > via getaddrinfo().  Please see the commit messages and the bug report
> > for in-depth explanation of what's going on.
> 
> The metadata for that bug report suggests that it affects the iputils
> package in unstable, and is not currently fixed there. Is that correct?

That's correct.  Upstream has not yet made a release containing the fix,
nor have I backported it to the version currently in testing (there are
enough changes to make that nontrivial).  I am making my request based
on the patch author's report that it does, indeed, fix the problem in
buster, and the fact that the fix has been accepted upstream.

If you'd prefer, we can wait until the next buster point release, by
which time we'll presumably have more testing of these patches.

noah

Bug#721192: ITP: uberwriter -- a simple markdown editor

[Nicholas D Steeves]

Control: retitle -1 ITP: uberwriter -- a simple markdown editor
Control: owner -1 !

I started packaging uberwriter for a family member and am currently
about 75% done.  Seeing as there hasn't been any activity for five
years I don't think anyone will object.

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#949981: budgie-extras: Build-Depends on pep8 which has been removed

[Simon McVittie]

Source: budgie-extras
Version: 0.9.1-1
Severity: serious
Tags: ftbfs sid bullseye
Control: fixed -1 0.91.0-1

budgie-extras Build-Depends on the pep8 transitional package, which has
already been removed (see #940736). This makes budgie-extras unbuildable
in unstable. Please build-depend on pycodestyle instead, and if necessary
update any build scripts that run the 'pep8' executable so they run
'pycodestyle' instead.

The version in experimental appears to have fixed this already.

smcv

Bug#949982: ovirt-guest-agent: Build-Depends on pep8 which has been removed

[Simon McVittie]

Source: ovirt-guest-agent
Version: 1.0.15.dfsg-1
Severity: serious
Tags: ftbfs sid bullseye

ovirt-guest-agent Build-Depends on the pep8 transitional package, which has
already been removed (see #940736). This makes ovirt-guest-agent unbuildable
in unstable. Please build-depend on pycodestyle instead, and if necessary
update any build scripts that run the 'pep8' executable so they run
'pycodestyle' instead.

smcv

Bug#940736: Bug#949938: d-feet build depends on the removed pep8 transitional package

[Simon McVittie]

Control: tags 949938 + pending

On Mon, 27 Jan 2020 at 13:21:03 +0200, Adrian Bunk wrote:
> pep8 is no longer built by src:pep8.

Thanks for reporting this, fix in progress. The pep8 binary package seems
to have been removed without checking for reverse-dependencies. Affected
packages:

Checking reverse dependencies...
# Broken Build-Depends:
backup2swift: pep8  #949942
budgie-extras: pep8 I'll open a bug
byobu: pep8 #949941
cloud-init: pep8#949940
custodia: pep8  #949939
d-feet: pep8#949938
dirspec: pep8   #949937
ovirt-guest-agent: pep8 I'll open a bug
pygobject: pep8 Fix in progress
python-apt: pep8I'll open a bug; fixed in experimental
python-cliapp: pep8 #949936
python-ddt: pep8#949935
seqdiag: pep8 (>= 1.3)  #949934
swiftsc: pep8   #949933
syslog-ng: pep8 #949847

Regards,
smcv

Bug#694398: pep8: please also check python scripts that are not named *.py

[Simon McVittie]

Control: reassign -1 pycodestyle

On Mon, 26 Nov 2012 at 10:40:34 +0800, Paul Wise wrote:
> It would be great if pep8 could detect files that are python scripts
> but are not named *.py.

Now that pep8 is no longer maintained upstream under that name, this
should presumably become a feature request for pycodestyle instead.

smcv

Bug#949960: Merging

[Lisandro Damián Nicanor Pérez Meyer]

reassign 949960 qtbase5-dev qtbase-opensource-src/5.12.5+dfsg-2
forcemerge merge 947117 949960
thanks

Hi! Indeed the bug is already solved in unstable, and it will hopefully migrate 
to testing in a few hours.


Cheers, Lisandro.

Bug#737474: Can't restore Audacious after minimizing

[Valdis Vītoliņš]

This bug also appears on Lubuntu 16.04.

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-01-27 23:24:22)
>   I: running --customize-hook directly: 
> /usr/share/autopkgtest/setup-commands/setup-testbed 
> ${HOME}/Downloads/mmdebstrap.2GP5UNhTac
>   /usr/share/autopkgtest/setup-commands/setup-testbed: Attempting to set up 
> Debian/Ubuntu apt sources automatically
>   /usr/share/autopkgtest/setup-commands/setup-testbed: Distribution assumed 
> to resemble Debian
>   update-initramfs: Generating /boot/initrd.img-5.4.0-3-amd64
>   W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module 
> r8169
>   [...]
>   W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module 
> r8169
>   cp: failed to access './/mkinitramfs_SqDsE7/lib/systemd/network/': No such 
> file or directory
>   E: /usr/share/initramfs-tools/hooks/udev failed with return 1.
>   update-initramfs: failed for /boot/initrd.img-5.4.0-3-amd64 with 1.
>   E: run_chroot failed: E: command failed: 
> /usr/share/autopkgtest/setup-commands/setup-testbed
>   I: main() received signal PIPE: waiting for setup...
>   W: listening on child socket failed: E: received eof on socket
>   
>   I: removing tempdir ${HOME}/Downloads/mmdebstrap.2GP5UNhTac...
>   $ ls -s
>   total 0
>   0 debian-unstable.tar
> 
> As you can see, I still obtain an empty file.
> 
> Did I misunderstand the situation?
> I thought it could work correctly, now...

this looks as if the error comes from
/usr/share/autopkgtest/setup-commands/setup-testbed. To figure out what goes
wrong, maybe try running setup-testbed with sh -x like so:

--customize-hook='sh -x /usr/share/autopkgtest/setup-commands/setup-testbed 
"$1"'

Your command works fine on my system, so this must be something specific to
your setup.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[Adam Borowski]

On Mon, Jan 27, 2020 at 02:46:32PM +0100, Gürkan Myczko wrote:
> 14:40 < tarzeau> coreboot sources are partly GPL-2-only (aka GPL-2) some are
> GPL-2-or-later (aka GPL-2+), is it possible to clean that up?
> 14:40 < tarzeau> relicense to one?
> 14:40 < maxii> but cb_parse_framebuffer() doesn't seem to get called
> 14:40 < tarzeau> debian/ubuntu packaging effort details:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946959
> 14:41 < maxii> nico_h: I think I am seeing the problem, not the solution.
> But at least a possible reason/the origin of the problem
> 14:41 < nico_h> tarzeau: you can just ship it as GPL-2-only, if that makes
> it easier
> 14:42 < tarzeau> well not really an option, i'm not the authority of the
> source files, so only authority of them can do so (if i did, it'd be a fork)
> 14:43 < tarzeau> (and even if i did and wanted, i can't just relicense stuff
> that's already published by another license)
> 14:44 -!- r1mikey [~r1mikey@2620:10d:c092:200::1:2fbd] has joined #coreboot
> 14:44 < nico_h> tarzeau: there's the point, you can relicense it in this
> case. and if you ship binaries that are build from both GPL-2-only and
> GPL-2-or-later you implicitly relicense parts of it anyway

I don't see any problem either.  GPL-2-only and GPL-2-or-higher are very
compatible licenses.  If you combine them, the result is GPL-2-only
(although if someone picks just GPL2+ pieces, they revert to compatibility
with GPL3 and so on.

That's the very point of license alternatives.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ The ill-thought conversion to time64_t will make us suffer from
⣾⠁⢠⠒⠀⣿⡁ the Y292B problem.  So let's move the Epoch by 43545140006400
⢿⡄⠘⠷⠚⠋⠀ (plus a safety margin in case of bad physicists) and make it
⠈⠳⣄ unsigned -- that'll almost double the range.

Bug#949800: libcgal-qt5-dev: Recommend qt?

[Joachim Reichel]

Control: tags -1 +pending

Hi Marc,

yes, good catch. I'm adding qtbase5-dev, libqt5opengl5-dev, and
libqt5svg5-dev, which contain the #include'd headers and also pull in tools
like moc.

Best regards,
  Joachim


On 25.01.20 09:40, Marc Glisse wrote:
> Package: libcgal-qt5-dev
> Version: 5.0-5+b1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I notice that libcgal-qt5-dev does not depend in any way on Qt and does
> not even suggest installing any Qt packages.
> 
> Before header-only, it depended on libcgal-qt5-13, which in turn
> installed several Qt dependencies, although probably not enough to do
> development. It looks like the Suggestions in libcgal-demo are the only
> ones that actually install Qt dev packages.
> 
> Do you think it would make sense to have libcgal-qt5-dev recommend some
> Qt packages? I don't know how much one can do with this package without
> Qt (I haven't tried).
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> 'testing'), (500, 'stable'), (50, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-2-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=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 libcgal-qt5-dev depends on:
> ii  libcgal-dev  5.0-5+b1
> 
> libcgal-qt5-dev recommends no packages.
> 
> libcgal-qt5-dev suggests no packages.
> 
> -- no debconf information
> 

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Sun, 17 Nov 2019 19:53:13 +0100 Johannes Schauer wrote:

> Quoting Johannes Schauer (2019-11-17 18:20:17)
> > > Maybe the recipe you suggested should be improved to address this issue
> > > with the selection of the mode...
> > 
> > Before doing that I'll see if this could be fixed by changing something in
> > either fakechroot or in update-initramfs.
> 
> See #944929

Hello Johannes!

After seeing bug #944929 closed as fixed in both unstable and testing,
I thought I could retry with mmdebstrap.
But I still get an error:

  $ cd Downloads
  $ TMPDIR='./'
  $ export TMPDIR
  $ mmdebstrap --variant=important --include=linux-image-amd64 \
  >   --customize-hook='chroot "$1" passwd --delete root' \
  >   --customize-hook='chroot "$1" useradd --home-dir /home/user --create-home 
user' \
  >   --customize-hook='chroot "$1" passwd --delete user' \
  >   --customize-hook='echo host > "$1/etc/hostname"' \
  >   --customize-hook='echo "127.0.0.1 localhost host" > "$1/etc/hosts"' \
  >   --customize-hook="/usr/share/autopkgtest/setup-commands/setup-testbed" \
  >   "sid" debian-unstable.tar
  I: automatically chosen mode: fakechroot
  I: chroot architecture amd64 is equal to the host's architecture
  I: using ${HOME}/Downloads/mmdebstrap.2GP5UNhTac as tempdir
  I: running apt-get update...
  done
  I: downloading packages with apt...
  done
  I: extracting archives...
  done
  I: installing packages...
  done
  I: downloading apt...
  done
  I: installing apt...
  done
  I: installing remaining packages inside the chroot...
  done
  I: running --customize-hook in shell: sh -c 'chroot "$1" passwd --delete 
root' exec ${HOME}/Downloads/mmdebstrap.2GP5UNhTac
  passwd: password expiry information changed.
  I: running --customize-hook in shell: sh -c 'chroot "$1" useradd --home-dir 
/home/user --create-home user' exec ${HOME}/Downloads/mmdebstrap.2GP5UNhTac
  I: running --customize-hook in shell: sh -c 'chroot "$1" passwd --delete 
user' exec ${HOME}/Downloads/mmdebstrap.2GP5UNhTac
  passwd: password expiry information changed.
  I: running --customize-hook in shell: sh -c 'echo host > "$1/etc/hostname"' 
exec ${HOME}/Downloads/mmdebstrap.2GP5UNhTac
  I: running --customize-hook in shell: sh -c 'echo "127.0.0.1 localhost host" 
> "$1/etc/hosts"' exec ${HOME}/Downloads/mmdebstrap.2GP5UNhTac
  I: running --customize-hook directly: 
/usr/share/autopkgtest/setup-commands/setup-testbed 
${HOME}/Downloads/mmdebstrap.2GP5UNhTac
  /usr/share/autopkgtest/setup-commands/setup-testbed: Attempting to set up 
Debian/Ubuntu apt sources automatically
  /usr/share/autopkgtest/setup-commands/setup-testbed: Distribution assumed to 
resemble Debian
  update-initramfs: Generating /boot/initrd.img-5.4.0-3-amd64
  W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module 
r8169
  [...]
  W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module 
r8169
  cp: failed to access './/mkinitramfs_SqDsE7/lib/systemd/network/': No such 
file or directory
  E: /usr/share/initramfs-tools/hooks/udev failed with return 1.
  update-initramfs: failed for /boot/initrd.img-5.4.0-3-amd64 with 1.
  E: run_chroot failed: E: command failed: 
/usr/share/autopkgtest/setup-commands/setup-testbed
  I: main() received signal PIPE: waiting for setup...
  W: listening on child socket failed: E: received eof on socket
  
  I: removing tempdir ${HOME}/Downloads/mmdebstrap.2GP5UNhTac...
  $ ls -s
  total 0
  0 debian-unstable.tar

As you can see, I still obtain an empty file.

Did I misunderstand the situation?
I thought it could work correctly, now...


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


pgpxrtBFMLY7R.pgp
Description: PGP signature

Bug#949980: libgl1-mesa-dri: SIGSEGV in rockchip_dri.so when running Gnome/GTK

[Antoine Sirinelli]

Package: libgl1-mesa-dri
Version: 19.3.2-1
Severity: important

Dear Maintainer,

On Debian-testing, arm64 architecture, on Pinebook Pro hardware.
Since a recent upgrade of libgl1-mesa-dri from 19.2.6-1 to 19.3.2-1, I
cannot launch most Gnome/GTK programs. This leads to a crash of the Xorg
server (SIGSEGV). Version 19.2.6-1 was fine. I am using i3 window
manager. At the moment I have not been able to find a mitigation action,
I am just avoiding Gnome/GTK applications: gimp, evince, pavucontrol,
Firefox (only file dialogs)...

I have been able to get the backtrace of the crash, I am attaching the
full gdb output.

Note that I have replaced the Xorg.log below by the one linked to the
crash.


-- Package-specific info:
glxinfo:

name of display: :0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
GLX_ARB_create_context, GLX_ARB_create_context_no_error, 
GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
GLX_EXT_create_context_es2_profile, GLX_EXT_create_context_es_profile, 
GLX_EXT_fbconfig_packed_float, GLX_EXT_framebuffer_sRGB, 
GLX_EXT_import_context, GLX_EXT_libglvnd, GLX_EXT_no_config_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
GLX_ARB_context_flush_control, GLX_ARB_create_context, 
GLX_ARB_create_context_no_error, GLX_ARB_create_context_profile, 
GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
GLX_ARB_create_context, GLX_ARB_create_context_no_error, 
GLX_ARB_create_context_profile, GLX_ARB_fbconfig_float, 
GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
GLX_EXT_buffer_age, GLX_EXT_create_context_es2_profile, 
GLX_EXT_create_context_es_profile, GLX_EXT_fbconfig_packed_float, 
GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, GLX_MESA_query_renderer, 
GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
GLX_SGI_swap_control, GLX_SGI_video_sync
Extended renderer info (GLX_MESA_query_renderer):
Vendor: panfrost (0x)
Device: panfrost (0x)
Version: 19.3.2
Accelerated: yes
Video memory: 3860MB
Unified memory: yes
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL vendor string: panfrost
OpenGL renderer string: panfrost
OpenGL version string: 2.1 Mesa 19.3.2
OpenGL shading language version string: 1.20
OpenGL extensions:
GL_AMD_draw_buffers_blend, GL_AMD_seamless_cubemap_per_texture, 
GL_AMD_shader_trinary_minmax, GL_APPLE_packed_pixels, 
GL_ARB_ES2_compatibility, GL_ARB_clear_buffer_object, 
GL_ARB_compressed_texture_pixel_storage, GL_ARB_copy_buffer, 
GL_ARB_copy_image, GL_ARB_debug_output, GL_ARB_depth_buffer_float, 
GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, 
GL_ARB_draw_elements_base_vertex, GL_ARB_explicit_attrib_location, 
GL_ARB_explicit_uniform_location, GL_ARB_fragment_coord_conventions, 
GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, 
GL_ARB_fragment_shader, GL_ARB_framebuffer_object, 
GL_ARB_framebuffer_sRGB, GL_ARB_get_program_binary, 
GL_ARB_get_texture_sub_image, GL_ARB_half_float_pixel, 
GL_ARB_half_float_vertex, GL_ARB_internalformat_query, 
GL_ARB_internalformat_query2, GL_ARB_invalidate_subdata, 
GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, GL_ARB_multi_bind, 
GL_ARB_multisample, GL_ARB_multitexture, 

Bug#949979: ITP: talkatu -- GTK+ widgets for instant messaging clients

[Richard Laager]

Package: wnpp
Severity: wishlist
Owner: Richard Laager 

* Package name: talkatu
  Version : 0.1.0-dev
  Upstream Author : Gary Kramlich 
* URL : https://bitbucket.org/rw_grim/talkatu/
* License : GPL-2+
  Programming Lang: C
  Description : GTK+ widgets for instant messaging clients

Talkatu is a collection of Gtk+ widgets that are useful for chat
applications.

--

"It was started as a rewrite of the GtkIMHTML widget found in Pidgin,
 but quickly expanded to include most things related to conversation
 windows."

This is the successor to Pidgin 2's GtkIMHTML widget and is a dependency
of Pidgin 3.

My intention is to package this for experimental only, until such time
as it and Pidgin 3 have stable releases. Having this in experimental
will make it easier for people to build Pidgin 3 and will ensure the
packaging is ready when Pidgin 3 is.

This package will be maintained on Debian Salsa at (not yet created):
https://salsa.debian.org/debian/talkatu

-- 
Richard

Bug#949978: ITP: gplugin -- GObject based plugin library

[Richard Laager]

Package: wnpp
Severity: wishlist
Owner: Richard Laager 

* Package name: gplugin
  Version : 0.29.0
  Upstream Author : Gary Kramlich 
* URL : https://bitbucket.org/rw_grim/gplugin/
* License : GPL-2+
  Programming Lang: C
  Description : GObject based plugin library

GPlugin is a GObject based library that implements a reusable plugin
system which supports loading plugins in other languages via loaders. It
relies heavily on GObjectIntrospection to expose its API to the other
languages.

--

This is a dependency of Pidgin 3.

My intention is to package this for experimental only, until such time
as it and Pidgin 3 have stable releases. Having this in experimental
will make it easier for people to build Pidgin 3 and will ensure the
packaging is ready when Pidgin 3 is.

This package will be maintained on Debian Salsa at (not yet created):
https://salsa.debian.org/debian/gplugin

-- 
Richard

Bug#949977: ITP: libgnt -- GLib Ncurses Toolkit

[Richard Laager]

Package: wnpp
Severity: wishlist
Owner: Richard Laager 

* Package name: libgnt
  Version : 2.14.0-devel
  Upstream Author : Pidgin Developers 
* URL : https://bitbucket.org/pidgin/libgnt/
* License : GPL-2+
  Programming Lang: C
  Description : GLib Ncurses Toolkit

GNT is an ncurses toolkit for creating text-mode graphical user
interfaces in a fast and easy way. It is based on GLib and ncurses.

It was born out of the console-based UI, Finch, for the libpurple
project.

--

This code is currently part of the Pidgin upstream tarball and thus the
pidgin source package, but is being broken out upstream for the next
release.  Accordingly, I am breaking it out into a new package in
Debian.  I am working with Ari Pollak, the pidgin package maintainer.

My intention is to prepare the package using a development snapshot so
that everything is ready in advance for the 2.14.0 releases of libgnt
and Pidgin. Given that this is already a stable library and going to be
a dependency of the next minor release of Pidgin, I am leaning towards
uploading to unstable rather than experimental, but I can be convinced
otherwise.

This package will be maintained on Debian Salsa at (not yet created):
https://salsa.debian.org/debian/libgnt

-- 
Richard

Bug#920937: (no subject)

[chriso]

I seem to have the same problem with version 20190717 (debian testing 
5.4.13-1 amd64). Syslog contains many different stack traces, but the 
first ones, are:



Jan 27 20:00:52 dellbian kernel: [34291.564389] perf: interrupt took too 
long (6719 > 6696), lowering kernel.perf_event_max_sample_rate to 29750
Jan 27 20:08:11 dellbian wpa_supplicant[645]: wlp3s0: 
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-69 noise=-92 txrate=6000
Jan 27 20:08:12 dellbian wpa_supplicant[645]: wlp3s0: 
CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-60 noise=-92 txrate=6000
Jan 27 20:08:13 dellbian wpa_supplicant[645]: wlp3s0: WPA: Group 
rekeying completed with xx:xx:xx:xx:xx:xx [GTK=CCMP]
Jan 27 20:10:50 dellbian kernel: [34889.456648] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x0003a028: -110
Jan 27 20:10:51 dellbian kernel: [34890.450607] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x0003a028: -110
Jan 27 20:11:26 dellbian kernel: [34925.480114] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x0003a028: -110
Jan 27 20:13:17 dellbian kernel: [35036.877206] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0x0010 at 0x0003503c: -110
Jan 27 20:13:18 dellbian kernel: [35037.378768] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0x1bf5 at 0x0003543c: -110
Jan 27 20:13:18 dellbian kernel: [35037.934095] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0x0011 at 0x0003503c: -110
Jan 27 20:13:22 dellbian wpa_supplicant[645]: wlp3s0: 
CTRL-EVENT-SCAN-FAILED ret=-110 retry=1
Jan 27 20:13:22 dellbian kernel: [35041.097587] ath10k_pci :03:00.0: 
failed to receive scan abortion completion: timed out
Jan 27 20:13:22 dellbian kernel: [35041.097598] ath10k_pci :03:00.0: 
failed to stop scan: -110
Jan 27 20:13:22 dellbian kernel: [35041.097602] ath10k_pci :03:00.0: 
failed to start hw scan: -110
Jan 27 20:13:23 dellbian kernel: [35042.414095] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0x1bf7 at 0x0003543c: -110
Jan 27 20:13:24 dellbian kernel: [35043.438152] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0x1bf9 at 0x0003543c: -110
Jan 27 20:13:25 dellbian kernel: [35044.462181] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0x1bfb at 0x0003543c: -110
Jan 27 20:13:26 dellbian wpa_supplicant[645]: wlp3s0: 
CTRL-EVENT-SCAN-FAILED ret=-11 retry=1
Jan 27 20:13:26 dellbian kernel: [35045.193612] ath10k_pci :03:00.0: 
wmi command 12289 timeout, restarting hardware
Jan 27 20:13:26 dellbian kernel: [35045.193626] ath10k_pci :03:00.0: 
failed to start hw scan: -11
Jan 27 20:13:26 dellbian kernel: [35045.246093] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x0003442c: -110
Jan 27 20:13:26 dellbian kernel: [35045.282545] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0xfffe at 0x0003442c: -110
Jan 27 20:13:26 dellbian kernel: [35045.318972] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x00034434: -110
Jan 27 20:13:26 dellbian kernel: [35045.355384] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0xf81f at 0x00034434: -110
Jan 27 20:13:26 dellbian kernel: [35045.391793] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x0003442c: -110
Jan 27 20:13:28 dellbian kernel: [35047.431164] ath10k_warn: 55 
callbacks suppressed
Jan 27 20:13:28 dellbian kernel: [35047.431165] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0xfffe at 0x00034c2c: -110
Jan 27 20:13:28 dellbian kernel: [35047.467668] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x00034c34: -110
Jan 27 20:13:28 dellbian kernel: [35047.504139] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0xf81f at 0x00034c34: -110
Jan 27 20:13:28 dellbian kernel: [35047.540625] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x00034c2c: -110
Jan 27 20:13:28 dellbian kernel: [35047.577109] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0xffe1 at 0x00034c2c: -110
Jan 27 20:13:28 dellbian kernel: [35047.613658] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x0003502c: -110
Jan 27 20:13:28 dellbian kernel: [35047.650117] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0xfffe at 0x0003502c: -110
Jan 27 20:13:28 dellbian kernel: [35047.686565] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x00035034: -110
Jan 27 20:13:28 dellbian kernel: [35047.723053] ath10k_pci :03:00.0: 
failed to wake target for write32 of 0xf81f at 0x00035034: -110
Jan 27 20:13:28 dellbian kernel: [35047.759535] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x0003502c: -110
Jan 27 20:13:33 dellbian kernel: [35052.460081] ath10k_warn: 127 
callbacks suppressed
Jan 27 20:13:33 dellbian kernel: [35052.460083] ath10k_pci :03:00.0: 
failed to wake target for read32 at 0x0003a028: -110
Jan 27 20:13:33 dellbian kernel: 

Bug#946959: RFS: coreboot/4.10-1 [ITP] -- Coreboot firmware utilities

[John Scott]

> > If there really is a problem with those files I would appreciate your
> > letting me know what I missed. Otherwise I hope you can avoid the 
> > repacking trouble in the future.
> Probably not, but the repacking is not trouble.

Without a good reason, you really shouldn't repack [1]. I do not understand 
your motivation for removing those files since they don't end up in the binary 
packages.

Repacking means that you, collaborators, and volunteers working on quality 
assurance can't
* use tools like uupdate to upgrade to a new upstream version very easily
* can't verify the tarball against upstream's signature
* package those parts being removed from Coreboot later on without duplicating 
effort into another source package

Perhaps you're not aware that it is typical to disregard parts of the package 
that aren't built (yet). Otherwise I would like to know what advantage it has 
for my own potential applications, and you should explain in debian/copyright 
how the source differs [2].

> You can save you that pain. I already stole your watch file, now it
> says:
> E: coreboot source: debian-watch-file-pubkey-file-is-missing

I thought I had sent a merge request, but seeing no trace I must not have. I 
wanted it to have an explanation of how to modify the watch file to do the 
repacking for you.
It's necessary to put the Coreboot team's minimal OpenPGP
key in debian/upstream/signing-key.asc, and I didn't do it because of the 
sensitivity of the key material. The wiki [3] explains what you need to do, 
and to determine the key you need, GnuPG will say or complain which if you try 
verifying the tarball.

[1] https://perl-team.pages.debian.net/howto/repacking.html#0._INTRODUCTION
[2] https://wiki.debian.org/BenFinney/software/repack
[3] https://wiki.debian.org/debian/watch#Cryptographic_signature_verification

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

Bug#937061: Python3 Port of ModelBuilder

[Scott Talbert]

On Tue, 3 Dec 2019, Andreas Tille wrote:


if someone will show interest by writing an autopkgtest (or would
provide some test script to prove the functionality which I'd
volunteer to turn into an autopkgtest) I'd feel slightly motivated
to package BIP and try my luck with a Python3 port.


Any objections to RM'ing model-builder?

Scott

Bug#948965: calamares: Debian 11 live testing amd64 LXQt + non-free fails with: "Bad unsquash configuration"

[scott092707]

Further attempts to install, with images through the current 01/27/2020 .iso,
continue to fail in exactly the same way.

Bug#949944: cppcheck-htmlreport not packaged anymore in sid

[Joachim Reichel]

Control: tags -1 +pending

Hi Michal,

> It seems that cppcheck-htmlreport is not packaged anymore in the cppcheck
> package from sid, see https://packages.debian.org/sid/amd64/cppcheck/filelist.

yes, right. Thanks for reporting.

Best regards,
  Joachim

Bug#947744: installation-reports: Debian Live Testing LXQt + nonfree - install fails with: "Bad unsquash configuration"

[scott092707]

Further attempts to install, with images through the current 01/27/2020 .iso,
continue to fail in exactly the same way.

Bug#907635: add .apk as file extension for jar and jarsigner #907635

[Hugo Ziviani]

Hello, I’m Hugo, and I would like to take this correction (#907635). 
I think this is not exactly a bug. 
Could anyone give-me more information if I start upstream or I can start from 
here downstream. 
Thanks, 
Hugo 

Bug#905453: debian-policy: Policy does not include a section on NEWS.Debian files

[Nicholas D Steeves]

On Sun, Aug 05, 2018 at 12:02:11AM -0700, Jonathan Nieder wrote:
> Hi Elana,
> 
> Elana Hashman wrote:
> 
> > NEWS.Debian files are listed in the "unofficial policy"[1] but not in
> > the official policy.
> >
> > It seems this was proposed in 2002[2], but in 2003, folks were
> > hesitant to "[get] this into policy until enough stuff uses it that we
> > can tell it works well".
> >
> > Is 15 years long enough? Can we make this official?
> 
> It would be a welcome addition!  Do you have ideas for wording?
> 

The section in Developer's reference looks good to me, and the only
nitpits I have with are a couple of grammar issues.  If no one has any
objections I'd be happy to copy move the section, properly attribute
its author, resolve these issues.

One thing I'm not sure about is what Policy section it would go in.
Would it be appended to §4 as §4.18, or something else?

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#907635: add .apk as file extension for jar and jarsigner

[Hugo Ziviani]

Hello, I’m Hugo, and I would like to take this correction (#907635).
I think this is not exactly a bug.
Could anyone give-me more information if I start upstream or I can start from 
here downstream.
Thanks,
Hugo

___
ERROR Related:
Package: bash-completion
Version: 1:2.8-1

Android APK files are officially defined as JAR files with JAR
signatures.  An APK _must_ have a JAR signature to be considered a valid
APK.  JAR signatures in Android land are known as "v1 signatures", there
is now v2 and v3 signatures which are still compatible with JAR, but not
verified or created by JAR tools.

I would really love to see `jarsigner` and `jar` do proper completion
for .apk files.

Bug#948205: buster-pu: package sogo-connector/60.0.2-1

[Carsten Schoenert]

Hi again,

On Sat, Jan 25, 2020 at 07:34:20PM +, Adam D. Barratt wrote:
> The delights of mozilla-related packages and stable. :-( Please go
> ahead.

thanks!
Also in NEW due the new binary package.

Regards
Carsten

Bug#949976: p11-kit update breaks flatpak

[Vincent Bernat]

Package: p11-kit
Version: 0.23.19-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Upgarding p11-kit to 0.23.19 breaks many Flatpaks, including Steam and
Spotify. It seems Flatpak is using p11-kit-remote and the on-wire
format was updated, but the details are a bit fuzzy. This can be
solved by downgrading to 0.23.18.1-2 in testing.

More information:
 https://bbs.archlinux.org/viewtopic.php?id=252390

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

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

Versions of packages p11-kit depends on:
ii  libc62.29-9
hi  libp11-kit0  0.23.18.1-2
ii  libtasn1-6   4.15.0-2
hi  p11-kit-modules  0.23.18.1-2

p11-kit recommends no packages.

p11-kit suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAl4vUYoSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX55GAP/iTuwh6/imUbYIsjInNmB+Pmj+4Bgtjp
ssiSnEDCDYOGjm+3KmxP2GHdHsrWY5xGv8xLLGepy+VLp43FwR3wC5dve12XWstU
EpwqvLf9c4lFPM/RUmRS21727rcDqS7eaOiVSN/OUty5LWJHWbEUTVy++PIre9Jn
V0ECF3+pvP9jk/miKmQYdFbXAoUoWCtJmdmdTTa6Kxz/JnyfTolXxIJP83tFrD17
9UvCZSIf5UIFO++QYh3PdBMtoDj1RO24+BUK/M5Zu1a7JzUAFA7lskZO9emHVBdz
oxElspv9xhycSms2/gmLtnFw96ejabjMB3JaVGt5Fc14FSdmIFAlayqmPKkV2cZv
PxrsnC81epeMd1Gzu+zN68kkFC4fCFFyr4vKb0gQp1q1k0OGYFlS0HVEkOr1wT6h
+eL24hFhBPLiOR/knUgHljBKcfL4shGdWJKABloPEzoK+1HbOPra3QD0OvmWf16A
ouCxYpJvciTYQpi0zOW1+vHBOdk/udFPDaHcstvSos9b/+vLKyAltYf+N1qOPf5f
WT3Yjn59bK55BuVSCqZor6AgpCmsEhhUKj72JswTYU4H+oT5w242KoHy6phY1bM6
P5/gA/KhPR8cPKnIfCnx9QKdC9v/te32RwkuZWoJ0acyr3mrqOQjx5oAA8ghZzAK
fnXEUKe21gHs
=pNCd
-END PGP SIGNATURE-

Bug#934479: fails to detect linux update on arm64 (Re: false negative: linux-image-4.19.0.5-powerpc64le)

[thomas]

tags 934479 upstream moreinfo
thanks


Hi,

could you please provide the output of:

  needrestart -k -v


Thanks,
Thomas


On Fri, 23 Aug 2019, Vagrant Cascadian wrote:


Package: needrestart
Version: 3.4-5
Followup-For: Bug #934479

Also encountering on arm64, with an upgrade of
linux-image-5.2.0-2-arm64 to a newer version:

 $ uname -a
 Linux ponder 5.2.0-2-arm64 #1 SMP Debian 5.2.9-1 (2019-08-18) aarch64 GNU/Linux
 $ ls -l /boot/vmlinuz-5.2.0-2-arm64
 -rw-r--r-- 1 root root 19775344 Aug 21 05:48 /boot/vmlinuz-5.2.0-2-arm64
 $ sudo needrestart
 Scanning processes...
 Scanning linux images...

 Running kernel seems to be up-to-date.

 Failed to check for processor microcode upgrades.

 No services need to be restarted.

 No containers need to be restarted.

 No user sessions are running outdated binaries.

I've had two updates over the last few days where it didn't detect the
newer kernel version.

live well,
 vagrant

-- Package-specific info:
needrestart output:



-- System Information:
Debian Release: 10.0
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable'), (120, 'unstable'), (1, 
'experimental')
Architecture: arm64 (aarch64)

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

Versions of packages needrestart depends on:
ii  binutils   2.31.1-16
ii  dpkg   1.19.7
ii  gettext-base   0.19.8.1-9
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.27-1
ii  libproc-processtable-perl  0.56-1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.38-1
ii  perl   5.28.1-6
ii  xz-utils   5.2.4-1

Versions of packages needrestart recommends:
ii  libpam-systemd  241-5

Versions of packages needrestart suggests:
pn  iucode-tool  
pn  needrestart-session | libnotify-bin  

-- no debconf information




--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  GnuPG: 0x49D0C2C3  mailto:tho...@fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#948203: buster-pu: package compactheader/2.1.6-1

[Carsten Schoenert]

Hello Adam,

On Sat, Jan 25, 2020 at 07:36:03PM +, Adam D. Barratt wrote:
> It's obviously not an ideal situation, but please go ahead.

yes, hopefully Mozilla wont change their AddOn API again within the next
ESR cycle of TB.

Uploaded minutes ago, it's in NEW due the new binary package. Hopefully
the FTP-Master can act in time. :)

Regards
Carsten

Bug#949975: coq,coqide: both ship /usr/bin/coqidetop{,.opt}

[Andreas Beckmann]

Package: coq,coqide
Version: 8.9.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

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

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

  Preparing to unpack .../120-coqide_8.9.1-4_amd64.deb ...
  Unpacking coqide (8.9.1-4) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-XoXXFb/120-coqide_8.9.1-4_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/coqidetop', which is also in package coq 
8.9.1-4
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-XoXXFb/120-coqide_8.9.1-4_amd64.deb


cheers,

Andreas


coqide=8.9.1-4_coq=8.9.1-4.log.gz
Description: application/gzip

Bug#949974: More details

[Enrico Zini]

Hello,

I tracked the issue: in http1connection.py, the write method does:

self._pending_write = self.stream.write(fchunk)
self._pending_write.add_done_callback(self._on_write_complete)   

The Future[1] documentation says:

Callbacks registered with add_done_callback() are always called via
the event loop’s call_soon_threadsafe().

So although self._pending_write in that case is already in a 'done'
state, self._on_write_complete is only called the next time we'll
reenter the event loop.

Meanwhile, before returning to the event loop, the flow of the code
continues and RequestHandler.finish calls:

self.request.connection.finish()

It detects correctly that there is still a pending write, and calls:

future_add_done_callback(self._pending_write, self._finish_request)

However, future_add_done_callback does not schedule self._finish_request
for the next ioloop iteration like Future.add_done_callback does:

# concurrent.py:
def future_add_done_callback(future, callback):
# …
if future.done():
callback(future)
else:
future.add_done_callback(callback)

Compare with:

# In concurrent.py, class Future:
def add_done_callback(self, fn):
# …
if self._done:
from tornado.ioloop import IOLoop
IOLoop.current().add_callback(fn, self)
else:
self._callbacks.append(fn)

So self._finish_request is called before self._on_write_complete,
_clear_callbacks() is called, which resets self._write_callbacks.

When control returns to the event loop, _on_write_complete is finally,
called, which finds self._write_future set to None, and won't trigger
the future that will permit RequestHandler.flush() to continue.

If there is still data to write, self._pending_write is not done when
future_add_done_callback is called, and RequestHandler.flush() won't get
stuck.


Enrico


[1] 
https://www.tornadoweb.org/en/stable/concurrent.html#tornado.concurrent.Future.add_done_callback

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#948477: transition: openbabel

[Paul Gevers]

Hi Andrius,

On 16-01-2020 11:48, mer...@debian.org wrote:
> Thanks a lot, I will wait a week before working on the transition.

I see you went ahead *and* you added an autopkgtest to openbabel.
Obviously I love autopkgtests, however, the test fails and times out on
arm64.

In case you don't know how to fix the test for arm64, I suggest you mark
the test with the skippable restriction and exit 77 at the start of the
test if it detects it runs on arm64. Obviously, fixing the test is better.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#927963: fails to detect updates in dhclient/libisc-export1100

[thomas]

Hi,

On Fri, 3 May 2019, Antoine Beaupré wrote:


In my opinion, a "blacklisted" service should still warn. Isn't that the
case for stuff like dbus that they do get marked as needing a restart
but don't get restarted automatically?


there is a (long) list of overrides for daemons that are not restarted 
by default. Dhclient is currently blacklisted so it is completely ignored. 
There are to many ways howto use dhclient (call it manualy, call it by 
ifupdown, use NetworkManager or WICD, ...) and for most cases it is not 
possible to restart it.


This is why the default configuration ignores it completely.


Regards,
Thomas

--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  GnuPG: 0x49D0C2C3  mailto:tho...@fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#944603: Check Printing Bug

[John Stewart]

Hello ,

I was very interested in the bug reported for check printing in Debian Buster.
I am running Gnucash on Raspian Buster on the Raspberry Pi 4 and check printing
crashes Gnucash 3.4.1. 

Linux aa5kv 4.19.93-v7l+ #1290 SMP Fri Jan 10 16:45:11 GMT 2020 armv7l GNU/Linux


I will report this bug to Raspian and provide the bug report number in Debian.

Hope we get this fixed soon, although I understand it is resolved in 3.5.

Thanks,

---John Stewart

Bug#886611: needrestart: detect need to reboot due to AMD microcode updates

[thomas]

tags 886611 fixed-upstream
thanks


Hi pabs,

I was able to add some microcode parsing for AMD (see also 
https://github.com/liske/needrestart/issues/150). It will be a 
experimental feature of the upcoming needrestart 3.5 release.



HTH,
Thomas


On Mon, 8 Jan 2018, Paul Wise wrote:


On Mon, 2018-01-08 at 08:00 +0100, Thomas Liske wrote:


checking if initramfs is newer than uptime might be a good idea


Possibly, but there might be false positives if the initramfs was
regenerated without having updated any files in it. Also, not every
initramfs contains files that are currently loaded/running. Only ones
that are include microcode and Linux kernel modules, but see below.


A reboot may be also required due to updates of 3rd party
kernel modules (like DKMS) if they are part of the initramfs.


Those can often just be unloaded and then reloaded again.

It would be good to detect when that is needed and possible, but Linux
doesn't seem to expose any info about the filesystem timestamp of the
currently loaded modules.

Once that is exposed, then you would have to determine if any resources
the modules expose are being used by any processes/mounts/etc.

Ones that aren't being used can just be unloaded/reloaded if they are
compatible with the current Linux kernel ABI.

Ones that are used will need a complicated dance where the services are
stopped (or processes stopped), the module reloaded and services
started again.


I would avoid to parse the initramfs in needrestart (would need to
handle different compression and archive file types etc.) just to look
for the microcode files. Report and recommend a reboot if there is an
updated initramfs should be sufficient, shouldn't it?


Agreed, this is why I suggested to look at the files from the AMD
microcode package instead. As explained above, I think that would
result in some false positives. Since reboots are costly for some
systems, I would recommend avoiding those false positives.




--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  GnuPG: 0x49D0C2C3  mailto:tho...@fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#925408: needrestart: false positive: gnome-session-binary, gnome-shell

[thomas]

tags 925408 -moreinfo upstream fixed-upstream
thanks


Hi,

for some reason your gnome-* has a removed mapping from /tmp. Upstream has 
been fixed to ignore those mappings.



Thanks,
Thomas

--

::  WWW:https://fiasko-nw.net/~thomas/  ::
   :::  GnuPG: 0x49D0C2C3  mailto:tho...@fiasko-nw.net  :::
::  flickr: https://www.flickr.com/photos/laugufe/  ::

Bug#949974: Finish hangs after flush

[Enrico Zini]

Package: python3-tornado
Version: 5.1.1-4
Severity: normal

Hello,

thank you for maintaining tornado in Debian.

Here's a simple variation of Tornado's hello example, supposing one
wants to take timing or log things after a flush:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
import tornado.ioloop
import tornado.web


class MainHandler(tornado.web.RequestHandler):
async def get(self):
print("START")
self.write("Hello, world")
await self.flush()
print("DATA WRITTEN")
await self.finish()
print("REQUEST DONE")


def make_app():
return tornado.web.Application([
(r"/", MainHandler),
])


if __name__ == "__main__":
app = make_app()
app.listen()
tornado.ioloop.IOLoop.current().start()
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Running this code, curl localhost:, and the output on tornado is:

  START
  DATA WRITTEN

That is, finish() seems to hang forever if it has no more data to write.


Enrico


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

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

Versions of packages python3-tornado depends on:
ii  ca-certificates  20190110
ii  libc62.28-10
ii  python3  3.7.3-1

python3-tornado recommends no packages.

Versions of packages python3-tornado suggests:
ii  python-tornado-doc  5.1.1-4
ii  python3-pycurl  7.43.0.2-0.1
ii  python3-twisted 18.9.0-3

-- no debconf information

Bug#949973: Acknowledgement (firmware-realtek: kernel error caught)

[Piotr]

lspci -k:

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
Subsystem: Hewlett-Packard Company RTL8111/8168/8411 PCI Express Gigabit
Ethernet Controller
Kernel driver in use: r8169
Kernel modules: r8169

Bug#949973: firmware-realtek: kernel error caught

[pioruns]

Package: firmware-realtek
Version: 20190114-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Was plugging and unplugging ethernet cable a lot, as I was configuring and
installing a new device in my network. I used my laptop to configure the
device.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Error has been caught during the process of plugging and unplugging ethernet
cable. Each time debian was trying to get me connected, I had DHCP enabled and
sometimes disabled.
   * What was the outcome of this action?

1. Error has been logged in the dmesg
2. Connecting to ethernet network is very slow on my laptop. I remember it
being so blazingly fast on Windows, and on other Linux distros. But now, with
my current system it takes several seconds to get me connected to DHCP server
and get me online

   * What outcome did you expect instead?

1. There should be no errors in dmesg at all
2. Connecting to my network should be faster

Dmesg:
[625913.001396] IPv6: ADDRCONF(NETDEV_UP): wlo1: link is not ready
[625921.530857] r8169 :01:00.0 enp1s0: Link is Down
[625931.118576] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow
control rx/tx
[625931.129944] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow
control rx/tx
[625957.365238] r8169 :01:00.0 enp1s0: Link is Down
[625970.612771] acpi PNP0501:00: Still not present
[625970.612897] acpi PNP0400:00: Still not present
[625971.769006] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow
control rx/tx
[625971.782279] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow
control rx/tx
[626117.714782] r8169 :01:00.0 enp1s0: Link is Down
[626122.933425] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow
control rx/tx
[626159.771334] r8169 :01:00.0 enp1s0: Link is Down
[626163.503036] r8169 :01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow
control rx/tx
[626187.779178] [ cut here ]
[626187.779189] NETDEV WATCHDOG: enp1s0 (r8169): transmit queue 0 timed out
[626187.779245] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:461
dev_watchdog+0x20d/0x220
[626187.779251] Modules linked in: usblp msr uinput fuse ctr ccm binfmt_misc
uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common
videodev media radeon arc4 rt2800pci rt2800mmio rt2800lib rt2x00pci
edac_mce_amd rt2x00mmio kvm_amd rt2x00lib ccp rng_core mac80211 kvm ttm
snd_hda_codec_idt snd_hda_codec_generic hp_wmi drm_kms_helper sparse_keymap
wmi_bmof irqbypass snd_hda_codec_hdmi crct10dif_pclmul cfg80211 snd_hda_intel
crc32_pclmul snd_hda_codec snd_hda_core drm snd_hwdep ghash_clmulni_intel
snd_pcm sg evdev joydev serio_raw pcspkr eeprom_93cx6 snd_timer crc_ccitt
k10temp sp5100_tco rfkill snd jmb38x_ms soundcore memstick i2c_algo_bit wmi
hp_accel battery lis3lv02d input_polldev pcc_cpufreq hp_wireless video ac
acpi_cpufreq button ip_tables x_tables autofs4 ext4 crc16 mbcache
[626187.779348]  jbd2 fscrypto ecb hid_generic usbhid hid btrfs xor
zstd_decompress zstd_compress xxhash uas usb_storage raid6_pq libcrc32c
crc32c_generic sr_mod cdrom sd_mod crc32c_intel ohci_pci xhci_pci r8169
xhci_hcd ahci aesni_intel libahci ohci_hcd libata ehci_pci ehci_hcd aes_x86_64
crypto_simd cryptd glue_helper psmouse realtek i2c_piix4 scsi_mod usbcore
libphy sdhci_pci cqhci sdhci mmc_core usb_common thermal
[626187.779408] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.19.0-6-amd64 #1
Debian 4.19.67-2+deb10u2
[626187.779412] Hardware name: Hewlett-Packard HP ProBook 4545s/17EA, BIOS
68CPD Ver. F.61 07/22/2015
[626187.779418] RIP: 0010:dev_watchdog+0x20d/0x220
[626187.779423] Code: 00 49 63 4e e0 eb 92 4c 89 e7 c6 05 b1 ea ad 00 01 e8 57
ba fc ff 89 d9 4c 89 e6 48 c7 c7 70 f0 2d 82 48 89 c2 e8 9d 0e a6 ff <0f> 0b eb
c0 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44
[626187.779427] RSP: 0018:919ef7283e90 EFLAGS: 00010286
[626187.779431] RAX:  RBX:  RCX:
0006
[626187.779433] RDX: 0007 RSI: 0092 RDI:
919ef72966b0
[626187.779436] RBP: 919ef5eb845c R08: 254a R09:
0007
[626187.779438] R10:  R11: 829f26ee R12:
919ef5eb8000
[626187.779441] R13: 0001 R14: 919ef5eb8480 R15:
0001
[626187.779444] FS:  () GS:919ef728()
knlGS:
[626187.779447] CS:  0010 DS:  ES:  CR0: 80050033
[626187.779449] CR2: 7f0f51e2b140 CR3: 0001f3b8e000 CR4:
000406e0
[626187.779452] Call Trace:
[626187.779457]  
[626187.779464]  ? pfifo_fast_enqueue+0x110/0x110
[626187.779469]  call_timer_fn+0x2b/0x130
[626187.779474]  run_timer_softirq+0x3d1/0x410
[626187.779479]  ? __hrtimer_run_queues+0x130/0x280
[626187.779483]  ? ktime_get+0x3a/0xa0
[626187.779489]  __do_softirq+0xde/0x2d8
[626187.779494]  

Bug#948041: impossible to update libbpf without updating the kernel

[Julia Kartseva]

On Sun, 19 Jan 2020 22:32:22 -0800 Andrii Nakryiko
 wrote:
> Libbpf releases are only loosely synchronized with kernel releases,
> and it's only due to current convention we established within
> community. There is nothing preventing multiple releases of libbpf
> between two releases of kernel. So having Linux distributions use
> Github's release tags ensures that all of them are building from
> exactly the same source code version.
> 
> > "No ties to any specific kernel, transparent handling of older kernels."
> >
> > What?  Either they are upstream for it or patch the source.  But this
> > point means it can't be a direct mirror.  So what is it?
> 
> It is mostly a direct mirror, with some extra Github-specific stuff
> beside (like Travis CI testing, etc). All the libbpf source code fixes
> do go through bpf-next tree, though.
> 
> But the point here was that libbpf itself is not built with any
> particular kernel version in mind. It is by design possible to use the
> very latest libbpf against a pretty old kernel version and this will
> work: libbpf will degrade some of the features (e.g, BTF type info
> associations), but everything will keep working otherwise (unless user
> requests feature that requires latest kernel version, of course: in
> that case BPF program will fail to load and libbpf will return
> corresponding error code).

+1

Having libbpf packaged from GH would spare Linux user space developers from
headache of supporting different versioning across distributions, e.g. in
Fedora and Debian.
Libbpf releases are independent from kernel releases and mapping from
kernel to libbpf versions will confuse and complicate developers.
Libbpf from GH should be a common denominator across distributions, so
Debian doesn't create a corner case.

Bug#910917: RFA: apache2 -- Apache HTTP Server

[Xavier]

Control: retitle -1 RFH: apache2 - Apache HTTP Server

Hi,

I'm going to transform it to RFH because I've limited talents in C language.

Cheers,
Xavier

Le 27 janvier 2020 19:06:43 GMT+01:00, Sudip Mukherjee 
 a écrit :
>Hi,
>
>On Wed, Nov 28, 2018 at 09:47:34AM +0100, Xavier wrote:
>> Job started. Could you update my role in salsa ? "developer" role
>> doesn't allow me to use GitLab API: I'd like to configure project to
>add
>> "tagpending" webhook.
>
>It seems Xavier has taken up the package since Version: 2.4.38-1. Do
>you
>want me to close this bug now or are you still looking for people to
>adopt apache2 ?
>
>
>--
>Regards
>Sudip

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

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

[Rebecca N. Palmer]

Control: retitle -1 clblas: *gemm wrong answers in out-of-order queues
Control: reassign -1 src:clblas
Control: found -1 2.12-1

I think I've found the actual bug, in clblas src/library/blas/xgemm.cc: 
clblasGemm (with a single command queue) enqueues up to 4 kernels and 
returns an event that depends on only the last of them, so if the queue 
is out-of-order, waiting on this event doesn't necessarily wait for all 
of them to finish.


This was previously noticed in 
https://github.com/clMathLibraries/clBLAS/issues/269#issuecomment-225453543 
, but not actually reported as a bug.


clblas includes a client/performance tester that creates an out-of-order 
queue (at src/client/clfunc_common.hpp:306), implying that it intends to 
allow such queues.  (We don't run clblas' own tests, possibly because of 
https://github.com/clMathLibraries/clBLAS/issues/338.)


The real fix would be to return an event that depends on all the 
kernels' events (e.g. created with clEnqueueMarkerWithWaitList).


As a workaround for now, I intend to disable out-of-order queues in 
libgpuarray.  (It appears to be the only reverse dependency of clblas 
that also uses out-of-order queues.)

Bug#946972: Acknowledgement (sawfish: Sometimes does not notice changes in xinerama / multihead configuration)

[Paul "LeoNerd" Evans]

There not being any activity here for a while, I have reported it
upstream at

  https://github.com/SawfishWM/sawfish/issues/41

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk  |  https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/  |  https://www.tindie.com/stores/leonerd/

Bug#946349: backintime-qt: Backup initiated from the GUI overwrites remote backup path permissions to 0700

[S. G.]

I just added a comment to upstream issue 974 [1] pointing to this bug
here.

[1] https://github.com/bit-team/backintime/issues/974

Bug#949972: ftbfs, fix build dependencies

[Matthias Klose]

Package: src:python-alignlib
Version: 0.1.1+dfsg-1
Severity: serious
Tags: sid bullseye patch

fix build dependencies, python3-all-dev is the only correct b-d.

patch at
http://launchpadlibrarian.net/462376359/python-alignlib_0.1.1+dfsg-1build1_0.1.1+dfsg-1ubuntu1.diff.gz

Bug#947847: [Fwd: Re: Bug#947847: please install systemd-sysusers using update-alternatives]

[Svante Signell]

--- Begin Message ---
On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote:
> 
> Strikes me as there is a possible solution, though: have opensysusers 
> dpkg-divert it and put a shell script in its place that checks which 
> init system is running, and exec's the right sysusers based on that.

It is as simple as:
if ps -p1|grep -q "systemd"; then
 
else
 
fi

> This wouldn't affect systemd-only machines (as opensysusers would not be 
> installed at all), and would do the right thing if someone has installed 
> two init systems to, e.g., consider switching. It'd need to be a script 
> that the systemd maintainers feel reasonably confident will always run 
> systemd's implementation when systemd is running, to avoid the mixed 
> implementations issue.



--- End Message ---

Bug#949971: ftbfs, missing b-d on dh-python

[Matthias Klose]

Package: src:pycangjie
Version: 1.3-1
Severity: serious
Tags: sid bullseye patch

missing b-d on dh-python,

patch at
http://launchpadlibrarian.net/462375088/pycangjie_1.3-1build1_1.3-1ubuntu1.diff.gz

Bug#949970: b-d's on python3-dev / python3-dbg but hardcodes 3.7

[Matthias Klose]

Package: src:pivy
Version: 0.6.4-2
Severity: serious
Tags: sid bullseye

b-d's on python3-dev / python3-dbg but hardcodes 3.7 in the rules file.  You
should not hard-code a specific Python3 version.

Bug#949969: transmission-gtk uses 100% of a CPU core

[Francois Gouget]

Package: transmission-gtk
Version: 2.94-2
Severity: normal

Dear Maintainer,

When running transmission-gtk with two torrents it uses 100% of a CPU core:

fgouget  24435 98.9  0.2 814620 67712 ?Sl   17:36   2:11 
/usr/bin/transmission-gtk
fgouget  24435 98.9  0.2 814620 67712 ?Sl   17:36   2:12 
/usr/bin/transmission-gtk
fgouget  24435 99.0  0.2 814620 67712 ?Sl   17:36   2:13 
/usr/bin/transmission-gtk

For both torrents the download speed is capped to 100 KB/s and neither
is uploading to anyone.

* Pausing both torrents does not lead to a reduction of the CPU usage.

* After exiting and restarting Transmission with both torrents still
  paused it uses under 1% of CPU. But restarting either torrent causes
  transmission-gtk to slowly go back up to 100% CPU usage again.

* Removing the download speed limit makes no difference.

* Keeping just one torrent does not help either.

* Then I suspended the torrent, restarted transmission-gtk, told it to
  verify the local data, waited until that was done, and then restarted
  the torrent with a 100 KB/s download limit and CPU usage still rose to
  83% (not 100% this time).

* Running transmission-cli on the torrent saved by transmission-gtk
  results in it using 100% CPU too. So the bug may be in the
  transmission-common package.

* Here's the one torrent I kept (~50GB):
  http://osm.cquest.org/torrents/planet-200120.osm.pbf.torrent


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

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

Versions of packages transmission-gtk depends on:
ii  libayatana-appindicator3-1  0.5.3-4
ii  libc6   2.28-10
ii  libcurl47.64.0-4
ii  libevent-2.1-6  2.1.8-stable-4
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgtk-3-0  3.24.5-1
ii  libminiupnpc17  2.1-1+b1
ii  libnatpmp1  20150609-7
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libssl1.1   1.1.1d-0+deb10u2
ii  transmission-common 2.94-2
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages transmission-gtk recommends:
ii  xdg-utils  1.1.3-1

transmission-gtk suggests no packages.

-- no debconf information

Bug#949968: fix build dependencies

[Matthias Klose]

Package: src:python-noise
Version: 0.3.0-2
Severity: serious
Tags: sid bullseye patch

fix build dependencies, python3-all-dev is the only correct b-d.

patch at
http://launchpadlibrarian.net/462373949/python-noise_1.2.3-2build1_1.2.3-2ubuntu1.diff.gz

Bug#949967: fix build dependencies

[Matthias Klose]

Package: src:python-py2bit
Version: 0.3.0-2
Severity: serious
Tags: sid bullseye patch

fix build dependencies, python3-all-dev is the only correct b-d.

patch at
http://launchpadlibrarian.net/462373681/python-py2bit_0.3.0-2build1_0.3.0-2ubuntu1.diff.gz

Bug#948745: ksh2020 vs. ksh93

[Thorsten Glaser]

On Fri, 24 Jan 2020, Anuradha Weeraman wrote:

> If you could team upload  as well that would be great!

Done!

I had to change some things in src:ksh as well, for better
coïnstallability, and for upgrading. Let’s hope this passes
all tests and ftpmasters…

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#949966: libgclib-dev: getLine ABI uses off_t and thus depends on _FILE_OFFSET_BITS

[Helmut Grohne]

Package: libgclib-dev
Version: 0.11.3-1
Severity: important
Tags: ftbfs
Control: affects -1 + src:gffread

gffread fails to build from source for 32bit architectures with the
following linker error:

| /usr/bin/ld: gffread.o: in function `GLineReader::getLine(_IO_FILE*)':
| /usr/include/gclib/GBase.h:576: undefined reference to 
`GLineReader::getLine(_IO_FILE*, long long&)'

The second argument of getLine is actually typed off_t&. libgclib is
built without _FILE_OFFSET_BITS, so off_t becomes long. gffread is built
with _FILE_OFFSET_BITS=64, so off_t becomes long long there. In C++,
these become different overloads and so we get the linker error.

Fundamentally, I think using off_t in an ABI is difficult. If you do so,
you must provide both variants. gclib fails to do so.

As a workaround on the gffread side, unsetting the lfs feature should
make it build:

export DEB_BUILD_MAINT_OPTIONS=future=-lfs

Of course, gffread comes without large file support then. Possibly,
rebuilding libgclib with _FILE_OFFSET_BITS=64 would be a good solution.
Beware that doing so is an ABI break and requires an soname bump though.

Helmut

Bug#949945: gcc-snapshot: some executables have debug info, making the package 3 times as big as previously

[Matthias Klose]

On 1/27/20 12:56 PM, Vincent Lefevre wrote:
> Package: gcc-snapshot
> Version: 1:20200124-1
> Severity: normal
> 
> One has:
> 
> -rw-r--r-- 1 198M 2019-11-30 15:28:32 gcc-snapshot_1%3a20191130-1_amd64.deb
> -rw-r--r-- 1 567M 2020-01-24 23:43:53 gcc-snapshot_1%3a20200124-1_amd64.deb
> 
> and
> 
> Package: gcc-snapshot
> Version: 1:20191130-1
> Installed-Size: 1066234
> 
> Package: gcc-snapshot
> Version: 1:20200124-1
> Installed-Size: 3067842
> 
> So both the .deb size and the install size have almost tripled!
> 
> According to a diff, this is apparently due to some executables from
> /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/10, which now have
> debug info and are no longer stripped, making them 10 times as big.
> 
> With gcc-snapshot 1:20191130-1, I get:
> 
> -rwxr-xr-x 1 30M 2019-11-30 08:57:40 cc1*
> -rwxr-xr-x 1 31M 2019-11-30 08:57:40 cc1obj*
> -rwxr-xr-x 1 33M 2019-11-30 08:57:40 cc1plus*
> -rwxr-xr-x 1 31M 2019-11-30 08:57:40 f951*
> -rwxr-xr-x 1 31M 2019-11-30 08:57:40 go1*
> -rwxr-xr-x 1 29M 2019-11-30 08:57:40 lto1*
> 
> cc1: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically 
> linked, interpreter /lib64/ld-linux-x86-64.so.2, 
> BuildID[sha1]=48082c3df2f3c926a3c027af59e2906f7c24225f, for GNU/Linux 3.2.0, 
> stripped
> 
> With gcc-snapshot 1:20200124-1, I get:
> 
> -rwxr-xr-x 1 311M 2020-01-24 12:01:06 cc1*
> -rwxr-xr-x 1 315M 2020-01-24 12:01:06 cc1obj*
> -rwxr-xr-x 1 342M 2020-01-24 12:01:06 cc1plus*
> -rwxr-xr-x 1 310M 2020-01-24 12:01:06 f951*
> -rwxr-xr-x 1 335M 2020-01-24 12:01:06 go1*
> -rwxr-xr-x 1 297M 2020-01-24 12:01:06 lto1*
> 
> cc1: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically 
> linked, interpreter /lib64/ld-linux-x86-64.so.2, 
> BuildID[sha1]=27e3f615a396668fe72d9e30bbaaf055ccf5660f, for GNU/Linux 3.2.0, 
> with debug_info, not stripped
> 
> Since the Debian changelog just says
> 
> gcc-snapshot (1:20200124-1) unstable; urgency=medium
> 
>   * Snapshot, taken from the trunk (20200124).
> 
>  -- Matthias Klose   Fri, 24 Jan 2020 12:01:06 +0100
> 
> I suppose that this change can be a mistake.

no, leading to the GCC 10 release, I didn't strip the executables to get
meaningful backtraces.  Will revert in a month or two.

Bug#949965: Add support for jigdo v2 format

[Steve McIntyre]

Package: debian-cd
Version: 3.1.25
Severity: normal

Jigdo and jigit already have support for the new sha256-based
format. Add support in debian-cd for using it too.

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

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

Versions of packages debian-cd depends on:
ii  apt1.8.2
ii  bc 1.07.1-2+b1
ii  bzip2  1.0.6-9.2~deb10u1
ii  cpp4:8.3.0-1
ii  curl   7.64.0-4
ii  dctrl-tools [grep-dctrl]   2.24-3
ii  dpkg-dev   1.19.7
ii  genisoimage9:1.1.11-3+b2
pn  libcompress-zlib-perl  
pn  libdigest-md5-perl 
ii  libdpkg-perl   1.19.7
ii  lynx   2.8.9rel.1-3
ii  make   4.2.1-1.2
ii  perl [libdigest-sha-perl]  5.28.1-6
ii  tofrodos   1.7.13+ds-4
ii  wget   1.20.1-1.1
ii  xorriso1.5.0-1

Versions of packages debian-cd recommends:
ii  dosfstools   4.1-2
ii  hfsutils 3.2.6-14
ii  isolinux 3:6.04~git20190206.bf6db5b4+dfsg1-1
ii  mtools   4.0.23-1
ii  netpbm   2:10.0-15.3+b2
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-1
ii  syslinux-utils   3:6.04~git20190206.bf6db5b4+dfsg1-1

debian-cd suggests no packages.

-- no debconf information

Bug#906271: Feature freeze?

[Arnaud Loonstra]

On Mon, 11 Feb 2019 09:01:18 +0100 Arnaud Loonstra  
wrote:
The feature freeze is close. With this bug SOGo provided by the Debian 
repos is in my opinion not usable, at least on ARM.


Is there anything we can do to give this some attention?

Rg,

Arnaud




The bug is fixed, at least in 4.0.7-1+deb10u1

I think this can be closed

Bug#949960: Qt5::Gui: CMake does not find libEGL.so

[Lisandro Damián Nicanor Pérez Meyer]

tag -1 moreinfo
thanks

Hi!


El lun., 27 ene. 2020 14:00, Joachim Wuttke 
escribió:

> Package: libqt5gui5
> Version: 5.12.5+dfsg-2
>
> CMake fails with the following message:
>
> CMake Error at
> /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfig.cmake:27 (message):
>The imported target "Qt5::Gui" references the file
>   "/usr/lib/x86_64-linux-gnu/libEGL.so"
>but this file does not exist.  Possible reasons include:
>* The file was deleted, renamed, or moved to another location.
>* An install or uninstall procedure did not complete successfully.
>* The installation package was faulty and contained
>   "/usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake"
>but not all the files it references.
> Call Stack (most recent call first):
>/usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:63
> (_qt5_Gui_check_file_exists)
>/usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfigExtras.cmake:85
> (_qt5gui_find_extra_libs)
>/usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfig.cmake:186 (include)
>/usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake:28 (find_package)
>CMakeLists.txt:50 (find_package)
> -- Configuring incomplete, errors occurred!
>
> Bug occured in docker image debian:testing, amd64.
> A few days before, everything still worked.
>


This should be fixed in unstable already. It was going to migrate to
testing but I've mistakenly uploaded a new version to unstable, so it will
take a little more.

The fix is depending on another -dev package.

Cheers, Lisandro.

>