Bug#875377: RM: hupnp -- ROM; unused, dead upstream

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

please remove hupnp: it was supposed to be used by kde4libs/solid, and
kipi-plugins, but the former does not use it anymore, and the latter
had an own copy which lately got moved (and modified) to digikam.
Also, the upstream is dead, with no commits nor releases in the last
four years.

Thanks,
-- 
Pino

Bug#875378: ITP: node-style-loader -- style loader module for webpack

[Daniel Ring]

Package: wnpp
Severity: wishlist
Owner: Daniel Ring 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-style-loader
  Version : 0.17.0
  Upstream Author : Tobias Koppers @sokra
* URL : https://github.com/webpack/style-loader
* License : Expat
  Programming Lang: JavaScript
  Description : style loader module for webpack

 This library is a style loader module for webpack.

 This library is a dependency for webpack. Webpack takes code targeted at
 node.js and adapts it to run in the browser. Node.js comes with an API of
 its own that is not available in browsers. Webpack exposes this code to
 programs that are unaware they are running in a browser.

 Node.js is an event-based server-side JavaScript engine.

Bug#874428: RFS: goldendict/1.5.0~git20160508.g92b5485-1.2 [RC, NMU]

[Tobias Frost]

Am Samstag, den 09.09.2017, 09:19 +0800 schrieb Boyuan Yang:

> Thank you for your mail. I believe this NMU should act as the
> beginning of 
> adoption. I am willing to package its newer snapshots and fix bugs
> later.

OK, but there should be big regressions. Otherwise we'd want to target
experimental first.

> It would be great if somebody could help sponsor this NMU now since
> the 
> original maintainer shows up and agrees with it.

I will take a look (if there is still need for an sponsor)
next weekend. (with some luck I will find time earlier, but cannot 
guarantee now)

If someone is faster grabbing the bug, go ahead, don't wait for me!

> Many thanks to everyone involved here. (especially the MIA team)
> 
> Regards,
> Boyuan Yang
> 

Bug#864964: autokey-qt: Depends on python-kde4 which is to be removed for Buster

[Scott Kitterman]

On Sun, 18 Jun 2017 01:29:04 -0400 Scott Kitterman  
wrote:
> Package: autokey-qt
> Version: 0.90.4-1
> Severity: important
> 
> Dear Maintainer,
> 
> During the Buster development cycle Qt4 is going to be removed.  As a
> result, PyQt4 and PyKDE4 will be removed as well.  This package depends
> on python-kde4.  If you want it to be part of the Buster release, it
> will have to be ported to Qt5 (Kf5 Python bindings are not available
> yet, but they are expected to be packaged early in the Buster
> development cycle).

autokey looks moribund upstream and I see no signs of a Qt5 port, so I think 
we should drop the -qt front end.  We are close to being able to remove 
PyKDE4, so please go ahead and drop the Qt front end.

I can do so via NMU if you'd prefer.

Scott K

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

Bug#864967: parley: Recommends python-kde4 which is to be removed for Buster

[Scott Kitterman]

On Sun, 18 Jun 2017 01:33:55 -0400 Scott Kitterman  
wrote:
> Package: parley
> Version: 4:16.08.3-1
> Severity: important
> 
> Dear Maintainer,
> 
> During the Buster development cycle Qt4 is going to be removed.  As a
> result, PyQt4 and PyKDE4 will be removed as well.  This package
> recommends python-kde4.  If you want it to be part of the Buster release,
> it will have to be ported to Qt5 (Kf5 Python bindings are not available
> yet, but they are expected to be packaged early in the Buster
> development cycle).

The current release of parley is Kf5, so updating the package to the current 
version should be enough to resolve this.  There is a legacy test.py file in 
the tarball, but it's for the KDE4 version of Parley, so can be safely 
ignored.  When updating Parley to the new version, just drop this Recommends.

Scott K

Bug#873755: vim-runtime: Perl plugin breaks Python keyword highlighting

[James McCoy]

Control: tag -1 fixed-upstream

On Wed, Aug 30, 2017 at 07:06:33PM +0200, Jakub Wilk wrote:
> The Perl filetype plugin breaks Python keyword highlighting.
> To reproduce, run:
> 
>vim -u NONE -U NONE -c 'syntax on' -c 'filetype plugin indent on' -c 'e 
> foo.pm' -c 'split bar.py'
> 
> Notice that "try" and "except are not highlighted as keywords.

This is due to 'iskeyword' being set globally in ftplugin/perl.vim.
That bug was fixed[0] almost 4 years ago upstream, but they haven't sent
updates to Bram for even longer.

[0]: 
https://github.com/vim-perl/vim-perl/commit/a21368569d16a53c765f8a3277259ecbeb01d599

Getting updated files to Bram has been brought up a couple times on
their tracker, but nothing's happened yet.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#874416: wordpress-shibboleth: XSS due to add_query_arg

[Craig Small]

On Wed, 6 Sep. 2017, 07:03 Dominic Hargreaves  wrote:

> I have just become aware of an old security issue that was fixed
> in upstream:
>
>
> https://github.com/michaelryanmcneill/shibboleth/commit/1d65ad6786282d23ba1865f5
> 6e2fd19188e7c26a
> 
>
>
> Given that noone has noticed and reported this as an issue for a year
> in the Debian package, and I'm not completely sure of how easy it is
> to exploit, I'm not exactly sure of the correct severity or whether
> this warrants a DSA or just a point release update. I'm CCing
> the Wordpress maintainer in case they have any ideas.
>
> This bug will be fixed in unstable shortly.
>
Hi,
  Probably a security team question but the un-patched plugin permits a XSS
attack so it should be a DSA I think.


 - Craig

> --
Craig Small https://dropbear.xyz/ csmall at : enc.com.au
Debian GNU/Linuxhttps://www.debian.org/   csmall at : debian.org
Mastodon: @smalls...@social.dropbear.xyz Twitter: @smallsees
GPG fingerprint:  5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#875360: FTBFS with Java 9: ant can't find tool(?)

[Emmanuel Bourg]

This is another dead project upstream (last release in 2005, doesn't
support Java bytecode >= 7) and unused in Debian (with a surprisingly
high popcon for an unused library though). I think this package should
be removed.

Bug#875376: libi8x: FTBFS on sparc64: bus errors in main test suite

[Aaron M. Ucko]

Source: libi8x
Version: 0.0.5-1
Severity: important
Tags: upstream
Justification: fails to build from source

The build of libi8x for sparc64 (admittedly not a release
architecture) has been failing with bus errors, generally a sign of
unaligned memory access.  Could you please take a look?

Thanks!

make  check-TESTS
../build-aux/test-driver: line 107: 25357 Bus error   "$@" > 
$log_file 2>&1
FAIL: bugs/test-bug-0001
../build-aux/test-driver: line 107: 25379 Bus error   "$@" > 
$log_file 2>&1
FAIL: bugs/test-bug-0002
../build-aux/test-driver: line 107: 25401 Bus error   "$@" > 
$log_file 2>&1
FAIL: bugs/test-bug-0003
../build-aux/test-driver: line 107: 25423 Bus error   "$@" > 
$log_file 2>&1
FAIL: exec/ops/test-deref
../build-aux/test-driver: line 107: 25445 Bus error   "$@" > 
$log_file 2>&1
FAIL: exec/test-factorial
../build-aux/test-driver: line 107: 25467 Bus error   "$@" > 
$log_file 2>&1
FAIL: exec/test-smoke
../build-aux/test-driver: line 107: 25489 Bus error   "$@" > 
$log_file 2>&1
FAIL: valid/test-corpus

-- 
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#874286: gnome-shell-pomodoro: uninstallable with gnome-shell 3.25+

[Joseph Herlant]

Control: tags -1 + pending

Hi,

The new version bringing compatibility with gnome-shell 3.26 is
available on mentors:
https://mentors.debian.net/package/gnome-shell-pomodoro

Checking with my current sponsor about the upload.

Thanks for your patience,
Joseph

Bug#875375: libi8x: FTBFS on non-Linux: libthread_db.c compilation errors

[Aaron M. Ucko]

Source: libi8x
Version: 0.0.5-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of libi8x for kFreeBSD and the Hurd (admittedly not release
architectures) have been failing due to compilation errors in
libthread_db.c.  On the Hurd, there is no  in the first
place.  On kFreeBSD, there are a bunch of warnings, mostly related to
the fact that psaddr_t is an integer rather than a pointer, and one
outright error:

  libthread_db.c:698:3: error: unknown type name 'elf_greg_t'

You can find the full logs at

https://buildd.debian.org/status/fetch.php?pkg=libi8x=hurd-i386=0.0.5-1=1505051410=0
https://buildd.debian.org/status/fetch.php?pkg=libi8x=kfreebsd-amd64=0.0.5-1=1505052145=0
https://buildd.debian.org/status/fetch.php?pkg=libi8x=kfreebsd-i386=0.0.5-1=1505051444=0

Could you please take a look?  If support for either or both kernels
is infeasible, you can restrict the package's Architecture field
accordingly.

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#875373: libi8x: FTBFS on s390x and sh4: TestPy8xNatfuncImpl trouble

[Aaron M. Ucko]

Source: libi8x
Version: 0.0.5-1
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

The latest builds of libi8x for s390x and the non-release architecture
sh4 have failed with errors testing the (new) Python bindings.  On
s390x, the test crashes:

  test_exec (tests.lo.test_py8x_natfunc_impl.TestPy8xNatfuncImpl)
  Test calling a native function. ... Segmentation fault
  debian/rules:17: recipe for target 'override_dh_auto_test' failed
  make[1]: *** [override_dh_auto_test] Error 139

On sh4, the test doesn't outright crash, but does hit two assertion
errors, as detailed at
https://buildd.debian.org/status/fetch.php?pkg=libi8x=sh4=0.0.5-1=1505052518=0

Could you please take a look?

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#875374: libi8x: FTBFS on alpha: two tests report "Invalid note"

[Aaron M. Ucko]

Source: libi8x
Version: 0.0.4-1
Severity: important
Tags: upstream
Justification: fails to build from source

The build of libi8x for alpha (admittedly not a release architecture)
has been failing, per the below excerpt from
https://buildd.debian.org/status/fetch.php?pkg=libi8x=alpha=0.0.5-1=1505056946=0

Could you please take a look?

Thanks!

FAIL: exec/test-factorial
=

exec/test-factorial.c:68: 
corpus/i8c/0.0.3/32el/test_loops/test_basic/0001-0001[0xe]: Invalid note
FAIL exec/test-factorial (exit status: 1)

FAIL: valid/test-corpus
===

corpus/i8c/0.0.4/32el/test_implicit_extern/test_implicit_extern/0001-0001[0xe]: 
Invalid note
corpus/i8c/0.0.4/32el/test_implicit_extern/test_implicit_extern/0001-0002[0xe]: 
Invalid note
corpus/i8c/0.0.4/32el/test_loops/test_basic/0001-0001[0xe]: Invalid note
[...]
corpus/glibc/0.00-2w/s390x/0001-0002[0x1e]: Invalid note
valid/test-corpus.c:159: ftw_failcount == 0
FAIL valid/test-corpus (exit status: 1)

-- 
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#875328: jellyfish1: FTBFS: __sync_val_compare_and_swap_8 undefined

[Aaron M. Ucko]

notfixed 875328 1.1.11-3
found 875328 1.1.11-3
thanks

"Aaron M. Ucko"  writes:

> Please link against -latomic, at least on these architectures.

Thanks for the quick upload, Andreas!  Alas, it looks like it will also
be necessary to port this code to __atomic_compare_exchange_8.

-- 
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#873499: Should depend on "gnupg | gnupg2 | gpg"

[Daniel Kahn Gillmor]

On Tue 2017-08-29 11:04:01 +0200, Yuri D'Elia wrote:
> On Tue, Aug 29 2017, Colin Watson wrote:
>>  This package contains /usr/bin/gpg itself, and is useful on its own
>>  only for public key operations (encryption, signature verification,
>>  listing OpenPGP certificates, etc).  If you want full capabilities
>>  (including secret key operations, network access, etc), please
>>  install the "gnupg" package, which pulls in the full suite of tools.
>>
>> pass requires secret key operations, not just public key operations.
>
> I've been using pass with gpg only already since gpg 2.1.23 became
> available using an equivs package to fulfill the dependency. Can you
> make an example of a "secret key operation"? 

an example of a secret key operation in pass is: decrypting an encrypted
password file.  if that is important to you, then you need at least
gpg-agent installed.

> I think gpg's description is misleading.

I'm sorry to hear that.  Can you suggest alternate wording that might be
more suitable?

> gpg can definitely generate and manipulate secret keys by itself for
> example.

I'm pretty sure that this is not true for the modern version of gpg.
You need gpg-agent.  here's a debian installation without gpg-agent,
trying to generate a key:

0 dkg@sid:~$ gpg --gen-key
gpg (GnuPG) 2.2.0; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory '/home/dkg/.gnupg' created
gpg: keybox '/home/dkg/.gnupg/pubring.kbx' created
Note: Use "gpg --full-generate-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: monkeypants
Email address: mon...@pants.example.org
You selected this USER-ID:
"monkeypants "

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: agent_genkey failed: No agent running
Key generation failed: No agent running
2 dkg@sid:~$ 


> The only difference is that you need to depend on dirmngr/gpgsm or the
> tools package explicitly.

The simplest thing is just to depend on the gnupg suite, and that is
totally reasonable for the "pass" package if the maintainer prefers it.
(it's also easier for rapid backporting) If the package maintainer wants
something fancier and more narrowly targeted, they could do something
like:

  Depends: gpg-agent, gpg
  Recommends: gnupg

since i don't believe that pass has any need for network access
(dirmngr) or X.509 or CMS (gpgsm).  But i don't know pass super well so
i can't guarantee that this is correct.

however, i've also considered just bundling *all* of the GnuPG suite
into a single "gnupg" package, and breaking out only "gpgv" from the lot
-- that would mean fewer packages installed overall (and therefore
probably fewer complaints from users who like "tight dependencies",
despite the fact that it would mean all the same binaries are actually
installed as the current variant where the binaries are all split into
separate packages).  I know that GnuPG upstream generally prefers to
have all the binaries installed together, so maybe that would be a
better approach if other debian packagers are annoyed by the package
split.

I certainly don't want most users to have to think about which specific
packages they need to install.

let me know what you think we should do!

  --dkg


signature.asc
Description: PGP signature

Bug#875372: inhomog: FTBFS on i386: test_alloc_big_array segmentation fault

[Aaron M. Ucko]

Source: inhomog
Version: 0.1.5-1
Severity: important
Tags: upstream
Justification: fails to build from source

The build of inhomog for i386 (but not any other 32-bit architectures)
failed:

  ../test-driver: line 107: 20956 Segmentation fault  "$@" > $log_file 2>&1
  FAIL: test_alloc_big_array

Could you please take a look?

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#856160: nettle-dev: Please transition nettle-dev to multi-arch

[Hugh McMaster]

On Monday, 11 September 2017 5:13 AM +1000, Niels Möller wrote:
> I made the following fix upstream:
> https://git.lysator.liu.se/nettle/nettle/commit/b7052093931d69d3626a54d59783e0d9e48ea20f
> 
> Not sure if you want something more minimal for a debian patch, but it
> would be nice if you can confirm it solves the problem.

With this upstream change, Debian systems now see the following code in 
version.h:
> #define NETTLE_USE_MINI_GMP 0
> 
> /* We need a preprocessor constant for GMP_NUMB_BITS, simply using
>sizeof(mp_limb_t) * CHAR_BIT is not good enough. */
> #if NETTLE_USE_MINI_GMP
> # define GMP_NUMB_BITS n/a
> #endif

Using "n/a" resolves the multi-arch conflict across Debian architectures.

Thank you!

--
Hugh McMaster

Bug#875340: FTBFS with Java 9: getPeer()

[Emmanuel Bourg]

We can also remove the AWTConsole completely, there is really no point
keeping an AWT interface when an equivalent Swing one is available.

Bug#862875: RFS: libzc/0.3.1-1 [ITP] -- fast zip cracking library

[Marc Ferland]

On Sat, Sep 2, 2017 at 8:43 AM, Andrey Rahmatullin  wrote:
>
> On Fri, Sep 01, 2017 at 09:43:54PM -0400, Marc Ferland wrote:
> > > Please switch to the debhelper compat level 10.
> Not fixed.

My bad.

> > > Please update Standards-Version to the current version.
> Not fixed.

Updated to 4.1.0. Based on https://tracker.debian.org/pkg/debian-policy

> Please remove unneeded comments and sample lines from d/rules.
> uscan says "Newest version of libzc on remote site is 0.3.2, local version
> is 0.3.3".
> All .dirs files are not needed.
> The package FTBFS in a clean sid chroot.
> Please install README.md.

Should all be OK now.

https://mentors.debian.net/debian/pool/main/libz/libzc/libzc_0.3.4-1.dsc

Marc

Bug#856160: nettle-dev: Please transition nettle-dev to multi-arch

[Hugh McMaster]

On Monday, 11 September 2017 4:23 AM +0200, Magnus Holmgren wrote:
> Well, except that CHAR_BIT requires limits.h and there need to be parentheses 
> around the expression.

Perhaps I'm missing something, but the substitution does have parentheses 
around the expression. You're right about needing limits.h though.

sed -i 's/\(\# define GMP_NUMB_BITS\).*/\1 \(__SIZEOF_LONG__ \* CHAR_BIT\)/' 
$(CURDIR)/version.h

# define GMP_NUMB_BITS 64   -->   # define GMP_NUMB_BITS (__SIZEOF_LONG__ * 
CHAR_BIT)

--
Hugh McMaster

Bug#873753: GnuPG Perl bindings in Debian [Re: Bug#873753: O: libcrypt-gpg-perl -- An Object Oriented Interface to GnuPG]

[Russ Allbery]

Daniel Kahn Gillmor  writes:

> There are too many bindings for GnuPG in different languages, and
> keeping them all up-to-date and clean is a pain.  we should focus on one
> or at most two per language.

> In debian, we have at least:

>   libpgp-sign-perl

FYI, this isn't a binding for GnuPG -- it's something much, much more
ancient that tries to do things like support PGPv2 and that I need to
completely rewrite, hopefully on top of an actual binding.  It's only used
by some Usenet stuff, and I'm keeping it limping along until I have a
chance to rewrite it properly.  It's best ignored for the purposes of
finding a good general solution in Debian.

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

Bug#736362: Possible cause of "Maximum number of concurrent DNS queries reached".

[Donovan Baarda]

In case anyone else is having this problem recently, I discovered that my
dnsmasq was caching poorly because spamhaus.org's SOA TTL is only 10s.

FTR, spamhaus.org is queried by spamassassin and uses NXDOMAIN DNS
responses to indicate "not-spam-site". WIth a SOA TTL of only 10s, these
responses are barely cacheable. When a burst of mail arrives, all the
spamassassin workers hammer dnsmasq with un-cacheable requests, one per
incoming email.

I suspect the 10s TTL is a recent-ish mistake and have sent spamhaus.org an
email about it. In the mean time your best workaround is to override the
TTL with the following entry in your dnsmasq.conf

min-cache-ttl=60

This will cache all responses for at least 1m.

-- 
Donovan Baarda 

Bug#709104: [pkg-gnupg-maint] Bug#709104: libgpgme11 dependency suckage

[Daniel Kahn Gillmor]

Hi Josip--

On Sun 2017-09-10 23:36:50 +0200, Josip Rodin wrote:
> JFTR the pinentry gtk ridiculosity, addressed in bug #753163, was never
> fixed in jessie, so upgrading headless servers that e.g. have mutt installed
> to read a few files in /var/mail/, has caused tons of these completely
> pointless dependencies to be installed via libgpgme11; or, rather, for
> libgpgme11 (and programs depending on it) to be removed and remembered as
> a pariah...

I think what you're saying here, when i take away the words that seem
intended mainly to inflame the conversation (like "suckage" and
"ridiculosity") is that you don't want to be bothered to install
pinentry-curses before upgrading from debian oldoldstable to debian
oldstable.  Am i reading that correctly, or do you have some other
concern?

I'm sorry to hear that you find that workaround tedious, but i'm
personally inclined to spend my time on debian GnuPG packaging focusing
on up-to-date systems (read: debian stable, at least) and on requests
that offer concrete suggestions for improvment without inflammatory
asides.

If you've got a concrete suggestion about what should be done in debian
jessie (oldstable) now, please spell it out explicitly.  Sorry that
debian isn't as good as it should be -- i hope we can do better in the
future!

All the best,

--dkg


signature.asc
Description: PGP signature

Bug#848916: ocp FTBFS on i386: dwnone_asminc.c:46: Error: junk `(%ebx)' after expression

[Steve Langasek]

Package: ocp
Version: 1:0.1.21-1.3
Followup-For: Bug #848916
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Control: tags -1 patch

I've applied the attached patch to ocp in Ubuntu which allows ocp to build
on i386 by disabling the use of i386 assembly.  Hand-optimized assembly is
mostly not interesting on i386, and the comment in the code indicates that
this is 32-bit only assembly which means it's almost certainly less
efficient on amd64 than whatever the compiler would come up with.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ocp-0.1.21/debian/patches/no-i386-asm.patch 
ocp-0.1.21/debian/patches/no-i386-asm.patch
--- ocp-0.1.21/debian/patches/no-i386-asm.patch 1969-12-31 16:00:00.0 
-0800
+++ ocp-0.1.21/debian/patches/no-i386-asm.patch 2017-09-10 15:42:04.0 
-0700
@@ -0,0 +1,21 @@
+Description: Don't try to use hand-coded assembly on i386
+ The assembly doesn't work with current toolchains, and i386 hand-optimized
+ assembly is not a particularly interesting target.
+Author: Steve Langasek 
+Bug-Debian: https://bugs.debian.org/848916
+
+Index: ocp-0.1.21/config.h.in
+===
+--- ocp-0.1.21.orig/config.h.in
 ocp-0.1.21/config.h.in
+@@ -132,10 +132,6 @@
+ 
+ #undef HAVE_RESIZETERM
+ 
+-#if (defined(_X86) || defined(__i386__)) && !defined(__APPLE__)
+-#define I386_ASM 1
+-#endif
+-
+ /* #define I386_ASM_EMU 1 */
+ 
+ /* #define ZIP_DEBUG */
diff -Nru ocp-0.1.21/debian/patches/series ocp-0.1.21/debian/patches/series
--- ocp-0.1.21/debian/patches/series2016-12-18 13:49:58.0 -0800
+++ ocp-0.1.21/debian/patches/series2017-09-10 15:40:39.0 -0700
@@ -2,3 +2,4 @@
 fix-desktop-file
 fix-gcc47-pcthunk
 gccver.diff
+no-i386-asm.patch

Bug#871835: more speedup

[Ben Hutchings]

On Mon, 2017-09-11 at 00:40 +0200, Thomas Lange wrote:
> Here's another patch, that improves speed. It needs grep -P which is
> not available in busybox. But I do not know if debootstrap is used in
> a busybox enviroment.

It's meant to be able to run on non-GNU systems, including those using
busybox.  (Also, the GNU grep manual page says "this is experimental".)

Ben.

> The execution time is now
> 
> real0m39.141s
> user0m38.924s
> sys 0m2.980s
> 
> So the user time drops from 50 to under 40 seconds on a 4-core
> machine.
> 
-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.



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

Bug#874797: didjvu: crash with: free(): invalid pointer

[Jakub Wilk]

* Elrond , 2017-09-09, 19:28:

- reading image
- image size: 2480 x 3507
- converting to DjVu
*** Error in `/usr/bin/python': free(): invalid pointer: 0x555fc49528f0 ***


Looks like a bug in Gamera (or VIGRA).

I've attached small reproducer, which crashes for me in unstable, both on i386 
and amd64.


--
Jakub Wilk
#!/usr/bin/python
import gamera.core as g
g.init_gamera()
im = g.Image((0, 0), (2479, 3506))
im = im.to_greyscale()
im.resize(g.Dim(1240, 1754), 0)

Bug#875371: xiccd process runing amok

[Eduard Bloch]

Package: xiccd
Version: 0.2.4-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I was playing around with Xephyr and additional X11 sessions.

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

Suspended the system with "systemctl suspend" from inside an Xephyr
session. Returned back. The X session in Xephyr started showing me a
screen with "You'll be redirected to the unlock dialog in a few seconds"
and kept switching over to another terminal with lightdm. So I killed
the Xephyr session and eerything looked ok.

   * What was the outcome of this action?

Suddenly some process started making lots of CPU load. It was iccd doing
nonsense. Strace says:

[pid 21735] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 
([{fd=4, revents=POLLIN|POLLHUP}])
[pid 21735] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 
([{fd=4, revents=POLLIN|POLLHUP}])
[pid 21735] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 
([{fd=4, revents=POLLIN|POLLHUP}])
[pid 21735] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 
([{fd=4, revents=POLLIN|POLLHUP}])
[pid 21735] poll([{fd=3, events=POLLIN}, {fd=4, events=POLLIN}], 2, -1) = 1 
([{fd=4, revents=POLLIN|POLLHUP}])

and continueing...

   * What outcome did you expect instead?

No weird side effects...

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

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

Versions of packages xiccd depends on:
ii  colord1.3.3-2
ii  libc6 2.24-17
ii  libcolord21.3.3-2
ii  libglib2.0-0  2.50.3-2
ii  libx11-6  2:1.6.4-3
ii  libxrandr22:1.5.1-1

xiccd recommends no packages.

xiccd suggests no packages.

-- no debconf information

Bug#875308: linklocal ipv6 addresses in debian-installer netcfg

[Michael Gebhard]

> You redacted your link-local address to be dead:beef::. I suppose what
> you actually mean is one with a fe80:: prefix? (I.e. it'd have been more
> helpful to redact the MAC/actual address.)

No, the scenario this came from is the following:
A server with a public ipv6 address,
A vm on this server with another public ipv6 address,
connected to the outside via a bridge on the server.
Server-side:
ip link add br0 type bridge
ip address add fe80::1 dev br0
ip link set dev br0 up
ip rourte add dead:beef::::1/68 dev br0
VM-side:
set up with virt-manager to use bridge br0
ip a add dead:beef::::1 dev eth0
ip l set dev eth0 up
ip r add default via fe80::1 dev eth0

So fe80::1%eth0 is the address of the bridge seen from the vm,
the redacted address is my vms public ipv6 address.

I admit, not the simplest test setup, but this has no influence
on netcfg not accepting % type addresses

Cheers,
Michael


signature.asc
Description: PGP signature

Bug#152714: fookb-plainx: X app-defaults

[Doug Torrance]

Control: tags -1 pending

On Fri, 12 Jul 2002 17:43:56 +1000 "Anand Kumria" wrote:
> Package: fookb-plainx
> Version: 3.0-1
> Severity: normal
>
> fookb-plainx stores its X defaults in /usr/X11R6/lib/X11/app-defaults
> whereas it seems that /etc/X11/app-defaults is now the preferred
> location -- although /usr/X11R6/... is a symlink to /etc/X11/...
>
> Additionally the resources file should be installed rather than
> instructions in README.Debian

Beginning with fookb 4.0 (which should be uploaded soon), Xresources 
support has been removed, so this bug will no longer be an issue.

Bug#871835: more speedup

[Thomas Lange]

Here's another patch, that improves speed. It needs grep -P which is
not available in busybox. But I do not know if debootstrap is used in
a busybox enviroment.

The execution time is now

real0m39.141s
user0m38.924s
sys 0m2.980s

So the user time drops from 50 to under 40 seconds on a 4-core machine.



0001-speed-up-by-using-grep-P-and-setting-LC_ALL-C.patch
Description: Binary data

-- 
regards Thomas

Bug#875300: transition: vdr

[Emilio Pozuelo Monfort]

Control: forwarded -1 https://release.debian.org/transitions/html/vdr.html
Control: tags -1 confirmed

On 10/09/17 15:44, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> looks like all the remaining vdr plugins need to be rebuilt for the
> virtual abi bump, too.
> For whatever reason they didn't show up yesterday (#874732) ...

binNMUs scheduled.

Emilio

Bug#875370: dependency on PSL pulls in ICU, which dwarfs wget in size

[Josip Rodin]

Package: wget
Severity: minor

Hi,

Resolving #766780 seems to have pulled in a pair of disproportionally large
libraries:

  [...]
  The following NEW packages will be installed:
libicu52 libpsl0
  The following packages will be upgraded:
wget
  [...]
  After this operation, 28,4 MB of additional disk space will be used.

Can this new dependency be made more optional, please? There's oh so many
situations where wget is used to download something where cookies are not
used at all, and having this amount of cruft lying around on the off chance
you enable cookies and then talk to a malicious server makes very littlek
sense.

See also https://lists.debian.org/debian-boot/2014/11/msg00595.html

TIA.

-- 
 2. That which causes joy or happiness.

Bug#709104: libgpgme11 dependency suckage

[Josip Rodin]

JFTR the pinentry gtk ridiculosity, addressed in bug #753163, was never
fixed in jessie, so upgrading headless servers that e.g. have mutt installed
to read a few files in /var/mail/, has caused tons of these completely
pointless dependencies to be installed via libgpgme11; or, rather, for
libgpgme11 (and programs depending on it) to be removed and remembered as
a pariah...

-- 
 2. That which causes joy or happiness.

Bug#865081: udevadm: -y documentation wrong

[Russell Stuart]

On Sun, 2017-09-10 at 19:04 +0200, Michael Biebl wrote:
> Russel, any news?

Sorry Michael, I apparently had a brain fart.  I read your request to
"file this change as a proper PR" but didn't do it.  Done now.

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

Bug#823215: [Pkg-kde-extras] Bug#874961: kmymoney: not ready for Qt5

[Micha Lenk]

Hi Pino,

Am 10.09.2017 um 23:37 schrieb Pino Toscano:
> Upstream didn't publish any Frameworks version yet, and considering that
> kmymoney manages accounts and money, I'm not keen to upload
> pre-release/unstable/alpha/beta/rc/etc versions.

Don't get me wrong. I did not intend to push for a pre-release of
KMyMoney in Debian (unless speaking about experimental).

Anyways, I've just [asked] upstream for more details about a real KF5
based release.

[asked]:
https://mail.kde.org/pipermail/kmymoney-devel/2017-September/019320.html
and https://bugs.kde.org/show_bug.cgi?id=382327

Regards,
Micha

Bug#875012: [Pkg-kde-extras] Bug#874961: kmymoney: not ready for Qt5

[Pino Toscano]

Hi,

In data domenica 10 settembre 2017 22:53:09 CEST, Micha Lenk ha scritto:
> as the Qt maintainers announced recently, Qt4 is about to removed from
> the Debian archive in the future. If I read the bug log for #823215
> correctly, a Qt5 port of kmymoney is under way, but upstream didn't
> publish an official release yet. Martin Steigerwald mentioned he
> succeeded to get a "stable enough" build that he is using.

The fact that "works for him" does not make it automatically
release-worthy material -- in fact, looking at the current Git master
(i.e. the current Frameworks branch):

  $ git grep -n TODO | grep -i port | grep -i kf5 | wc -l
  51

(to catch comments like "TODO: port KF5" or similar)

> I conclude that in principle it should be possible to build kmymoney for
> Qt5.

Upstream didn't publish any Frameworks version yet, and considering that
kmymoney manages accounts and money, I'm not keen to upload
pre-release/unstable/alpha/beta/rc/etc versions.

-- 
Pino Toscano

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

Bug#860794: Please update DNSSEC trusted keys before ICANN key rollover event

[Bernhard Schmidt]

Control: fixed -1 1:9.10.3.dfsg.P4-12.3+deb9u3
Control: fixed -1 1:9.9.5.dfsg-9+deb8u14

Ondřej Surý has taken care of this issue for Stretch and Jessie. The
fixed packages are now available through Stable Updates
(https://wiki.debian.org/StableUpdates) and should be part of the next
point release. Which probably will be just in time for Stretch, but too
late for Jessie.

Bug#868756: stretch-pu: package ntp/1:4.2.8p10+dfsg-3+deb9u1 (pre-pre-approval)

[Bernhard Schmidt]

On 09.09.2017 15:12, Julien Cristau wrote:

Hi,

>> +ntp (1:4.2.8p10+dfsg-3+deb9u1) stretch; urgency=medium
> Seems ok, feel free to upload.

Uploaded and accepted.

Bernhard

Bug#875369: FTBFS with Java 9: fails to find javac

[Chris West]

Source: hyperestraier
Version: 1.4.13
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

The package seems to think that javac(1) would be in
/usr/java/bin/javac, which is probably the result of having failed to
guess its location in other paths. See the wiki for /jre-related
changes.

Build log:

cd javapure && /usr/bin/make
make[1]: Entering directory '/build/hyperestraier-1.4.13/javapure'
/usr/java/bin/javac -source 1.5 -target 1.5 -d . Document.java Condition.java 
ResultDocument.java NodeResult.java Node.java Utility.java Call.java
/bin/bash: /usr/java/bin/javac: No such file or directory
Makefile:128: recipe for target 'estraierpure.jar' failed


Cheers,
Chris.

Bug#875367: FTBFS with Java 9: javax.xml.bind

[Chris West]

Source: hdrhistogram
Version: 2.1.9-1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

The tests try to find javax.xml.bind, which is gone by default. See the
wiki.

I asked upstream to change api or something:
https://github.com/HdrHistogram/HdrHistogram/issues/125

Build log:

java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
at 
org.HdrHistogram.HistogramLogReaderWriterTest.ycsbV1Log(HistogramLogReaderWriterTest.java:229)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.DatatypeConverter
at 
org.HdrHistogram.HistogramLogReaderWriterTest.ycsbV1Log(HistogramLogReaderWriterTest.java:229)

jHiccupV0Log(org.HdrHistogram.HistogramLogReaderWriterTest)  Time elapsed: 0 
sec  <<< ERROR!
java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
at 
org.HdrHistogram.HistogramLogReaderWriterTest.jHiccupV0Log(HistogramLogReaderWriterTest.java:175)


Cheers,
Chris.

Bug#875368: FTBFS with Java 9: (mvn) javadoc classpath

[Chris West]

Source: hikaricp
Version: 2.6.0-1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

The classpath for the javadoc generation seems to have gone wrong, which
is odd as this is a Maven project. There are a couple of other packages
that have this problem, but not many.

Build log:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (default-cli) on 
project HikariCP: MavenReportException: Error while generating Javadoc: 
[ERROR] Exit code: 1 - 
/build/hikaricp-2.6.0/src/main/java/com/zaxxer/hikari/hibernate/HikariConfigurationUtil.java:22:
 error: package org.hibernate.cfg does not exist
[ERROR] import org.hibernate.cfg.AvailableSettings;
[ERROR] ^
[ERROR] 
/build/hikaricp-2.6.0/src/main/java/com/zaxxer/hikari/hibernate/HikariConnectionProvider.java:23:
 error: package org.hibernate does not exist
[ERROR] import org.hibernate.HibernateException;
[ERROR] ^



Cheers,
Chris.

Bug#875366: FTBFS with Java 9: tools.jar

[Chris West]

Source: h2database
Version: 1.4.196
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

Tries to find tools.jar, which is gone. Don't know why it wants it.

Build log:

[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project com.h2database:h2:1.4.195-SNAPSHOT 
(/build/h2database-1.4.196/pom.xml) has 1 error
[ERROR] 'dependencies.dependency.systemPath' for com.sun:tools:jar must 
specify an absolute path but is ${tools.jar} @ line 136, column 19
[ERROR] 


Cheers,
Chris.

Bug#875365: FTBFS with Java 9: sun.misc

[Chris West]

Source: glassfish
Version: 2.1.1-b31g+dfsg1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

This is probably only the first problem; glassfish is a complex piece of
software, and the version we have here is horribly outdated; 5.0 is
about to be released.

The offending class is fixed upstream, but I can't trace the history to
when it was actually fixed.

Build log:

   [javac] 
/build/glassfish-2.1.1-b31g+dfsg1/appserv-api/src/java/com/sun/appserv/management/client/prefs/MemoryHashLoginInfoStore.java:53:
 error: cannot find symbol
[javac] import sun.misc.BASE64Decoder;
[javac]^
[javac]   symbol:   class BASE64Decoder
[javac]   location: package sun.misc
[javac] 
/build/glassfish-2.1.1-b31g+dfsg1/appserv-api/src/java/com/sun/appserv/management/client/prefs/MemoryHashLoginInfoStore.java:54:
 error: cannot find symbol
[javac] import sun.misc.BASE64Encoder;
[javac]^



Cheers,
Chris.

Bug#874585: dpkg-shlibdeps: does not parse Version References

[Dimitri John Ledkov]

On 10 September 2017 at 15:03, Guillem Jover  wrote:
> Control: tag -1 moreinfo
>
> Hi!
>
> On Thu, 2017-09-07 at 16:16:49 +0100, Dimitri John Ledkov wrote:
>> Package: dpkg
>> Version: 1.18.24
>> Severity: important
>
>> I am attaching the objdump to this bug report. In that log, one can
>> see that the highest symbol referenced by Dynamic symbol table is for
>> GLIBC_2.17 which is the dependency dpkg-shlibs generates.
>>
>> However, in the `Version References' section, one can see that
>> GLIBC_2.25 is required.
>>
>> The net result is that libc6 (>= 2.17) is generated, instead of the
>> required libc6 (>= 2.25).
>>
>> The binaries are not executable when e.g. 2.24 glibc is installed and
>> fail like so:
>>
>> # ldd /usr/sbin/NetworkManager
>> /usr/sbin/NetworkManager: /lib/x86_64-linux-gnu/libc.so.6: version
>> `GLIBC_2.25' not found (required by /usr/sbin/NetworkManager)
>>
>> I am not sure how glibc managed to generate a Version reference,
>> without using any of the dynamic symbols from 2.25.
>
> I've built and checked the resulting binary, by objdump'ing everything
> I could think of, and I was unable to see why the version reference
> had been picked up.
>
>> Reading the code, it seems like maybe dpkg-shlibdeps needs to grow the
>> ability to parse "Version References" section of the objdump and use
>> version symbols referenced there to bump up requirements just like
>> dynamic symbols do?
>
> Before doing that I'd like to first understand why that is the case, if
> it's expected and not a bug in the toolchain or similar.
>

That is a very reasonable question. Given that the version dep is 2.25
I went through the glibc abi lists to see what was new in 2.25.
A few things from those are referenced in the NetworkManager but
unused (e.g. makedev()) and thus did not gain a dep (e.g dropping that
function did not result in getting the ABI back lower).
However, in the partial embedded copy of systemd there is embeded
implementation of explicit_bzero if glibc does not provide one.
It seems that NetworkManager included the declaration check too in
their configure.ac such that with glibc 2.25+ explicit_bzero from libc
starts to be referenced.
However, in the end, none of the bits that NetworkManager actual use
hit the string_erase function and thus do not call explicit_bzero.
Thus it looks like compiler did compile / link usage of
explicit_bzero, and eventually dropped it, yet version info persistent
to the end binaries/libraries.
With the attached patch, builds of network-manager end up not having
GLIBC_2.25 version reference.

Is this normal toolchain behaviour to not optimise out version
references, when all symbols are optimised out?
The code is crazy, but I would have expected optimised out things to
remove version references too.

-- 
Regards,

Dimitri.
Description: Drop code referencing explicit_bzero
Author: Dimitri John Ledkov 
Bug-Debian: https://bugs.debian.org/874585
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1715641

--- a/configure.ac
+++ b/configure.ac
@@ -62,12 +62,6 @@
 AC_CHECK_SIZEOF(dev_t)
 AC_CHECK_SIZEOF(time_t)
 
-AC_CHECK_DECLS([
-	explicit_bzero],
-	[], [], [[
-#include 
-]])
-
 dnl
 dnl translation support
 dnl
--- a/config.h.in
+++ b/config.h.in
@@ -34,10 +34,6 @@
*/
 #undef HAVE_DCGETTEXT
 
-/* Define to 1 if you have the declaration of `explicit_bzero', and to 0 if
-   you don't. */
-#undef HAVE_DECL_EXPLICIT_BZERO
-
 /* Define to 1 if you have the  header file. */
 #undef HAVE_DLFCN_H
 
--- a/src/systemd/src/basic/string-util.c
+++ b/src/systemd/src/basic/string-util.c
@@ -825,36 +825,6 @@
 return 1;
 }
 
-#if !HAVE_DECL_EXPLICIT_BZERO
-/*
- * Pointer to memset is volatile so that compiler must de-reference
- * the pointer and can't assume that it points to any function in
- * particular (such as memset, which it then might further "optimize")
- * This approach is inspired by openssl's crypto/mem_clr.c.
- */
-typedef void *(*memset_t)(void *,int,size_t);
-
-static volatile memset_t memset_func = memset;
-
-void explicit_bzero(void *p, size_t l) {
-memset_func(p, '\0', l);
-}
-#endif
-
-char* string_erase(char *x) {
-if (!x)
-return NULL;
-
-/* A delicious drop of snake-oil! To be called on memory where
- * we stored passphrases or so, after we used them. */
-explicit_bzero(x, strlen(x));
-return x;
-}
-
-char *string_free_erase(char *s) {
-return mfree(string_erase(s));
-}
-
 bool string_is_safe(const char *p) {
 const char *t;
 
--- a/src/systemd/src/basic/string-util.h
+++ b/src/systemd/src/basic/string-util.h
@@ -189,14 +189,4 @@
 return memmem(haystack, haystacklen, needle, needlelen);
 }
 
-#if !HAVE_DECL_EXPLICIT_BZERO
-void explicit_bzero(void *p, size_t l);
-#endif
-
-char *string_erase(char *x);
-
-char *string_free_erase(char *s);
-DEFINE_TRIVIAL_CLEANUP_FUNC(char *, string_free_erase);
-#define _cleanup_string_free_erase_ 

Bug#875364: FTBFS with Java 9: overrides core packages

[Chris West]

Source: geronimo-jta-1.1-spec
Version: 1.1.1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

Attempting to override core packages has been banned by javadoc,
apparently.

Build log:

ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (default-cli) on 
project geronimo-jta_1.1_spec: MavenReportException: Error while generating 
Javadoc: 
[ERROR] Exit code: 1 - 
/build/geronimo-jta-1.1-spec-1.1.1/src/main/java/javax/transaction/xa/XAException.java:26:
 error: package exists in another module: java.sql
[ERROR] package javax.transaction.xa;
[ERROR] ^
[ERROR] 
/build/geronimo-jta-1.1-spec-1.1.1/src/main/java/javax/transaction/xa/Xid.java:26:
 error: package exists in another module: java.sql
[ERROR] package javax.transaction.xa;
[ERROR] ^
[ERROR] 
/build/geronimo-jta-1.1-spec-1.1.1/src/main/java/javax/transaction/xa/XAResource.java:26:
 error: package exists in another module: java.sql
[ERROR] package javax.transaction.xa;
[ERROR] ^
[ERROR] 
[ERROR] Command line was: /usr/lib/jvm/java-9-openjdk-amd64/bin/javadoc 
@options @packages
[ERROR] 
[ERROR] Refer to the generated Javadoc files in 
'/build/geronimo-jta-1.1-spec-1.1.1/target/apidocs' dir.



Cheers,
Chris.

Bug#875363: "apt build-dep" fails for empty "Build-Depends-Indep:" line

[Chris West]

Package: apt
Version: 1.5~rc1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

The package "src:geotranz" contains a control file like:

...
Maintainer: Roberto Lumbreras 
Build-Depends: cdbs (>= 0.4.93~), dh-exec (>=0.3), debhelper (>= 9), 
default-jdk, giftrans, imagemagick, cpio
Build-Depends-Indep: 
Standards-Version: 3.9.5
...

https://sources.debian.net/src/geotranz/3.3-1/debian/control/#L6


Running apt build-dep on this package results in a failure:

% sudo apt build-dep .
Note, using directory '.' to get the build dependencies
Reading package lists... Done
E: Problem parsing dependency: Build-Depends-Indep
E: Unable to get build-dependency information for .


Please either fix apt to accept this, or clarify why this is illegal,
so we can get geotranz fixed.

My guess as to the relevant spec would be 5.1:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-controlsyntax

> Empty field values are only permitted in source package control
> files (debian/control). Such fields are ignored.

(Personally I feel that geotranz is wrong, and apt is fine here.)

Cheers,
Chris.

Bug#856160: nettle-dev: Please transition nettle-dev to multi-arch

[Magnus Holmgren]

söndag 10 september 2017 kl. 21:13:41 CEST skrev  Niels Möller:
> Magnus Holmgren  writes:
> > Well, except that CHAR_BIT requires limits.h and there need to be
> > parentheses around the expression.
> 
> I made the following fix upstream:
> https://git.lysator.liu.se/nettle/nettle/commit/b7052093931d69d3626a54d59783
> e0d9e48ea20f
> 
> Not sure if you want something more minimal for a debian patch, but it
> would be nice if you can confirm it solves the problem.

I think so, although *ideally* I think we want packages built by just adding 
--enable-mini-gmp to the ./configure command in debian/rules to be multi-arch-
installable too. I don't know if anyone would want to do that though, and 
there are more things to take care of if so, such as the new exported symbols 
that appear in the symbols files. It's probably easiest to put the headers in 
arch-specific directories. After all it's only a matter of a couple of hundred 
kB.

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#823215: kmymoney: not ready for Qt5

[Micha Lenk]

Control: block 874961 by 823215
Control: block 875012 by 874961


Hi kmymoney maintainers,

as the Qt maintainers announced recently, Qt4 is about to removed from
the Debian archive in the future. If I read the bug log for #823215
correctly, a Qt5 port of kmymoney is under way, but upstream didn't
publish an official release yet. Martin Steigerwald mentioned he
succeeded to get a "stable enough" build that he is using.

I conclude that in principle it should be possible to build kmymoney for
Qt5. We (Debian) probably need to ping upstream and ask them to publish
an official Qt5 ready release. Once we have that, we hopefully can
resolve #823215, which will probably automatically resolve #874961 too.
After that the libgwenhywfar source package can drop the Qt4 support (no
other package than kmymoney build-depends on it).

I am updating the bugs's block relations accordingly.

Regards,
Micha

Bug#875362: linux-image-4.12.0-1-amd64: 5GHz wifi randomly drops on ath10k QCA6174

[Thibaut Girka]

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

Since I upgraded to linux 4.12.0-1-amd64, my wifi at home (5.18GHz, WPA2-PSK)
frequently and silently fails. Manually re-connecting works. This issue does
not appear on linux 4.11.0-1, nor does it occur at my workplace, where I am
connected to a 2.4GHz access-point (WPA2 TTLS).



-- Package-specific info:
** Version:
Linux version 4.12.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
6.4.0 20170805 (Debian 6.4.0-3) ) #1 SMP Debian 4.12.6-1 (2017-08-12)

** Command line:
BOOT_IMAGE=/vmlinuz-4.12.0-1-amd64 root=/dev/mapper/vicious--vg-root ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: XPS 13 9360
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: 2.2.1
board_vendor: Dell Inc.
board_name: 05JK94
board_version: A00

** Loaded modules:
fuse
ctr
ccm
rfcomm
arc4
cmac
bnep
hid_multitouch
snd_hda_codec_hdmi
binfmt_misc
nls_ascii
nls_cp437
snd_hda_codec_realtek
vfat
dell_laptop
i2c_designware_platform
dell_wmi
dell_smbios
fat
snd_hda_codec_generic
i2c_designware_core
dcdbas
intel_rapl
x86_pkg_temp_thermal
intel_powerclamp
efi_pstore
coretemp
kvm_intel
snd_soc_skl
kvm
snd_soc_skl_ipc
ath10k_pci
irqbypass
ath10k_core
snd_soc_sst_ipc
snd_soc_sst_dsp
intel_cstate
intel_uncore
snd_hda_ext_core
snd_soc_sst_match
ath
intel_rapl_perf
evdev
mac80211
joydev
uvcvideo
snd_soc_core
videobuf2_vmalloc
snd_compress
videobuf2_memops
pcspkr
serio_raw
efivars
snd_hda_intel
i915
videobuf2_v4l2
snd_hda_codec
iTCO_wdt
iTCO_vendor_support
cfg80211
snd_hda_core
snd_hwdep
snd_pcm
snd_timer
rtsx_pci_ms
snd
soundcore
videobuf2_core
memstick
videodev
media
idma64
drm_kms_helper
drm
mei_me
btusb
btrtl
processor_thermal_device
i2c_algo_bit
mei
shpchp
intel_pch_thermal
intel_soc_dts_iosf
intel_lpss_pci
ucsi
wmi
battery
hci_uart
btbcm
btqca
btintel
soc_button_array
intel_vbtn
bluetooth
ecdh_generic
rfkill
video
intel_lpss_acpi
intel_lpss
intel_hid
int3403_thermal
sparse_keymap
int3400_thermal
int340x_thermal_zone
acpi_thermal_rel
acpi_als
acpi_pad
kfifo_buf
ac
button
industrialio
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
fscrypto
ecb
mbcache
btrfs
crc32c_generic
xor
raid6_pq
algif_skcipher
af_alg
dm_crypt
dm_mod
crct10dif_pclmul
crc32_pclmul
crc32c_intel
ghash_clmulni_intel
pcbc
rtsx_pci_sdmmc
mmc_core
aesni_intel
aes_x86_64
crypto_simd
glue_helper
cryptd
psmouse
i2c_i801
nvme
xhci_pci
nvme_core
rtsx_pci
xhci_hcd
mfd_core
usbcore
usb_common
thermal
i2c_hid
hid

** Network interface configuration:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** Network status:
*** IP interfaces and addresses:
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: wlp58s0:  mtu 1500 qdisc mq state UP group 
default qlen 1000
link/ether 9c:b6:d0:d5:97:fb brd ff:ff:ff:ff:ff:ff
inet 192.168.0.121/24 brd 192.168.0.255 scope global dynamic wlp58s0
   valid_lft 42814sec preferred_lft 42814sec
inet6 fdad:3df7:b2f3::600/128 scope global 
   valid_lft forever preferred_lft forever
inet6 fdad:3df7:b2f3:0:921f:8ac8:1720:b6bf/64 scope global noprefixroute 
   valid_lft forever preferred_lft forever
inet6 fdc9:3611:9af8:0:6c49:6680:2f8b:f60a/64 scope global noprefixroute 
dynamic 
   valid_lft 7072sec preferred_lft 1672sec
inet6 fe80::7386:2396:a415:5402/64 scope link 
   valid_lft forever preferred_lft forever

*** Device statistics:
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:  122036 988000 0  0 0   122036 
988000 0   0  0
wlp58s0: 79301192   58720000 0  0 0  2546397   
18364000 0   0  0

*** Protocol statistics:
Ip:
Forwarding: 2
18818 total packets received
7 with invalid addresses
0 forwarded
0 incoming packets discarded
18787 incoming packets delivered
17123 requests sent out
40 outgoing packets dropped
14 dropped because of missing route
Icmp:
473 ICMP messages received
0 input ICMP message failed
ICMP input histogram:
destination unreachable: 86
echo replies: 387
478 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 86
echo requests: 392
IcmpMsg:
InType0: 387
InType3: 86
OutType3: 86
OutType8: 392
Tcp:
  

Bug#875001: marked as done ([ktp-call-ui] Future Qt4 removal from Buster)

[Maximiliano Curia]

On Sunday, 10 September 2017 21:55:14 CEST Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On 10 September 2017 at 16:51, Debian Bug Tracking System
>  wrote:
> > -- Forwarded message --
> > From: Pino Toscano 

> > Theoretically this was fixed in experimental already, although it would
> > be nice to know why the telepathy-kde stack was not updated as a whole
> > in unstable, time ago...

> IIRC freeze and then busy maintainers. It would be good to have it in
> unstable.

And the fact that the ktp in experimental is not functional. I'm currently 
updating the packages to 17.08, from what I gathered from the kde ml's it 
seems that it should be functional but in an almost unmaintainable state... In 
the current state, it would make sense to request the removal from unstable, 
and keep it only in experimental till it works again (or is dropped from 
applications).

Happy hacking,
-- 
"The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time."
-- Tom Cargill
 Saludos /\/\ /\ >< `/


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

Bug#875360: FTBFS with Java 9: ant can't find tool(?)

[Chris West]

Source: emma-coverage
Version: 2.0.5312+dfsg
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

ant can't seem to load a tool, no idea what's going on here.
I don't expect this to be the only problem with Emma.

Build log:

-timestamp.1:
 [java] Could not find com.vladium.util.version.VersionStampTool. Make sure 
you have it in your classpath
 [java] at 
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:140)
 [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:834)
 [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:228)
 [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:137)
 [java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:110)
 [java] at 
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
 [java] at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown 
Source)
 [java] at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)




Cheers,
Chris.

Bug#875361: perl: missing newline after "Unable to flush stdout: ..."

[Jakub Wilk]

Package: perl
Version: 5.26.0-7
Severity: minor

$ perl -E'say 42' >/dev/full || echo '<-- missing newline here'
Unable to flush stdout: No space left on device<-- missing newline here


-- System Information:
Architecture: i386

Versions of packages perl depends on:
ii  dpkg   1.18.24
ii  perl-base  5.26.0-7
ii  perl-modules-5.26  5.26.0-7
ii  libperl5.265.26.0-7

Versions of packages perl recommends:
ii  netbase  5.4

Versions of packages perl suggests:
ii  perl-doc5.26.0-7
ii  libterm-readline-gnu-perl   1.35-1+b2
ii  libterm-readline-perl-perl  1.0303-1
ii  make4.1-9.1

--
Jakub Wilk

Bug#875359: RM: netemul -- ROM; Dead upstream, needs Qt4, low popcon

[Lisandro Damián Nicanor Pérez Meyer]

Package: ftp.debian.org
Severity: normal

Hi! Please remove netemul from th earchive. It has been dead upstream
for ages, Qt4 is going to be removed and it's popcon is low.

Thanks!

Bug#875358: Fails with Java 9, >2.0.0 required to work

[Chris West]

Source: powermock
Version: 1.6.6
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

Powermock fails to work properly on Java 9.

Upstream say that it will only be supported in Powermock 2, as yet
unreleased. Powermock 2 will also only support Mockito 2, not Mockito 1:
https://github.com/powermock/powermock/issues/783#issuecomment-326992288

Please upgrade Powermock to version 2.

Powermock itself seems to build (no idea why, no tests?), but it breaks
other packages, at least: dnssecjava, who's build log is:

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 7.262 sec <<< 
FAILURE! - in org.jitsi.dnssec.unbound.rpl.UnboundTests
initializationError(org.jitsi.dnssec.unbound.rpl.UnboundTests)  Time elapsed: 
0.008 sec  <<< ERROR!
org.objenesis.ObjenesisException: java.lang.reflect.InvocationTargetException
Caused by: java.lang.reflect.InvocationTargetException
Caused by: java.lang.IllegalAccessError: class 
jdk.internal.reflect.ConstructorAccessorImpl loaded by 
org/powermock/core/classloader/MockClassLoader cannot access 
jdk/internal/reflect superclass jdk.internal.reflect.MagicAccessorImpl


Results :

Tests in error: 
  RTest.initializationError ?? Objenesis 
java.lang.reflect.InvocationTargetExcep...
  TestAlgorithmSupport.initializationError ?? Objenesis 
java.lang.reflect.Invoca...
  TestBogusReasonMessage.initializationError ?? Objenesis 
java.lang.reflect.Invo...
  TestCNames.initializationError ?? Objenesis 
java.lang.reflect.InvocationTarget...


Cheers,
Chris.

Bug#875357: FTBFS with Java 9: sun..spi removed

[Chris West]

Source: dnsjava
Version: 2.1.8
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

I raised this upstream, as the feature here is just gone:
https://sourceforge.net/p/dnsjava/feature-requests/24/

Build log:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.6.1:compile (default-compile) 
on project dnsjava: Compilation failure: Compilation failure: 
[ERROR] 
/build/dnsjava-2.1.8/org/xbill/DNS/spi/DNSJavaNameServiceDescriptor.java:[16,54]
 cannot find symbol
[ERROR]   symbol: class NameServiceDescriptor
[ERROR] 
/build/dnsjava-2.1.8/org/xbill/DNS/spi/DNSJavaNameServiceDescriptor.java:[18,16]
 cannot find symbol
[ERROR]   symbol:   class NameService
[ERROR]   location: class org.xbill.DNS.spi.DNSJavaNameServiceDescriptor
[ERROR] 
/build/dnsjava-2.1.8/org/xbill/DNS/spi/DNSJavaNameServiceDescriptor.java:[30,8] 
cannot find symbol
[ERROR]   symbol:   class NameService
[ERROR]   location: class org.xbill.DNS.spi.DNSJavaNameServiceDescriptor
[ERROR] 
/build/dnsjava-2.1.8/org/xbill/DNS/spi/DNSJavaNameServiceDescriptor.java:[7,1] 
package sun.net.spi.nameservice does not exist
[ERROR] 
/build/dnsjava-2.1.8/org/xbill/DNS/spi/DNSJavaNameServiceDescriptor.java:[21,30]
 cannot find symbol



Cheers,
Chris.

Bug#875356: Wrong timeout computation in xf86WaitForInput breaks xserver-xorg-input-wacom

[Thomas Richter]

Package: xserver-xorg-core
Version: 2:1.19.2-1+deb9u1
Severity: important

The current debian version of xserver-xorg-core breaks due to a protocol
change xserver-xorg-input-wacom. In particular, the function affected is
xf86WaitForInput(), which used to expect a timeout in microseconds due
to its implementation on top of select(), though now runs into
xserver_poll(), which expects a delay in milliseconds.
xserver-xorg-input-wacom uses this function to initiate a delay of
250msecs to reset the wacom serial protocol, but now receives a delay of
250seconds instead. IOWS, the xserver startup hangs for all practical
purposes.

The current source of xf86WaitForInput is as follows:

int
xf86WaitForInput(int fd, int timeout)
{
int r;
struct pollfd poll_fd;

poll_fd.fd = fd;
poll_fd.events = POLLIN;

if (fd >= 0) {
SYSCALL(r = xserver_poll(_fd, 1, timeout));
}
else {
SYSCALL(r = xserver_poll(_fd, 0, timeout));
}
xf86ErrorFVerb(9, "poll returned %d\n", r);
return r;
}

Note that this bug has been fixed upstream which includes the necessary
scaling:


int
xf86WaitForInput(int fd, int timeout)
{
int r;
struct pollfd poll_fd;

poll_fd.fd = fd;
poll_fd.events = POLLIN;

/* convert microseconds to milliseconds */
timeout = (timeout + 999) / 1000;

if (fd >= 0) {
SYSCALL(r = xserver_poll(_fd, 1, timeout));
}
else {
SYSCALL(r = xserver_poll(_fd, 0, timeout));
}
xf86ErrorFVerb(9, "poll returned %d\n", r);
return r;
}

Please consider adding this fix to the debian version as otherwise at
least the wacom input module will break.

Bug#875355: FTBFS with Java 9: msgfmt can't find javac

[Chris West]

Source: dbus-java
Version: 2.8
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

msgfmt fails to find a compiler. I'm pretty sure I've seen this elsewhere,
maybe it's a bug in msgfmt not these packages, or they are expected to set
or not set environment variables?


Build log:

(cd translations; for i in *.po; do msgfmt --java2 -r dbusjava_localized -d 
../classes -l ${i%.po} $i; done)
msgfmt: Java compiler not found, try installing gcj or set $JAVAC
msgfmt: compilation of Java class failed, please try --verbose or set $JAVAC
Makefile:80: recipe for target '.classes' failed

Cheers,
Chris.

Bug#875354: FTBFS with Java 9: (mvn) javadoc classpath

[Chris West]

Source: cssparser
Version: 0.9.5
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

This maven build seems to fail to correctly set the classpath during the
Javadoc build. This is unsual. See the wiki.

Build log:

ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (default-cli) on 
project cssparser: MavenReportException: Error while generating Javadoc: 
[ERROR] Exit code: 1 - 
/build/cssparser-0.9.5/src/main/java/com/steadystate/css/dom/CSSStyleSheetImpl.java:50:
 error: cannot find symbol
[ERROR] import com.steadystate.css.parser.SACParserCSS2;
[ERROR]  ^
[ERROR]   symbol:   class SACParserCSS2
[ERROR]   location: package com.steadystate.css.parser
[ERROR] 
/build/cssparser-0.9.5/src/main/java/com/steadystate/css/parser/AbstractSACParser.java:69:
 error: cannot find symbol
[ERROR] protected abstract Token getToken();
[ERROR]^




Cheers,
Chris.

Bug#875351: FTBFS with Java 9: test detects missing methods

[Chris West]

Source: commons-math3
Version: 3.6.1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

Looks like a test is intentionally failing the build because there's
some extra work to be done for developers; not because anything is
actually broken as-is.

Build log:

Failed tests: 
  FastMathTest.checkMissingFastMathClasses:1376 FastMath should implement all 
StrictMath methods


Cheers,
Chris.

Bug#853581: ocp: ftbfs with GCC-7

[Steve Langasek]

Package: ocp
Followup-For: Bug #853581
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Control: tags -1 patch
Control: user ubuntu-de...@lists.ubuntu.com
Control: usertags -1 ubuntu-patch artful origin-ubuntu

Hello,

Attached is a patch that fixes this build failure.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ocp-0.1.21/debian/patches/gccver.diff 
ocp-0.1.21/debian/patches/gccver.diff
--- ocp-0.1.21/debian/patches/gccver.diff   2016-12-18 13:49:58.0 
-0800
+++ ocp-0.1.21/debian/patches/gccver.diff   2017-09-10 13:11:08.0 
-0700
@@ -1,13 +1,13 @@
-Index: b/configure.ac
+Index: ocp-0.1.21/configure.ac
 ===
 a/configure.ac
-+++ b/configure.ac
-@@ -117,7 +117,7 @@ else
+--- ocp-0.1.21.orig/configure.ac
 ocp-0.1.21/configure.ac
+@@ -117,7 +117,7 @@
'')
AC_MSG_ERROR([not found]);
;;
 -  
2.95.[[2-9]]|2.95.[[2-9]][[-.]]*|3.[[0-9]]|3.[[0-9]].[[0-9]]|3.[[0-9]]|3.[[0-9]].[[0-9]]-*|4.*)
-+  
2.95.[[2-9]]|2.95.[[2-9]][[-.]]*|3.[[0-9]]|3.[[0-9]].[[0-9]]|3.[[0-9]]|3.[[0-9]].[[0-9]]-*|[[4-9]].*)
++  
2.95.[[2-9]]|2.95.[[2-9]][[-.]]*|3.[[0-9]]|3.[[0-9]].[[0-9]]|3.[[0-9]]|3.[[0-9]].[[0-9]]-*|[[4-9]].*|[[4-9]])
_cc_major=`echo $cc_version | cut -d '.' -f 1`
_cc_minor=`echo $cc_version | cut -d '.' -f 2`
_cc_mini=`echo $cc_version | cut -d '.' -f 3`

Bug#875353: FTBFS with Java 9: (mvn) javadoc classpath

[Chris West]

Source: commons-vfs
Version: 2.1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

This fails to find the right classpath during the javadoc build, despite
being a maven project. This is unusual. See the wiki.

Build log:

[INFO] --- maven-jar-plugin:3.0.2:test-jar (default) @ commons-vfs2 ---
[INFO] Skipping packaging of the test-jar
[INFO] 
[INFO] --- maven-javadoc-plugin:2.10.4:jar (default-cli) @ commons-vfs2 ---
[INFO] 
71 errors
[INFO] 
[INFO] 
[INFO] Skipping Apache Commons VFS
[INFO] This project has been banned from the build due to previous failures.
[INFO] 
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache Commons VFS . SUCCESS [  3.312 s]
[INFO] Apache Commons VFS Core  FAILURE [ 30.852 s]
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 34.995 s
[INFO] Finished at: 2017-08-30T21:11:52Z
[INFO] Final Memory: 23M/80M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (default-cli) on 
project commons-vfs2: MavenReportException: Error while generating Javadoc: 
[ERROR] Exit code: 1 - 
/build/commons-vfs-2.1/core/src/main/java/org/apache/commons/vfs2/provider/hdfs/HdfsFileObject.java:32:
 error: package org.apache.hadoop.fs does not exist
[ERROR] import org.apache.hadoop.fs.FileStatus;
[ERROR]^
[ERROR] 
/build/commons-vfs-2.1/core/src/main/java/org/apache/commons/vfs2/provider/hdfs/HdfsFileObject.java:33:
 error: package org.apache.hadoop.fs does not exist
[ERROR] import org.apache.hadoop.fs.FileSystem;
[ERROR]^



Cheers,
Chris.

Bug#875352: imagemagick: CVE-2017-13768

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-11
Severity: important
Tags: upstream patch security
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/706

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-13768[0]:
| Null Pointer Dereference in the IdentifyImage function in
| MagickCore/identify.c in ImageMagick through 7.0.6-10 allows an
| attacker to perform denial of service by sending a crafted image file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-13768
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13768
[1] https://github.com/ImageMagick/ImageMagick/issues/706
[2] 
https://github.com/ImageMagick/ImageMagick/commit/2c1b360d80e5f8f7c7108c0afedde64ab79318ff

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#875350: FTBFS with Java 9: javadoc classpath

[Chris West]

Source: closure-compiler
Version: 20130227+dfsg1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

It appears that the javadoc classpath is not being set as accurately as
with the main build. This is a new problem.

Build log:

  [javadoc] Loading source files for package 
com.google.debugging.sourcemap.proto...
  [javadoc] Constructing Javadoc information...
  [javadoc] 
/build/closure-compiler-20130227+dfsg1/src/com/google/javascript/jscomp/ant/AntErrorManager.java:24:
 error: package org.apache.tools.ant does not exist
  [javadoc] import org.apache.tools.ant.Project;
  [javadoc]^
  [javadoc] 
/build/closure-compiler-20130227+dfsg1/src/com/google/javascript/jscomp/ant/AntErrorManager.java:25:
 error: package org.apache.tools.ant does not exist
  [javadoc] import org.apache.tools.ant.Task;
  [javadoc]^



Cheers,
Chris.

Bug#875324: diffoscope: Increased number of timeouts in recent versions?

[Mattia Rizzolo]

On Sun, Sep 10, 2017 at 06:35:48PM +0100, Chris Lamb wrote:
> So, I've just run a very unscientific benchmark across all the various
> releases in Git:
> 
>   https://i.imgur.com/t4m5isZ.jpg

Oh, interesting image :)

> This is only using the --text presenter.

Could you please also do your unscientific benchmark with --html?
html generation is a relevant part of diffoscope's runtime.

-- 
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#875349: libp11: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: libp11
Version: 0.4.7-1
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans
Control: block 871056 by -1

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#875001: marked as done ([ktp-call-ui] Future Qt4 removal from Buster)

[Lisandro Damián Nicanor Pérez Meyer]

On 10 September 2017 at 16:51, Debian Bug Tracking System
 wrote:
> -- Forwarded message --
> From: Pino Toscano 
> To: 875001-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 10 Sep 2017 21:27:42 +0200
> Subject: Re: Bug#875001: [ktp-call-ui] Future Qt4 removal from Buster
> Source: ktp-call-ui
> Source-Version: 16.04.0-1
>
> Theoretically this was fixed in experimental already, although it would
> be nice to know why the telepathy-kde stack was not updated as a whole
> in unstable, time ago...

IIRC freeze and then busy maintainers. It would be good to have it in unstable.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#875126: comptext: Incomplete debian/copyright?

[Ana C. Custura]

> I just ACCEPTed comptext from NEW but noticed it was missing 
> attribution in debian/copyright for at least Stelios Bounano
> in the win32 bit.
> 
> (This is not exhaustive so please check over the entire package 
> carefully and address these on your next upload.)

Thank you, will do!

Bug#873996: [pkg-octave/master] java9.patch: new patch, fixes FTBFS with Java 9.

[Sébastien Villemot]

tag 873996 pending
thanks

Date: Sun Sep 10 17:33:51 2017 +0200
Author: Sébastien Villemot 
Commit ID: eb21f1084dd1b6c879d757afb028a105daf25026
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git;a=commitdiff;h=eb21f1084dd1b6c879d757afb028a105daf25026
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave.git;a=commitdiff_plain;h=eb21f1084dd1b6c879d757afb028a105daf25026

java9.patch: new patch, fixes FTBFS with Java 9.

Closes: #873996
  

Bug#875348: O: librcc -- Library for autoconvert codepages

[Mattia Rizzolo]

Package: wnpp

The current maintainer of librcc, Ivan Borzenkov ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: librcc
Binary: librcc0, librccgtk2-0, librcc-dev
Version: 0.2.12-0.1
Maintainer: Ivan Borzenkov 
Build-Depends: debhelper (>= 9), librcd-dev, libenca-dev, libdb-dev, 
libxml2-dev, libaspell-dev, doxygen, automake, libtool, pkg-config, 
libgtk2.0-dev
Architecture: any
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 cfb8680aa9a6900d59d46d6431d68659 2000 librcc_0.2.12-0.1.dsc
 930de6cd64e5daa33cabed58261634bb 466527 librcc_0.2.12.orig.tar.bz2
 55607e501788873955466c7a89fc592e 3756 librcc_0.2.12-0.1.debian.tar.xz
Vcs-Browser: http://dside.dyndns.org/rusxmms/browser/librcc
Vcs-Bzr: http://dside.dyndns.org/bzr/rusxmms/librcc
Checksums-Sha256:
 b659d5b5c6350306f58a486349489519d5f9ae306fd6f73e1826784a0ad40871 2000 
librcc_0.2.12-0.1.dsc
 207973fbb73e1e376dad7542af17fe428efece91ea7f92a4efbcee676d2cb74b 466527 
librcc_0.2.12.orig.tar.bz2
 e0257dbd02d0db8b432ec836f19602ce7c47c1b4de75e732d69f54d2c1bf393c 3756 
librcc_0.2.12-0.1.debian.tar.xz
Homepage: http://rusxmms.sourceforge.net/
Package-List: 
 librcc-dev deb libdevel extra
 librcc0 deb libs extra
 librccgtk2-0 deb libs extra
Directory: pool/main/libr/librcc
Priority: source
Section: libs

Package: librcc0
Source: librcc
Version: 0.2.12-0.1
Installed-Size: 175
Maintainer: Ivan Borzenkov 
Architecture: amd64
Depends: librcd0, libenca0, libaspell15 (>= 0.60.7~20110707), libc6 (>= 2.15), 
libdb5.3, libxml2 (>= 2.7.4)
Description: Library for autoconvert codepages
Description-md5: 6ce1fa15a6acf59c2b6051470d18
Homepage: http://rusxmms.sourceforge.net/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/libr/librcc/librcc0_0.2.12-0.1_amd64.deb
Size: 48808
MD5sum: 1455e382f759f8ca3172530064a82f44
SHA256: 861430f0a996d8a28715e30ea559f7bc2fbdf318af471e4471ded7d00f4a8af8

Package: librccgtk2-0
Source: librcc
Version: 0.2.12-0.1
Installed-Size: 118
Maintainer: Ivan Borzenkov 
Architecture: amd64
Replaces: librcc0 (<< 0.2.8-1)
Depends: librcc0 (= 0.2.12-0.1), libatk1.0-0 (>= 1.12.4), libc6 (>= 2.4), 
libcairo2 (>= 1.2.4), libfontconfig1 (>= 2.11), libfreetype6 (>= 2.2.1), 
libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 
2.8.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), 
libpangoft2-1.0-0 (>= 1.14.0), libxml2 (>= 2.7.4)
Description: Library for autoconvert codepages GTK2 interface
Description-md5: 969e5bd0d93f0bc3c9cbeb7403ef1619
Homepage: http://rusxmms.sourceforge.net/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/libr/librcc/librccgtk2-0_0.2.12-0.1_amd64.deb
Size: 26228
MD5sum: e0f648b741de21543255b867f967c217
SHA256: c4a5718eff15c7ebfd0bd5039b800cfa7ad77c0b93e1a20cf17b39f364b832c9

Package: librcc-dev
Source: librcc
Version: 0.2.12-0.1
Installed-Size: 1746
Maintainer: Ivan Borzenkov 
Architecture: amd64
Depends: librcc0 (= 0.2.12-0.1), librccgtk2-0 (= 0.2.12-0.1), librcd-dev
Description: Library for autoconvert codepages development files
Description-md5: cf9cd63b809c1fbd46d5a7f8f762638d
Homepage: http://rusxmms.sourceforge.net/
Tag: devel::examples, devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/libr/librcc/librcc-dev_0.2.12-0.1_amd64.deb
Size: 211300
MD5sum: 7fa5f6da98f50a8029a564d85d69bc12
SHA256: b8dc0d44b3429757fdde8efbb54e2875dfacd743648801df4693791073df6b21


-- 
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#867230: [pkg-octave/master] d/control: Drop dependency on imagemagick

[Rafael Laboissiere]

tag 867230 pending
thanks

Date: Sun Sep 10 16:39:25 2017 -0300
Author: Rafael Laboissiere 
Commit ID: 3e5bd4ca91c3182e696f669cbf26c45161811096
Commit URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-image.git;a=commitdiff;h=3e5bd4ca91c3182e696f669cbf26c45161811096
Patch URL: 
https://anonscm.debian.org/cgit/pkg-octave/octave-image.git;a=commitdiff_plain;h=3e5bd4ca91c3182e696f669cbf26c45161811096

d/control: Drop dependency on imagemagick

Closes: #867230
  

Bug#870922: Removed package(s) from unstable

[Mattia Rizzolo]

Control: clone -1 -2
Control: reopen -2
Control: retitle -2 RM: elmerfem/experimental -- RoQA; missed both jessie and 
stretch

On Sun, Sep 10, 2017 at 06:33:27PM +0200, Tobias Frost wrote:
> Should elmerfem also be removed from experimental?

Of course, thanks for catching it!

-- 
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#875346: FTBFS with Java 9: tools.jar

[Chris West]

Source: checkstyle
Version: 6.15
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

It's looking for tools.jar.
The upstream build seems not to look for tools.jar, but fail anyway
because it can't find things inside it.

I raised a "It doesn't work" issue with upstream:
https://github.com/checkstyle/checkstyle/issues/5102

The package is quite a way behind upstream anyway, so updating it may be
challenging.

Upstream build log:

[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/home/faux/code/checkstyle/src/test/java/com/puppycrawl/tools/checkstyle/doclets/TokenTypesDocletTest.java:[44,29]
 cannot find symbol
  symbol:   class JavadocTool
  location: package com.sun.tools.javadoc


Debian build log:

[ERROR] Failed to execute goal on project checkstyle: Could not resolve
dependencies for project com.puppycrawl.tools:checkstyle:jar:6.15: Could
not find artifact com.sun:tools:jar:debian at specified path
/usr/lib/jvm/java-9-openjdk-amd64/../lib/tools.jar -> [Help 1]


Cheers,
Chris.

Bug#868453: xorg log flooded by dbus messages

[Ivan Shmakov]

Control: reopen -1
Control: found -1 2:1.19.2-1+deb9u1

> Trek  writes:

 > Version: 2:1.16.4-1+deb8u1+b1

 > with the latest update, the dbus dependency is gone and the error
 > message is no more printed to the log

 > thank you!

I’m observing the same issue on Stretch (2:1.19.2-1+deb9u1.)

I guess that the fix for Debian Bug#867492 (per DSA-3905-1)
affected Stretch just as well.  Could this please be rectified?

TIA.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#875345: opencv: CVE-2017-12864: Integer overflow in ReadNumber

[Salvatore Bonaccorso]

Source: opencv
Version: 2.4.9.1+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/opencv/opencv/issues/9372

Hi,

the following vulnerability was published for opencv.

CVE-2017-12864[0]:
| In opencv/modules/imgcodecs/src/grfmt_pxm.cpp, function ReadNumber did
| not checkout the input length, which lead to integer overflow. If the
| image is from remote, may lead to remote code execution or denial of
| service. This affects Opencv 3.3 and earlier.

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-12864
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12864
[1] https://github.com/opencv/opencv/issues/9372

Regards,
Salvatore

Bug#875340: FTBFS with Java 9: getPeer()

[Rene Engelhard]

Hi,

On Sun, Sep 10, 2017 at 08:07:12PM +0100, Chris West wrote:
> getPeer() has been removed. The use here looks horrible, and exactly why
> getPeer() was removed:
> 
> /* 
> Here's the really disguisting hack.
> We have to get to the peer because TextComponent will refuse to
> let us set us set a caret position greater than the text length.
> Great.  What a piece of crap.
> */
> public void setCaretPosition( int pos ) {
> ((java.awt.peer.TextComponentPeer)getPeer()).setCaretPosition( 
> pos + countNLs() );
> }
> 

JFTR, LO did just remove it

https://cgit.freedesktop.org/libreoffice/core/commit/?id=f20810a1318a8dd55cb01e42a0fde7f0e1b36623

Regards,

Rene

Bug#856160: nettle-dev: Please transition nettle-dev to multi-arch

[Niels Möller]

Magnus Holmgren  writes:

> Well, except that CHAR_BIT requires limits.h and there need to be parentheses 
> around the expression.

I made the following fix upstream:
https://git.lysator.liu.se/nettle/nettle/commit/b7052093931d69d3626a54d59783e0d9e48ea20f

Not sure if you want something more minimal for a debian patch, but it
would be nice if you can confirm it solves the problem.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Bug#875344: opencv: CVE-2017-12863: Integer overflow in PxMDecoder::readData

[Salvatore Bonaccorso]

Source: opencv
Version: 2.4.9.1+dfsg-1
Severity: important
Tags: upstream security
Forwarded: https://github.com/opencv/opencv/issues/9371

Hi,

the following vulnerability was published for opencv.

CVE-2017-12863[0]:
| In opencv/modules/imgcodecs/src/grfmt_pxm.cpp, function
| PxMDecoder::readData has a integer overflow when calculate src_pitch.
| If the image is from remote, may lead to remote code execution or
| denial of service. This affects Opencv 3.3 and earlier.

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-12863
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12863
[1] https://github.com/opencv/opencv/issues/9371

Regards,
Salvatore

Bug#875343: FTBFS with Java 9: RM? Or tools.jar

[Chris West]

Source: carrotsearch-hppc
Version: 0.6.1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

It uses dodgy, doomed methods to try and find tools.jar.

It's a library package with no rdepends, and it's pretty outdated. We
could RM it?

The upstream version has fixed this problem; they don't depend on
tools.jar anymore. I didn't test if the upstream version fixes all the
problems, however.

Build log:

ERROR] Failed to execute goal
org.apache.maven.plugins:maven-antrun-plugin:1.8:run (generate.sources)
on project hppc: Execution generate.sources of goal
org.apache.maven.plugins:maven-antrun-plugin:1.8:run failed: Plugin
org.apache.maven.plugins:maven-antrun-plugin:1.8 or one of its
dependencies could not be resolved: Could not find artifact
sun.jdk:tools:jar:debian at specified path
/usr/lib/jvm/java-9-openjdk-amd64/../lib/tools.jar -> [Help 1]


Cheers,
Chris.

Bug#875342: opencv: CVE-2017-12862: AutoBuffer_heap_overflow in grfmt_pxm.cpp

[Salvatore Bonaccorso]

Source: opencv
Version: 2.4.9.1+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/opencv/opencv/issues/9370

Hi,

the following vulnerability was published for opencv.

CVE-2017-12862[0]:
| In modules/imgcodecs/src/grfmt_pxm.cpp, the length of buffer
| AutoBuffer _src is small than expected, which will cause copy buffer
| overflow later. If the image is from remote, may lead to remote code
| execution or denial of service. This affects Opencv 3.3 and earlier.

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-12862
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12862
[1] https://github.com/opencv/opencv/issues/9370

Regards,
Salvatore

Bug#875341: imagemagick: CVE-2017-12693

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-11
Severity: important
Tags: security patch upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/652

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-12693[0]:
| The ReadBMPImage function in coders/bmp.c in ImageMagick 7.0.6-6
| allows remote attackers to cause a denial of service (memory
| consumption) via a crafted BMP file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-12693
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12693
[1] https://github.com/ImageMagick/ImageMagick/issues/652
[2] 
https://github.com/ImageMagick/ImageMagick/commit/6709bd585b9609a9cf98a7042089f3e725886d5e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#875339: imagemagick: CVE-2017-12692

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-11
Severity: important
Tags: patch upstream security
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/653

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-12692[0]:
| The ReadVIFFImage function in coders/viff.c in ImageMagick 7.0.6-6
| allows remote attackers to cause a denial of service (memory
| consumption) via a crafted VIFF file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-12692
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12692
[1] https://github.com/ImageMagick/ImageMagick/issues/653
[2] 
https://github.com/ImageMagick/ImageMagick/commit/5919dc606bc1d6022d3d2d205a91fdbe98de9e15

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#875340: FTBFS with Java 9: getPeer()

[Chris West]

Source: bsh
Version: 2.0b4
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

getPeer() has been removed. The use here looks horrible, and exactly why
getPeer() was removed:

/* 
Here's the really disguisting hack.
We have to get to the peer because TextComponent will refuse to
let us set us set a caret position greater than the text length.
Great.  What a piece of crap.
*/
public void setCaretPosition( int pos ) {
((java.awt.peer.TextComponentPeer)getPeer()).setCaretPosition( 
pos + countNLs() );
}

Upstream is super dead, and the fork of upstream is super dead too.

Build log:

[javac] /build/bsh-2.0b4/src/bsh/util/AWTConsole.java:223: error: cannot 
find symbol
[javac] 
((java.awt.peer.TextComponentPeer)getPeer()).setCaretPosition( 
[javac]   ^
[javac]   symbol:   method getPeer()
[javac]   location: class AWTConsole



Cheers,
Chris.

Bug#875338: imagemagick: CVE-2017-12691

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-11
Severity: important
Tags: security patch upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/656

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-12691[0]:
| The ReadOneLayer function in coders/xcf.c in ImageMagick 7.0.6-6
| allows remote attackers to cause a denial of service (memory
| consumption) via a crafted file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-12691
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12691
[1] https://github.com/ImageMagick/ImageMagick/issues/656
[2] 
https://github.com/ImageMagick/ImageMagick/commit/68bbe7b8b226ed79e339296793f68f1b2bebc519

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#869836: Info received (Bug#869836: stretch-pu: package nvidia-graphics-drivers/375.82-1~deb9u1)

[Julien Aubin]

Hi,

Sorry to disturb but as this package contains critical security fixes and
because it has already been uploaded to jessie-bpo could you please upload
it to stable-updates before the point release ?

Issue for jessie-bpo :
https://lists.debian.org/debian-backports/2017/09/msg9.html


Thanks in advance,

On Sun, 13 Aug 2017 18:04:10 +0200 Julien Aubin 
wrote:
> Hi,
>
> Also tested on a third machine w/ a GeForce GTX 760 and KDE and kernel 4.9
> AMD64 and it works well too.
>
> Thanks
>
> 2017-08-13 16:51 GMT+02:00 Debian Bug Tracking System <
ow...@bugs.debian.org
> >:
>
> > Thank you for the additional information you have supplied regarding
> > this Bug report.
> >
> > This is an automatically generated reply to let you know your message
> > has been received.
> >
> > Your message is being forwarded to the package maintainers and other
> > interested parties for their attention; they will reply in due course.
> >
> > Your message has been sent to the package maintainer(s):
> >  Debian Release Team 
> >
> > If you wish to submit further information on this problem, please
> > send it to 869...@bugs.debian.org.
> >
> > Please do not send mail to ow...@bugs.debian.org unless you wish
> > to report a problem with the Bug-tracking system.
> >
> > --
> > 869836: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869836
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> >

Bug#875337: FTBFS with Java 9: crypto overloads

[Chris West]

Source: bouncycastle
Version: 1.57
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

Upstream have patched the immediate, trivial issue:
https://github.com/bcgit/bc-java/issues/209

Build log:

build-provider:
[mkdir] Created dir: 
/build/bouncycastle-1.57/build/artifacts/jdk1.5/bcprov-jdk15on-157
 [copy] Copying 3 files to 
/build/bouncycastle-1.57/build/artifacts/jdk1.5/bcprov-jdk15on-157
 [copy] Copying 3 files to 
/build/bouncycastle-1.57/build/artifacts/jdk1.5/bcprov-jdk15on-157/docs
 [copy] Copying 2053 files to 
/build/bouncycastle-1.57/build/artifacts/jdk1.5/bcprov-jdk15on-157/src
[mkdir] Created dir: 
/build/bouncycastle-1.57/build/bcprov-jdk15on-157/classes
[javac] /build/bouncycastle-1.57/ant/bc+-build.xml:111: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Use of a source 1.5 is no longer supported, switching to 1.6
[javac] Use of a target 1.5 is no longer supported, switching to 1.6
[javac] Compiling 1971 source files to 
/build/bouncycastle-1.57/build/bcprov-jdk15on-157/classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/bouncycastle-1.57/build/artifacts/jdk1.5/bcprov-jdk15on-157/src/org/bouncycastle/jcajce/provider/drbg/DRBG.java:243:
 error: reference to reseed is ambiguous
[javac] drbg.reseed(null);
[javac] ^
[javac]   both method reseed(SecureRandomParameters) in SecureRandom and 
method reseed(byte[]) in SP800SecureRandom match




Cheers,
Chris.

Bug#875336: FTBFS with Java 9: _ as identifier

[Chris West]

Source: bnd
Version: 2.4.1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

Using _ as an identifier is not allowed at -source 9; use older -source
or fix the code.

The package is a very old version; upstream fixed the code > 6 years
ago, so updating would probably fix it.

Build log:

[mkdir] Created dir: /build/bnd-2.4.1/bootstrap/build
[javac] /build/bnd-2.4.1/debian/bootstrap.xml:15: warning: 
'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to 
false for repeatable builds
[javac] Compiling 427 source files to /build/bnd-2.4.1/bootstrap/build
[javac] 
/build/bnd-2.4.1/aQute.libg/src/aQute/lib/collections/ExtList.java:19: error: 
as of release 9, '_' is a keyword, and may not be used as an identifier
[javac] public ExtList(Collection _) {
[javac]  ^
[javac] 
/build/bnd-2.4.1/aQute.libg/src/aQute/lib/collections/ExtList.java:20: error: 
as of release 9, '_' is a keyword, and may not be used as an identifier
[javac] super(_);
[javac]   ^




Cheers,
Chris.

Bug#875335: predictable /tmp file vulnerability while building lp-solve

[Helmut Grohne]

Source: lp-solve
Version: 5.5.0.15-4
Severity: important
Tags: security
User: helm...@debian.org
Usertags: rebootstrap

Building the lp-solve package exposes users to a predictable /tmp file
vulnerability. debian/rules runs lpsolve55/ccc. That script hard codes
/tmp/platform.c. By setting up a carefully crafted symbolic link, and
attacker on the same machine can gain privileges of the user running an
lp-solve build. I did not request a CVE for this issue.

Helmut

Bug#875297: dracut: Support early loading microcode on Debian

[Henrique de Moraes Holschuh]

On Sun, 10 Sep 2017, Philipp Kern wrote:
> On 09/10/2017 02:32 PM, Philipp Kern wrote:
> > 3) Add a patch to dracut.sh (/usr/bin/dracut) because intel-microcode
> > uses the .initramfs suffix for the ucode files where it requests early
> > loading. Given that hostonly is the default for dracut, only including
> > microcode for the machine it is currently running on, we need to add a
> > star to the pattern it looks for:
> > 
> > Index: dracut-045+132/dracut.sh
> > ===
> > --- dracut-045+132.orig/dracut.sh
> > +++ dracut-045+132/dracut.sh
> > @@ -1649,7 +1649,7 @@ if [[ $early_microcode = yes ]]; then
> >  _src="*"
> >  dinfo "*** Constructing ${ucode_dest[$idx]} "
> >  if [[ $hostonly ]]; then
> > -_src=$(get_ucode_file)
> > +_src="$(get_ucode_file)*"
> >  [[ $_src ]] || break
> >  [[ -r $_fwdir/$_fw/$_src ]] || break
> >  fi
> 
> Unfortunately I left out a line that I didn't copy over when preparing
> the patch. Updated version:
> 
> Index: dracut-045+132/dracut.sh
> ===
> --- dracut-045+132.orig/dracut.sh
> +++ dracut-045+132/dracut.sh
> @@ -1649,9 +1649,8 @@ if [[ $early_microcode = yes ]]; then
>  _src="*"
>  dinfo "*** Constructing ${ucode_dest[$idx]} "
>  if [[ $hostonly ]]; then
> -_src=$(get_ucode_file)
> +_src="$(get_ucode_file)*"
>  [[ $_src ]] || break
> -[[ -r $_fwdir/$_fw/$_src ]] || break
>  fi
> 
>  for i in $_fwdir/$_fw/$_src; do
> 

Thanks.  I wish dracut grew hooks/extensions support to be extensible /
enhanced by other packages...

In the long run, it might be a good idea to detect when
/usr/sbin/iucode_tool is available, and in that case use an alternate
code path to implement early-initramfs support and microcode selection
using iucode-tool and the same behavior config files as the
initramfs-tools extension modules provided by the intel-microcode
package.

-- 
  Henrique Holschuh

Bug#856160: nettle-dev: Please transition nettle-dev to multi-arch

[Magnus Holmgren]

Sunday, 27 August 2017 at 09:40:34 CEST Hugh McMaster wrote:
> Dear Maintainer,
> 
> The attached patch fixes the header conflict in nettle-dev.
> 
> Once it is applied, the package can be marked Multi-Arch: same.

Well, except that CHAR_BIT requires limits.h and there need to be parentheses 
around the expression.

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#875334: FTBFS with Java 9: javax.xml.bind

[Chris West]

Source: biojava4-live
Version: 4.2.7+dfsg
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

javax.xml.bind has been removed from the default classpath. Please see the
section on the wiki for further details, and hopefully eventually a
solution.

Build log:

[mkdir] Created dir: 
/build/biojava4-live-4.2.7+dfsg/buildtest/biojava4-aa-prop/classes
[javac] /build/biojava4-live-4.2.7+dfsg/biojava-aa-prop/build.xml:86: 
warning: 'includeantruntime' was not set, defaulting to 
build.sysclasspath=last; set to false for repeatable builds
[javac] Compiling 9 source files to 
/build/biojava4-live-4.2.7+dfsg/buildtest/biojava4-aa-prop/classes
[javac] 
/build/biojava4-live-4.2.7+dfsg/biojava-aa-prop/src/test/java/org/biojava/nbio/aaproperties/CookBookTest.java:29:
 error: package javax.xml.bind is not visible
[javac] import javax.xml.bind.JAXBException;
[javac] ^
[javac]   (package javax.xml.bind is declared in module java.xml.bind, 
which is not in the module graph)
[javac] 
/build/biojava4-live-4.2.7+dfsg/biojava-aa-prop/src/test/java/org/biojava/nbio/aaproperties/CookBookTest.java:47:
 error: cannot find symbol
[javac] public void shortExample2() throws FileNotFoundException, 
JAXBException{
[javac]   ^


Cheers,
Chris.

Bug#875333: FTBFS with Java 9: tools.jar

[Chris West]

Source: aspectj-maven-plugin
Version: 1.7-1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

It's looking for tools.jar, which has gone.
There is an upstream issue:
https://github.com/mojohaus/aspectj-maven-plugin/issues/24

Build log:

INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] 'dependencies.dependency.systemPath' for com.sun:tools:jar must specify 
an absolute path but is ${toolsjarSystemPath} @ line 175, column 16
 @ 
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]   
[ERROR]   The project org.codehaus.mojo:aspectj-maven-plugin:1.7 
(/build/aspectj-maven-plugin-1.7/pom.xml) has 1 error
[ERROR] 'dependencies.dependency.systemPath' for com.sun:tools:jar must 
specify an absolute path but is ${toolsjarSystemPath} @ line 175, column 16
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException




Cheers,
Chris.

Bug#875331: r-cran-dotcall64: FTBFS on hurd-i386: PATH_MAX undeclared

[Aaron M. Ucko]

Source: r-cran-dotcall64
Version: 0.9.04-1
Severity: important
Tags: upstream
Justification: fails to build from source

The build of r-cran-dotcall64 for hurd-i386 (admittedly not a release
architecture) failed:

  dotCall64.c:88:19: error: 'PATH_MAX' undeclared (first use in this function); 
did you mean 'INT8_MAX'?

The Hurd has no hard PATH_MAX.  Best practice is to substitute
pathconf(_PC_PATH_MAX), which can in turn entail allocating more
buffers dynamically.  Alternatively, you can supply a fallback
constant definition, typically 4096.

Could you please take a look?

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#875332: FTBFS with Java 9: sun.misc.URLClassPath

[Chris West]

Source: openhft-affinity
Version: 2.2-1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9
Tags: fixed-upstream

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

Upstream have rewritten the class:
https://github.com/OpenHFT/Java-Thread-Affinity/issues/37

Build log:

[ERROR] 
/build/openhft-affinity-2.2/affinity/src/main/java/net/openhft/affinity/BootClassPath.java:[23,16]
 cannot find symbol
  symbol:   class URLClassPath
  location: package sun.misc



Cheers,
Chris.

Bug#875330: O: brewtarget -- needs a new maintainer

[Philip Lee]

Package: wnpp
Severity: normal

The debian packaging for this project has been maintained here:
https://github.com/Brewtarget/debian-packaging I would love someone to take
over this repo. The source packages are here, including 2.3.1-1 which
should be uploaded to debian ASAP:
https://github.com/Brewtarget/brewtarget/releases

Bug#875329: FTBFS with Java 9: _ as identifier

[Chris West]

Source: akuma
Version: 1.10-1
Severity: normal
User: debian-j...@lists.debian.org
Usertags: default-java9

This package fails to build with default-jdk pointing to openjdk-9-jdk.
Please fix it, so that we can start the transition to Java 9.
The wiki has some common problems and their solutions:
https://wiki.debian.org/Java/Java9Pitfalls

_ is not a valid identifier any longer.
Upstream issue, currently ignored:
https://github.com/kohsuke/akuma/issues/14

Build log:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:2.10.4:jar (default-cli) on 
project akuma: MavenReportException: Error while generating Javadoc: 
[ERROR] Exit code: 1 - 
/build/akuma-1.10/src/main/java/com/sun/akuma/JavaVMArguments.java:380: error: 
as of release 9, '_' is a keyword, and may not be used as an identifier
[ERROR] IntByReference _ = new IntByReference();
[ERROR]^
[ERROR] /build/akuma-1.10/src/main/java/com/sun/akuma/JavaVMArguments.java:388: 
error: as of release 9, '_' is a keyword, and may not be used as an identifier
[ERROR] if(LIBC.sysctl(new int[]{CTL_KERN,KERN_ARGMAX},2, 
argmaxRef.getPointer(), size, NULL, _)!=0)



Cheers,
Chris.

Bug#875328: jellyfish1: FTBFS: __sync_val_compare_and_swap_8 undefined

[Aaron M. Ucko]

Source: jellyfish1
Version: 1.1.11-2
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of jellyfish1 for mips(el) and the non-release architectures
m68k, powerpc(spe), and sh4 have been failing:

  ././jellyfish/atomic_gcc.hpp:27: undefined reference to 
`__sync_val_compare_and_swap_8'
  jellyfish/mer_counter.o:././jellyfish/atomic_gcc.hpp:27: more undefined 
references to `__sync_val_compare_and_swap_8' follow
  collect2: error: ld returned 1 exit status
  Makefile:1082: recipe for target 'bin/jellyfish' failed

Please link against -latomic, at least on these architectures.  You
can avoid a formal dependency on libatomic on architectures that don't
actually need it without hardcoding an architecture list by prefacing
-latomic with -Wl,--as-needed (and optionally following it with
-Wl,--no-as-needed).

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#874166: RFS: node-grunt-babel

[Rahulkrishnan R A]

Dear mentors,

I am looking for a sponsor for the following package:

* Package name: node-grunt-babel
  Version : 7.0.0-1
  Upstream Author : Sindre Sorhus 
* URL : *https://github.com/babel/grunt-babel
*
* License : Expat
  Section : web

Please check out the package by visiting the following URL:

https://anonscm.debian.org/git/pkg-javascript/node-grunt-babel.git

It is lintian clean


Changes since last upload:

 * Initial release (Closes: #874166)


Consider to review and upload it.

Regards,

Rahulkrishnan R A

Bug#829485: roundcube-core: noninteractive configuration fails when preseeding to use postgres

[Paul Gevers]

Control: tags -1 moreinfo

Hi Mike,

On Sun, 03 Jul 2016 14:07:00 -0400 Mike Ashley 
wrote:
> * roundcube/database-type: mysql
   ^
This is the weird line if I am correct, that should read psql.

Can you please repeat what you did with "dbc_debug=true" set and
copy/paste the output. Please check for credentials, I am not sure if
they are hidden by default.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#875327: QJson removal in Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: openambit
Version: 0.3-1
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qjson-removal

Hi! As you might know we the Qt/KDE team are preparing to remove Qt4.
This means that we need to remove QJson from the archive too.

In order to make this move, all packages directly or indirectly depending on
the QJson library have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =


 
Some of us where involved in various Qt4 to Qt5 migrations [migration] and we   

 
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less   

 
painful than it was from Qt3 to Qt4.

 


 
Noreover porting from QJson to Qt5's QJson (part of the official API) tends to  

 
be quite easy.  

 


 
Don't forget to take a look at the C++ API changes page [apichanges] whenever   

 
you start porting your application. 

 

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org


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

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

Bug#868558: nmu: multiple r-* packages

[Dirk Eddelbuettel]

On 10 September 2017 at 16:15, Niels Thykier wrote:
| To be perfectly, honest, I would prefer if you did a proper ABI-like
| transition over the Breaks.  At this scale, Breaks seems too fragile and
| too likely for people to get wrong.

I *am* -- all packages (currently) get have r-api-3:

  edd@bud:~$ apt-cache show r-cran-rcpp | grep r-api-3
  Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libstdc++6 (>= 5.2), 
r-base-core (>= 3.3.1-1), r-api-3, littler, r-cran-pkgkitten
  edd@bud:~$ 
|
Next April they will have r-api-4.  *This case* did not warrant puzting with
r-api-* and you will have to take my word for it.

| > Dear debian-release:  Please remove this block.
| > 
| I respectfully decline.

That's truly and madly saddening. So I will just code around you and direct
users to a different repo.  We have been doing that via an informal backports
repo available at all CRAN mirrors anyway.

It's too bad, but we all have our standards to live by.

Apparently I am now rogue as far as the release teams goes. Life goes on.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org