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

[hema]

On Wed, 07 Nov 2018 20:25:11 +0100 Stefan Fritsch  wrote:
> Hi Mosab,
>
> sorry for the late response. I forgot to subscribe to the wnpp report and
did
> not get your mail.
>
> On Thursday, 18 October 2018 10:47:34 CET Mosab Ibrahim wrote:
> > I don't have experience with packaging, but I do have experience with
using
> > Apache HTTP Server, and I am a quick learner.
> >
> > Would like to be part of the maintaining team for this package.
>
> The apache2 package is not the ideal package for beginers, but we will
see. It
> may still work out well, especially if there are other volunteers that
have
> more experience in packaging.
>
> I suggest that you start by looking at some bug reports and try to debug
/
> respond / produce patches. There are probably also some bugs that can be
> closed because they concern debian versions that are no longer supported,
or
> the submitter did not reply to some questions.  For a start, if you
produce a
> patch for a bug, simply send it to the bug or to me. If that works out, I
will
> give you commit access to the package repository [1] later on.
>
> You should probably also read at least parts of the new maintainer guide
[2].
>
> I also hang around on the IRC channel #apache on oftc [3], but response
times
> may not be fast.
>
> Cheers,
> Stefan
>
> [1] https://salsa.debian.org/apache-team/apache2
> [2] https://www.debian.org/doc/manuals/maint-guide/index.en.html
> [3] https://www.oftc.net/
>
>
> >
> > Cheers,
> > Mosab.
> > On Sat, 13 Oct 2018 13:29:51 +0200 Stefan Fritsch 
> >
> > wrote:
> > > Package: wnpp
> > > Severity: normal
> > >
> > > I am looking for new maintainers for the Apache httpd server (the
> > > apache2 package).
> > >
> > > The apache2 package has a relatively complex packaging and config
> >
> > file
> >
> > > handling. There are also a lot of third-party module packages in
> >
> > Debian.
> >
> > > Therefore, some experience with using Apache httpd and with Debian
> > > packaging is highly recommended.
> > >
> > >
> > > After more than 11 years of maintaining apache2, my interests have

Bug#944998: Update to sane-backends-1.0.28 for Canon Pixma TS8260 suport

[Daniel Drake]

Package: libsane
Version: 1.0.27-3.2

Hi,

The Endless OS user at
https://community.endlessos.com/t/brother-bought-a-printer-scanner/10726/6
reports that his new Canon Pixma TS8260 is unable to scan.
(Endless OS is based on Debian and uses Debian's sane-backends package
with no modifications)

Louis Lagendijk from the SANE project has looked into it and states
that version 1.0.28 adds support for this new model. Version 1.0.28
was released on 2019-07-31. Please update it in Debian when you have a
chance.

Thanks!

Bug#944968: popularity-contest: Program accesses internal dpkg database

[Niels Thykier]

On Sun, 17 Nov 2019 22:59:58 +0100 Bill Allombert 
wrote:
> On Sun, Nov 17, 2019 at 10:44:02PM +0100, Guillem Jover wrote:
> > Source: popularity-contest
> > Source-Version: 1.69
> > Severity: important
> > User: debian-d...@lists.debian.org
> > Usertags: dpkg-db-access-blocker
> > 
> > Hi!
> > 
> > This package contains the «popularity-contest» program, which directly
> > accesses the dpkg internal database, instead of using one of the public
> > interfaces provided by dpkg.
> > 
> > The program should stop reading the files list files, and switched to
> > use something like:
> > 
> >   «dpkg-query \
> > --showformat 'Package: ${Package}\nFiles:\n${db-fsys:Files}\n' \
> > --show»
> > 
> > to get them.
> 
> Hello Guillem,
> 
> the last time this comes up the performance of using dpkg-query was poor. 
> Was it improved ? What is the first release to support this syntax ?
> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 
> 
> 

Hi,

I tested Guillem's command on my own system and got:

 ~11.5s (cold cache/first time)
 ~0.3 (warm cache/2nd+3rd time)

For reference, "dpkg -l | wc -l" says I have roughly 1500 packages
installed.

I do not know what the original numbers were, so I cannot put the
following numbers into that context.

Thanks,
~Niels

Bug#942235: Adding Python 3.8 as a supported Python3 version

[Matthias Klose]

On 18.11.19 07:52, Alastair McKinstry wrote:
> So I've uploaded a python-xarray 0.14.0-2 which passes on python3.7.
> 
> Its failing on python 3.8 but apparently due to pandas not ready on 3.8, so it
> should be ok to pass as the transition completes.
> 
> xarray really needs dask >= 2.0 but version 1 is in unstable; I've disabled 
> some
> functionality (dask='parallelize') and marked some tests xfail until this is 
> done.
> 
> Alastair

yes, people are aware of a needed dask update, see #942235. There's now also a
dask 2.8 release available, I didn't look at that yet.

> On 07/11/2019 14:08, Matthias Klose wrote:
>> This weekend, I am planning to upload python3-defaults, adding python3.8 as a
>> supported Python3 version.  This may introduce some churn in unstable until
>> the basic binNMUs are available as well.
>>
>>
>>  - python-xarray #944044. 1.4 is already broken with Python 3.7. For
>>    Ubuntu I fell back to 1.2.1. 1.2.3 might work as well, still seeing
>>    one or two test failures.
>>
>> Packages building on top of numpy/scipy/pandas, like the PyAstro stack,
>> continue to work with these updates, despite some new test failures.
>>
>> Matthias
>>
>> [1] https://wiki.debian.org/Python/Python3.8.
>> [2]
>> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.8;users=debian-pyt...@lists.debian.org
>>
>>

Bug#944249: gnuplot-mode does not work with emacs26

[Dima Kogan]

Thanks for the patches, Agustin. I just tried it out. Works for the most
part. One thing that doesn't work for me is (gnuplot-mode) being
executed when opening a .gp file. You added this to the package, and the
dh-elpa machinery is creating the appropriate file:

  /etc/emacs/site-start.d/50elpa-gnuplot-mode.el

I don't think this is being evaluated, however. Is it working for you?
Do you know at which point in the emacs startup sequence this is
sourced? Is it always supposed to be sourced? What about 'emacs -q'? Or
'emacs -Q'?

Thanks

Bug#941713: buster-pu: package ntpsec/1.1.3+dfsg1-2+deb10u1

[Richard Laager]

In the time since I created the original .debdiff, I have moved the
ntpsec packaging from GitHub to Salsa and switched to DEP-14 branch naming.

Attached is a refreshed .debdiff.2 and an .interdiff comparing that to
the first .debdiff. The only changes are the Vcs-* and debian/gbp.conf
changes related to the above.

I'll proceed with the upload.

-- 
Richard
diff -Nru ntpsec-1.1.3+dfsg1/debian/changelog 
ntpsec-1.1.3+dfsg1/debian/changelog
--- ntpsec-1.1.3+dfsg1/debian/changelog 2019-02-04 01:38:48.0 -0600
+++ ntpsec-1.1.3+dfsg1/debian/changelog 2019-11-18 00:04:00.0 -0600
@@ -1,3 +1,15 @@
+ntpsec (1.1.3+dfsg1-2+deb10u1) buster; urgency=medium
+
+  * Backport fix for slow DNS retries (Closes: 924192)
+  * ntpdate.8: Remove duplicated -o option
+  * ntpdate.8: Remove -p option (Closes: 926877)
+  * ntpdate.8: Remove -e option
+  * ntpdate.8: Remove inaccurate BUGS section
+  * Update ntpdate-debian.8 to match ntpdate.8
+  * Fix ntpdate -s (syslog) to fix the if-up hook (Closes: 931414)
+
+ -- Richard Laager   Mon, 18 Nov 2019 00:04:00 -0600
+
 ntpsec (1.1.3+dfsg1-2) unstable; urgency=medium
 
   * Suppress lintian warning
diff -Nru ntpsec-1.1.3+dfsg1/debian/control ntpsec-1.1.3+dfsg1/debian/control
--- ntpsec-1.1.3+dfsg1/debian/control   2019-02-04 01:38:48.0 -0600
+++ ntpsec-1.1.3+dfsg1/debian/control   2019-11-17 23:48:21.0 -0600
@@ -22,8 +22,8 @@
  libwww-ssl-dev
 Standards-Version: 4.3.0
 Rules-Requires-Root: no
-Vcs-Browser: https://github.com/rlaager/ntpsec-pkg
-Vcs-Git: https://github.com/rlaager/ntpsec-pkg.git
+Vcs-Browser: https://salsa.debian.org/debian/ntpsec
+Vcs-Git: https://salsa.debian.org/debian/ntpsec.git
 Homepage: https://www.ntpsec.org
 
 Package: ntpsec
diff -Nru ntpsec-1.1.3+dfsg1/debian/gbp.conf ntpsec-1.1.3+dfsg1/debian/gbp.conf
--- ntpsec-1.1.3+dfsg1/debian/gbp.conf  2019-02-04 01:38:48.0 -0600
+++ ntpsec-1.1.3+dfsg1/debian/gbp.conf  2019-11-18 00:04:00.0 -0600
@@ -1,9 +1,12 @@
 [DEFAULT]
-debian-branch = sid
+debian-branch = debian/buster
+pristine-tar = True
+upstream-branch = upstream/latest
 
 [buildpackage]
-sign-tags = True
+dist = buster
 posttag = gbp push
+sign-tags = True
 
 [dch]
 meta = True
diff -Nru ntpsec-1.1.3+dfsg1/debian/man/ntpdate.8 
ntpsec-1.1.3+dfsg1/debian/man/ntpdate.8
--- ntpsec-1.1.3+dfsg1/debian/man/ntpdate.8 2019-02-04 01:38:48.0 
-0600
+++ ntpsec-1.1.3+dfsg1/debian/man/ntpdate.8 2019-11-17 21:36:12.0 
-0600
@@ -3,17 +3,13 @@
 ntpdate \- set the date and time via NTP
 .SH SYNOPSIS
 .B ntpdate
-.RB [\| \-46bBdoqsuv \|]
+.RB [\| \-46bBdqsuv \|]
 .RB [\| \-a
 .IR key \|]
-.RB [\| \-e
-.IR authdelay \|]
 .RB [\| \-k
 .IR keyfile \|]
 .RB [\| \-o
 .IR version \|]
-.RB [\| \-p
-.IR samples \|]
 .RB [\| \-t
 .IR timeout \|]
 .I server
@@ -91,13 +87,6 @@
 but not adjust the local clock and using an unprivileged port. Information
 useful for general debugging will also be printed.
 .TP
-.BI \-e \ authdelay
-Specify the processing delay to perform an authentication
-function as the value authdelay, in seconds and fraction (see
-ntpd for details). This number is usually small enough to be
-negligible for most purposes, though specifying a value may
-improve timekeeping on very slow CPU's.
-.TP
 .BI \-k \ keyfile
 Specify the path for the authentication key file as the string
 keyfile. The default is /etc/ntp.keys. This file should be in
@@ -108,11 +97,6 @@
 can be 1, 2, 3 or 4. The default is 4. This allows ntpdate to be used with
 older NTP versions.
 .TP
-.BI \-p \ samples
-Specify the number of samples to be acquired from each server
-as the integer samples, with values from 1 to 8 inclusive. The
-default is 4.
-.TP
 .B \-q
 Query only \(en don't set the clock.
 .TP
@@ -144,12 +128,6 @@
 .TP
 .I /etc/ntp.keys
 \- encryption keys used by ntpdate.
-.SH BUGS
-The slew adjustment is actually 50% larger than the measured offset,
-since this (it is argued) will tend to keep a badly drifting clock
-more accurate. This is probably not a good idea and may cause a
-troubling hunt for some values of the kernel variables tick and
-tickadj.
 .SH AUTHOR
 David L. Mills (mi...@udel.edu)
 .br
diff -Nru ntpsec-1.1.3+dfsg1/debian/man/ntpdate-debian.8 
ntpsec-1.1.3+dfsg1/debian/man/ntpdate-debian.8
--- ntpsec-1.1.3+dfsg1/debian/man/ntpdate-debian.8  2019-02-04 
01:38:48.0 -0600
+++ ntpsec-1.1.3+dfsg1/debian/man/ntpdate-debian.8  2019-11-17 
21:36:12.0 -0600
@@ -3,19 +3,17 @@
 ntpdate-debian \- set the date and time via NTP
 .SH SYNOPSIS
 .B ntpdate-debian
-.RB [\| \-bBdoqsuv \|] 
-.RB [\| \-a 
-.IR key \|] 
-.RB [\| \-e 
-.IR authdelay \|] 
-.RB [\| \-k 
+.RB [\| \-46bBdqsuv \|]
+.RB [\| \-a
+.IR key \|]
+.RB [\| \-k
 .IR keyfile \|]
 .RB [\| \-o
 .IR version \|]
-.RB [\| \-p
-.IR samples \|]
 .RB [\| \-t
 .IR timeout \|]
+.I server
+.RB [\| ... \|]
 .SH DESCRIPTION
 .B ntpdate-debian
 is identical to
@@ -24,5 +22,7 @@
 .I /etc/default/ntpsec-ntpdate
 by default.
 .B ntpd

Bug#944949: dbus-python: needs an explicit build dependency on dh-python

[Matthias Klose]

On 17.11.19 20:53, Simon McVittie wrote:
> Control: tags 944949 + moreinfo
> 
> On Sun, 17 Nov 2019 at 19:07:39 +, Matthias Klose wrote:
>> Please add an explicit build dependency on dh-python.
> 
> As far as I can see it's been explicit since 2015. Is anything more
> needed here?
> 
> Note that the FTBFS with
> 
> dh_python2
> make[1]: dh_python2: Command not found
> 
> seems to be because /usr/bin/dh_python2 is a #!/usr/bin/python script in
> a package that doesn't depend on python (#944894). The misleading
> "Command not found" is similar to this:
> 
> $ cat > Makefile
> all:
>   ./script
> $ cat > script
> #!/usr/bin/does-not-exist
> $ chmod +x script
> $ make
> ./script
> make: ./script: Command not found
> make: *** [Makefile:2: all] Error 127
> 
> I have a workaround which I believe should still be harmless after
> dh_python2 moves out of python2 (presumably into dh-python?), which I'll
> upload soon.
> 
> If that doesn't work, I'll temporarily re-add the python B-D so the
> python3.8 transition can go through, and remove it after #944894 is
> resolved.
> 
> It's unfortunate that the python3.8 transition, the effort to replace
> references to python2 with python, and the migration of dh_python2 from
> python2 to dh-python (?) are happening at the same time and affect
> overlapping sets of packages. Perhaps one (or more) of these could be
> deferred until one of the others has been done?

this specific issue is unrelated. dh_python2.py was calling python, not python2.
now fixed in an interim upload.

Still waiting for feedback from my co-maintainer how to proceed with the dropped
dh-python dependency in python3-defaults.

Bug#934665: upload grpc and protobuf to unstable

[Pirate Praveen]

On തി, Nov 18, 2019 at 10:31, Pirate Praveen 
 wrote:
opencv built fine without ccache in chroot. So only ola and 
ignition-transport are the relvant failures now.


missed anbox from the second list sent by Nilesh. Now confirmed anbox 
also fails.

Bug#944997: ITP: ruby-net-ntp -- NTP client for ruby

[Pirate Praveen]

Package: wnpp
severity: wishlist
Owner: Pirate Praveen 

 
 this is a dependency of 
gitlab 12.3+

Bug#944995: gtkimageview FTBFS: error: ‘GTypeDebugFlags’ is deprecated

[Helmut Grohne]

Source: gtkimageview
Version: 1.6.4+dfsg-2
Severity: serious
Tags: ftbfs

gtkimageview fails to cross build from source in unstable. The crucial
bit is:

| /usr/include/gtk-2.0/gtk/gtktypeutils.h:236:1: error: ‘GTypeDebugFlags’ is 
deprecated [-Werror=deprecated-declarations]
|   236 | voidgtk_type_init   (GTypeDebugFlagsdebug_flags);
|   | ^~~~

This is a problem, because gtkimageview builds with -Werror.

Reproducible by reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/gtkimageview_1.6.4+dfsg-2.rbuild.log.gz
Reproducible by crossqa:
http://crossqa.debian.net/build/gtkimageview_1.6.4+dfsg-2_ppc64el_20191014234854.log

As a first measure, dropping -Werror will likely make it build again,
then you likely need to fix #618962 and drop the gtk2 variant.

Helmut

Bug#944974: gdal-bin: gdal2tiles.py option --webviewer=leaflet does nothing.

[Sebastiaan Couwenberg]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/OSGeo/gdal/issues/2030

Hi Witold,

This is not something to be fixed by the package maintainer, so I've
forwarded it upstream. You should follow up there.

Note the following from their issue template:

"
 The GDAL project is made of contributions from various individuals and
 organizations, each with their own focus. The issue you are facing is
 not necessarily in the priority list of those contributors and
 consequently there is no guarantee that it will be addressed in a
 timely manner.
 If this bug report or feature request is high-priority for you,
 we suggest engaging a GDAL developer or support organisation and
 financially sponsoring a fix.
"

Kind Regards,

Bas

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

Bug#934665: upload grpc and protobuf to unstable

[Pirate Praveen]

On തി, Nov 18, 2019 at 01:16, Pirate Praveen 
 wrote:
nageru was a real failure but its maintainer fixed it as soon as I 
filed the bug. opencv seems to be fine (still building).


opencv built fine without ccache in chroot. So only ola and 
ignition-transport are the relvant failures now.

Bug#944617: python3-h5py import performance severely degraded in 2.10.0 release (due to OpenMPI?)

[Drew Parsons]

Source: h5py
Followup-For: Bug #944617

There is additional overhead in h5py 2.10 compared to 2.8.

Comparing 2.10 with and without mpi support shows the load-up
difference with mpi to be slower by a factor of only 2-3 rather
than ×7.


h5py 2.10.0 with mpi support:

$ multitime -qq -n 10 python3 -c 'import h5py'
===> multitime results
1: -qq python3 -c "import h5py"
MeanStd.Dev.Min Median  Max
real0.696   0.123   0.637   0.659   1.065
user0.608   0.052   0.480   0.617   0.665   
sys 0.313   0.049   0.196   0.315   0.394   



h5py 2.10.0 without mpi support:

$ multitime -qq -n 10 python3 -c 'import h5py'
===> multitime results
1: -qq python3 -c "import h5py"
MeanStd.Dev.Min Median  Max
real0.293   0.048   0.260   0.270   0.414   
user0.549   0.036   0.479   0.552   0.605   
sys 0.269   0.022   0.228   0.264   0.301   




But note that this test only measures the time for loading the h5py
module itself, so it does not provide a good measure of performance
with mpi support available. It's not fair to characterise it as ×2.5
slower, since this is a once-off cost in CPU time.  i.e. the relevant
quantity here is the additional 0.4 sec of time to load the module.
It's a bit of a stretch to say that 0.4 sec is a severe performance
penalty, I think.


To measure performance, you would need to measure the time taken to
work with the actual data files, e.g. to load a large data file (say
4-8 GB data).  It would be interesting if you could run this kind of
performance test.

Bug#944994: trustedqsl: new upstream release 2.5.1 available

[tony mancill]

Source: trustedqsl
Severity: wishlist

Upstream has released a new version of TrustedQSL, which I am in the
process of updating.  This bug is merely for coordination/progress
tracking and to prevent duplication of effort.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure

[Drew Parsons]

Source: h5py
Followup-For: Bug #944769

Thanks for your analysis, Thibaut.  Testing OMPI_COMM_WORLD_SIZE and
MPI_LOCALNRANKS is a decent idea.  Fair enough that non-MPI users
shouldn't have to worry about MPI settings (the MPI capability should
be transparent if not explicitly invoked).

Drew

Bug#944993: gnome-shell-extension-show-ip: primary-interface patch broke loading the extension

[Paul Wise]

Package: gnome-shell-extension-show-ip
Version: 8-4
Severity: serious
Tags: patch

The primary-interface patch I proposed had a serious issue:

JS ERROR: Extension show...@sgaraud.github.com: ReferenceError: device is not 
defined

I've fixed the issue upstream and in the attached patch.

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

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

Versions of packages gnome-shell-extension-show-ip depends on:
ii  gnome-shell  3.34.1+git20191024-1

gnome-shell-extension-show-ip recommends no packages.

gnome-shell-extension-show-ip suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From 626ff48b7e29cf4178a2f439b85340e7b1e25774 Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Thu, 2 Mar 2017 18:07:14 +0800
Subject: [PATCH] Show the primary IP address when no interface was chosen

Makes it easier to see all IP addresses at a glance.

Uses NM to get which interface(s) are in the default route.
---
 README.md|  1 +
 extension.js | 53 +---
 2 files changed, 43 insertions(+), 11 deletions(-)

diff --git a/README.md b/README.md
index 0fafb7a..eec47e3 100644
--- a/README.md
+++ b/README.md
@@ -83,6 +83,7 @@ issues](https://github.com/sgaraud/gnome-extension-show-ip/issues).
 ### License
 
 Copyright (C) 2015 Sylvain Garaud
+Copyright 2017 Paul Wise
 
 This program is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
diff --git a/extension.js b/extension.js
index d9a7940..5dc7d9a 100644
--- a/extension.js
+++ b/extension.js
@@ -3,6 +3,7 @@
  * https://github.com/sgaraud/gnome-extension-show-ip
  * 
  * Copyright (C) 2015 Sylvain Garaud
+ * Copyright 2017 Paul Wise
  *
  * This file is part of Show-IP GNOME extension.
  * Show IP GNOME extension is free software: you can redistribute it and/or modify
@@ -170,17 +171,30 @@ const IpMenuBase = new Lang.Class({
 }
 });
 
+this._getPrimaryDevices(this.client);
+let selectedIp = '';
+let primaryIp = '';
+let firstIp = '';
 for (let device of this._devices) {
-if (device.ifc == this.selectedDevice) {
-if (Schema.get_boolean("menu")) {
-this.label.set_text(_("IP: %s").format(device.ip));
-} else {
-this.label.set_text(device.ip);
-}
-break;
+if (!selectedIp && device.ifc == this.selectedDevice) {
+selectedIp = device.ip;
+}
+if (!primaryIp && device.primary) {
+primaryIp = device.ip;
+}
+if (!firstIp) {
+firstIp = device.ip;
 }
 }
-if ('' == this.selectedDevice) {
+let ip = selectedIp ? selectedIp : primaryIp ? primaryIp : firstIp;
+if (ip) {
+if (Schema.get_boolean("menu")) {
+this.label.set_text(_("IP: %s").format(ip));
+} else {
+this.label.set_text(ip);
+}
+this.label.set_text(ip);
+} else {
 this.label.set_text(NOT_CONNECTED);
 }
 },
@@ -207,6 +221,26 @@ const IpMenuBase = new Lang.Class({
 this._createPopupMenu();
 },
 
+_getPrimaryDevices: function (nmc) {
+let primary_conn = nmc.get_primary_connection();
+let primary_devices = primary_conn.get_devices();
+let primary_ifcs = [];
+let i = 0;
+if (primary_devices) {
+for (let device of primary_devices) {
+primary_ifcs[i++] = device.get_iface();
+}
+}
+for (let device of this._devices) {
+device.primary = false;
+for (let ifc of primary_ifcs) {
+if (device.ifc == ifc) {
+device.primary = true;
+}
+}
+}
+},
+
 _getNetworkDevices: function (nmc) {
 let _device;
 this.devices = nmc.get_devices();
@@ -290,9 +324,6 @@ const IpMenuBase = new Lang.Class({
 } else {
 device.ip = this._decodeIp4(ipadd);
 }
-if ('' == this.selectedDevice) {
-this.selectedDevice = device.ifc;
-}
 break;
 

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Ahmed El-Mahmoudy]

On Mon, Nov 11, 2019 at 01:50:18PM -0500, Jeremy Bicha wrote:
> Sorry: TabError: inconsistent use of tabs and spaces in indentation
> (HijriCal.py, line 83)
> dpkg: error processing package python3-hijra (--configure):
>  installed python3-hijra package post-installation script subprocess
> returned error exit status 1
> dpkg: dependency problems prevent configuration of hijra-applet:
>  hijra-applet depends on python3-hijra (= 0.4.1-2); however:
>   Package python3-hijra is not configured yet.

Working on it

> Thank you for adding me to the Salsa team as a Developer. I tried
> pushing a minor change to othman's packaging repo, but the repo
> settings are that only Maintainers can push to the master branch.
> Please allow Developers to push there too.

Done.

> I think there is a good chance that the hijra gnome-shell extension
> will work with the gnome-shell version in Testing. If so, please drop
> the upper gnome-shell dependency limit so that the gnome-shell
> extension will be installable.

Unfortunately, I cannot test this currently
-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#944992: provide documentation in HTML format

[Nicholas D Steeves]

Package: elpa-ivy
Version: 0.12.0+dfsg-1
Severity: wishlist
Control: block -1 by 944704

Ivy/Counsel/Swiper's HTML exportation/publication depends on
org-html-themes.  Filing this tracking bug as a reminder.

Bug#944991: new upstream version 0.13.0

[Nicholas D Steeves]

Source: emacs-ivy
Version: 0.12.0+dfsg-1
Severity: normal
Control: block -1 by 944986

Ivy/Counsel/Swiper has wgrep as a new dep, so I'm filing this tracking
bug.

Bug#877755: ITP: moinmoin-mode -- emacs major mode to edit MoinMoin wiki pages

[Nicholas D Steeves]

Control: retitle -1 RFP: moinmoin-mode -- emacs major mode to edit MoinMoin 
wiki pages
Control: noowner -1

On Sun, Apr 22, 2018 at 06:00:40PM -0400, Nicholas D Steeves wrote:
> Current blocker: moinmoin-mode.el does not have a license defined.  I
> have contacted upstream's devel mailling list and am waiting for a reply.

Upstream has still not replied, so I'm unsetting myself as owner and
making this bug an RFP.


signature.asc
Description: PGP signature

Bug#944990: patching llvm-8 for julia 1.3.0 (upcoming)

[Mo Zhou]

Source: llvm-toolchain-8
Version: 1:8.0.1-4
Severity: normal

Hi Sylvestre,

As an notice in advance, I'm going to patch llvm-8 for julia, adding
exactly the following patches

https://github.com/JuliaLang/julia/blob/36c4eb251edfcd57b05d31a6b2b44ac71a36e36d/deps/llvm.mk#L464-L475

I'll prepare the changes in a certain git branch, and ping you to
review them when it's ready.

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Sean Whitton  writes:
> On Sun 17 Nov 2019 at 10:10AM -08, Russ Allbery wrote:

>> +* The term *may* and the adjective *optional* are sometimes used to
>> +  clarify cases where it may otherwise appear that Policy is specifying a
>> +  requirement or recommendation. These words describe decisions that are
>> +  truly optional and at the maintainer's discretion.

> I've done some grepping to verify that this change is consistent.

Oh, thank you.  I checked the other new terms, but didn't check may and
optional.

> So how about adding "In such cases, ..." right before "... these words
> describe decisions ...", to clarify that your new text is not exhaustive
> regarding usage of 'may' and 'optional' in Policy?

I agree, but let's also fix existing incorrect wording.  I reviewed every
instance of may and optional in Policy, and I think this larger diff will
make wording (mostly) consistent.  I've tried not to change the sense of
any of these Policy statements (even though a few are questionable and
should probably be revisited).

Most of the problems fixed here were also inconsistent with the previous
wording and definition of may or optional.  I didn't catch any mentions
that were using may in the wishlist bug sense, and only one instance of
optional used that way.

diff --git a/policy/ch-archive.rst b/policy/ch-archive.rst
index b8ba081..e37ebee 100644
--- a/policy/ch-archive.rst
+++ b/policy/ch-archive.rst
@@ -329,8 +329,8 @@ management tools.
 the user doesn't select anything else. It doesn't include many large
 applications.
 
-No two packages that both have a priority of ``standard`` or higher
-may conflict with each other.
+Two packages that both have a priority of ``standard`` or higher must
+not conflict with each other.
 
 ``optional``
 This is the default priority for the majority of the archive. Unless
diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
index 74a1690..f1e518e 100644
--- a/policy/ch-binary.rst
+++ b/policy/ch-binary.rst
@@ -362,8 +362,8 @@ adding or removing diversions, package maintainer scripts 
must provide
 the ``--package`` flag to ``dpkg-divert`` and must not use ``--local``.
 
 All packages which supply an instance of a common command name (or, in
-general, filename) should generally use ``update-alternatives``, so that
-they may be installed together. If ``update-alternatives`` is not used,
+general, filename) should generally use ``update-alternatives`` so that
+they can be installed together. If ``update-alternatives`` is not used,
 then each package must use ``Conflicts`` to ensure that other packages
 are removed. (In this case, it may be appropriate to specify a conflict
 against earlier versions of something that previously did not use
diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 60edc82..1dd702c 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -72,7 +72,7 @@ Whitespace must not appear inside names (of packages, 
architectures,
 files or anything else) or version numbers, or between the characters of
 multi-character version relationships.
 
-The presence and purpose of a field, and the syntax of its value may
+The presence and purpose of a field, and the syntax of its value, may
 differ between types of control files.
 
 Field names are not case-sensitive, but it is usual to capitalize the
@@ -553,7 +553,7 @@ The three components here are:
 ``epoch``
 This is a single (generally small) unsigned integer. It may be
 omitted, in which case zero is assumed. If it is omitted then the
-``upstream_version`` may not contain any colons.
+``upstream_version`` must not contain any colons.
 
 Epochs can help when the upstream version numbering scheme
 changes, but they must be used with care.  You should not change
@@ -572,19 +572,19 @@ The three components here are:
 respect to the ``upstream_version`` is described below. The
 ``upstream_version`` portion of the version number is mandatory.
 
-The ``upstream_version`` may contain only alphanumerics [#]_ and
+The ``upstream_version`` must contain only alphanumerics [#]_ and
 the characters ``.`` ``+`` ``-`` ``~`` (full stop, plus, hyphen,
 tilde) and should start with a digit. If there is no
 ``debian_revision`` then hyphens are not allowed.
 
 ``debian_revision``
 This part of the version number specifies the version of the Debian
-package based on the upstream version. It may contain only
+package based on the upstream version. It must contain only
 alphanumerics and the characters ``+`` ``.`` ``~`` (plus, full stop,
 tilde) and is compared in the same way as the ``upstream_version`` is.
 
 It is optional; if it isn't present then the ``upstream_version``
-may not contain a hyphen. This format represents the case where a
+must not contain a hyphen. This format represents the case where a
 piece of software was written specifically to be a Debian pa

Bug#944989: ITP: python-fissix -- backport of lib2to3, supporting the latest Python3 grammars, with enhancements

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist

Package name: python-fissix
Version : 19.2b1
Upstream Author : John Reese 
URL : https://github.com/jreese/fissix
License : PSF
Programming Lang: Python
Description : backport of lib2to3, supporting the latest Python3 grammars, 
with enhancements

Fissix is a backport of lib2to3, a CST (concrete syntax tree)
implementation, that supports various features and grammars that are
more up-to-date than the latest upstream CPython version.  It is the
parser that Bowler uses to make safe, large scale code modifications
and smart refactoring.  It supports source written in both Python 2
and 3.

As noted Fissix is a dependency of Bowler, and I am packaging Bowler
because Rope isn't well maintained upstream, because Parso/Jedi do not
yet support refactoring, and because Elpy (the Emacs Python IDE) has
been hoping to move away from Rope for many years now.

I plan to maintain it on the DPMT, I will need a sponsor for the
initial upload, and I would very much appreciate a co-maintainer who
has advanced Python expertise!


Regards,
Nicholas

Bug#944988: libmng need to install pkg-config file

[Keyikedalube Ndang]

Package: libmng-dev
Version: 1.0.10+dfsg-3.1

I'm having building synfig project using CMake on Debian Bullseye. The project 
collaborator mentioned the issue with Debian libmng package not installing 
pkg-config file as the problem.

Here's the quoted link 
https://github.com/synfig/synfig/issues/928#issuecomment-554623877

Regards,
Keyikedalube Ndang

Bug#944704: ITP: org-html-themes -- export Emacs Org mode files into awesome HTML in 2 minutes or less

[Nicholas D Steeves]

On Thu, Nov 14, 2019 at 07:20:18PM +, Ben Hutchings wrote:
> On Wed, 2019-11-13 at 23:41 -0500, Nicholas D Steeves wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Nicholas D Steeves 
> > 
> > * Package name: org-html-themes
> >   Version : 1.0.0
> >   Upstream Author : 
> > * URL : https://github.com/fniessen/org-html-themes
> > * License : GPL-3+
> >   Programming Lang: Org_style_markdown, HTML, CSS, js vs Debian's libjs-foos
> >   Description : export Emacs Org mode files into awesome HTML in 2 
> > minutes
> > 
> >  Org-HMTL themes is an open source framework that enables the
> [...]
> 
> Typo: "HMTL".

Thanks, fixed! :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#944145: marked as pending in lintian

[Chris Lamb]

Hi Richard,

> The logic introduced in 1a9e33024cbffa15329b61ad281e9b8db8c46cf1 to fix
> this bug is backwards.

Whoops… Fixed in:

  
https://salsa.debian.org/lintian/lintian/commit/064d0be3b862e26a5e9729d7cd086aaf05815834

Thanks. :)


Regards,

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

Bug#944987: pylint: please upgrade to >= 2.3.0

[Joseph Herlant]

Source: pylint
Version: 2.2.2-4
Severity: wishlist

Hi Sandro,

Would it be possible to upgrade pylint to latest please?
I'm currently in the need of pylint 2.3.0 minimum to be able to upgrade pylint-
django.
If you want me to take care of it, please let me know I can try.

Thanks,
Joseph



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

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

Bug#944916: asymptote: asymptote.sty uses `\RequirePackage[space]{grffile}' which crashes

[Norbert Preining]

> \RequirePackage[space]{grffile}

Good idea, uploaded a new version just now. Thanks!

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#944986: ITP: emacs-wgrep -- edit multiple files simultaneously in Emacs using grep buffers--pattern editing

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 
Control: tag + moreinfo

Package name: emacs-wgrep
Version : 2.3.0
Upstream Author : Masahiro Hayashi 
URL : https://github.com/mhayashi1120/Emacs-wgrep
License : GPL-3+
Programming Lang: Emacs LISP
Description : edit multiple files simultaneously in Emacs using grep 
buffers--pattern editing

Wgrep for Emacs enables writeable grep buffers.  It is a maintained
fork of Matsushita Akihisa's grep-edit.el.  I have not yet tested it,
and am packaging it as a new dependency of src:emacs-ivy_0.13.0.  I am
supposing that it is something like an interactive sed shell that
enables multiple files to be edited simultaneously using patterns,
because if it can't do this then its primary value when compared to
the built-in M-x replace-regexp is probably buffer persistence (vs
replace-regexp's ephemeral minibuffer).

I would be maintaining it as part of the Debian Emacsen Team and will
require a sponsor for the initial upload.

I have marked this bug as "moreinfo" because while upstream provides
GPL-3+ headers for all files, a LICENSE or COPYING file is not present
for this multi-file work, Masahiro Hayashi does not note his copyright
anywhere in the project, and more importantly Matsushita Akihisa's
2002-2009 automatic-copyright-on-fixation is not mentioned anywhere.
Assuming all of his work hasn't been replaced in this fork, I think
that's probably a blocker.  I will contact upstream about these issues
before proceeding with packaging this software for Debian.


Regards,
Nicholas

Bug#944882: diffoscope: please (at least) include hint in html that text version has no max report size

[Chris Lamb]

forwarded 944882 
https://salsa.debian.org/reproducible-builds/diffoscope/issues/76
thanks

I've forwarded this upstream here:

  https://salsa.debian.org/reproducible-builds/diffoscope/issues/76


Regards,

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

Bug#944145: marked as pending in lintian

[Richard Laager]

Control: reopen 944145
Control: found 944145 2.36.0

The logic introduced in 1a9e33024cbffa15329b61ad281e9b8db8c46cf1 to fix
this bug is backwards. It is now suppressing the missing-install-key for
all standalone services, when it should be suppressing it for not
standalone services.

The following patch fixes the original bug and the new bug.

diff --git a/checks/systemd.pm b/checks/systemd.pm
index 263456c6d..f125a2d63 100644
--- a/checks/systemd.pm
+++ b/checks/systemd.pm
@@ -304,7 +304,7 @@ sub check_systemd_service_file {
   $self->extract_service_file_values($file, 'Install', 'RequiredBy',1)
   or $self->extract_service_file_values($file, 'Install', 'Also',1)
   or $is_oneshot
-  or $is_standalone
+  or not $is_standalone
   or $file !~ m,^lib/systemd/[^\/]+/[^\/]+\.service$,
   or $file =~ m,@\.service$,;

-- 
Richard

Bug#944985: Use of uninitialized value in concatenation or string at…Command/make.pm

[Nicholas D Steeves]

Package: dh-make-elpa
Version: 0.17
Severity: normal

Hi,

While I initially found this bug using a local bpo of dh-make-elpa,
I've confirmed that 0.17 in sid is affected.

$ dh-make-elpa
W: Failed to determine binary packages
W: Falling back to a single binary package
Use of uninitialized value in concatenation (.) or string at 
/usr/share/perl5/DhMakeELPA/Command/make.pm line 144.

Steps to reproduce in a clean sid chroot:

1. apt install git emacs-nox dh-make-elpa
2. git clone -o upstream https://github.com/mhayashi1120/Emacs-wgrep.git
3. mv Emacs-wgrep emacs-wgrep && cd emacs-wgrep
4. git reset --hard 2.3.0
5. git branch --unset-upstream
6. dh-make-elpa --pkg-emacsen
7. Warnings are printed.
8. All els are installed to the main elpa-wgrep package.
9. The value for the "Copyright: " field for "Files: *" is empty.

After consulting make.pm:L144 my guess is that "use of uninitialized
value in concatenation" is caused by empty results when trying to
match patterns such as "Copyright", "(C)", or "©", because none of
these patterns appear anywhere in upstream's tree.

While #8 could be cloned as a wishlist bug (better autodetection of
subpackages), I believe #9 is a normal priority bug where dh-make-elpa
should handle the no-matches-found case, and print something useful
like "no matches found for $list_of_patterns ; manually check all
files, and consider contacting upstream about missing copyright".


Thanks,
Nicholas

Bug#944325: please fix this unclear and obtuse phrasing in §7.8 (suggestion provided)

[Sean Whitton]

Hello,

On Sun 17 Nov 2019 at 10:29AM -08, Russ Allbery wrote:

> How about:
>
> This field should only be used when there are license or DFSG
> requirements to retain the referenced source package.  It should not
> be added solely as a way to locate packages that need to be rebuilt
> against newer versions of their build dependencies.

Thanks, I think this is good -- would be good to hear from Nicholas too
though.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#944920: Revise terminology used to specify requirements

[Sean Whitton]

Hello Russ,

Thanks for this.

On Sun 17 Nov 2019 at 10:10AM -08, Russ Allbery wrote:

> +* The term *may* and the adjective *optional* are sometimes used to
> +  clarify cases where it may otherwise appear that Policy is specifying a
> +  requirement or recommendation. These words describe decisions that are
> +  truly optional and at the maintainer's discretion.

I've done some grepping to verify that this change is consistent.

In section 4.11 we have "This is an optional, recommended configuration
file ..." and in other places too it seems that 'optional' gets used to
mean, specifically, that a computer program is not going to shout at you
if something is not present.

Additionally, I think that 'may' gets used in a few other ways -- it
comes up very many times and I haven't checked all of them.

So how about adding "In such cases, ..." right before "... these words
describe decisions ...", to clarify that your new text is not exhaustive
regarding usage of 'may' and 'optional' in Policy?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#944932: pages 403ing

[Tom Goulet]

Also
https://www.debian.org/distrib/ and
https://www.debian.org/intro/about and
https://www.debian.org/mirror/list
are all returning 403 forbidden error messages.

-- 
Tom

Bug#944984: live-installer: Scripts access internal dpkg database

[Guillem Jover]

Source: live-installer
Source-Version: 57
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains several scripts, which directly access the dpkg
internal database, instead of using one of the public interfaces
provided by dpkg.

These scripts check for the presence of the .list and .postinst files to
assert whether packages are installed. These components should be switched
to use something else. For example check the status for each of these
packages via dpkg-query.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944983: live-build: Scripts access internal dpkg database

[Guillem Jover]

Source: live-build
Source-Version: 1:20190315
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains several scripts, which directly access the dpkg
internal database, instead of using one of the public interfaces
provided by dpkg.

The script «scripts/build/chroot_live-packages» checks for the presence
of the .list file to assert whether a package is installed. It should
be switched to use something else. For example the package status from
«dpkg-query».

The other scripts, even though do mess with the internal database, seem
to be installer code, and as long as it is executed before any dpkg in
that chroot, then it might assume historical database layouts, although
I'd rather we found a way to avoid those usages too (but let's ignore
these for now).


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944982: open-infrastructure-compute-tools: Script accesses internal dpkg database

[Guillem Jover]

Source: open-infrastructure-compute-tools
Source-Version: 20190811-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a script («share/scripts/debconf»), which
directly access the dpkg internal database, instead of using one
of the public interfaces provided by dpkg.

The script checks for the presence of the .list and .postinst files to
assert whether packages are installed. These components should be switched
to use something else. For example check the status for each of these
packages via dpkg-query.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944981: open-infrastructure-system-tools: Components and script access internal dpkg database

[Guillem Jover]

Source: open-infrastructure-system-tools
Source-Version: 20190301-lts1-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains several components (system-config) and scripts
(system-build), which directly access the dpkg internal database,
instead of using one of the public interfaces provided by dpkg.

All these components (system-config) check the presence of the .list
file to assert whether a package is installed. These components should
be switched to use something else. Either check the status for each of
these components (via dpkg-query), or these checks should be refactored
into the call site which could do the checks over the entire database
with a single call to «dpkg-query --show» instead of calling it once
per package.

The script «scripts/build/chroot_live-packages» should be changed to
do something similar to the above. The other script, even though do
mess with the internal database, seem to be installer code, and as
long as it is executed before any dpkg in that chroot, then it might
assume historical database layouts, although I'd rather we found a way
to avoid those usages too (but let's ignore these for now).


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944980: live-config: Components access internal dpkg database

[Guillem Jover]

Source: live-config
Source-Version: 5.20190519
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains several components, which directly access
the dpkg internal database, instead of using one of the public
interfaces provided by dpkg.

All these components check the presence of the .list file to assert
whether a package is installed. These components should be switched
to use something else. Either check the status for each of these
components (via dpkg-query), or these checks should be refactored
into the call site which could do the checks over the entire database
with a single call to «dpkg-query --show» instead of calling it once
per package.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944621: RFS: logrotate/3.15.1-2 -- Log rotation utility

[Adam Borowski]

On Sun, Nov 17, 2019 at 04:36:07PM +0100, Christian Göttsche wrote:
> Am So., 17. Nov. 2019 um 05:37 Uhr schrieb Adam Borowski 
> :
> > autopkgtest [05:22:32]: test custom-run: [---
> > == run #1
> > Potentially dangerous mode on config: 0664
> > error: Ignoring config because it is writable by group or others.
> > Reading state from file: state
> > Allocating hash table for state file, size 64 entries
> > Creating new state
> >
> > Handling 0 logs
> > Removing /tmp/autopkgtest.ZQUE0K/build.BFe/src/test.log from state file, 
> > because it does not exist and has not been rotated for one year
> > == checking test.log
> > == checking test.log.1
> > autopkgtest [05:22:33]: test custom-run: ---]
> > autopkgtest [05:22:33]: test custom-run:  - - - - - - - - - - results - - - 
> > - - - - - - -
> > custom-run   FAIL non-zero exit status 1
> 
> Thanks for reviewing.
> 
> Fixed in 
> https://salsa.debian.org/debian/logrotate/-/tags/debian%2F3.15.1-2+reupload1
> and re-uploaded to mentors.d.n .

Alas, it still fails, although with a different message:

autopkgtest [23:30:01]: test custom-run: [---
== run #1
reading config file config
Reading state from file: state
Allocating hash table for state file, size 64 entries
Creating new state

Handling 1 logs

rotating pattern: /tmp/autopkgtest.EJZ8hM/build.wOv/src/test.log  after 1 days 
(3 rotations)
empty log files are rotated, old logs are removed
considering log /tmp/autopkgtest.EJZ8hM/build.wOv/src/test.log
error: skipping "/tmp/autopkgtest.EJZ8hM/build.wOv/src/test.log" because parent 
directory has insecure permissions (It's world writable or writable by group 
which is not "root") Set "su" directive in config file to tell logrotate which 
user/group should be used for rotation.
Removing /tmp/autopkgtest.EJZ8hM/build.wOv/src/test.log from state file, 
because it does not exist and has not been rotated for one year
autopkgtest [23:30:02]: test custom-run: ---]
autopkgtest [23:30:02]: test custom-run:  - - - - - - - - - - results - - - - - 
- - - - -
custom-run   FAIL non-zero exit status 1



喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#944979: Security: unrtf Jessie crash (global-buffer-overflow)

[Antoine Cervoise]

Package: unrtf
Version: 0.21.5-3+deb8u1

Dear Maintainer,

unrtf on Debian Jessie crashes when analyzing the following file (crash.rtf). 
unrtf is not crashing on Debian Stretch Package (0.21.9-clean-3).

Package info:
$ dpkg --list
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   Architecture
  Description
+++-=-=-=-===
ii  unrtf 0.21.5-3+deb8u1   amd64   
  RTF to other formats converter

File info:
$ md5sum crash.rtf
e025c809c42b784c0b00d2cb2a34b279  crash.rtf
$ sha1sum crash.rtf
d5de7e21b22399c859083bd28ce32bc4127492e1  crash.rtf
$ sha256sum crash.rtf
13a5b726cca07f1ce3ba296c897ccc24ae4fefe278889d3e90386d1495e6d2a6  crash.rtf
$ file crash.rtf
crash.rtf: Rich Text Format data, version 1, ANSI

Crash:
$ unrtf crash.rtf






Segmentation fault

Trace from crash (gdb with peda plugin):
Program received signal SIGSEGV, Segmentation fault.

[--registers---]
RAX: 0x0
RBX: 0x77dd72a0 --> 0xfbad2a84
RCX: 0x
RDX: 0x20 (' ')
RSI: 0x7ffe
RDI: 0x69666e6f63206f4e ('No confi')
RBP: 0x7fffde90 --> 0x613380 --> 0x77dd72a0 --> 0xfbad2a84
RSP: 0x7fffd8c0 --> 0x3
RIP: 0x77a7bdcc (<_IO_vfprintf_internal+19468>:)
R8 : 0x69666e6f63206f4e ('No confi')
R9 : 0x77a7c99a (<_IO_vfprintf_internal+22490>:)
R10: 0x77dd56a0 --> 0x0
R11: 0x0
R12: 0x40ccf8 ("%d %s %d ")
R13: 0x0
R14: 0x0
R15: 0x7fffdea8 --> 0x300020 (' ')
EFLAGS: 0x10286 (carry PARITY adjust zero SIGN trap INTERRUPT direction 
overflow)
[-code-]
   0x77a7bdc3 <_IO_vfprintf_internal+19459>:xoreax,eax
   0x77a7bdc5 <_IO_vfprintf_internal+19461>:or 
rcx,0x
   0x77a7bdc9 <_IO_vfprintf_internal+19465>:movrdi,r8
=> 0x77a7bdcc <_IO_vfprintf_internal+19468>:
repnz scas al,BYTE PTR es:[rdi]
   0x77a7bdce <_IO_vfprintf_internal+19470>:
movDWORD PTR [rbp-0x4c8],0x0
   0x77a7bdd8 <_IO_vfprintf_internal+19480>:movrsi,rcx
   0x77a7bddb <_IO_vfprintf_internal+19483>:notrsi
   0x77a7bdde <_IO_vfprintf_internal+19486>:lear10,[rsi-0x1]
[stack-]
| 0x7fffd8c0 --> 0x3
0008| 0x7fffd8c8 --> 0x65e090 --> 0x65e820 ("\n\n")
0016| 0x7fffd8d0 --> 0x7fffda20 --> 0x40cc7d ("align_right_begin")
0024| 0x7fffd8d8 --> 0x77aa5907 (<_IO_new_file_xsputn+87>:mov
QWORD PTR [rbp+0x28],rax)
0032| 0x7fffd8e0 --> 0x77dd72a0 --> 0xfbad2a84
0040| 0x7fffd8e8 --> 0x7fffdee0 --> 0x7e3
0048| 0x7fffd8f0 --> 0x40cf30 ("creation date: ")
0056| 0x7fffd8f8 --> 0xf
[--]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x77a7bdcc in _IO_vfprintf_internal (s=,
format=, ap=ap@entry=0x7fffdea8) at vfprintf.c:1642
1642vfprintf.c: No such file or directory.

Trace from crash (Debian package with patches compiled with Address Sanitizer 
on another computer):
==20518==ERROR: AddressSanitizer: global-buffer-overflow on address 
0x555977f1f8c8 at pc 0x555977f0c113 bp 0x7ffd07589a30 sp 0x7ffd07589a20
READ of size 1 at 0x555977f1f8c8 thread T0
#0 0x555977f0c112 in word_print_core 
(/media/cvs/GSM/fuzz/unrtf/jessie/asan/unrtf-0.21.5/src/unrtf+0x22112)
#1 0x555977f0c7bb in word_print_core 
(/media/cvs/GSM/fuzz/unrtf/jessie/asan/unrtf-0.21.5/src/unrtf+0x227bb)
#2 0x555977f0cdde in word_print 
(/media/cvs/GSM/fuzz/unrtf/jessie/asan/unrtf-0.21.5/src/unrtf+0x22dde)
#3 0x555977f0f9de in main 
(/media/cvs/GSM/fuzz/unrtf/jessie/asan/unrtf-0.21.5/src/unrtf+0x259de)
#4 0x7f0240a52b96 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
#5 0x555977efbdf9 in _start 
(/media/cvs/GSM/fuzz/unrtf/jessie/asan/unrtf-0.21.5/src/unrtf+0x11df9)

0x555977f1f8c8 is located 3 bytes to the right of global variable '*.LC189' 
defined in 'convert.c' (0x555977f1f8c0) of size 5
  '*.LC189' is ascii string 'ansi'
0x555977f1f8c8 is located 56 bytes to the left of global variable '*.LC190' 
defined in 'convert.c' (0x555977f1f900) of size 8
  '*.LC190' is ascii string 'ansicpg'
SUMMARY: AddressSanitizer: global-buffer-overflow 
(/media/cvs/GSM/fuzz/unrtf/jessie/asan/unrtf-0.21.5/src/unrtf+0x22112) in 
word_print_core
Shadow bytes around the buggy address:
  0x0aabaefdbec0: 00 01 f9 f9 f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9
  0x0aabaefdbed0: 00 07 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
  0x0aabaefdbee0: 00 00 00 00 00 00 00 

Bug#944923: mmdebstrap: depends on perl-doc seemingly nedlessly

[Jonas Smedegaard]

Quoting Johannes Schauer (2019-11-17 22:51:10)
> Quoting Jonas Smedegaard (2019-11-17 21:50:54)
> > Ah, indeed - I wasn't aware of that (and wonder if other tools in 
> > Debian suffer from same issue).
> > 
> > I suggest look at the package rename - from a quick experimentation 
> > it seems to show source only for its more exotic --man option and 
> > not its --help option.
> > 
> > Even if keeping code as-is, I'd argue that it makes more sense to 
> > relax to only recommend perl-doc: Core functionality is unaffected 
> > and nothing explodes, it just "looks weird".
> 
> I think there is an easy solution. It indeed seems that executing 
> pod2usage() from Pod::Usage with -verbose=>1 does *not* require the 
> package perl-doc and prints the sections "synopsis" and "options" 
> which I think is everything that can be expected of the --help output. 
> Only with -verbose=>2 is the perl-doc package needed to avoid printing 
> out the source code.
> 
> So after changing the call to pod2usage() from -verbose=>2 to 
> -verbose=>1 for the --help output we can completely drop the perl-doc 
> dependency.

Good to hear that.  Happy to help just a tiny bit on this marvellous 
tool!

 - Jonas

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

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


signature.asc
Description: signature

Bug#944977: avfs: Modules access internal dpkg database

[Guillem Jover]

Source: avfs
Source-Version: 1.1.1-1
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains the «extfs/apt.in», «extfs/debd.in» and
«extfs/dpkg.in» modules, which directly accesses the dpkg internal
database, instead of using one of the public interfaces provided by
dpkg.

---
The «extfs/apt.in» module should stop reading the status database
and the files list files, and be switched to use something like:

  «dpkg-query \
--showformat 'Package: ${Package}\n\
  Status: ${db:Status-Status}\n\
  Section: ${Section}\n\
  Installed-Size: ${Installed-Size}\n\
  Mtime: ${db-fsys:Last-Modified}\n' \
--show»

to get them.

---
The «extfs/debd.in» module should stop poking into the control files
database, and instead use something like:

  «dpkg-query --control-list $pkg»

to get the list of control files present. It should also stop reading
the files list file directly and instead switch the initial «dpkg -s»
call into something like:

  «dpkg-query \
--showformat 'Package: ${Package}\n\
  Status: ${db:Status-Status}\n\
  Files:\n${db-fsys:Files}\n' \
--show $pkg»

to get them. And it instead of «cat»'ing the control files it should
be using:

  «dpkg-query --control-show $pkg $ctrfile»

there is currently no way to externally trigger the execution of a
maint-script, even though it looks like the one in the fun() function
is bogus as it will not pass any of the expected environment variables
nor expected arguments.

---
The «extfs/dpkg.in» module should stop readind the status and available
databases directly, and use instead:

  «dpkg-query --status»
  «dpkg-query --print-avail»

which will dump the entire things. To get the package last-modified
time it should do something similar to the «extfs/apt.in» module.



This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944976: debootstrap: please add Ubuntu focal

[Adam Borowski]

Package: debootstrap
Version: 1.0.116
Severity: wishlist

Hi!
Ubuntuites don't announce their release names in advance, which means a new
script is required immediately after being known.

This time, the name is "focal".

I've tried to symlink eoan (which links to gutsy) -- seems to work ok.


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

Kernel: Linux 5.4.0-rc7-00053-g1f56ffec5b2d (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  debian-archive-keyring  2019.1
ii  gnupg   2.2.17-3

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client   
ii  ubuntu-archive-keyring   2018.09.18.1-5
ii  ubuntu-keyring [ubuntu-archive-keyring]  2018.09.18.1-5

-- no debconf information

Bug#944978: pandoc: fails to convert horizontal rules from markdown to PDF (through LaTeX)

[Francesco Poli (wintermute)]

Package: pandoc
Version: 2.5-2+b1
Severity: important

Hello!

I've just encountered a new issue with pandoc.

Since the last upgrade of texlive-* packages
(2019.20190930-1 -> 2019.20191112-1), pandoc is no longer able to
produce a PDF file (through LaTeX) from a markdown file including
horizontal rules.

Steps to reproduce:

  $ cat hrule.md
  # Some horizontal rules
  
  --
  *  *  *  *
  __
  $ pandoc hrule.md -o hrule.pdf
  Error producing PDF.
  ! Missing number, treated as zero.
  
 \protect
  l.62 ...enter}\rule{0.5\linewidth}{\linethickness}


It seems that pdflatex does not like the LaTeX code generated by
pandoc:

  $ pandoc hrule.md -o hrule.tex
  $ grep rule hrule.tex
  \hypertarget{some-horizontal-rules}{%
  \section{Some horizontal rules}\label{some-horizontal-rules}}
  \begin{center}\rule{0.5\linewidth}{\linethickness}\end{center}
  \begin{center}\rule{0.5\linewidth}{\linethickness}\end{center}
  \begin{center}\rule{0.5\linewidth}{\linethickness}\end{center}
  $ texfot pdflatex hrule.tex
  /usr/bin/texfot: invoking: pdflatex hrule.tex
  This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian) 
(preloaded format=pdflatex)
  ! Missing number, treated as zero.
  
  l.62 ...enter}\rule{0.5\linewidth}{\linethickness}
  ! Emergency stop.
  
  l.62 ...enter}\rule{0.5\linewidth}{\linethickness}
  !  ==> Fatal error occurred, no output PDF file produced!
  Transcript written on hrule.log.
  

Please fix this bug and/or forward my bug report upstream.
Thanks for your time.

Bye!


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

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

Versions of packages pandoc depends on:
ii  libatomic1   9.2.1-19
ii  libc62.29-3
ii  libffi6  3.2.1-9
ii  libgmp10 2:6.1.2+dfsg-4
ii  libpcre3 2:8.39-12+b1
ii  pandoc-data  2.5-2
ii  zlib1g   1:1.2.11.dfsg-1+b1

pandoc recommends no packages.

Versions of packages pandoc suggests:
pn  context
pn  ghc
pn  groff  
pn  libjs-mathjax  
ii  librsvg2-bin   2.44.14-1
pn  node-katex 
pn  nodejs 
ii  pandoc-citeproc0.15.0.1-1+b1
ii  perl   5.30.0-9
pn  php
ii  python 2.7.17-1
pn  r-base-core
ii  ruby   1:2.5.2
ii  texlive-latex-extra2019.20191112-1
ii  texlive-latex-recommended  2019.20191112-1
pn  texlive-luatex 
ii  texlive-xetex  2019.20191112-1
pn  wkhtmltopdf

-- no debconf information

Bug#944975: pulseaudio user daemon degraded state

[Eduard Bloch]

Package: pulseaudio
Version: 13.0-3
Severity: normal

$ systemctl --user |grep failed
● pulseaudio.service
loaded failed failedSound Service
● pulseaudio.socket 
loaded failed failedSound System
$ systemctl --user status pulseaudio.service
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-11-17 23:02:42 CET; 4min 
54s ago
  Process: 21056 ExecStart=/usr/bin/pulseaudio --daemonize=no (code=exited, 
status=1/FAILURE)
 Main PID: 21056 (code=exited, status=1/FAILURE)
$ sudo journalctl --user -u pulseaudio
No journal files were found.
-- No entries --
$ systemctl --user restart pulseaudio
Job for pulseaudio.service failed because the control process exited with error 
code.
See "systemctl --user status pulseaudio.service" and "journalctl --user -xe" 
for details.
$ systemctl --user status pulseaudio.service
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-11-17 23:10:32 CET; 13s ago
  Process: 21409 ExecStart=/usr/bin/pulseaudio --daemonize=no (code=exited, 
status=1/FAILURE)
 Main PID: 21409 (code=exited, status=1/FAILURE)
$ journalctl --user -xe
No journal files were found.

Am I missing something? How to debug this?

The same command works fine when run manually.

NOTE: I have no idea when this misbehavior has started. That's because
this system didn't have user systemd sessions for some months (disabled
in libpam-systemd), now that was restored and it apparently works except
for pulseaudio.

$ systemctl --user status
● zombie
State: degraded
 Jobs: 0 queued
   Failed: 2 units
Since: Fri 2019-11-15 09:16:35 CET; 2 days ago
   CGroup: /user.slice/user-500.slice/user@500.service
   ├─gvfs-daemon.service
   │ ├─ 3763 /usr/lib/gvfs/gvfsd
   │ └─20283 /usr/lib/gvfs/gvfsd-http --spawner :1.9 
/org/gtk/gvfs/exec_spaw/0
   ├─init.scope
   │ ├─3293 /lib/systemd/systemd --user
   │ └─3294 (sd-pam)
   ├─gpg-agent.service
   │ └─3526 /usr/bin/gpg-agent --supervised
   ├─at-spi-dbus-bus.service
   │ ├─ 3735 /usr/lib/at-spi2-core/at-spi-bus-launcher
   │ ├─ 3740 /usr/bin/dbus-daemon 
--config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork 
--print-address 3
   │ └─19314 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
   └─dbus.service
 └─3335 /usr/bin/dbus-daemon --session --address=systemd: --nofork 
--nopidfile --systemd-activation --syslog-only

Best regards,
Eduard.

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.3.8+ (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pulseaudio depends on:
ii  adduser  3.118
ii  init-system-helpers  1.57
ii  libasound2   1.1.9-1
ii  libasound2-plugins   1.1.9-1
ii  libc62.29-3
ii  libcap2  1:2.27-1
ii  libdbus-1-3  1.12.16-2
ii  libgcc1  1:9.2.1-19
ii  libice6  2:1.0.9-2
ii  libltdl7 2.4.6-11
ii  liborc-0.4-0 1:0.4.31-1
ii  libpulse013.0-3
ii  libsm6   2:1.2.3-1
ii  libsndfile1  1.0.28-6
ii  libsoxr0 0.1.3-2
ii  libspeexdsp1 1.2~rc1.2-1.1
ii  libstdc++6   9.2.1-19
ii  libsystemd0  243-6
ii  libtdb1  1.4.2-2
ii  libudev1 243-6
ii  libwebrtc-audio-processing1  0.3-1+b1
ii  libx11-6 2:1.6.8-1
ii  libx11-xcb1  2:1.6.8-1
ii  libxcb1  1.13.1-2
ii  libxtst6 2:1.2.3-1
ii  lsb-base 11.1.0
ii  pulseaudio-utils 13.0-3

Versions of packages pulseaudio recommends:
ii  dbus-user-session  1.12.16-2
ii  libpam-systemd 243-6
ii  rtkit  0.12-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-4
pn  pavumeter
ii  udev 243-6

-- no debconf 

Bug#944958: interimap: please optionally sync flags with local notmuch database

[Guilhem Moulin]

Hi Jonas,

On Sun, 17 Nov 2019 at 21:19:21 +0100, Jonas Smedegaard wrote:
> I would love something geared towards standards-compliant IMAP,
> enabled by adding one interimap config line pointing to my notmuch
> database.

Such a MUA-specific feature is most likely a won't fix I'm afraid,
because interimap is intentionally MUA-agnostic and I'm very, very keen
to keep it that way…

Not tagging the bug as ‘wontfix’ as hooks *might* be added at some point
in the distant future (or by someone else).  But I'm not convinced it'd
work, because AFAIK notmuch works with filenames in the Maildir, while
interimap has only access to the message UID and sequence number.  (One
could FETCH X-GUIDs but that becomes Dovecot-specific.)  It works with
OfflineIMAP because it speak Maildir natively.  Furthermore, while a
hook system could in principle replicate remote flag updates to a custom
format locally, for the other way around we'd need active polling which
sound rather clunky, especially with NOTIFY.

Sorry to give up on that one, but I'm also very keen on preserving
layering :-P  IMHO the better fix would be to add an IMAP backend to
notmuch.  Unfortunately, that's also the most difficult :-(  (And not
something I plan to work on.)  Perhaps a stand-alone tool to sync a
notmuch tag database against an IMAP server would be easier?  Or even —
further breaking layering — directly in the Maildir.  Both options would
be IMAPd-specific though.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#926717: linux-image-4.19.0-4-amd64: Size of DVD in external drive not recognised properly

[Jan]

Hi!

Sorry, forgot to also send the answer to the bug tracker. So here's an updated 
version:

Nov 7, 2019, 20:57 by st...@s.cotton.clara.co.uk:

> Is there any mention of pktsetup or pktcdvd in dmesg? Although you don't have
> udftools installed, it seems most of the implementation is in the kernel;
> udftools's pktsetup is just a userland tool for running modprobe, sending a
> couple of ioctls, and printing status.
>
Thanks for the hint. I just rechecked with the current Bullseye kernel
$ uname -a
Linux aurora 5.2.0-3-amd64 #1 SMP Debian 5.2.17-1 (2019-09-26) x86_64 GNU/Linux

All symptoms described in this bug report remain and there's no mention of 
pktsetup or pktcdvd in 'journalctl'
# journalctl | grep pkt


Regards, Jan

Bug#944022:

[Michael Norton]

I came here to report the same problem and found there was already this bug, so 
consider this a confirmation. I am certain that /etc/default/firehol did work 
as documented at some point in the past.

Probably a better title for this bug might have been “/etc/defaults/firehol is 
ignored” since that is the actual problem. I hit this bug on a desktop and was 
merely annoyed at the sudden blast of netfilter logs on the console as soon as 
the package installed. So the current title does not apply to my situation at 
all even though it is really the exact same problem. ;-)

A default policy like suggested would have terrible security implications, as 
people with other filtering already in place could unintentionally open up 
their machine just by installing the package. Best to just fix the default 
start-up behaviour.

It looks like this bug is probably a result of migration from init.d script to 
systemd unit. The init.d script is where the check for START_FIREHOL 
happen(s/ed) but the systemd unit doesn’t contain anything equivalent.

Not sure what fix would be correct. I.e., fix things so that 
/etc/default/firehol works again, or change the systemd unit to not start by 
default (or both)? Either would restore the desired previous behaviour of not 
starting by default. I’m assuming there’s likely some sort of Debian policy 
relevant to how default behaviour should happen.

Bug#944437: RFS: rpl/1.0-3 [QA] -- replace strings in files

[Thiago Marques]

Hi,

In my PC the manpage works fine.
Really the program is having some big special character handling.  I'll be
communicating the upstream and closing the bug.
Thanks for your review.

[]
Thiago Andrade

Em dom, 10 de nov de 2019 21:32, Adam Borowski 
escreveu:

> On Sun, Nov 10, 2019 at 10:33:06PM +0100, Adam Borowski wrote:
> > And the tool doesn't seem to work either:
> > .
> > [~/tmp/pkg/some-other-random-package/debian]$ rpl Package Pąckagę *
> >
> > rpl: Replacing "Package" with "Pąckagę" (case sensitive; partial words
> matched)
>
> Alas, it looks like mutt fails to escape a lone dot (ie, SMTP terminator).
>
> The output was:
> .
> | $ rpl Package Pąckagę *
> |
> | rpl: Replacing "Package" with "Pąckagę" (case sensitive; partial words
> matched)
> | .
> | rpl: could not guess encoding; using locale default 'UTF-8'
> |
> | rpl: Could not replace /tmp/.tmp.yl3o48fk with changelog; error: [Errno
> 18] Invalid cross-device link: '/tmp/.tmp.yl3o48fk' -> 'changelog'
> | .
> | rpl: Could not replace /tmp/.tmp.df0h2nph with control; error: [Errno
> 18] Invalid cross-device link: '/tmp/.tmp.df0h2nph' -> 'control'
> | ..
> | rpl: A total of 0 matches replaced in 8 files searched
> `
>
> --
> ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
> ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
> ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
> ⠈⠳⣄ etc), let the drink age at least 3-6 months.
>
owner 944437!
close 944437

>

Bug#944974: gdal-bin: gdal2tiles.py option --webviewer=leaflet does nothing.

[Witold Baryluk]

Package: gdal-bin
Version: 2.4.3+dfsg-1
Severity: normal

I did run gdal2tiles.py on big PNG input in raster mode and gdal2tiles
generated only tilemapresource.xml , no leaflet viewer skeleton when I
used --webviewer=leaflet.

There are no HTML / JS / CSS files in the current working directory or in
the directory with tiles.

Looking at the source code it looks like the included leaflet viewer only
supports mercator profile, not raster. I know leaflet does support raster
/ cartesian layers, so this simply looks like a bit of missing code
(actually way less than the one for the mercator) to add, but maybe there
is some other reason behind it.

This might be a good start:




  
  {title}
  
  https://unpkg.com/leaflet@1.5.1/dist/leaflet.css";

integrity="sha512-xwE/Az9zrjBIphAcBb3F6JVqxf46+CDLwfLMHloNu6KEQCAWi6HcDUbeOfBIptF7tcCzusKFjFw2yuvEpDL9wQ=="
crossorigin=""/>
  https://unpkg.com/leaflet@1.5.1/dist/leaflet.js";
   
integrity="sha512-GffPMF3RvMeYyc1LWMHtK8EbPv0iNZ8/oTtHPx9/cc2ILxQ+u905qIwdpULaqDkyBKgOaB57QTMg7ztg8Jm2Og=="
   crossorigin="">




var yx = L.latLng;

// Helper function to conver to leaflet coventions.
var xy = function(x, y) {
  if (L.Util.isArray(x)) {// When doing xy([x, y]);
return yx(x[1], x[0]);
  }
  return yx(y, x);  // When doing xy(x, y);
};

document.addEventListener('DOMContentLoaded', (event) => {
  // In a CRS.Simple, one horizontal map unit is mapped to one horizontal
  // pixel, and idem with vertical. This means that the whole map is about
  // 1000x1000 pixels big and won’t fit in our HTML container. Luckily, we
  // can set minZoom to values lower than zero.

  var map = L.map('mapid', {zoomSnap: 0.25, zoomDelta: 0.5, crs: L.CRS.Simple, 
minZoom: -5, maxZoom: 10});  // Square cartesian grid for coordinate reference 
system.

  map.setView([3, 3], 0);  // [y, x]

  L.tileLayer('{outputdir}/{z}/{x}/{y}.png', {
attribution: '{copyright}',
maxZoom: {maxzoom},
  }).addTo(map);
});





Cheers,
Witold



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

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 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 gdal-bin depends on:
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-19
ii  libgdal20 [gdal-abi-2-4-0]  2.4.3+dfsg-1
ii  libstdc++6  9.2.1-19
ii  python3 3.7.5-1
ii  python3-gdal2.4.3+dfsg-1
ii  python3-numpy [python3-numpy-abi9]  1:1.16.5-1

gdal-bin recommends no packages.

Versions of packages gdal-bin suggests:
ii  libgdal-grass  2.4.3-2

-- no debconf information

Bug#944973: ocsinventory-agent: Module accesses internal dpkg database

[Guillem Jover]

Source: ocsinventory-agent
Source-Version: 2:2.4.2-3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package ships a module
(«lib/Ocsinventory/Agent/Backend/OS/Generic/Packaging/Deb.pm»), which
directly accesses the dpkg internal database, instead of using one of
the public interfaces provided by dpkg.

The function run() in the module, should be switched to use something
like:

  «dpkg-query --showformat '${Package} ${db-fsys:Last-Modified}\n' --show»

to get the mtime from all .list files. Or add this virtual field into
the existing dpkg-query call.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944968: popularity-contest: Program accesses internal dpkg database

[Bill Allombert]

On Sun, Nov 17, 2019 at 10:44:02PM +0100, Guillem Jover wrote:
> Source: popularity-contest
> Source-Version: 1.69
> Severity: important
> User: debian-d...@lists.debian.org
> Usertags: dpkg-db-access-blocker
> 
> Hi!
> 
> This package contains the «popularity-contest» program, which directly
> accesses the dpkg internal database, instead of using one of the public
> interfaces provided by dpkg.
> 
> The program should stop reading the files list files, and switched to
> use something like:
> 
>   «dpkg-query \
> --showformat 'Package: ${Package}\nFiles:\n${db-fsys:Files}\n' \
> --show»
> 
> to get them.

Hello Guillem,

the last time this comes up the performance of using dpkg-query was poor. 
Was it improved ? What is the first release to support this syntax ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#944972: opensvc: Module accesses internal dpkg database

[Guillem Jover]

Source: opensvc
Source-Version: 1.8~20170412-3
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package ships a module («lib/rcPkgLinux.py»), which directly
accesses the dpkg internal database, instead of using one of the public
interfaces provided by dpkg.

The module «lib/rcPkgLinux.py», should be switched to use something like:

  «dpkg-query --showformat '${Package} ${db-fsys:Last-Modified}\n' --show»

to get the mtime from all .list files.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#929525: primus: brakes libgl1-nvidia-legacy-390xx-glvnd-glx

[Daniele Scasciafratte]

I can confirm the issue and using the flag on apt avoided getting the
nvidia driver switched to a legacy one

--no-install-recommends

Bug#944970: salt: Modules access internal dpkg databases

[Guillem Jover]

Source: salt
Source-Version: 2018.3.4+dfsg1-7
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains modules («salt/modules/dpkg.py» and
«salt/modules/alternatives.py»), which directly access the dpkg
internal database, instead of using one of the public interfaces
provided by dpkg.

In «salt/modules/dpkg.py» module, the function _get_pkg_install_time()
should be switched to use something like:

  «dpkg-query --showformat '${Package} ${db-fsys:Last-Modified}\n' --show $pkg»

to get the mtime from .list files.

The function _get_pkg_ds_avail(), should be switched to use something
like:

  «dpkg-query --print-avail»

to get the available database dump.

In the «salt/modules/alternatives.py», the show_link() function should
be switched to something like:

  «update-alternatives --query $name»


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#941853: crypt(3) should be provided by libxcrypt

[Marco d'Itri]

On Nov 05, Aurelien Jarno  wrote:

> We have done a new upload of glibc into sid. I have just merged the
> changes to the libxcrypt branch. You might want to update your branch by
> adding 1 to the debian revision for the breaks/conflicts.
I have uploaded 4.4.10-2 targeted to experimental with Breaks/Replaces 
for glibc 2.29-4.

ftpmasters: as requested, now you have have explicit signoffs from 
Aurelien and debian-boot: please let me know if something is still 
preventing the currenty libxcrypt from being approved from NEW.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#944971: qtwebengine-opensource-src: the stack is executable, and forced upon linked programs

[Chris Wellons]

Source: qtwebengine-opensource-src
Severity: normal

The libQt5WebEngineCore.so shared object requests an executable stack
from the loader. You can see this using "readelf -l" and inspecting the
GNU_STACK program header. All programs linked against this library also
get an executable stack whether or not they need or want it. Affected
programs include several that parse hostile input from the internet,
such as KMail, Akregator, qutebrowser, and Akonadi. Other Qt and KDE
applications are also affected.

You can see the executable stack in affected programs by looking in
their /proc/PID/maps while they're running.

This isn't a security vulnerability in itself, but an executable stack
makes vulnerabilities in all these applications much easier to exploit.
Fortunately there's no need for an executable stack in QtWebEngine. It
only arises due to a compilation misconfiguration: A handful of object
files fail to use .note.GNU-stack to opt out an executable stack.

https://www.airs.com/blog/archives/518

I've attached a list of the offending object files. Each is an assembly
file, and all but one belong to BoringSSL. Either each of these each
need to be assembled with an empty .note.GNU-stack section, or the "-z
noexecstack" option needs to be supplied at link time.
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/aes128gcmsiv-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/chacha-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/x25519-asm-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/x86_64-mont5.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/sha256-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/x86_64-mont.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/vpaes-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/sha1-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/rdrand-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/sha512-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/p256-x86_64-asm.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/md5-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/rsaz-avx2.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/ghash-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/aesni-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/bsaes-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/aesni-gcm-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/aes-x86_64.o
./src/core/release/host/obj/third_party/boringssl/boringssl_asm/chacha20_poly1305_x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/x25519-asm-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/x86_64-mont5.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/vpaes-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/sha1-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/x86_64-mont.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/sha512-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/rdrand-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/sha256-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/p256-x86_64-asm.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/aesni-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/rsaz-avx2.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/md5-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/bsaes-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/ghash-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/aesni-gcm-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/aes-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/chacha20_poly1305_x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/chacha-x86_64.o
./src/core/release/obj/third_party/boringssl/boringssl_asm/aes128gcmsiv-x86_64.o
./src/core/release/obj/third_party/WebKit/Source/platform/heap/asm/asm/SaveRegisters_x86.o

Bug#944923: mmdebstrap: depends on perl-doc seemingly nedlessly

[Johannes Schauer]

Quoting Jonas Smedegaard (2019-11-17 21:50:54)
> Ah, indeed - I wasn't aware of that (and wonder if other tools in Debian
> suffer from same issue).
> 
> I suggest look at the package rename - from a quick experimentation it 
> seems to show source only for its more exotic --man option and not its 
> --help option.
> 
> Even if keeping code as-is, I'd argue that it makes more sense to relax 
> to only recommend perl-doc: Core functionality is unaffected and nothing
> explodes, it just "looks weird".

I think there is an easy solution. It indeed seems that executing pod2usage()
from Pod::Usage with -verbose=>1 does *not* require the package perl-doc and
prints the sections "synopsis" and "options" which I think is everything that
can be expected of the --help output. Only with -verbose=>2 is the perl-doc
package needed to avoid printing out the source code.

So after changing the call to pod2usage() from -verbose=>2 to -verbose=>1 for
the --help output we can completely drop the perl-doc dependency.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#944969: logrotate processing broken

[Eduard Bloch]

Package: iptraf-ng
Version: 1:1.1.4-6+b1
Severity: normal

I saw that logrotate.service state went red so I checked the log:

systemctl status logrotate.service
● logrotate.service - Rotate log files
   Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-11-17 00:00:00 CET; 22h ago
 Docs: man:logrotate(8)
   man:logrotate.conf(5)
 Main PID: 9160 (code=exited, status=1/FAILURE)

Nov 17 00:00:00 zombie systemd[1]: Starting Rotate log files...
Nov 17 00:00:00 zombie logrotate[9160]: error: iptraf-ng:2 duplicate log entry 
for /var/log/iptraf/rvnamed.log
Nov 17 00:00:00 zombie logrotate[9160]: error: found error in file iptraf-ng, 
skipping
Nov 17 00:00:00 zombie systemd[1]: logrotate.service: Main process exited, 
code=exited, status=1/FAILURE
Nov 17 00:00:00 zombie systemd[1]: logrotate.service: Failed with result 
'exit-code'.
Nov 17 00:00:00 zombie systemd[1]: Failed to start Rotate log files.

However, this is the state of the said file, this can hardly contain a
duplicated log entry:

-rw-r--r--  1 root root 0 Mai 24  2017 rvnamed.log

So I guess it's complaining about wrong logrotate config itself?

$ grep iptraf /etc/logrotate.d/ -r
/etc/logrotate.d/iptraf-ng:# Logrotate file for iptraf
/etc/logrotate.d/iptraf-ng:/var/log/iptraf/*.log {
/etc/logrotate.d/iptraf:/var/log/iptraf/*.log {
/etc/logrotate.d/iptraf:/usr/bin/killall -USR1 iptraf 2> 
/dev/null || :

Checking, purging iptraf -> result: the problem is solved.

Please find a clean solution here, at least mentioning the side effects
of iptraf's remains in README.Debian (but better, check for the other's
config state via checksum and killing it, although not sure whether
policy has some kind of exception for this case).

Best regards,
Eduard.

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

Kernel: Linux 5.3.8+ (SMP w/12 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iptraf-ng depends on:
ii  libc6 2.29-3
ii  libncursesw6  6.1+20191019-1
ii  libtinfo6 6.1+20191019-1

iptraf-ng recommends no packages.

iptraf-ng suggests no packages.

-- no debconf information

--
 installations anleitung für intelx86 richtig ?
 Angel`Eye: Kommt auf deinen Rechner an. Wenn du die Antwort nicht weißt,
ist sie ja.

Bug#944968: popularity-contest: Program accesses internal dpkg database

[Guillem Jover]

Source: popularity-contest
Source-Version: 1.69
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains the «popularity-contest» program, which directly
accesses the dpkg internal database, instead of using one of the public
interfaces provided by dpkg.

The program should stop reading the files list files, and switched to
use something like:

  «dpkg-query \
--showformat 'Package: ${Package}\nFiles:\n${db-fsys:Files}\n' \
--show»

to get them.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#942415: Calligra and Akonadi

[Sandro Knauß]

Hey pino,

> > Why this is not built and shipped and still we have the dependency?
> 
> I do not see any akonadi dependency in the binary packages, can you
> please explain exactly what you see?

what I mean is, if it is only checked at buildtime but no binary package 
depend on it, why it was added to Build-Depends in first place?

Why we do not ship the calligra_semanticitem_{contact,event} plugins?
 
> This is because the tracker for the transition is partially wrong:
> - it considers "affected" all the sources that only build-depend on PIM
>   packages: while this is generally correct, it ought to check both the
>   actual bad _and_ good runtime dependencies instead

You are totally right, the ben file is not that exact that it could be. But 
first it is one of my first transition that I triggered, so I'm not that 
familiar with the ben syntax.

> - the "good" check seems correctly checking for the "new library names"
> - the "bad" check is basically "everything that does not depend on
>   depend on the new names"... which is wrong -- it ought to explicitly
>   check for the _old_ names instead

the bad state is the hard one to describe.
bad state:
 a package depend on libfoo5
good state:
 a package depend on libfoo5 and libfoo-18.08

> - calligra is considered "bad"
> - libkf5sieve, kf5-messagelib, kmail, libkf5mailcommon, and kmail are
>   considered "bad" in all the architectures where they are not actually
>   built
> - maybe (although I'm not sure about this) also all the "?!" states
> 
> Please fix the ben file for this transition, so its status can be
> checked properly.

Well the next kdepim transition is easier as bad is libfoo-18.08 and good is 
libfoo-19.08.

hefee


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

Bug#944967: multistrap: Script accesses internal dpkg database

[Guillem Jover]

Source: multistrap
Source-Version: 2.2.10
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-ctrl

Hi!

This package contains the «multistrap» program, which directly accesses
the dpkg internal database, instead of using one of the public
interfaces provided by dpkg.

The check_bin_sh() function should be switched to use something like:

  «dpkg-query --control-path dash postinst»

to get at the pathname within the database, even though what it tries
to do next is not very kosher. :) But perhaps this code can be removed
now though?

The native() function, I'm not sure what's the intention there TBH,
but it could be replaced with a loop over all installed packages and
then --control-path.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, might change in
the future.

Thanks,
Guillem

Bug#942901: [Pkg-privacy-maintainers] Bug#942901: Bug#942901: torbrowser-launcher: Tor Browser 9.0 shows only black screens due to no write access to /dev/shm/org.mozilla.ipc.*.*

[intrigeri]

Hi,

Antoine Beaupré:
> I also had to add:

> owner @{torbrowser_home_dir}/updater ix,

FWIW, this one is fixed in upstream Git (too):
https://github.com/micahflee/torbrowser-launcher/pull/442

Bug#944966: ruby-debian: Module accesses internal dpkg database

[Guillem Jover]

Source: ruby-debian
Source-Version: 0.3.10
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains the «debian» module, which directly accesses
the dpkg internal database, instead of using one of the public
interfaces provided by dpkg.

The module should stop reading the files list files, and switched to
use something like:

  «dpkg-query \
--showformat 'Package: ${Package}\nFiles:\n${db-fsys:Files}\n' \
--show»

to get them.

To get the status and available files it should instead call
«dpkg-query --status» or «dpkg-query --print-avail» which now support
dumping the entire databases, and which will take care of including
live or pending journal entries.


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944965: debsums: Script accesses internal dpkg database

[Guillem Jover]

Source: debsums
Source-Version: 2.2.4
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains the «debsums» program, which directly accesses
the dpkg internal database, instead of using one of the public
interfaces provided by dpkg.

The debsums program should be switched to use something like:

  «dpkg-query --control-show $pkg md5sums»

to get the md5sums file contents. If the file is missing an error will
be returned. While this is not ideal, because this interface does not
allow batching, at least it will stop accessing the internal database.
I will be adding in the near future a new virtual field to dpkg-query
to be able to fetch all md5sums for all packages with something like:

  «dpkg-query \
--showformat 'Package: ${Package}\nMd5sums: ${db-fsys:Md5sums}\n' \
--show»

The other question though, is whether it still makes sense to ship
debsums, with «dpkg --audit» checking for missing md5sums files,
«dpkg --verify» checking for hash mismatches, and «dpkg --unpack»
generating these when the to be installed does not provide one?


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944923: mmdebstrap: depends on perl-doc seemingly nedlessly

[Jonas Smedegaard]

Quoting Johannes Schauer (2019-11-17 21:03:19)
> Quoting Jonas Smedegaard (2019-11-17 19:17:26)
> > mmdebstrap depends on perl-doc, and is among a very few packages 
> > doing that. I suspect it is unneded.
> > 
> > mmdebstrap added a dependency on perl-doc in December 2018
> > (git commit ffc7faa, seemingly not mentioned in changelog).
> > 
> > Git commit message hints at the reason being "for pod2usage" but I 
> > fail to understand what is needed there, as the only thing I can 
> > find related to pod2usage in perl-doc is its html documentation, 
> > otherwise it is provided in package perl:
> > 
> > jonas@auryn:~$ apt-file search pod2usage
> > perl: /usr/bin/pod2usage
> > perl: /usr/share/man/man1/pod2usage.1.gz
> > perl-doc-html: /usr/share/doc/perl-doc-html/pod2usage.html
> > 
> > 
> > Please consider dropping that dependency.
> 
> try out the following:
> 
> $ mmdebstrap --help
> 
> That's the documentation for mmdebstrap.
> 
> Then fore-remove perl-doc:
> 
> $ dpkg --force-all -r perl-doc
> 
> If you then try running "mmdebstrap --help" again you will see the 
> source code instead of the documentation.
> 
> If you know how to make this work without perl-doc, please don't 
> hesitate to tell.

Ah, indeed - I wasn't aware of that (and wonder if other tools in Debian 
suffer from same issue).

I suggest look at the package rename - from a quick experimentation it 
seems to show source only for its more exotic --man option and not its 
--help option.

Even if keeping code as-is, I'd argue that it makes more sense to relax 
to only recommend perl-doc: Core functionality is unaffected and nothing 
explodes, it just "looks weird".


 - Jonas

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

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


signature.asc
Description: signature

Bug#944801: debian-policy: must all inits support /etc/insserv/override & /usr/share/insserv/override

[Russ Allbery]

Russ Allbery  writes:

> I think the current approach in the entirety of 9.11 no longer makes
> sense, but there are two possible alternative approaches and which to
> pick will depend on the results of the current GR.  Therefore, I think
> we should for the results of the GR rather than doing work on this right
> now.

Should wait for.

(There's some weird kernel bug with the trackpad in my laptop that causes
constant resets that drop or repeat keys while it's being reset.  It's
really irritating, and now I'm going to go experiment with kernel options
to try to fix it properly.)

-- 
Russ Allbery (r...@debian.org)  

Bug#944964: dh-make-perl: Module accesses internal dpkg database

[Guillem Jover]

Source: dh-make-perl
Source-Version: 0.107
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contains a perl module [M], which directly accesses the
dpkg internal database. Instead of using one of the public interfaces
provided by dpkg.

 [M] lib/Debian/DpkgLists.pm

The function _cat_lists() accesses the file list files directly, and
should be switched to use either «dpkg-query --listfiles» instead, or the
dpkg-query db-fsys:Files virtual field with --show. If using the former
and to avoid a performance hit, the code should batch multiple packages
on each call, taking into account command-line length limits. Each
package will get a paragraph separated by a blank line (even if it is
not installed).


This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944962: git-revise: Forward FHS patch to upstream

[Nicolas Schier]

Package: git-revise
Version: 0.4.2-1
Severity: minor

Dear Maintainer,

as suggested in RFP #935329, please forward the FHS patch to upstream.


-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: arm64 (aarch64)

Versions of packages git-revise depends on:
ii  git  1:2.24.0-1
ii  python3  3.7.5-3

git-revise recommends no packages.

git-revise suggests no packages.

-- no debconf information

Bug#944963: debian-goodies: Scripts access internal dpkg database

[Guillem Jover]

Source: debian-goodies
Source-Version: 0.84
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package programs («which-pkg-broke» and «dglob»), which directly
accesses the dpkg internal database, instead of using one of the public
interfaces provided by dpkg.

The program which-pkg-broke, should be switched to use something like:

  «dpkg-query --showformat '${Package} ${db-fsys:Last-Modified}\n' --show $pkg»

to get the mtime from .list files.

The program dglob, should be switched to use:

  «dpkg-query --status»

to get the status file dump, including current journal entries.

This is a problem for several reasons, because even though the layout and
format of the dpkg database is administrator friendly, and it is expected
that those might need to mess with it, in case of emergency, this
“interface” does not extend to other programs besides the dpkg suite of
tools. The admindir can also be configured differently at dpkg build or
run-time. And finally, the contents and its format, will be changing in
the near future.

Thanks,
Guillem

Bug#944959: libonig: CVE-2019-19012

[Salvatore Bonaccorso]

Source: libonig
Version: 6.9.2-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/kkos/oniguruma/issues/16

Hi,

The following vulnerability was published for libonig.

CVE-2019-19012[0]:
| An integer overflow in the search_in_range function in regexec.c in
| Oniguruma 6.x before 6.9.4_rc2 leads to an out-of-bounds read, in
| which the offset of this read is under the control of an attacker.
| (This only affects the 32-bit compiled version). Remote attackers can
| cause a denial-of-service or information disclosure, or possibly have
| unspecified other impact, via a crafted regular expression.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-19012
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19012
[1] https://github.com/kkos/oniguruma/issues/16

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#944961: jhead: CVE-2019-19035

[Salvatore Bonaccorso]

Source: jhead
Version: 1:3.03-3
Severity: important
Tags: security upstream

Hi,

The following vulnerability was published for jhead. The Red Hat
bugzilla entry refers to the poc files from the reporter.

CVE-2019-19035[0]:
| jhead 3.03 is affected by: heap-based buffer over-read. The impact is:
| Denial of service. The component is: ReadJpegSections and process_SOFn
| in jpgfile.c. The attack vector is: Open a specially crafted JPEG
| file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-19035
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19035
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1765647

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#944960: git-revise: Split-out docbase documentation in a separate package

[Nicolas Schier]

Package: git-revise
Version: 0.4.2-1
Severity: normal

Dear Maintainer,

as suggested in RFP #935329, the documentation should be build properly for 
docbase integration, split-out into in a separate package.


-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: arm64 (aarch64)

Versions of packages git-revise depends on:
ii  git  1:2.24.0-1
ii  python3  3.7.5-3

git-revise recommends no packages.

git-revise suggests no packages.

-- no debconf information

Bug#944801: debian-policy: must all inits support /etc/insserv/override & /usr/share/insserv/override

[Russ Allbery]

Ansgar  writes:

>>> 9.11 states:
>>> 
>>> +---
>>> > Alternative init implementations must support running SysV init
>>> > scripts as described at System run levels and init.d scripts for
>>> > compatibility.
>>> +---

> Thinking a bit more about this, I think this requirement should just be
> removed from Policy.  It should be left to the individual communities
> interested in a particular init system how much compatibility with
> sysvinit is useful for them.

I think the current approach in the entirety of 9.11 no longer makes
sense, but there are two possible alternative approaches and which to pick
will depend on the results of the current GR.  Therefore, I think we
should for the results of the GR rather than doing work on this right now.

The two alternatives I see are:

1. Some GR option saying that systemd is the only supported init system
   wins.  In that case, we're going to be deprecating init scripts since
   the integration proporties of unit files are so much better, so we'll
   be making other changes to Policy to document systemd units as the
   preferred syntax for configuring services and everything 9.11 currently
   says should be deleted.  (We probably still want a section on
   alternative init systems, but it would be much different.)

2. Some GR option saying that we want to continue to maintain init scripts
   for compatibility with other init systems wins.  In this case, I think
   we should document the common init script syntax used for compatibility
   purposes along with whatever rules the GR indicates we should have for
   when an init script alongside a systemd unit is required.  Then, I
   think we should rephrase 9.11 to instead say that services are
   configured with either unit files or init scripts and an alternative
   init system therefore would need to handle one or the other or it won't
   be able to properly boot Debian.  (Which does not necessarily mean that
   it would violate Policy requirements; there's nothing wrong with
   packaging init systems intended for use inside containers or other
   special-purpose environments that do not need to support arbitrary
   Debian packages.  But any alternate init system should make clear which
   of those use cases it's aiming at.)

-- 
Russ Allbery (r...@debian.org)  

Bug#944958: interimap: please optionally sync flags with local notmuch database

[Jonas Smedegaard]

Package: interimap
Version: 0.4-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I love interimap helping me distribute emails to multiple workstations.

One thing is missing, though: flags a.k.a. tags.

None of the lightweight MUAs that I use support imap flags, but I have
found a few that support notmuch.  Unfortunately notmuch is local-only.

Ideally I could translate notmuch tags to imag flags.

This approach seems sensible to me:
https://deferred.io/2016/01/18/notmuch-tags-gmail-labels-bidirectional-sync.html#how-does-it-work

...but I am not offering to implement it myself.

Could you perhaps be intrigued to implement it?

The link to code in above blog post is a broken link, but looking around
a bit seems to indicate that the blog author now uses this:
https://github.com/gauteh/lieer

That's written in Python, tightly integrated with yet another sync tools
which is geared towards GMail.

I would love something geared towards standards-compliant IMAP,
enabled by adding one interimap config line pointing to my notmuch
database.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl3Rq0YACgkQLHwxRsGg
ASFNQhAAhBfz//5UzT7x8a7lGdlbvP7iYVSD5jClK39eml5GH/6Xw59bf6pHSeIY
Dp8Bhr0zXloxjp0ecPxqED0M5PEYwyyDUXJ1yp8YHIXtSTv8mpQmd8G+8ANDOjRT
uHgw2jwJ2qq/u8yfVsHapmsTBf2mrVWW4Mu7F7EJYrhRnAeoHwQDvtM2y2KjJ0ma
90IRcO4A8JVR5vAwJYz9gPWuUek+CvQmyImaeTgXPG8+tMdooIR73FjXDdovBvd1
G037OWH1tdboPQx2yOegNTfvv4g1dSc2zZ0jMfHLGVoV/IhGUdhypGCKBXQTGW0f
Zfsa1TLnR3LLuyFEHTIPjo90kiXwWq7Q0tVBBFT0v9ZN+/xrNR1upJgqEj+jS1px
vLzHHepGad8m3OFX7nstKazqVRvV8MlYK9KFFlf3f+JGoC9UKWfkduV2hQi7MHzb
bUEFiHAbtdU3dfWOZu2OVrjJHoupIpOB53KlOrVUtrCINJgvoSEYSJRfAg8Qr4x8
3gZWcMPd5EXq8REF+SzFBpE/O0/kirrs+q4sC3RSa0767/bhFoGXN2CAQJaSO/iu
Gk7CXKyWCg+KfDLBNTXbaf6psw815cwuLJ96U2Ez05R58ooiIio2WbL93tAQvNSJ
nBaiEauWcG0ENbJSycvc4ifzhNB5jzliza61lMGVEPlpqyqqpL4=
=zisj
-END PGP SIGNATURE-

Bug#944957: git-revise's test suite is not run by autopkgtest

[Nicolas Schier]

Package: git-revise
Version: 0.4.2-1
Severity: minor

git-revise's test suite is not run by autopkgtest during package build.


-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: arm64 (aarch64)

Versions of packages git-revise depends on:
ii  git  1:2.24.0-1
ii  python3  3.7.5-3

git-revise recommends no packages.

git-revise suggests no packages.

-- no debconf information

Bug#944329: debian-policy: Unclear text about password files modifications

[Russ Allbery]

Guillem Jover  writes:

> There's this text in section §9.2.1:

>   ,---
>   Packages other than "base-passwd" must not modify "/etc/passwd",
>   "/etc/shadow", "/etc/group" or "/etc/gshadow".
>   `---

> It's not clear to me, whether this refers to the packaging or any
> program provided by that package. Depending on the reading this would
> make the passwd package buggy. So it might be worth clarifying probably
> by adding "passwd" to the exception.

I thought this was more complicated and other packages like adduser might
modify those files directly, but it looks like this isn't the case and
everything else uses the commands in passwd.  So I think we can just say
this:

Packages other than ``base-passwd`` and ``passwd`` must not directly
modify ``/etc/passwd``, ``/etc/shadow``, ``/etc/group`` or
``/etc/gshadow``.

I added "directly" since of course adduser modifies /etc/passwd
indirectly, as does every package that calls adduser in its maintainer
scripts.

-- 
Russ Allbery (r...@debian.org)  

Bug#944923: mmdebstrap: depends on perl-doc seemingly nedlessly

[Johannes Schauer]

Hi,

Quoting Jonas Smedegaard (2019-11-17 19:17:26)
> mmdebstrap depends on perl-doc, and is among a very few packages doing that.
> I suspect it is unneded.
> 
> mmdebstrap added a dependency on perl-doc in December 2018
> (git commit ffc7faa, seemingly not mentioned in changelog).
> 
> Git commit message hints at the reason being "for pod2usage"
> but I fail to understand what is needed there, as the only thing I can
> find related to pod2usage in perl-doc is its html documentation,
> otherwise it is provided in package perl:
> 
> jonas@auryn:~$ apt-file search pod2usage
> perl: /usr/bin/pod2usage
> perl: /usr/share/man/man1/pod2usage.1.gz
> perl-doc-html: /usr/share/doc/perl-doc-html/pod2usage.html
> 
> 
> Please consider dropping that dependency.

try out the following:

$ mmdebstrap --help

That's the documentation for mmdebstrap.

Then fore-remove perl-doc:

$ dpkg --force-all -r perl-doc

If you then try running "mmdebstrap --help" again you will see the source code
instead of the documentation.

If you know how to make this work without perl-doc, please don't hesitate to
tell.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#944812: interimap: uninitialized value

[Guilhem Moulin]

On Sun, 17 Nov 2019 at 20:54:47 +0100, Jonas Smedegaard wrote:
> Ohh - problem seems gone indeed now:

Woo! \o/

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#944929: initramfs-tools: postinst fails when run under fakechroot

[Johannes Schauer]

Control: tag -1 + patch

It seems not only the fakeroot library but also the fakechroot library were
wrongly attempted to being copied. With these changes the postinst script
finishes successfully:

https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/19


signature.asc
Description: signature

Bug#944956: linux-image-4.19.0-6-amd64: NVMe drive not detected

[David MacDonald]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: important

Dear Maintainer,

Installing NVMe SSD on Asus UX430UA laptop (SSD is ADATA ZPG SX8200 Pro). Goal 
was dual boot Windows 10 (already on drive) and Debian
10. Neither Debian 10 installer nor Deb 10.2 Live USB key
could detect NVMe drive. lsblk did not show drive, no /dev/nvme* files were 
present. Drive works on Windows on same machine, and
works on Debian 9 on my desktop machine.

dmesg showed error nvme :03:00.0: Refused to change power state, currently 
in D3
/dev/disk/by-id and /dev/disk/by-type had links for the partitions on the NVMe 
drive - correct number of partitions, but broken links
to /dev/nvme* files that didn't exist.

Added this line to startup in GRUB: nvme_core.default_ps_max_latency_us=0 (also 
tried 5500, which worked)

That seems to have solved the problem, though I imagine that is at the cost of 
proper power management.

As I mentioned, this drive worked on my desktop Deb 9 and on Windows on the 
same laptop. Ideally, it would work without having to 
disable APST so that Debian 10 can run without the extra power drain.

Thanks


-- Package-specific info:
** Version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-6-amd64 
root=UUID=5a3fe95c-c293-4153-9685-6d090c4f29b8 ro 
nvme_core.default_ps_max_latency_us=5500 quiet

** Not tainted

** Kernel log:
[7.462791] kauditd_printk_skb: 5 callbacks suppressed
[7.462793] audit: type=1400 audit(1574017435.750:16): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince" pid=490 
comm="apparmor_parser"
[7.463199] audit: type=1400 audit(1574017435.750:17): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince//sanitized_helper" pid=490 comm="apparmor_parser"
[7.464208] audit: type=1400 audit(1574017435.750:18): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/evince-previewer" 
pid=490 comm="apparmor_parser"
[7.464463] audit: type=1400 audit(1574017435.750:19): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince-previewer//sanitized_helper" pid=490 
comm="apparmor_parser"
[7.464971] audit: type=1400 audit(1574017435.750:20): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/bin/evince-thumbnailer" pid=490 comm="apparmor_parser"
[9.954030] audit: type=1400 audit(1574017438.242:21): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice" 
pid=466 comm="apparmor_parser"
[9.954736] audit: type=1400 audit(1574017438.242:22): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-soffice//gpg" 
pid=466 comm="apparmor_parser"
[   10.046272] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   10.046274] Bluetooth: BNEP filters: protocol multicast
[   10.046278] Bluetooth: BNEP socket layer initialized
[   10.282108] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[   10.541054] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[   10.822616] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[   10.904097] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[   12.033151] fuse init (API version 7.27)
[   14.340048] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[   15.062746] wlp2s0: authenticate with 00:26:5a:d0:55:bc
[   15.072080] wlp2s0: send auth to 00:26:5a:d0:55:bc (try 1/3)
[   15.078665] wlp2s0: authenticated
[   15.081387] wlp2s0: associate with 00:26:5a:d0:55:bc (try 1/3)
[   15.085349] wlp2s0: RX AssocResp from 00:26:5a:d0:55:bc (capab=0x431 
status=0 aid=2)
[   15.089785] wlp2s0: associated
[   15.163549] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
[   22.383573] Bluetooth: RFCOMM TTY layer initialized
[   22.384011] Bluetooth: RFCOMM socket layer initialized
[   22.384016] Bluetooth: RFCOMM ver 1.11
[  161.405575] PM: suspend entry (deep)
[  161.405577] PM: Syncing filesystems ... done.
[  161.407478] (NULL device *): firmware: direct-loading firmware 
iwlwifi-8000C-36.ucode
[  161.407524] Freezing user space processes ... (elapsed 0.001 seconds) done.
[  161.408999] OOM killer disabled.
[  161.409000] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
done.
[  161.410162] Suspending console(s) (use no_console_suspend to debug)
[  161.410518] wlp2s0: deauthenticating from 00:26:5a:d0:55:bc by local choice 
(Reason: 3=DEAUTH_LEAVING)
[  161.727163] ACPI: EC: interrupt blocked
[  161.782211] ACPI: Preparing to enter system sleep state S3
[  161.786436] ACPI: EC: event blocked
[  161.786438] ACPI: EC: EC stopped
[  161.786440] PM: Saving platform NVS memory
[  161.786537] Disabling non-boot CPUs ...
[  161.802787] smpboot: CPU 1 is now offline
[  161.828298] smpboot: CPU 2 is now offline
[  161.850681] smpboot: CPU 3 is now offline
[184467

Bug#944955: libprelude: doesn't build for all supported python3 versions

[Mattia Rizzolo]

Source: libprelude
Version: 5.0.0-1
Severity: important
Tags: patch

It seems that you lost a line in d/rules that made the package build
against multiple python3 versions.

The following patch reinstate the line:

--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,7 @@ CONFIGURE_FLAGS = --without-python2 --enable-easy-bindings
 ifeq ($(filter nopython,$(DEB_BUILD_PROFILES)),)
DH_ADDONS += --with python3
CONFIGURE_FLAGS += --with-python3=yes
+   PY3VERS=$(shell py3versions -vr)
 else
CONFIGURE_FLAGS += --with-python3=no
 endif


Doing so, yields the following difference in the python3 packages:
|% debdiff python3-prelude_5.1.1-*deb
|[The following lists of changes regard files as different if they have
|different names, permissions or owners.]
|
|Files in second .deb but not in first
|-
|-rw-r--r--  root/root   
/usr/lib/python3/dist-packages/_prelude.cpython-38-x86_64-linux-gnu.so
|
|Control files: lines which differ (wdiff format)
|
|Depends: python3 (<< [-3.8),-] {+3.9),+} python3 (>= 3.7~), python3:any, 
libprelude28 (= [-5.1.1-3),-] {+5.1.1-4),+} libc6 (>= 2.22), libgcc1 (>= 
1:3.0), libpreludecpp12, libstdc++6 (>= 5.2)
|Installed-Size: [-783-] {+1168+}
|Provides: [-python3.7-prelude-] {+python3.7-prelude, python3.8-prelude+}
|Version: [-5.1.1-3-] {+5.1.1-4+}
|
|No differences were encountered between the postinst files
|
|No differences were encountered between the prerm files

Please consider applying the patch above at your earliest convenience.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#944949: dbus-python: needs an explicit build dependency on dh-python

[Simon McVittie]

Control: tags 944949 + moreinfo

On Sun, 17 Nov 2019 at 19:07:39 +, Matthias Klose wrote:
> Please add an explicit build dependency on dh-python.

As far as I can see it's been explicit since 2015. Is anything more
needed here?

Note that the FTBFS with

dh_python2
make[1]: dh_python2: Command not found

seems to be because /usr/bin/dh_python2 is a #!/usr/bin/python script in
a package that doesn't depend on python (#944894). The misleading
"Command not found" is similar to this:

$ cat > Makefile
all:
./script
$ cat > script
#!/usr/bin/does-not-exist
$ chmod +x script
$ make
./script
make: ./script: Command not found
make: *** [Makefile:2: all] Error 127

I have a workaround which I believe should still be harmless after
dh_python2 moves out of python2 (presumably into dh-python?), which I'll
upload soon.

If that doesn't work, I'll temporarily re-add the python B-D so the
python3.8 transition can go through, and remove it after #944894 is
resolved.

It's unfortunate that the python3.8 transition, the effort to replace
references to python2 with python, and the migration of dh_python2 from
python2 to dh-python (?) are happening at the same time and affect
overlapping sets of packages. Perhaps one (or more) of these could be
deferred until one of the others has been done?

smcv

Bug#944812: interimap: uninitialized value

[Jonas Smedegaard]

Quoting Guilhem Moulin (2019-11-17 20:37:33)
> On Sun, 17 Nov 2019 at 19:35:51 +0100, Jonas Smedegaard wrote:
> > I tried now to remove all dovecot.index* files for that Maildir, and 
> > (as earlier) the command greps nothing.
> 
> Sounds good to me, and hopefully UID 97 no longer show up in 
> mailbox-wise UID FETCH commands:
> 
> b UID FETCH 1:* (MODSEQ FLAGS INTERNALDATE BODY.PEEK[])
> 
> If that's indeed the case then the problem seems gone to me.

Ohh - problem seems gone indeed now:

jonas@auryn:~$ interimap --config debian --repair INBOX.olpc
local: IMAP traffic (bytes): recv 197.05K sent 234
remote: IMAP traffic (bytes): recv 197.30K sent 267


Possibly it was reindexing that did the trick. Not sure.

Thanks for the ride!

 - Jonas

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

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


signature.asc
Description: signature

Bug#903153: RE: nasm does not handle rdf2 output correctly due to incorrect use of pure_func

[Παναγιώτης Μπίκος]

Issue persists in nasm 2.14-1 (Debian 10.2 Stable)


pbikos@dev:/home/large/code/osdev$ cat main.asm

section .text

pbikos@dev:/home/large/code/osdev$ nasm -f rdf main.asm
main.asm:panic: rdf segment numbers not allocated as expected (2,4,6)
pbikos@dev:/home/large/code/osdev$ nasm -v
NASM version 2.14

Bug#934665: upload grpc and protobuf to unstable

[Pirate Praveen]

On തി, Nov 18, 2019 at 00:36, Nilesh Patra  
wrote:



On Sun, 17 Nov 2019, 23:44 Pirate Praveen, > wrote:
These packages should rebuilt without ccache in chroot and confirm 
if ccache caused the failure: nageru, opencv


I will try checking them.



nageru was a real failure but its maintainer fixed it as soon as I 
filed the bug. opencv seems to be fine (still building).


I also rebuilt for gRPC, and I found no failed rebuilds on the 
reverse build dependencies for the same.




Thanks, that means we have to worry about ola and ignition-transport 
only.


Laszlo,

Probably we should ask release team for transition as they take time to 
give us a slot anyway and meanwhile we can try to fix the remaining 
ones.



Thanks and regards
Nilesh

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Bastian Blank  writes:
> On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote:

>> +The Release Team may, at their discretion, downgrade a Policy requirement
>> +to a Policy recommendation for a given release of the Debian distribution.
>> +This may be done for only a specific package or for the archive as a
>> +whole. This provision is intended to provide flexibility to balance the
>> +quality standards of the distribution against the release schedule and the
>> +importance of making a stable release.

> I don't think this aligns to the current release team practice, which
> provides a canonical list of points that are considered policy
> requirements:[1]

> | The purpose of this document is to be a correct, complete and canonical
> | list of issues that merit a "serious" bug under the clause "a severe
> | violation of Debian policy".

It doesn't exactly, although it can if you squint, since effectively the
release team is downgrading all other Policy requirements to Policy
recommendations by not listing them there.

Let me copy the release team.  How would you all prefer to handle the
relationship between release-criticality and Policy requirements?  I don't
think as a project it's ideal to maintain two separate lists of
requirements, but Policy currently doesn't have a nice summary list like
that.

One possible option would be for Policy to take over maintenance of a
summary list of all Policy requirements, and then the release team can
maintain only a list of exceptions for a given Debian release.  Do you
think that might be an improvement?

-- 
Russ Allbery (r...@debian.org)  

Bug#944954: lugin rrdtool failed to handle option DataDir, return code: -1

[Richard Kettlewell]

Package: collectd-core
Version: 5.9.2.g-1

# dpkg --configure collectd-core
Setting up collectd-core (5.9.2.g-1) ...
Job for collectd.service failed because the control process exited with
error code.
See "systemctl status collectd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript collectd, action "start" failed.
● collectd.service - Statistics collection and monitoring daemon
   Loaded: loaded (/lib/systemd/system/collectd.service; enabled; vendor
preset: enabled)
   Active: activating (auto-restart) (Result: exit-code) since Sun
2019-11-17 19:10:08 GMT; 3ms ago
 Docs: man:collectd(1)
   man:collectd.conf(5)
   https://collectd.org
  Process: 22890 ExecStartPre=/usr/sbin/collectd -t (code=exited,
status=0/SUCCESS)
  Process: 22891 ExecStart=/usr/sbin/collectd (code=exited,
status=1/FAILURE)
 Main PID: 22891 (code=exited, status=1/FAILURE)

Nov 17 19:10:08 deodand collectd[22891]: plugin_load: plugin
"write_graphite" successfully loaded.
Nov 17 19:10:08 deodand systemd[1]: Failed to start Statistics
collection and monitoring daemon.
Nov 17 19:10:08 deodand collectd[22891]: Found a configuration for the
`rrdtool' plugin, but the plugin isn't loaded or didn't register a
configuration callback.
Nov 17 19:10:08 deodand collectd[22891]: Plugin rrdtool failed to handle
option DataDir, return code: -1
dpkg: error processing package collectd-core (--configure):
 installed collectd-core package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
 collectd-core

The configuration section for rrdtool is from the default config. This
happens even with LoadPlugin line for rrdtool commented out.

I commented out the  section to work around it.

ttfn/rjk

Bug#838994: Bug#891493: Bug#838994: Bug#891493: unresolved gtk2-engines-murrine situation (was: numix-gtk-theme: Undocumented and very likely also broken Breaks against murrine-themes since 2.6.7-2)

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2019-11-17 at 11:00 +, Mike Gabriel wrote:
> If you plan to drop maintenance sooner or later anyway, then please  
> state that asap (packages are in deferred-15 from today again), so  
> that I can change the uploads and make these bugs go away without  
> introducing a virtual package.

Let's be realistic, I won't have time / priority for those themes, so I'm ok
with dropping maintenance even right now. So go ahead with your preferred
plan.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl3RouwACgkQ3rYcyPpX
RFvuoggAzbl9QuKIg6U3z3qUK1cEn9486QAsCFFqyEkCpU2SdbvN0jQKsU+zlk/P
YeBh80ungay/7cRp3mHX9/HDlJ550PhoiqE3Laj++OOYGC0yzUT+s7ARhwmztpOY
nk3Y3BJ7xZ7zgOgR1JdMO81FbDEx7Qa49epCLjZ+Nmjci4Bwk5CuEIbIn5ujOpqR
zmeyaUSYursxSV0GMNBz5bCMBOjdGbqLUNA/IzlaPCRusdjlUpwJH6NWwdAQbXJ/
XWC9fQiegEIe+9+4fEOZXWPNu4AUQb4gV5fVAh7RWh5y08Va723RqzB11iBBJ247
r4A6B66fyUWKvWOXGyGULm4pHnDRZA==
=vLjy
-END PGP SIGNATURE-

Bug#944953: net-snmp FTCBFS: multiple reasons

[Helmut Grohne]

Source: net-snmp
Version: 5.8+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

net-snmp fails to cross build from source. The immediate failure is when
satisfying Build-Depends. The perl dependency is interpreted as host
architecture and conflicts with the build architecture perl. Looking
closer, net-snmp depends on perl, because it wants to build a perl
extension module. We've introduced a new package perl-xs-dev for that
purpose. This package is temporarily virtual and will become real soon.

The next issue is with detecting mysql. It tries to use mysql_config,
but that doesn't work for cross compilation at all. Since a while mysql
and now mariadb do provide a pkg-config file and using that makes this
part work. The attached patch takes care of not regressing the build by
first trying pkg-config and then falling back to mysql_config.

The third failure is when building the perl extension. It tries to build
the perl extension for the build architecture and consequently fails on
missing dependencies. Niko Tyni has updated debhelper to correctly
invoke a Makefile.PL, but I didn't figure out how to integrate that into
the net-snmp build. The attached patch doesn't address this and net-snmp
keeps failing to cross build.

Please consider applying the attached patch as an incremental step and
close this bug when doing so.

Helmut
diff --minimal -Nru net-snmp-5.8+dfsg/debian/changelog 
net-snmp-5.8+dfsg/debian/changelog
--- net-snmp-5.8+dfsg/debian/changelog  2019-10-22 23:56:17.0 +0200
+++ net-snmp-5.8+dfsg/debian/changelog  2019-11-17 17:02:50.0 +0100
@@ -1,3 +1,12 @@
+net-snmp (5.8+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: (Closes: #-1)
++ Build-Depends: perl-xs-dev for building a perl extension.
++ cross.patch: Detect mysql using pkg-config.
+
+ -- Helmut Grohne   Sun, 17 Nov 2019 17:02:50 +0100
+
 net-snmp (5.8+dfsg-2) unstable; urgency=medium
 
   * All MIB directory values removed and just use the default compile-time
diff --minimal -Nru net-snmp-5.8+dfsg/debian/control 
net-snmp-5.8+dfsg/debian/control
--- net-snmp-5.8+dfsg/debian/control2019-10-22 23:56:17.0 +0200
+++ net-snmp-5.8+dfsg/debian/control2019-11-17 17:02:50.0 +0100
@@ -6,10 +6,10 @@
  Thomas Anders ,
  Noah Meyerhans 
 Build-Depends: debhelper-compat (= 12),
- libtool, libwrap0-dev, libssl-dev, perl (>=5.8), libperl-dev,
+ libtool, libwrap0-dev, libssl-dev, perl:any (>=5.8), perl-xs-dev,
  autoconf, automake, debianutils (>=1.13.1),
  bash (>=2.05), findutils (>=4.1.20), procps,
- pkg-config [kfreebsd-i386 kfreebsd-amd64],
+ pkg-config,
  libbsd-dev [kfreebsd-i386 kfreebsd-amd64],
  libkvm-dev [kfreebsd-i386 kfreebsd-amd64],
  libsensors-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64],
diff --minimal -Nru net-snmp-5.8+dfsg/debian/patches/cross.patch 
net-snmp-5.8+dfsg/debian/patches/cross.patch
--- net-snmp-5.8+dfsg/debian/patches/cross.patch1970-01-01 
01:00:00.0 +0100
+++ net-snmp-5.8+dfsg/debian/patches/cross.patch2019-11-17 
17:02:50.0 +0100
@@ -0,0 +1,36 @@
+--- net-snmp-5.8+dfsg.orig/configure.d/config_os_libs2
 net-snmp-5.8+dfsg/configure.d/config_os_libs2
+@@ -520,12 +520,16 @@
+ ##
+ #   mysql
+ ##
+-if test "x$with_mysql" = "xyes" ; then
+-  AC_PATH_PROGS(MYSQLCONFIG,mysql_config)
+-  test -x "$MYSQLCONFIG" \
++AS_IF([test "x$with_mysql" = "xyes"],[
++  PKG_CHECK_MODULES([MYSQL],[mysqlclient],[
++MYSQL_INCLUDES="$MYSQL_CFLAGS"
++  ],[
++AC_PATH_PROGS(MYSQLCONFIG,mysql_config)
++test -x "$MYSQLCONFIG" \
+   || AC_MSG_ERROR([Could not find mysql_config and was specifically asked 
to use MySQL support])
+-  MYSQL_LIBS=`$MYSQLCONFIG --libs`
+-  MYSQL_INCLUDES=`$MYSQLCONFIG --include`
++MYSQL_LIBS=`$MYSQLCONFIG --libs`
++MYSQL_INCLUDES=`$MYSQLCONFIG --include`
++  ])
+   _libs="${LIBS}"
+   _cppflags="${CPPFLAGS}"
+   LIBS="${LIBS} ${MYSQL_LIBS}"
+@@ -574,9 +578,9 @@
+   CPPFLAGS="${_cppflags}"
+   LIBS="${_libs}"
+   AC_MSG_CACHE_ADD(MYSQL Trap Logging: enabled)
+-else
++],[
+   AC_MSG_CACHE_ADD(MYSQL Trap Logging: unavailable)
+-fi
++])
+ AC_SUBST(MYSQL_LIBS)
+ AC_SUBST(MYSQL_INCLUDES)
+ 
diff --minimal -Nru net-snmp-5.8+dfsg/debian/patches/series 
net-snmp-5.8+dfsg/debian/patches/series
--- net-snmp-5.8+dfsg/debian/patches/series 2019-10-22 23:56:17.0 
+0200
+++ net-snmp-5.8+dfsg/debian/patches/series 2019-11-17 17:02:50.0 
+0100
@@ -31,3 +31,4 @@
 netsnmp_mib_api_3_groff
 snmplib_error_subcontainer
 apps_makefile_use_ldflags
+cross.patch

Bug#944920: Revise terminology used to specify requirements

[Bastian Blank]

On Sun, Nov 17, 2019 at 10:10:11AM -0800, Russ Allbery wrote:
> +The Release Team may, at their discretion, downgrade a Policy requirement
> +to a Policy recommendation for a given release of the Debian distribution.
> +This may be done for only a specific package or for the archive as a
> +whole. This provision is intended to provide flexibility to balance the
> +quality standards of the distribution against the release schedule and the
> +importance of making a stable release.

I don't think this aligns to the current release team practice, which
provides a canonical list of points that are considered policy
requirements:[1]

| The purpose of this document is to be a correct, complete and canonical
| list of issues that merit a "serious" bug under the clause "a severe
| violation of Debian policy".

Bastian

[1]: https://release.debian.org/bullseye/rc_policy.txt
-- 
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3

Bug#944952: libnet-ssleay-perl FTCBFS: perl dependency not installable

[Helmut Grohne]

Source: libnet-ssleay-perl
Version: 1.88-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

Thanks to Niko's work, perl stuff now tends to cross build fairly well.
libnet-ssleay-perl does need a tweak though. It still depends on perl,
which is unsatisfiable unless annotated :native or :any. However,
libnet-ssleay-perl is a perl extension module and therefore needs the
new perl-xs-dev (which will become a real package lateron and is
temporarily provided by libperl-dev). Please consider applying the
attached patch. If libnet-ssleay-perl needs to be backported to stable,
please consider deferring patch application until after bullseye is
released or leaving a comment in debian/control.

Helmut
diff --minimal -Nru libnet-ssleay-perl-1.88/debian/changelog 
libnet-ssleay-perl-1.88/debian/changelog
--- libnet-ssleay-perl-1.88/debian/changelog2019-07-19 03:59:57.0 
+0200
+++ libnet-ssleay-perl-1.88/debian/changelog2019-11-17 12:44:24.0 
+0100
@@ -1,3 +1,10 @@
+libnet-ssleay-perl (1.88-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Update Build-Depends perl -> perl-xs-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 17 Nov 2019 12:44:24 +0100
+
 libnet-ssleay-perl (1.88-1) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libnet-ssleay-perl-1.88/debian/control 
libnet-ssleay-perl-1.88/debian/control
--- libnet-ssleay-perl-1.88/debian/control  2019-07-19 03:59:57.0 
+0200
+++ libnet-ssleay-perl-1.88/debian/control  2019-11-17 12:44:24.0 
+0100
@@ -6,7 +6,7 @@
 Testsuite: autopkgtest-pkg-perl
 Priority: optional
 Build-Depends: debhelper-compat (= 12),
-   perl,
+   perl-xs-dev,
libssl-dev,
libtest-exception-perl ,
libtest-nowarnings-perl ,

Bug#944812: interimap: uninitialized value

[Guilhem Moulin]

On Sun, 17 Nov 2019 at 19:35:51 +0100, Jonas Smedegaard wrote:
> Seems you edited above quote: I had a dot between INBOX and olpc - is 
> that the "typo" you are talking about then the command I ran included 
> that dot (as did the email I sent).

Oh sorry for that, my finger must have ripped as I was replying, and
doveadm-force-resync(1) appears not to complain when the mailbox doesn't
exist :-P
 
>> If it still doesn't work with the right name, here is what I would do if
>> I were you:
>> 
>>   1. ~$ cp /path/to/maildir/.INBOX.olpc /path/to/maildir/.INBOX.olpc.back
>>   2. ~$ rm -vf /path/to/maildir/.INBOX.olpc/dovecot.*
>>   3. Run `doveadm -f flow fetch "uid modseq guid flags text" mailbox 
>> INBOX.olpc | grep -iE "(^| )uid=97( |$)"`
>>  again.
>>   4a. If 3. doesn't match anymore, then `interimap --repair INBOX.olpc`
>>   should be able to reconcile the mailboxes (it'll complain about
>>   missed updates because of the reset HIGHESTMODSEQ, but that's
>>   harmless), and subsequent `interimap --repair INBOX.olpc`
>>   shouldn't spew anny warning.
>>   4b. If 3. still matches, then also remove 
>> /path/to/maildir/.INBOX.olpc/dovecot-uid*
>>   However that will invalidate the UID mapping, so interimap
>>   won't be able to reconcile, you'll need to remove the mailbox
>>   from the database and the local server.
> 
> Not sure what you mean by "doesn't match anymore" - if I understand 
> correctly it didn't match before either.

I mean grep(1) has exit status 1.  At the bottom of 
https://bugs.debian.org/944812#57 you wrote

| jonas@auryn:~$ ssh jonas-deb...@xayide.jones.dk 'doveadm -f flow fetch "uid 
modseq guid flags text" mailbox INBOX.olpc' | grep -iE "(^| )uid=97( |$)"
| doveadm(jonas-debian): Error: net_connect_unix() failed: Connection refused
| doveadm(jonas-debian): Error: fetch(guid) failed for box=INBOX.olpc uid=97: 
Message was expunged
| doveadm(jonas-debian): Error: fetch(text) failed for box=INBOX.olpc uid=97: 
Message was expunged
| uid=97 modseq=1 guid= flags=11662 text=2

Which seems to be the source of the problem (the mail is gone and
doesn't show up when queried specifically, but *does* show up when its
UID is included in a larger range).
 
> I tried now to remove all dovecot.index* files for that Maildir, and (as 
> earlier) the command greps nothing.

Sounds good to me, and hopefully UID 97 no longer show up in
mailbox-wise UID FETCH commands:

b UID FETCH 1:* (MODSEQ FLAGS INTERNALDATE BODY.PEEK[])

If that's indeed the case then the problem seems gone to me.
 
>> Beside that I'm not sure which Dovecot magic could help.  Perhaps double
>> check that all files in that directory look alright?
>> 
>>   find /path/to/maildir/.INBOX.olpc/{cur,new,tmp} -mindepth 1 \
>>   \! -type f -o \! -name "*.M*,S=*"
> 
> That find command finds almost every all mails in that Maildir:

Ah fair enough, I'm not so familiar with the Maildir format, seems like
file names are more diverse than I thought.  At least this one shouldn't
list anything:

find /path/to/maildir/.INBOX.olpc/{cur,new,tmp} -mindepth 1 \! -type f

(I have no idea how Dovecot deals with mails that aren't regular files,
broken symlinks, etc.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#944943: python-freecontact: needs an explicit build dependency on dh-python

[Andreas Tille]

Control: tags -1 moreinfo

Hi Matthias,

On Sun, Nov 17, 2019 at 07:07:32PM +, Matthias Klose wrote:
> Package: src:python-freecontact
> Version: 1.1-5
> Severity: serious
> Tags: sid bullseye
> 
> python3-all and python3-dev now dropped the dependency on
> dh-python:
> 
> [ Piotr Ożarowski ]
>* Remove dh-python dependency from python3-all and python3-dev packages.
>  Packages should build depend on dh-python or dh-sequence-python3 instead.

The package Build-Depends from dh-python since 1.1-5

   https://packages.debian.org/source/unstable/python-freecontact

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#944894: /usr/bin/dh_python2: is a #!/usr/bin/python script but does not depend on python

[Matthias Klose]

On 17.11.19 13:29, Simon McVittie wrote:
> Package: python2
> Version: 2.7.17-1
> Severity: serious
> File: /usr/bin/dh_python2
> Justification: Policy 3.5
> Control: affects -1 src:dbus-python
> 
> As instructed by the py2removal mass-bug-filing templates, I have been
> removing references to python from packages I maintain, and replacing them
> with references to python2 if the Python 2 modules are still needed.
> 
> This seems to have caused dbus-python to FTBFS when NMU'd for the python3.8
> transition:
> 
> https://buildd.debian.org/status/fetch.php?pkg=dbus-python&arch=amd64&ver=1.2.12-1%2Bb1&stamp=1573984727&raw=0
>> Unpacking python2 (2.7.17-1) ...
> ...
>> Unpacking dh-python (4.20191017) ...
> ...
>>debian/rules override_dh_python2
>> make[1]: Entering directory '/<>'
>> py3versions: no X-Python3-Version in control file, using supported versions
>> dh_python2
>> make[1]: dh_python2: Command not found
>> make[1]: *** [debian/rules:214: override_dh_python2] Error 127
> 
> /usr/bin/dh_python2 is in the python2 binary package, which is
> installed, so this "command not found" shouldn't be caused by absence
> of /usr/bin/dh_python2.
> 
> As far as I can work out, it's actually caused by the absence of
> the interpreter named in its first line, which is /usr/bin/python
> (shells do not make it easy to distinguish between these two
> failure modes). dbus-python no longer build-depends on python, so
> /usr/bin/python2.7 and /usr/bin/python2 exist in the build environment,
> but /usr/bin/python does not.
> 
> I think /usr/bin/dh_python2 should now be a #!/usr/bin/python2 (or maybe
> #!/usr/bin/python2.7) script, instead of a #!/usr/bin/python script.

the VCS already has the pending fix to remove dh_python2 from python2.

Bug#944332: debian-policy: Broken markup in policy source

[Russ Allbery]

Control: tags -1 pending

Guillem Jover  writes:

> Found this markup issue while going over the policy:

>   - chapter 4, footnote [6], rendered as:

> ,---
> listed in the :ref:"`Maintainer" <#s-f-Maintainer` or "`Uploaders"
> ` control fields of the package), the first line of
> `---

> source:

> ,---
> :ref:```Maintainer`` <#s-f-Maintainer` or
> ```Uploaders`` ` control fields of the package),
> `---

Thanks, fixed.

-- 
Russ Allbery (r...@debian.org)  

Bug#942415: Calligra and Akonadi

[Pino Toscano]

In data domenica 17 novembre 2019 13:59:59 CET, Sandro Knauß ha scritto:
> thanks for your last update of calligra! That at least makes it build again 
> *yeah* But for me it seems like, the whole Akonadi dependency isn't used at 
> all.

Sure, it is only checked at cmake time, and apparently not actually
used.

> Why this is not built and shipped and still we have the dependency?

I do not see any akonadi dependency in the binary packages, can you
please explain exactly what you see?

> calligra is identified as fake candidate (for the moment) every reverse 
> dependency is built correctly and it is nothing to do left expect for wait 
> till kdepim will go to testing.
> 
> Just for the record, for thise who are not familiar with the other red 
> crosses:
> libkf5sieve, kf5-messagelib, kmail, libkf5mailcommon and kmail can only be 
> built for 5 archs, that are supported by qtwebengine.

This is because the tracker for the transition is partially wrong:
- it considers "affected" all the sources that only build-depend on PIM
  packages: while this is generally correct, it ought to check both the
  actual bad _and_ good runtime dependencies instead
- the "good" check seems correctly checking for the "new library names"
- the "bad" check is basically "everything that does not depend on
  depend on the new names"... which is wrong -- it ought to explicitly
  check for the _old_ names instead
- also I see whitespaces in all the regexps in the HTML page of the
  transition -- not sure whether it is actually like that in the ben
  file, or just a glitch in the HTML page

This would explain why:
- calligra is considered "bad"
- libkf5sieve, kf5-messagelib, kmail, libkf5mailcommon, and kmail are
  considered "bad" in all the architectures where they are not actually
  built
- maybe (although I'm not sure about this) also all the "?!" states

Please fix the ben file for this transition, so its status can be
checked properly.

-- 
Pino Toscano

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

Bug#944928: osmosis ftbfs with protobuf 3.10.1 in experimental

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 11/17/19 7:39 PM, Pirate Praveen wrote:
> This package fail to build with protobuf 3.10.1 in experimental with the
> following failure.

Because the java code needs to be regenerated with protoc 3.10.

> Please fix this failure so we can upload protobuf 3.10 to unstable.

The fix can't be uploaded until 3.10 is in unstable, just like previous
transitions the patched osmosis will be uploaded when the transition starts.

Kind Regards,

Bas

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