Bug#958282: dx: DebSci Additional info upstream homepage

[Ben Tris]

Package: dx

upstream defunct, alternative:
https://web.archive.org/web/20080705135547/http://opendx.npaci.edu/source/

Homepage defunct, alternative:
https://web.archive.org/web/20080812051658/http://www.opendx.org/




signature.asc
Description: OpenPGP digital signature

Bug#932473: shorewall6 init script is broken in buster too

[Matt Palmer]

found 932473 5.2.3.2-1
severity 932473 important
thanks

I've noticed this problem is present in the buster version of shorewall6,
also.  I've bumped the severity because it "has a major effect on the
usability of a package".

- Matt

Bug#818382: tracker.debian.org: False positive: "Problems while searching for new upstream version"

[Drew Parsons]

Package: tracker.debian.org
Followup-For: Bug #818382

The problem reported in this bug seems to be particularly prevalent
for upstream sources hosted on github.com.  I imagine there's a
temporary access problem at the time UDD tries to connect.  If that's
the case can it be marked to try again after say 5 minutes rather than
waiting a whole day or week?

Packages just in my list currently affected:

golang-github-anacrolix-dms
golang-github-anacrolix-ffprobe
golang-github-anacrolix-missinggo
golang-github-huandu-xstrings
packmol
pytest-mpi
python-bumps
python-dmsh
python-periodictable
python-pypathlib
qutip
sasview
sphinx-click
superlu-dist
apbs
armci-mpi
avogadro
golang-github-azure-azure-pipeline-go
golang-github-roaringbitmap-roaring
hypre
pyfftw
scalapack
xhtml2pdf


All on github.com.


Curiously avogadrolibs is fine, hosted by the same github user as
avogadro.

Can UDD uscan access to github.com be made more robust?

Not clear from this bug, is there already a patch available to help
with the problem?

Drew

Bug#958281: mujs FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: mujs
Version: 1.0.6-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mujs fails to cross build from source, because it does not pass cross
tools to make during the shared build. Using dh_auto_build is the
simplest way to fix that and doing so makes mujs cross buildable. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru mujs-1.0.6/debian/changelog mujs-1.0.6/debian/changelog
--- mujs-1.0.6/debian/changelog 2020-04-11 15:33:46.0 +0200
+++ mujs-1.0.6/debian/changelog 2020-04-20 07:29:44.0 +0200
@@ -1,3 +1,10 @@
+mujs (1.0.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 20 Apr 2020 07:29:44 +0200
+
 mujs (1.0.6-2) unstable; urgency=medium
 
   * Set Vcs fields
diff --minimal -Nru mujs-1.0.6/debian/rules mujs-1.0.6/debian/rules
--- mujs-1.0.6/debian/rules 2020-04-11 15:33:46.0 +0200
+++ mujs-1.0.6/debian/rules 2020-04-20 07:29:43.0 +0200
@@ -10,7 +10,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) XCFLAGS=-Wl,-soname,libmujs.so.1 shared
+   dh_auto_build -- XCFLAGS=-Wl,-soname,libmujs.so.1 shared
dh_auto_build
 
 override_dh_auto_install:

Bug#958280: dokuwiki: Firefox says "404 Not Found" for URL of newly created multisite farm animal

[Kingsley G. Morse Jr.]

Package: dokuwiki
Version: 0.0.20180422.a-2
Severity: normal

Hi Tanguuy,

Thanks for maintaining Debian's dokuwiki package.

I like the simplicity of not depending on a
database.

I've been using dokuwiki for years.

The main reason I'm writing is I'm worried I may
have found a bug.

But maybe I just don't understand the
documentation.

   * What led up to the situation?

I've maintained a local wiki on my daily
driver/local host computer for years.

Firefox finds it at an apache virtual host

localhost:2001/dokuwiki

I want to add a second wiki.

Dokuwiki calls it a multisite farm animal.


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

I upgraded from version 0.0.20180422.a-1 to 0.0.20180422.a-2

$ aptitude install dokuwiki

Then I added a new wiki

$ dokuwiki-addsite testsite2

It seemed to add OK.

Then I tried to access the new farm animal/wiki through Firefox at

http://localhost:2001/dokuwiki/testsite2

   * What was the outcome of this action?

Firefox complained with

404 Not Found

The requested URL was not found on this server.

/var/log/apache2/access.log contains

"GET /dokuwiki/testsite2 HTTP/1.1" 404 490

and /var/log/apache2/error.log contains

AH00128: File does not exist: /usr/share/dokuwiki/testsite2


   * What outcome did you expect instead?

I expected Firefox to render a page that said
something like 

"Welcome to dokuwiki"


I happened to notice 

/usr/share/dokuwiki/index.php

normally redirects to doku.php.

Should 

$ dokuwiki-addsite testsite2

create something like

/usr/share/dokuwiki/testsite2/index.php

that also redirects to a doku.php?

If so, how would it know to look in the new data
page path

/var/lib/dokuwiki/farm/testsite2/

instead of the default

/var/lib/dokuwiki/

?

Thanks,
Kingsley

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

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages dokuwiki depends on:
ii  cdebconf [debconf-2.0]  0.249
ii  debconf [debconf-2.0]   1.5.73
ii  javascript-common   11
ii  libjs-jquery3.3.1~dfsg-3
ii  libjs-jquery-cookie 10-2
ii  libjs-jquery-ui 1.12.1+dfsg-5
ii  libphp-simplepie1.3.1+dfsg-3.1
ii  php 1:7.2+62
ii  php-geshi   1.0.8.11-2
ii  php-phpseclib   2.0.12-1
ii  php-random-compat   2.0.17-1
ii  php-xml 1:7.2+61
ii  php7.2 [php]7.2.8-1
ii  php7.2-xml [php-xml]7.2.8-1
ii  ucf 3.0038+nmu1

Versions of packages dokuwiki recommends:
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  php-cli  1:7.2+61
ii  php-ldap 1:7.2+62
ii  php7.2-cli [php-cli] 7.2.8-1
ii  php7.2-ldap [php-ldap]   7.2.8-1
ii  wget 1.20.3-1

Versions of packages dokuwiki suggests:
pn  libapache2-mod-xsendfile  

-- Configuration Files:
/etc/dokuwiki/plugins.local.php changed:

Bug#958279: gkrellm-xkb FTCBFS: multiple reasons

[Helmut Grohne]

Source: gkrellm-xkb
Version: 1.05-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gkrellm-xkb fails to cross build from source, because it builds for the
build architecture. debian/rules does not pass cross tools to make. The
easiest way to fix that is using dh_auto_build.  Beyond that, the
upstream Makefile hard codes the build architecture pkg-config. Making
pkg-config substitutable is necessary here. It finally strips using the
build architecture strip via install -s during make install. Beyond
breaking cross compilation, this also breaks generation of -dbgsym
packages as well as DEB_BUILD_OPTIONS=nostrip. The attached patch fixes
all of that. Please consider applying it.

Helmut
diff -u gkrellm-xkb-1.05/Makefile gkrellm-xkb-1.05/Makefile
--- gkrellm-xkb-1.05/Makefile
+++ gkrellm-xkb-1.05/Makefile
@@ -1,6 +1,7 @@
 
 PREFIX ?= $(DESTDIR)/usr
-GTK_CONFIG = pkg-config gtk+-2.0
+PKG_CONFIG ?= pkg-config
+GTK_CONFIG = $(PKG_CONFIG) gtk+-2.0
 PLUGIN_DIR ?= $(PREFIX)/lib/gkrellm2/plugins
 GKRELLM_INCLUDE = -I$(PREFIX)/include
 GTK_CFLAGS = `$(GTK_CONFIG) --cflags` 
diff -u gkrellm-xkb-1.05/debian/control gkrellm-xkb-1.05/debian/control
--- gkrellm-xkb-1.05/debian/control
+++ gkrellm-xkb-1.05/debian/control
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: Adam Sloboda 
-Build-Depends: debhelper (>= 5), gkrellm (>= 2.0.0), libgtk2.0-dev, pkg-config
+Build-Depends: debhelper (>= 7), gkrellm (>= 2.0.0), libgtk2.0-dev, pkg-config
 Standards-Version: 3.7.3
 Homepage: http://www.sweb.cz/tripie/gkrellm/xkb/
 
diff -u gkrellm-xkb-1.05/debian/rules gkrellm-xkb-1.05/debian/rules
--- gkrellm-xkb-1.05/debian/rules
+++ gkrellm-xkb-1.05/debian/rules
@@ -22,7 +22,7 @@
 
 build-stamp: configure-stamp 
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch $@
 
 clean:
@@ -37,7 +37,7 @@
dh_testroot
dh_clean -k 
dh_installdirs
-   $(MAKE) DESTDIR=$(CURDIR)/debian/gkrellm-xkb install
+   $(MAKE) DESTDIR=$(CURDIR)/debian/gkrellm-xkb install 'INSTALL=install 
--strip-program=true'
 
 
 # Build architecture-independent files here.
diff -u gkrellm-xkb-1.05/debian/changelog gkrellm-xkb-1.05/debian/changelog
--- gkrellm-xkb-1.05/debian/changelog
+++ gkrellm-xkb-1.05/debian/changelog
@@ -1,3 +1,13 @@
+gkrellm-xkb (1.05-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Make pkg-config substitutable.
++ Defer stripping to dh_strip.
+
+ -- Helmut Grohne   Mon, 20 Apr 2020 07:05:11 +0200
+
 gkrellm-xkb (1.05-5) unstable; urgency=low
 
   * Fixed lintian warnings about upstream changelog

Bug#958278: pd-nusmuk FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: pd-nusmuk
Version: 20151113+repack-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

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

Helmut
diff --minimal -Nru pd-nusmuk-20151113+repack/debian/changelog 
pd-nusmuk-20151113+repack/debian/changelog
--- pd-nusmuk-20151113+repack/debian/changelog  2020-04-13 21:21:21.0 
+0200
+++ pd-nusmuk-20151113+repack/debian/changelog  2020-04-20 07:11:18.0 
+0200
@@ -1,3 +1,10 @@
+pd-nusmuk (20151113+repack-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 20 Apr 2020 07:11:18 +0200
+
 pd-nusmuk (20151113+repack-5) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff --minimal -Nru pd-nusmuk-20151113+repack/debian/rules 
pd-nusmuk-20151113+repack/debian/rules
--- pd-nusmuk-20151113+repack/debian/rules  2020-04-13 21:21:21.0 
+0200
+++ pd-nusmuk-20151113+repack/debian/rules  2020-04-20 07:11:15.0 
+0200
@@ -16,10 +16,10 @@
dh $@ -Smakefile
 
 override_dh_auto_build:
-   make -Caudio \
+   dh_auto_build --sourcedirectory=audio -- \
CFLAGS="$(CPPCFLAGS) $(CFLAGS)" \
LDFLAGS="$(LDFLAGS)"
-   make -Cutils \
+   dh_auto_build --sourcedirectory=utils -- \
CFLAGS="$(CPPCFLAGS) $(CFLAGS)" \
LDFLAGS="$(LDFLAGS) -Wl,--export-dynamic -shared"
 

Bug#958277: simple-cdd: Resulting Install CD asks for questions answered in the profiles/NAME.x files

[Buck]

Package: simple-cdd
Version: 0.6.5
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Create my-simple-cdd/profiles/NAME.x files that specify answers
to installer questions

Run build-simple-cdd --profiles NAME

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

Removed /usr/share/simple-cdd/profiles.

   * What was the outcome of this action?

New error: $default_desktop not defined

   * What outcome did you expect instead?

I expected that removing /usr/share/simple-cdd/profiles would
force build-simple-cdd to read the profile files in
~/my-simple-cdd/profiles/NAME.x



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

Kernel: Linux 4.19.107-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-2+b1
ii  debian-cd   3.1.20
ii  lsb-release 9.20161125
ii  python3 3.5.3-1
ii  python3-simple-cdd  0.6.5
ii  reprepro5.1.1-1
ii  rsync   3.1.2-1+deb9u2
ii  wget1.18-5+deb9u3

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-8+deb9u1

Versions of packages simple-cdd suggests:
ii  qemu-kvm  1:2.8+dfsg-6+deb9u9

-- no debconf information

Bug#958276: simple-cdd: $default_desktop not defined

[Buck]

Package: simple-cdd
Version: 0.6.5
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
   
   Running ~$ build-simple-cdd --profiles NAME
   NAME represents profile build files in  profiles/NAME.x
   
   First run build a normal Debian installer CD, so I renamed
   /usr/share/simple-cdd/profiles as
   /usr/share/simple-cdd/profiles-GOAWAY so these would not be read.  
   
   * 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?

   This error goes away when /usr/share/simple-cdd/profiles exists.  But
   then the built CD launches a Debian installer, but the NAME.x files
   in profiles/ should make this an automatic build (no questions asked)

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

Kernel: Linux 4.19.107-1.pvops.qubes.x86_64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-2+b1
ii  debian-cd   3.1.20
ii  lsb-release 9.20161125
ii  python3 3.5.3-1
ii  python3-simple-cdd  0.6.5
ii  reprepro5.1.1-1
ii  rsync   3.1.2-1+deb9u2
ii  wget1.18-5+deb9u3

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-8+deb9u1

Versions of packages simple-cdd suggests:
ii  qemu-kvm  1:2.8+dfsg-6+deb9u9

-- no debconf information

Bug#798955: [PATCH] libstdc++: don't use #include_next in c_global headers

[Helmut Grohne]

The  and  headers need their counter parts  and
 from the libc respectively, but libstdc++ wraps these
headers. Now  and  include these headers using

$ echo '#include ' | g++ -x c++ -E - -isystem /usr/include >/dev/null
In file included from :1:
/usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or 
directory
   75 | #include_next 
  |   ^~
compilation terminated.
$

What happens here is that g++ includes
libstdc++-v3/include/c_global/cstdlib. That header temporarily #defines
_GLIBCXX_INCLUDE_NEXT_C_HEADERS and then does #include_next .
libstdc++-v3's replacement libstdc++-v3/include/c_comaptibility/stdlib.h
happens to come earlier and is not considered.  Unfortunately, the
-isystem above inserted glibc's header before the location containing
, so the #include_next continues searching and fails to find
.

Now you are probably going to say that "-isystem /usr/include" is a bad
idea and that you shouldn't do that. I'm inclined to agree. This isn't a
problem just yet. Debian wants to move /usr/include/stdlib.h to
/usr/include//stdlib.h. After that move, the problematic flag
becomes "-isystem /usr/include/". Unfortunately, around 30
Debian packages[1] do pass exactly that flag. Regardless whether doing
so is a bad idea, I guess we will have to support that.

I am proposing to replace those two #include_next with plain #include.
That'll solve the problem described above, but it is not entirely
obvious that doing so doesn't break something else.

After switching those #include_next to #include,
libstdc++-v3/include/c_global/cstdlib will continue to temporarily
will #include . Now, it'll search all include directories. It
may find libstdc++-v3/include/c_comaptibility/stdlib.h or the libc's
version. We cannot tell which. If it finds the one from libstdc++-v3,
the header will notice the _GLIBCXX_INCLUDE_NEXT_C_HEADERS macro and
immediately #include_next  skipping the rest of the header.
That in turn will find the libc version. So in both cases, it ends up
using the right one. Precisely what we wanted. #include_next is simply
not useful here.

The #include_next was originally added via PRs libstdc++/14608 and
libstdc++/60401. At that time, the _GLIBCXX_INCLUDE_NEXT_C_HEADERS guard
macro was also added. It seems like the #include_next was a meant as an
extra safe-guard, but actually breaks a practical use case.

For these reasons, I think that using #include_next here is harmful and
that replacing it with plain #include solves the problem without
introducing regressions.

[1] Including but not limited chromium-browser, inkscape, various kde
packages, opencv, and vtk.

libstdc++-v3/ChangeLog:

* include/c_global/cmath: Don't use #include_next.
* include/c_global/cstdlib: Likewise.
---
 libstdc++-v3/include/c_global/cmath   | 2 +-
 libstdc++-v3/include/c_global/cstdlib | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Given the patch's size, I think that the copyright dance is not
necessary. The issue affects at least gcc-8 to gcc-10. Please Cc me in
replies.

Helmut

diff --git a/libstdc++-v3/include/c_global/cmath 
b/libstdc++-v3/include/c_global/cmath
index b99aaf8df40..8b2bb7c0785 100644
--- a/libstdc++-v3/include/c_global/cmath
+++ b/libstdc++-v3/include/c_global/cmath
@@ -42,7 +42,7 @@
 #include 
 #include 
 #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
-#include_next 
+#include 
 #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
 #include 
 
diff --git a/libstdc++-v3/include/c_global/cstdlib 
b/libstdc++-v3/include/c_global/cstdlib
index f42db41fc51..80b39f6144f 100644
--- a/libstdc++-v3/include/c_global/cstdlib
+++ b/libstdc++-v3/include/c_global/cstdlib
@@ -72,7 +72,7 @@ namespace std
 // Need to ensure this finds the C library's  not a libstdc++
 // wrapper that might already be installed later in the include search path.
 #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
-#include_next 
+#include 
 #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
 #include 
 
-- 
2.26.0

Bug#955957: torbrowser-launcher: Depends on deprecated dbus-glib

[Roger Shimizu]

On Sat, Apr 18, 2020 at 5:21 PM Roger Shimizu  wrote:
>
> control: tags -1 upstream
> control: forwarded -1 https://trac.torproject.org/projects/tor/ticket/10014
>
> found the upstream bug above.
> seems it marked as wontfix, because it relies on firefox, the upstream
> of upstream.

I also see #955890, and #955891.
And ticket from upstream of upstream:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1532281

Bug#944750: neomutt: Build with autocrypt support

[Parleur]

I strongly support this suggestion to support autocrypt !

Bug#958275: RM: mumble [arm64 mips64el mipsel] -- RoQA; Depends on zeroc-ice

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
Control: block 958274 by -1

Please remove mumble from arm64, mips64el & mipsel, it depends on
zeroc-ice which in turn depends on openjfx which needs to be removed
from these architectures (#958273).

Kind Regards,

Bas

Bug#881879: [Pkg-sugar-devel] Bug#881879: sugar-browse-activity: does not start, missing collabwrapper

[James Cameron]

Agreed, is fixed, thanks.

By the way, sugar-browse-activity:debian/watch continues to refer to
github tags instead of download.sugarlabs.org.  Also affects Chat,
Pippy and Write.  But not many of the others.

Bug#958274: RM: zeroc-ice [arm64 mips64el mipsel] -- RoQA; Depends on openjfx

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal
Control: block 958273 by -1

Please remove zeroc-ice from arm64, mips64el & mipsel, it depends on
openjfx which needs to be removed from these architectures (#958273).

Kind Regards,

Bas

Bug#958273: RM: openjfx [arm64 mips64el mipsel] -- ROM; FTBFS due to architecture specific issue

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove openjfx from arm64, mips64el & mipsel where it FTBFS due to
an architecture specific issue, to allow it to migrate to testing.

Kind Regards,

Bas

Bug#943015: fonts-ebgaramond: Python2 removal in sid/bullseye

[peter green]

python-fontforge has been removed from testing, so fonts-ebgaramond (which is a 
key package thanks to texlive) can no longer be built in testing.

This bug was tagged as pending over 5 months ago. Is there something blocking 
an upload or did it simply get missed?

Bug#958272: RFS: gmchess/0.29.6-3 [ITA]-- Chinese Chess (Xiangqi) game

[atzlinux]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gmchess"

* Package name : gmchess
Version : 0.29.6-3
Upstream Author : 
* URL : https://github.com/lerosua/gmchess
* License : GPL-2+
* Vcs : https://salsa.debian.org/chinese-team/gmchess
Section : games

It builds those binary packages:

convert-pgn - chess book format converter
eleeye - Chinese Chess (Xiangqi) engine
gmchess - Chinese Chess (Xiangqi) game
libeval0 - support library for eleeye
libeval0-dev - support library for eleeye - development file

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/gmchess

Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/g/gmchess/gmchess_0.29.6-3.dsc

Changes since the last upload:

[ Faris Xiao ]
* Bumped Standards-Version to 4.5.0
* Bumped debhelper to >=12
* replaced debian/compat with the debhelper-compat virtual package
* set xiao sheng wen as Maintainer,delete from Uploaders
* delete unused patch:0001-fix-the-warning-from-cppcheck.patch
* add patch 0004-fix-desktop-mime.patch for desktop.in
* add patch 0005-fix-buster-configure.patch for Debian 10 configure
[ 肖盛文 ]
* add %f for Exec=gmchess in gmchess.desktop.in
* modify changelog.
* copy the whole debian dir from
g...@salsa.debian.org:chinese-team/gmchess.git,
use master branch commit 195f039.
thanks for by...@debian.org
[ byang ]
* Mark libeval0 and libeval0-dev as M-A: same.
* d/control: Remove outdated Replaces field for convert-pgn.
* d/control: Update homepage field and package descriptions.
* d/rules: Remove generation of xpm icons, prefer png icons.
* d/rules: Add "dh_missing --fail-missing".
* d/copyright: Update information.
* Drop dependency against libglademm, no longer used.
* Bump Standards-Version to 4.1.3.
* Bump debhelper compat version to v11.
* d/menu: File already dropped, thus closes: #776771.
* d/control: Remove homepage field, upstream already dead.
* d/control: Add Vcs fields.
* d/copyright: Rewrite in machine-readable format.
* d/watch: Removed, upstream dead.
* d/rules: Modernize usage of dh sequencer.
* Ack previous NMU. Thanks Adrian!
* Drop debian/menu file (should not coexist with desktop file).
* Bump debhelper compat to v10.
+ Drop dep autotools-dev, not needed.

Regards,

-- 
肖盛文 Faris Xiao
微信：atzlinux
ＱＱ：909868357
铜豌豆 Linux 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com




signature.asc
Description: OpenPGP digital signature

Bug#936244: bsdmainutils: Python2 removal in sid/bullseye

[peter green]

Severity 936244 serious
Thanks

libhdate has now been removed from testing, so bsdmainutils can no longer be 
built in testing.

Bug#937144: [Python-modules-team] Bug#938756: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[Scott Kitterman]

On April 20, 2020 2:36:00 AM UTC, peter green  wrote:
>(using -quiet aliases where multiple involved packages have the same
>maintainer listed.
>
>Hi
>
>I have just been running some self-contained buildability tests on
>bullseye and these tests indicated that the python-linecache2 and
>python-traceback2 source packages have been unbuildable in testing for
>170+ days. Both are fixed in unstable by removing python 2 support, but
>can't migrate to testing because the python-unittest2 binary package
>depends on the python-traceback2 binary package. The python2 removal
>bug for python-traceback2 lists python-funcsigs as a blocker. The
>python2 removal bug for python-traceback2 lists nipype and numba as
>blockers.
>
>unittest2 and python-funcsigs seem to be just module packages, so
>dropping python2 support should be simple. numba seems to be a case of
>leftover recommends and test-triggers so that should be a pretty easy
>job to clean up too.
>
>nipype on the other hand looks like it needs a new upstream release. It
>seems this was previously blocked on a package passing new, but said
>package has now passed new.
>
>python-funcsigs seems to have a build-dependency on python-traceback2
>but not a binary dependency, this suggests that the dependency is only
>used to run tests at build time.
>
>nipype and numba are not currently in testing.
>
>This IMO leaves three potential ways forward
>
>Option 1: fix all four packages to be python 2 free.
>
>Option 2: Remove python2 stuff from traceback2, python-funcsigs and
>numba. Break the dependencies of nipype in sid.
>
>Option 3: Remove python2 stuff from traceback2, modify python-funcsigs
>so it still builds the python2 package but does not run tests with
>python 2.
>
>If the maintainers of nipype are willing to upload a python 3 version
>soon, then option 1 is IMO the preffered way forward, but a new
>upstream version is not something I would be prepared to NMU.
>
>Otherwise I am inclined towards option 2. Depending on what responses I
>get to this mail I may implement this option through NMUs later.

Nipype in Unstable is already all kinds of broken.  I'd ignore further breaking 
it your analysis.  I'd suggest move forward with option 2.

Scott K

Bug#937144: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).

[peter green]

(using -quiet aliases where multiple involved packages have the same maintainer 
listed.

Hi

I have just been running some self-contained buildability tests on bullseye and 
these tests indicated that the python-linecache2 and python-traceback2 source 
packages have been unbuildable in testing for 170+ days. Both are fixed in 
unstable by removing python 2 support, but can't migrate to testing because the 
python-unittest2 binary package depends on the python-traceback2 binary 
package. The python2 removal bug for python-traceback2 lists python-funcsigs as 
a blocker. The python2 removal bug for python-traceback2 lists nipype and numba 
as blockers.

unittest2 and python-funcsigs seem to be just module packages, so dropping 
python2 support should be simple. numba seems to be a case of leftover 
recommends and test-triggers so that should be a pretty easy job to clean up 
too.

nipype on the other hand looks like it needs a new upstream release. It seems 
this was previously blocked on a package passing new, but said package has now 
passed new.

python-funcsigs seems to have a build-dependency on python-traceback2 but not a 
binary dependency, this suggests that the dependency is only used to run tests 
at build time.

nipype and numba are not currently in testing.

This IMO leaves three potential ways forward

Option 1: fix all four packages to be python 2 free.

Option 2: Remove python2 stuff from traceback2, python-funcsigs and numba. 
Break the dependencies of nipype in sid.

Option 3: Remove python2 stuff from traceback2, modify python-funcsigs so it 
still builds the python2 package but does not run tests with python 2.

If the maintainers of nipype are willing to upload a python 3 version soon, 
then option 1 is IMO the preffered way forward, but a new upstream version is 
not something I would be prepared to NMU.

Otherwise I am inclined towards option 2. Depending on what responses I get to 
this mail I may implement this option through NMUs later.

Bug#958271: Excessive memory use when comparing linux debug packages

[Ben Hutchings]

Package: diffoscope
Version: 141
Severity: normal

Comparing two versions of linux-image-5.5.0-trunk-amd64-dbg causes
diffoscope to use up about 13 GiB of VM, and then crash because it
still wants more:

$ TMPDIR=/var/tmp diffoscope --max-diff-block-lines-saved 1000 --text 
dummy.diffoscope linux-image-5.6.0-trunk-amd64-dbg_5.6.4-1~exp{1,2}_amd64.deb
Traceback (most recent call last):###|  100% 
ETA:  0:00:00
  File "/usr/bin/diffoscope", line 36, in 
main()
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 740, in main
sys.exit(run_diffoscope(parsed_args))
  File "/usr/lib/python3/dist-packages/diffoscope/main.py", line 692, in 
run_diffoscope
difference = compare_root_paths(path1, path2)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
74, in compare_root_paths
difference = compare_files(file1, file2)
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
128, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 453, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 401, in _compare_using_details
other.as_container, no_recurse=no_recurse
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 195, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
128, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 453, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 401, in _compare_using_details
other.as_container, no_recurse=no_recurse
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 195, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
128, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 453, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 401, in _compare_using_details
other.as_container, no_recurse=no_recurse
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/container.py", 
line 195, in compare_pair
file1, file2, source=None, diff_content_only=no_recurse
  File 
"/usr/lib/python3/dist-packages/diffoscope/comparators/utils/compare.py", line 
128, in compare_files
return file1.compare(file2, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 453, in compare
difference = self._compare_using_details(other, source)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/utils/file.py", 
line 371, in _compare_using_details
details.extend(self.compare_details(other, source))
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/elf.py", line 
629, in compare_details
return _compare_elf_data(self.path, other.path)
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/elf.py", line 
271, in _compare_elf_data
for x in list(READELF_COMMANDS) + READELF_DEBUG_DUMP_COMMANDS
  File "/usr/lib/python3/dist-packages/diffoscope/comparators/elf.py", line 
271, in  
for x in list(READELF_COMMANDS) + READELF_DEBUG_DUMP_COMMANDS
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 256, in 
from_command
klass, path1, path2, *args, **kwargs
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 288, in 
from_command_exc
feeder1, feeder2, path1, path2, *args, **kwargs
  File "/usr/lib/python3/dist-packages/diffoscope/difference.py", line 213, in 
from_feeder
unified_diff = diff(feeder1, feeder2)
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 330, in diff
return run_diff(fifo1_path, fifo2_path, fifo1.end_nl_q, fifo2.end_nl_q)
  File "/usr/lib/python3/dist-packages/diffoscope/tools.py", line 100, in 
tool_check
return fn(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/diffoscope/diff.py", line 179, in 
run_diff
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
  File "/usr/lib/python3.7/subprocess.py", line 472, in run
with Popen(*popenargs, **kwargs) as process:
  File "/usr/lib/python3.7/subprocess.py", line 775, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.7/subprocess.py", line 1453, in _execute_child
restore_signals, start_new_session, preexec_fn)
OSError: 

Bug#945055: great CPU temperature increase from 5.2 to 5.5 ... and when using intel_pstate

[Christoph Anton Mitterer]

Controle: retitle -1 huge CPU temperature increase from 5.2 to 5.5 ... and when 
using intel_pstate


I've upgraded to 5.5.17 (again the stock Debian sid package), and all
future tests with 5.5.x will be with this.

Problems unchanged.




I've also checked 5.5.17 with intel_pstate being enabled but at the
same time using:

iommu=off mitigations=off pci=nomsi


I didn't repeat all tests as extensively as they're in the git repo,
but I've played back a video with mpv and did some casual working (Atl-
Tab-switching between windows, scrolling/up down in some windows,
etc.).

None of these seem to help in terms of my CPU temperature going through
the roof.

Bug#958270: nmu: nohang_0.1-1

[Yangfl]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

nmu nohang_0.1-1 . all . unstable . -m "Rebuild on buildd"

Bug#958269: nmu: libinih_48-1

[Yangfl]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

nmu libinih_48-1 . amd64 . unstable . -m "Rebuild on buildd"

Bug#958180: roundcube: roundcube cannot be installed from the backport

[Patrick Roy Lapratte]

Same problem here. 

On Sun, 19 Apr 2020 14:37:00 +0200 Dirk Lehmann wrote: > Package:
roundcube-core > Version: 1.3.10+dfsg.1-1~deb10u1 > Severity: normal >
File: roundcube > > Dear Maintainer, > > The roundcube package is now
also in the backports. As a result, my previous version was uninstalled
and the current version from the backports cannot be installed. > >
roundcube-core: Depends on: php-masterminds-html5 (> = 2.5.0) but cannot
be installed > > > > -- System Information: > Debian Release: 10.3 > APT
prefers stable-updates > APT policy: (500, 'stable-updates'), (500,
'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux
5.4.0-0.bpo.4-amd64 (SMP w/2 CPU cores) > Locale: LANG=de_DE.UTF-8,
LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8
(charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd
(via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of
packages roundcube-core depends on: > ii dbconfig-common 2.0.11+deb10u1
> ii debconf [debconf-2.0] 1.5.71 > ii dpkg 1.19.7 > ii libmagic1 
> 1:5.35-4+deb10u1 > ii php 2:7.3+69 > pn php-auth-sasl > ii php-common 2:69 > 
> pn php-intl > pn php-mail-mime > pn php-net-sieve > pn php-net-smtp > pn 
> php-net-socket > ii php-pear 1:1.10.6+submodules+notgz-1.1 > ii php7.3 [php] 
> 7.3.14-1~deb10u1 > ii php7.3-cli [php-cli] 7.3.14-1~deb10u1 > ii php7.3-json 
> [php-json] 7.3.14-1~deb10u1 > ii roundcube-mysql 1.4.3+dfsg.1-1~bpo10+1 > ii 
> ucf 3.0038+nmu1 > > Versions of packages roundcube-core recommends: > ii 
> apache2 [httpd-cgi] 2.4.41-1~bpo10+1 > ii php-gd 2:7.3+69 > pn php-pspell > 
> ii php7.3-fpm [php-fpm] 7.3.14-1~deb10u1 > ii php7.3-gd [php-gd] 
> 7.3.14-1~deb10u1 > > Versions of packages roundcube-core suggests: > pn 
> php-crypt-gpg > pn php-net-ldap2 > pn php-net-ldap3 > pn roundcube-plugins > 
> > -- Configuration Files: > /etc/roundcube/apache.conf changed [not included]

-- 
PATRICK ROY LAPRATTE
Administrateur réseau / Network administrator
roylaprat...@linuxme.ca

Bug#958265: Use system libqrcodegen-dev

[Yangfl]

Source: network-manager
Severity: wishlist

Hi,

As libqrcodegen-dev package is now available, please consider linking
against system library instead of bundled qrcodegen.c.

Bug#958266: Use system libqrcodegen-dev

[Yangfl]

Source: network-manager-applet
Severity: wishlist

Hi,

As libqrcodegen-dev package is now available, please consider linking
against system library instead of bundled qrcodegen.c.

Bug#958267: Use system libqrcodegen-dev

[Yangfl]

Source: faust
Severity: wishlist

Hi,

As libqrcodegen-dev package is now available, please consider linking
against system library instead of bundled qrcodegen.c.

Bug#958268: Use system libqrcodegen-dev

[Yangfl]

Source: radare2
Severity: wishlist

Hi,

As libqrcodegen-dev package is now available, please consider linking
against system library instead of bundled qrcodegen.c.

Bug#958264: Use system libqrcodegen-dev

[Yangfl]

Source: smplayer
Severity: wishlist

Hi,

As libqrcodegen-dev package is now available, please consider linking
against system library instead of bundled qrcodegen.c.

Bug#954898: libgccjit0: the issue remains in 10-20200418-1

[Gong-Yi Liao]

Package: libgccjit0
Version: 10-20200418-1
Followup-For: Bug #954898

Dear Maintainer,

This issue still exists in 10-20200418-1

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

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

Versions of packages libgccjit0 depends on:
ii  binutils   2.34-6
ii  gcc-10-base10-20200418-1
ii  libc6  2.30-4
ii  libgcc-10-dev  10-20200418-1
ii  libgmp10   2:6.2.0+dfsg-4
ii  libisl22   0.22.1-1
ii  libmpc31.1.0-1
ii  libmpfr6   4.0.2-1
ii  libzstd1   1.4.4+dfsg-3
ii  zlib1g 1:1.2.11.dfsg-2

libgccjit0 recommends no packages.

libgccjit0 suggests no packages.

-- no debconf information

Bug#958262: Use system axTLS

[Yangfl]

Source: argyll
Severity: wishlist

Hi,

As axTLS package is now available, please consider linking against
system library instead of bundled one.

Bug#958263: Use system axTLS

[Yangfl]

Source: gauche
Severity: wishlist

Hi,

As axTLS package is now available, please consider linking against
system library instead of bundled one.

Bug#683940: lintian.d.o: Specially mark FTP auto-reject tags

[Felix Lechner]

Hi,

On lintian.d.o, FTP Master auto-reject tags could be marked more
prominently. (A related idea would be for tracker.d.o to show a visual
alert.) Maybe it would reduce the burden on the FTP team to keep the
community informed [1]

Kind regards
Felix Lechner

[1] https://lists.debian.org/debian-devel-announce/2009/10/msg4.html

Bug#958261: Use system libsimpleini-dev

[Yangfl]

Source: funguloids
Severity: wishlist

Hi,

As libsimpleini-dev is now available, please consider linking against
system library instead of bundled SimpleIni.h.

Bug#958260: Use system libsimpleini-dev

[Yangfl]

Source: mrpt
Severity: wishlist

Hi,

As libsimpleini-dev is now available, please consider linking against
system library instead of bundled SimpleIni.h.

Bug#958258: Use system libminini-dev

[Yangfl]

Source: drc
Severity: wishlist

Hi,

As libminini-dev is now available, please consider linking against
system library instead of bundled minIni.c.

Bug#958259: Use system libminini-dev

[Yangfl]

Source: libnss-securepass
Severity: wishlist

Hi,

As libminini-dev is now available, please consider linking against
system library instead of bundled minIni.c.

Bug#958257: golang-github-cheekybits-genny: Installs no Golang files

[Dmitry Smirnov]

Source: golang-github-cheekybits-genny
Version: 1.0.0-2
Severity: serious

Package installs no golang files.

-- 
Regards,
 Dmitry Smirnov

---

I believe in only one thing: liberty; but I do not believe in liberty
enough to want to force it upon anyone.
-- H. L. Mencken


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

Bug#958255: Use system libjsonparser-dev

[Yangfl]

Source: shadowsocks-libev
Severity: wishlist

Hi,

As libjsonparser-dev is now available, please consider linking against
system library instead of bundled json.c.

Bug#958256: Use system libjsonparser-dev

[Yangfl]

Source: remind
Severity: wishlist

Hi,

As libjsonparser-dev is now available, please consider linking against
system library instead of bundled json.c.

Bug#958252: Use system libjsonparser-dev

[Yangfl]

Source: simple-obfs
Severity: wishlist

Hi,

As libjsonparser-dev is now available, please consider linking against
system library instead of bundled json.c.

Bug#958251: Use system libjsonparser-dev

[Yangfl]

Source: bitlbee
Severity: wishlist

Hi,

As libjsonparser-dev is now available, please consider linking against
system library instead of bundled json.c.

Bug#958254: Use system libjsonparser-dev

[Yangfl]

Source: cctools
Severity: wishlist

Hi,

As libjsonparser-dev is now available, please consider linking against
system library instead of bundled json.c.

Bug#958250: Use system libjsonparser-dev

[Yangfl]

Source: vlc
Severity: wishlist

Hi,

As libjsonparser-dev is now available, please consider linking against
system library instead of bundled json.c.

Bug#958253: Use system libjsonparser-dev

[Yangfl]

Source: pgpool2
Severity: wishlist

Hi,

As libjsonparser-dev is now available, please consider linking against
system library instead of bundled json.c.

Bug#958249: Use system libjsonparser-dev

[Yangfl]

Source: teeworlds
Severity: wishlist

Hi,

As libjsonparser-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958246: Use system libinih-dev

[Yangfl]

Source: mpdas
Severity: wishlist

Hi,

As libinih-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958248: Use system libinih-dev

[Yangfl]

Source: knxd
Severity: wishlist

Hi,

As libinih-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958247: Use system libinih-dev

[Yangfl]

Source: mgba
Severity: wishlist

Hi,

As libinih-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958245: Use system libinih-dev

[Yangfl]

Source: fs-uae
Severity: wishlist

Hi,

As libinih-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958244: Use system libinih-dev

[Yangfl]

Source: hinge
Severity: wishlist

Hi,

As libinih-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958243: Use system libinih-dev

[Yangfl]

Source: gnutls28
Severity: wishlist

Hi,

As libinih-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958242: Use system libinih-dev

[Yangfl]

Source: ocserv
Severity: wishlist

Hi,

As libinih-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958241: Use system libinih-dev

[Yangfl]

Source: pcp
Severity: wishlist

Hi,

As libinih-dev is now available, please consider linking against
system library instead of bundled ini.c.

Bug#958240: /usr/bin/ssh: ssh client should process arguments in the command line order

[Colin Watson]

On Mon, Apr 20, 2020 at 12:04:57AM +, Witold Baryluk wrote:
> $ ssh 10.0.0.1 -l baryluk -X -l root
> baryluk@10.0.0.1's password: 
> 
> 
> 
> Well, that is wrong. The last parameter overwrite should win.

Would you mind please filing this upstream at
https://bugzilla.mindrot.org/, and then we can mark it forwarded here?
It's not something we're going to change specifically in Debian.  While
I could file it upstream on your behalf, it's often better if the
original reporter does so, because then upstream developers can talk to
you directly rather than me having to be an inefficient go-between if
there are any questions or disputes.

Thanks,

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

Bug#955453: Another case

[Jelmer Vernooij]

Spam detection software, running on the system "rhonwyn.jelmer.uk",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
the administrator of that system for details.

Content preview:  Another case, for heimdall-flash: 
https://github.com/Benjamin-Dobell/Heimdall
   

Content analysis details:   (6.2 points, 5.0 required)

 pts rule name  description
 -- --
 0.0 FSL_HELO_NON_FQDN_1No description available.
 0.9 SPF_FAIL   SPF: sender does not match SPF record (fail)
[SPF failed: Please see 
http://www.openspf.org/Why?s=mfrom;id=jelmer%40jelmer.uk;ip=2a01%3A348%3A125%3A8%3A%3A11;r=rhonwyn.jelmer.uk]
 0.0 HELO_NO_DOMAIN Relay reports its domain incorrectly
 0.0 TVD_SPACE_RATIONo description available.
 1.3 RDNS_NONE  Delivered to internal network by a host with no rDNS
 1.9 URI_ONLY_MSGID_MALFURI only + malformed message ID
 2.1 TVD_SPACE_RATIO_MINFP  Space ratio


--- Begin Message ---
Another case, for heimdall-flash:
https://github.com/Benjamin-Dobell/Heimdall
--- End Message ---

Bug#957311: groonga: ftbfs with GCC-10

[Kentaro Hayashi]

FYI:

This issue was fixed in upstream
https://github.com/matsumotory/ngx_mruby/pull/452

Bug#935292: lintian: reporing-harness get stuck when lintian deadlocks

[Felix Lechner]

Control: retitle -1 lintian: encrypted zip files stall processing

Hi,

On Wed, Aug 21, 2019 at 4:27 AM Niels Thykier  wrote:
>
> Below is the log from where
> lintian was manually killed by me on a stuck package

We have a new tag sieve that examines the archive. It is separate from
Lintian, and will be moved to a team location soon:

https://salsa.debian.org/lechner/taxiv

The tag sieve currently gets stuck on two packages that ship encrypted
zip files that require passwords. Archive::Zip apparently waits for
user input, although there is no prompt. The affected packages are:

androguard
fcrackzip

The following commands appear in the process table. Lintian will
resume processing when they are killed, but the condition should not
appear:

unzip -t 
/tmp/lintian-pool-isMSeQshki/pool/a/androguard/androguard_3.3.5-2_all_binary/unpacked/usr/share/doc/androguard/examples/malware/4e2201cde26141715255d2421f0bcfb1.zip

unzip -t 
/tmp/lintian-pool-x_RwncOeP5/pool/f/fcrackzip/fcrackzip_1.0-10_amd64_binary/unpacked/usr/share/doc/fcrackzip/examples/noradi.zip

This patch seemed plausible but did not work:

index 2142c92da..2322f4962 100644
--- a/lib/Lintian/Index/Java.pm
+++ b/lib/Lintian/Index/Java.pm
@@ -164,6 +164,10 @@ sub parse_jar {
 next
   if $member->isDirectory;

+# prompts for password otherwise
+next
+  if $member->isEncrypted;
+
 # store for later processing
 $manifest = $member
   if $name =~ m@^META-INF/MANIFEST.MF$@oi;

The presence of an encrypted zip member should probably also trigger a tag.

Kind regards
Felix Lechner

Bug#958240: /usr/bin/ssh: ssh client should process arguments in the command line order

[Witold Baryluk]

Package: openssh-client
Version: 1:8.2p1-4
Severity: normal
File: /usr/bin/ssh


$ ssh 10.0.0.1 -l baryluk -X -l root
baryluk@10.0.0.1's password: 



Well, that is wrong. The last parameter overwrite should win.

This is helpful when one creates a shell alias (i.e. `alias r='ssh
10.0.0.1 -l baryluk -X'`) or a shell script (`exec ssh 10.0.0.1 -l baryluk -X 
"$@"`),
but still wants to be able to append and/or overwrite arguments (`r -l root`).

The same should apply when one says `ssh a@10.0.0.1 -l b`, the b should
win, as it is the most rightmost one.

This applies to few other options (-c, -D, -A/-a, -E, -I, -K/-k,
-q/-v/-y, -T/-t, -X/-Y/-x, -b, -B, -i, -S, etc).


Regards,
Witold



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

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  libc6 2.30-4
ii  libedit2  3.1-20191231-1
ii  libfido2-11.4.0-1
ii  libgssapi-krb5-2  1.17-7
ii  libselinux1   3.0-1+b3
ii  libssl1.1 1.1.1f-1
ii  passwd1:4.8.1-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages openssh-client recommends:
ii  xauth  1:1.0.10-1

Versions of packages openssh-client suggests:
pn  keychain 
pn  libpam-ssh   
pn  monkeysphere 
ii  ssh-askpass  1:1.2.4.1-10+b1
ii  ssh-askpass-gnome [ssh-askpass]  1:8.2p1-4

-- no debconf information

Bug#956287: (no subject)

[Michael Lustfield]

I did not notice that the .so and .exe files were strictly test input. This
makes perfect sense and I agree with your refutal.

Bug#958239: ITP: ruby-growl -- Uniform notifier for various utilities

[Cocoa]

package: wnpp
Severity: wishlist
Owner: 'Cocoa'

*Package Name  : ruby-uniform-notifier
 Version   : 1.13.0-1
 Upstream Author   : Richard Huang
*URL   : https://github.com/flyerhzm/uniform_notifier
*License   : Expat
*Description   : Uniform notifier for various utilities

Dependency for bullet.

Bug#958238: ITP: ruby-xmpp4r -- XMPP/Jabber Library for Ruby

[Cocoa]

package: wnpp
Severity: wishlist
Owner: 'Cocoa'

*Package Name  : ruby-xmpp4r
 Version   : 0.5.6-1
 Upstream Author   : Lucas Nussbaum, Stephan Maka
*URL   : https://github.com/xmpp4r/xmpp4r
*License   : Ruby
*Description   :XMPP/Jabber Library for Ruby

Gem required by uniform_notifier, which is required for bullet.

Bug#958237: ITP: ruby-growl -- Pure-Ruby Growl Notifier

[Cocoa]

package: wnpp
Severity: wishlist
Owner: 'Cocoa' 

*Package Name  : ruby-growl
 Version   : 4.1-1
 Upstream Author   : Eric Hodel
*URL   : https://github.com/drbrain/ruby-growl
*License   : BSD-3-clause
*Description   : Pure-Ruby Growl Notifier

Gem required by uniform_notifier, which is required for bullet.

Bug#923289: product inquiry/ PO

[Gerald Bod]

Good day,
I am Gerald Bod Anh from Agro Direct B.V, Netherlands. A friend and business associate referred me to your company and I am willing to buy. Attached purchase order are specification i would like of your products.
 
Please respond ASAP so that we could deliberate on payrnent method and shipping. Also, build business relationship with you.Due to the ongoing Corona virus issue, we would like to know how fast shipment can get to us once the order is confirmed.
 
Thank You,
Gerald Bod ANH
HR Procurement Officer
AGRO DIRECT B.V, NETHERLANDS
 
 


From: Grace illonSent: Thursday, April 16, 2020 11:21 AMTo: Gerald BodSubject: Re: Contact

 

Hi Gerald,

 

Nice to read from you and hope you are staying safe during the COVID 19.

 

Yes, I know where u can have tat ordered from. below is their email contact

 

E-mail: 923...@bugs.debian.org

 

Regard

 

Grace

 



From: Grace illonSent: Friday, April 10, 2020 4:21 PMTo: Gerald BodSubject:  Contact

 

Grace,
 
We know you have contact with manufacturers that produce the attached product. 
 
Please can you refer us or share email contact of any?
 
 
Thank You,
Gerald Bod ANH
HR Procurement Officer
AGRO DIRECT B.V, NETHERLANDS<<< text/html; name="AGRO purchase_order 0045642397_Mehrere ZC02 1.xlsx.htm": Unrecognized >>>

Bug#958236: grub2: rootfs may be rendered unbootable due to grub2 not supporting the latest btrfs features

[waxhead]

Source: grub2
Version: 2.04-5
Severity: grave
Tags: patch
Justification: causes non-serious data loss

Dear Maintainer,

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

   * What led up to the situation?

   The latest kernel (5.5) and btrfs-progs 5.6 supports rebalancing to a new 
metadata mode for the filfeystem caller Raid1c3 or Raid1c4.
   unlike the regular raid1 this allows for more copies of the data.
   If your rootfs is btrfs , and you rebalance either metadata or data to 
raid1c3/raid1c4 your system is not unbootable.

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

   I downloaded the grub2 source with apt-get source grub2 , and checked 
grub-core/fs/btrfs.c for the additions found here:
   
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=495781f5ed1b48bf27f16c53940d6700c181c74c
   They are missing and hence your rootfs can become unbootable.

   * What was the outcome of this action?

   I could not find that this patch was applied
   
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=495781f5ed1b48bf27f16c53940d6700c181c74c

   * What outcome did you expect instead?
   I would expect grub2 to include this minor patch to support btrfs 
raid1c3/raid1c4


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


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

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

Bug#958235: manpages: Please remove memusage.1 from the package

[Jean-Philippe MENGUAL]

Package: manpages
Version: 5.06-1
Severity: minor

Dear Maintainer,

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

   * What led up to the situation?

memusage has not been in Debian for a long time, at least a decade.

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

Translating the manpages-l10n, I see that memusage is still
present. Upstream cannot remove it, as the command exists in gcc-toools
on Fedora, but Debian should do it.

Would help for translation stats and not to have a useless page

Best regards

   * 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 unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

manpages depends on no packages.

manpages recommends no packages.

Versions of packages manpages suggests:
ii  man-db [man-browser]  2.9.1-1

-- no debconf information

Bug#958100: fixed in dnsmasq 2.81-2

[Laurent Bigonville]

Le 19/04/20 à 22:58, Simon Kelley a écrit :

On 19/04/2020 09:55, Laurent Bigonville wrote:

On Sat, 18 Apr 2020 18:48:37 + Debian FTP Masters
 wrote:
[...]

dnsmasq (2.81-2) unstable; urgency=low
.
* Fix FTBFS on kFreeBSD. (closes: #958100)

Thanks for the fast upload, the package is now building fine.

Why didn't you apply the changes to the debian/control file that I
proposed as well?

pkg-config is needed to build the package, it was also needed before my
patch, so adding it to the build-dependencies is necessary. Packages
using pkg-config should BD on it and not rely on other -dev packages to
pull it IMVHO.

Regarding the build-dependency on libbsd-dev, it is only needed on
kfreebsd, not hurd, that's why I changed the architecture from
!linux-any to kfreebsd-any

Kind regards,

Laurent Bigonville


Argh. Oversight on my part. Apologies. I just uploaded 2.81-3 which
fixes this.

No need to do a specific upload for this I guess

Bug#956055: dpkg should use treat signatures from the DD_nu keyring as valid

[Guillem Jover]

Hi!

On Mon, 2020-04-06 at 14:57:30 -0400, Taowa wrote:
> Package: dpkg
> Version: 1.19.7
> Tags: patch

> --require-valid-signature currently uses the DD uploading and DM
> keyrings (among others), it should also check against the DD
> nonuploading keyring as they are treated like DMs as per [1,2].

Thanks for the patch! The change to the .pot should have gone instead
to the man/dpkg-source.man (but that didn't trigger a git grep I guess
due to the escaped «-» :/, I'll be moving to POD so that this kind of
thing does not happen among other stuff :), I've fixed this locally.

I was wondering though how do you want it to be attributed when I
commit to git? Say:

  Taowa Munene-Tardif 

or like in the From to the bug report?

  Taowa 

Something else? :)

(I'd recommend setting up git config user.email, committing patches to
git and then using «git format-patch» so that you state clearly this
kind of thing. :)

Thanks,
Guillem

Bug#958232: CVE-2020-11722

[Adam Borowski]

On Sun, Apr 19, 2020 at 11:10:48PM +0200, Moritz Muehlenhoff wrote:
> Source: crawl
> Severity: important
> Tags: security
> 
> This was assigned CVE-2020-11722:
> https://dpmendenhall.blogspot.com/2020/03/dungeon-crawl-stone-soup.html
> 
> Patches:
> https://github.com/crawl/crawl/commit/768f60da87a3fa0b5561da5ade9309577c176d04
> https://github.com/crawl/crawl/commit/fc522ff6eb1bbb85e3de60c60a45762571e48c28

Hi!
I'm aware of this issue, but Crawl as configured in Debian is not affected.
Our builds are not setgid anymore, and only local play is supported (ssh and
X-forwarding counting as "local").

Crawl has three user interfaces:
* text (curses-like)
  + may be compiled with dgamelaunch support, for untrusted users
* graphical SDL
* graphical web (played via a browser)

The Debian packaging ships only the text and SDL variants, we do not provide
either dgamelaunch nor webtiles builds.

So the only reason to consider patching this vulnerability is because
someone might want to take Debian's .orig to compile the executable for a
public server.  But, public servers are notorious to pick additional
customizations.  That's nice when using a preferred form for modification
like a git repo, but uncool with a tarball.

Thus, I believe there's little point in providing a fix.  Do you agree with
my assessment?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#958068: gnome-shell crashes during normal system use. Workspace related problem

[Marcelo Laia]

I solved that problem.

First of all, I uninstalled all gnome-shell-extensions.

After, I backup all exclusive gnome hidden directories:

https://help.gnome.org/admin//system-admin-guide/2.32/appendixa-0.html.en

So, I delete the originals ones and reboot the system.

All work correct again.

That's all. Solved my issue. This could be marked "solved".

Thank you!

-- 
Marcelo

Bug#955770: grace: fix of bug #727796 is a regression

[Nicholas Breen]

On Sat, Apr 04, 2020 at 09:18:04PM +0200, Lothar Brendel wrote:
> Package: grace
> Version: 1:5.1.25-7+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> xmgrace's UI got slightly inferior since version 1:5.1.25-6: The menu 
> accelerators have dissapreared, the font is less fitting.
> 
> Actually, I beg to differ regarding bug #727796 and its fix. The Xresources 
> hardcoded in xmgrace.c are *fallback* resources, employed via 
> XtAppSetFallbackResources(). They can be and *are* overriden by user 
> specified Xresources (I don't know why this didn't work in the bug reporter's 
> case). What's a bit annoying: *All* of them are dismissed as soon as a 
> resource file is given, even an empty one.
> 
> This can be verified nicely in version 1:5.1.23-3: Without an 
> /etc/X11/app-defaults/XMgrace, the UI has colors, a nice font, and menu 
> accelerators. With an empty /etc/X11/app-defaults/XMgrace, it is b/w, has a 
> monospaced font and no menu accelerators. Unfortunately, with the 
> /etc/X11/app-defaults/XMgrace shipped since version 1:5.1.23-6, it has 
> colors, but still the monospaced font and still no menu accelerators. This I 
> consider a regression.

Some of this may be DE-dependent; I get a monospaced font *with*
accelerators.  But I take your point.

> My suggestion: Don't cripple the fallback resources in the code and instead 
> of supplying a deficient /etc/X11/app-defaults/XMgrace, provide an example in 
> the docs. The example file could contain precisely the fallback values, then 
> the user could edit just the relevant bits.

This seems reasonable.  I feel like very, very few people are
customizing their Xresources file in the current day.  



-- 
Nicholas Breen
nbr...@debian.org

Bug#954845: poor performance for -g 256x50

[Thomas Dickey]

On Sun, Apr 12, 2020 at 11:50:32AM -0400, Thomas Dickey wrote:
> On Sun, Apr 12, 2020 at 05:27:56PM +0200, Harald Dunkel wrote:
> > You can reproduce the performance fall-off by using a slow network 
> > connection,
> 
> I suppose I could, if I had a slow connection.
> Simulating one (from previous experience) hasn't been reliable :-(

I found this useful

https://wiki.linuxfoundation.org/networking/netem

and was able to set up a test for this bug.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#956585: openjfx: FTBFS on all making openjfx uninstallable

[Emmanuel Bourg]

Le 19/04/2020 à 20:57, Sebastiaan Couwenberg a écrit :

> 11.0.7+0-2 still FTBFS on arm64 & mips*, will you still file the RM bugs
> for openjfx & zeroc-ice to unblock the testing migration or shall I?

Yes go ahead with the RM, thank you for the help.

Emmanuel Bourg

Bug#957569: mtink: ftbfs with GCC-10

[Eduard Bloch]

Control: 957569 tags +patch

Hallo,
* Matthias Klose [Fri, Apr 17 2020, 11:06:38AM]:
> Package: src:mtink
> Version: 1.0.16-10
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-10

I don't have time to make a full release but at least for that
problem: see attached patch.

If nobody steps forwared to do the QA upload, please ping me later.

Best regards,
Eduard.
Description: mark some structure declarations in shared header external
 This should never have worked anyway.
Author: Eduard Bloch 
Bug-Debian: https://bugs.debian.org/957569

--- mtink-1.0.16.orig/mainSrc/mtink.h
+++ mtink-1.0.16/mainSrc/mtink.h
@@ -133,11 +133,11 @@ typedef struct wConfig_data_s

 #endif

-wConfig_data_t firstConfig;
-wConfig_data_t newPrinter;
+extern wConfig_data_t firstConfig;
+extern wConfig_data_t newPrinter;

-wConfig_data_t exchangeCartridge;
-wConfig_data_t alignHead;
+extern wConfig_data_t exchangeCartridge;
+extern wConfig_data_t alignHead;

 #if WITH_X
 extern Widget createNoPrinterBox(char *);

Bug#958100: fixed in dnsmasq 2.81-2

[Simon Kelley]

On 19/04/2020 09:55, Laurent Bigonville wrote:
> On Sat, 18 Apr 2020 18:48:37 + Debian FTP Masters
>  wrote:
> [...]
>> dnsmasq (2.81-2) unstable; urgency=low
>> .
>> * Fix FTBFS on kFreeBSD. (closes: #958100)
> 
> Thanks for the fast upload, the package is now building fine.
> 
> Why didn't you apply the changes to the debian/control file that I
> proposed as well?
> 
> pkg-config is needed to build the package, it was also needed before my
> patch, so adding it to the build-dependencies is necessary. Packages
> using pkg-config should BD on it and not rely on other -dev packages to
> pull it IMVHO.
> 
> Regarding the build-dependency on libbsd-dev, it is only needed on
> kfreebsd, not hurd, that's why I changed the architecture from
> !linux-any to kfreebsd-any
> 
> Kind regards,
> 
> Laurent Bigonville
> 

Argh. Oversight on my part. Apologies. I just uploaded 2.81-3 which
fixes this.

Simon.

Bug#956925: dpkg: dpkg-source: should fail before-build if patches can't be applied fully in v3-quilt

[Guillem Jover]

Control: ressign -1 libdpkg-perl
Control: merge 950142 -1

On Thu, 2020-04-16 at 21:31:21 +0200, Jiri Palecek wrote:
> Package: dpkg
> Version: 1.20.0+nmu2~1.gbpcd9614
> Severity: normal
> Tags: patch

> while building some of my packages, I noticed they were built without
> patches applied. Further investigation in the code showed that it was
> caused by dpkg-source --before-build carrying on silently if the first
> patch could't be applied, eg. when the series was partially applied, or
> the patch itself was somehow defective. It seems this behaviour was a
> legacy from package format 2 and IMHO is totally unneeded with quilt. I
> therefore suggest to apply this patch, which I've used for several
> months now without problems. It relegates the issue of deciding when to
> apply patches to quilt.

Unfortunately that's not possible, as people expect to be able to
build packages w/o having used quilt to apply them, for example when
they store a source with patches applied in a VCS.

Thanks,
Guillem

Bug#958234: RM: mod-authz-securepass -- RoQA; Dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove mod-authz-securepass. It's removed from testing June 2018
and dead upstream (http://www.gippa.net/securepass-eol)

Cheers,
Moritz

Bug#958233: RM: libnss-securepass -- RoQA; Dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove libnss-securepass. It's removed from testing since
2018 and is dead upstream (http://www.gippa.net/securepass-eol).

Cheers,
Moritz

Bug#958229: Please document whether trailing commas are allowed

[Guillem Jover]

Hi!

On Sun, 2020-04-19 at 13:45:17 -0700, Josh Triplett wrote:
> Package: dpkg-dev
> Version: 1.19.7
> Severity: normal
> File: /usr/share/man/man5/deb-control.5.gz

> The deb-control manpage seemed like the right place to look to find out
> if Debian control files can have trailing commas in comma-separated
> fields (such as Depends). However, it didn't mention whether this was
> allowed.

That man pages documents the control file for binary packages.

> (I'm hoping that it is, as that would improve the quality of diffs.)

This got documented in deb-src-control(5) in 1.19.0, I think at a
similar time when this got requested to be clarified in debian-policy.

  


I'm wondering what gave this false lead?

(I have a pending and unfinished branch somewhere to move all the
dependency syntax into its own man page, perhaps that would have
helper here?)

Thanks,
Guillem

Bug#958232: CVE-2020-11722

[Moritz Muehlenhoff]

Source: crawl
Severity: important
Tags: security

This was assigned CVE-2020-11722:
https://dpmendenhall.blogspot.com/2020/03/dungeon-crawl-stone-soup.html

Patches:
https://github.com/crawl/crawl/commit/768f60da87a3fa0b5561da5ade9309577c176d04
https://github.com/crawl/crawl/commit/fc522ff6eb1bbb85e3de60c60a45762571e48c28

Cheers,
Moritz

Bug#958231: RM: gplaycli/3.25+ds-1

[Andres Salomon]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Google API changes broke the gplaycli tool. See #950112 for an 
explanation. Newer

versions are fine, but the version in stable is broken.

Bug#771677: Segmentation fault during detect

[Kipp Cannon]

Hi,

I'm getting segmentation faults during detect, but it might be a new
bug.  The problem is only present in the Debian package, if I build the
software myself from the upstream git source I do not get segmentation
faults.

I'm using urjtag 0.10+r2007-1.2 which is the version currently
available through Debian testing.  I have a Spartan 3E Starter Kit, and
I am using urjtag with the "xpc_int" cable choice.  There are three
devices in the jtag chain on the development board.

The interaction I see is

% jtag

UrJTAG 0.10 #2007
Copyright (C) 2002, 2003 ETC s.r.o.
Copyright (C) 2007, 2008, 2009 Kolja Waschk and the respective authors

UrJTAG is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
There is absolutely no warranty for UrJTAG.

warning: UrJTAG may damage your hardware!
Type "quit" to exit, "help" for help.

jtag> cable xpc_int
firmware version = 0x0404 (1028)
cable CPLD version = 0x0006 (6)
jtag> detect
IR length: 22
Chain length: 3
Device Id: 01101110010010010011 (0x06E5E093)
  Manufacturer: Xilinx (0x093)
  Part(0):  XC2C64-VQ44 (0x6E5E)
  Stepping: 0
  Filename: /usr/share/urjtag/xilinx/xc2c64a-vq44/xc2c64a-vq44
Segmentation fault

In case it helps, the last few lines of an ltrace for the segmentation
fault are

fopen("/usr/share/urjtag/xilinx/xc2c64a"..., "re") = 0x5574c81b76c0
malloc(168)  = 0x5574c81fd0a0
malloc(200)  = 0x5574c81fd180
malloc(12)   = 0x5574c81ef090
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

The output of the detect command when I run the version I have compiled
myself is

jtag> detect
IR length: 22
Chain length: 3
Device Id: 01101110010010010011 (0x06E5E093)
  Manufacturer: Xilinx (0x093)
  Part(0):  XC2C64-VQ44 (0x6E5E)
  Stepping: 0
  Filename: /home/kipp/urjtag/share/urjtag/xilinx/xc2c64a-vq44/xc2c64a-vq44
Device Id: 01010100011010010011 (0x05046093)
  Manufacturer: Xilinx (0x093)
  Part(1):  xcf04s (0x5046)
  Stepping: 0
  Filename: /home/kipp/urjtag/share/urjtag/xilinx/xcf04s/xcf04s
Device Id: 00011110001010010011 (0x01C22093)
  Manufacturer: Xilinx (0x093)
  Part(2):  xc3s500e_fg320 (0x1C22)
  Stepping: 0
  Filename: 
/home/kipp/urjtag/share/urjtag/xilinx/xc3s500e_fg320/xc3s500e_fg320


-Kipp


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

Bug#958230: Please add libpam0g-dev as buid-dep (solves auth not working on shadow)

[Santiago Garcia Mantinan]

Source: freerdp2
Severity: normal

Hi!

First, sorry about the almost empty mail to the list, I was trying to abort,
but somehow I managed to send :-(

The thing is that when I tested freerdp2-shadow-x11 I saw that auth was not
working when being run as a user, I couldn't authenticate with current user
password. Googling a bit I came across some old reports, namely:

https://github.com/FreeRDP/FreeRDP/issues/2775
https://github.com/FreeRDP/FreeRDP/issues/3144

That say that you need to compile with libpam0g-dev for that to work.  I
have tested that with 2.0.0~git20190204.1.2693389a+dfsg1-2 and yes, it
worked Ok after compiling with libpam0g-dev enabled, so, if there isn't any
security risks in doing so, can you please add this build-dep in order to
fix the auth bug?

Thanks in advance.

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#958229: Please document whether trailing commas are allowed

[Josh Triplett]

Package: dpkg-dev
Version: 1.19.7
Severity: normal
File: /usr/share/man/man5/deb-control.5.gz

The deb-control manpage seemed like the right place to look to find out
if Debian control files can have trailing commas in comma-separated
fields (such as Depends). However, it didn't mention whether this was
allowed.

(I'm hoping that it is, as that would improve the quality of diffs.)

-- Package-specific info:

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

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

Versions of packages dpkg-dev depends on:
ii  binutils  2.34-6
ii  bzip2 1.0.8-2
ii  libdpkg-perl  1.19.7
ii  make  4.2.1-1.2
ii  patch 2.7.6-6
ii  perl  5.30.0-10
ii  tar   1.30+dfsg-7
ii  xz-utils  5.2.4-1+b1

Versions of packages dpkg-dev recommends:
ii  build-essential  12.8
ii  clang-10 [c-compiler]1:10.0.0-4
ii  fakeroot 1.24-1
ii  gcc [c-compiler] 4:9.2.1-3.1
ii  gcc-9 [c-compiler]   9.3.0-10
ii  gnupg2.2.20-1
ii  gpgv 2.2.20-1
pn  libalgorithm-merge-perl  

Versions of packages dpkg-dev suggests:
pn  debian-keyring  

-- no debconf information

Bug#956672: rtkit activation fails, because service unit is installed at the wrong place

[Boyuan Yang]

Control: tags -1 -pending +patch
X-Debbugs-CC: sate...@debian.org

Alright -- I think I got the reason.

Since we switched to meson buildsystem, all variable handling happens in
meson.build. Starting at 
https://salsa.debian.org/multimedia-team/rtkit/-/blob/0a0f6d58f792f8dcf38f9b0b4cf925e9f4f4337d/meson.build#L61
:

systemunitdir = ''
if systemunitdir == '' and systemd_dep.found()
systemunitdir = systemd_dep.get_pkgconfig_variable(
'systemdsystemunitdir',
default: '',
)
endif
if systemunitdir == ''
systemunitdir = get_option('libdir') / 'systemd' / 'system'
endif


Now librt does NOT build-depend on systemd. As a result, meson cannot find
/usr/share/pkgconfig/systemd.pc (provided by binary package systemd). This
makes systemd_dep.found() to return false. Finally systemunitdir will be given
as $libdir/systemd/system, which is wrong since $libdir is multi-archified.

I would propose to add systemd as build-dependency. Personally I am okay with
this, but downstream Devuan and other maintainers who want to keep away from
systemd might not be happy. Another choice is to patch the buildsystem. I'd
leave this decision to current rtkit maintainers.

Besides: it would also be great if an optional build-dependency libpolkit-
gobject-1-dev could be added as well.

-- 
Regards,
Boyuan Yang


On Tue, 14 Apr 2020 08:52:48 +0200 =?utf-8?b?R8OhYm9yIEdvbWLDoXM=?= <
gomb...@digikabel.hu> wrote:
> Package: rtkit
> Version: 0.13-2
> Severity: important
> 
> Hi,
> 
> syslog is full with:
> 
> Apr 14 08:42:53 host dbus-daemon[940]: [system] Activating via systemd:
service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service'
requested by ':1.158' (uid=1000 pid=156197 comm="/usr/lib/firefox/firefox
-contentproc -childID 6 -")
> Apr 14 08:42:53 host dbus-daemon[940]: [system] Activation via systemd
failed for unit 'rtkit-daemon.service': Unit rtkit-daemon.service not found.
> 
> ... and the reason is:
> 
> # dpkg -L rtkit | grep rtkit-daemon.service
> /usr/lib/x86_64-linux-gnu/systemd/system/rtkit-daemon.service
> 
> The unit file should be under /usr/lib/systemd/system.


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

Bug#956535: buster-pu: package php-horde-data/2.1.4-5+deb10u1

[Roberto C . Sánchez]

Hi Mathieu & Adam,

On Wed, Apr 15, 2020 at 03:07:00PM +0200, Mathieu Parent (Debian) wrote:
> 
> 
> Thanks Roberto!
> 
> Hello Salvatore,
> 
> > Mathieu, but are you still planning to request removals?
> 
> Done as #956808.
> 
Given that the removal has been requested, I'll not prepare new uploads
for unstable.  Adam, could you weigh in on whether I may proceed with
the uploads (all six) or whether I need to wait for the removal to take
place?

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#958228: RFS: rumur/2020.04.05-1 -- model checker for the Murphi language

[Matthew Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "rumur"

* Package name: rumur
   Version : 2020.04.05-1
   Upstream Author : Matthew Fernandez 
* URL : https://github.com/Smattr/rumur
* License : Unlicense
* Vcs : https://github.com/Smattr/rumur.git
   Section : devel

It builds those binary packages:

  rumur - model checker for the Murphi language

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/rumur

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.04.05-1.dsc

Changes since the last upload:

   * New upstream release.
.
   * Add some autopkgtests for new binary, murphi2murphi.

Regards,
Matthew

Bug#958226: mark binutils-arm-none-eabi Multi-Arch: foreign

[Helmut Grohne]

Package: binutils-arm-none-eabi
Version: 14
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:sunxi-tools

sunxi-tools fails to cross build from source, because it fails running
arm-none-eabi-as. Packages containing triplet-prefixed tools should
normally be marked Multi-Arch: foreign. This also applies to
binutils-arm-none-eabi. Please consider applying the attached patch.

Helmut
diff --minimal -Nru binutils-arm-none-eabi-14/debian/changelog 
binutils-arm-none-eabi-14+nmu1/debian/changelog
--- binutils-arm-none-eabi-14/debian/changelog  2020-03-05 11:56:18.0 
+0100
+++ binutils-arm-none-eabi-14+nmu1/debian/changelog 2020-04-19 
22:09:15.0 +0200
@@ -1,3 +1,10 @@
+binutils-arm-none-eabi (14+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark binutils-arm-none-eabi Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 19 Apr 2020 22:09:15 +0200
+
 binutils-arm-none-eabi (14) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru binutils-arm-none-eabi-14/debian/control 
binutils-arm-none-eabi-14+nmu1/debian/control
--- binutils-arm-none-eabi-14/debian/control2020-03-05 11:56:18.0 
+0100
+++ binutils-arm-none-eabi-14+nmu1/debian/control   2020-04-19 
22:09:14.0 +0200
@@ -26,6 +26,7 @@
 
 Package: binutils-arm-none-eabi
 Architecture: any
+Multi-Arch: foreign
 Built-Using: ${Built-Using}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: GNU assembler, linker and binary utilities for ARM Cortex-R/M 
processors

Bug#958227: vblade FTCBFS: does not pass cross tools to make

[Helmut Grohne]

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

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

Helmut
diff --minimal -Nru vblade-24/debian/changelog vblade-24/debian/changelog
--- vblade-24/debian/changelog  2019-02-25 20:47:57.0 +0100
+++ vblade-24/debian/changelog  2020-04-19 22:17:51.0 +0200
@@ -1,3 +1,10 @@
+vblade (24-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 19 Apr 2020 22:17:51 +0200
+
 vblade (24-3) unstable; urgency=medium
 
   * Improve init scripts
diff --minimal -Nru vblade-24/debian/rules vblade-24/debian/rules
--- vblade-24/debian/rules  2018-09-15 13:22:56.0 +0200
+++ vblade-24/debian/rules  2020-04-19 22:17:51.0 +0200
@@ -19,7 +19,7 @@
dh_clean
 
 override_dh_auto_build:
-   $(MAKE) PLATFORM=$(PLATFORM)
+   dh_auto_build --no-parallel -- PLATFORM=$(PLATFORM)
 
 override_dh_auto_install:
$(MAKE) install prefix=debian/vblade/usr

Bug#958225: Unusable and Details button not working, closing not working

[Eduard Bloch]

Package: kjots
Version: 4:5.0.2-2
Severity: important

Installed kjots because I was looking for some OneNote replacement.

The program is not usable. It shows only one screen which tells that
something is wrong with my KDE pim installation and I shall klick
Details to see more details. But pushing that Details button does absolutely
NOTHING.

Sadly, not much useful functionality was in the menues. So I tried to
close and reopen it. But cannot do so, getting this output:

KCatalog being used without a Q*Application instance. Some translations won't 
work
kjots is already running!

Sorry, there is no KJots window open nor is there an open systray
button. Why did it not stop its process when the window was closed?

Anyway, I tried the same again. Now the process was not zombified, after
closing the window the process was still running.

Best regards,
Eduard.

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

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

Versions of packages kjots depends on:
ii  akonadi-server   4:19.08.3-1
ii  kio  5.62.1-2+b1
ii  libc62.30-4
ii  libgcc-s1 [libgcc1]  10-20200418-1
ii  libgcc1  1:10-20200418-1
ii  libgrantlee-templates5   5.1.0-2.1
ii  libgrantlee-textdocument55.1.0-2.1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-19.08]4:19.08.3-1
ii  libkf5akonadinotes5 [libkf5akonadinotes5-19.08]  4:19.08.3-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-19.08]  4:19.08.3-1
ii  libkf5bookmarks5 5.62.0-1+b1
ii  libkf5configcore55.62.0-1+b1
ii  libkf5configgui5 5.62.0-1+b1
ii  libkf5configwidgets5 5.62.0-1+b1
ii  libkf5coreaddons55.62.0-1
ii  libkf5i18n5  5.62.0-1
ii  libkf5itemmodels55.62.0-1
ii  libkf5kcmutils5  5.62.0-1+b2
ii  libkf5kiowidgets55.62.1-2+b1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-19.08]  19.08.3-1
ii  libkf5mime5abi1 [libkf5mime5-19.08]  19.08.3-1
ii  libkf5parts5 5.62.0-1+b1
ii  libkf5pimtextedit5abi2 [libkf5pimtextedit5-19.08]19.08.3-1
ii  libkf5textwidgets5   5.62.0-1+b1
ii  libkf5widgetsaddons5 5.62.0-1+b1
ii  libkf5xmlgui55.62.0-1+b1
ii  libqt5core5a 5.12.5+dfsg-10
ii  libqt5dbus5  5.12.5+dfsg-10
ii  libqt5gui5   5.12.5+dfsg-10
ii  libqt5printsupport5  5.12.5+dfsg-10
ii  libqt5widgets5   5.12.5+dfsg-10
ii  libstdc++6   10-20200418-1

kjots recommends no packages.

kjots suggests no packages.

-- no debconf information

--
18:51  Tolimar: gib mir noch 30min. dann ist mein fruehstueck fertig...
18:52  zobel: Oh, erst beim frühstücken?  Dann nimm dir ruhig 40min.
18:52  Frühstück ist die wichtigste Mahlzeit des Tages.

Bug#958224: libpam-alreadyloggedin: autopkgtest regression: module 'string' has no attribute 'lowercase'

[Paul Gevers]

Source: libpam-alreadyloggedin
Version: 0.3-8
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent upload of libpam-alreadyloggedin the autopkgtest of
libpam-alreadyloggedin fails in testing when that autopkgtest is run
with the binary packages of libpam-alreadyloggedin from unstable. It
passes when run with only packages from testing. In tabular form:

passfail
libpam-alreadyloggedin from testing0.3-8
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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=libpam-alreadyloggedin

https://ci.debian.net/data/autopkgtest/testing/amd64/libp/libpam-alreadyloggedin/5030060/log.gz

autopkgtest [14:12:09]: test tests: [---
getenv(ADTTMP) ... ok
getuid() ... root
/var/run/utmp ... ok
reset umask ... ok
setup SIGALRM handler ... ok
create pam.d/login backup ... ok
create new pam.d/login ... ok
plant new pam.d/login ... ok
restore pam.d/login ... ok
Traceback (most recent call last):
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 307, in 
main()
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 249, in main
with c_user() as (login, password):
  File "/usr/lib/python3.8/contextlib.py", line 113, in __enter__
return next(self.gen)
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 157, in c_user
login = generate_username()
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 125, in generate_username
parts += [rng.choice(string.lowercase) for i in range(8)]
  File
"/tmp/autopkgtest-lxc.d47pj_qf/downtmp/build.lDk/src/debian/tests/tests",
line 125, in 
parts += [rng.choice(string.lowercase) for i in range(8)]
AttributeError: module 'string' has no attribute 'lowercase'
autopkgtest [14:12:09]: test tests: ---]



signature.asc
Description: OpenPGP digital signature

Bug#898045: nvidia-cuda-gdb: depends on libncurses5

[Andreas Beckmann]

On 11/04/2020 09.04, Tobias Frost wrote:
> This seems the last package blocking the completion of the ncurses 
> transistion.
> 
> Should this bug be RC?

I'm trying to build cuda-gdb from the source tarball the cuda toolkit
ships ... but I'm currently stuck at some weird compile error.
If anyone wants to take a look, I've pushed it to master+cuda-gdb.
(cuda-gdb is based on gdb 7.12 (that version was in stretch), and that
doesn't change in 10.2 either)

Andreas

Bug#958223: eslint: autopkgtest failure: ESLint couldn't find the plugin "eslint-plugin-eslint-plugin"

[Paul Gevers]

Source: eslint
Version: 5.0.1~dfsg-4
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: always-fails

Dear maintainer(s),

With a recent upload of eslint you added an autopkgtest, great. However,
it fails. I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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=eslint

https://ci.debian.net/data/autopkgtest/testing/amd64/e/eslint/4723665/log.gz

autopkgtest [09:13:37]: test command2:  NODE_PATH=tools find lib conf
bin tests/lib/util tests/lib/config tests/lib/code-path-analysis
tests/lib/formatters tests/lib/testers tests/lib/rules tests/bin
tests/lib/*.js -type f -name '*.js' -not -path
tests/lib/code-path-analysis/code-path.js -exec eslint --format tap
--report-unused-disable-directives {} +
autopkgtest [09:13:37]: test command2: [---

Oops! Something went wrong! :(

ESLint: 5.0.1.
ESLint couldn't find the plugin "eslint-plugin-eslint-plugin". This can
happen for a couple different reasons:

1. If ESLint is installed globally, then make sure
eslint-plugin-eslint-plugin is also installed globally. A
globally-installed ESLint cannot find a locally-installed plugin.

2. If ESLint is installed locally, then it's likely that the plugin
isn't installed correctly. Try reinstalling by running the following:

npm i eslint-plugin-eslint-plugin@latest --save-dev

Path to ESLint package: /usr/share/nodejs/eslint

If you still can't figure out the problem, please stop by
https://gitter.im/eslint/eslint to chat with the team.

autopkgtest [09:13:39]: test command2: ---]



signature.asc
Description: OpenPGP digital signature

Bug#958222: edflib: autopkgtest failure: gcc: Command not found

[Paul Gevers]

Source: edflib
Version: 1.16-2
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: always-fails

Dear maintainer(s),

With a recent upload of edflib you added an autopkgtest, great. However,
it fails. I suspect you are just missing test dependencies. I copied
some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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=edflib

https://ci.debian.net/data/autopkgtest/testing/amd64/e/edflib/4738699/log.gz

autopkgtest [15:14:29]: test run-unit-test: [---
gcc -Wall -Wextra -Wshadow -Wformat-nonliteral -Wformat-security
-Wtype-limits -g -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -c unittest.c
-o unittest.o
make: gcc: Command not found
make: *** [Makefile:20: unittest.o] Error 127
autopkgtest [15:14:29]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#958113: lintian crash on empty orig.tar

[Baptiste BEAUPLAT]

Hi Felix,

On 4/19/20 9:35 PM, Felix Lechner wrote:
> There are additional conditions in Lintian that could cause follow-on
> failures. Will you please provide that package, even if it isn't in
> the archive?

Here you go.

Best,
-- 
Baptiste BEAUPLAT - lyknode
Format: 1.8
Date: Sun, 02 Dec 2018 22:38:11 +0100
Source: hello
Architecture: source
Version: 1.0-1
Distribution: unstable
Urgency: medium
Maintainer: Vincent TIME 
Changed-By: Vincent TIME 
Closes: 0
Changes:
 hello (1.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #0)
Checksums-Sha1:
 9a30a5005b8002de80e8c0446ba03635845e6dc8 861 hello_1.0-1.dsc
 f91ec020c1da1bb51a5b5104a093290e5e1db983 113 hello_1.0.orig.tar.gz
 d9a2c5351f7d73cf0a18887f1a7e2ce2cacefeb8 1408 hello_1.0-1.debian.tar.xz
Checksums-Sha256:
 c2db9c4de0e6236dd26fc79776ec3bdad9de5c90ad50eb89c7124fa77d3d83f6 861 
hello_1.0-1.dsc
 21d8015108bdc711b989f9e734a32d51ffe02ac8c4b52944ac4dee80096c9914 113 
hello_1.0.orig.tar.gz
 9529ab3f60da66e048a3460a6d318555da7b5638eb07f845fbe0f51683c62233 1408 
hello_1.0-1.debian.tar.xz
Files:
 f4c9bb66ba3704ff5d5d94da2ae127c9 861 utils optional hello_1.0-1.dsc
 71db41d43b76f2a8a95633cb68313f56 113 utils optional hello_1.0.orig.tar.gz
 4a9d6733ff5f15b00f19f28b3d8f35a1 1408 utils optional hello_1.0-1.debian.tar.xz


hello_1.0-1.debian.tar.xz
Description: application/xz
Format: 3.0 (quilt)
Source: hello
Binary: hello
Architecture: any
Version: 1.0-1
Maintainer: Vincent TIME 
Homepage: https://example.org
Standards-Version: 4.1.3
Vcs-Browser: https://salsa.debian.org/debian/hello
Vcs-Git: https://salsa.debian.org/debian/hello.git
Build-Depends: debhelper (>= 11)
Package-List:
 hello deb utils optional arch=any
Checksums-Sha1:
 f91ec020c1da1bb51a5b5104a093290e5e1db983 113 hello_1.0.orig.tar.gz
 d9a2c5351f7d73cf0a18887f1a7e2ce2cacefeb8 1408 hello_1.0-1.debian.tar.xz
Checksums-Sha256:
 21d8015108bdc711b989f9e734a32d51ffe02ac8c4b52944ac4dee80096c9914 113 
hello_1.0.orig.tar.gz
 9529ab3f60da66e048a3460a6d318555da7b5638eb07f845fbe0f51683c62233 1408 
hello_1.0-1.debian.tar.xz
Files:
 71db41d43b76f2a8a95633cb68313f56 113 hello_1.0.orig.tar.gz
 4a9d6733ff5f15b00f19f28b3d8f35a1 1408 hello_1.0-1.debian.tar.xz


hello_1.0.orig.tar.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#958221: konversation: Konversation has irc.debian.org configured as "Freenode"

[Quazgar]

Package: konversation
Version: 1.7.5-1
Severity: normal

Dear Maintainer,

on a freshly installed Debian, Konversation comes pre-configured with an IRC
network named "Freenode".  Unlike what one would expect, this does NOT connect
to irc.freenode.org or another connected server, but to irc.debian.org
(equivalent to OFTC).  Please rename the preconfigured network accordingly, to
avoid confusion.

Thank you!



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

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

Versions of packages konversation depends on:
ii  kio5.54.1-1
ii  konversation-data  1.7.5-1
ii  libc6  2.28-10
ii  libkf5archive5 5.54.0-1
ii  libkf5bookmarks5   5.54.0-1
ii  libkf5codecs5  5.54.0-1
ii  libkf5completion5  5.54.0-1
ii  libkf5configcore5  5.54.0-1+deb10u1
ii  libkf5configgui5   5.54.0-1+deb10u1
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  libkf5emoticons-bin5.54.0-1
ii  libkf5emoticons5   5.54.0-1
ii  libkf5globalaccel-bin  5.54.0-1
ii  libkf5globalaccel5 5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5iconthemes5  5.54.0-1
ii  libkf5idletime55.54.0-1
ii  libkf5itemviews5   5.54.0-1
ii  libkf5kiocore5 5.54.1-1
ii  libkf5kiofilewidgets5  5.54.1-1
ii  libkf5kiowidgets5  5.54.1-1
ii  libkf5notifications5   5.54.0-1
ii  libkf5notifyconfig55.54.0-1
ii  libkf5parts5   5.54.0-1
ii  libkf5service-bin  5.54.0-1
ii  libkf5service5 5.54.0-1
ii  libkf5textwidgets5 5.54.0-1
ii  libkf5wallet-bin   5.54.0-1
ii  libkf5wallet5  5.54.0-1
ii  libkf5widgetsaddons5   5.54.0-1
ii  libkf5windowsystem55.54.0-1
ii  libkf5xmlgui5  5.54.0-1
ii  libphonon4qt5-44:4.10.2-1
ii  libqca-qt5-2   2.1.3-2
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus55.11.3+dfsg1-1+deb10u3
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u3
ii  libqt5network5 5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5 5.11.3+dfsg1-1+deb10u3
ii  libstdc++6 8.3.0-6
ii  phonon4qt5 4:4.10.2-1

konversation recommends no packages.

konversation suggests no packages.

-- no debconf information

Bug#958219: gkrellshoot FTCBFS: multiple reasons

[Helmut Grohne]

Source: gkrellshoot
Version: 0.4.4-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gkrellshoot fails to cross build from source. The immediate reason is
passing compiler flags inside the CC variable as that gets substituted
by dh_auto_build during cross compilation. Then the compiler flags are
constructed using the build architecture pkg-config as it is hard coded
in the upstream Makefile. Finally, make install strips using the build
architecture strip via install -s. Doing so also breaks generation of
-dbgsym packages as well as DEB_BUILD_OPTIONS=nostrip. The attached
patch fixes all of that. Please consider applying it.

Helmut
diff --minimal -Nru gkrellshoot-0.4.4/debian/changelog 
gkrellshoot-0.4.4/debian/changelog
--- gkrellshoot-0.4.4/debian/changelog  2016-11-14 03:55:43.0 +0100
+++ gkrellshoot-0.4.4/debian/changelog  2020-04-19 18:00:25.0 +0200
@@ -1,3 +1,13 @@
+gkrellshoot (0.4.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Don't pass compiler flags via CC.
++ Make pkg-config substitutable.
++ Defer stripping to dh_strip.
+
+ -- Helmut Grohne   Sun, 19 Apr 2020 18:00:25 +0200
+
 gkrellshoot (0.4.4-2) unstable; urgency=medium
 
   * Changed maintainer's email address.
diff --minimal -Nru gkrellshoot-0.4.4/debian/patches/cross.patch 
gkrellshoot-0.4.4/debian/patches/cross.patch
--- gkrellshoot-0.4.4/debian/patches/cross.patch1970-01-01 
01:00:00.0 +0100
+++ gkrellshoot-0.4.4/debian/patches/cross.patch2020-04-19 
18:00:25.0 +0200
@@ -0,0 +1,36 @@
+--- gkrellshoot-0.4.4.orig/Makefile
 gkrellshoot-0.4.4/Makefile
+@@ -1,17 +1,19 @@
+-GTK_INCLUDE = `pkg-config gtk+-2.0 --cflags`
+-GTK_LIB = `pkg-config gtk+-2.0 --libs`
++PKG_CONFIG ?= pkg-config
++GTK_INCLUDE = `$(PKG_CONFIG) gtk+-2.0 --cflags`
++GTK_LIB = `$(PKG_CONFIG) gtk+-2.0 --libs`
+ 
+-FLAGS = -O2 -Wall $(GTK_INCLUDE) 
++CFLAGS += -O2 -Wall $(GTK_INCLUDE) 
+ LIBS = $(GTK_LIB)
+ CFLAGS += -fPIC
+ LDFLAGS += -shared
+ 
+-CC = gcc $(FLAGS)
++CC = gcc
++INSTALL ?= install
+ 
+ OBJS = gkrellshoot.o
+ 
+ gkrellshoot.so: $(OBJS)
+-  $(CC) $(OBJS) -o gkrellshoot.so $(LDFLAGS) $(LIBS) 
++  $(CC) $(CFLAGS) $(OBJS) -o gkrellshoot.so $(LDFLAGS) $(LIBS) 
+ 
+ clean:
+   rm -f *.o core *.so* *.bak *~
+@@ -19,7 +21,7 @@
+ gkrellshoot.o: gkrellshoot.c
+ 
+ install:
+-  install -D -p -s -m 644 gkrellshoot.so 
$(DESTDIR)/usr/lib/gkrellm2/plugins/gkrellshoot.so
++  $(INSTALL) -D -p -s -m 644 gkrellshoot.so 
$(DESTDIR)/usr/lib/gkrellm2/plugins/gkrellshoot.so
+ 
+ uninstall:
+   rm -f $(DESTDIR)/usr/lib/gkrellm2/plugins/gkrellshoot.so
diff --minimal -Nru gkrellshoot-0.4.4/debian/patches/series 
gkrellshoot-0.4.4/debian/patches/series
--- gkrellshoot-0.4.4/debian/patches/series 2016-11-14 03:55:43.0 
+0100
+++ gkrellshoot-0.4.4/debian/patches/series 2020-04-19 18:00:08.0 
+0200
@@ -1 +1,2 @@
 install.patch
+cross.patch
diff --minimal -Nru gkrellshoot-0.4.4/debian/rules 
gkrellshoot-0.4.4/debian/rules
--- gkrellshoot-0.4.4/debian/rules  2016-04-17 02:42:59.0 +0200
+++ gkrellshoot-0.4.4/debian/rules  2020-04-19 18:00:25.0 +0200
@@ -7,3 +7,6 @@
 
 %:
dh $@
+
+override_dh_auto_install:
+   dh_auto_install -- INSTALL='install --strip-program=true'

Bug#958220: vncsnapshot FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: vncsnapshot
Version: 1.2a-5.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

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

Helmut
diff --minimal -Nru vncsnapshot-1.2a/debian/changelog 
vncsnapshot-1.2a/debian/changelog
--- vncsnapshot-1.2a/debian/changelog   2012-06-06 18:56:25.0 +0200
+++ vncsnapshot-1.2a/debian/changelog   2020-04-19 21:26:34.0 +0200
@@ -1,3 +1,10 @@
+vncsnapshot (1.2a-5.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 19 Apr 2020 21:26:34 +0200
+
 vncsnapshot (1.2a-5.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru vncsnapshot-1.2a/debian/rules vncsnapshot-1.2a/debian/rules
--- vncsnapshot-1.2a/debian/rules   2012-06-06 18:55:44.0 +0200
+++ vncsnapshot-1.2a/debian/rules   2020-04-19 21:26:33.0 +0200
@@ -27,7 +27,7 @@
 
 build-stamp: configure-stamp 
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch build-stamp
 
 clean: