Bug#939808: exim4: Very problematic default DKIM_SIGN_HEADERS

[Marc Haber]

tags #939808 upstream
thanks

Hi,

it would probably be a good idea to discuss this with upstream. I don't
think that Debian should do a local patch here.

Greetings
Marc

On Mon, Sep 09, 2019 at 04:10:33AM +0200, Guillem Jover wrote:
> The default DKIM_SIGN_HEADERS macro contains many headers that make
> sending mails to mailing lists or (re)sending mails on someone's
> behalf pretty much infeasible. This has big impact on systems with
> strict DKIM and DMARC policies.
> 
> There are several of the listed fields that are intended to be set by the
> system resending a mail, be that a mailing list or a third-party. If these
> fields are listed in the default set it means any mail going through those
> systems will contain a signature for an empty header, which will then be
> filled and fail signature validatation. Moreover the RFC4871 and RFC6376
> in their §5.4 section mentions that signing missing fields should be done
> carefully.
> 
> Mark Sender and all Resent-* and List-* fields to only be signed if
> present.
> 
> Add also duplicate entries for the From and Subject fields, to reject
> appended fields.
> 
> There's a related write up at
> .
> 
> I'm attaching a patch that should fix this.
> 
> Thanks,
> Guillem

> Description: Fix default DKIM_SIGN_HEADERS macro.
>  There are several of the listed fields that are intended to be set by the
>  system resending a mail, be that a mailing list or a third-party. If these
>  fields are listed in the default set it means any mail going through those
>  systems will contain a signature for an empty header, which will then be
>  filled and fail signature validate. Moreover the RFC4871 and RFC6376 in
>  their §5.4 section mentions that signing missing fields should be done
>  carefully.
>  .
>  Add also duplicate entries for the From and Subject fields, to reject
>  appended fields.
> Author: Guillem Jover 
> Last-Update: 2019-09-08
> 
> 
> ---
>  src/pdkim/pdkim.h |   16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> --- a/src/pdkim/pdkim.h
> +++ b/src/pdkim/pdkim.h
> @@ -26,14 +26,14 @@
>  #include "../blob.h"
>  #include "../hash.h"
>  
> -#define PDKIM_DEFAULT_SIGN_HEADERS "From:Sender:Reply-To:Subject:Date:"\
> - "Message-ID:To:Cc:MIME-Version:Content-Type:"\
> - "Content-Transfer-Encoding:Content-ID:"\
> - "Content-Description:Resent-Date:Resent-From:"\
> - "Resent-Sender:Resent-To:Resent-Cc:"\
> - "Resent-Message-ID:In-Reply-To:References:"\
> - "List-Id:List-Help:List-Unsubscribe:"\
> - 
> "List-Subscribe:List-Post:List-Owner:List-Archive"
> +#define PDKIM_DEFAULT_SIGN_HEADERS \
> +  "From:From:=Sender:Reply-To:Subject:Subject:Date:To:Cc:"\
> +  "Message-ID:In-Reply-To:References:MIME-Version:"\
> +  "Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description:"\
> +  "=Resent-Date:=Resent-From:=Resent-Sender:=Resent-To:=Resent-Cc:"\
> +  "=Resent-Message-ID:"\
> +  "=List-Id:=List-Help:=List-Unsubscribe:=List-Subscribe:=List-Post:"\
> +  "=List-Owner:=List-Archive"
>  
>  /* 
> -- */
>  /* Length of the preallocated buffer for the "answer" from the dns/txt


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#892939: 4.19.0-6

[Torben Schou Jensen]

This error still exist in latest Debian Stable kernel

Linux ci547 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2 (2019-08-28) x86_64
GNU/Linux

Bug#939813: tasksel: selected packages marked for removal on apt full-upgrade

[Jeremy Turnbull]

Package: tasksel
Version: 3.53
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

The real packages that are installed from the metapackages that tasksel uses
will be marked for automatic removal after the next full system upgrade because
neither the metapackages nor the real packages are marked as being manually
installed to apt, and the metapackages are not listed as dependent packages of
tasksel, which is the only one of these packages that is marked as being
manually installed.

After upgrading from Debian 9.9 to 10.1, I had over 300 packages marked to be
automatically removed. Looking through the list, some of them were what I would
consider as "core" packages to my desktop computing environment, packages like
LibreOffice, Firefox, and XFCE. I used 'apt install' to both mark some of these
packages as being manually installed and to ensure that I was not missing any
new, dependent packages. The problem was, I missed that the network-manager
package was also marked as automatically installed and set to be removed, so
after my next 'apt autoremove' and system reboot, my system had no network
connection and was missing a lot of the packages necessary to create one.

Luckily, I still had a Debian 9.5 installation thumb drive lying around and
was able to boot that into rescue mode and inject the network-manager package
into my root filesystem. However, actions such as this or knowing to scrutinize
the list of packages marked for automatic removal are not behaviors that should
be expected of normal users. The list of packages that automatically will be
removed should not break the system or remove core functionality.

If possible, probably the easiest fix would be to ensure that packages tasksel
marks for installation are also marked as being manually installed to apt.


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

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

Versions of packages tasksel depends on:
ii  apt 1.8.2
ii  debconf [debconf-2.0]   1.5.71
ii  liblocale-gettext-perl  1.07-3+b4
ii  perl-base   5.28.1-6
ii  tasksel-data3.53

tasksel recommends no packages.

tasksel suggests no packages.

-- debconf information:
  tasksel/title:
  tasksel/first: desktop, xfce-desktop, print-server, standard
* tasksel/desktop: xfce
  tasksel/tasks:

Bug#807169: README.Debian / advice about plugins

[duck]

Quack,

First, sorry you did not get a reply at the time and thanks for your 
input. I think this is still relevant so I will reply.


On Sun, 06 Dec 2015 13:42:33 +0100 Daniel Pocock wrote:


It seems that a lot of functionality (e.g. tagging, iCalendar support)
is not in Redmine itself and this has to be added using plugins.


There were a few additions but it's still the case for several classical 
features like tags:

 http://www.redmine.org/issues/1448

Could you add some notes about this to README.Debian, the wiki[1] or 
both?


I inherited the redmine maintenance and did not know we had a wiki page. 
It's not in a bad shape but still would need some love, adding to the 
todolist.

Since 3.0 the README.Debian was improved and we'll continue doing so.


- README.Debian already describes setting X_DEBIAN_SITEID for rake
commands. The installation instructions for many plugins (example[2])
recommend running a rake command. Should X_DEBIAN_SITEID be set for
those rake commands and does the rake command need to be run for each
instance? Or is a plugin installation shared between multiple 
instances?


You're right, plugins installation was not documented at all. I added a 
chapter for 4.0.4-3.



- README.Debian gives an example rake command using sudo www-data.
Should plugin installation be run as www-data or as root?


Antonio make a great jobs at modernizing the installation procedure and 
it now uses triggers, so plugin installation does not require to run 
rake commands manually anymore. This is not covered in the new chapter.



- Can you comment on best practices for packaging plugins? As part of
my project, I'm likely to use at least 2 or 3 plugins and would 
probably

like to upload them to Debian.


So with the new system and use of triggers you just need to drop files 
in the plugins/ directory, nothing else.


We've had quite some work around the main package and I still did not 
get time to work on the few packaged plugins. When I get to it I guess I 
could write a few lines in README.Debian about it.



- Can you comment on selection of plugins (and their suitability for
being in Debian)? I notice that many of them appear to be for specific
Redmine versions and discussions in the issue trackers frequently
indicate plugins breaking with newer versions of Redmine or Rails. Is
this likely to be troublesome for supporting packages of the plugins?


Well, in my personal experience with plugins, they do not often survive 
a Debian release time. I guess that's why previous maintainers did not 
packaged many.


The tags absence is not solved in the core and the one you were using 
has not been updated for two years. There is a PR about supporting Rails 
4 and we're already using 5. So I guess it's a good example that even 
when there's a real demand for a feature there's no certitude it's going 
to be maintained.


Currently my only plan is to see if we can have the recaptcha plugin 
back. I don't think this is sustainable to commit to maintain 
non-critical plugins.



- I could also imagine that if some plugin becomes part of core then
people using one of the alternative plugins (e.g. there are several
plugins for tagging right now) might have trouble during a package
upgrade to the version of Redmine where it is part of core. Has anybody
with more experience with Redmine dealt with such situations already 
and

can anybody comment on the impact for people who may contemplate
uploading plugin packages to Debian?


I think upstream is unwilling to add too many big feature to core, so it 
does not seem likely.
Currently the only plugins you cannot remove easily from core are 
gravatar and open_id_authentication.
I've been using Redmine for many years with a handful of plugins and 
never encountered this situation.



- Some other families of packages (e.g. Drupal) have scripts for
automatically creating packages of their plugins (e.g.
dh-make-drupal[3]). Is anybody already working on something like that
for Redmine plugins?


No, but since with the new system there's nothing to do but installing 
files in the right directory, I don't think this is needed anymore.



- If a dh-make-redmine tool was created, it could be interesting to
automatically build an unofficial apt repository of all official 
Redmine

plugins


Not sure. Manual installation is pretty easy in the new system 
(documented in the new chapter too). Also all advertized plugins are not 
in a usable state.



I'll keep this bug open to remind us to add a note about plugin 
packaging and to update the wiki page.


Thanks for your input.
\_o<

--
Marc Dequènes

Bug#939539: docker.io: Failed to start Docker Application Container Engine.

[Felicia P]

$ sudo systemctl status docker.service
● docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Sun 2019-09-08 21:16:42 MST;
58s ago
 Docs: https://docs.docker.com
  Process: 727741 ExecStart=/usr/sbin/dockerd -H fd:// $DOCKER_OPTS
(code=exited, status=1/FAILURE)
 Main PID: 727741 (code=exited, status=1/FAILURE)
  CPU: 165ms

Sep 08 21:16:42 life systemd[1]: Failed to start Docker Application
Container Engine.
Sep 08 21:16:42 life systemd[1]: docker.service: Service
RestartSec=100ms expired, scheduling restart.
Sep 08 21:16:42 life systemd[1]: docker.service: Scheduled restart job,
restart counter is at 3.
Sep 08 21:16:42 life systemd[1]: Stopped Docker Application Container
Engine.
Sep 08 21:16:42 life systemd[1]: docker.service: Start request repeated
too quickly.
Sep 08 21:16:42 life systemd[1]: docker.service: Failed with result
'exit-code'.
Sep 08 21:16:42 life systemd[1]: Failed to start Docker Application
Container Engine.


0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#939494: xdvik-ja: Do not display \includegraphics'ed EPS

[NIDE, Naoyuki]

Bug #939494 can be fixed by the following patch to xdvik-ja.

--- xdvik-ja-22.87.03+j1.42/texk/xdvik/psgs.c.orig  2016-07-14 
20:54:54.0 +0900
+++ xdvik-ja-22.87.03+j1.42/texk/xdvik/psgs.c   2019-09-09 02:53:38.931370029 
+0900
@@ -561,6 +561,11 @@
">> setuserparams .locksafe "
"} stopped pop\n";
 static const char str1[] =
+   "/execute { "
+   "  stopped $error /newerror get and "
+   "   {/handleerror .systemvar exec flush //true} "
+   "   {//false} ifelse pop "
+   "} bind def "
"/xdvi$run {$error /newerror false put {currentfile cvx execute} 
stopped pop} "
"def "
"/xdvi$ack (\347\310\376) def "

The cause of this bug is that gs9.27 has removed a command 'execute' which
xdvi uses to display EPS. It exists in gs9.26, so the combination of
xdvik-ja and gs9.26 does not have this bug.
So, restoring this command can fix this bug.
Thus, another solution of this bug is to apply the following patch
to gs9.27.

--- ghostscript-9.27~dfsg/Resource/Init/gs_init.ps.orig 2019-04-04 
16:41:50.0 +0900
+++ ghostscript-9.27~dfsg/Resource/Init/gs_init.ps  2019-09-09 
04:02:00.870141856 +0900
@@ -531,6 +531,9 @@
 cvx { .runexec } //.execute exec pop
   } loop
 } bind def
+/execute { %  execute -
+  //.execute exec pop
+} bind def
 currentdict /.execute .undef
 
 /filter

Bug#939539: docker.io: Failed to start Docker Application Container Engine.

[Felicia P]

Oops sorry about that.


Sep 08 20:48:33 life systemd[1]: docker.service: Scheduled restart job,
restart counter is at 3.
Sep 08 20:48:33 life systemd[1]: Stopped Docker Application Container
Engine.
Sep 08 20:48:33 life systemd[1]: docker.socket: Succeeded.
Sep 08 20:48:33 life systemd[1]: Closed Docker Socket for the API.
Sep 08 20:48:33 life systemd[1]: Stopping Docker Socket for the API.
Sep 08 20:48:33 life systemd[1]: Starting Docker Socket for the API.
Sep 08 20:48:33 life systemd[1]: Listening on Docker Socket for the API.
Sep 08 20:48:33 life systemd[1]: docker.service: Start request repeated
too quickly.
Sep 08 20:48:33 life systemd[1]: docker.service: Failed with result
'exit-code'.
Sep 08 20:48:33 life systemd[1]: Failed to start Docker Application
Container Engine.
Sep 08 20:48:33 life systemd[1]: docker.socket: Failed with result
'service-start-limit-hit'



0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#932168: Correct version of libc-dev not found on security.debian.org

[Mobile Computing]

The error I encountered was only slightly different, instead of deb9u2, I
got it on deb9u3:

Unable to correct missing packages.
E: Failed to fetch
http://security.debian.org/debian-security/pool/updates/main/l/linux/linux-libc-dev_4.9.168-1+deb9u3_amd64.deb
404 Not Found

The solution I found was to simply change "
http://security.debian.org/debian-security; in sources.list to "
http://deb.debian.org/debian-security;. I do not understand why the URL
alias failed on only this package.

RUN sed -i "s#deb http://security.debian.org/debian-security
stretch/updates main#deb http://deb.debian.org/debian-security
stretch/updates main#g" /etc/apt/sources.list

Thereafter I can build normally.

Bug#939810: dkopp FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

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

dkopp fails to cross build from source, because the upstream Makefile
hard codes the build architcture pkg-config. Please consider applying
the attached patch.

Helmut
--- dkopp-6.5.orig/Makefile
+++ dkopp-6.5/Makefile
@@ -8,6 +8,7 @@
 CXXFLAGS ?= -O2 -Wall -ggdb 
 LDFLAGS ?= -rdynamic -lpthread
 PREFIX ?= /usr
+PKG_CONFIG ?= pkg-config
 
 # target install directories
 BINDIR = $(PREFIX)/bin
@@ -18,8 +19,8 @@
 MANDIR = $(PREFIX)/share/man/man1
 MENUFILE = $(PREFIX)/share/applications/$(PROGRAM).desktop
 
-CFLAGS = $(CXXFLAGS) -c `pkg-config --cflags gtk+-3.0`
-LIBS = `pkg-config --libs gtk+-3.0` -lpthread
+CFLAGS = $(CXXFLAGS) -c `$(PKG_CONFIG) --cflags gtk+-3.0`
+LIBS = `$(PKG_CONFIG) --libs gtk+-3.0` -lpthread
 
 $(PROGRAM): $(PROGRAM).o zfuncs.o
 	$(CXX) $(LDFLAGS) $(PROGRAM).o zfuncs.o $(LIBS) -o $(PROGRAM)  

Bug#939812: ophcrack FTCBFS: uses the build architecture qmake

[Helmut Grohne]

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

ophcrack fails to cross build from source, because it runs the build
architecture qmake. When searching for qmake from autoconf, one should
be using AC_PATH_TOOL to add $ac_tool_prefix, but ophcrack uses
AC_PATH_PROGS and thus searches without $ac_tool_prefix. Please consider
applying the attached patch.

Helmut
--- ophcrack-3.8.0.orig/config/ax_path_qmake5.m4
+++ ophcrack-3.8.0/config/ax_path_qmake5.m4
@@ -22,12 +22,13 @@
 AC_DEFUN([AX_PATH_QMAKE5], [
   ax_guessed_qt5_dirs="/usr/lib/qt5/bin:/usr/local/lib/qt5/bin:/usr/qt5/bin:/usr/local/qt5/bin:${QT5DIR}/bin:${QTDIR}/bin"
   AC_PROG_EGREP
-  AC_PATH_PROGS(_QMAKE5, [qmake-qt5 qmake5], [], ["$PATH:$ax_guessed_qt5_dirs"])
-  AC_PATH_PROGS(_QMAKE, [qmake], [], ["$PATH:$ax_guessed_qt5_dirs"])
+  AC_PATH_TOOL(_QMAKEQT5, [qmake-qt5], [qmake-qt5], , ["$PATH:$ax_guessed_qt5_dirs])
+  AC_PATH_TOOL(_QMAKE5, [qmake5], [qmake5], , ["$PATH:$ax_guessed_qt5_dirs])
+  AC_PATH_TOOL(_QMAKE, [qmake], [qmake], , ["$PATH:$ax_guessed_qt5_dirs])
 
   AC_CACHE_CHECK([for Qt5 version of qmake], ax_cv_path_QMAKE5, [
 ax_cv_path_QMAKE5=no
-for qmake5 in ${_QMAKE5} ${_QMAKE}; do
+for qmake5 in ${_QMAKEQT5} ${_QMAKE5} ${_QMAKE}; do
   if ($qmake5 --version 2>&1 | $EGREP -q 'Qt version 5'); then
 QMAKE5="$qmake5"
 ax_cv_path_QMAKE5="$qmake5"

Bug#939811: fastqtl FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: fastqtl
Version: 2.184+dfsg-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

fastqtl fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so is using dh_auto_build. Even
then it continues to fail, because it invokes architecture-dependent
behaviour of make. As it selects dynamic linking, LIB_TABX becomes -lhts
and when this is used in a Makefile dependency, make fails finding itfor
it on the build architecture. For cross-portable Makefiles -l flags must
not show up in Makefile dependencies. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru fastqtl-2.184+dfsg/debian/changelog 
fastqtl-2.184+dfsg/debian/changelog
--- fastqtl-2.184+dfsg/debian/changelog 2018-07-18 20:55:22.0 +0200
+++ fastqtl-2.184+dfsg/debian/changelog 2019-09-09 06:08:32.0 +0200
@@ -1,3 +1,12 @@
+fastqtl (2.184+dfsg-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Fix Makefile dependencies.
+
+ -- Helmut Grohne   Mon, 09 Sep 2019 06:08:32 +0200
+
 fastqtl (2.184+dfsg-6) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru fastqtl-2.184+dfsg/debian/patches/cross.patch 
fastqtl-2.184+dfsg/debian/patches/cross.patch
--- fastqtl-2.184+dfsg/debian/patches/cross.patch   1970-01-01 
01:00:00.0 +0100
+++ fastqtl-2.184+dfsg/debian/patches/cross.patch   2019-09-09 
06:08:28.0 +0200
@@ -0,0 +1,11 @@
+--- fastqtl-2.184+dfsg.orig/Makefile
 fastqtl-2.184+dfsg/Makefile
+@@ -90,7 +90,7 @@
+ $(LIB_TABX):
+   cd $(PATH_TABX) && make && cd ../..
+ 
+-$(FILE_BIN): $(FILE_O) $(LIB_TABX)
++$(FILE_BIN): $(FILE_O) $(if $(DYNAMIC_LINK),,$(LIB_TABX))
+   $(CXX) $(LDFLAG) $^ $(LIB) -o $@
+ 
+ obj/%.o: %.cpp $(FILE_H)
diff --minimal -Nru fastqtl-2.184+dfsg/debian/patches/series 
fastqtl-2.184+dfsg/debian/patches/series
--- fastqtl-2.184+dfsg/debian/patches/series2018-07-18 20:55:22.0 
+0200
+++ fastqtl-2.184+dfsg/debian/patches/series2019-09-09 06:08:03.0 
+0200
@@ -1,3 +1,4 @@
 01_Makefile_dynamic_hardenings.patch
 02_Replace_libtabix_by_libhts.patch
 03_Reproducible_builds.patch
+cross.patch
diff --minimal -Nru fastqtl-2.184+dfsg/debian/rules 
fastqtl-2.184+dfsg/debian/rules
--- fastqtl-2.184+dfsg/debian/rules 2018-07-18 20:55:22.0 +0200
+++ fastqtl-2.184+dfsg/debian/rules 2019-09-09 06:04:47.0 +0200
@@ -11,7 +11,7 @@
 override_dh_auto_build:
mkdir -p $(CURDIR)/obj/
mkdir -p $(CURDIR)/bin/
-   $(MAKE) CXXFLAGS='$(CXXFLAGS)'
+   dh_auto_build -- CXXFLAGS='$(CXXFLAGS)'
cd $(CURDIR)/example/ && \
tar Jcvf examples.tar.xz * --sort=name --mode=go=rX,u+rw,a-s 
--owner=root --group=root --numeric-owner
 

Bug#848816: dgit: detect gbp export-dir configuration, and prefill build-products-dir

[Sean Whitton]

Hello,

On Sun 08 Sep 2019 at 06:52PM +01, Ian Jackson wrote:

> Sean Whitton writes ("Re: Bug#848816: dgit: detect gbp export-dir 
> configuration, and prefill build-products-dir"):
>> I think you're right, but I think we've discussed this before.  I was in
>> favour of having that config namespace be controlled by src:devscripts,
>> but the devscripts maintainers are not yet on board with that idea, right?
>
> That sounds familiar.
>
> How about the following approach: we post to -devel saying "we need a
> place for Debian build tools to get common stuff, we propose the
> following file in ~ and the following syntax, and we propose that dgit
> contain the registry since devscripts maintainers don't want it".
>
> Open questios then are filename and syntax but maybe -devel can tell
> us what to use.

Let's ask -devel about the idea in general before talking about which
package it might live in, as that's somewhat secondary.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#939629: links2: Problem displaying a websit

[Jean-Philippe MENGUAL]

Package: links2
Version: 2.20.1-1
Followup-For: Bug #939629

Dear Maintainer,

Many thanks for the reply and all you did.

And thanks for Mikulas for feedback on this bug.

I confirm that the solution suggested by Mikulas works properly.  The page is
again displayed.
Do you want me t close this bug?


Many thanks for this marvelous package

Best regards

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

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

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


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

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

Versions of packages links2 depends on:
ii  libbrotli1 1.0.7-2
ii  libbz2-1.0 1.0.8-2
ii  libc6  2.28-10
ii  libcairo2  1.16.0-4
ii  libdirectfb-1.7-7  1.7.7-9
ii  libevent-2.1-6 2.1.8-stable-4
ii  libfontconfig1 2.13.1-2+b1
ii  libfreetype6   2.9.1-4
ii  libglib2.0-0   2.60.6-2
ii  libgomp1   9.2.1-7
ii  libgpm21.20.7-5+b1
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblz1 1.11-4
ii  liblzma5   5.2.4-1+b1
ii  libpng16-161.6.37-1
ii  librsvg2-2 2.44.14-1
ii  libssl1.1  1.1.1c-1
ii  libtiff5   4.0.10+git190818-1
ii  libx11-6   2:1.6.7-1
ii  libzstd1   1.4.3+dfsg-1
ii  zlib1g 1:1.2.11.dfsg-1+b1

Versions of packages links2 recommends:
ii  ca-certificates  20190110
ii  mate-terminal [x-terminal-emulator]  1.22.1-1

links2 suggests no packages.

-- debconf-show failed

Bug#939539: docker.io: Failed to start Docker Application Container Engine.

[Arnaud Rebillout]

On 9/9/19 10:49 AM, Felicia P wrote:

Oops sorry about that.


Sep 08 20:48:33 life systemd[1]: docker.service: Scheduled restart job,
restart counter is at 3.
Sep 08 20:48:33 life systemd[1]: Stopped Docker Application Container
Engine.
Sep 08 20:48:33 life systemd[1]: docker.socket: Succeeded.
Sep 08 20:48:33 life systemd[1]: Closed Docker Socket for the API.
Sep 08 20:48:33 life systemd[1]: Stopping Docker Socket for the API.
Sep 08 20:48:33 life systemd[1]: Starting Docker Socket for the API.
Sep 08 20:48:33 life systemd[1]: Listening on Docker Socket for the API.
Sep 08 20:48:33 life systemd[1]: docker.service: Start request repeated
too quickly.
Sep 08 20:48:33 life systemd[1]: docker.service: Failed with result
'exit-code'.
Sep 08 20:48:33 life systemd[1]: Failed to start Docker Application
Container Engine.
Sep 08 20:48:33 life systemd[1]: docker.socket: Failed with result
'service-start-limit-hit'



Doesn't seem to change anything... You know that after modifying a 
systemd service file, you must reload the systemd daemon, right? Did you 
run `sudo systemctl daemon-reload` before `sudo systemctl restart 
docker.service`?


Can you share again the output of `sudo systemctl status docker.service` 
please, just to make sure?


Thanks!

  Arnaud

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

[Celejar]

Package: firmware-iwlwifi
Version: 20190717-2
Followup-For: Bug #934781

I did some further digging - in my case, at least, the problem seems to
be triggered by some relatively recent kernel change. I combed through
the system journal for the last few months, and the problem first starts
appearing in the logs a few days after I began running kernel 5.2.x
(from 5.2.7 through 5.2.9). Previously, while running 4.19.x, the
problem never appears.

I haven't done a bisection, but it seems pretty clear at this point that
there's a microcode bug that has begun to be triggered by something in
newer kernels.

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.135

-- no debconf information

Bug#939539: docker.io: Failed to start Docker Application Container Engine.

[Arnaud Rebillout]

On 9/9/19 9:59 AM, Felicia P wrote:

   Drop-In: /etc/systemd/system/docker.service.d
    └─override.conf



Please have a look at this file, you probably want to remove it.



  Docs:https://docs.docker.com
   Process: 715918 ExecStart=/usr/sbin/dockerd -H unix:// $DOCKER_OPTS
(code=exited, status=1/FAILURE)



You're still trying to launch docker with a modified command line (ie -H 
unix:// instead of -H fd://), surely due to the override.conf file 
mentioned above.

Bug#939539: docker.io: Failed to start Docker Application Container Engine.

[Felicia P]

Hi Arnaud I removed the custom ExecStart and attempted to restart
docker.  Here is the relevant output from journalctl:


Sep 08 19:04:37 life systemd[1]: Starting Docker Socket for the API.
Sep 08 19:04:37 life systemd[1]: Listening on Docker Socket for the API.
Sep 08 19:04:37 life systemd[1]: docker.service: Start request repeated
too quickly.
Sep 08 19:04:37 life systemd[1]: docker.service: Failed with result
'exit-code'.
Sep 08 19:04:37 life systemd[1]: Failed to start Docker Application
Container Engine.
Sep 08 19:04:37 life systemd[1]: docker.socket: Failed with result
'service-start-limit-hit'.




0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#939539: docker.io: Failed to start Docker Application Container Engine.

[Arnaud Rebillout]

On 9/9/19 9:06 AM, Felicia P wrote:

Hi Arnaud I removed the custom ExecStart and attempted to restart
docker.  Here is the relevant output from journalctl:


Sep 08 19:04:37 life systemd[1]: Starting Docker Socket for the API.
Sep 08 19:04:37 life systemd[1]: Listening on Docker Socket for the API.
Sep 08 19:04:37 life systemd[1]: docker.service: Start request repeated
too quickly.
Sep 08 19:04:37 life systemd[1]: docker.service: Failed with result
'exit-code'.
Sep 08 19:04:37 life systemd[1]: Failed to start Docker Application
Container Engine.
Sep 08 19:04:37 life systemd[1]: docker.socket: Failed with result
'service-start-limit-hit'.



You don't even have logs from the docker daemon itself, meaning it dies 
immediately. If ever it's started.


Can you share the output of the following commands:

  systemctl status docker.service

  cat /lib/systemd/system/docker.service

  cat /etc/default/docker

  ls -l /usr/sbin/dockerd

Thanks

Bug#938823: wicd and Python 3 (was: "wicd" utf8 and too many APs nightmare/bug)

[Axel Beckert]

Hi Guido,

(Cc'ing the according Debian bug report #938823 to get these things
documented publicly.)

Guido Maria Serra wrote:
> hello hello... I patched it to fully work on python3 
> https://github.com/zeph/wicd ...

Thanks! That was a good base to work on.

> how do I package to test it on my system now?

I used
https://github.com/zeph/wicd/compare/49523ed2bd400123ae648170617692d5445be983..49ad8e46536200068d3d9b675d4324986bb392af.patch
as base to patch the existing Debian package, see

https://salsa.debian.org/debian/wicd/commit/6e3055709b11e258ea3881900b93e43c5b46fb35

Had to merge those individual patches into one, though, as dpkg-source
bailed out otherwise:
https://salsa.debian.org/debian/wicd/commit/ea91dc9614d0c2a08726ca4591f4627b214ae3cf

I then had to add these additional changes to get more and more things
working:

Get it build on my system locally:
https://salsa.debian.org/debian/wicd/commit/f69d30b531830e51b466451b0c248851c92ab963

Get it build in a clean chroot:
https://salsa.debian.org/debian/wicd/commit/366807e1c1859462ea2f3a42321ff00abdfd67db

Being able to install the packages:
https://salsa.debian.org/debian/wicd/commit/20901b51930d49ff8b9d84e79c304ac537e1e356

I think most of these three patches needs to be applied to your fork,
too.

Now I'm stuck with this Python error when I run "wicd -c -f":

Traceback (most recent call last):
  File "/usr/share/wicd/daemon/wicd-daemon.py", line 62, in 
from wicd.logfile import ManagedStdio
  File "/usr/lib/python3/dist-packages/wicd/logfile.py", line 32, in 
class LogFile(file):
NameError: name 'file' is not defined

Any idea on how to fix this? "file" is no more an object we can
subclass in Python 3... The failing code seems to be this:
https://salsa.debian.org/debian/wicd/blob/python3/wicd/logfile.py#L32-40

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

Bug#816693: ftp.debian.org: Please add new 'perl6' section

[Guillem Jover]

Hi!

On Fri, 2016-03-04 at 14:02:44 +0100, Dominique Dumont wrote:
> Package: ftp.debian.org
> Severity: wishlist

> rakudo packaging teams is packaging perl6 compiler (rakudo) and
> will package several Perl6 modules packages.
> 
> It would make sense to use a 'perl6' section for all these packages
> instead of the more generic 'interpreters' section.
> 
> Could you add this new section ?

Given the very possible name change of the language, it would be wise
to hold off any such section addition until that has been settled.

For reference .

Thanks,
Guillem

Bug#939809: ftp.debian.org: Please provide more informative NEW graphs

[Guillem Jover]

Package: ftp.debian.org
Severity: wishlist

Hi!

The NEW queue web page points to some graphs about the queue itself
over time . The problem is
that this only shows whether there's been progress as long as there
has been no new uploads, or the processing outpaces the uploading.

It would be really nice to also include in the graphs the amount of
ACCEPTED and REJECTED packages, so that we can improve on the teams
visibility of the work being done, and reduce frustrations with the
queue lenght and state due to the progress being made.

Otherwise if the amount processed and uploaded stays constant there
is the easy first perception of the queue being stuck.

Thanks,
Guillem

Bug#939808: exim4: Very problematic default DKIM_SIGN_HEADERS

[Guillem Jover]

Source: exim4
Source-Version: 4.92.2-2
Severity: important
Tags: patch

Hi!

The default DKIM_SIGN_HEADERS macro contains many headers that make
sending mails to mailing lists or (re)sending mails on someone's
behalf pretty much infeasible. This has big impact on systems with
strict DKIM and DMARC policies.

There are several of the listed fields that are intended to be set by the
system resending a mail, be that a mailing list or a third-party. If these
fields are listed in the default set it means any mail going through those
systems will contain a signature for an empty header, which will then be
filled and fail signature validatation. Moreover the RFC4871 and RFC6376
in their §5.4 section mentions that signing missing fields should be done
carefully.

Mark Sender and all Resent-* and List-* fields to only be signed if
present.

Add also duplicate entries for the From and Subject fields, to reject
appended fields.

There's a related write up at
.

I'm attaching a patch that should fix this.

Thanks,
Guillem
Description: Fix default DKIM_SIGN_HEADERS macro.
 There are several of the listed fields that are intended to be set by the
 system resending a mail, be that a mailing list or a third-party. If these
 fields are listed in the default set it means any mail going through those
 systems will contain a signature for an empty header, which will then be
 filled and fail signature validate. Moreover the RFC4871 and RFC6376 in
 their §5.4 section mentions that signing missing fields should be done
 carefully.
 .
 Add also duplicate entries for the From and Subject fields, to reject
 appended fields.
Author: Guillem Jover 
Last-Update: 2019-09-08


---
 src/pdkim/pdkim.h |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

--- a/src/pdkim/pdkim.h
+++ b/src/pdkim/pdkim.h
@@ -26,14 +26,14 @@
 #include "../blob.h"
 #include "../hash.h"
 
-#define PDKIM_DEFAULT_SIGN_HEADERS "From:Sender:Reply-To:Subject:Date:"\
- "Message-ID:To:Cc:MIME-Version:Content-Type:"\
- "Content-Transfer-Encoding:Content-ID:"\
- "Content-Description:Resent-Date:Resent-From:"\
- "Resent-Sender:Resent-To:Resent-Cc:"\
- "Resent-Message-ID:In-Reply-To:References:"\
- "List-Id:List-Help:List-Unsubscribe:"\
- "List-Subscribe:List-Post:List-Owner:List-Archive"
+#define PDKIM_DEFAULT_SIGN_HEADERS \
+  "From:From:=Sender:Reply-To:Subject:Subject:Date:To:Cc:"\
+  "Message-ID:In-Reply-To:References:MIME-Version:"\
+  "Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description:"\
+  "=Resent-Date:=Resent-From:=Resent-Sender:=Resent-To:=Resent-Cc:"\
+  "=Resent-Message-ID:"\
+  "=List-Id:=List-Help:=List-Unsubscribe:=List-Subscribe:=List-Post:"\
+  "=List-Owner:=List-Archive"
 
 /* -- */
 /* Length of the preallocated buffer for the "answer" from the dns/txt

Bug#939539: docker.io: Failed to start Docker Application Container Engine.

[Arnaud Rebillout]

On 9/6/19 1:21 PM, Felicia wrote:

Package: docker.io
Version: 18.09.5+dfsg1-1
Severity: important

Dear Maintainer,

After a recent upgrade to linux-image-5.2.0-2-amd64 docker no longer starts 
with the following reported by systemd:



  Hi Felicia,

can you give us more logs regarding your issue? Maybe try that:

- stop docker: sudo systemctl stop docker
- watch the logs: journalctl -f
- start docker in another shell: sudo systemctl start docker

Then watch the logs, and if you can't sort it out yourself you can paste 
it here, in case we can help.


FYI I don't see the problem you mention, with the same version of docker 
and the kernel that you have.


  $ dpkg -l | grep -E 'docker.io|linux-image-amd64'
  ii  docker.io    18.09.1+dfsg1-9
  ii  linux-image-amd64    5.2+106~bpo10+1


If I run the following from the command line:

$ sudo /usr/sbin/dockerd -H fd://

it produces the following output:

Failed to load listeners: no sockets found via socket activation: make
sure the service was started by systemd


Indeed, you should start docker using `systemctl start docker`.



According to other forum posts I've read, one recommendation was to
change fd:// to unix://.


Hmm I don't know about that, but I don't think it's a good idea. Things 
should work out of the box.




In order to override the systemd ExecStart command I did:

$ sudo systemctl edit docker.service

and put the following lines in the file:

[Service]
ExecStart=
ExecStart=/usr/sbin/dockerd -H unix:// $DOCKER_OPTS



Please be sure to revert this change to the original value 
"ExecStart=/usr/sbin/dockerd -H fd:// $DOCKER_OPTS", there is really no 
need to modify this line.


Best regards,

  Arnaud

Bug#935443: [PATCH] dgit-maint-bpo(7): Mention occasional need for --new

[Sean Whitton]

Hello,

On Sun 08 Sep 2019 at 06:48PM +01, Ian Jackson wrote:

> Sean Whitton writes ("Re: Bug#935443: [PATCH] dgit-maint-bpo(7): Mention 
> occasional need for --new"):
>> On Thu 05 Sep 2019 at 04:50PM +01, Ian Jackson wrote:
>> > +=head1 GENERAL TIPS
>> > +
>> > +The first time a package is backported
>> > +for any particular Debian release,
>> > +you will have to pass the --new option to dgit.
>> > +
>> >  =head1 CHOOSING BETWEEN THE TWO WORKFLOWS
>> >
>> >  If backporting involves making no (additional) changes to the upstream
>> > @@ -59,8 +65,6 @@ work on machines running Debian stable, it is advisable 
>> > to choose a
>> >  rebasing workflow.  This ensures that dgit can automatically update
>> >  the debian/patches directory without any manual intervention.
>> >
>> > -=head1 TIPS FOR A MERGING WORKFLOW
>> > -
>>
>> Dropping the =head1 here looks to be an error?
>
> Err, yes.  Do you like the rest of the patch ? :-)

The text is fine but I don't think it should be inserted between
TERMINOLOGY and CHOOSING BETWEEN THE TWO WORKFLOWS because those are
meant to be read together.

How about adding the new section before SEE ALSO?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#939789: faketime: Fails to parse "strict" timestamps with error message "Success"(!)

[BenWiederhake.GitHub]

Control: severity -1 minor
Thanks

Hello Wolfgang,

thanks for your quick response!


With your calls, you should not use the '-f' parameter. Without '-f',
the timestamp is passed on to date/gdate for parsing, which yields the
following for me on Debian Buster x86_64:


That changes the behavior: Without '-f', the called program will see
time passing.
In my case the call goes to a build process which takes several seconds,
and the timestamp that I want to influence is taken at the very end of
it.  So without the '-f', the "fake clock" would show a
non-deterministic, and most likely different, time.  That's exactly the
thing that I want to avoid.


https://github.com/wolfcw/libfaketime


Thanks!  I hoped that it could parse the absolute timestamp anyway, but
4b) is clear enough.  Oh well.


I hope that helps a bit.


It does indeed, thank you.  Like I already mentioned, in my case git's
`iso` makes faketime happy, and makes me brush up my knowledge on bash.


I also agree that "Success" isn't much of a useful error message here.
In this case, it's created by a call to the standard perror() system
call, which should be considered to be replaced with something more
meaningful. I'll put that on the todo list. :-) However, more useful
error messages are printed by the wrapper when '-f' is not used.


Sounds good.

So in summary:
- The parsing is "as intended".
- git and faketime have different about "strict ISO date formats".
- The bug is actually only the `: Success` part of the output.
Therefore, the bug is only minor.  Also, I have a manual workaround anyway.

Cheers,
Ben Wiederhake

Bug#939768: gimp: After the last upgrade, GIMP crashes when creating a new image or opening an existing one.

[Asher Gordon]

Package: gimp
Version: 2.10.8-2+b1
Followup-For: Bug #939768

Hello,

I'm also using testing (bullseye) and I can confirm this bug too.

Here's what I think happened:

GIMP 2.10.8-2 was built on sid (which had GEGL 0.4.12 at the
time). Testing also had GEGL 0.4.12, so there was no version mismatch
and everything was fine. Then, GIMP 2.10.8-2+b1 was built on sid, which
now has GEGL 0.4.14. When GIMP 2.10.8-2+b1 (now built against GEGL
0.4.14) migrated to testing (which still has GEGL 0.4.12), the version
mismatch occurred causing the GIMP to crash.

Note that I am just guessing the versions of packages that sid and
testing had in the past, so it should be taken with a grain of salt.

If this is the case, there appears to be three obvious fixes:

1. Migrate GEGL 0.4.14 to testing.
2. Revert the testing GIMP package to 2.10.8-2.
3. Build the testing GIMP package against GEGL 0.4.12.

Since GEGL is 188 days old and should be migrated anyway, 1. seems to be
preferable. Looking at the package tracker [1], it appears that there
are some migration issues that need to be looked at, so perhaps 2. could
be a temporary fix. I'm not sure how 3. would be implemented, since the
sid GIMP package would still need to be built against GEGL 0.4.14.

In the future, care should be taken to avoid GEGL mismatches like this.

By the way, #939754 looks like the same bug.

Hope this helps,
Asher

P.S. I am neither a GIMP developer nor a Debian developer, just an
affected user trying to help.


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

-- 
By necessity, by proclivity, and by delight, we all quote.  In fact, it is as
difficult to appropriate the thoughts of others as it is to invent.
-- R. Emerson
-- Quoted from a fortune cookie program
(whose author claims, "Actually, stealing IS easier.")
[to which I reply, "You think it's easy for me to
misconstrue all these misquotations?!?"  Ed.]

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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.6.1-2
ii  libheif1 1.5.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.0-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-5+b1
ii  librsvg2-2   2.44.14-1
ii  libstdc++6   9.2.1-4
ii  libtiff5 4.0.10+git190818-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-3.1

Versions of packages gimp suggests:
pn  gimp-data-extras  
ii  gimp-help-en [gimp-help]  2.8.2-1
pn  gimp-python   
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information


signature.asc
Description: PGP signature

Bug#939766: [pkg-cryptsetup-devel] Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.

[Guilhem Moulin]

Control: tag -1 moreinfo

Hi,

On Mon, 09 Sep 2019 at 00:53:44 +0200, Alexander Brock wrote:
> but on my machine there is no /bin/libc.so.[0-9.-]+ instead it is in
> /usr/lib/x86_64-linux-gnu.

(I assume you meant ‘/lib.*/libc\.so\.[0-9.-]+’.)  How did you end up
with a system where /lib/*-linux-gnu/libc.so.6 is neither a symlink to a
shared library under /lib nor /usr/lib?  I can't reproduce that with a
clean bullseye nor with an upgrading system from an upgrading system
from a buster netinst.  AFAICT the existing regexp work for these
systems in both normal and ‘usrmerge’ layouts.  This on a sid system
upgraded from buster with a ‘usrmerge’ layout:

root@kvm-10487:~# ldd /sbin/cryptsetup | grep -F libc.so
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f075b205000)
root@kvm-10487:~# readlink -f /lib/*linux-gnu/libc.so*
/usr/lib/x86_64-linux-gnu/libc-2.28.so
root@kvm-10487:~# lsinitramfs /initrd.img | grep libgcc
usr/lib/x86_64-linux-gnu/libgcc_s.so.1

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#939807: sbcl build-depends on package that is cruft in unstable and gone in testing.

[peter green]

Package: sbcl
Version: 2:1.5.6-1
Severity: serious

sbcl build-depends on texlive-generic-recommended which is no longer built by 
texlive-base. The old texlive-generic-recommended is still present in unstable 
as a cruft package, but is completely gone from testing.

Please update your build-dependency to texlive-plain-generic.

Bug#433270: processing

[Jeffrey Cliff]

it's been 4 years since there's been any activity on this oneis anyone
still actually working on it?

Bug#677350: please accept the parenthesed syntax subject(section), e.g. man ls(1)

[Colin Watson]

Control: tag -1 fixed-upstream

On Sat, Apr 28, 2018 at 06:26:03AM +0800, Paul Wise wrote:
> On Wed, 13 Jun 2012 12:32:04 +0100 Colin Watson wrote:
> > Is it still worth it if you have to go to the effort of quoting it
> > anyway?
> 
> Yes, it is much easier to type two quote characters and paste in the
> middle of them than to paste then mangle to one of the accepted forms:

OK, fair enough.  I've implemented this for the next upstream release:

  
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=7859173c3e6d8d858cc0a5009bdf68d1c2725093

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#939096: RFS: oomd/0.1.0-1 [ITP] -- userspace Out-Of-Memory (OOM) killer for Linux systems

[Paul Wise]

On Sun, Sep 8, 2019 at 9:51 PM Yangfl wrote:

> https://www.debian.org/doc/debian-policy/ch-opersys.html says "The
> default behaviour is to enable autostarting your package’s daemon",
> IIUC.

Apologies for not making it clear but my message was about the
situation where a daemon needs configuration before it can be started.
I'm glad that is now not the case for oomd.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#939717: [PATCH] Workaround invalid characters provided during installation

[David Prévot]

Hi Wolfgang,

Le 08/09/2019 à 07:39, Wolfgang Schweer a écrit :
> On Sat, Sep 07, 2019 at 10:36:10PM -1000, David Prévot wrote:

> I've checked the patch via running 'cf-agent -I -Dinstallation,di' on 
> the main server. As far as I can tell, another change is needed to get a 
> valid workaround:

Thank you for checking and pointing a way to reproduce (I didn’t tag
that bug as patch, as I wasn’t yet able to reproduce it outside d-i,
just trying to find an easy workaround as a first debugging step).

> Please note that running 'ldap-debian-edu-install' via cf-agent (in 
> finish_install) causes the problem.

Thank you for narrowing down!

> I guess for a proper fix it would be needed to figure out how cf-agent 
> is involved here.

nods (trying to find if it behaves as if the sting was seen as a
non-UTF8 string in an UTF-8 environment maybe).

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#939690: libasound2-plugins:amd64: HDMI plugin missing

[Elimar Riesebieter]

* Simon Richter  [2019-09-07 22:53 +0200]:

> Package: libasound2-plugins
> Version: 1.1.8-1
> Severity: normal
> 
> Hi,
> 
> aplay -L reports that I have two HDMI audio channels:
> 
> hdmi:CARD=PCH,DEV=0
> HDA Intel PCH, HDMI 0
> HDMI Audio Output
> hdmi:CARD=PCH,DEV=1
> HDA Intel PCH, HDMI 1
> HDMI Audio Output
> 
> That is indeed correct, but trying to use them I end up with
> 
> alsa-lib: dlmisc.c:287:(snd1_dlobj_cache_get) Cannot open shared library
>   /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_hdmi.so ((null):
>   /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_hdmi.so: cannot
>   open shared object file: No such file or directory)
> 
> It seems the plugin is missing here. The normal audio device works in some
> configurations, but has no information on the capabilities of the connected
> device.

AFAIK libasound_module_pcm_hdmi.so isn't distributed from alsa. Do
you have a ~/.asoundrc? If yes, how does it lokk like?

Elimar
-- 
  Do you smell something burning or is it me?

Bug#939748: Additional information.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It is sad to see this. It is the same reason that I refuse to use GTK3.

I hope that you can contact upstream to preserve bitmaps. Or at least compile a 
separate package with bitmap support.
The problem is that most TrueType fonts are rendered poorly unless you have a 
high-DPI/"retina" display, which most people do not have.
Also, remember that embedded devices usually have low-resolution screens (like 
128*128 or 64*64).
If you enable antialiasing you get blurry texts. If you disable antialiasing 
you get out-of-shape texts.
Bitmap fonts have no such problems because they are pixel-perfect and does not 
require antialiasing if a fixed font size is specified (which in most cases is).
Last but not least, bitmap fonts are easy to edit, unlike TrueType fonts.
Also, not everyone uses a DE like GNOME. I (and many people) use WMs like i3 
and TWM because they use fewer resources and has fewer distractions.
If I use a minimal WM and I use the terminal all day long, obviously I want the 
UI font to be the same as the terminal font.
-
Please limit your reply to 7-bit ASCII.
I refuse to see your idiotic emoji in a TTY.
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBcBAEBCAAGBQJddYolAAoJENi1YDlFXXQf9nMIAIiZ8obxAUt4faKEnwEp
zmHmAY1bydH/yWRzxqZ5WGu1BiWkna0tPL2dIuPA0dp2W1rPMR5YnrkbaKca
c1H17Y9XeayOhs1GObEEihmORJiEuYwfhFS5LLT9emRS/fd0NfwtrRZU1+iY
ytZaO8RU11larzPPzLCHDnGoGGf61q61/+dDA7vDbYVVQ4tlunkQd/pFdqEm
Ye4TbW7En3I4tm/n6unv3sIjCbMbTJn62ECs0KbmaI33u3iXYB8Xq5pBVKbU
cSJqCOQb3JEKONt2TZKY8v8Ohuclf2ri6ZAQjV1zzHQ9Tx9NcVNhJK8a40jI
Dx135xocUWvsunBnYiA+/Io=
=SHFu
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#939768: gimp: After the last upgrade, GIMP crashes when creating a new image or opening an existing one.

[japers]

Package: gimp
Version: 2.10.8-2+b1
Followup-For: Bug #939768

Dear Maintainer,

   * What led up to the situation?
Any attempt to open or create an image file results in segmentation
fault and exit from the software.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
No attempt to open any kind of image on my system resulted in anything
but segmentation fault and exit from the software.




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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.6.1-2
ii  libheif1 1.5.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.0-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-5+b1
ii  librsvg2-2   2.44.14-1
ii  libstdc++6   9.2.1-4
ii  libtiff5 4.0.10+git190818-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-3.1

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1
ii  gimp-help-en [gimp-help]  2.8.2-1
ii  gimp-python   2.10.8-2+b1
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information

Bug#939715: manual upgrades prevented

[Matthias Klumpp]

Am So., 8. Sept. 2019 um 20:21 Uhr schrieb Karsten :
>
> Am 08.09.19 um 19:28 schrieb Lisandro Damián Nicanor Pérez Meyer:
> > Please ru it again with:
> > LANG=C aptitude update
> >
> > And re send the output. We don't read german :-)
> >
> > Thanks!
>
> Yes - that's of course correct.
> But i am to lazy now and just use an translator. :-)

The lock should only be held for a brief period of time - is this
persistent for a longer time (like, 5min when Discover isn't actually
performing any update)?
Otherwise this wouldn't be a bug, but actual intended behavior (when
checking for updates, the APT cache has to be locked, of course).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#939737: emacs: please package newer release 26.3

[Rob Browning]

"Héctor Orón Martínez"  writes:

> Package: emacs
> Version: 1:26.1+1-3.3
> Severity: wishlist
>
> Dear Maintainer,
>
>   Please consider packaging newer emacs 26.3 release:
> https://lists.gnu.org/archive/html/emacs-devel/2019-08/msg00577.html

It's in progress, but right now I'm working on the EPLA cert epiration
problem for buster and sid, then I'll resume 26.3.


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

Bug#939766: cryptsetup-initramfs: Trying to boot linux-image-5.2.0-2-amd64 fails, linux-image-4.19.0-5-amd64 works.

[Alexander Brock]

I searched for clues why that libgcc_s.so.1 is not added and found the
script:
/usr/share/initramfs-tools/hooks/cryptroot

it contains the line:

LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* =>
(/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"

but on my machine there is no /bin/libc.so.[0-9.-]+ instead it is in
/usr/lib/x86_64-linux-gnu. Therefore $LIBC_DIR is empty which leads to
the "find: ‘’: No such file or directory" error message in the log
(https://paste.debian.net/1099530/)

Allowing any number of characters before the /lib fixes the problem:

LIBC_DIR="$(ldd /sbin/cryptsetup | sed -nr 's#.* =>
(.*/lib.*)/libc\.so\.[0-9.-]+ \(0x[[:xdigit:]]+\)$#\1#p')"

I changed this and now the 5.2 kernel boots again. I made a merge
request:
https://salsa.debian.org/cryptsetup-team/cryptsetup/merge_requests/10

Bug#935578: [Pkg-rust-maintainers] Bug#935578: bat: bacula-console-qt already ships /usr/sbin/bat (and /usr/share/man/man1/bat.1.gz)

[Paride Legovini]

Andreas Beckmann wrote on 24/08/2019:
> Package: bat
> Version: 0.11.0-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install
> because it tries to overwrite other packages files.
> 
> Since /usr/sbin/bat is already provided by another package, you can't
> ship a different binary as /usr/bin/bat.
> I noticed this by the clash on the manpage.
> 
> From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package bat.
>   Preparing to unpack .../11-bat_0.11.0-2_amd64.deb ...
>   Unpacking bat (0.11.0-2) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-xqEwrF/11-bat_0.11.0-2_amd64.deb (--unpack):
>trying to overwrite '/usr/share/man/man1/bat.1.gz', which is also in 
> package bacula-console-qt 9.4.4-2+b1
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-xqEwrF/11-bat_0.11.0-2_amd64.deb

:(

Thanks Andreas for the heads-up, I missed this name clash. I knew tat
the 'bat' binary name and manpage were taken by the bareos-bat package
up to Buster. That package has now been dropped, and I happily packaged
'bat' without renames, as I didn't know that bacula-console-qt was
installing those files too; bareos-bat had a Conflits/Replaces on
bacula-console-qt, so there was no name clash in that case.

I guess I'll have to rename some files here. This isn't obvious at the
moment as the build dependencies for rust-bat are not satisfied in unstable.

Paride

Bug#939805: painintheapt with only pubsub configured does not work

[Kim Alvefur (Zash)]

Package: painintheapt
Version: 0.20181201-1
Severity: normal

Dear Maintainer,

If configured with pubsub_service and pubsub_node then painintheapt
prints "xep_0060" and exits with status code 1.


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

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

Versions of packages painintheapt depends on:
ii  python3  3.7.3-1
ii  python3-apt  1.8.4
ii  python3-prettytable  0.7.2-4
ii  python3-sleekxmpp1.3.3-4

painintheapt recommends no packages.

Versions of packages painintheapt suggests:
ii  cron [cron-daemon]  3.0pl1-134

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

-- no debconf information

Bug#863920: man -d -l : too many irrelevant lines are output

[Colin Watson]

Control: tag -1 fixed-upstream

On Thu, Jun 01, 2017 at 11:48:38PM +, Bjarni Ingi Gislason wrote:
>   about the output of "man -d -l ".
> 
>   The location of the  is already known.
> 
>   There are so many irrelevant lines about where the location of the input
> file could be, that it makes it more difficult and time consuming to spot
> relevant lines.

Most of this is from parsing the configuration file.  man still has to
do this and determine the manpath even in the -l case, and it's not
irrelevant.  While it's true that the location of the manual page is
*usually* known, that isn't always so: if you give "man -l" a full path
to an executable then it will try to look up the executable's name in
the appropriate parts of the manpath on the basis that that's more
likely to be helpful than spewing binary data all over your screen; and
of course we also need things like pager configuration that may be set
in the configuration file.

That said, it's certainly true that the debugging output was less tight
than it could have been: I want to keep enough in there to allow me to
still be able to diagnose users' problems effectively, but it could be
rather less redundant.  I've pushed a couple of commits upstream that
make it substantially shorter and less noisy:

  
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=84b6f4457e5ee1c6372ca60c303ad9c71b5f6d27
  
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=6580d8cd2e72ac6df1f0bb6f6876e80bca9fded3

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#880380: Salsa MR

[Melvin Vermeeren]

Submitted MR to salsa that should fix this. I can't reproduce the error any 
more after installing this fix on a server that had the issue before, though I 
cannot say with 100% certainty every possible way to trigger the bug are 
handled by these 2 backported commits.

https://salsa.debian.org/horde-team/php-horde-db/merge_requests/2

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

Bug#939804: erlang: FTBFS on hppa - escript: exception error: bad argument

[John David Anglin]

Source: erlang
Version: 1:20.3.8.8+dfsg-1
Severity: normal

Dear Maintainer,

Since version 1:20.3.8.8+dfsg-1, erlang has failed to build on hppa.  It
fails with a bad argument exception running escript:

escript /<>/lib/erl_docgen/priv/bin/github_link.escript 
diameter_codec.xml \
"lib/diameter/doc/src/diameter_codec.xml" "NA" ../xml/diameter_codec.xml
escript: exception error: bad argument
  in function  re:split/3
 called as re:split(<<"\ndiameter_dict(4)'>\n  
>,
"\n",[])
escript: exception error: bad argument
  in function  re:split/3
 called as re:split(<<"\ndictionary file'>\n  >,
"\n",[])
make[1]: *** [/<>/make/otp_release_targets.mk:47: 
../xml/diameter_codec.xml] Error 127
make[1]: *** Waiting for unfinished jobs

I've tried to debug this error but so far I haven't had much luck.  There
is a hppa porter box.

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 4.14.142+ (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#939798: floppy support in d-i [Was: Re: Bug#939798: kickseed: remove floppy support]

[John Paul Adrian Glaubitz]

On 9/8/19 11:43 PM, Holger Wansing wrote:

I assume, this bugreport was motivated by bug #880122 by Chris Lamb from 2017,
which proposed to remove floppy support from hw-detect package, since
floppies appear to no longer be widely used for ages:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880122


The same bugreport made me working on preparations for removing floppy support
from debian-installer templates recently:
https://lists.debian.org/debian-boot/2019/09/msg00057.html


(...)


With this "Debian Ports" argumentation, we need a discussion on this topic
first, as it seems.


The standard floppy driver in the kernel just recently got a new maintainer [1]
and Linus underlined that the floppy driver is still useful for virtualization
environments (I can't find the LKML post at the moment).

It's super easy to create a floppy image with just the dd tool and use it in
qemu or on servers.

Please do not assume that all users are just on x86 laptops with no optical
drives or floppy drives. I know that a lot of people don't use optical or
floppy media anymore, but that doesn't mean there is still a use case for it.

Like with serial connections, floppy drives are simple enough that they work
in basically every environment, so having them as a simple fallback is
incredibly useful and unless there is a very good reason for removing floppy
support - i.e. code that is broken or blocks other new code - I'm objecting
to removing floppy support and would be willing to take care of it.

Thanks,
Adrian


[1] https://lkml.org/lkml/2019/7/31/771


--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#936036: fd-find: shell completion does not works

[Paride Legovini]

On Thu, 29 Aug 2019  wrote:> Shell
completion does not work (tested in zsh and bash), because of the
> executable name in Debian (fdfind and not fd as in upstream).
> I have completion when i type fd (which is a command not found), but nothing
> with fdfind.

Thanks for your report. This is easy to fix in principle, but as some
other packages have been upgraded fd-find is now missing some versioned
build-dependencies. A new upload will require some patching and updating
other packages first.

Paride

Bug#898949: schroot: PAM config should use common-session-noninteractive

[Roger Leigh]

On 07/09/2019 10:30, Simon McVittie wrote:


On Thu, 17 May 2018 at 19:36:11 +0200, Ansgar Burchardt wrote:

On systems with libpam-systemd installed using common-session will
create a logind session which schroot should not do.

In particular, creating a logind session results in $XDG_RUNTIME_DIR
being set inside the chroot, to a path that only exists outside the chroot.


Should this path be bound into the chroot?

Which Debian version introduced common-session-noninteractive?


Regards,

Roger

Bug#939803: RM: netanim -- RoQA; depends on qt4, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove netanim. The package in the archive was a single upload
back in 2012 and no followup to any of the bugs. Current upstream
releases are compatible with Qt5, but the version in the archive
still uses Qt4, which is going away.

Cheers,
Moritz

Bug#939770: wireshark: Wrong path in pre-install notification

[Balint Reczey]

Hi Justin,

On Sun, Sep 8, 2019 at 11:48 PM Justin B Rye  wrote:
>
> Balint Reczey wrote:
> >> I suggest to change path in the question and make it clear that the
> >> file will only exist after the package is installed – even though a
> >> text mentioning it might be shown before installation is completed.
>
> Thanks for taking the trouble to deal with this!  The patch would work
> as it is, but I've thought of another complication: I might be reading
> this template when no package installation is occurring.  For a start,
> I might give an answer, wait for wireshark to be installed, read the
> README file, and then decide to run "dpkg-reconfigure wireshark" to
> get the same prompt again and give a different answer...
>
> So instead of saying "after the package installation is finished" you
> might change it to something like:
>
>   For more detailed information please see
> - /usr/share/doc/wireshark-common/README.Debian.
> + /usr/share/doc/wireshark-common/README.Debian.gz once the package is
> + installed.

Good point. Can I apply this change as the one reviewed?

Cheers,
Balint

>
> --
> JBR with qualifications in linguistics, experience as a Debian
> sysadmin, and probably no clue about this particular package



-- 
Balint Reczey
Ubuntu & Debian Developer

Bug#880380: Problematic in buster

[Melvin Vermeeren]

Buster ships with postgresql 11 and this problem is currently experienced in 
stable production systems. Although it appears upstream has fixed this by now 
they have never released a new version containing the fix, 2.4.0 is broken.

See also a similar bug in fedora[1] and the commit references there[2][3], 
which should likely be backported into buster.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1721458
[2] https://github.com/horde/Db/commit/
8819f8708acac4684e58d70241e8442f1696347b
[3] https://github.com/horde/Db/commit/
f50a0b03d2688b1b9dbd78b9aa64c594bcb93d79

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

Bug#939802: buster-pu: package guile-2.2/2.2.4+1-2

[Rob Browning]

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

This should fix the FTBFS that's already been fixed in sid.

diff -Nru guile-2.2-2.2.4+1/debian/changelog guile-2.2-2.2.4+1/debian/changelog
--- guile-2.2-2.2.4+1/debian/changelog	2019-06-02 11:17:15.0 -0500
+++ guile-2.2-2.2.4+1/debian/changelog	2019-09-08 15:22:44.0 -0500
@@ -1,3 +1,10 @@
+guile-2.2 (2.2.4+1-2+deb10u1) buster; urgency=medium
+
+  * Switch to dh_missing and ignore guile-X.Y for binary-indep.  Thanks to
+Santiago Vila for reporting the problem. (Closes: 930774)
+
+ -- Rob Browning   Sun, 08 Sep 2019 15:22:44 -0500
+
 guile-2.2 (2.2.4+1-2) unstable; urgency=medium
 
   * Backport upstream fix for after-gc-hook test failures.  Replace
diff -Nru guile-2.2-2.2.4+1/debian/rules guile-2.2-2.2.4+1/debian/rules
--- guile-2.2-2.2.4+1/debian/rules	2019-06-02 11:17:15.0 -0500
+++ guile-2.2-2.2.4+1/debian/rules	2019-09-08 15:22:01.0 -0500
@@ -231,7 +231,8 @@
 
 override_dh_install-arch: $(autogen_install_files)
 	cd debian/tmp/usr/bin && mv -i guile-$(deb_src_eff_ver) guile
-	dh_install -a --fail-missing \
+	dh_install -a
+	dh_missing -a --fail-missing \
 	  -Xusr/lib/$(march)guile/$(deb_src_eff_ver)/extensions/guile-readline.a \
 	  -Xusr/lib/$(march)guile/$(deb_src_eff_ver)/extensions/guile-readline.la
 	test -e $(gdb_ext)
@@ -242,7 +243,9 @@
 # Glob should match the one in debian/guile-doc.install
 	test "$(sort $(expected_info))" = \
 	  "$(sort $(shell cd debian/tmp/usr/share/info && ls guile.info*))"
-	dh_install -i --fail-missing \
+	dh_install -i
+	dh_missing -i --fail-missing \
+	  -Xusr/bin/guile-$(deb_src_eff_ver) \
 	  -Xusr/share/info/dir \
 	  -Xusr/share/info/r5rs.info \
 	  -Xusr/lib/$(march)guile/$(deb_src_eff_ver)/extensions/guile-readline.a \

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

Bug#939801: xtables-addons-source: xtables-addons-2.12.0 fails to compile (kernel 5.2.0-0.bpo.2-amd64)

[Olaf Martens]

Package: xtables-addons-source
Version: 2.12-0.1
Severity: serious
Justification: Policy 4.15

Dear maintainer,

whenever attempting to compile xtables-addons-dkms, the following occurs
reproducibly:

root@h2182426:/var/lib/dkms/xtables-addons/2.12/build# make
make  all-recursive
make[1]: Verzeichnis „/var/lib/dkms/xtables-addons/2.12/build“ wird betreten
Making all in extensions
make[2]: Verzeichnis „/var/lib/dkms/xtables-addons/2.12/build/extensions“ wird 
betreten
Xtables-addons 2.12 - Linux 5.2.9
if [ -n "/lib/modules/5.2.0-0.bpo.2-amd64/build" ]; then make -C 
/lib/modules/5.2.0-0.bpo.2-amd64/build 
M=/var/lib/dkms/xtables-addons/2.12/build/extensions modules; fi;
make[3]: Verzeichnis „/usr/src/linux-headers-5.2.0-0.bpo.2-amd64“ wird betreten
  CC [M]  /var/lib/dkms/xtables-addons/2.12/build/extensions/pknock/xt_pknock.o
/var/lib/dkms/xtables-addons/2.12/build/extensions/pknock/xt_pknock.c: In 
function ‘add_rule’:
/var/lib/dkms/xtables-addons/2.12/build/extensions/pknock/xt_pknock.c:472:2: 
error: implicit declaration of function ‘init_timer’; did you mean 
‘init_timers’? [-Werror=implicit-function-declaration]
  init_timer(>timer);
  ^~
  init_timers
/var/lib/dkms/xtables-addons/2.12/build/extensions/pknock/xt_pknock.c:473:23: 
error: assignment to ‘void (*)(struct timer_list *)’ from incompatible pointer 
type ‘void (*)(long unsigned int)’ [-Werror=incompatible-pointer-types]
  rule->timer.function = peer_gc;
   ^
/var/lib/dkms/xtables-addons/2.12/build/extensions/pknock/xt_pknock.c:474:13: 
error: ‘struct timer_list’ has no member named ‘data’
  rule->timer.data = (unsigned long)rule;
 ^
/var/lib/dkms/xtables-addons/2.12/build/extensions/pknock/xt_pknock.c: In 
function ‘xt_pknock_mt_init’:
/var/lib/dkms/xtables-addons/2.12/build/extensions/pknock/xt_pknock.c:1138:13: 
error: ‘struct shash_desc’ has no member named ‘flags’
  crypto.desc.flags = 0;
 ^
cc1: some warnings being treated as errors
make[7]: *** 
[/usr/src/linux-headers-5.2.0-0.bpo.2-common/scripts/Makefile.build:290: 
/var/lib/dkms/xtables-addons/2.12/build/extensions/pknock/xt_pknock.o] Fehler 1
make[6]: *** 
[/usr/src/linux-headers-5.2.0-0.bpo.2-common/scripts/Makefile.build:494: 
/var/lib/dkms/xtables-addons/2.12/build/extensions/pknock] Fehler 2
make[5]: *** [/usr/src/linux-headers-5.2.0-0.bpo.2-common/Makefile:1610: 
_module_/var/lib/dkms/xtables-addons/2.12/build/extensions] Fehler 2
make[4]: *** [Makefile:179: sub-make] Fehler 2
make[3]: *** [Makefile:8: all] Fehler 2
make[3]: Verzeichnis „/usr/src/linux-headers-5.2.0-0.bpo.2-amd64“ wird verlassen
make[2]: *** [Makefile:463: modules] Fehler 2
make[2]: Verzeichnis „/var/lib/dkms/xtables-addons/2.12/build/extensions“ wird 
verlassen
make[1]: *** [Makefile:496: all-recursive] Fehler 1
make[1]: Verzeichnis „/var/lib/dkms/xtables-addons/2.12/build“ wird verlassen
make: *** [Makefile:381: all] Fehler 2

Kind regards,

Olaf Martens

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

Kernel: Linux 5.2.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.utf8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to 
de_DE.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages xtables-addons-source depends on:
ii  bzip2 1.0.6-9.2~deb10u1
ii  debhelper 12.1.1
ii  iptables-dev  1.8.3-2~bpo10+1
ii  make  4.2.1-1.2
ii  pkg-config0.29-6

Versions of packages xtables-addons-source recommends:
ii  module-assistant  0.11.10

xtables-addons-source suggests no packages.

-- no debconf information

Bug#939539: Bug 939539

[Felicia P]

I forgot to mention I also did:

$ sudo apt remove --purge docker.io
$ sudo rm -rf /var/lib/docker
$ sudo apt install docker.io

To make sure it was a clean installation





0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#939797: Remove Bug 939797

[Felicia P]

Please remove this bug. 

There is an option in Settings -> Configure Dolphin -> Startup -> Show
filter bar which resolves this issue



0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#939798: floppy support in d-i [Was: Re: Bug#939798: kickseed: remove floppy support]

[Holger Wansing]

Hi Adrian,

John Paul Adrian Glaubitz  wrote:
> On 9/8/19 10:53 PM, Miguel Figueiredo wrote:
> > Package: kickseed
> > tags: patch
> > 
> > in attachment, patch to remove floppy support from the kickseed package.
> 
> Why does floppy support need to be removed? It might be usable for any of
> the architectures we use in Debian Ports like m68k or powerpc.
> 
> Unless there is a compelling reason to remove it, I would rather keep
> floppy support.

I assume, this bugreport was motivated by bug #880122 by Chris Lamb from 2017,
which proposed to remove floppy support from hw-detect package, since
floppies appear to no longer be widely used for ages:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880122


The same bugreport made me working on preparations for removing floppy support 
from debian-installer templates recently:
https://lists.debian.org/debian-boot/2019/09/msg00057.html


With this "Debian Ports" argumentation, we need a discussion on this topic
first, as it seems.


@debian-boot team:
How to deal with floppy support these days?



Holger


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

Bug#939539: Bug 939539

[Felicia P]

If I run the following from the command line:

$ sudo /usr/sbin/dockerd -H fd://

it produces the following output:

Failed to load listeners: no sockets found via socket activation: make
sure the service was started by systemd

According to other forum posts I've read, one recommendation was to
change fd:// to unix://.  If I do that then it appears to initialize but
then fails with the following output:

Error starting daemon: Devices cgroup isn't mounted


In order to override the systemd ExecStart command I did:

$ sudo systemctl edit docker.service

and put the following lines in the file:

[Service]
ExecStart=
ExecStart=/usr/sbin/dockerd -H unix:// $DOCKER_OPTS





0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#939770: wireshark: Wrong path in pre-install notification

[Justin B Rye]

Balint Reczey wrote:
>> I suggest to change path in the question and make it clear that the
>> file will only exist after the package is installed – even though a
>> text mentioning it might be shown before installation is completed.

Thanks for taking the trouble to deal with this!  The patch would work
as it is, but I've thought of another complication: I might be reading
this template when no package installation is occurring.  For a start,
I might give an answer, wait for wireshark to be installed, read the
README file, and then decide to run "dpkg-reconfigure wireshark" to
get the same prompt again and give a different answer...

So instead of saying "after the package installation is finished" you
might change it to something like:

  For more detailed information please see
- /usr/share/doc/wireshark-common/README.Debian.
+ /usr/share/doc/wireshark-common/README.Debian.gz once the package is
+ installed.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- debian_templates.txt.old	2019-09-08 22:33:54.100118962 +0100
+++ debian_templates.txt	2019-09-08 22:37:02.834579867 +0100
@@ -17,7 +17,8 @@
  less of the code will run with elevated privileges.
  .
  For more detailed information please see
- /usr/share/doc/wireshark-common/README.Debian.
+ /usr/share/doc/wireshark-common/README.Debian.gz once the package is
+ installed.
  .
  Enabling this feature may be a security risk, so it is disabled by
  default. If in doubt, it is suggested to leave it disabled.

Bug#934665: upload grpc and protobuf to unstable

[GCS]

On Sun, Sep 8, 2019 at 3:03 PM Pirate Praveen  wrote:
> Now autopkgtest results for packages in experimental is also available.
>
> See https://release.debian.org/britney/pseudo-excuses-experimental.html
>
> Migration status for protobuf (3.6.1.3-2 to 3.9.1-2): BLOCKED: 
> Rejected/violates migration policy/introduces a regression
 All of these are expected. Need to transition (rebuild) these with
the Protobuf 3.9.1 version. But as the 3.10.0 release is around the
corner, I plan to package its RC release tomorrow.

Regards,
Laszlo/GCS

Bug#936045: Can not reproduce anymore ...

[Dietz Proepper]

As in the subject - my bt headset now works with 12.99.2-1.

Can someone close that bug?

Regards,
Dietz

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

Bug#862751: updated repository link

[Jeffrey Cliff]

https://codeberg.org/themusicgod1/evacuated-babelify is available as a
non-NSA/Microsoft walled garden link.

Bug#918905: logrotate fails to start becauset OVS is not started yet

[Christian Göttsche]

Control: reassign -1 openvswitch-switch
Control: notfound -1 3.14.0-4
Control: affects -1 logrotate

logrotate failed cause the openvswitch postrotate invocation failed.
The definition is in /etc/logrotate.d/openvswitch-switch, which is
part of the package openvswitch-switch.

Please share the content of your /etc/logrotate.d/openvswitch-switch.

Bug#939698: [pkg-php-pear] Bug#939698: lintian: warning about pkg-php-tools versioned dependency conflicts with cme suggestion

[Antonio Ospite]

On Sun, 8 Sep 2019 21:57:49 +0200
Mathieu Parent  wrote:

> Le dim. 8 sept. 2019 à 02:25, David Prévot  a écrit :
> >
> > Le 07/09/2019 à 11:00, Antonio Ospite a écrit :
> > > Package: lintian
> > […]
> > > one of my packages build-depends on pkg-php-tools, and I used to have
> > > that as a versioned dependency, as suggested by this lintian warning:
> > >
> > > W: tweeper source: pear-package-feature-requires-newer-pkg-php-tools (>= 
> > > 1.7~) for Composer package support
> > >
> > > However I found out that running `cme check dpkg` on said package
> > > suggests to remove the versioned dependency because it has become
> > > unnecessary:
> >
> > It has become unnecessary since at least oldoldstable, so full ack. I’m
> > not the pkg-php-tools maintainer, just a member of the PHP PEAR (and
> > Composer) team taking care of ~100 of PHP library packages.
> 
> Acking too as the main author and maintainer of pkg-php-tools.
> 

Thanks David and Mathieu for the prompt reply.

And thank you Chris for being awesome:
https://salsa.debian.org/lintian/lintian/commit/6cac2636b44942507d5e3fd9085bac40c95f5be8

The warning will be removed from the next lintian release.

Ciao,
   Antonio

-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#939800: librtlsdr-dev: Incomplete pkg-config file

[Jonas Eymann]

Package: librtlsdr-dev
Version: 0.6-1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello Maitland,

while trying to build tfrec (https://github.com/baycom/tfrec) I came across the
problem that pkg-config does not provide the correct linker flags for
librtlsdr:

~$ pkg-config --libs librtlsdr
-L -lrtlsdr

(empty path after -L). Looking at librtlsdr.pc shows that the first four lines
do not have any values defined:

prefix=
exec_prefix=
libdir=
includedir=

Name: RTL-SDR Library
Description: C Utility Library
Version: 0.6.0
Cflags: -I${includedir}/
Libs: -L${libdir} -lrtlsdr
Libs.private:  -lusb-1.0

To me, the upstream librtlsdr.pc.in seems to look fine, so it might a problem
introduced during packaging, but I'm not an expert on pkg-config...

Best regards,
Jonas



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

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

Versions of packages librtlsdr-dev depends on:
ii  librtlsdr00.6-1
ii  libusb-1.0-0-dev  2:1.0.22-2

librtlsdr-dev recommends no packages.

librtlsdr-dev suggests no packages.

-- no debconf information

Bug#939798: kickseed: remove floppy support

[John Paul Adrian Glaubitz]

On 9/8/19 10:53 PM, Miguel Figueiredo wrote:

Package: kickseed
tags: patch

in attachment, patch to remove floppy support from the kickseed package.


Why does floppy support need to be removed? It might be usable for any of
the architectures we use in Debian Ports like m68k or powerpc.

Unless there is a compelling reason to remove it, I would rather keep
floppy support.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#939799: hw-detect: remove floppy support

[John Paul Adrian Glaubitz]

On 9/8/19 10:56 PM, Miguel Figueiredo wrote:

Package: hw-detect
Version: 1.138
tags: patch

in attachment, patch to remove floppy support from the hw-detect package.


There is no reason to drop floppy support for loading firmware.

Please keep in mind that Debian isn't an x86-only distribution.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#939770: wireshark: Wrong path in pre-install notification

[Balint Reczey]

Control: tags -1 confirmed patch
Control: found -1 1.2.9-2

Dear English Localization Team,

Please review the attached patch for fixing the issue reported below.

The current template can be found here:
https://salsa.debian.org/debian/wireshark/blob/debian/master/debian/templates

Thank you,
Balint

On Sun, Sep 8, 2019 at 6:36 PM Nils Dagsson Moskopp
 wrote:
>
> Package: wireshark
> Version: 2.6.7-1~deb9u1
> Severity: minor
>
> Dear Maintainer,
>
> in the pre-install notification about installing dumpcamp so that
> non-root users can capture packets it is displayed that users can
> read about that feature in the file at the following path:
>
> /usr/share/doc/wireshark-common/README.Debian
>
> A file does not actually exist at the path.
> After installation, it does also not exist.
> However, the following path holds the file:
>
> /usr/share/doc/wireshark-common/README.Debian.gz
>
> I suggest to change path in the question and make it clear that the
> file will only exist after the package is installed – even though a
> text mentioning it might be shown before installation is completed.

-- 
Balint Reczey
Ubuntu & Debian Developer
From 38256c713614c857c43692ab153c369b721ac42b Mon Sep 17 00:00:00 2001
From: Balint Reczey 
Date: Sun, 8 Sep 2019 22:30:10 +0200
Subject: [PATCH] debian/templates: Fix README.Debian's path and not that it
 needs to be installed

Change-Id: I7ebc987a8956122e1bb283d33ec3c989c5d83330
Closes: #939770
---
 debian/templates | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/templates b/debian/templates
index dc47130770..66fb399ae2 100644
--- a/debian/templates
+++ b/debian/templates
@@ -17,7 +17,8 @@ _Description: Should non-superusers be able to capture packets?
  less of the code will run with elevated privileges.
  .
  For more detailed information please see
- /usr/share/doc/wireshark-common/README.Debian.
+ /usr/share/doc/wireshark-common/README.Debian.gz after the package
+ installation is finished.
  .
  Enabling this feature may be a security risk, so it is disabled by
  default. If in doubt, it is suggested to leave it disabled.
-- 
2.17.1

Bug#794410: debian-installer: Installer hangs during 'select and install software'

[guillaume]

thank you.

i had the same problem (installer always hangs during "select and 
install software" - around 10% of the progress)


my laptop: LENOVO ideapad 100
i install in legacy mode (mbr, not UEFI).

i tried with debian 8, 9 and 10: same problem.

so i read the comments, and in the BIOS i put:
Boot priority: "UEFI first"
OS Optimized Defaults: "Win8"

then i installed debian 9 (with mbr partitioning, as i always do), and 
it works.

Bug#875184: [sofa-framework] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Sun, Sep 08, 2019 at 08:41:40AM +0200, Andreas Tille wrote:
> On Sat, Sep 07, 2019 at 10:43:53PM +0200, Moritz Mühlenhoff wrote:
> > 
> > The current releases on https://github.com/sofa-framework claim to be Qt5
> > compatible. Is anyone working on updating the package or should it be 
> > removed?
> > 
> > sofa-framework is one of the three remaining reverse dependencies of
> > libqwt5-qt4-dev at this point.
> 
> I tried to upgrade sofa-framework but had severe issues with new cmake
> configuration.  I'll have a look next week.

If you're stuck, feel free to ping #debian-qt-kde.

Cheers,
Moritz

Bug#939375: dub depends on unavailable default-d-compiler

[Matthias Klumpp]

Hi!

Am Mi., 4. Sept. 2019 um 11:17 Uhr schrieb Matthias Klose :
>
> Package: dub
> Version: 1.16.0-1
> Severity: serious
> Tags: sid bullseye
>
> dub depends on the unavailable package default-d-compiler. Maybe that one 
> should
> be built from the dh-dlang source. If you touch that package, please add the
> package for all the mips* targets as well, now built by gcc-9/gdc-9.

I add the respective architectures to the default-d-compiler
metapackage dependent on whether there is a working D compiler on the
respective architecture. "Working" in this case means "can build and
run dub". This is the case for risc64 now, surprisingly, but
unfortunately not yet for mips*, apparently builds on that
architecture succeed, but running the simple manual page generator
fails with a segmentation fault.
Once that issue is fixed, I'll add mips* as well.
As for the other architectures, with the latest dh-dlang upload dub
should be installable on all architectures where it actually builds.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#939799: hw-detect: remove floppy support

[Miguel Figueiredo]

Package: hw-detect
Version: 1.138
tags: patch

in attachment, patch to remove floppy support from the hw-detect package.

--
Best regards / Melhores cumprimentos,

Miguel Figueiredo
diff --git a/debian/hw-detect.templates b/debian/hw-detect.templates
index c413e88e..b9854bd1 100644
--- a/debian/hw-detect.templates
+++ b/debian/hw-detect.templates
@@ -74,7 +74,7 @@ Default: false
 # :sl2:
 _Description: Load missing drivers from removable media?
  A driver for your hardware is not available. You may need
- to load drivers from removable media, such as a USB stick, or driver floppy.
+ to load drivers from removable media, such as a USB stick.
  .
  If you have such media available now, insert it, and continue.
 
@@ -84,8 +84,7 @@ Default: true
 # :sl2:
 _Description: Load missing firmware from removable media?
  Some of your hardware needs non-free firmware files to operate. The
- firmware can be loaded from removable media, such as a USB stick or
- floppy.
+ firmware can be loaded from removable media, such as a USB stick.
  .
  The missing firmware files are: ${FILES}
  .
diff --git a/debian/po/templates.pot b/debian/po/templates.pot
index 59c12851..ad3c057d 100644
--- a/debian/po/templates.pot
+++ b/debian/po/templates.pot
@@ -291,7 +291,7 @@ msgstr ""
 #: ../hw-detect.templates:10001
 msgid ""
 "A driver for your hardware is not available. You may need to load drivers "
-"from removable media, such as a USB stick, or driver floppy."
+"from removable media, such as a USB stick."
 msgstr ""
 
 #. Type: boolean
@@ -317,7 +317,7 @@ msgstr ""
 #: ../hw-detect.templates:11001
 msgid ""
 "Some of your hardware needs non-free firmware files to operate. The firmware "
-"can be loaded from removable media, such as a USB stick or floppy."
+"can be loaded from removable media, such as a USB stick."
 msgstr ""
 
 #. Type: boolean
diff --git a/hw-detect.sh b/hw-detect.sh
index c0f785ae..c6b215bb 100755
--- a/hw-detect.sh
+++ b/hw-detect.sh
@@ -107,8 +107,7 @@ load_module() {
 		IFS="$IFS_SAVE"
 	else   
 		log "Error loading '$module'"
-		if [ "$module" != floppy ] && [ "$module" != ide-floppy ] && \
-		   [ "$module" != ide-cd ] && [ "$module" != ide-generic ]; then
+		if [ "$module" != ide-cd ] && [ "$module" != ide-generic ]; then
 			db_subst hw-detect/modprobe_error CMD_LINE_PARAM "modprobe -v $module"
 			db_input medium hw-detect/modprobe_error || [ $? -eq 30 ]
 			db_go
@@ -145,31 +144,13 @@ get_detected_hw_info() {
 	fi
 }
 
-# NewWorld PowerMacs don't want floppy or ide-floppy, and on some models
-# (e.g. G5s) the kernel hangs when loading the module.
-get_floppy_info() {
-	case $SUBARCH in
-		powerpc/powermac_newworld) ;;
-		*) echo "floppy:Linux Floppy" ;;
-	esac
-}
-
-get_ide_floppy_info() {
-	case $SUBARCH in
-		powerpc/powermac_newworld) ;;
-		*) echo "ide-floppy:Linux IDE floppy" ;;
-	esac
-}
-
 # Manually load modules to enable things we can't detect.
 # XXX: This isn't the best way to do this; we should autodetect.
 # The order of these modules are important.
 get_manual_hw_info() {
 	if [ "$LOAD_IDE" ]; then
-		get_floppy_info
 		get_ide_chipset_info
 		echo "ide-generic:Linux IDE support"
-		get_ide_floppy_info
 		echo "ide-disk:Linux ATA DISK"
 		echo "ide-cd:Linux ATAPI CD-ROM"
 	fi
@@ -502,7 +483,7 @@ if [ -d /sys/class/misc/pmu/ ]; then
 fi
 
 # Install eject?
-if [ -n "$(list-devices cd; list-devices maybe-usb-floppy)" ]; then
+if [ -n "$(list-devices cd )" ]; then
 	apt-install eject || true
 fi
 

Bug#939798: kickseed: remove floppy support

[Miguel Figueiredo]

Package: kickseed
tags: patch

in attachment, patch to remove floppy support from the kickseed package.


--
Best regards / Melhores cumprimentos,

Miguel Figueiredo
diff --git a/cmdline.sh b/cmdline.sh
index 72dcd72..e1e3f74 100644
--- a/cmdline.sh
+++ b/cmdline.sh
@@ -28,12 +28,6 @@ kickseed_file () {
 		file:/*)
 			echo "${1#file:}"
 			;;
-		floppy)
-			echo /floppy/ks.cfg
-			;;
-		floppy:/*)
-			echo "/floppy${1#floppy:}"
-			;;
 		ftp://*/*)
 			spoolpath="$SPOOL/fetch/ftp/${1#ftp://};
 			mkdir -p "${spoolpath%/*}"
diff --git a/initrd-kickseed b/initrd-kickseed
index e4a0d4f..ec96ba6 100755
--- a/initrd-kickseed
+++ b/initrd-kickseed
@@ -100,11 +100,6 @@ case $KS in
 esac
 
 case $KSCFG in
-	/floppy/*)
-		mountmedia floppy || true
-		KSCFG="/media/${KSCFG#/floppy/}"
-		trap 'umount /media || true' EXIT HUP INT QUIT TERM
-		;;
 	/media/*)
 		device="${KSCFG#/media/}"
 		device="${device%%/*}"

Bug#939797: dolphin: Filter bar always present in new Dolphin window

[Felicia]

Package: dolphin
Version: 4:18.08.0-1
Severity: minor

Dear Maintainer,

When a new Dolphin window is launched the filter bar is always open.  If I 
close the filter bar and then close Dolphin, then reopen Dolphin, the filter 
bar is opened again.  It appears that there is no way to prevent the filter bar 
from always being opened when Dolphin launches.


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

Kernel: Linux 5.2.0-2-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= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dolphin depends on:
ii  baloo-kf5  5.54.0-1
ii  kinit  5.54.0-1
ii  kio5.54.1-1
ii  libc6  2.29-0experimental1
ii  libdolphinvcs5 4:18.08.0-1
ii  libkf5baloo5   5.54.0-1
ii  libkf5baloowidgets54:18.08.1-1
ii  libkf5bookmarks5   5.54.0-1
ii  libkf5codecs5  5.54.0-1
ii  libkf5completion5  5.54.0-1
ii  libkf5configcore5  5.54.0-2
ii  libkf5configgui5   5.54.0-2
ii  libkf5configwidgets5   5.54.0-1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5crash5   5.54.0-1
ii  libkf5dbusaddons5  5.54.0-1
ii  libkf5filemetadata35.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5iconthemes5  5.54.0-1
ii  libkf5itemviews5   5.54.0-1
ii  libkf5jobwidgets5  5.54.0-1
ii  libkf5kcmutils55.54.0-1
ii  libkf5kiocore5 5.54.1-1
ii  libkf5kiofilewidgets5  5.54.1-1
ii  libkf5kiowidgets5  5.54.1-1
ii  libkf5newstuff55.54.0-2
ii  libkf5notifications5   5.54.0-1
ii  libkf5parts5   5.54.0-1
ii  libkf5service-bin  5.54.0-1
ii  libkf5service5 5.54.0-1
ii  libkf5solid5   5.54.0-1
ii  libkf5textwidgets5 5.54.0-1
ii  libkf5widgetsaddons5   5.54.0-1
ii  libkf5xmlgui5  5.54.0-1
ii  libphonon4qt5-44:4.10.3-3
ii  libqt5core5a   5.11.3+dfsg1-4
ii  libqt5dbus55.11.3+dfsg1-4
ii  libqt5gui5 5.11.3+dfsg1-4
ii  libqt5widgets5 5.11.3+dfsg1-4
ii  libqt5xml5 5.11.3+dfsg1-4
ii  libstdc++6 9.2.1-7
ii  phonon4qt5 4:4.10.3-3

Versions of packages dolphin recommends:
ii  kimageformat-plugins  5.54.0-1+b1
ii  kio-extras4:18.08.3-1+b1
ii  ruby  1:2.5.1

Versions of packages dolphin suggests:
pn  dolphin-plugins  

-- no debconf information

Bug#932379: apt-mirror doesn't grab *.xz i18n Translation files

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

I agree with Justin Pasher, but if you look a little lower in the text of the 
program "apt-mirror",
you can see a similar code, but for all 3 archive formats:

sub find_dep11_files_in_release
 ...
  if ( $filename =~ 
m{^$component/dep11/(Components-${arch}\.ml|icons-[^./]+\.tar)\.(gz|bz2|xz)$} )

So maybe better to add a line:

 if ( $filename =~ m{^$component/i18n/Translation-[^./]*\.(gz|bz2|xz)$} 
)

In order not to think about it anymore, especially since all the rest of the 
text supports all 3 formats.

Bug#939740: libwxgtk3.0-gtk3-0v5: -10 is not compatible with -9 [symbol _ZNK8wxWindow21GetContentScaleFactorEv version WXU_3.0 not defined in file libwx_gtk3u_core-3.0.so.0 with link time reference]

[Olly Betts]

Control: tag -1 +pending

On Sun, Sep 08, 2019 at 12:00:57PM +0200, Andreas Metzler wrote:
> ametzler@argenau:/tmp/HUGIN$ ldd -r /usr/bin/hugin > /dev/null
> symbol _ZNK8wxWindow21GetContentScaleFactorEv version WXU_3.0 not defined in 
> file libwx_gtk3u_core-3.0.so.0 with link time reference  
> (/usr/lib/hugin/libhuginbasewx.so.0.0)
> symbol _ZNK8wxWindow21GetContentScaleFactorEv version WXU_3.0 not defined in 
> file libwx_gtk3u_core-3.0.so.0 with link time reference  
> (/usr/lib/hugin/libicpfindlib.so.0.0)
> symbol _ZNK8wxWindow21GetContentScaleFactorEv version WXU_3.0 not defined in 
> file libwx_gtk3u_core-3.0.so.0 with link time reference  (/usr/bin/hugin)

There's a new entry in the upstream linker version script for this, but
this is the only new symbol since the last upstream release which our
package has cherry-picked the patch for and it looks like I failed to
merge the version-script change for it appropriately.

Thanks for catching this.  I'll make a new upload shortly.

Cheers,
Olly

Bug#874834: [Help] [avogadro] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Wed, Dec 13, 2017 at 02:54:07PM +0100, Andreas Tille wrote:
> control: tags -1 help
> 
> Hi,
> 
> I've moved avogadro packaging from SVN to Git.  I also had a look into
> the Qt5 migration.  The Git repository[1] contains a branch qt5.  I
> tried my best to adapt cmake to finalise the configuration step.

https://github.com/cryos/avogadro/issues/891 was tagged wontfix,
so let's remove it from the archive? We're closing in on the Qt4 removal
now.

It mentions an avogadro2, that can still be uploaded before bullseye
release when ready.

Cheers,
Moritz

Bug#939048: transition: glibc

[Aurelien Jarno]

On 2019-09-08 22:23, Paul Gevers wrote:
> Control: tags -1 confirmed
> 
> Hi Aurelien,
> 
> Let's have this going.

Ok, I have just uploaded it.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#849308: state of wireguard mainline inclusion?

[Daniel Kahn Gillmor]

Version: 0.0.20190905-1

Over in 849...@bugs.debian.org, Daniel Kahn Gillmor wrote:
> I do plan for putting wireguard into buster-backports, since i expect
> the upstream inclusion issues to be resolved one way or another by the
> time of bullseye release.  If anyone wants to help out by adding it to
> stretch-backports-sloppy, i would welcome that.

Following up on this, and after some discussion with Jason (upstream), i
think it's time to let wireguard migrate into debian testing.

So i'm closing #849308 with this e-mail, and once wireguard migrates
into testing, i'll look into putting it into buster-backports.

I welcome anyone who wants to contribute to the debian packaging to
offer maintenance help too!

  --dkg


signature.asc
Description: PGP signature

Bug#935607: lintian: classify "Starting $DESC" in init.d scripts

[Chris Lamb]

tags 935607 + moreinfo
retitle 935607 lintian: classify "Starting $DESC" / use of $VERBOSE (etc.) in 
init.d scripts
thanks

Hi Dmitry,

> When we see, which of these styles is majority, we can proclaim other
> unwanted and to be fixed.

... but, unless I'm missing something you can surely do that now
almost trivially using codesearch.debian.net and certainly much
quicker, independetly and with less hassle than introducing two new
Lintian tags, etc.

I thus suggest you do that and come back to this bug when you/we have
a concrete implementation plan. 


Regards,

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

Bug#939768: gimp: It's the gegl mismatch...

[Manuel Bilderbeek]

Package: gimp
Version: 2.10.8-2+b1
Followup-For: Bug #939768

Dear Maintainer,

Some discussion on the GIMP IRC channel:

 what's your gegl version? (you can see with $ gimp -v)
 using GEGL version 0.4.12 (compiled against version 0.4.14)
 is that mismatch relevant?
 in this case, probably not
 Ell: do you think it's something gegl related?
 it could be
 Ell: is it worth to try with matching gegl?
 oh, wait. i see what it is :) it's absolutely the 0.4.12/14 mismatch
 Quibus: yes, a matching gegl will fix it

So, looks like the dependencies to gegl are not OK?

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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b2.6.1-2
ii  libheif1 1.5.1-1
ii  libilmbase24 2.3.0-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3+b1
ii  liblzma5 5.2.4-1+b1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1+b1
ii  libopenexr24 2.3.0-6
ii  libopenjp2-7 2.3.0-2
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libpng16-16  1.6.37-1
ii  libpoppler-glib8 0.71.0-5+b1
ii  librsvg2-2   2.44.14-1
ii  libstdc++6   9.2.1-4
ii  libtiff5 4.0.10+git190818-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.2.0-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2+b3
ii  libxpm4  1:3.5.12-1
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages gimp recommends:
ii  ghostscript  9.27~dfsg-3.1

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
pn  gimp-python   
ii  gvfs-backends 1.38.1-5
ii  libasound21.1.8-1

-- no debconf information

Bug#921017: wireguard: doesn't always set all allowed-ips

[Daniel Kahn Gillmor]

Control: tags 921017 + moreinfo unreproducible

Hi Piotr--

On Thu 2019-01-31 18:15:04 +0100, Piotr Ożarowski wrote:
> I have multiple peers defined in /etc/wireguard/wg0.conf
> but setting AllowedIPs doesn't fully work for some of them
> if I use `wg setconf`… and works perfectly fine if I do this
> "manually" via `wg set wg0 peer my_public_key allowed-ips …`.
>
> example peer setup in /etc/wireguard/wg0.conf:
>
>  [Peer]
>  PublicKey = my_public_key
>  AllowedIPs = 10.8.1.2/32,10.1.0.0/20,10.0.0.0/20,192.168.6.0/24
>
> and `wg setconf wg0 /etc/wireguard/wg0.conf && wg show wg0 allowed-ips | grep 
> my_public_key`
> outputs:
>
>  my_public_key 192.168.6.0/24 10.8.1.2/32
>
> (note missing 10.1.0.0/20,10.0.0.0/20)

I tried to replicate this with exactly the kind of setup you've
described, but using version 0.0.20190905-1 on amd64 on a
debian/unstable system.  i saw the output was like:

my_public_key=  10.8.1.2/32 10.1.0.0/20 10.0.0.0/20 192.168.6.0/24

Can you still replicate the problem?

--dkg


signature.asc
Description: PGP signature

Bug#939795: flatpak: After updating to Debian 9.10, Pithos 1.4.1 which runs as a flatpak no longer works. Keep getting 502 Bad Gateway error. If I restore back to Debian 9.9 it works fine.

[Simon McVittie]

On Sun, 08 Sep 2019 at 15:04:24 -0500, jtl wrote:
> After updating to Debian 9.10, Pithos 1.4.1
> which runs as a flatpak no longer works. Keep getting  502 Bad Gateway
> error.

What do you do that results in a 502 Bad Gateway error? Updating Pithos?
Running it? Something else?

Where did you install Pithos from? Flathub, or somewhere else?

Do you access the server from which you installed Pithos via a proxy?

If you repeat the upgrade to Debian 9.10 do you still get the same errors?

I suspect this may have been a temporary problem with the server from which
you installed Pithos, or a proxy server through which you access it.
Flatpak did not change in the Debian 9.10 update.

smcv

Bug#875144: [qscintilla2] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

Hi,

On Sat, Sep 09, 2017 at 11:07:32PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: qscintilla2
> Version: 2.9.3+dfsg-4
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version

All the reverse dependencies of libqscintilla2-qt4-dev and pyqt4.qsci-dev
have now been removed or fixed, so support for Qt4 can simply be dropped.

Cheers,
Moritz

Bug#939048: transition: glibc

[Paul Gevers]

Control: tags -1 confirmed

Hi Aurelien,

Let's have this going.

Paul
@ginggs, I don't mind if you beat me to the binNMU's ;)



signature.asc
Description: OpenPGP digital signature

Bug#716414: ubiupdatevol: Prevent null pointer dereference

[Bastian Germann]

You can find a patch posted to upstream at
http://lists.infradead.org/pipermail/linux-mtd/2019-September/091479.html

Bug#939741: FTBFS with OCaml 4.08.0 (safe strings)

[Benjamin Barenblat]

Control: block 939741 by 897129

I agree. coq-doc acquired a new dependency in the 8.9 release, so
that’ll need to get packaged first.

Bug#921962: Please remove obsolete 'xm' completion file

[Gabriel F. T. Gomes]

On Sat, 23 Feb 2019 10:52:43 -0300 "Gabriel F. T. Gomes" 
 wrote:
>
> Thanks for the information.  I have forwarded this upstream as
> https://github.com/scop/bash-completion/pull/284

This has been integrated into bash-completion 2.9, which is now
available in Debian unstable as 1:2.9-1 (not migrating to Debian
testing because I still need to do a source-only upload... I'll do it
when I have more fixes to upload, as suggested in the Q in the
announcement of Debian Buster release [1])

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

Bug#935057: RM: afl -- ROM; upstream not actively developed anymore

[Scott Kitterman]

It was removed two weeks ago, so it'll need to go back through New.

Scott K

On Sunday, September 8, 2019 4:02:17 PM EDT Paul Tagliamonte wrote:
> Amazing! Thank you for your hard work and willingness to help! Very cool!
> 
> Cc'ing ftpmaster so no one actions it while its in limbo
> 
> Paul
> 
> On Sun, Sep 8, 2019, 2:39 PM Nils Dagsson Moskopp <
> 
> nils+debian-report...@dieweltistgarnichtso.net> wrote:
> > Paul Tagliamonte  writes:
> > > Well, seeing as how Daniel Is the maintainer, perhaps one of you can
> > > take
> > > over as maintainer and rename / reassign this bug to an adoption.
> > > 
> > > How does that sound, all?
> > 
> > If no one is willing, I can be a maintainer, but I have no experience.
> > 
> > I have been asking around for maintainers for some days now.
> > 
> > Please reassign this bug to an adoption soon.

Bug#939796: ITP: lxqt-kcm-integration -- Integration package for several KDE control modules into LXQt

[Alf Gaida]

Package: wnpp
Severity: wishlist
Owner: Alf Gaida 

* Package name: lxqt-kcm-integration
  Version : 0.0.1
  Upstream Author : Alf Gaida 
* URL : https://github.com/lxqt/lxqt-kcm-integration
* License : (LGPL2+)
  Programming Lang: (desktop files)
  Description : Integration package for several KDE control modules into 
LXQt

Right now the set of controls include:
* KCM KWin settings
* KCM Appearance
* KCM Bluetooth
* KCM Systeminfo

The package will ease the pain when $user descide to use kwin with LXQt.
The LXQt packaging team will maintain the package.

Bug#939794: ghostscript breaks fig2dev autopkgtest: compare arrow tips with template failed unexpectedly

[Paul Gevers]

Source: ghostscript, fig2dev
Control: found -1 ghostscript/9.28~~rc2~dfsg-1
Control: found -1 fig2dev/1:3.2.7a-7
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of ghostscript the autopkgtest of fig2dev fails in
testing when that autopkgtest is run with the binary packages of
ghostscript from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
ghostscriptfrom testing9.28~~rc2~dfsg-1
fig2devfrom testing1:3.2.7a-7
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. (The output is
rather dense. I would love a more verbose output, so that others like me
have something to look at.)

Currently this regression is blocking the migration of ghostscript to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
ghostscript/9.28~~rc2~dfsg-1. I.e. due to versioned dependencies or
breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=ghostscript

https://ci.debian.net/data/autopkgtest/testing/amd64/f/fig2dev/2909339/log.gz
Test PostScript output language.

 28: compare arrow tips with templateFAILED (output.at:41)



signature.asc
Description: OpenPGP digital signature

Bug#935057: RM: afl -- ROM; upstream not actively developed anymore

[Paul Tagliamonte]

Amazing! Thank you for your hard work and willingness to help! Very cool!

Cc'ing ftpmaster so no one actions it while its in limbo

Paul

On Sun, Sep 8, 2019, 2:39 PM Nils Dagsson Moskopp <
nils+debian-report...@dieweltistgarnichtso.net> wrote:

> Paul Tagliamonte  writes:
>
> > Well, seeing as how Daniel Is the maintainer, perhaps one of you can take
> > over as maintainer and rename / reassign this bug to an adoption.
> >
> > How does that sound, all?
>
> If no one is willing, I can be a maintainer, but I have no experience.
>
> I have been asking around for maintainers for some days now.
>
> Please reassign this bug to an adoption soon.
>

Bug#939791: [Debian-ha-maintainers] Bug#939791: crmsh: autopkgtest needs update for new version of lxml

[Valentin Vidić]

On Sun, Sep 08, 2019 at 09:53:34PM +0200, Paul Gevers wrote:
> Thanks for letting us know. I'll trigger a test run with lxml and crmsh
> from unstable. If that succeeds as expected, than please close this bug
> with the version of crmsh that fixed the issue.

Will do, thanks. Did not know about the versioned depends in tests,
hope I remember next time :)

-- 
Valentin

Bug#939698: [pkg-php-pear] Bug#939698: lintian: warning about pkg-php-tools versioned dependency conflicts with cme suggestion

[Mathieu Parent]

Le dim. 8 sept. 2019 à 02:25, David Prévot  a écrit :
>
> Le 07/09/2019 à 11:00, Antonio Ospite a écrit :
> > Package: lintian
> […]
> > one of my packages build-depends on pkg-php-tools, and I used to have
> > that as a versioned dependency, as suggested by this lintian warning:
> >
> > W: tweeper source: pear-package-feature-requires-newer-pkg-php-tools (>= 
> > 1.7~) for Composer package support
> >
> > However I found out that running `cme check dpkg` on said package
> > suggests to remove the versioned dependency because it has become
> > unnecessary:
>
> It has become unnecessary since at least oldoldstable, so full ack. I’m
> not the pkg-php-tools maintainer, just a member of the PHP PEAR (and
> Composer) team taking care of ~100 of PHP library packages.

Acking too as the main author and maintainer of pkg-php-tools.

Regards
-- 
Mathieu Parent

Bug#934384: libvma: FTBFS: some symbols or patterns disappeared

[Tzafrir Cohen]

On 10/08/2019 17:46, Niko Tyni wrote:
> Source: libvma
> Version: 8.8.1.really.8.7.7-1
> Severity: serious
> Tags: ftbfs
> 
> This package fails to build on current sid/amd64.
> 
>>From my build log:
> 
>   dpkg-gensymbols: warning: some new symbols appeared in the symbols file: 
> see diff output below
>   dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
> file: see diff output below
>   dpkg-gensymbols: warning: debian/libvma8/DEBIAN/symbols doesn't match 
> completely debian/libvma8.symbols
>   --- debian/libvma8.symbols (libvma8_8.8.1.really.8.7.7-1_amd64)
>   +++ dpkg-gensymbolsBhlY4G   2019-08-10 14:41:41.948238949 +
>   @@ -542,7 +542,7 @@
> _ZN12sockinfo_tcp2rxE9rx_call_tP5ioveclPiP8sockaddrPjP6msghdr@Base 
> 8.8.1.really.8.7.7
> _ZN12sockinfo_tcp2txE9tx_call_tPK5iovecliPK8sockaddrj@Base 
> 8.8.1.really.8.7.7
> 
> _ZN12sockinfo_tcp30create_flow_tuple_key_from_pcbER10flow_tupleP7tcp_pcb@Base 
> 8.8.1.really.8.7.7
>   - _ZN12sockinfo_tcp30return_reuse_buffers_postponedEv@Base 
> 8.8.1.really.8.7.7
>   +#MISSING: 8.8.1.really.8.7.7-1# 
> _ZN12sockinfo_tcp30return_reuse_buffers_postponedEv@Base 8.8.1.really.8.7.7
> _ZN12sockinfo_tcp4bindEPK8sockaddrj@Base 8.8.1.really.8.7.7
> _ZN12sockinfo_tcp5fcntlEim@Base 8.8.1.really.8.7.7
> _ZN12sockinfo_tcp5ioctlEmm@Base 8.8.1.really.8.7.7
>   [...]
>   dh_makeshlibs: failing due to earlier errors
>   make: *** [debian/rules:15: binary] Error 255
>   dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
> status 2
> 

Sorry for the delay. Working on this and will have a fix this week.

-- Tzafrir

Bug#939791: [Debian-ha-maintainers] Bug#939791: crmsh: autopkgtest needs update for new version of lxml

[Valentin Vidić]

On Sun, Sep 08, 2019 at 09:25:48PM +0200, Paul Gevers wrote:
> Source: crmsh
> Version: 4.1.0-2
> Severity: serious
> X-Debbugs-CC: debian...@lists.debian.org, l...@packages.debian.org
> Tags: sid bullseye
> User: debian...@lists.debian.org
> Usertags: needs-update
> Control: affects -1 src:lxml
> 
> Dear maintainers,
> 
> With a recent upload of lxml the autopkgtest of crmsh fails in testing
> when that autopkgtest is run with the binary packages of lxml from
> unstable. It passes when run with only packages from testing. In tabular
> form:
>passfail
> lxml   from testing4.4.1-1
> crmsh  from testing4.1.0-2
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.

Indeed, I updated crmsh to 4.1.0-3 in unstable to fix this problem
and autopkgtest is passing for unstable now. The only problem is
that it now needs the same version of lxml in testing to pass there.
In other words I think that lxml and crmsh should migrate to testing
together now?

The new version of lxml does not break the package itself, it's just
that one of the tests checks the XML output and the ordering of
attributes has changed with the new version of lxml.

-- 
Valentin

Bug#939791: [Debian-ha-maintainers] Bug#939791: crmsh: autopkgtest needs update for new version of lxml

[Paul Gevers]

Hi Valentin,

On 08-09-2019 21:47, Valentin Vidić wrote:
> Indeed, I updated crmsh to 4.1.0-3 in unstable to fix this problem
> and autopkgtest is passing for unstable now.

Thanks, I failed to spot that.

> The only problem is
> that it now needs the same version of lxml in testing to pass there.

So, the test should have had a *versioned* depends on lxml.

> In other words I think that lxml and crmsh should migrate to testing
> together now?

Yes. Next time, please make sure that the dependency resolution will
also know how to find the right combination.

> The new version of lxml does not break the package itself, it's just
> that one of the tests checks the XML output and the ordering of
> attributes has changed with the new version of lxml.

Thanks for letting us know. I'll trigger a test run with lxml and crmsh
from unstable. If that succeeds as expected, than please close this bug
with the version of crmsh that fixed the issue.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#931803: cpio -tvF

[Gabriel F. T. Gomes]

On Wed, 10 Jul 2019 23:24:43 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson 
 wrote:
> 
> I do cpio -tvF  and the screen flashes.

I did not understand this bug report, nor was I able to reproduce it.
Could you describe it in other words, and perhaps explain how I can
reproduce it?  I never saw the screen flash, so I would ask you to even
tell me what terminal emulator you are using.

Cheers,
Gabriel

Bug#935057: RM: afl -- ROM; upstream not actively developed anymore

[Nils Dagsson Moskopp]

Paul Tagliamonte  writes:

> Well, seeing as how Daniel Is the maintainer, perhaps one of you can take
> over as maintainer and rename / reassign this bug to an adoption.
>
> How does that sound, all?

If no one is willing, I can be a maintainer, but I have no experience.

I have been asking around for maintainers for some days now.

Please reassign this bug to an adoption soon.

Bug#939789: faketime: Fails to parse "strict" timestamps with error message "Success"(!)

[Wolfgang Hommel]

Hi Ben,

thanks for reporting this. Please be advised that a newer release is 
available upstream, which however likely is not related to your issue.


With your calls, you should not use the '-f' parameter. Without '-f', 
the timestamp is passed on to date/gdate for parsing, which yields the 
following for me on Debian Buster x86_64:



./faketime '2019-09-06 03:14:37 02:00' /bin/date
date: invalid date ‘2019-09-06 03:14:37 02:00’
Error: Timestamp to fake not recognized, please re-try with a different 
timestamp.


./faketime '2019-09-06T03:14:37+02:00' /bin/date
Fri 06 Sep 2019 03:14:37 AM CEST


So the "iso-strict" variant seems to work out of the box.


When using '-f', the specified string is directly passed on to 
libfaketime by the 'faketime' wrapper without parsing (using 
date/gdate). In this case, you either have to stick to one of the 
formats that libfaketime expects (as documented in the README at 
https://github.com/wolfcw/libfaketime), or, which might be more 
appropriate for your case, you also have to set the FAKETIME_FMT 
environment variable.


I hope that helps a bit.

I also agree that "Success" isn't much of a useful error message here. 
In this case, it's created by a call to the standard perror() system 
call, which should be considered to be replaced with something more 
meaningful. I'll put that on the todo list. :-) However, more useful 
error messages are printed by the wrapper when '-f' is not used.



Best regards
Wolfgang


Ben Wiederhake wrote on 08.09.19 20:54:

Package: faketime
Version: 0.9.7-3
Severity: normal

Dear Maintainer,

I've tried to use faketime to build something reproducibly, by using the git
commit time.
Git offers shortcuts for the formats "iso" (e.g. "2019-09-06 03:14:37 +0200")
and "iso-strict" (e.g. "2019-09-06T03:14:37+02:00").

Steps to reproduce, and actual behavior in bash:

$ LC_ALL=C faketime -f "2019-09-06 03:14:37 02:00" true  # "iso"
[$? = 0]
$ LC_ALL=C faketime -f "2019-09-06T03:14:37+02:00" true  # "iso-strict"
Failed to parse FAKETIME timestamp: Success
[$? = 1]

Expected behavior: Either the second invocation should "just work",
or produce a more meaningful error message.

I prefer the first behavior, and "Success"
sounds like the parsing actually worked, just got handled wrongly,
so maybe this can be done easily?

For my little thing I'll just use git's "iso" shortcut.

Cheers,
Ben Wiederhake



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

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

Versions of packages faketime depends on:
ii  libc62.28-10
ii  libfaketime  0.9.7-3

faketime recommends no packages.

faketime suggests no packages.

-- no debconf information

Bug#939793: plplot breaks coyote autopkgtest: times out

[Paul Gevers]

Grr, I forgot the attachment, and I forgot that there is a transition
involved. Let me run the test with coyote from unstable as the test
passes there.

Paul

On 08-09-2019 21:34, Paul Gevers wrote:
> I copied some of the output at the bottom of this report

Openbox-Message: Unable to find a valid menu file
"/var/lib/openbox/debian-menu.xml"
% WARNING: your version of the GraphicsMagick library will truncate
images to 16 bits per pixel
% Compiled module: TEST_COYOTE.
% Compiled module: CGDEMODATA.
% Compiled module: CGSCALEVECTOR.
% Compiled module: FPUFIX.
% Compiled module: CGDISPLAY.
% Compiled module: CGQUERY.
% Compiled module: CGERRORMSG.

%CGDISPLAY: PLplot installation lacks the requested driver: xwin

Traceback Report from CGDISPLAY:

 PLplot installation lacks the requested driver: xwin
% Compiled module: CGPLOT.
% Compiled module: CGSETCOLORSTATE.
% Compiled module: CGGETCOLORSTATE.
% CGGETCOLORSTATE: PLplot installation lacks the requested driver: xwin
% Error occurred at: CGGETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cggetcolorstate.pro
%CGSETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cgsetcolorstate.pro
%CGPLOT 699
/usr/share/gnudatalanguage/coyote/cgplot.pro
%BASIC_LINE_PLOT  9
/tmp/autopkgtest-lxc.ru1iwmn9/downtmp/build.8eN/src/debian/tests/test_coyote.pro
%TEST_COYOTE302
/tmp/autopkgtest-lxc.ru1iwmn9/downtmp/build.8eN/src/debian/tests/test_coyote.pro
%$MAIN$

%CGPLOT: PLplot installation lacks the requested driver: xwin

Traceback Report from CGPLOT:

 PLplot installation lacks the requested driver: xwin
% CGGETCOLORSTATE: PLplot installation lacks the requested driver: xwin
% Error occurred at: CGGETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cggetcolorstate.pro
%CGSETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cgsetcolorstate.pro
%CGPLOT 699
/usr/share/gnudatalanguage/coyote/cgplot.pro
%PLOT_WITH_LEGEND36
/tmp/autopkgtest-lxc.ru1iwmn9/downtmp/build.8eN/src/debian/tests/test_coyote.pro
%TEST_COYOTE303
/tmp/autopkgtest-lxc.ru1iwmn9/downtmp/build.8eN/src/debian/tests/test_coyote.pro
%$MAIN$

%CGPLOT: PLplot installation lacks the requested driver: xwin

Traceback Report from CGPLOT:

 PLplot installation lacks the requested driver: xwin
% CGGETCOLORSTATE: PLplot installation lacks the requested driver: xwin
% Error occurred at: CGGETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cggetcolorstate.pro
%CGSETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cgsetcolorstate.pro
%CGPLOT 699
/usr/share/gnudatalanguage/coyote/cgplot.pro
%PLOT_WITH_LEGEND38
/tmp/autopkgtest-lxc.ru1iwmn9/downtmp/build.8eN/src/debian/tests/test_coyote.pro
%TEST_COYOTE303
/tmp/autopkgtest-lxc.ru1iwmn9/downtmp/build.8eN/src/debian/tests/test_coyote.pro
%$MAIN$

%CGPLOT: PLplot installation lacks the requested driver: xwin

Traceback Report from CGPLOT:

 PLplot installation lacks the requested driver: xwin
% Compiled module: CGLEGEND.
% Compiled module: CGLEGENDITEM__DEFINE.
% Compiled module: SETDEFAULTVALUE.
% Compiled module: CGDEFCHARSIZE.
% CGGETCOLORSTATE: PLplot installation lacks the requested driver: xwin
% Error occurred at: CGGETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cggetcolorstate.pro
%CGSETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cgsetcolorstate.pro
%CGLEGENDITEM::DRAW   637
/usr/share/gnudatalanguage/coyote/cglegenditem__define.pro
%CGLEGENDITEM::INIT   382
/usr/share/gnudatalanguage/coyote/cglegenditem__define.pro
%CGLEGEND   208
/usr/share/gnudatalanguage/coyote/cglegend.pro
%PLOT_WITH_LEGEND44
/tmp/autopkgtest-lxc.ru1iwmn9/downtmp/build.8eN/src/debian/tests/test_coyote.pro
%TEST_COYOTE303
/tmp/autopkgtest-lxc.ru1iwmn9/downtmp/build.8eN/src/debian/tests/test_coyote.pro
%$MAIN$

%CGLEGENDITEM::DRAW: PLplot installation lacks the requested driver: xwin

Traceback Report from CGLEGENDITEM::DRAW:

 PLplot installation lacks the requested driver: xwin

%CGDISPLAY: PLplot installation lacks the requested driver: xwin

Traceback Report from CGDISPLAY:

 PLplot installation lacks the requested driver: xwin
% CGGETCOLORSTATE: PLplot installation lacks the requested driver: xwin
% Error occurred at: CGGETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cggetcolorstate.pro
%CGSETCOLORSTATE150
/usr/share/gnudatalanguage/coyote/cgsetcolorstate.pro
%CGPLOT 699
/usr/share/gnudatalanguage/coyote/cgplot.pro
%ADDITIONAL_AXES_PLOT   

Bug#939793: plplot breaks coyote autopkgtest: times out

[Paul Gevers]

Source: plplot, coyote
Control: found -1 plplot/5.15.0+dfsg-3
Control: found -1 coyote/2019.02.25-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update timeout

Dear maintainers,

With a recent upload of plplot the autopkgtest of coyote fails in
testing when that autopkgtest is run with the binary packages of plplot
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
plplot from testing5.15.0+dfsg-3
coyote from testing2019.02.25-1
all others from testingfrom testing

I copied some of the output at the bottom of this report, but the
problem may be an infinite loop as the test times out now in the
autopkgtest framework after 2:27 hours, where it used to run under one
minute.

Currently this regression is blocking the migration of plplot to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=plplot

https://ci.debian.net/data/autopkgtest/testing/amd64/c/coyote/2906835/log.gz




signature.asc
Description: OpenPGP digital signature

Bug#939791: crmsh: autopkgtest needs update for new version of lxml

[Paul Gevers]

Source: crmsh
Version: 4.1.0-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, l...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:lxml

Dear maintainers,

With a recent upload of lxml the autopkgtest of crmsh fails in testing
when that autopkgtest is run with the binary packages of lxml from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
lxml   from testing4.4.1-1
crmsh  from testing4.1.0-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of lxml to testing
[1]. Of course, lxml shouldn't just break your autopkgtest (or even
worse, your package), but it seems to me that the change in lxml was
intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from lxml should really add a
versioned Breaks on the unfixed version of (one of your) package(s).

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=lxml

https://ci.debian.net/data/autopkgtest/testing/amd64/c/crmsh/2911559/log.gz

==
FAIL: test_configs (unittests.test_parse.TestCliParser)
--
Traceback (most recent call last):
  File "/usr/share/crmsh/tests/unittests/test_parse.py", line 725, in
test_configs
self.assertEqual(expected, result)
AssertionError: '
?
 ---
+ 
?
   +++

 >> begin captured stdout << -
ERROR: Reference not found: d1-ops
ERROR: Reference not found: d1
ERROR: Reference not found: l2-rule1
ERROR: Reference not found: l2

- >> end captured stdout << --

==
FAIL: test_fencing (unittests.test_parse.TestCliParser)
--
Traceback (most recent call last):
  File "/usr/share/crmsh/tests/unittests/test_parse.py", line 460, in
test_fencing
self.assertEqual(expect, xml_tostring(out))
AssertionError: '' != ''
- 
+ 


--



signature.asc
Description: OpenPGP digital signature