Bug#893247: Intend to take over libjbzip2-java and libnanoxml2-java into Debian Med team

[Andreas Tille]

On Sun, Mar 25, 2018 at 11:56:18PM +0200, Emmanuel Bourg wrote:
> Le 25/03/2018 à 19:55, tony mancill a écrit :
> 
> > Multiple teams wanting to maintain a library is a good problem to have.
> > I propose we consider:
> > 
> > (a) pulling these libraries into the "Debian" project on Salsa, which
> > replaces collab-maint and grants commit permissions to all DDs and any
> > designated guest account
> 
> -1

:-)
 
> > (b) relaxing the default pkg-java permissions to be like those of the
> > Debian Perl Team and allow all DDs by default
> 
> +1, but note that this is basically how it already works today since any
> request to join the pkg-java group (or now java-team on Salsa) is always
> granted.

Same for Debian Med.  Its a bit sad that it can not easily be granted to
any DD any more to enable commits of team uploads / NMUs instantly but
require an extra step.

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#894071: RFS: gemmlowp/0~20180308-gf59a96b-1 [ITP]

[Lumin]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: gemmlowp
   Version : 0~20180308-gf59a96b-1
   Upstream Author : google
 * URL : https://github.com/google/gemmlowp
 * License : apache2
   Section : science

  It builds those binary packages:

libgemmlowp-dev - small self-contained low-precision GEMM library

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/g/gemmlowp/gemmlowp_0~20180308-gf59a96b-1.dsc

  More information about hello can be obtained from

http://debomatic-amd64.debian.net/distribution#experimental/gemmlowp/0~20180308-gf59a96b-1/buildlog

  Changes since the last upload:

gemmlowp (0~20180308-gf59a96b-1) experimental; urgency=medium

  * Initial release. (Closes: #848882)




-- 
Best,

Bug#894070: ca-certificates: Please remove myself from Uploaders

[Christian Perrier]

Package: ca-certificates
Version: 20170717
Severity: minor

Hello,

It's been a very long time since I uploaded ca-certificates, mostly
acting as a sponsor rather than real maintainer.

I'm currently trying to clean out my developer page, so that it
includes only packages I really feel responsiible for.

As a consequence, I suggest that I'm removed from Uploaders for this
package.

Many thanks in advance.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ca-certificates depends on:
ii  cdebconf [debconf-2.0]  0.241+b1
ii  debconf [debconf-2.0]   1.5.66
ii  openssl 1.1.0g-2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information excluded

Bug#894069: libgtk-3-dv: AM_PATH_GTK_3_0 misuses AC_PATH_PROG

[Helmut Grohne]

Package: libgtk-3-dev
Version: 3.22.29-2
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:terminatorx

AM_PATH_GTK_3_0 uses AC_PATH_PROG for finding pkg-config. Unfortunately,
that will find the build architecture pkg-config which in turn will miss
the host architecture gtk+3.0. What must be used here is the host
architecture pkg-config and that is found with AC_PATH_TOOL. Please
consider applying the attached patch.

If AM_PATH_GTK_3_0 was using PKG_PROG_PKG_CONFIG or even
PKG_CHECK_MODULES, this problem would have gone away entirely. Is there
a reason for not using these macros?

Helmut
Index: gtk+3.0-3.22.29/m4macros/gtk-3.0.m4
===
--- gtk+3.0-3.22.29.orig/m4macros/gtk-3.0.m4
+++ gtk+3.0-3.22.29/m4macros/gtk-3.0.m4
@@ -25,7 +25,7 @@
 
   no_gtk=""
 
-  AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
+  AC_PATH_TOOL(PKG_CONFIG, pkg-config, no)
 
   if test x$PKG_CONFIG != xno ; then
 if $PKG_CONFIG --atleast-pkgconfig-version 0.7 ; then
@@ -201,7 +201,7 @@
   min_gtk_version=ifelse([$2],,3.0.0,$2)
   pkg_config_args="$pkg_config_args >= $min_gtk_version"
 
-  AC_PATH_PROG(PKG_CONFIG, [pkg-config], [AC_MSG_ERROR([No pkg-config found])])
+  AC_PATH_TOOL(PKG_CONFIG, [pkg-config], [AC_MSG_ERROR([No pkg-config found])])
 
   if $PKG_CONFIG $pkg_config_args ; then
 target_found=yes

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

[James R. Barlow]

Package: ocrmypdf
Version: v6.0.0
Severity: serious
Tags: newcomer
Justification: fails to build from source (but built successfully in the past)

Dear Sean,

In v6.0.0, which addresses and hopefully fixes #888917, I have introduced a
new dependency on PyMuPDF (Python bindings for MuPDF).  Unfortunately PyMuPDF
isn't available in Debian as yet (I have checked there is no python3-pymupdf).

The build procedure should go like this:

  - download/unpack MuPDF to mupdf/
  - download/unpar PyMuPDF to pymupdf/
  - cp pymupdf/fitz/_mupdf_config.h mupdf/include/mupdf/fitz/config.h
  - export CFLAGS=-fPIC 
  - make HAVE_X11=no HAVE_GLFW=no HAVE_GLUT=no
  - patch pymupdf/setup.py to point library_dirs and include_dirs to the
output of mupdf/ build

The reason for this circumlocution is that the vendor of MuPDF, Artifex, 
does not provide or support dynamic libraries or a stable ABI, and 
compiling the Python bindings requires a dynamic library.  Perhaps as a way
to warn people about their stance, they don't enable -fPIC by default and
link their application statically.

This means that unfortunately, one cannot link to libmupdf-dev (and 
actually, I'm not sure if libmupdf-dev serves any purpose at all, unless 
it were rebuilt with -fPIC).  Certainly if the maintainers of this 
package could be persuaded to build it with -fPIC that would make this 
much easier.

I did try to build with it with Debian sid against the libmupdf-dev 
library. The error, as with Ubuntu, is:
  relocation R_X86_64_PC32 against symbol `fz_empty_irect' can not be 
used when making a shared object; recompile with -fPIC

The make options and replacement of the header file in mupdf are all 
disabling features unnecessary for PyMuPDF's purposes. It shrinks the 
binary from 30 MB to 3 MB.

The PyMuPDF developers describe their build process here:
https://github.com/rk700/PyMuPDF/wiki/Ubuntu-Installation-Experience

I'm happy to help with the packaging of this dependency, and I got it the
process working for Python binary wheels already.  However, I don't really
know much about Debian processes and policy.

Regards,
James

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

Kernel: Linux 4.4.119-boot2docker (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages ocrmypdf depends on:
pn  ghostscript   
pn  icc-profiles-free 
pn  liblept5  
ii  python3   3.6.5~rc1-1
pn  python3-cffi-backend-api-max  
pn  python3-cffi-backend-api-min  
pn  python3-img2pdf   
pn  python3-pil   
ii  python3-pkg-resources 39.0.1-1
pn  python3-pypdf2
pn  python3-reportlab 
pn  python3-ruffus
pn  qpdf  
pn  tesseract-ocr 
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages ocrmypdf recommends:
pn  unpaper  

Versions of packages ocrmypdf suggests:
pn  img2pdf  
pn  ocrmypdf-doc 
pn  python-watchdog  

Bug#894067: lxc: snapshotclone fails to work (LVM backend)

[Peter.Chubb]

Package: lxc
Version: 1:2.0.9-6
Severity: normal

Dear Maintainer,

I created an instance of stretch Debian on ext4 on a
thinly-provisioned LVM backend.  I attempt to clone it using a
snapshot.  Thus:

   $ sudo vgcreate lxc --dataalignment 512k -s 1M /dev/md0
(sizes chosen to match chunksize and stripewidth of underlying device)

   $ sudo lvcreate -l 50%VG --type=thin-pool -n lxc-pool lxc
   $ sudo lxc-create -n 'stretch-thin' --fssize=8G --fstype ext4 -B lvm 
--thinpool lxc-pool -t debian --  --mirror=http://mirror.aarnet.edu.au/debian/ 
-r stretch

Then:
   $ sudo lxc-copy -l DEBUG -s -n stretch-thin -N stretch-copy
   Using default stripesize 64.00 KiB.
   Logical volume "stretch-copy" created.
   lxc-copy: lxccontainer.c: container_destroy: 2576 Error destroying rootfs 
for stretch-copy
   clone failed

At this point, the container is half-created.
$ sudo ls -l /var/lib/lxc/stretch-copy/
total 4
-rw-r--r-- 1 root root 732 Mar 26 14:35 config
drwxr-xr-x 2 root root   6 Mar 26 14:35 rootfs

$ sudo lvs
  LV   VG  Attr   LSize   Pool Origin   Data%  Meta%  Move 
Log Cpy%Sync Convert
  lxc-pool lxc twi-aotz-- 931.38g   0.04   0.44 
  stretch-copy lxc Vwi---tz-k   8.00g lxc-pool stretch-thin
  stretch-thin lxc Vwi-a-tz--   8.00g lxc-pool  4.13

BUT:

$ sudo ls -l /dev/lxc
total 0
lrwxrwxrwx 1 root root 7 Mar 26 14:35 stretch-thin -> ../dm-4

and:

$ sudo lxc-start -n stretch-copy
lxc-start: lxccontainer.c: wait_on_daemonized_start: 754 Received container 
state "ABORTING" instead of "RUNNING"
lxc-start: tools/lxc_start.c: main: 368 The container failed to start.

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

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

Versions of packages lxc depends on:
ii  libapparmor1  2.11.0-3+deb9u2
ii  libc6 2.27-2
ii  libcap2   1:2.25-1
ii  libgnutls30   3.5.8-5+deb9u3
ii  liblxc1   1:2.0.9-6
ii  libseccomp2   2.3.1-2.1
ii  libselinux1   2.6-3+b3
ii  lsb-base  9.20161125
ii  python3   3.6.4-1
ii  python3-lxc   1:2.0.9-6

Versions of packages lxc recommends:
ii  bridge-utils  1.5-13+deb9u1
ii  debootstrap   1.0.89
ii  dirmngr   2.1.18-8~deb9u1
ii  dnsmasq-base  2.76-5+deb9u1
ii  gnupg 2.1.18-8~deb9u1
ii  iptables  1.6.0+snapshot20161117-6
ii  libpam-cgfs   2.0.7-1
ii  lxcfs 2.0.7-1
ii  openssl   1.1.0f-3+deb9u1
ii  rsync 3.1.2-1+deb9u1
ii  uidmap1:4.4-4.1

Versions of packages lxc suggests:
pn  apparmor 
pn  btrfs-progs  
ii  lvm2 2.02.168-2

-- no debconf information

Bug#885777: (no subject)

[Carlo Segre]

As far as I can tell libgnomecanvas2-0 is still in the distribution but 
fails to compile because it needs some packages which are unmaintained.


For the moment it is still in testing and unstable.

Carlo

On Sun, 25 Mar 2018, Denis Auroux wrote:

Uh, wait... the mailing list post from October 2017 announcing the 
deprecation and removal of libgnome and libgnomeui and other related 
libraries didn't even list libgnomecanvas among the libraries to be removed, 
or xournal among the affected packages -- perhaps showing awareness that 
libgnomecanvas is in fact not related to libgnome in any way.  Could it be 
that someone got overzealous and decided to remove libgnomecanvas for no good 
reason?  Perhaps that can still be undone?


Denis



--
Carlo U. Segre -- Duchossois Leadership Professor of Physics
Interim Chair, Department of Chemistry
Director, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org

Bug#894025: python-certbot-dns-cloudflare: Fails to build from source

[Harlan Lieberman-Berg]

Hm, so, we've never shipped the testdata.  All the way back to the first
tag (0.0.0.dev20151104-1), we've removed the testdata.  It's only for the
test cases, so we don't ship it out in the debs.

An update to the python version caused the way that it was being deleted to
break a while ago, it looks like.  A user reported it to me recently
because it was causing chkrootkit to trip on their systems, so I fixed the
removal in 8bb2938.

I'm not sure what we should do here.  Shipping the testdata isn't a huge
amount of resources for the end user, though it's a bit annoying that it's
causing some security stuff to complain.  We could create an intermediary
package that just ships the testdata that we could B-D on, but that seems
potentially unnecessary for the additional load on the ftpmasters and the
archive.  We could also ask upstream to ship the testdata that each package
needs with each package.

Thoughts?

On Sun, Mar 25, 2018 at 10:45 AM, Andrew Starr-Bochicchio 
wrote:

> On Sun, Mar 25, 2018 at 9:47 AM, Jeremy Bicha  wrote:
>>
>> error: [Errno 2] No such file or directory:
>> '/usr/lib/python3/dist-packages/certbot/tests/testdata/rsa512_key.pem'
>>
>> Full build log at
>> https://launchpad.net/ubuntu/+source/python-certbot-dns-clou
>> dflare/0.22.0-1/+build/14491162
>>
>
> Looks like this was caused by this change in the main certbot package:
>
> https://salsa.debian.org/letsencrypt-team/certbot/certbot/commit/
> 8bb2938afb15594cb79f8661d951724323f0e754
>
> Harlan, any more context on that or concerns about reverting?
>
> Thanks,
>
> -- Andrew Starr-Bochicchio
>
>Debian Developer 
>Ubuntu Developer 
>PGP/GPG Key ID: 3B56E2BBD53FDCB1
>
>


-- 
Harlan Lieberman-Berg
~hlieberman

Bug#885777: (no subject)

[Denis Auroux]

Uh, wait... the mailing list post from October 2017 announcing the 
deprecation and removal of libgnome and libgnomeui and other related 
libraries didn't even list libgnomecanvas among the libraries to be 
removed, or xournal among the affected packages -- perhaps showing 
awareness that libgnomecanvas is in fact not related to libgnome in any 
way.  Could it be that someone got overzealous and decided to remove 
libgnomecanvas for no good reason?  Perhaps that can still be undone?


Denis

Bug#894066: purple-matrix: Can't login: Invalid response from server

[Russell Stuart]

Package: purple-matrix
Version: 0.0.0+git20180325-1
Severity: grave
Tags: upstream
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Attemping to login to matrix.org now fails unconditionally, with
purple-matrix saying "Invalid response from homeserver" every
time.  This was triggered by matrix.org moving to cloudflare,
cloudflare using chunked encoding, and purple-matrix attempting
to parse the returned JSON after receiving the first chunk.

This was fixed upstream 8 hours ago:

https://github.com/matrix-org/purple-matrix/issues/72

I've rebuilt this purple-matrix package with the new sources and
verified it works, so all you need to is rebuild with the latest
sources on github.


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

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

Versions of packages purple-matrix depends on:
ii  libc6   2.24-11+deb9u3
ii  libglib2.0-02.50.3-2
ii  libhttp-parser2.1   2.1-2
ii  libjson-glib-1.0-0  1.2.6-1
ii  libpurple0  2.12.0-1

purple-matrix recommends no packages.

purple-matrix suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAlq4WxQACgkQrNSfiF5U
Um56AQ/+MP+mFYttABRfT+xG4brAd0dwrDsSGOOldRS5cHGj8w0yE8D0RK1W3cy2
p1jurenV6WJP6cKNLJGw1T+p/6R6gjFdbt3rqXIjUedmt3SMXtIK7u7Kwv0hkGBy
4+99bbkpEDjGZdOWO5tW74vFFV+OkBDDnSN/s3bnGO8L+MBFYVLzZcv8wJn+ok3e
hwQYoWr+uBUwrJKap5Dt4IG1l7fqjeY9cIIBH+QxSA3v/YnphPUXHUX3PEBQ/rGX
J1oOGlTSzvctW0QGRRQA6eGJm5JTZ3BFQLX47xDuQLv2tcg3w6NacMqi4pGzntXG
BvfOuOLQHeeVcRgtKo/NglrvZBV+Un1ufjHYkEQAGf2piojCpSibU76OUNSO0SQO
1J9EN3i9jduySP1AEwq/cdXg75s5dAsXstKb+aDiaa/rz8bG2iUQ6Itt+bfSt/y4
WQsw+aYNWkKN31DQzuMxcloc9MKKIHPpbCANPn/3pZO1VxGBAvxf4P3qc+Rp8G9m
bcIuzmgn8i71/dyvczSVItsZqKs704F6jlGjkyQ02IXk7PPrEfuEd4MEEs+DbXQc
s39HOFtfjXV41tSB2Q/t4J5rSMNbPcGy7Y78Z2q8xAjTn/ReQEFS/P1gyPVwstBe
/Z9uqTQeAAuWE0CA7NbYCrw+x6e7uE2wVwNyCOxiF6Ko/6xOxrI=
=ynIo
-END PGP SIGNATURE-

Bug#894065: tar: zstd support

[Adam Borowski]

Package: tar
Version: 1.29b-2
Severity: wishlist
Tags: patch


Hi!
Here's a patch that adds ZSTD support to tar.  It has been accepted upstream
(commit 3d45373d3b192d7342d49524193497598818d36d) but because of very slow
release cadence, and its poor alignment with Debian releases, we'd get this
goodie only in 3½ years from now.  Thus, I believe it's worthy to apply this
patch for Buster.

ZSTD is a new compression algorithm that beats the competition along a good
part from of the speed:ratio curve, from LZO to low levels of XZ.  For
example, with default settings, tarring a 16824672 byte executable takes:

compdecomp  size
xz  8.038s  0.356s  4320292
bz2 2.265s  0.730s  5234516
zst 0.274s  0.102s  5657626
gz  0.880s  0.152s  6515505
Z   0.499s  0.133s  8932459
lzo 0.100s  0.095s  9198874

If you plot this curve, especially compression speed is several times faster
than one would expect...


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

Kernel: Linux 4.16.0-rc6-debug-00108-g2c1be8f99900 (SMP w/6 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: sysvinit (via /sbin/init)

Versions of packages tar depends on:
ii  libacl1  2.2.52-3+b1
ii  libc62.27-2
ii  libselinux1  2.7-2+b1

tar recommends no packages.

Versions of packages tar suggests:
ii  bzip21.0.6-8.1
pn  ncompress
pn  tar-doc  
pn  tar-scripts  
ii  xz-utils 5.2.2-1.3

-- no debconf information
Description: zstd support
 Accept .tar.zst and .tzst, including magic sniffing.
Forwarded: accepted upstream

--- tar-1.29b.orig/configure.ac
+++ tar-1.29b/configure.ac
@@ -250,6 +250,7 @@ TAR_COMPR_PROGRAM(lzip)
 TAR_COMPR_PROGRAM(lzma)
 TAR_COMPR_PROGRAM(lzop)
 TAR_COMPR_PROGRAM(xz)
+TAR_COMPR_PROGRAM(zstd)
 
 AC_MSG_CHECKING(for default archive format)
 
--- tar-1.29b.orig/doc/tar.1
+++ tar-1.29b/doc/tar.1
@@ -825,6 +825,10 @@ Filter the archive through
 \fB\-Z\fR, \fB\-\-compress\fR, \fB\-\-uncompress\fR
 Filter the archive through
 .BR compress (1).
+.TP
+\fB\-\-zstd\fR
+Filter the archive through
+.BR zstd (1).
 .SS Local file selection
 .TP
 \fB\-\-add\-file\fR=\fIFILE\fR
--- tar-1.29b.orig/src/buffer.c
+++ tar-1.29b/src/buffer.c
@@ -270,7 +270,8 @@ enum compress_type {
   ct_lzip,
   ct_lzma,
   ct_lzop,
-  ct_xz
+  ct_xz,
+  ct_zstd
 };
 
 static enum compress_type archive_compression_type = ct_none;
@@ -299,6 +300,7 @@ static struct zip_magic const magic[] =
   { ct_lzma, 6, "\xFFLZMA" },
   { ct_lzop, 4, "\211LZO" },
   { ct_xz,   6, "\xFD" "7zXZ" },
+  { ct_zstd, 4, "\x28\xB5\x2F\xFD" },
 };
 
 #define NMAGIC (sizeof(magic)/sizeof(magic[0]))
@@ -314,6 +316,7 @@ static struct zip_program zip_program[]
   { ct_lzma, XZ_PROGRAM,   "-J" },
   { ct_lzop, LZOP_PROGRAM, "--lzop" },
   { ct_xz,   XZ_PROGRAM,   "-J" },
+  { ct_zstd, ZSTD_PROGRAM, "--zstd" },
   { ct_none }
 };
 
--- tar-1.29b.orig/src/suffix.c
+++ tar-1.29b/src/suffix.c
@@ -45,6 +45,7 @@ static struct compression_suffix compres
   { S(lzo,  LZOP) },
   { S(xz,   XZ) },
   { S(txz,  XZ) }, /* Slackware */
+  { S(zst,  ZSTD) },
   { NULL }
 #undef S
 #undef __CAT2__
--- tar-1.29b.orig/src/tar.c
+++ tar-1.29b/src/tar.c
@@ -348,7 +348,8 @@ enum
   WARNING_OPTION,
   XATTR_OPTION,
   XATTR_EXCLUDE,
-  XATTR_INCLUDE
+  XATTR_INCLUDE,
+  ZSTD_OPTION,
 };
 
 static char const doc[] = N_("\
@@ -682,6 +683,7 @@ static struct argp_option options[] = {
   {"lzma", LZMA_OPTION, 0, 0, NULL, GRID+1 },
   {"lzop", LZOP_OPTION, 0, 0, NULL, GRID+1 },
   {"xz", 'J', 0, 0, NULL, GRID+1 },
+  {"zstd", ZSTD_OPTION, 0, 0, NULL, GRID+1 },
 #undef GRID
 
 #define GRID 100
@@ -1129,6 +1131,10 @@ tar_help_filter (int key, const char *te
   s = xasprintf (_("filter the archive through %s"), XZ_PROGRAM);
   break;
 
+case ZSTD_OPTION:
+  s = xasprintf (_("filter the archive through %s"), ZSTD_PROGRAM);
+  break;
+
 case ARGP_KEY_HELP_EXTRA:
   {
const char *tstr;
@@ -1673,6 +1679,10 @@ parse_opt (int key, char *arg, struct ar
   set_use_compress_program_option (COMPRESS_PROGRAM, args->loc);
   break;
 
+case ZSTD_OPTION:
+  set_use_compress_program_option (ZSTD_PROGRAM, args->loc);
+  break;
+
 case ATIME_PRESERVE_OPTION:
   atime_preserve_option =
(arg

Bug#885777: (no subject)

[Denis Auroux]

libgnomecanvas is not related to libgnome in any way despite the name. 
It provides a high-performance canvas widget for GTK2, it is the 
standard canvas widget for GTK2. There is no good replacement for GTK3. 
I am not aware of any serious issues with it apart from it being old.


The two GTK3 canvases that aim to provide something similar to 
libgnomecanvas, foocanvas/geocanvas and goocanvas, are not so 
well-maintained, not as well-optimized, and not as standard as 
libgnomecanvas.  I don't want to invest a lot of effort into switching 
to one just to have Debian declare it deprecated the following year.


The official Debian line that libgnomecanvas is deprecated in favor of 
cairo is nonsense since the two don't offer equivalent functionality -- 
it's impossible to port libgnomecanvas software to rely only on cairo 
and the cairo ecosystem.


Please consider un-deprecating libgnomecanvas.  Despite the lack of 
active development, it is a useful library, has no security issues that 
I am aware of, and software that people want to use depends on it.


I don't have time to port xournal to GTK3 and a GTK3 canvas at the 
moment. You can try using the gtk3 branch from Daniel German's git 
repository, but I am not ready to adopt this as the main upstream 
xournal, and probably won't have time to migrate xournal to GTK3 or to a 
different canvas widget for the next couple of years at least.


If Debian persists, I would simply advise xournal users to install 
libgnomecanvas and xournal outside of the distribution's package manager.


Sincerely,
Denis Auroux

Bug#885777:

[Borden Rhodes]

I can't afford to lose this program. I've asked upstream what their
plans are to migrate to GTK+ 3. What can non C programmers do to help?

Bug#893930: mmm-mode: broken under XEmacs: Cannot open load file: cl-lib

[Aaron M. Ucko]

Alexander Zangerl  writes:

> (justification: affects only xemacs, and can be fixed by manually installing
> cl-lib.el.)

Fair enough; I was on the fence as to what severity to declare.

> i'll look at adding some backwards-compat logic for xemacs, but it'll take
> a few days.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#894064: openjdk-11: Please add patch for ia64 support

[John Paul Adrian Glaubitz]

Source: openjdk-11
Version: 11~5-1
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

The attached patch fixes OpenJDK-11 for ia64 (Zero). Please consider
applying it for the next upload.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-11-11~5/debian/patches/hotspot-ia64.diff 
new/openjdk-11-11~5/debian/patches/hotspot-ia64.diff
--- old/openjdk-11-11~5/debian/patches/hotspot-ia64.diff1970-01-01 
01:00:00.0 +0100
+++ new/openjdk-11-11~5/debian/patches/hotspot-ia64.diff2018-03-26 
02:41:36.451934089 +0200
@@ -0,0 +1,26 @@
+--- a/src/hotspot/share/runtime/os.cpp 2018-03-05 14:18:55.0 +0100
 b/src/hotspot/share/runtime/os.cpp 2018-03-26 02:26:44.607427867 +0200
+@@ -1145,7 +1145,7 @@
+ // if C stack is walkable beyond current frame. The check for fp() is not
+ // necessary on Sparc, but it's harmless.
+ bool os::is_first_C_frame(frame* fr) {
+-#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32)
++#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32) && !defined(LINUX)
+   // On IA64 we have to check if the callers bsp is still valid
+   // (i.e. within the register stack bounds).
+   // Notice: this only works for threads created by the VM and only if
+--- a/make/autoconf/platform.m42018-03-05 14:18:55.0 +0100
 b/make/autoconf/platform.m42018-03-26 02:28:39.067699053 +0200
+@@ -60,6 +60,12 @@
+   VAR_CPU_BITS=64
+   VAR_CPU_ENDIAN=little
+   ;;
++ia64)
++  VAR_CPU=ia64
++  VAR_CPU_ARCH=ia64
++  VAR_CPU_BITS=64
++  VAR_CPU_ENDIAN=little
++  ;;
+ m68k)
+   VAR_CPU=m68k
+   VAR_CPU_ARCH=m68k
diff -Nru old/openjdk-11-11~5/debian/rules new/openjdk-11-11~5/debian/rules
--- old/openjdk-11-11~5/debian/rules2018-03-22 00:43:24.0 +0100
+++ new/openjdk-11-11~5/debian/rules2018-03-26 03:14:41.436735774 +0200
@@ -319,6 +319,7 @@
8199220.diff \
machine-flag.diff \
zero-x32.diff \
+   hotspot-ia64.diff \
 
 #  m68k-support.diff \
 

Bug#894063: [patch] Link with gcc -shared, not ld; don't explicitly link with libc

[Matthias Klose]

Package: src:java3d
Version: 1.5.2+dfsg-13
Tags: patch

Please link with gcc -shared, not ld; don't explicitly link with libc.

- 02_fix_generic_ftbfs.patch: Link with gcc -shared, not ld; don't
  explicitly link with libc.
 
diff -Nru java3d-1.5.2+dfsg/debian/patches/02_fix_generic_ftbfs.patch java3d-1.5.2+dfsg/debian/patches/02_fix_generic_ftbfs.patch
--- java3d-1.5.2+dfsg/debian/patches/02_fix_generic_ftbfs.patch	2018-03-09 06:46:01.0 +0800
+++ java3d-1.5.2+dfsg/debian/patches/02_fix_generic_ftbfs.patch	2018-03-26 08:59:08.0 +0800
@@ -120,8 +120,8 @@
 +
 +
 +
-+
-+	
++
++	
 +
 +
 +  
@@ -133,8 +133,8 @@
 +
 +
 +
-+
-+	
++
++	
 +
 +
 +  

Bug#894062: openjdk-10: Please add patch for ia64 support

[John Paul Adrian Glaubitz]

Source: openjdk-10
Version: 10~46-2
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Hi!

The attached patch fixes OpenJDK-10 for ia64 (Zero). Please consider
applying it for the next upload.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru old/openjdk-10-10~46/debian/patches/hotspot-ia64.diff 
new/openjdk-10-10~46/debian/patches/hotspot-ia64.diff
--- old/openjdk-10-10~46/debian/patches/hotspot-ia64.diff   1970-01-01 
01:00:00.0 +0100
+++ new/openjdk-10-10~46/debian/patches/hotspot-ia64.diff   2018-03-26 
02:41:36.451934089 +0200
@@ -0,0 +1,26 @@
+--- a/src/hotspot/share/runtime/os.cpp 2018-03-05 14:18:55.0 +0100
 b/src/hotspot/share/runtime/os.cpp 2018-03-26 02:26:44.607427867 +0200
+@@ -1145,7 +1145,7 @@
+ // if C stack is walkable beyond current frame. The check for fp() is not
+ // necessary on Sparc, but it's harmless.
+ bool os::is_first_C_frame(frame* fr) {
+-#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32)
++#if (defined(IA64) && !defined(AIX)) && !defined(_WIN32) && !defined(LINUX)
+   // On IA64 we have to check if the callers bsp is still valid
+   // (i.e. within the register stack bounds).
+   // Notice: this only works for threads created by the VM and only if
+--- a/make/autoconf/platform.m42018-03-05 14:18:55.0 +0100
 b/make/autoconf/platform.m42018-03-26 02:28:39.067699053 +0200
+@@ -60,6 +60,12 @@
+   VAR_CPU_BITS=64
+   VAR_CPU_ENDIAN=little
+   ;;
++ia64)
++  VAR_CPU=ia64
++  VAR_CPU_ARCH=ia64
++  VAR_CPU_BITS=64
++  VAR_CPU_ENDIAN=little
++  ;;
+ m68k)
+   VAR_CPU=m68k
+   VAR_CPU_ARCH=m68k
diff -Nru old/openjdk-10-10~46/debian/rules new/openjdk-10-10~46/debian/rules
--- old/openjdk-10-10~46/debian/rules   2018-03-15 14:31:57.0 +0100
+++ new/openjdk-10-10~46/debian/rules   2018-03-26 02:46:26.974332045 +0200
@@ -327,6 +327,7 @@
mips-sigset.diff \
disable-doclint-by-default.diff \
make-4.2-workaround.diff \
+   hotspot-ia64.diff \
 
 ifeq ($(derivative),Ubuntu)
   COMMON_PATCHES += \

Bug#887682: r-cran-utf8: FTBFS on m68k: missing value where TRUE/FALSE needed

[Aaron M. Ucko]

Dylan Aïssi  writes:

> This package was built correctly for m68k on 2018-02-27 [1].
> Can we close this bug?

Yes, please.  IIRC, this failure turned out to stem from a problem with
the build setup (specifically, a qemu bug); sorry for the noise.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#882555: r-cran-ddalpha: FTBFS on m68k: no boost::math::Rlog1p

[Aaron M. Ucko]

Dylan Aïssi  writes:

> This package was built correctly for m68k on 2018-03-23 [1].
> Can we close this bug?

Yes, please.  IIRC, this failure turned out to stem from a problem with
the build setup (specifically, a qemu bug); sorry for the noise.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#887680: r-cran-git2r: FTBFS on m68k: missing value where TRUE/FALSE needed

[Aaron M. Ucko]

Dylan Aïssi  writes:

> This package was built correctly for m68k on 2018-02-27 [1].
> Can we close this bug?

Yes, please.  IIRC, this failure turned out to stem from a problem with
the build setup (specifically, a qemu bug); sorry for the noise.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#893309: post_upload_command output broken (Python 3 issue?)

[Mattia Rizzolo]

Control: tag -1 patch

On Sat, Mar 17, 2018 at 02:43:15PM -0700, Russ Allbery wrote:
> dput-ng throws an exception when reporting the output from a
> post_upload_command and does not show the output.  The exception is:
> 
> Traceback (most recent call last):
>   File "/usr/bin/dput", line 124, in 
> upload_package(changes, args)
>   File "/usr/lib/python3/dist-packages/dput/uploader.py", line 352, in 
> invoke_dput
> logger.warning("No hooks defined in the profile. "
>   File "/usr/lib/python3.6/contextlib.py", line 88, in __exit__
> next(self.gen)
>   File "/usr/lib/python3/dist-packages/dput/uploader.py", line 175, in 
> uploader
> obj._post_hook()
>   File "/usr/lib/python3/dist-packages/dput/uploader.py", line 68, in 
> _post_hook
> self._run_hook("post_upload_command")
>   File "/usr/lib/python3/dist-packages/dput/uploader.py", line 86, in 
> _run_hook
> sys.stdout.write(output)  # XXX: Fixme
> TypeError: write() argument must be str, not bytes
> 
> Looks like a Python 2 to Python 3 unicode handling issue?

I believe so, yes.

Russ, could you please double check this (currently untested) patch
solves the issue for you?

diff --git a/dput/uploader.py b/dput/uploader.py
index 19cb7f1..3c5df71 100644
--- a/dput/uploader.py
+++ b/dput/uploader.py
@@ -84,6 +84,7 @@ class AbstractUploader(object):
 return

 sys.stdout.write(output)  # XXX: Fixme
+sys.stdout.flush()
 if ret != 0:
 raise DputError(
 "Command `%s' returned an error: %s [err=%d]" % (
diff --git a/dput/util.py b/dput/util.py
index 6275a5b..6d42edf 100644
--- a/dput/util.py
+++ b/dput/util.py
@@ -96,6 +96,8 @@ def run_command(command):
 logger.error("Could not execute %s: %s" % (" ".join(command), e))
 return (None, None, -1)
 (output, stderr) = pipe.communicate()
+output = output.decode('utf-8', errors='replace')
+stderr = stderr.decode('utf-8', errors='replace')
 #if pipe.returncode != 0:
 #   error("Command %s returned failure: %s" % (" ".join(command), stderr))
 return (output, stderr, pipe.returncode)


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#894061: guake refuses to work with sway/wayland

[kardan]

Package: guake
Version: 3.0.4-1
Severity: wishlist

When sway is running on another tty, in a Xorg session guake fails on startup:

Traceback (most recent call last):
  File "/usr/bin/guake", line 10, in 
sys.exit(exec_main())
  File "/usr/lib/python3/dist-packages/guake/main.py", line 356, in exec_main
if not main():
  File "/usr/lib/python3/dist-packages/guake/main.py", line 333, in main
remote_object.show_hide()
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 70, in __call__
return self._proxy_method(*args, **keywords)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 145, in __call__
**keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in 
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Python.NameError: Traceback 
(most recent call last):
  File "/usr/lib/python3/dist-packages/guake/utils.py", line 31, in 
get_server_time
return GdkX11.x11_get_server_time(widget.get_window())
TypeError: argument window: Expected GdkX11.X11Window, but got 
__gi__.GdkWaylandWindow

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/service.py", line 707, in 
_message_cb
retval = candidate_method(self, *args, **keywords)
  File "/usr/lib/python3/dist-packages/guake/dbusiface.py", line 45, in 
show_hide
self.guake.show_hide()
  File "/usr/lib/python3/dist-packages/guake/guake_app.py", line 768, in 
show_hide
self.show()
  File "/usr/lib/python3/dist-packages/guake/guake_app.py", line 888, in show
time = get_server_time(self.window)
  File "/usr/lib/python3/dist-packages/guake/utils.py", line 36, in 
get_server_time
return get_local_timestamp()
NameError: name 'get_local_timestamp' is not defined

When sway is stopped, guake works as usual.

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

Kernel: Linux 4.14.0-3-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages guake depends on:
ii  gir1.2-glib-2.0   1.54.1-4
ii  gir1.2-gtk-3.03.22.29-1
ii  gir1.2-keybinder-3.0  0.3.2-1
ii  gir1.2-notify-0.7 0.7.7-3
ii  gir1.2-pango-1.0  1.40.14-1
ii  gir1.2-vte-2.91   0.52.0-1
ii  libglib2.0-bin2.56.0-2
ii  python3   3.6.4-1
ii  python3-cairo 1.16.2-1
ii  python3-dbus  1.2.6-1
ii  python3-gi3.26.1-2
ii  python3-pbr   3.1.1-4

guake recommends no packages.

Versions of packages guake suggests:
ii  libutempter0 1.1.6-3
pn  numix-gtk-theme  

-- no debconf information

Bug#894060: kiki: Bad Homepage link

[John Eikenberry]

Package: kiki
Version: 0.5.6-8.1
Severity: minor

The homepage link [1] for the package is bad, the domain expired and it is now
a parking page to buy the domain.

[1] http://project5.freezope.org/kiki

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

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

Versions of packages kiki depends on:
ii  python   2.7.13-2
ii  python-wxgtk3.0  3.0.2.0+dfsg-4

kiki recommends no packages.

kiki suggests no packages.

-- no debconf information

-- 

John Eikenberry
[ j...@zhar.net - http://zhar.net ]
[ PGP public key @ http://zhar.net/jae_at_zhar_net.gpg ]

"Perfection is attained, not when no more can be added, but when no more
 can be removed." -- Antoine de Saint-Exupery


signature.asc
Description: PGP signature

Bug#891161: cwidget: FTBFS with libncursesw6

[Manuel A. Fernandez Montecelo]

2018-03-24 11:01 GMT+01:00 Sven Joachim :
> Control: severity -1 important
>
> On 2018-03-10 22:55 +0100, Manuel A. Fernandez Montecelo wrote:
>
>> 2018-03-10 19:37 GMT+01:00 Sven Joachim :
>>> On 2018-02-25 00:55 +0100, Manuel A. Fernandez Montecelo wrote:
>>>
 2018-02-24 8:54 GMT+01:00 Sven Joachim :
>
> So here is a possible plan:
>
> - Do *not* fix this bug in unstable now, to exclude the possibility of
>   the above symbol lookup error after a cwidget rebuild when the ncurses
>   transition starts.
>
> - After ncurses has been accepted in experimental, upload cwidget there
>   too.  Rename the library package again, say to libcwidget3v6, and
>   build-depend on libncurses-dev (>= 6.0+20180210) to ensure that it gets
>   linked against libncursesw6 rather than libncursesw5.
>
> - When the ncurses transition starts in unstable, both aptitude and
>   cwidget still FTBFS.  Upload the new cwidget package to unstable, get
>   aptitude binNMU'ed, and everyone is happy.
>
> Does this sound reasonable?

 Yes, with the following comments/caveats (mostly reminders for myself,
 or somebody else if ends up doing this):

 - the "v5" suffix was for the GCC5 transition (changes due to C++11
 ABI), the name should be "libcwidget4" or something.  I wanted to
 change a couple of minor things and bump the soversion anyway, just
 never find the time to sort out all of the details, so let's see :)
>>>
>>> Do you think you can finish these changes this month?  So far I have
>>> only found one other showstopper[1] for the ncurses transition, and I
>>> intend to file a bug against release.debian.org in 2-3 weeks if nothing
>>> else crops up.
>>
>> Yes, very busy right now but should be more free in the last week, if
>> that's all right :)
>>
>> Feel free to ping me again, raise the severity of the bug or anything,
>> so I notice and remember.
>
> I intend to file a transition bug for ncurses tomorrow.  If you can
> finish the changes for libcwidget4 until Easter, that's probably
> sufficiently early, but I have also come up with a backup plan: declare
> a versioned Breaks against aptitude and bump shlibs in libcwidget3v5.
> This requires uploads for both cwidget and aptitude, but does not need
> to through NEW.
>
> See these branches for cwidget and aptitude:
> https://salsa.debian.org/joachim-guest/cwidget/commits/ncurses6
> https://salsa.debian.org/joachim-guest/aptitude/commits/ncurses6

That's good.  Sorry for not being more responsive, but I am massively
snowed under.

I was leaving this precisely for Easter, because I have like 5 days of
holidays in total :)


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#893300: cdebconf: Adding support for a pkg.cdebconf.nogtk build-profile

[Colin Watson]

On Sat, Mar 17, 2018 at 09:09:11PM +0100, Karsten Merker wrote:
> I would like to add support for a "pkg.cdebconf.nogtk" build-profile
> to cdebconf.  Background for that is that cdebconf (in particular
> libdebconfclient0) is needed rather early in the process of
> bootstrapping a new Debian architecture, but getting it built during
> early architecture bootstrap is difficult due to its build-dependency
> on gtk+cairo, which pulls in an enormous list of transitive
> build-dependencies that are effectively impossible to fullfill in a
> bootstrap scenario.

This approach and patch looks good to me.  I'm OK with you committing
and uploading it, modulo the comments below.

> diff --git a/debian/rules b/debian/rules
> index b2b35f4d..8b85a7af 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -21,6 +21,11 @@ LIBDEBCONF=libdebconfclient0
>  DEB_FRONTENDS=passthrough text newt gtk
>  UDEB_FRONTENDS=passthrough text newt gtk
>  
> +ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
> +DEB_FRONTENDS:=$(filter-out gtk,$(DEB_FRONTENDS))
> +UDEB_FRONTENDS:=$(filter-out gtk,$(UDEB_FRONTENDS))
> +endif

I think this would be clearer reversed, i.e.:

  DEB_FRONTENDS=passthrough text newt
  UDEB_FRONTENDS=passthrough text newt

  ifeq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
  DEB_FRONTENDS+=gtk
  UDEB_FRONTENDS+=gtk
  endif

> +ifneq ($(filter pkg.cdebconf.nogtk,$(DEB_BUILD_PROFILES)),)
> + dh_install -plibdebconfclient0-dev 
> src/modules/frontend/gtk/cdebconf_gtk.h usr/include/cdebconf/
> +endif

I think I may understand what this is doing now after some confusion,
but it's pretty opaque and definitely needs at least a comment.  I think
you're trying to keep the package contents identical regardless of build
profile, since the main build system won't handle it in this case due to
the change in *_FRONTENDS?

Thanks,

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

Bug#894059: installation-reports: rock64, difficult install

[Vagrant Cascadian]

Package: installation-reports
Severity: normal

A bit of a rough install, despite eventual success...

It required manually creating the boot media, appending all kernel
modules to the initrd, using a device-tree from a newer kernel version,
and installing u-boot-menu to have a working boot menu, and manually
marking the partition as bootable, so u-boot would try to boot from it.

More details in the Comments/Problems section.

live well,
  vagrant

-- Package-specific info:

Boot method: copied netboot files onto microSD
Image version: 
https://d-i.debian.org/daily-images/arm64/20180324-02:06/netboot/netboot.tar.gz
Date: 2018-03-25

Machine: rock64
Partitions: 
Filesystem Type 1K-blocksUsed Available Use% Mounted on
udev   devtmpfs   1992960   0   1992960   0% /dev
tmpfs  tmpfs   4095965308404288   2% /run
/dev/mmcblk0p6 ext4   5700724 1298352   4093076  25% /
tmpfs  tmpfs  2047980   0   2047980   0% /dev/shm
tmpfs  tmpfs 5120   0  5120   0% /run/lock
tmpfs  tmpfs  2047980   0   2047980   0% /sys/fs/cgroup
tmpfs  tmpfs   409596   0409596   0% /run/user/1000


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[O]
Configure network:  [E]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [E]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[ ]

Comments/Problems:

Had to manually create the boot media, as PXE boot didn't work with the 
vendor-provided u-boot. Had to create boot media by hand, by copying
files onto the boot media and creating a boot menu that the vendor
u-boot can read (e.g. extlinux.conf, or boot.scr).

Insufficient modules being available during the install, worked around
by appending all modules to the initrd.gz. This will hopefully be fixed
when d-i starts using 4.15.0-2 for the kernel version.

The ethernet detected fine, but a bug that prevented it from actually 
downloading data reliably. It is fixed in the device-tree in linux 
4.16-rc6, but worked fine using linux 4.15 in the installer with the 
device-tree from 4.16-rc6. That could probably be backported to 4.15.x.
Also ran the installer with 4.16-rc6, which seemed to work ok.

There was no bootloader configuration, but I worked around this by using
u-boot-menu to generate an extlinux.conf menu. I manually installed
linux 4.16-rc6 from experimental before rebooting, as it seems to be
better supported for this board.

The partitioner did not successfully mark the partition as bootable. I'm
guessing it partman doesn't support setting the legacy_boot flag on GPT
partitions?  This was needed for u-boot to choose which partition to
scan for the boot configuration.

-- 
==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20180324-02:04"
X_INSTALLATION_MEDIUM=netboot

==
Installer hardware-summary:
==
uname -a: Linux rk64 4.15.0-1-arm64 #1 SMP Debian 4.15.4-1 (2018-02-18) aarch64 
GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.15.0-1-arm64 ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.15.0-1-arm64 ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: DWC OTG Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.15.0-1-arm64 dwc2_hsotg
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: dm_mod143360  0
lsmod: md_mod159744  0
lsmod: xfs  1241088  0
lsmod: libcrc32c  16384  1 xfs
lsmod: jfs   196608  0
lsmod: btrfs1257472  0
lsmod: zstd_decompress77824  1 btrfs
lsmod: zstd_compress 163840  1 btrfs
lsmod: xxhash 16384  2 zstd_compress,zstd_decompress
lsmod: xor20480  1 btrfs
lsmod: raid6_pq  102400  1 btrfs
lsmod: ntfs  122880  0
lsmod: fuse  114688  0
lsmod: vfat   

Bug#894058: RM: gxine -- RoQA; orphaned, depends on ancient mozjs

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: gx...@packages.debian.org

gxine was orphaned in November by the MIA Team. [1]

It is one of the last packages depending on the ancient mozjs (the
SpiderMonkey JavaScript engine from um, Firefox 4, I believe). For
that reason, it was removed from Testing 6 months ago. [2]

mozjs has been replaced by mozj52 (corresponds with Firefox 52 ESR)
which is still supported by Mozilla.

gxine is still maintained somewhat upstream so if this issue is ever
fixed and there's a Debian maintainer, gxine can be reintroduced to
Debian. But for now, please remove gxine from Debian.

[1] https://bugs.debian.org/881509
[2] https://bugs.debian.org/863786
[3] https://sourceforge.net/projects/xine/files/gxine/

Thanks,
Jeremy Bicha

Bug#894057: ITP: golang-github-jedisct1-xsecretbox -- Go implementation of crypto_secretbox_xchacha20poly1305

[Eric Dorland]

Package: wnpp
Severity: wishlist
Owner: Eric Dorland 

* Package name: golang-github-jedisct1-xsecretbox
  Version : 0.0~git20180214.88b1956-1
  Upstream Author : Frank Denis
* URL : https://github.com/jedisct1/xsecretbox
* License : MIT
  Programming Lang: Go
  Description : Go implementation of crypto_secretbox_xchacha20poly1305

 xsecretbox is a Go implementation of crypto_secretbox_xchacha20poly1305.

Bug#893158: Pending fixes for bugs in the httpunit package

[pkg-java-maintainers]

tag 893158 + pending
thanks

Some bugs in the httpunit package are closed in revision
9639ef643c820283d32ffdf7d9fec91ab536acdc in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/httpunit.git/commit/?id=9639ef6

Commit message:

Fixed the build failure with Java 9 (Closes: #893158)

Bug#894054: radeontop: New upstream version, needed for VEGA support.

[John Paul Adrian Glaubitz]

Hi!

On 03/26/2018 05:47 AM, Boyd Stephen Smith Jr. wrote:
> I have a VEGA card and the latest radeontop from Debian does not recognize the
> card.  Upstream indicates that a newer version would at least partially 
> resolve
> the issue: https://github.com/clbr/radeontop/issues/57

There is currently no newer upstream available, upstream lists 1.0 as
the latest version, see [1]. I cannot upload a new upstream version
before the upstream developer tags it.

Please ask upstream to release a new upstream release first.

Adrian

> [1] https://github.com/clbr/radeontop/releases

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

Bug#893247: Intend to take over libjbzip2-java and libnanoxml2-java into Debian Med team

[gregor herrmann]

On Sun, 25 Mar 2018 23:29:13 +0200, Andreas Tille wrote:

> > (b) relaxing the default pkg-java permissions to be like those of the
> > Debian Perl Team and allow all DDs by default
> I'd prefer this a lot.  We did so for Debian Med on Alioth - I'm not
> sure how that works on Salsa but if we found out this will be
> established.

FWIW, the perl-team projects on Salsa are not DD-writable any more
because that's not as simple as it was on Alioth.
IIRC it's not possible to grant permissions ("share with ..") on a
group or sub-group level, only for each individual project, and that
takes ages via the API and whatnot.

I found my report from January:
https://lists.debian.org/debian-perl/2018/01/msg00045.html
  

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rolling Stones


signature.asc
Description: Digital Signature

Bug#893247: Bug#893268: Intend to take over libjbzip2-java and libnanoxml2-java into Debian Med team

[Emmanuel Bourg]

Le 25/03/2018 à 23:29, Andreas Tille a écrit :

> I'm fine with moving libjbzip2-java (which I uploaded today) once
> pkg-java has moved to Salsa (or did I missed the move?)

I'm working on the migration, I haven't finalized the notification hooks
yet.

Bug#893247: Intend to take over libjbzip2-java and libnanoxml2-java into Debian Med team

[Emmanuel Bourg]

Le 25/03/2018 à 19:55, tony mancill a écrit :

> Multiple teams wanting to maintain a library is a good problem to have.
> I propose we consider:
> 
> (a) pulling these libraries into the "Debian" project on Salsa, which
> replaces collab-maint and grants commit permissions to all DDs and any
> designated guest account

-1

> (b) relaxing the default pkg-java permissions to be like those of the
> Debian Perl Team and allow all DDs by default

+1, but note that this is basically how it already works today since any
request to join the pkg-java group (or now java-team on Salsa) is always
granted.

Emmanuel Bourg

Bug#894052: libwx-perl: autopkgtests are failing

[gregor herrmann]

On Sun, 25 Mar 2018 16:40:56 -0400, Jeremy Bicha wrote:

> libwx-perl's autopkgtests began failing March 21. That corresponds
> with when wxwidgets 3.0.4 was uploaded to unstable.
> 
> https://ci.debian.net/packages/libw/libwx-perl/unstable/amd64/

A binNMU has already been requested in #893923.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rolling Stones


signature.asc
Description: Digital Signature

Bug#886040: sugar: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of these bugs.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885819: almanah: Depends on gconf

[Jeremy Bicha]

Control: severity -1 serious
Control: tags -1 +patch

Actually, all you need to do is drop the Build-Depends on
libgconf2-dev. (No patch attached but this is a trivial fix.)

Thanks,
Jeremy Bicha

Bug#893179: Pending fixes for bugs in the icu4j-49 package

[pkg-java-maintainers]

tag 893179 + pending
thanks

Some bugs in the icu4j-49 package are closed in revision
48d80c71fceb30e9374a1f357b1c58231ba5bb61 in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/icu4j-49.git/commit/?id=48d80c7

Commit message:

Fixed the build failure with Java 9 (Closes: #893179)

Bug#886048: plasma-pa: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#757909: pulseaudio-module-gconf: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#894053: zathura: upstream switched to a different issue tracker, please re-forward Debian bug reports

[Francesco Poli]

On Sun, 25 Mar 2018 23:03:23 +0200 Sebastian Ramacher wrote:

> On 2018-03-25 22:50:26, Francesco Poli (wintermute) wrote:
> > Package: zathura
> > Version: 0.3.9-1
> > Severity: normal
> > 
> > Hello!
> > 
> > It seems to me that the old upstream issue tracker for zathura
> > is gone.
> > The upstream developers appear to have switched to a new
> > [repository](https://git.pwmt.org/pwmt/zathura) with its associated
> > [issue tracker](https://git.pwmt.org/pwmt/zathura/issues).
> > 
> > I think that all the Debian bug reports filed against package zathura
> > have to be re-forwarded to the new upstream issue tracker.
> > Could you please do so?
> 
> They were all migrated to the new system. The links might have changed, but 
> they
> are all there …

Thanks for your prompt reply!

However, I cannot find the new locations for the upstream issues
corresponding to the following Debian bug reports:

#733949
#733946
#733945
#733944

Could you please set the new forwarded URLs for the above Debian bug
reports? 

Thanks for your helpfulness.



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


pgpbSPZQh8doI.pgp
Description: PGP signature

Bug#886046: soundconverter: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886071: grdesktop: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886076: gnome-commander: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886051: ooo-thumbnailer: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886086: camorama: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#894056: gconf-editor: only useful for gconf which is being removed from Debian

[Jeremy Bicha]

Source: gconf-editor
Version: 3.0.1-4
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

As announced, we are working to remove gconf from Debian. As part of this 
process, I am now filing this RC bug.

References
--
https://lists.debian.org/debian-devel/2018/02/msg00169.html

https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-gnome-maintain...@lists.alioth.debian.org;tag=gconf

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885820: apcupsd: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#893247: Intend to take over libjbzip2-java and libnanoxml2-java into Debian Med team

[Andreas Tille]

Hi Emmanuel,

On Sun, Mar 25, 2018 at 10:55:54AM -0700, tony mancill wrote:
> On Sun, Mar 25, 2018 at 06:37:05PM +0200, Emmanuel Bourg wrote:
> > These are quite generic non-med related libraries, I'd prefer keeping them 
> > under the Java Team umbrella.

I'm fine with moving libjbzip2-java (which I uploaded today) once
pkg-java has moved to Salsa (or did I missed the move?)
 
> Multiple teams wanting to maintain a library is a good problem to have.
> I propose we consider:
> 
> (a) pulling these libraries into the "Debian" project on Salsa, which
> replaces collab-maint and grants commit permissions to all DDs and any
> designated guest account

Hmmm, I admit I prefer a real team since I have the impression that the
love a package receives is higher than for packages that end up in the
collab-maint / debian "dustbin".
 
> OR
> 
> (b) relaxing the default pkg-java permissions to be like those of the
> Debian Perl Team and allow all DDs by default

I'd prefer this a lot.  We did so for Debian Med on Alioth - I'm not
sure how that works on Salsa but if we found out this will be
established.
 
> OR
> 
> (c) configuring any other mechanism that would allow the union of these
> two teams (and others!) to contribute to the packaging.

Definitely.
 
> As for which team is listed in the Maintainer field, I don't think it
> matters much as long as we have a suitable set of interested Uploaders.

I agree that it does not matter much.  We have some lib*-java as well as
python-* and lib*-perl packages maintained in Debian Med team if there
are only Debian Med rdepends.  If we think about it like in the
libjbzip2-java case we should not only move back this one but also other
packages to the Java team.  That would be fine for me but there are
always cases where one needs to decide between (at least) two teams.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#886083: eclipse-platform: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#893049: libfiu FTBFS: recipe for target 'run-test-basic_ctrl.py' failed

[Alberto Bertogli]

On Sun, Mar 25, 2018 at 09:43:44PM +0100, Chris Lamb wrote:
> tags 893049 + fixed-upstream
> thanks
> 
> Hi Alberto,
> 
> > That also explains why it works when you go to the failed directory and
> > run it manually.
> 
> Ahh! Of course. :-)
> 
> > Can you give this patch a try?
> > https://blitiri.com.ar/git/r/libfiu/c/053239cab98817561187dfca491203401fae5b9c/
> 
> Works for me; looking forward to the new release!

Great!

Will try to cut it today, but might get pushed to tomorrow depending on
how the rest of my evening goes.


> (FYI did you see the SYNOPSIS → SYNOPSYS typo correction?)

Yes, I merged that patch last year (but thanks for checking! :)

Thanks!
Alberto

Bug#886082: foxtrotgps: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886067: gtkwave: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#890400: Any news about a new upstream version with new SONAME?

[Andreas Tille]

Looks strange.  May be you create a fresh clone and try again?

On Sun, Mar 25, 2018 at 08:51:11PM +0200, Julien Yann Dutheil wrote:
> Dear Andreas,
> 
> I moved forward with libbpp-seq, but after pushing I got the following
> message:
> 
> remote: Resolving deltas: 100% (172/172), completed with 152 local objects.
> remote:
> remote: To create a merge request for pristine-tar, visit:
> remote:
> https://salsa.debian.org/med-team/libbpp-seq/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar
> remote:
> remote: To create a merge request for upstream, visit:
> remote:
> https://salsa.debian.org/med-team/libbpp-seq/merge_requests/new?merge_request%5Bsource_branch%5D=upstream
> remote:
> 
> Clicking on the suggested links leads to a 404 error (I do not have
> permission to access this page).
> 
> Is everything ok or did I somehow do sthg wrong?
> 
> Best,
> 
> Julien.
> 
> On Thu, Mar 22, 2018 at 11:17 AM, Julien Yann Dutheil <
> julien.duth...@univ-montp2.fr> wrote:
> 
> > Hi Andreas,
> >
> > On Thu, Mar 22, 2018 at 10:17 AM, Andreas Tille  wrote:
> >
> >> Hi Julien,
> >>
> >> On Wed, Mar 21, 2018 at 09:26:01PM +0100, Julien Yann Dutheil wrote:
> >> > I could somehow udate the symbols list, but still get a lintian warning
> >> > [1].
> >>
> >> That was just a typo (see commit 06beb6872bb0c773aff727c25dfe07
> >> 77a7c401ca).
> >>
> >> Ok, thanks.
> >
> >
> >> > I have pushed my commits, would you mind giving them a look? Will
> >> > proceed with other libs once I have confirmation that everything is ok.
> >>
> >> I've just uploaded.  I think the following lintian *infos* (lintian -I)
> >> will be interesting for you:
> >>
> >> I: libbpp-core source: testsuite-autopkgtest-missing
> >> N:
> >> N:This package does not declare a test suite. Having a test suite
> >> helps
> >> N:with automated QA in response to changes in the archive. For
> >> example, if
> >> N:your package has a test suite, it is possible to re-execute that
> >> test
> >> N:suite when any of the package dependencies has a new version and
> >> check
> >> N:whether that update caused problems for your package.
> >> N:
> >> N:To declare a test suite, please add a debian/tests/control file to
> >> your
> >> N:package.
> >> N:
> >> N:For more information on how to add functional tests to your package,
> >> N:browse to https://ci.debian.net/doc/.
> >> N:
> >> N:Severity: wishlist, Certainty: certain
> >> N:
> >> N:Check: testsuite, Type: source
> >>
> >> May be you see a chance to tweak the build time test into an autopkgtest.
> >>
> >> Humm... not sure how that integrates with our existing series of unit
> > tests at build time?
> >
> > I: libbpp-core4: spelling-error-in-binary 
> > usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
> >> colums columns
> >> I: libbpp-core4: spelling-error-in-binary 
> >> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
> >> controled controlled
> >> I: libbpp-core4: spelling-error-in-binary 
> >> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
> >> wih with
> >>
> >> Please verify your code and simply fix with next upstream release if
> >> these are no false positives.
> >>
> >> Wow, impressive! Fixed upstream. fortunately, no interface break :)
> >
> >>
> >> Kind regards and thanks for your cooperation
> >>
> >> Thanks a lot for your patience and advice!
> >
> > Julien.
> >
> >>Andreas.
> >>
> >> --
> >> http://fam-tille.de
> >>
> >>
> >
> >
> > --
> > Julien Y. Dutheil, Ph-D
> > 0 (+49) 6421 178 986 <+49%206421%20178986>
> >
> > § Max Planck Institute for Evolutionary Biology
> > Molecular Systems Evolution
> > Department of Evolutionary Genetics
> > Plön -- GERMANY
> >
> > § Institute of Evolutionary Sciences - Montpellier
> > University of Montpellier 2 -- FRANCE
> >
> 
> 
> 
> -- 
> Julien Y. Dutheil, Ph-D
> 0 (+49) 4522 763 298
> 
> § Max Planck Institute for Evolutionary Biology
> Molecular Systems Evolution
> Department of Evolutionary Genetics
> Plön -- GERMANY
> 
> § Institute of Evolutionary Sciences - Montpellier
> University of Montpellier 2 -- FRANCE

-- 
http://fam-tille.de

Bug#885666: gpdftext: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#894055: gwyddion: Depends on gconf

[Jeremy Bicha]

Source: gwyddion
Version: 2.49-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends and build-depends on gconf, but gconf will be removed from 
Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html
https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#894054: radeontop: New upstream version, needed for VEGA support.

[Boyd Stephen Smith Jr.]

Package: radeontop
Version: 1.0-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

I have a VEGA card and the latest radeontop from Debian does not recognize the
card.  Upstream indicates that a newer version would at least partially resolve
the issue: https://github.com/clbr/radeontop/issues/57

Thank you for making Debian great.

- -- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (850, 
'proposed-updates'), (700, 'testing'), (500, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages radeontop depends on:
ii  libc6  2.27-2
ii  libdrm22.4.91-2
ii  libncurses56.0+20161126-1+deb9u2
ii  libpciaccess0  0.13.4-1+b2
ii  libtinfo5  6.0+20161126-1+deb9u2
ii  libxcb-dri2-0  1.12-1
ii  libxcb11.12-1

radeontop recommends no packages.

radeontop suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHQEARECADQWIQTFhn3a8g2plxzZYyjnmmovsbVAWQUCWrgK7xYcYnNzQGlndWFu
YXN1aWNpZGUubmV0AAoJEOeaai+xtUBZPwQAoIUHws90knbp/ZVqTIhFZrFDiEOq
AJ9NVj6uY0ho8F8d68dZXMilyF6pZQ==
=62Z4
-END PGP SIGNATURE-

Bug#886066: gxneur: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886056: morris: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886055: mssh: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886052: ogmrip: raising severity of gconf dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we are working to remove gconf from Debian. As part of this 
process, I am now raising the severity of this bug.

Please try to port your package away from gconf. Otherwise, please consider 
requesting that your package be removed from Debian to help us complete this 
goal.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#832566: systemd-machined breaks automounting nfs shares

[John Pearson]

Hi Michael,

If I disable libvirtd, systemd-machined isn't started.

Can't say if this problem also occurs in Stretch - this is the only 
machine with this configuration I have access to, and upgrading to 
Stretch is on hold due to other considerations; I'll see if I can create 
a similar environment to check, or failing that report back when it's 
upgraded.


Regards,


John Pearson.

On 25/03/18 07:11, Michael Biebl wrote:

On Tue, 28 Mar 2017 07:39:58 +0200 Michael Biebl  wrote:

Am 27.10.2016 um 23:13 schrieb John Pearson:

Hello Michael,

Thanks for looking at this.

On 22/10/16 11:07, Michael Biebl wrote:

Am 27.07.2016 um 02:59 schrieb John Pearson:

Hello Michael,

After the problem first occurred I reviewed bug #767468 and purged both
cgmanager and sytemd-shim, but the problem remained.  And, of course,
/proc shows systemd-machined (and only systemd-machined) still "thought"
/nfs/home was mounted.

Why is systemd-machined running? Do you have any systemd-nspawn
containers running where /home is symlinked or bind-mounted?

I have no idea - it was installed as part of the systemd package, and
starts automatically at boot.  The machine runs a single KVM instance
hosting Windows 7, managed by libvirtd.


If you stop systemd-machined, is the problem gone?

That seems to fix it without any obvious drawbacks, but I assume I'd
have to do the same after each reboot.


Is machined started by libvirtd then? What if you systemctl disable
libvirtd.service, does systemd-machined.service still start?

Can you reproduce the problem with stretch, i.e. with systemd v232?

Is this still reproducible with stretch?



--
*email:*j...@huiac.com  
"The greatest shortcoming of the human race
is our inability to understand
the exponential function."
- Albert Allen Bartlett
*web:*  http://www.huiac.com/
*mob:*  +61 407 391 169
*phone:*+61 8 7127 6275

Bug#894053: zathura: upstream switched to a different issue tracker, please re-forward Debian bug reports

[Francesco Poli (wintermute)]

Package: zathura
Version: 0.3.9-1
Severity: normal

Hello!

It seems to me that the old upstream issue tracker for zathura
is gone.
The upstream developers appear to have switched to a new
[repository](https://git.pwmt.org/pwmt/zathura) with its associated
[issue tracker](https://git.pwmt.org/pwmt/zathura/issues).

I think that all the Debian bug reports filed against package zathura
have to be re-forwarded to the new upstream issue tracker.
Could you please do so?

Thanks for your time.
Bye.

Bug#893049: libfiu FTBFS: recipe for target 'run-test-basic_ctrl.py' failed

[Chris Lamb]

tags 893049 + fixed-upstream
thanks

Hi Alberto,

> That also explains why it works when you go to the failed directory and
> run it manually.

Ahh! Of course. :-)

> Can you give this patch a try?
> https://blitiri.com.ar/git/r/libfiu/c/053239cab98817561187dfca491203401fae5b9c/

Works for me; looking forward to the new release!

(FYI did you see the SYNOPSIS → SYNOPSYS typo correction?)


Best wishes,

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

Bug#894000: [Pkg-dns-devel] Bug#894000: bind9rndc: connect failed: 127.0.0.1#953: connection refused

[Bernhard Schmidt]

Control: tags -1 moreinfo

On 25.03.2018 11:04, Arthur Marsh wrote:

Hi Arthur,

> Package: bind9
> Version: 1:9.11.3+dfsg-1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> trying to upgrade bind9 and associated packages:
> 
> Setting up bind9 (1:9.11.3+dfsg-1) ...
> [] Stopping domain name service...: bind9rndc: connect failed: 
> 127.0.0.1#953: connection refused
> . ok 

Looks like BIND wasn't running at this point when the postinst script
tried to stop it for restarting.

> [FAIL] Starting domain name service...: bind9 failed!

And it failed starting as well. Anything in your syslog when you start bind?

What version are you coming from?

Bernhard

Bug#894052: libwx-perl: autopkgtests are failing

[Jeremy Bicha]

Source: libwx-perl
Version: 1:0.9932-2
Severity: important

libwx-perl's autopkgtests began failing March 21. That corresponds
with when wxwidgets 3.0.4 was uploaded to unstable.

https://ci.debian.net/packages/libw/libwx-perl/unstable/amd64/

Thanks,
Jeremy Bicha

Bug#894034: debian-installer: mount point /boot/efi

[Heinrich Schuchardt]

debian-installer/packages/partman-efi/check.d/efi starts with these lines:

if [ ! -d /proc/efi ] && [ ! -d /sys/firmware/efi ]; then
exit 0
fi

if [ -f /var/lib/partman/ignore_uefi ]; then
exit 0
fi


So it seems installation for EFI is only supported if the installer is
booted via EFI.

The armhf netinstall iso does not make use of the UEFI implementation of
u-boot in contrast to what Suse and Fedora do. So we get stuck in a
legacy mode of booting. This is unsatisfactory if we want to setup a
multi-boot installation.

Best regards

Heinrich

Bug#894051: kubernetes: CVE-2017-1002102

[Salvatore Bonaccorso]

Source: kubernetes
Version: 1.7.7+dfsg-3
Severity: grave
Tags: patch security upstream
Forwarded: https://github.com/kubernetes/kubernetes/issues/60814

Hi,

the following vulnerability was published for kubernetes.

CVE-2017-1002102[0]:
| In Kubernetes versions 1.3.x, 1.4.x, 1.5.x, 1.6.x and prior to
| versions 1.7.14, 1.8.9 and 1.9.4 containers using a secret, configMap,
| projected or downwardAPI volume can trigger deletion of arbitrary
| files/directories from the nodes where they are running.

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

For further information see:

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

Regards,
Salvatore

Bug#894050: xerces-c: CVE-2017-12627: Null pointer dereference while processing the path to DTD allows denial of service

[Salvatore Bonaccorso]

Source: xerces-c
Version: 3.2.0+debian-2
Severity: grave
Tags: patch security upstream

Hi,

the following vulnerability was published for xerces-c.

CVE-2017-12627[0]:
| In Apache Xerces-C XML Parser library before 3.2.1, processing of
| external DTD paths can result in a null pointer dereference under
| certain conditions.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-12627
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12627
[1] https://svn.apache.org/viewvc?view=revision=1819998
[2] https://xerces.apache.org/xerces-c/secadv/CVE-2017-12627.txt

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#894049: transition: ncurses

[Sven Joachim]

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

I would like to start a transition for ncurses, changing the soname of
the libraries from 5 to 6.  This affects a large number of packages
(about 600 of them), but should be doable almost exclusively via
binNMUs, with two exceptions:

- libcdk5 needs a sourceful upload and a rename of the library package,
  neither this package nor its three reverse dependencies should be
  rebuilt before that.  Please see https://bugs.debian.org/892280 and
  https://release.debian.org/transitions/html/auto-libcdk5.html.

- cwidget also needs a sourceful upload and either a package rename or a
  shlibs bump + versioned Breaks against aptitude, please see
  https://bugs.debian.org/891161 for details.  Fortunately both cwidget
  and aptitude currently FTBFS with libncursesw6, so there is no danger
  of incompatible combinations after binNMUs.

The packages libtinfo5, libncurses5 and libncursesw5 are still built, so
only packages depending on the multilib packages and the udeb become
uninstallable and need to be rebuilt right away: grub, readline and
screen.

Apart from cwidget/aptitude, I have not noticed any ncurses related
FTBFS bugs, and the API is unchanged.  However, there will certainly be
quite a few unrelated FTBFS problems, such as the recent switch to
openjdk-9 and the python3.6/python3-distutils breakage.

Suggested ben file (please check if it is correct):

title = "ncurses";
is_affected = .depends ~ 
/\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/;
is_good = .depends ~ 
/\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
is_bad = .depends ~ 
/\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/
 & ! .package ~ /\b(libncursesw5|libncurses5)\b/; 

Thanks for your consideration,
Sven


signature.asc
Description: PGP signature

Bug#894047: bulletml FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: bulletml
Version: 0.0.6-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

bulletml fails to cross build from source, because it uses the build
architecture compiler. Letting dh_auto_build pass cross tools to make
mostly fixes that except for the linking step of the tinyxml embedded
library. Also setting LD is required here. The attached patch does both
and makes bulletml cross build successfully. Please consider applying
it.

Why does bulletml use an embedded copy of tinyxml? Please consider using
the packaged version.

Helmut
diff --minimal -Nru bulletml-0.0.6/debian/changelog 
bulletml-0.0.6/debian/changelog
--- bulletml-0.0.6/debian/changelog 2017-11-22 23:13:46.0 +0100
+++ bulletml-0.0.6/debian/changelog 2018-03-25 21:32:30.0 +0200
@@ -1,3 +1,12 @@
+bulletml (0.0.6-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Also pass LD along.
+
+ -- Helmut Grohne   Sun, 25 Mar 2018 21:32:30 +0200
+
 bulletml (0.0.6-7) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru bulletml-0.0.6/debian/rules bulletml-0.0.6/debian/rules
--- bulletml-0.0.6/debian/rules 2017-11-22 23:13:46.0 +0100
+++ bulletml-0.0.6/debian/rules 2018-03-25 21:32:30.0 +0200
@@ -12,9 +12,9 @@
dh_testdir
rm -f src/calc.cpp #needs to be regenerated from src/calc.yy
rm -f src/*.o src/*/*.o
-   $(MAKE) -C src CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS)" libbulletml.a
+   dh_auto_build --sourcedirectory=src -- LD='$$(CXX)' 
CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS)" libbulletml.a
rm -f src/*.o src/*/*.o
-   $(MAKE) -C src CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS) -fPIC -fpic" \
+   dh_auto_build --sourcedirectory=src -- LD='$$(CXX)' 
CXXFLAGS="$(CXXFLAGS) $(CPPFLAGS) -fPIC -fpic" \
LDFLAGS="$(LDFLAGS) -Wl,-z,defs" libbulletml.so
touch $@
 

Bug#894048: RFS: urlwatch/2.9-1

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: p...@debian.org

Dear mentors,

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

 * Package name: urlwatch
   Version : 2.9-1
   Upstream Author : Thomas Perl
 * URL : https://thp.io/2008/urlwatch/
 * License : BSD-3-clause
   Section : web

It builds those binary packages:
  urlwatch   - tool for monitoring webpages for updates

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/urlwatch

Alternatively, one can download the package with dget using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/u/urlwatch/urlwatch_2.9-1.dsc

More information about urlwatch can be obtained from
https://github.com/thp/urlwatch.

Changes since the last upload:

urlwatch (2.9-1) unstable; urgency=medium

  * New upstream release
  * Removed patch included upstream (fixSetuptoolsWarning.diff)
  * Fixed lintian's tag default-mta-dependency-not-listed-first
  * Fixed some check-all-the-things warnings

Regards,

Maxime Werlen

Bug#893372: botan: armhf build still fails due to NEON usage

[Adam Majer]

Source: botan
Version: 2.4.0-1
Followup-For: Bug #893372

I've tested the patch on abel.d.o. The patch is also attached to
this report and for a few days the compiled version is on 
abel.d.o:~adamm/botan-2.4.0

- Adam
commit 67652aed9d0240dfee628a9a67f204d468df90d4
Author: Jack Lloyd 
Date:   Sun Mar 18 11:10:23 2018 -0400

Fix --disable-{neon,sse2,altivec} for simd_32 users

Using --disable-neon was not effective because simd_32 users had
special logic that would still enable it.

Index: botan-2.4.0/configure.py
===
--- botan-2.4.0.orig/configure.py
+++ botan-2.4.0/configure.py
@@ -1086,12 +1086,14 @@ class CompilerInfo(InfoObject): # pylint
 return self.isa_flags[arch_isa]
 return None
 
-def get_isa_specific_flags(self, isas, arch):
+def get_isa_specific_flags(self, isas, arch, options):
 flags = set()
 
 def simd32_impl():
 for simd_isa in ['sse2', 'altivec', 'neon']:
-if simd_isa in arch.isa_extensions and self.isa_flags_for(simd_isa, arch.basename):
+if simd_isa in arch.isa_extensions and \
+   simd_isa not in options.disable_intrinsics and \
+   self.isa_flags_for(simd_isa, arch.basename):
 return simd_isa
 return None
 
@@ -1586,7 +1588,7 @@ def yield_objectfile_list(sources, obj_d
 name = name.replace('.cpp', obj_suffix)
 yield os.path.join(obj_dir, name)
 
-def generate_build_info(build_paths, modules, cc, arch, osinfo):
+def generate_build_info(build_paths, modules, cc, arch, osinfo, options):
 # pylint: disable=too-many-locals
 
 # first create a map of src_file->owning module
@@ -1599,7 +1601,7 @@ def generate_build_info(build_paths, mod
 
 def _isa_specific_flags(src):
 if os.path.basename(src) == 'test_simd.cpp':
-return cc.get_isa_specific_flags(['simd'], arch)
+return cc.get_isa_specific_flags(['simd'], arch, options)
 
 if src in module_that_owns:
 module = module_that_owns[src]
@@ -1607,11 +1609,11 @@ def generate_build_info(build_paths, mod
 if 'simd' in module.dependencies():
 isas.append('simd')
 
-return cc.get_isa_specific_flags(isas, arch)
+return cc.get_isa_specific_flags(isas, arch, options)
 
 if src.startswith('botan_all_'):
 isas = src.replace('botan_all_', '').replace('.cpp', '').split('_')
-return cc.get_isa_specific_flags(isas, arch)
+return cc.get_isa_specific_flags(isas, arch, options)
 
 return ''
 
@@ -2931,7 +2933,7 @@ def main_action_configure_build(info_mod
 build_config.lib_sources = amalg_cpp_files
 template_vars['generated_files'] = ' '.join(amalg_cpp_files + amalg_headers)
 
-template_vars.update(generate_build_info(build_config, using_mods, cc, arch, osinfo))
+template_vars.update(generate_build_info(build_config, using_mods, cc, arch, osinfo, options))
 
 with open(os.path.join(build_config.build_dir, 'build_config.json'), 'w') as f:
 json.dump(template_vars, f, sort_keys=True, indent=2)

Bug#868403: mail-notification: Raising severity of libgnome dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. As part of this process, I
am now raising the severity of this bug.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#868427: grdesktop: Raising severity of libgnome dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. As part of this process, I
am now raising the severity of this bug.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#868422: gjiten: Raising severity of libgnomeui dependency bug

[Jeremy Bicha]

Control: severity -1 serious

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries. As part of this process, I
am now raising the severity of this bug.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#873227: Please upgrade to 4.1: Java 9 support

[tony mancill]

On Sun, Mar 25, 2018 at 04:03:59PM +0200, Markus Koschany wrote:
> Hi tony,
> 
> Am 25.03.2018 um 06:26 schrieb tony mancill:
> [...]
> 
> > I'm going to upload to experimental momentarily and ask others on the
> > Java Team if there any concern about uploading Gradle 3.4 to unstable.
> 
> Let's do it. I remember there were two failing packages with Gradle 3.4
> but BND might be fixed already thanks to Kai-Chung Yan. I guess we will
> solve the remaining issues as well eventually.

Done, and thank you for the pointer regarding BND.  There was a problem
with ivy failing to parse the POM for gradle-logging due to the
jansi-native dependency being added without a groupId (which just seems
weird to me).  Fortunately specifying the group explicitly resolved the
problem for BND.

Hopefully there is not too much additional fall-out from the update, but
I'll be watching for it.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#894046: libgtkdatabox FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: libgtkdatabox
Version: 1:0.9.3.0+dfsg-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

libgtkdatabox fails to cross build from source, because it uses the
build architecture pkg-config in a few places. Its ./configure correctly
detects the host architecture one, but it fails to use it later on. The
attached patch fixes those wrong uses and makes libgtkdatabox cross
build successfully. Please consider applying it.

Helmut
Index: libgtkdatabox-0.9.3.0+dfsg/configure.ac
===
--- libgtkdatabox-0.9.3.0+dfsg.orig/configure.ac
+++ libgtkdatabox-0.9.3.0+dfsg/configure.ac
@@ -64,7 +64,7 @@
 			ac_cv_enable_libglade=yes, ac_cv_enable_libglade=no)
 	if test x"$ac_cv_enable_libglade" = xyes; then
 		AC_DEFINE(USE_LIBGLADE, 1, Define if you want libglade support)
-		libglade_moduledir=`pkg-config libglade-2.0 --variable=moduledir`
+		libglade_moduledir=`$PKG_CONFIG libglade-2.0 --variable=moduledir`
 		AC_DEFINE_UNQUOTED(LIBGLADE_MODULEDIR, [$libglade_moduledir], [Libglade module directory])
 	else
 		AC_MSG_RESULT(not found)
@@ -91,9 +91,9 @@
 			ac_cv_enable_glade=yes, ac_cv_enable_glade=no)
 	if test x"$ac_cv_enable_glade" = xyes; then
 		AC_DEFINE(USE_GLADE, 1, Define if you want glade interface builder support)
-		glade_moduledir=`pkg-config gladeui-2.0 --variable=moduledir`
+		glade_moduledir=`$PKG_CONFIG gladeui-2.0 --variable=moduledir`
 		AC_DEFINE_UNQUOTED(GLADE_MODULEDIR, [$glade_moduledir], [Glade-3 module directory])
-		glade_catalogdir=`pkg-config gladeui-2.0 --variable=catalogdir`
+		glade_catalogdir=`$PKG_CONFIG gladeui-2.0 --variable=catalogdir`
 		AC_DEFINE_UNQUOTED(GLADE_CATALOGDIR, [$glade_catalogdir], [Glade-3 catalog directory])
 	else
 		AC_MSG_RESULT(not found)
Index: libgtkdatabox-0.9.3.0+dfsg/examples/Makefile.am
===
--- libgtkdatabox-0.9.3.0+dfsg.orig/examples/Makefile.am
+++ libgtkdatabox-0.9.3.0+dfsg/examples/Makefile.am
@@ -67,7 +67,7 @@
 			-DGSEAL_ENABLED\
 			-DGTK_DISABLE_SINGLE_INCLUDES\
 			@LIBGLADE_CFLAGS@ \
-			`pkg-config gtk+-2.0 --cflags`
+			`@PKG_CONFIG@ gtk+-2.0 --cflags`
 
 
 LDADD 			= $(top_builddir)/gtk/libgtkdatabox.la\
Index: libgtkdatabox-0.9.3.0+dfsg/gtk/Makefile.am
===
--- libgtkdatabox-0.9.3.0+dfsg.orig/gtk/Makefile.am
+++ libgtkdatabox-0.9.3.0+dfsg/gtk/Makefile.am
@@ -63,4 +63,4 @@
 			-DGTK_MULTIHEAD_SAFE=1\
 			-DGSEAL_ENABLE\
 			-DGTK_DISABLE_SINGLE_INCLUDES\
-			`pkg-config gtk+-2.0 --cflags`
+			`@PKG_CONFIG@ gtk+-2.0 --cflags`

Bug#894045: libvncserver: CVE-2018-7225

[Salvatore Bonaccorso]

Source: libvncserver
Version: 0.9.11+dfsg-1
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/LibVNC/libvncserver/issues/218

Hi,

the following vulnerability was published for libvncserver.

CVE-2018-7225[0]:
| An issue was discovered in LibVNCServer through 0.9.11.
| rfbProcessClientNormalMessage() in rfbserver.c does not sanitize
| msg.cct.length, leading to access to uninitialized and potentially
| sensitive data or possibly unspecified other impact (e.g., an integer
| overflow) via specially crafted VNC packets.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-7225
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7225
[1] https://github.com/LibVNC/libvncserver/issues/218

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#894044: zsh: CVE-2018-1071

[Salvatore Bonaccorso]

Source: zsh
Version: 5.4.2-3
Severity: normal
Tags: patch security upstream

Hi,

the following vulnerability was published for zsh.

CVE-2018-1071[0]:
| zsh through version 5.4.2 is vulnerable to a stack-based buffer
| overflow in the exec.c:hashcmd() function. A local attacker could
| exploit this to cause a denial of service.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1071
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1071
[1] 
https://sourceforge.net/p/zsh/code/ci/679b71ec4d852037fe5f73d35bf557b0f406c8d4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#893049: libfiu FTBFS: recipe for target 'run-test-basic_ctrl.py' failed

[Alberto Bertogli]

On Fri, Mar 16, 2018 at 03:28:24PM +, Chris Lamb wrote:
> Hi Alberto and Adrian
> 
> > https://github.com/lamby/pkg-libfiu/commit/9bf63e144117fbd382f4053a4338041b975b8c67
> […]
> > Thanks for coming up with a patch for this!
> 
> Actually the patch doesn't work. Or, rather, it's stranger than that. If
> I build the package using fairly vanilla scripts (or on the official buildds
> as Adrian as pointed out and reopened to match) the package fails to build,
> even with this patch.
> 
> However, if I then go into the failed build directory and run `make test`
> the test passes (same chroot/container!). Does that help diagnose it at
> all? :)

It does!  Sorry for the delay in replying.

It's a build race issue.  I managed to reproduce this locally by running
with -j 8 (but weirdly, not if I teed its output!).

That also explains why it works when you go to the failed directory and
run it manually.


Can you give this patch a try?
https://blitiri.com.ar/git/r/libfiu/c/053239cab98817561187dfca491203401fae5b9c/

Once you confirm it works (fingers crossed), I'll include it in the
master branch and cut a new release (it's been a while and there are
other changes as well).

Thanks a lot!
Alberto

Bug#894043: zsh: CVE-2018-1083

[Salvatore Bonaccorso]

Source: zsh
Version: 5.4.2-3
Severity: normal
Tags: patch security upstream

Hi,

the following vulnerability was published for zsh, filling a bug in
the BTS to keep track of the Debian fix. No DSA is IMHO warranted for
the zsh CVEs currently known.

CVE-2018-1083[0]:
|check bounds on PATH_MAX-sized buffer used for file completion
|candidates

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1083
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1083
[1] 
https://sourceforge.net/p/zsh/code/ci/259ac472eac291c8c103c7a0d8a4eaf3c2942ed7

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#892999: Provide pkg-config.multiarch

[Andrej Shadura]

Control: tag -1 wontfix

Hi Corentin,

On 15 March 2018 at 12:49, Corentin Noël  wrote:
> Package: pkgconf
> Version: 0.9.12-6
>
> The pkg-config package provides /usr/lib/pkg-config.multiarch file when
> pkgconf provides /usr/lib/pkgconf.multiarch
> I'm currently writing a function trying to "guess" the pkgconfig
> folders in a sysroot and having to read only one file reliably would be
> better.
> pkgconf could provide /usr/lib/pkg-config.multiarch the same way that
> it provides the /usr/bin/pkg-config substitution

I was willing to implement this at first, but when I started looking
into it more closely, I found that introducing
/usr/lib/pkg-config.multiarch is non-trivial to do correctly at this
point. Apart from that, it’s not part of pkg-config’s or pkgconf’s API
upstream or in Debian. I think you can achieve what you’re trying to
do without having to parse this file or knowing it exists at all.

If you see it differently, please do explain why and how having this
file is beneficial to what you do over other approaches (and I’m happy
to be convinced!), but for now I’m going to mark this bug as wontfix.

-- 
Cheers,
  Andrej

Bug#890400: Any news about a new upstream version with new SONAME?

[Julien Yann Dutheil]

Dear Andreas,

I moved forward with libbpp-seq, but after pushing I got the following
message:

remote: Resolving deltas: 100% (172/172), completed with 152 local objects.
remote:
remote: To create a merge request for pristine-tar, visit:
remote:
https://salsa.debian.org/med-team/libbpp-seq/merge_requests/new?merge_request%5Bsource_branch%5D=pristine-tar
remote:
remote: To create a merge request for upstream, visit:
remote:
https://salsa.debian.org/med-team/libbpp-seq/merge_requests/new?merge_request%5Bsource_branch%5D=upstream
remote:

Clicking on the suggested links leads to a 404 error (I do not have
permission to access this page).

Is everything ok or did I somehow do sthg wrong?

Best,

Julien.

On Thu, Mar 22, 2018 at 11:17 AM, Julien Yann Dutheil <
julien.duth...@univ-montp2.fr> wrote:

> Hi Andreas,
>
> On Thu, Mar 22, 2018 at 10:17 AM, Andreas Tille  wrote:
>
>> Hi Julien,
>>
>> On Wed, Mar 21, 2018 at 09:26:01PM +0100, Julien Yann Dutheil wrote:
>> > I could somehow udate the symbols list, but still get a lintian warning
>> > [1].
>>
>> That was just a typo (see commit 06beb6872bb0c773aff727c25dfe07
>> 77a7c401ca).
>>
>> Ok, thanks.
>
>
>> > I have pushed my commits, would you mind giving them a look? Will
>> > proceed with other libs once I have confirmation that everything is ok.
>>
>> I've just uploaded.  I think the following lintian *infos* (lintian -I)
>> will be interesting for you:
>>
>> I: libbpp-core source: testsuite-autopkgtest-missing
>> N:
>> N:This package does not declare a test suite. Having a test suite
>> helps
>> N:with automated QA in response to changes in the archive. For
>> example, if
>> N:your package has a test suite, it is possible to re-execute that
>> test
>> N:suite when any of the package dependencies has a new version and
>> check
>> N:whether that update caused problems for your package.
>> N:
>> N:To declare a test suite, please add a debian/tests/control file to
>> your
>> N:package.
>> N:
>> N:For more information on how to add functional tests to your package,
>> N:browse to https://ci.debian.net/doc/.
>> N:
>> N:Severity: wishlist, Certainty: certain
>> N:
>> N:Check: testsuite, Type: source
>>
>> May be you see a chance to tweak the build time test into an autopkgtest.
>>
>> Humm... not sure how that integrates with our existing series of unit
> tests at build time?
>
> I: libbpp-core4: spelling-error-in-binary 
> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
>> colums columns
>> I: libbpp-core4: spelling-error-in-binary 
>> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
>> controled controlled
>> I: libbpp-core4: spelling-error-in-binary 
>> usr/lib/x86_64-linux-gnu/libbpp-core.so.4.0.0
>> wih with
>>
>> Please verify your code and simply fix with next upstream release if
>> these are no false positives.
>>
>> Wow, impressive! Fixed upstream. fortunately, no interface break :)
>
>>
>> Kind regards and thanks for your cooperation
>>
>> Thanks a lot for your patience and advice!
>
> Julien.
>
>>Andreas.
>>
>> --
>> http://fam-tille.de
>>
>>
>
>
> --
> Julien Y. Dutheil, Ph-D
> 0 (+49) 6421 178 986 <+49%206421%20178986>
>
> § Max Planck Institute for Evolutionary Biology
> Molecular Systems Evolution
> Department of Evolutionary Genetics
> Plön -- GERMANY
>
> § Institute of Evolutionary Sciences - Montpellier
> University of Montpellier 2 -- FRANCE
>



-- 
Julien Y. Dutheil, Ph-D
0 (+49) 4522 763 298

§ Max Planck Institute for Evolutionary Biology
Molecular Systems Evolution
Department of Evolutionary Genetics
Plön -- GERMANY

§ Institute of Evolutionary Sciences - Montpellier
University of Montpellier 2 -- FRANCE

Bug#894030: linux-image-4.15.0-2-amd64: kernel memory leak while recording with audacity

[Dominique Dumont]

Hi

The oops related to USB were due to a DVB device attached to a 5m cable. This 
length 
of cable is the max supported by USB and was ok with my previous ASUS mobo, 
but leads to oops on this one.

I've removed kdeconnect and not the kernel log looks fine except for these 
lines:

sp5100_tco: I/O address 0x0cd6 already in use
 radeon :29:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x000f 
address=0x flags=0x]

Memory usage is still quite high .

When I began the recording the memory usage was:
$ smem -wt
Area   Used  Cache   Noncache 
firmware/hardware 0  0  0 
kernel image  0  0  0 
kernel dynamic memory   1143432 711624 431808 
userspace memory1385328 3040201081308 
free memory13910156   13910156  0 
--
   16438916   149258001513116

One hour later:

$ smem -wt
Area   Used  Cache   Noncache
firmware/hardware 0  0  0
kernel image  0  0  0
kernel dynamic memory   659182031819883409832
userspace memory2528836 5629241965912
free memory 73182607318260  0
--
   16438916   110631725375744

$ sudo cat /proc/slabinfo 
slabinfo - version: 2.1
# name
 : tunables: slabdata 
  
fuse_request  80 80400   404 : tunables000 : 
slabdata  2  2  0
fuse_inode39 39832   398 : tunables000 : 
slabdata  1  1  0
ccp-1-dmaengine-cmd-cache  0  0320   252 : tunables00   
 0 : slabdata  0  0  0
rpc_inode_cache   92 92704   468 : tunables000 : 
slabdata  2  2  0
ext4_groupinfo_4k  34020  34020144   281 : tunables000 : 
slabdata   1215   1215  0
ext4_inode_cache   51477  54060   1088   308 : tunables000 : 
slabdata   1802   1802  0
ext4_allocation_context512512128   321 : tunables00
0 : slabdata 16 16  0
ext4_io_end 1280   1280 64   641 : tunables000 : 
slabdata 20 20  0
ext4_extent_status  20271  22338 40  1021 : tunables000 : 
slabdata219219  0   
   
mbcache 1533   1533 56   731 : tunables000 : 
slabdata 21 21  0   

jbd2_journal_head   1122   1122120   341 : tunables000 : 
slabdata 33 33  0   

jbd2_revoke_table_s768768 16  2561 : tunables000 : 
slabdata  3  3  0   
  
fscrypt_info1664   1664 32  1281 : tunables000 : 
slabdata 13 13  0   

fscrypt_ctx 1360   1360 48   851 : tunables000 : 
slabdata 16 16  0   

RAWv6196196   1152   288 : tunables000 : 
slabdata  7  7  0   

UDPv6416416   1216   268 : tunables000 : 
slabdata 16 16  0   

tw_sock_TCPv6 34 34240   342 : tunables000 : 
slabdata  1  1  0   

request_sock_TCPv6  0  0304   262 : tunables000 : 
slabdata  0  0  0   
   
TCPv6195195   2176   158 : tunables000 : 
slabdata 13 13  0   

cfq_io_cq578578120   341 : tunables000 : 
slabdata 17 17  0   

cfq_queue544544240   342 : tunables000 : 
slabdata 16 16  0   

bsg_cmd0  0216   372 : tunables000 : 
slabdata  0  0  0   
   

Bug#894042: nictools-pci FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: nictools-pci
Version: 1.3.8-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

nictools-pci fails to cross build from source, because it uses the build
architecture toolchain. It seems to have had some cross support at an
earlier time, but that's dysfunctional now. In any case, using
dh_auto_build fixes the issue. Please consider applying the attached
patch.

Helmut
diff -u nictools-pci-1.3.8/debian/changelog nictools-pci-1.3.8/debian/changelog
--- nictools-pci-1.3.8/debian/changelog
+++ nictools-pci-1.3.8/debian/changelog
@@ -1,3 +1,10 @@
+nictools-pci (1.3.8-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 25 Mar 2018 20:25:24 +0200
+
 nictools-pci (1.3.8-2) unstable; urgency=low
 
   * QA upload.
diff -u nictools-pci-1.3.8/debian/rules nictools-pci-1.3.8/debian/rules
--- nictools-pci-1.3.8/debian/rules
+++ nictools-pci-1.3.8/debian/rules
@@ -6,26 +6,13 @@
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
 
-BUILD_ARCH:=$(DEB_BUILD_GNU_TYPE)
-# New cross-compilation policy may set the DEB_HOST_ARCH variable.
-ifdef DEB_HOST_ARCH
- ARCH:=$(DEB_HOST_ARCH)
-else
- # dpkg-cross sets the ARCH environment variable, so use it.
- ifdef ARCH
-  ARCH:=$(ARCH)
- else
-  ARCH:=$(BUILD_ARCH)
- endif
-endif
-
 build: build-arch build-indep
 build-arch: build-stamp
 build-indep: build-stamp
 
 build-stamp:
dh_testdir
-   $(MAKE) all
+   dh_auto_build -- all
touch build-stamp
 
 clean:

Bug#893929: libqt4-dev-bin: kopete FTBFS

[Lisandro Damián Nicanor Pérez Meyer]

Hi Jiri!

El viernes, 23 de marzo de 2018 18:25:29 -03 Jiri Palecek escribió:
> Package: libqt4-dev-bin
> Version: 4:4.8.7+dfsg-13
> Severity: normal
> Tags: patch
> File: /usr/bin/moc-qt4
> 
> Dear Maintainer,
> 
> I tried to rebuild kopete from source and got errors such as these:
> 
> Generating s5b.moc
> /mnt/extras/src/kopete-17.08.3/protocols/jabber/libiris/src/irisnet/noncore/
> cutestuff/bytestream.h:52: Parse error at "defined"
> 
> Apparently this is caused by a nonconformity of moc's preprocessor which
> manifests itself when macro
> 
> major(arg)

I reember this was an issue some time ago. I went ahead and rebuilt unstable's 
kopete and did it without issues. So I wonder why unstable kopete builds and 
your build doesnt :-/

For what it's worth, the next kopete version should be qt5 based.

Kinds regards, Lisandro.


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

Bug#892586: debhelper cannot be upgraded to 1.11.5 with make-guile instead of make

[Guillem Jover]

Hi!

On Sun, 2018-03-11 at 04:34:56 +0100, Jose Antonio Ortega Ruiz wrote:
> Package: debhelper
> Version: 11.1.4
> Severity: important

> I've got make-guile, instead of make, installed in my system.
> debhelper 11.1.5 introduces a dependency on make, forcing me to
> uninstall make-guile, even though the latter provides the package name
> "make" to (it's just make built with support for guile).  Could this
> be an oversight?

This would be easily fixed by making make-guile use a versioned make
Provides instead. The other less optimal solution would be to hunt
down any package depending on make and add an alternative make-guile
dependency. Not reassigning, to let Niels decide what he'd prefer. :)

Thanks,
Guillem

Bug#894041: love FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: love
Version: 0.9.1-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

love fails to cross build from source, because it configures for the
build architecture compiler by not passing the relevant --host flag. The
simplest way to fix that is deferring it to dh_auto_configure.
Furthermore pkg-config must be prefixed with the host architecture, but
letting dpkg's buildtools.mk take care of that is easier. After doing
both, love cross builds successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru love-0.9.1/debian/changelog love-0.9.1/debian/changelog
--- love-0.9.1/debian/changelog 2016-08-03 22:37:52.0 +0200
+++ love-0.9.1/debian/changelog 2018-03-25 20:04:20.0 +0200
@@ -1,3 +1,10 @@
+love (0.9.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use dh_auto_configure and buildtools.mk. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 25 Mar 2018 20:04:20 +0200
+
 love (0.9.1-4) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru love-0.9.1/debian/rules love-0.9.1/debian/rules
--- love-0.9.1/debian/rules 2016-08-03 22:37:52.0 +0200
+++ love-0.9.1/debian/rules 2018-03-25 20:04:14.0 +0200
@@ -5,16 +5,15 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+-include /usr/share/dpkg/buildtools.mk
+PKG_CONFIG ?= pkg-config
+
 CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS)
 LDFLAGS:=$(shell dpkg-buildflags --get LDFLAGS) -Wl,-z,defs -Wl,-as-needed
 
 CONFIGURE_OPTIONS:= \
-   $(CROSS) \
-   --prefix=/usr \
-   --mandir=\$${prefix}/share/man \
-   --infodir=\$${prefix}/share/info \
CPPFLAGS="$(CPPFLAGS)" \
CFLAGS="$(CFLAGS)" \
CXXFLAGS="$(CXXFLAGS)" \
@@ -27,10 +26,10 @@
libtoolize
dh_autoreconf
 
-   if pkg-config luajit ; then echo + Using luagit ; \
-   ./configure $(CONFIGURE_OPTIONS) --with-lua=luajit ; \
+   if $(PKG_CONFIG) luajit ; then echo + Using luagit ; \
+   dh_auto_configure -- $(CONFIGURE_OPTIONS) --with-lua=luajit ; \
else echo + Using lua ; \
-   ./configure $(CONFIGURE_OPTIONS) --with-lua=lua ; \
+   dh_auto_configure -- $(CONFIGURE_OPTIONS) --with-lua=lua ; \
fi
 
cd src/scripts/ && lua auto.lua boot graphics

Bug#863663: Letter to Santa

[Francesco Poli]

On Thu, 21 Dec 2017 11:57:51 -0500 Nicolas Dufresne wrote:

> Le jeudi 21 décembre 2017 à 11:48 +0200, Sebastian Dröge a écrit :
> > On Wed, 2017-12-20 at 23:57 +0100, Francesco Poli wrote:
> > > 
> > > ;-)
> > > 
> > > Seriously: is there any progress (not documented on the bugzilla
> > > bug)? Please let me know.
> > 
> > The mailing list is no bug tracker and mails like this are not going to
> > motivate anybody, and at least in my case got rid of any motivation at
> > all to look at it.
> 
> I liked it, I think it was friendly and funny. It also motivated me to
> actually ask question and understand the problem. I don't have the time
> right now to fix it, but seems like something I have the skill to fix.
[...]

Hello Nicolas,
I am writing to you, since you said that you probably have the skill to
fix [bug 783267](https://bugzilla.gnome.org/show_bug.cgi?id=783267).

I don't know whether you have the time now, but, if you could find
some, it would be really really great!

Thanks for your helpfulness.
Bye.



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


pgpnvHOJfm_PH.pgp
Description: PGP signature

Bug#894040: RM: colorname -- RoM; RoQA; unmaintained; depends on gnome-python

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: colorn...@packages.debian.org

colorname was removed from Debian Testing in November because it
depends on gnome-python. [1] colorname appears to be no longer
maintained upstream.

Please remove colorname from Debian.

I got permission from the Debian maintainer David Paleino before
filing this bug.

[1] https://bugs.debian.org/845956

Thanks,
Jeremy Bicha

Bug#894039: crack-attack: please rebuild with a non-broken version of PKG_CHECK_MODULES

[Helmut Grohne]

Source: crack-attack
Version: 1.1.14-9.1
Severity: important
Justification: policy 4.13
User: helm...@debian.org
Usertags: rebootstrap

crack-attack fails to cross build from source, because it uses a broken,
outdated, embedded copy of PKG_CHECK_MODULES. Please update your copy of
PKG_CHECK_MODULES and rebuild configure from source.

This bug report comes without a patch, because the bug is already fixed.

If you insist on using embedded copies, please register them:
https://wiki.debian.org/EmbeddedCodeCopies

Helmut

Bug#893247: Intend to take over libjbzip2-java and libnanoxml2-java into Debian Med team

[tony mancill]

On Sun, Mar 25, 2018 at 06:37:05PM +0200, Emmanuel Bourg wrote:
> Hi Andreas,
> 
> These are quite generic non-med related libraries, I'd prefer keeping them 
> under the Java Team umbrella.
> 
> Emmanuel Bourg

Hi,

Multiple teams wanting to maintain a library is a good problem to have.
I propose we consider:

(a) pulling these libraries into the "Debian" project on Salsa, which
replaces collab-maint and grants commit permissions to all DDs and any
designated guest account

OR

(b) relaxing the default pkg-java permissions to be like those of the
Debian Perl Team and allow all DDs by default

OR

(c) configuring any other mechanism that would allow the union of these
two teams (and others!) to contribute to the packaging.

As for which team is listed in the Maintainer field, I don't think it
matters much as long as we have a suitable set of interested Uploaders.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#893525: CVE-2018-1000097

[Santiago Vila]

For completeness, I'm attaching here (so that it's also stored in our
BTS) the test file from the original report in decrypted and
uncompressed from. To reproduce:

unshar heap-buffer-overflow.bin

Thanks.

heap-buffer-overflow.bin
Description: Binary data

Bug#894038: gspiceui FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: gspiceui
Version: 1.1.00+dfsg-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gspiceui fails to cross build from source, because it uses the build
architecture compiler as a make default. The easiest way of passing
cross compilers is letting dh_auto_build do it. After doing so, gspiceui
cross builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru gspiceui-1.1.00+dfsg/debian/changelog 
gspiceui-1.1.00+dfsg/debian/changelog
--- gspiceui-1.1.00+dfsg/debian/changelog   2018-01-25 10:45:49.0 
+0100
+++ gspiceui-1.1.00+dfsg/debian/changelog   2018-03-25 19:37:34.0 
+0200
@@ -1,3 +1,10 @@
+gspiceui (1.1.00+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 25 Mar 2018 19:37:34 +0200
+
 gspiceui (1.1.00+dfsg-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru gspiceui-1.1.00+dfsg/debian/rules 
gspiceui-1.1.00+dfsg/debian/rules
--- gspiceui-1.1.00+dfsg/debian/rules   2018-01-25 10:45:49.0 +0100
+++ gspiceui-1.1.00+dfsg/debian/rules   2018-03-25 19:37:34.0 +0200
@@ -17,7 +17,7 @@
dh $@
 
 override_dh_auto_build:
-   CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(LDFLAGS)" $(MAKE)
+   CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(LDFLAGS)" dh_auto_build
 
 override_dh_auto_install:
$(MAKE) DESTDIR=$(CURDIR)/debian/gspiceui/usr install

Bug#893525: CVE-2018-1000097

[Salvatore Bonaccorso]

Hi Santiago, hi Moritz,

On Mon, Mar 19, 2018 at 06:20:44PM +0100, Santiago Vila wrote:
> On Mon, Mar 19, 2018 at 05:58:04PM +0100, Moritz Muehlenhoff wrote:
> > Source: sharutils
> > Severity: grave
> > Tags: security
> > 
> > This has been assigned CVE-2018-197:
> > http://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg4.html
> > 
> > Proposed patch at:
> > http://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg5.html
> 
> Thanks for the report. Simple question: Is this the same problem as this one?
> 
> http://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg3.html
> 
> or there will be another different CVE for that?

That's an issue on it's own, but I do not think it has a CVE assigned
yet. The most recent assigned CVE is for the msg4.html message,
which was adressed with the proposed fix (and can be verified with the
reproducer which first needs to be extracted).

The issue from the msg3.html is in src/unshar.c

391   for (;;)
392 {
393   size_t len = fread (rw_buffer, 1, rw_base_size, file);
394   if (len == 0)
395 break;
396   fwrite (rw_buffer, 1, len, shell_fp);
397 }

specifically at the write in line 396. 

There is no reply on
https://lists.gnu.org/archive/html/bug-gnu-utils/2018-02/msg3.html
so either it has been lost or ignored, might be worth reping the mail.

Regards,
Salvatore

Bug#894037: debian-installer: grub-efi installation not offered

[Heinrich Schuchardt]

Package: debian-installer
Version: 20171204
Severity: normal

I am installing Debian buster armhf on an iSCSI disk.
This is the image I am using:
debian-testing-armhf-netinst.iso2018-03-25 18:24

In contrast to the amd64 installer I am not offered the choice to
install GRUB.

On a system booting via UEFI grub-efi provides the boot menu to choose
the operating system.

Therefore on armhf and arm64 the package grub-efi should be offered for
installation.

Best regards

Heinrich Schuchardt

Bug#849354: (no subject)

[Thomas Adam]

Hi,

I'm afraid, despite all the suggestions mentioned, that I can't reproduce
this problem.

Can you pleae ensure you're able to reproduce this problem with fvwm2 built
from master, and if necessary, supply the minimal fvwm2rc file which shows
this problem?

One thing to bear in mind, when functions are involved, they'll grab the
XServer.  I'm wondering if you're noticing this on a laptop specifically
because of the ms timeouts on what FVWM considers a single click and a
doubleclick?

Kindly,
Thomas

Bug#825317:

[Francesc Zacarias]

I'm currently running debian sid with bash-completion package
version 1:2.7-1 and I'm still experiencing this issue.

Note that this was fixed in Ubuntu more than 2 years ago.
https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1390061

I applied the patch manually on my laptop and it addresses the problem.

Any chance you could merge this patch soon?

Bug#894035: linux-image-4.14.0-3-amd64: ACPI error with kernel 4.14.0-3-amd64

[Marc]

Package: src:linux
Version: 4.14.17-1
Severity: normal

Dear Maintainer,

When I boot my computer, I have the followed warning :

mars 25 18:51:17 Midgard kernel: ACPI Error: [DSSP] Namespace lookup 
failure, AE_NOT_FOUND (20170728/psargs-364)
mars 25 18:51:17 Midgard kernel: ACPI Error: Method parse/execution 
failed \_SB.PCI0.SAT0.SPT4._GTF, AE_NOT_FOUND (20170728/psparse-550)
mars 25 18:51:17 Midgard kernel: ACPI Error: [DSSP] Namespace lookup 
failure, AE_NOT_FOUND (20170728/psargs-364)
mars 25 18:51:17 Midgard kernel: ACPI Error: Method parse/execution 
failed \_SB.PCI0.SAT0.SPT4._GTF, AE_NOT_FOUND (20170728/psparse-550)
mars 25 18:51:17 Midgard kernel: ACPI Error: [DSSP] Namespace lookup 
failure, AE_NOT_FOUND (20170728/psargs-364)
mars 25 18:51:17 Midgard kernel: ACPI Error: Method parse/execution 
failed \_SB.PCI0.SAT0.SPT5._GTF, AE_NOT_FOUND (20170728/psparse-550)
mars 25 18:51:17 Midgard kernel: ACPI Error: [DSSP] Namespace lookup 
failure, AE_NOT_FOUND (20170728/psargs-364)
mars 25 18:51:17 Midgard kernel: ACPI Error: Method parse/execution 
failed \_SB.PCI0.SAT0.SPT5._GTF, AE_NOT_FOUND (20170728/psparse-550)


mars 25 18:51:18 Midgard kernel: usbhid 3-6.3:1.1: couldn't find an 
input interrupt endpoint


My computer seem work find, but this message are new.

Regards

-- Package-specific info:
** Version:
Linux version 4.14.0-3-amd64 (debian-ker...@lists.debian.org) (gcc 
version 7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.14.17-1 (2018-02-14)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.14.0-3-amd64 
root=UUID=adf75a18-c4e0-4908-9b83-7cde3e9db64d ro ipv6.disable=1 
ipv6.disable=1 quiet


** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[    2.899560] usb 3-12: Product: USB Storage
[    2.899561] usb 3-12: Manufacturer: Generic
[    2.911896] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    2.919499] snd_ctxfi :09:00.0: chip 20K2 model SB0880 
(1102:0042) is found

[    2.919509] snd_ctxfi :09:00.0: enabling device ( -> 0002)
[    2.924928] ACPI Warning: SystemIO range 
0x1828-0x182F conflicts with OpRegion 
0x1800-0x187F (\PMIO) (20170728/utaddress-247)
[    2.924933] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver
[    2.924935] ACPI Warning: SystemIO range 
0x1C40-0x1C4F conflicts with OpRegion 
0x1C00-0x1FFF (\GPR) (20170728/utaddress-247)
[    2.924937] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver
[    2.924938] ACPI Warning: SystemIO range 
0x1C30-0x1C3F conflicts with OpRegion 
0x1C00-0x1C3F (\GPRL) (20170728/utaddress-247)
[    2.924940] ACPI Warning: SystemIO range 
0x1C30-0x1C3F conflicts with OpRegion 
0x1C00-0x1FFF (\GPR) (20170728/utaddress-247)
[    2.924943] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver
[    2.924943] ACPI Warning: SystemIO range 
0x1C00-0x1C2F conflicts with OpRegion 
0x1C00-0x1C3F (\GPRL) (20170728/utaddress-247)
[    2.924946] ACPI Warning: SystemIO range 
0x1C00-0x1C2F conflicts with OpRegion 
0x1C00-0x1FFF (\GPR) (20170728/utaddress-247)
[    2.924948] ACPI: If an ACPI driver is available for this device, you 
should use it instead of the native driver

[    2.924949] lpc_ich: Resource conflict(s) found affecting gpio_ich
[    2.951618] Adding 8388604k swap on /dev/sdb2.  Priority:-2 extents:1 
across:8388604k FS

[    2.976024] usb 3-6.3: new low-speed USB device number 9 using xhci_hcd
[    3.081757] usb 3-6.3: New USB device found, idVendor=10d5, 
idProduct=000d
[    3.081758] usb 3-6.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[    3.081759] usb 3-6.3: Product: HA2-A3
[    3.081760] usb 3-6.3: Manufacturer: No brand
[    3.081761] usb 3-6.3: SerialNumber: 0\xc2\x92
[    3.086951] input: No brand HA2-A3 as 
/devices/pci:00/:00:14.0/usb3/3-6/3-6.3/3-6.3:1.0/0003:10D5:000D.0004/input/input5
[    3.144136] hid-generic 0003:10D5:000D.0004: input,hidraw3: USB HID 
v1.10 Keyboard [No brand HA2-A3] on usb-:00:14.0-6.3/input0

[    3.144835] usbhid 3-6.3:1.1: couldn't find an input interrupt endpoint
[    3.235424] snd_ctxfi :09:00.0: Use xfi-native timer
[    3.273222] input: PC Speaker as /devices/platform/pcspkr/input/input6
[    3.273393] EFI Variables Facility v1.08 2004-May-17
[    3.276773] input: Microsoft X-Box 360 pad as 
/devices/pci:00/:00:14.0/usb3/3-5/3-5:1.0/input/input7

[    3.276873] usbcore: registered new interface driver xpad
[    3.277062] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 
655360 ms ovfl timer

[    3.277063] RAPL PMU: hw unit of domain 

Bug#842292: libnss3: re-enable SSLKEYLOGFILE support

[Peter Wu]

severity -1 normal
tags -1 patch
--

Hi,

Raising the severity of this bug, it is a regression from NSS 3.24,
affecting all current NSS packages (in wheezy, jessie, stretch, buster
and sid).

Attached is a patch that re-enables the SSLKEYLOGFILE feature in the
debian rules file. Note that the official Mozilla Firefox builds do this
as well, see https://bugzilla.mozilla.org/show_bug.cgi?id=1188657

This feature can be used for troubleshooting issues or educational
purposes. For example, while trying to audit what background activity is
performed by Firefox, having this feature is essential for understanding
HTTPS sessions. Affected users are students and Kali Linux users.

Without this feature, people currently have at least three options:
- Install chromium which does have this feature.
- Download the official Firefox packages.
- Rebuild nss with this patch (not something for the average user).

Please consider restoring this feature.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
--- debian/rules.orig   2018-03-25 16:24:04.86400 +
+++ debian/rules2018-03-25 16:24:08.35600 +
@@ -109,6 +109,7 @@
NSPR_INCLUDE_DIR=/usr/include/nspr \
NSPR_LIB_DIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
BUILD_OPT=1 \
+   NSS_ALLOW_SSLKEYLOGFILE=1 \
NS_USE_GCC=1 \
OPTIMIZER="$(CFLAGS) $(CPPFLAGS)" \
LDFLAGS='$(LDFLAGS) $$(ARCHFLAG) $$(ZDEFS_FLAG)' \