Bug#914464: Any update?

[Jelmer Vernooij]

On Mon, Jan 21, 2019 at 05:08:15PM +0100, Filip Pytloun wrote:
> any update with this package?
> I would need it to build newer vdirsyncer.
I've just uploaded to NEW.

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#914160: qcontrol: Job dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device/start

[Ian Campbell]

On Mon, 2019-01-21 at 19:36 +0100, Bernhard Übelacker wrote:
> Is this supposed to work at the moment or already known,
> or should I report it, if yes to which package.

I think flash-kernel is probably the right starting point, although it
might turn out to be a kernel issue.

> Which information are needed, is /var/log/syslog sufficient?

That plus the `dmesg` output too should be a good starting point.

Ian.

Bug#920032: qemu-user uses wrong struct timeval on sparc

[Ben Hutchings]

Package: qemu-user
Version: 1:3.1+dfsg-2
Severity: important
Tags: patch

On sparc (only) Linux defines timeval::tv_usec with type int, not
long.  However qemu-user's definition of struct target_timeval uses
abi_long unconditionally.  This results in the syscall translation
layer effectively multiplying tv_usec by 2**32.  All sparc syscalls
passing non-zero values for this field fail with -EINVAL.  The
following patch seems to fix this.

Ben.

--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -210,7 +210,11 @@ struct target_linger {
 
 struct target_timeval {
 abi_long tv_sec;
+#if defined (TARGET_SPARC)
+abi_int tv_usec;
+#else
 abi_long tv_usec;
+#endif
 };
 
 struct target_timespec {
--- END ---

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

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

Versions of packages qemu-user depends on:
ii  libc6 2.28-3
ii  libcapstone3  3.0.5-3
ii  libgcc1   1:8.2.0-13
ii  libglib2.0-0  2.58.1-2
ii  libstdc++68.2.0-13
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages qemu-user recommends:
ii  qemu-user-static [qemu-user-binfmt]  1:3.1+dfsg-2

Versions of packages qemu-user suggests:
ii  sudo  1.8.26-2

-- no debconf information

Bug#919951:

[Anil Madhavapeddy]

Ian Jackson wrote:
> Note that this ocaml tool `dune' was previously known as `jbuilder'.
> It has nothing to do with Java AIUI.  

The term ‘jbuilder’ came from the fact that the project originated as
an internal build tool at Jane Street, which was then subsequently
open sourced and adapted by the OCaml community.

It had to be renamed due to trademarks quite soon after
open sourcing, and there was a search for a new name at:
https://github.com/ocaml/dune/issues/360

The winning suggestion here was Dune:
https://github.com/ocaml/dune/issues/360#issuecomment-350895720

which noted the existence of a numerical *library* that didn’t
install a binary called dune, and so we didn’t have a clash.

> No-one has suggested a plausible charitable explanation for
> why the ocaml upstream made such egregiously bad naming
> mistakes twice in succession.

Has anyone actually bothered to ask the Dune maintainers
this question?  Are we supposed to track all Debian mailing
lists in the hope that we’ll run across a query about our work?

To state the obvious, Caml has had a desert-naming theme
for quite some time (since it originates from before the Debian
project even began).  We did our research with the Dune
name, and I fail to understand why this block in Debian
reasonably exists, particularly as libdune (the numerical
library) doesn’t install anything called `/usr/bin/dune`.

I also dispute your rather dubious claim that there was 
"rough consensus” about this. Looking at the bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622

As far as I can tell from browsing the archives, the
*only person* to seriously object is you, and that too with very
misleading comments. To quote you from:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622

Ian Jackson wrote:
> What on earth possessed them to pick the name `dune' ?  Even if they
> couldn't be bothered to do a Debian file search,
> https://www.google.com/search?q=dune+software
> https://en.wikipedia.org/wiki/Dune_(software)
> https://www.google.com/search?q=%2Fusr%2Fbin%2Fdune
> Under the circumstances it seems obvious that no-one should be allowed
> the name /usr/bin/dune.

To follow your own queries above, the file search reveals the only use of 
/usr/bin/dune to be a VRML editor.  Since that upstream is actually called
white_dune, surely the obvious conclusion is that that binary should
be renamed after a polite request to the maintainers of the desktop
tool.

regards,
Anil

Bug#914771: cannot load such file -- bundler-1.16.1/exe/bundle

[arpin . hugo]

Hi,

Sorry if I don't follow the guidelines, I just switched to debian.
I too have encoutered this error, here is an example that can reproduce
the bug by installing rails 5 from scratch.

#!/bin/bash

# Install the dependencies for rails 5
sudo apt install -y ruby ruby-dev ruby-bundler git libsqlite3-dev base-
devel

ROOT="$HOME/rails5"
rm -rf "${ROOT}" && mkdir "${ROOT}" && cd "${ROOT}"

bundle init
bundle config --local path ./.bundle

echo 'gem "rails", "~> 5.0"' >> Gemfile
bundle install

# This will fail: No such file or directory -- /usr/lib/ruby/exe/bundle
(LoadError)
bundle exec rails new . <<< "y"

I'm on buster, since the new release is coming soon, I think this is a
good time to update bundler.
I think v1.17.3 would be a great choice, I don't think it would break
any existing applications, bundler is usually very stable, but I'm not
100% on this.

Thanks!

Bug#920031: schleuder: DEP8 failures with ruby-mail 2.7.1

[Andreas Hasenack]

Package: schleuder
Version: 2.7.1+dfsg1-1
Severity: normal

Dear Maintainer,

The DEP8 tests from schleuder are currently failing on all arches
because it can't find ruby-mail 2.6.0:

https://ci.debian.net/packages/s/schleuder/

The test output doesn't show it, but here is a manual run in an Ubuntu
Disco LXD container:

https://pastebin.ubuntu.com/p/Tp3g2PFPp7/
...
/usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could
not find 'mail' (~> 2.6.0) - did find: [mail-2.7.1]
(Gem::MissingSpecVersionError)

I found these upstream:
- https://0xacab.org/schleuder/schleuder/merge_requests/128/diffs:
commit that pinned ruby-mail to 2.6.0
- https://0xacab.org/schleuder/schleuder/issues/277: "ruby-mail 2.7.0
breaks unicode and various other formats
"

I hacked the gem spec to allow ruby-mail 2.7.1, which is what we have
in Ubuntu Disco and Debian Testing, and the test run had two failures:

https://pastebin.ubuntu.com/p/WZhZf42gJg/
...

Failures:

  1) user sends keyword x-resend with utf-8 body and umlauts
 Failure/Error:
expect(message.parts[1].body.to_s.force_encoding(message.parts[1].charset)).to
eql(content_body.encode(message.parts[1].charset))

   expected: "This is a test\nAnd here are some umlauts:ÄäÖöÜüß"
got: "This is a test\r\nAnd here are some umlauts:ÄäÖöÜüß"

   (compared using eql?)

   Diff:

 # ./spec/schleuder/integration/keywords_spec.rb:1923:in `block (2
levels) in '
 # ./spec/spec_helper.rb:47:in `block (3 levels) in '
 # ./spec/spec_helper.rb:46:in `block (2 levels) in '

  2) user sends keyword x-resend with iso-8859-1 body
 Failure/Error:
expect(message.parts[1].body.to_s.force_encoding(message.parts[1].charset)).to
eql(content_body.encode(message.parts[1].charset))

   expected: "Hello again! \xA1Hola!\n"
got: "Hello again! \xA1Hola!\r\n"

   (compared using eql?)

   Diff:

 # ./spec/schleuder/integration/keywords_spec.rb:1881:in `block (2
levels) in '
 # ./spec/spec_helper.rb:47:in `block (3 levels) in '
 # ./spec/spec_helper.rb:46:in `block (2 levels) in '

Bug#919829: libatteanx-store-sparql-perl: FTBFS (failing tests)

[Niko Tyni]

On Sun, Jan 20, 2019 at 12:19:21AM +, Santiago Vila wrote:
> Package: src:libatteanx-store-sparql-perl
> Version: 0.010-1
> Severity: serious
> Tags: ftbfs

> Test Summary Report
> ---
> t/plan.t   (Wstat: 65280 Tests: 0 Failed: 0)
>   Non-zero exit status: 255
>   Parse errors: No plan found in TAP output
> Files=2, Tests=1,  7 wallclock secs ( 0.05 usr  0.01 sys +  5.78 cusr  0.51 
> csys =  6.35 CPU)
> Result: FAIL

  $ perl -Iblib/lib  t/plan.t 
  Can't apply Attean::API::Model to AtteanX::Model::SPARQL - missing 
count_quads_estimate at /usr/share/perl5/Moo/Role.pm line 280.
  Compilation failed in require at t/plan.t line 5.
  BEGIN failed--compilation aborted at t/plan.t line 5.

This seems to have broken with libattean-perl 0.020-1. The upstream changelog
states:

  (Update) Expose count_quads_estimate method at the model level.

-- 
Niko Tyni   nt...@debian.org

Bug#917864: closed by Gianfranco Costamagna (Re: Fails to build for non-current kernel version)

[Ben Hutchings]

On Mon, 2019-01-21 at 07:55 +, Gianfranco Costamagna wrote:
>  Hello, so it didn't build correctly?do you have a build log?

It was in my last message.

> I'm failing to understand why this can't be a m-a bug...I'm not an
> user of m-a myself, but I usually create a deb file and then dpkg -i
> it.

The bug is in the makefile you provide to module-assistant.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.




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

Bug#914160: qcontrol: Job dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device/start

[Bernhard Übelacker]

Hello Ian,
additionally I found a new installer in [1].
Therefore I tried to install current buster directly.
The relevant part of qcontrol below.

Unfortunately the installation reported a failure later.

Is this supposed to work at the moment or already known,
or should I report it, if yes to which package.
Which information are needed, is /var/log/syslog sufficient?

Kind regards,
Bernhard


[1] 
http://ftp.debian.org/debian/dists/buster/main/installer-armel/20190118/images/kirkwood/network-console/qnap/ts-11x/kernel-6282

Jan 21 16:58:59 in-target: qcontrol (0.5.6-4) wird eingerichtet ...^M
Jan 21 16:58:59 in-target: Running in chroot, ignoring request.
Jan 21 16:58:59 in-target: ^M
Jan 21 16:58:59 in-target: update-initramfs: deferring update (trigger 
activated)^M
Jan 21 16:58:59 in-target: Running in chroot, ignoring request.
Jan 21 16:58:59 in-target: ^M
Jan 21 16:58:59 in-target: invoke-rc.d: policy-rc.d denied execution of start.^M
Jan 21 16:59:01 in-target: Created symlink 
/etc/systemd/system/multi-user.target.wants/qcontrol.service → 
/lib/systemd/system/qcontrol.service.
Jan 21 16:59:01 in-target: ^M
Jan 21 16:59:02 in-target: Created symlink 
/etc/systemd/system/multi-user.target.wants/qcontrold.service → 
/lib/systemd/system/qcontrold.service.
Jan 21 16:59:02 in-target: ^M
Jan 21 16:59:04 in-target: Created symlink 
/etc/systemd/system/sockets.target.wants/qcontrold.socket → 
/lib/systemd/system/qcontrold.socket.
Jan 21 16:59:04 in-target: ^M
Jan 21 16:59:04 in-target: Trigger für libc-bin (2.28-5) werden verarbeitet ...
...
Jan 21 17:44:02 in-target: u-boot-tools wurde als manuell installiert 
festgelegt. 
 
Jan 21 17:44:02 in-target: 0 aktualisiert, 0 neu installiert, 0 zu entfernen 
und 0 nicht aktualisiert.   
  
Jan 21 17:44:03 in-target: update-initramfs: Generating 
/boot/initrd.img-4.19.0-1-marvell   
   
Jan 21 17:44:17 in-target: kirkwood-qnap: machine: QNAP TS219 family

   
Jan 21 17:44:17 in-target: Using DTB: kirkwood-ts219-6282.dtb   

   
Jan 21 17:44:18 in-target: Installing 
/usr/lib/linux-image-4.19.0-1-marvell/kirkwood-ts219-6282.dtb into 
/boot/dtbs/4.19.0-1-marvell/./kirkwood-ts219-6282.dtb   
  
Jan 21 17:44:18 in-target: Installing new kirkwood-ts219-6282.dtb.  

   
Jan 21 17:44:18 in-target: flash-kernel: installing version 4.19.0-1-marvell

   
Jan 21 17:44:23 in-target: /proc/mtd doesn't exist  

   
Jan 21 17:44:24 flash-kernel-installer: error: flash-kernel failed  

   

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Chris Lamb]

tags 919979 - moreinfo
tags 919979 + pending
thanks

Chris Lamb wrote:

> > Packages should not install and ship headers in /usr/include/python3.7/
> > but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
> 
> Why? I'll need such an explanation for the long description. :)

I've freestyled this myself:

  
https://salsa.debian.org/lintian/lintian/commit/e02972d10255fbc40358e7d3561bfd4b135c39c9

Uploading in a few moments.


Regards,

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

Bug#916702: Merge request

[Dave Steele]

Upstream upgrade available as a merge request.

https://salsa.debian.org/debian/python-freezegun/merge_requests

Bug#911327: add .libretro metadata for better integration with gnome-games

[Jeremy Bicha]

Sergio, I opened a merge request for this issue, because I know when
we discussed this in 2017, you didn't think it was appropriate to add
these .libretro files to each package.

Since then, we're already adding AppStream metadata to these packages
so I don't see the harm of adding one more small file to our packaging
and I'd like to do that work and the uploads.

I think adding that to each package is the best place for that
metadata. With the exception of libretro-core-info, metadata for a
package belongs in that package not somewhere else.

Please take a look at this soon since I'd like to fix this issue in
time for Buster's release.

https://salsa.debian.org/games-team/mgba/merge_requests/1
https://gitlab.gnome.org/GNOME/gnome-games/issues/79

Thanks,
Jeremy Bicha

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[Tollef Fog Heen]

]] Stéphane Glondu 

Hi,

> Le 20/01/2019 à 23:14, Ian Jackson a écrit :
> > In #919622 and the associated debian-devel thread,
> >  "Conflict over /usr/bin/dune"
> >   https://lists.debian.org/debian-devel/2019/01/msg00227.html
> > the file conflict over /usr/bin/dune was discussed.
> > 
> > The rough consensus of the debian-devel thread was that /usr/bin/dune
> > ought definitely not to be taken by the ocaml build system, and that
> > the best claim on it was the C++ library which already provides a
> > number of /usr/bin/dune?* binaries.
> 
> I do not agree there was such concensus.

FWIW, I don't think there was any particularly clear consensus, and I
also don't think that an absence of a veto from the whitedune
maintainers makes it ok to go ahead and NMU whitedune with a renamed
binary.

[...]

> > Additionally the binary package name `dune' for the ocaml tool is bad,
> > too.
> 
> Actually, I am not fond of the `dune' name either, but I think it's not
> my job to judge and rename it. And I would feel ridiculous asking
> upstream for a change (I am already ashamed of this situation).

It's not unusual for packages in Debian to be renamed and have their
binaries renamed to avoid naming conflicts and it is part of the work of
being a maintainer to ensure a package fits well into the Debian
ecosystem.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#919960: sync packages

[Andreas Metzler]

On 2019-01-21 積丹尼 Dan Jacobson  wrote:
> Package: exim4

> Odd, something is out of sync:

> The following packages have unmet dependencies:
>  exim4 : Depends: exim4-base (< 4.92~RC4-2.1) but 4.92~RC4-3 is to be 
> installed
> The following actions will resolve these dependencies:

>  Remove the following packages:
> 1) exim4 [4.92~RC4-2 (now)]

> Accept this solution? [Y/n/q/?] n
> The following actions will resolve these dependencies:

>  Keep the following packages at their current version:
> 1) exim4-base [4.92~RC4-2 (now)]

Hello,

The packages are in sync on all release architectures. See

ametzler@argenau:~$ rmadison --suite=sid exim4-base exim4
exim4  | 4.89-7| unstable   | source, all
exim4  | 4.90.1-5  | unstable   | source, all
exim4  | 4.92~RC4-3| unstable   | source, all
exim4-base | 4.89-7| unstable   | hurd-i386
exim4-base | 4.90.1-5  | unstable   | kfreebsd-amd64, kfreebsd-i386
exim4-base | 4.92~RC4-3| unstable   | amd64, arm64, armel, armhf, i386, 
mips, mips64el, mipsel, ppc64el, s390x

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#919835: mgba; AppStream metadata isn't being used because of its license

[Jeremy Bicha]

Sergio, please take a look at my merge proposal to fix this issue. We
need your approval to merge it.

https://salsa.debian.org/games-team/mgba/merge_requests/2

You can get your own Salsa account at https://signup.salsa.debian.org/
Let the Debian Games team know when you have an account so that we can
give you permissions to update your packages.

Thanks,
Jeremy Bicha

Bug#919389: wpasupplicant: 2.7 fails to connect to (hidden) network

[Andrej Shadura]

On Mon, 21 Jan 2019 at 19:13, Andrej Shadura  wrote:
>
> On Tue, 15 Jan 2019 at 14:08, Andrej Shadura  wrote:
> > Hi,
> >
> > Forwarding yet another issue; this time, with BCM4360 :(
>
> One of the users (cc'ed) adds to the bug report:
>
> ===
> Dear Maintainer,
>
> I am also seeing (probably) the same problem with wl.
> My machine works with wpasupplicant <= 2:2.7~git20181004+1dd66fc-1, but
> not with >= 2:2.7-1.
> After bisecting changes to upstream and Debian packaging, I have found
> that disabling at least following build-time options, all of which have been
> enabled in 2:2.7-1 or 2:2-7-2, restores it to work well again:
>
> CONFIG_FILS
> CONFIG_MBO
> CONFIG_MESH

Yoshihito, does it fail with any of those set or only with FILS?

Thanks!

-- 
Cheers,
  Andrej

Bug#919957: Please check for binaries depending on unused libraries

[Chris Lamb]

Hi Josh,

> I think there'd still be value in catching binaries that still end up 
> with unused dependencies for some reason, but making --as-needed the 
> default will certainly reduce the incidence of such issues.

Getcha. Let's therefore revisit this after it becomes the default. :)


Regards,

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

Bug#920029: python3-zope.proxy: ships header in /usr/include/python3.7/

[Andreas Beckmann]

Package: python3-zope.proxy
Version: 4.2.0-1
Severity: serious

Hi,

your package ships the header file(s):

  /usr/include/python3.7/zope.proxy/proxy.h

but /usr/include/python3.7 is a symlink to python3.7m in
libpython3.7-dev. This may result in silent file overwrites or depending
on the unpacking order /usr/include/python3.7 being a directory in some
cases, separating the headers into two independent trees.

These header files must be shipped in /usr/include/python3.7m/ instead.
Please talk to the python maintainers to find a proper solution for
handling the packaging of python header files in a future-proof way.


Cheers,

Andreas

Bug#920030: python3-pygame: ships headers in /usr/include/python3.7/

[Andreas Beckmann]

Package: python3-pygame
Version: 1.9.4.post1+dfsg-2
Severity: serious

Hi,

your package ships the header file(s):

 /usr/include/python3.7/pygame/_camera.h
 /usr/include/python3.7/pygame/_pygame.h
 /usr/include/python3.7/pygame/_surface.h
 /usr/include/python3.7/pygame/bitmask.h
 /usr/include/python3.7/pygame/camera.h
 /usr/include/python3.7/pygame/fastevents.h
 /usr/include/python3.7/pygame/font.h
 /usr/include/python3.7/pygame/freetype.h
 /usr/include/python3.7/pygame/mask.h
 /usr/include/python3.7/pygame/mixer.h
 /usr/include/python3.7/pygame/pgarrinter.h
 /usr/include/python3.7/pygame/pgbufferproxy.h
 /usr/include/python3.7/pygame/pgcompat.h
 /usr/include/python3.7/pygame/pgopengl.h
 /usr/include/python3.7/pygame/pygame.h
 /usr/include/python3.7/pygame/scrap.h
 /usr/include/python3.7/pygame/surface.h

but /usr/include/python3.7 is a symlink to python3.7m in
libpython3.7-dev. This may result in silent file overwrites or depending
on the unpacking order /usr/include/python3.7 being a directory in some
cases, separating the headers into two independent trees.

These header files must be shipped in /usr/include/python3.7m/ instead.
Please talk to the python maintainers to find a proper solution for
handling the packaging of python header files in a future-proof way.


Cheers,

Andreas

Bug#920028: python3-bsddb3: ships header in /usr/include/python3.7/

[Andreas Beckmann]

Package: python3-bsddb3
Version: 6.2.6-2
Severity: serious

Hi,

your package ships the header file(s):

  /usr/include/python3.7/bsddb3/bsddb.h

but /usr/include/python3.7 is a symlink to python3.7m in
libpython3.7-dev. This may result in silent file overwrites or depending
on the unpacking order /usr/include/python3.7 being a directory in some
cases, separating the headers into two independent trees.

These header files must be shipped in /usr/include/python3.7m/ instead.
Please talk to the python maintainers to find a proper solution for
handling the packaging of python header files in a future-proof way.


Cheers,

Andreas

Bug#920027: python3-persistent: ships headers in /usr/include/python3.7/

[Andreas Beckmann]

Package: python3-persistent
Version: 4.2.2-1
Severity: serious

Hi,

your package ships the header file(s):

 /usr/include/python3.7/persistent/cPersistence.h
 /usr/include/python3.7/persistent/ring.h

but /usr/include/python3.7 is a symlink to python3.7m in
libpython3.7-dev. This may result in silent file overwrites or depending
on the unpacking order /usr/include/python3.7 being a directory in some
cases, separating the headers into two independent trees.

These header files must be shipped in /usr/include/python3.7m/ instead.
Please talk to the python maintainers to find a proper solution for
handling the packaging of python header files in a future-proof way.


Cheers,

Andreas

Bug#920026: python-greenlet-dev: ships header in /usr/include/python3.7/

[Andreas Beckmann]

Package: python-greenlet-dev
Version: 0.4.15-1
Severity: serious

Hi,

your package ships the header file(s):

  /usr/include/python3.7/greenlet/greenlet.h

but /usr/include/python3.7 is a symlink to python3.7m in
libpython3.7-dev. This may result in silent file overwrites or depending
on the unpacking order /usr/include/python3.7 being a directory in some
cases, separating the headers into two independent trees.

These header files must be shipped in /usr/include/python3.7m/ instead.
Please talk to the python maintainers to find a proper solution for
handling the packaging of python header files in a future-proof way.


Andreas

Bug#918475: mercurial: CipherString = DEFAULT@SECLEVEL=2 from 1.1.1~~pre6-1 breaks it

[Stefan Huehner]

Package: mercurial
Version: 4.8.2-1
Followup-For: Bug #918475

Hello,
i am also getting the same error on my sid system and after asking from
#debian/#debian-next tried a bit more.

openssl s_client -connect api.media.atlassian.com:443

is enough to get same error message. So topic should maybe be moved to
openssl package.
Trying various versions from snapshot.debian.net (withou touching
openssl.conf (downgrading both libssl1.1+openssl packages)

Last working: 1.1.1~~pre4
First failing: 1.1.1~~pre6-2 (-1 does not have binaries on
snapshot.debian.net)

Change triggering the issue seems to be the SecurityLevel change in
/etc/ssl/openssl.conf
Commenting out this line on unmodified sid with latest libssl/openssl is
enough to make connection work.
Also lowering minTLS version from 1.2 to 1.10 without touching
Cipersuite makes connection work again.

Reading i.e.
https://wiki.debian.org/ContinousIntegration/TriagingTips/openssl-1.1.1
page i don't understand the problem as the server config in atlassian
looks fine to not use any low grade security and s_client connects with:
TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256

Apart atlassian recently changed their config to raise min-version of
their bitbucket.org hosting to be TLSv1.2 (note that host talked about
in this issue is related to that service (used in their clonebundles).

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

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

Versions of packages mercurial depends on:
ii  libc6 2.28-5
ii  mercurial-common  4.8.2-1
ii  python2.7.15-4
ii  ucf   3.0038+nmu1

Versions of packages mercurial recommends:
ii  openssh-client  1:7.9p1-5

Versions of packages mercurial suggests:
ii  meld  3.20.0-1
pn  qct   

-- no debconf information

Bug#919957: Please check for binaries depending on unused libraries

[Josh Triplett]

On January 21, 2019 8:48:35 AM PST, Chris Lamb  wrote:
>Hi Matthias,
>
>> [...] I think I'll enable that by default in GCC 9 for bullseye.
>
>Cool. I think that therefore asking Developers to add it manually
>via Lintian would therefore not be ideal - what do you think?

I think there'd still be value in catching binaries that still end up with 
unused dependencies for some reason, but making --as-needed the default will 
certainly reduce the incidence of such issues.

Bug#818793: Segmentation fault related to log filename and dateformat length when using compress, sharedscripts, olddir

[Bernhard Übelacker]

Dear Maintainer,
found while searching for another bug that upstream
report [1] that looked familiar.

That upstream report points to the same source line
and is written to be resolved by [2] with topic dateformat.
This patch seems included first in debian stretch with
version 3.11.0-0.1 [3].

My last mail and this one is just based on the backtrace
in message #25.

Maybe that is enough to close this bug as fixed?

Kind regards,
Bernhard

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1369438
[2] 
https://github.com/logrotate/logrotate/commit/768b23c0bd94f973abf108f6e2cf4138c426f140
[3] https://sources.debian.org/src/logrotate/3.11.0-0.1/logrotate.c/#L1516

Bug#920025: python3-lib389: Missing dependency on libnss3-tools

[Jan Luca Naumann]

Package: python3-lib389
Version: 1.4.0.20-3
Severity: normal

The package python3-lib389 is missing a dependency on the package
libnss3-tools which provides the tool certutil. Without this package
the instance creation via dscreate is broken if using self-signed
certificate.

Bug#915689: Fwd: Re: Bug#919893: package shouldn't exist

[Diederik de Haas]

On maandag 21 januari 2019 17:13:42 CET Michael Stone wrote:
> >Entropy generation for the creation of SSH keys as the netinstaller is
> >mostly used in headless situations.
> >https://github.com/debian-pi/raspbian-ua-netinst/issues/42
> 
> That functionality doesn't require the old package; will work fine with
> rng-tools5.

Great, thanks :)

FTR: That *I* don't need it in my particular use case does not mean that no 
one has a need for the functionality now provided by rng-tools-debian

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

Bug#911322: [Android-tools-devel] Bug#911322:

[Lampa]

When downloading from
https://developer.android.com/studio/releases/platform-tools noother
libraries are required (statically linked ?)

ldd adb
linux-vdso.so.1 (0x7ffc6b1fd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f7b9e025000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f7b9e004000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f7b9de81000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f7b9de77000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f7b9de5d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7b9dc9c000)
/lib64/ld-linux-x86-64.so.2 (0x7f7b9e283000)

po 21. 1. 2019 v 17:34 odesílatel Hans-Christoph Steiner  napsal:
>
> Lampa:
> > I don't see reason for dependency on android-* crap for fastboot
> > package. I want to control my phone over fastboot/adb and i don't need
> > android-* crap.
> >
> > Android-* should be marked as recommended.
>
> Without the android-* libs, fastboot/adb would not work at all.  If you
> want to change that, please send patches upstream.



-- 
Lampa

Bug#889321: Also fails in python3

[Hugh Pumphrey]

Coming back to this a year later. The only reason I am adding to the thread
is that I am moving over to python3. I can report that the bug exists in
python3 as well as python 2; the only difference is that when it crashes in
python 3 it just says "Segmentation fault".  In python 2 it says
*** Error in `python': malloc(): memory corruption: 0x56280f863970 ***
=== Backtrace: =

Aborted

Bug#920020: [Openjdk] Bug#920020: javadoc: The code being documented uses modules but the packages defined in … are in the unnamed module

[Matthias Klose]

Control: tags -1 + important

On 21.01.19 17:42, Thorsten Glaser wrote:
> Package: openjdk-11-jdk
> Version: 11.0.2+7-1

> Severity: grave
> Justification: renders package unusable

no, why are you exaggerating? Both the jre and the jdk are usable.

> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (attach-javadocs) on 
> project octopus-rpctunnel: MavenReportException: Error while generating 
> Javadoc: 
> [ERROR] Exit code: 1 - javadoc: error - The code being documented uses 
> modules but the packages defined in 
> https://docs.oracle.com/javase/8/docs/api/ are in the unnamed module.
> 
> The cause for this is:
> 
> https://bugs.openjdk.java.net/browse/JDK-8212233
> 
> The fix is (not tested by myself):
> 
> http://hg.openjdk.java.net/jdk/jdk/rev/8ce4083fc831
> via:
> https://bugs.openjdk.java.net/browse/JDK-8217177

Bug#919389: wpasupplicant: 2.7 fails to connect to (hidden) network

[YOSHINO Yoshihito]

Package: wpasupplicant
Followup-For: Bug #919389

Dear Maintainer,

I am also seeing (probably) the same problem with wl.
My machine works with wpasupplicant <= 2:2.7~git20181004+1dd66fc-1, but
not with >= 2:2.7-1.
After bisecting changes to upstream and Debian packaging, I have found
that disabling at least following build-time options, all of which have been
enabled in 2:2.7-1 or 2:2-7-2, restores it to work well again:

CONFIG_FILS
CONFIG_MBO
CONFIG_MESH

CONFIG_FILS_SK_PFS looks related to CONFIG_FILS, so I suppose this should also
be disabled, while it looks working whether or not this option is set in my
experiment. Moreover, upstream says FILS should be disabled; quoting from
wpa_supplicant/defconfig:

# Fast Initial Link Setup (FILS) (IEEE 802.11ai)
# Note: This is an experimental and not yet complete implementation. This
# should not be enabled for production use.
#CONFIG_FILS=y
# FILS shared key authentication with PFS
#CONFIG_FILS_SK_PFS=y

Note that we need to cherry-pick an upstream commit after 2.7,
f2973fa39d6109f0f34969e91551a98dc340d537, to avoid FTBFS with CONFIG_FILS
disabled.

Thanks in advance,
-- 
YOSHINO Yoshihito 

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8),
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages wpasupplicant depends on:
ii  adduser3.118
ii  libc6  2.28-5
ii  libdbus-1-31.12.12-1
ii  libnl-3-2003.4.0-1
ii  libnl-genl-3-200   3.4.0-1
ii  libnl-route-3-200  3.4.0-1
ii  libpcsclite1   1.8.24-1
ii  libreadline7   7.0-5
ii  libssl1.1  1.1.1a-1
ii  lsb-base   10.2018112800

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

Bug#918370: libqt5gui5: Krita crashes with with QT 5.11.3

[Lisandro Damián Nicanor Pérez Meyer]

tag 918370 moreinfo
thanks

El domingo, 20 de enero de 2019 06:59:36 -03 Dominique Dumont escribió:
> On vendredi 18 janvier 2019 18:44:41 CET Bernhard Übelacker wrote:
> > But I guess a Qt version containing a fix will not appear for Buster,
> > I wonder if the workarounds [1][2] for krita should be applied?
> 
> Looks like krita 4.1.7 already contains this workaround. Here's the relevant
> part found in krita 4.1.7 tarball (in libs/ui/input/kis_input_manager.cpp):
> 
> // See https://bugreports.qt.io/browse/QTBUG-72488
> #if QT_VERSION < QT_VERSION_CHECK(5, 11, 3)
> 
> But this workaround has no effect if krita was built with qt lib older than
> 5.11.3
> 
> I've rebuilt krita with up-to-date qt libs and the first test shows that
> krita no longer crashes using a tablet.
> 
> My daughter will do further tests and I'll keep you posted.
> 
> All the best

Thanks Dominique! If this is the case then we can simply fix it with a binNMU. 
Waiting for your results then.


-- 
Those are my principles. If you don't like them I have others.
 -- Groucho Marx

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


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

Bug#880393: nmuing cyrus-sasl2

[Ondřej Surý]

Hi all,

I spent a half-day hacking cyrus-sasl2 and I uploaded 2.1.27 to experimental. I 
would appreciate if more people can test the package (I won’t have time until 
tomorrow or next week). I didn’t even had a chance to test it myself, so even 
the basic it installs and nothing breaks horribly would help.

Ondrej
--
Ondřej Surý 

> On 21 Jan 2019, at 03:17, Ryan Tandy  wrote:
> 
> Hello,
> 
> I extracted Helmut's changes for this issue from the debdiff he posted in an 
> earlier message, and proposed a merge request on salsa.
> 
> https://salsa.debian.org/debian/cyrus-sasl2/merge_requests/3
> 
> as a git-format-patch(1) patch:
> 
> https://salsa.debian.org/debian/cyrus-sasl2/merge_requests/3.patch
> 
> I have built it and verified that the Depends line and library dependencies 
> are corrected, and that it is installable. I have not actually tested the 
> module's functionality.
> 
> I agree with Helmut that this looks suitable for a stretch update. I would be 
> willing to drive that process if the maintainers agree but lack time.

Bug#919860: qtcreator: Probably missing clang dependency

[Lisandro Damián Nicanor Pérez Meyer]

tag 919860 unreproducible moreinfo
thanks

Hi Salvo!

El domingo, 20 de enero de 2019 05:52:47 -03 Salvo Tomaselli escribió:
> Package: qtcreator
> Version: 4.8.1-1
> Severity: important
> 
> Dear Maintainer,
> 
> I tried the newly packaged version.
> 
> The code warnings in the editor kept appearing and disappearing, CPU usage
> went at 100%
> 
> In the General messages tab, this was printed, over and over
> 
> 2019-01-20T09:48:39 Clang Code Model: Error: The clangbackend process has
> finished unexpectedly and was restarted. 2019-01-20T09:48:40 Clang Code
> Model: Error: The clangbackend process has finished unexpectedly and was
> restarted.
[snip]

That's definitely interesting. I could not reproduce this behavior but I do 
have some ideas of what could be wrong.

I don't think anything clang/llvm is missing as a dependency, but in the 
latest upload I disabled some experimental plugins that I should not have 
enabled in the first place. If you enabled them maybe that could be causing 
the crash.

Please try either:

- Trying with a new user.
- Moving creator's config away from ~/.config. This is more involved, as it's 
not just one file:

  ~/.config/QtCreatorrc
  ~/.config/QtProject/*

Of course this needs to be done without Qt creator running.

In both cases do not enable any clang plugin not already enabled by default.


Thanks, Lisandro.

-- 
Hacer algo siempre te llevará más tiempo del que esperabas, incluso si
tienes en cuenta la ley de Hofstadter.
  Douglas Hofstadter
  http://mundogeek.net/archivos/2009/09/05/la-ley-de-hofstadter/

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


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

Bug#920024: Doesn't parse package architectures correctly when any-amd64 is used (etc.)

[Steve McIntyre]

Package: tracker.debian.org
Severity: normal

Hi folks,

Thanks for the great service on tracker. It really makes my life
easier when doing Debian work!

I've just been looking at the details for sbsigntool
(https://tracker.debian.org/pkg/sbsigntool) It looks like the tracker
code is confused by the architecture list for sbsigntool:

  Architecture: any-amd64 any-i386 arm64 armhf

and is just showing 

  arch: arm64 armhf

which is quite confusing!

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

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

Bug#920023: webpy: update package for Python 3.7 compatibility

[W. Martin Borgert]

Package: python3-webpy
Version: 1:0.38+20170615-1

The package needs to be updated to the current
git master, so that it works with Python 3.7.

Bug#919992: drbl: Remove/replace ash dependency

[Georges Khaznadar]

Hello Juan,

thank you for the bug report. I suppose that the dependency on ash was
the consequence of a typo mistake: the only dependency is bash, as some
scripts contain bashisms.

I shall fix this shortly.

Juan Picca a écrit :
> Package: drbl
> Version: 2.20.11-6
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Your package is the only one that use the package ash as dependency.
> 
> If you can change it for the package dash, the functionality remain unchanged
> and the dash source package can remove the creation of the ash package.
> 
> Also, inspecting the files in drbl package, i can't see the usage of ash/dash
> shell; the only one used is bash.
> 
> Regards,
> Juan Picca

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#919957: Please check for binaries depending on unused libraries

[Chris Lamb]

Hi Matthias,

> [...] I think I'll enable that by default in GCC 9 for bullseye.

Cool. I think that therefore asking Developers to add it manually
via Lintian would therefore not be ideal - what do you think?


Best wishes,

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

Bug#920022: gfortran: doesn't generate reproducibly the same object file for an unchanged fortran source file

[Gilles Filippini]

Package: gfortran
Version: 4:8.2.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'm filing this bug against gfortran because I can't find any related
piece of information anywhere about this reproducibility problem.

I'm just one step to achieve the Reproducible builds goal for the code-saturne
package, but I'm stuck with unreproducible fortran builds [1].

[1] 
https://tests.reproducible-builds.org/debian/dbdtxt/unstable/armhf/code-saturne_5.3.1+repack-8.diffoscope.txt.gz

I've narrowed the problem to - at least - one source file: src/base/clptur.f90.

Steps to reproduce:
1- Run a first build code-saturne 5.3.1+repack-8 against unstable
2- In the src/base subdirectory, run this command several times:
gfortran -I../../src -I../../src/alge -I../../src/atmo -I../../src/cfbl 
-I../../src/cogz -I../../src/comb -I../../src/ctwr -I../../src/darc 
-I../../src/elec -I../../src/lagr -I../../src/pprt -I../../src/rayt 
-I../../src/turb -I../../src/user -O -x f95-cpp-input -Wall -pedantic-errors 
-std=f2003 -fdiagnostics-color=auto -g -O2 -fdebug-prefix-map=$(readlink -f 
../..)=. -fstack-protector-strong -fopenmp -c clptur.f90  -fPIC -o 
.libs/clptur.o 2>/dev/null && readelf -a .libs/clptur.o | grep ntlast && ls -l 
.libs/clptur.o

Here is an example of what I obtain after two runs in a row:

$ gfortran -I../../src -I../../src/alge -I../../src/atmo -I../../src/cfbl 
-I../../src/cogz -I../../src/comb -I../../src/ctwr -I../../src/darc 
-I../../src/elec -I../../src/lagr -I../../src/pprt -I../../src/rayt 
-I../../src/turb -I../../src/user -O -x f95-cpp-input -Wall -pedantic-errors 
-std=f2003 -fdiagnostics-color=auto -g -O2 -fdebug-prefix-map=$(readlink -f 
../..)=. -fstack-protector-strong -fopenmp -c clptur.f90  -fPIC -o 
.libs/clptur.o 2>/dev/null && readelf -a .libs/clptur.o | grep ntlast && ls -l 
.libs/clptur.o 
 9:  4 OBJECT  LOCAL  DEFAULT3 ntlast.4720
- -rw-rw-r-- 1 pini pini 182504 Jan 21 09:07 .libs/clptur.o
$ gfortran -I../../src -I../../src/alge -I../../src/atmo -I../../src/cfbl 
-I../../src/cogz -I../../src/comb -I../../src/ctwr -I../../src/darc 
-I../../src/elec -I../../src/lagr -I../../src/pprt -I../../src/rayt 
-I../../src/turb -I../../src/user -O -x f95-cpp-input -Wall -pedantic-errors 
-std=f2003 -fdiagnostics-color=auto -g -O2 -fdebug-prefix-map=$(readlink -f 
../..)=. -fstack-protector-strong -fopenmp -c clptur.f90  -fPIC -o 
.libs/clptur.o 2>/dev/null && readelf -a .libs/clptur.o | grep ntlast && ls -l 
.libs/clptur.o 
 9:  4 OBJECT  LOCAL  DEFAULT3 ntlast.4722
- -rw-rw-r-- 1 pini pini 182536 Jan 21 09:07 .libs/clptur.o

First, the size of the generated object file isn't always the same.
Second, the symbol generated for the 'ntlast' variable varies from
'ntlast.4719' to 'ntlast.4722'.

Any help appreciated.
Thanks in advance,

_g.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAlxF9rcACgkQ7+hsbH/+
z4MQWgf+JKMSRT8sqgV1l1naPxacMoDEt+Cy698QmNUzS1ez7cn+O1KIUFeqkBwe
H+Qr6RX0EnkxC3PYuIC2BU6PVD3uAJVo4NI0x4wtKlhc2r/hXODfJyUykDnxSnHr
V36FA/tYwx/ilQDEhv1Dd0u3yKwlDW2K80xTbFroxJ/CcywO/PwcG4Knq1wVAUsp
tr5WI4i5u/ewEWGvXKkov1nGfLgGxqx4oA3QF116tyCvYPxv92PXY7PL4PzRxJwZ
KlXAPad/9HklQc9eqi5gH8t2w/f1ITghmMTg0ddJVsT2odIn6FZm6zk7pShyUhdk
3uifKCKldTV32EmqKdvUEhQwNXAfsA==
=uMKT
-END PGP SIGNATURE-

Bug#916672: libzvbi-chains.so: undefined symbols: needs -ldl

[Eriberto]

Em seg, 17 de dez de 2018 às 05:06, Paul Wise  escreveu:
>
> Package: libzvbi0
> Version: 0.2.35-15
> Severity: normal
> File: /usr/lib/x86_64-linux-gnu/libzvbi-chains.so.0.0.0
> User: debian...@lists.debian.org
> Usertags: undefined-symbol adequate
>
> libzvbi-chains.so needs to link with -ldl, see the output of adequate,
> symtree and objdump below. I detected this on amd64 but the Debian
> build log scanner also detected dpkg-buildpackage complaining about it
> on most architectures, see the w3m/getbuildlog output below.


Thanks a lot Paul! Your explanation was very useful.

I will fix it now, adding -ldl to DEB_LDFLAGS_MAINT_APPEND.

Cheers,

Eriberto

Bug#920021: RM: nbsphinx -- ROM; python-nbsphynx >= 0.4 broken

[Jerome Benoit]

Package: ftp.debian.org
Severity: normal

Please remove the stray binary package python-nbsphynx 0.4.1+ds-1
as uptream no more support Python 2 from version 0.4,
this package is broken (see #97418).

It need to be removed before I bring back a 0.3 working package
that supports Python 2. See #97418 for details, Thorsten Glaser comment.

Thanks,
Jerome

Bug#920020: javadoc: The code being documented uses modules but the packages defined in … are in the unnamed module

[Thorsten Glaser]

Package: openjdk-11-jdk
Version: 11.0.2+7-1
Severity: grave
Tags: patch
Justification: renders package unusable

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:jar (attach-javadocs) on 
project octopus-rpctunnel: MavenReportException: Error while generating 
Javadoc: 
[ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules 
but the packages defined in https://docs.oracle.com/javase/8/docs/api/ are in 
the unnamed module.

The cause for this is:

https://bugs.openjdk.java.net/browse/JDK-8212233

The fix is (not tested by myself):

http://hg.openjdk.java.net/jdk/jdk/rev/8ce4083fc831
via:
https://bugs.openjdk.java.net/browse/JDK-8217177

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages openjdk-11-jdk depends on:
ii  libc62.28-5
ii  openjdk-11-jdk-headless  11.0.2+7-1
ii  openjdk-11-jre   11.0.2+7-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages openjdk-11-jdk recommends:
pn  libxt-dev  

Versions of packages openjdk-11-jdk suggests:
pn  openjdk-11-demo
pn  openjdk-11-source  
pn  visualvm   

-- no debconf information

Bug#919356: Fw: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear

[MJ Ray]

Missed the bug off the CC for this. Sorry.

Begin forwarded message:

Date: Mon, 21 Jan 2019 13:34:13 +
From: MJ Ray 
To: debian-le...@lists.debian.org
Subject: Re: Bug#919356: dwarves-dfsg: Copyright/licensing is unclear


Domenico Andreoli  skribis:

>   the situation of dwarves-dfsg improved a lot over the weekend, the
> only knot left is now the license of hash.h
> 
> This file is also present in the kernel [0] with an updated copyright
> but still without license.
> 
> I received a private email from somebody in the kernel community who
> already tried to contact Nadia in the past but did not get any reply.
> [...]
> [0]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h
>   

One of the commits to that file is from Nadia. Sorry if I'm being
dense, but where does the doubt that it is under the kernel's licence
arise?

Thanks,
-- 

MJR http://mjr.towers.org.uk/
Member of http://www.software.coop/ (but this email is my personal view
only)



-- 

MJR http://mjr.towers.org.uk/
Member of http://www.software.coop/ (but this email is my personal view
only)



pgpje0cOXw5e8.pgp
Description: OpenPGP digital signature

Bug#918085: Still an issue?

[Francois Marier]

It looks like the experimental version of kmymoney is no longer installable
in sid:

$ LANG=C sudo apt install libkf5newstuffcore5
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libalkimia5-7 libaqbanking-data libaqbanking35 libaqbanking35-plugins 
libaqebics0 libaqhbci24
  libaqofxconnect7 libgwengui-cpp0 libgwengui-qt5-0 libgwenhywfar-data 
libgwenhywfar60 libkchart2
  libkchart2-l10n libkf5holidays-data libkf5holidays5 libkf5webkit5 
libktoblzcheck1v5 libofx7
  libqt5sensors5 libqt5webkit5 libre2-4 libsqlcipher0 libxmlsec1-gcrypt 
libxmlsec1-gnutls
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  kio libkf5attica5 libkf5bookmarks-data libkf5bookmarks5 libkf5completion-data 
libkf5completion5
  libkf5configwidgets-data libkf5configwidgets5 libkf5iconthemes-data 
libkf5iconthemes5
  libkf5jobwidgets-data libkf5jobwidgets5 libkf5kcmutils-data libkf5kcmutils5 
libkf5kiofilewidgets5
  libkf5quickaddons5 libkf5solid5 libkf5solid5-data libkf5textwidgets-data 
libkf5textwidgets5
  libkf5wallet-bin libkf5wallet-data libkf5wallet5 libkf5widgetsaddons-data 
libkf5widgetsaddons5
  libkf5xmlgui-data libkf5xmlgui5 libkwalletbackend5-5 libqt5core5a libqt5dbus5 
libqt5designer5
  libqt5gui5 libqt5multimedia5 libqt5multimedia5-plugins 
libqt5multimediawidgets5 libqt5network5
  libqt5opengl5 libqt5positioning5 libqt5printsupport5 libqt5qml5 libqt5quick5 
libqt5quickcontrols2-5
  libqt5quicktemplates2-5 libqt5quickwidgets5 libqt5script5 libqt5sensors5 
libqt5sql5
  libqt5sql5-sqlite libqt5svg5 libqt5test5 libqt5texttospeech5 
libqt5waylandclient5
  libqt5waylandcompositor5 libqt5webchannel5 libqt5webengine-data 
libqt5webengine5
  libqt5webenginecore5 libqt5webenginewidgets5 libqt5webkit5 libqt5widgets5 
libqt5xml5 python3-pyqt5
  python3-pyqt5.qtwebchannel python3-pyqt5.qtwebengine 
qml-module-qtgraphicaleffects
  qml-module-qtquick-controls qml-module-qtquick-controls2 
qml-module-qtquick-layouts
  qt5-gtk-platformtheme qtwayland5 telegram-desktop
Suggested packages:
  qt5-qmltooling-plugins python3-pyqt5-dbg
Recommended packages:
  libkf5iconthemes-bin qml-module-org-kde-newstuff libkf5xmlgui-bin
The following packages will be REMOVED:
  kmymoney
The following packages will be upgraded:
  kio libkf5attica5 libkf5bookmarks-data libkf5bookmarks5 libkf5completion-data 
libkf5completion5
  libkf5configwidgets-data libkf5configwidgets5 libkf5iconthemes-data 
libkf5iconthemes5
  libkf5jobwidgets-data libkf5jobwidgets5 libkf5kcmutils-data libkf5kcmutils5 
libkf5kiofilewidgets5
  libkf5newstuffcore5 libkf5quickaddons5 libkf5solid5 libkf5solid5-data 
libkf5textwidgets-data
  libkf5textwidgets5 libkf5wallet-bin libkf5wallet-data libkf5wallet5 
libkf5widgetsaddons-data
  libkf5widgetsaddons5 libkf5xmlgui-data libkf5xmlgui5 libkwalletbackend5-5 
libqt5core5a libqt5dbus5
  libqt5designer5 libqt5gui5 libqt5multimedia5 libqt5multimedia5-plugins 
libqt5multimediawidgets5
  libqt5network5 libqt5opengl5 libqt5positioning5 libqt5printsupport5 
libqt5qml5 libqt5quick5
  libqt5quickcontrols2-5 libqt5quicktemplates2-5 libqt5quickwidgets5 
libqt5script5 libqt5sensors5
  libqt5sql5 libqt5sql5-sqlite libqt5svg5 libqt5test5 libqt5texttospeech5 
libqt5waylandclient5
  libqt5waylandcompositor5 libqt5webchannel5 libqt5webengine-data 
libqt5webengine5
  libqt5webenginecore5 libqt5webenginewidgets5 libqt5webkit5 libqt5widgets5 
libqt5xml5 python3-pyqt5
  python3-pyqt5.qtwebchannel python3-pyqt5.qtwebengine 
qml-module-qtgraphicaleffects
  qml-module-qtquick-controls qml-module-qtquick-controls2 
qml-module-qtquick-layouts
  qt5-gtk-platformtheme qtwayland5 telegram-desktop

Bug#911322: [Android-tools-devel] Bug#911322:

[Hans-Christoph Steiner]

Lampa:
> I don't see reason for dependency on android-* crap for fastboot
> package. I want to control my phone over fastboot/adb and i don't need
> android-* crap.
> 
> Android-* should be marked as recommended.

Without the android-* libs, fastboot/adb would not work at all.  If you
want to change that, please send patches upstream.

Bug#919529: CVE-2019-6256

[Salvatore Bonaccorso]

Hi,

On Sun, Jan 20, 2019 at 03:22:31PM +0100, Sebastian Ramacher wrote:
> On 2019-01-19 22:36:05, Salvatore Bonaccorso wrote:
> > Hey!
> > 
> > On Thu, Jan 17, 2019 at 12:00:13AM +0100, Sebastian Ramacher wrote:
> > > Control: found -1 2016.11.28-1
> > > 
> > > On 2019-01-16 23:19:45, Moritz Muehlenhoff wrote:
> > > > Source: liblivemedia
> > > > Severity: grave
> > > > Tags: security
> > > > 
> > > > Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-6256
> > > > 
> > > > Cheers,
> > > > Moritz
> > > 
> > > Not sure if I'm missing something, but the PoC does not seem to work on
> > > buster/sid. On stretch I get segfaults, but only if I abort the PoC. So 
> > > marking
> > > as found in stable and closing for sid.
> > 
> > Not having a poc triggering does not necessarly mean the issue needs
> > to be fixed. Do we know something on the actual fix? Skimming (but
> > only superficial) in the git repository I have not found something
> > obvious, but possible I only missed it.
> 
> http://lists.live555.com/pipermail/live-devel/2018-November/021099.html
> explicitely mentions that the issue was fixed in 2018.11.26.

perfect, thank you!

Salvatore

Bug#920019: dput fails to build on test errors

[Sebastien Bacher]

Package: dput
Version: 1.0.2

hey,

dput currently fails to build on tests error, it seems to be due to the
fact that the test url used is invalid
"https://ipsum.example.org/proin;

$ host ipsum.example.org
Host ipsum.example.org not found: 3(NXDOMAIN)

Cheers,

Bug#920018: Memory Leak in journald? Failed to write entry (23 items, 500 bytes), ignoring: Cannot allocate memory

[Sven Hartge]

On Mon, 21 Jan 2019 17:17:23 +0100 Sven Hartge  wrote:

> Since systemd_240-4 journald seems to either leak memory or something
> strange is going on with my system.

I believe this is https://github.com/systemd/systemd/issues/11502
At least the problem (journald eating memory) and the workaround
(downgrade to 240-3) look very alike to the things I've been seeing.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#916798: Acknowledgement (firmware-iwlwifi 20180825+dfsg-1 breaks bluetooth on Intel 8265)

[Vroomfondel]

I've just upgraded to the latest firmware-iwlwifi_20190114-1_all.deb and I can 
confirm that the problem with bluetooth on the 8265 is now fixed so this bug 
report can be closed from my point of view.


Thanks.

P.S. Incidentally, the e91976c0 firmware for the wifi I was using previously 
also fixed all of the problems I was having with my wifi connection in earlier 
versions - even to the extent I no longer needed to specify any special options 
(mostly 11n_disable=1 and bt_coex_active=0 to attain a semi-reliable 
connection). I'll commence testing with the newer 9f0a2d68 version included in 
this release and make good on my threat to open a separate bug report if I run 
into any further problems.

Bug#920018: Memory Leak in journald? Failed to write entry (23 items, 500 bytes), ignoring: Cannot allocate memory

[Sven Hartge]

Package: systemd
Version: 240-4
Severity: important

Hi!

Since systemd_240-4 journald seems to either leak memory or something
strange is going on with my system.

Soon after boot or journald restart, I get messages like this in my
kernel log:

[...]
[31317.206261] systemd-journald[341]: Failed to write entry (29 items, 682 
bytes), ignoring: Cannot allocate memory
[31330.715806] systemd-journald[341]: Failed to write entry (21 items, 547 
bytes), ignoring: Cannot allocate memory
[31330.756475] systemd-journald[341]: Failed to write entry (21 items, 549 
bytes), ignoring: Cannot allocate memory
[31330.756946] systemd-journald[341]: Failed to write entry (21 items, 633 
bytes), ignoring: Cannot allocate memory
[31330.757454] systemd-journald[341]: Failed to write entry (21 items, 629 
bytes), ignoring: Cannot allocate memory
[31331.070486] systemd-journald[341]: Failed to write entry (22 items, 577 
bytes), ignoring: Cannot allocate memory
[31331.070625] systemd-journald[341]: Failed to write entry (22 items, 564 
bytes), ignoring: Cannot allocate memory
[31331.103742] systemd-journald[341]: Failed to write entry (22 items, 581 
bytes), ignoring: Cannot allocate memory
[31331.103878] systemd-journald[341]: Failed to write entry (22 items, 548 
bytes), ignoring: Cannot allocate memory
[31331.104589] systemd-journald[341]: Failed to write entry (22 items, 562 
bytes), ignoring: Cannot allocate memory
[31334.787786] systemd-journald[341]: Failed to write entry (24 items, 611 
bytes), ignoring: Cannot allocate memory
[31335.992491] systemd-journald[341]: Failed to write entry (23 items, 500 
bytes), ignoring: Cannot allocate memory
[...]

Also the committed memory size as recored by munin (see attached image)
spikes quickly. You can clearly spot in the graph, when I upgraded to
systemd_240-4. You can also see the times where I manually restarted
journald.

(Yes, this system is a bit small for all the services running on it,
hence the swap usage.)

I now have downgraded to systemd_240-3 which resolves this issue for me.

Other systems of mine show the same, but because they have more RAM, the
problem is not as visible (yet).

Grüße,
Sven.

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.2-3
ii  libaudit11:2.8.4-2
ii  libblkid12.33.1-0.1
ii  libc62.28-5
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.6-1
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.5-2
ii  libgpg-error01.33-3
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-3
ii  libkmod2 25-2
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.33.1-0.1
ii  libpam0g 1.1.8-4
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  240-4
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  240-4

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 240-4

-- Configuration Files:
/etc/systemd/journald.conf changed:
[Journal]
Storage=persistent
ForwardToConsole=yes
TTYPath=/dev/tty12

/etc/systemd/logind.conf changed:
[Login]
KillUserProcesses=no

/etc/systemd/system.conf changed:
[Manager]
RuntimeWatchdogSec=60


-- debconf-show failed

Bug#915689: Fwd: Re: Bug#919893: package shouldn't exist

[Michael Stone]

On Mon, Jan 21, 2019 at 04:47:51PM +0100, Diederik de Haas wrote:

On maandag 21 januari 2019 13:34:19 CET Michael Stone wrote:

On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote:
>On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
>> I’m very much against just saying this package
>> “should not exist”
>
>I'm inclined to agree with this as the source (+ features/parameters) for
>this package is substantially different from rng-tools/rng-tools5.

Yes, but most of those features are obsolescent at best. I'm not clear
on what functionality is actually being used. (I'm hesitant to remove
it exactly because I'm not clear on that, but I tend to think that it's
functionally obsolete.)


I'm not knowledgeable enough to weigh in on that and/or what is best towards
the future, so I'll leave that up to you.


>coordination/progress. I'm thinking of updating
>https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we
>use(d) the old rng-tools to get much better/more entropy on the Raspberry
>Pi.

In what way?


Entropy generation for the creation of SSH keys as the netinstaller is mostly
used in headless situations.
https://github.com/debian-pi/raspbian-ua-netinst/issues/42


That functionality doesn't require the old package; will work fine with 
rng-tools5. 

Bug#919802: Fwd: Re: Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Hi Emmanuel, Niels,

Any input on this topic?

Thanks in advance,

_g.

 Message transféré 
Sujet : Re: Bug#919802: libjstun-java: FTBFS (The code being documented
uses packages in the unnamed module)
Date : Mon, 21 Jan 2019 16:58:08 +0100
De : Gilles Filippini 
Pour : 919...@bugs.debian.org, Ying-Chun Liu (PaulLiu)
, Santiago Vila 

Hi,

On Sun, 20 Jan 2019 13:28:57 +0800 "Ying-Chun Liu (PaulLiu)"
 wrote:
> Santiago Vila 於 2019/1/20 上午1:35 寫道:
> > Package: src:libjstun-java
> > Version: 0.7.3+dfsg-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > Dear maintainer:
> > 
> > I tried to build this package in buster but it failed:
> > 
> > 
> > [...]
> >  debian/rules build-indep
> > dh build-indep --with javahelper
> >dh_update_autotools_config -i
> >jh_linkjars -i
> >jh_build -i
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javac -g -cp 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.libjstun-java -source 1.7 -target 1.7 -encoding 
> > ISO8859-1
> > warning: [options] bootstrap class path not set in conjunction with -source 
> > 7
> > Note: src/de/javawi/jstun/test/demo/ice/ICENegociator.java uses unchecked 
> > or unsafe operations.
> > Note: Recompile with -Xlint:unchecked for details.
> > 1 warning
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
> > /usr/share/doc/default-jdk-doc/api -link 
> > /usr/share/doc/default-jre-headless/api -classpath 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
> > -source 1.7
> > Creating destination directory: "debian/_jh_build.javadoc/api/"
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
> > in named modules.
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in 
> > /usr/share/doc/default-jre-headless/api/ are in named modules.
> > 2 errors
> > make: *** [debian/rules:11: build-indep] Error 123
> > dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> > status 2
> > 
> > 
> > (The above is just how the builds ends and not necessarily the most 
> > relevant part)
> > 
> > The build was made in my autobuilder with "dpkg-buildpackage -A"
> > and it also fails here:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libjstun-java.html
> > 
> > where you can get a full build log if you need it.
> > 
> > If this is really a bug in one of the build-depends, please use reassign 
> > and affects,
> > so that this is still visible in the BTS web page for this package.
> > 
> > Thanks.
> > 
> 
> Hi Santiago,
> 
> It seems to me that this line causes the problem.
> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0
> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link
> /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api -classpath
> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp
> -source 1.7
> 
> But if remove "-link /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api", then it will pass.
> 
> I'm wondering if javahelper needs to call javadoc in different way.

I've got the very same result for #919803 affecting src:mac-widgets.

Thanks,

_g.





signature.asc
Description: OpenPGP digital signature

Bug#919957: Please check for binaries depending on unused libraries

[Matthias Klose]

On 21.01.19 16:37, Chris Lamb wrote:
> [Adding d...@debian.org to CC]
> 
> Josh Triplett wrote:
> 
>>> This does not sound like a good idea to me, since fixing such warnings 
>>> would result in many ugly (and sometimes not upstreamable) hacks.
>>
>> In most cases, fixing such warnings would involve either adding
>> --as-needed or just removing a library from linking for a given program.
> 
> I believe Adrian's wider point was more that there would be no need to
> add --as-needed if it were made the default in Debian.
> 
> I believe doko (added to CC) was working on this (eg. #916831); is there
> a status, ETA, tracking bug, etc.?

no. but I think I'll enable that by default in GCC 9 for bullseye.

Bug#919652: Acknowledgement (ath10k - QCA6174 - Surface Go - missing board data - fix .bin included extracted form official .msi)

[wayne wayne]

Output of "sudo journalctl | grep ath10k" after getting version 20190114-1 via 
packetmanager into Buster.

Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: pci irq msi 
oper_irq_mode 2 irq_mode 0 reset_mode 0
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: firmware: 
failed to load ath10k/pre-cal-pci-:01:00.0.bin (-2)
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: firmware: 
failed to load ath10k/cal-pci-:01:00.0.bin (-2)
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: firmware: 
direct-loading firmware ath10k/QCA6174/hw3.0/firmware-6.bin
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: qca6174 
hw3.2 target 0x0503 chip_id 0x00340aff sub 168c:3370
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: kconfig 
debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: firmware ver 
RM.4.4.1.c2-00057-QCARMSWP-1 api 6 features 
wowlan,ignore-otp,no-4addr-pad,raw-mode crc32 e061250a
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: firmware: 
direct-loading firmware ath10k/QCA6174/hw3.0/board-2.bin
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: failed to 
fetch board data for 
bus=pci,vendor=168c,device=003e,subsystem-vendor=168c,subsystem-device=3370 
from ath10k/QCA6174/hw3.0/board-2.bin
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: firmware: 
direct-loading firmware ath10k/QCA6174/hw3.0/board.bin
Jan 21 16:59:19 debian-surface-go kernel: ath10k_pci :01:00.0: board_file 
api 1 bmi_id N/A crc32 ed5f849a
Jan 21 16:59:20 debian-surface-go kernel: ath10k_pci :01:00.0: Unknown 
eventid: 118809
Jan 21 16:59:20 debian-surface-go kernel: ath10k_pci :01:00.0: htt-ver 3.56 
wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 hwcrypto 1
Jan 21 16:59:20 debian-surface-go NetworkManager[466]:   
[1548086360.8720] rfkill1: found Wi
...

Version 12.0.0.722 of eeprom_ar6320_3p0_TX8_clpc.bin fixed the issue again.

best regards

Bug#914464: Any update?

[Filip Pytloun]

Hello,

any update with this package?
I would need it to build newer vdirsyncer.

Thank you,
Filip


signature.asc
Description: PGP signature

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[David Bremner]

Ian Jackson  writes:

> Package: tech-ctte
>
> In #919622 and the associated debian-devel thread,
>  "Conflict over /usr/bin/dune"
>   https://lists.debian.org/debian-devel/2019/01/msg00227.html
> the file conflict over /usr/bin/dune was discussed.
>
> The rough consensus of the debian-devel thread was that /usr/bin/dune
> ought definitely not to be taken by the ocaml build system, and that
> the best claim on it was the C++ library which already provides a
> number of /usr/bin/dune?* binaries.
>
> Instead, the maintainers of the ocaml package reassigned the bug
> against their `dune' package to the whitedune package, which
> previously provided /usr/bin/dune as a compat symlink.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622
>
> They used the phrase
>   "As discussed on debian-devel"
> which is very misleading because it makes it sounds like there was a
> consensus for this course of action, whereas the opposite is true.
>
> Apparently as a result of this there was an NMU of `whitedune' to drop
> the symlink /usr/bin/dune.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#58
>

Per article 6.6 of the constitution (which I know you're aware of ;)),
have efforts to resolve this via consensus really failed? Except under
extraordinary circumstances, I would expect whitedune maintainers to NAK
the NMU if they disagreed with this resolution. I don't think the
wording of the NMU changelog alone is enough to involve the TC, nor do I
think the social appropriateness of this NMU is really within our
purview.

d

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Hi,

On Sun, 20 Jan 2019 13:28:57 +0800 "Ying-Chun Liu (PaulLiu)"
 wrote:
> Santiago Vila 於 2019/1/20 上午1:35 寫道:
> > Package: src:libjstun-java
> > Version: 0.7.3+dfsg-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > Dear maintainer:
> > 
> > I tried to build this package in buster but it failed:
> > 
> > 
> > [...]
> >  debian/rules build-indep
> > dh build-indep --with javahelper
> >dh_update_autotools_config -i
> >jh_linkjars -i
> >jh_build -i
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javac -g -cp 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.libjstun-java -source 1.7 -target 1.7 -encoding 
> > ISO8859-1
> > warning: [options] bootstrap class path not set in conjunction with -source 
> > 7
> > Note: src/de/javawi/jstun/test/demo/ice/ICENegociator.java uses unchecked 
> > or unsafe operations.
> > Note: Recompile with -Xlint:unchecked for details.
> > 1 warning
> > find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
> > /usr/share/doc/default-jdk-doc/api -link 
> > /usr/share/doc/default-jre-headless/api -classpath 
> > /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> >  -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
> > -source 1.7
> > Creating destination directory: "debian/_jh_build.javadoc/api/"
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
> > in named modules.
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in 
> > /usr/share/doc/default-jre-headless/api/ are in named modules.
> > 2 errors
> > make: *** [debian/rules:11: build-indep] Error 123
> > dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> > status 2
> > 
> > 
> > (The above is just how the builds ends and not necessarily the most 
> > relevant part)
> > 
> > The build was made in my autobuilder with "dpkg-buildpackage -A"
> > and it also fails here:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libjstun-java.html
> > 
> > where you can get a full build log if you need it.
> > 
> > If this is really a bug in one of the build-depends, please use reassign 
> > and affects,
> > so that this is still visible in the BTS web page for this package.
> > 
> > Thanks.
> > 
> 
> Hi Santiago,
> 
> It seems to me that this line causes the problem.
> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0
> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link
> /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api -classpath
> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
> -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp
> -source 1.7
> 
> But if remove "-link /usr/share/doc/default-jdk-doc/api -link
> /usr/share/doc/default-jre-headless/api", then it will pass.
> 
> I'm wondering if javahelper needs to call javadoc in different way.

I've got the very same result for #919803 affecting src:mac-widgets.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#920017: ruby2.5: FTBFS on x32: Unsupported RVALUE_SIZE=24, update test_memsize

[Thorsten Glaser]

Source: ruby2.5
Version: 2.5.3-3
Severity: important
Justification: fails to build from source, on d-ports arch

Please see the full log:
https://buildd.debian.org/status/fetch.php?pkg=ruby2.5=x32=2.5.3-3=1545671782=0

[…]
[17335/17367] YAMLStoreTest#test_yaml_store_files_are_accessed_as_binary_files 
= 0.31 s  

 
  1) Failure:   
 
TestTime#test_memsize [/<>/test/ruby/test_time.rb:1137]:   
 
Unsupported RVALUE_SIZE=24, update test_memsize 
 

 
Finished tests in 412.368898s, 42.0376 tests/s, 5493.8212 assertions/s. 
 
17335 tests, 2265481 assertions, 1 failures, 0 errors, 59 skips 
 

 
ruby -v: ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-linux-gnux32]   
 
make[2]: *** [uncommon.mk:698: yes-test-almost] Error 1 
 



Please note that I’ve uploaded a “nocheck” build of this version because
it’s urgently needed for Build-Depends of required packages. If you don’t
fix this, the next upload will fail likewisely.

Bug#918106: logrotate: segfaults in rotateLogSet

[secucatcher]

ok, so here we go
but i don't see much more withour bt full, do i understand correctly ?

the command:

coredumpctl gdb 754
display/i $pc
info reg
disassemble $pc-0x50,$pc+0x50

thanks


coredumpctl gdb 754
quit
   PID: 754 (logrotate)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Sun 2019-01-20 11:24:28 CET (1 day 5h ago)
  Command Line: /usr/sbin/logrotate /etc/logrotate.conf
Executable: /usr/sbin/logrotate
 Control Group: /system.slice/cron.service
  Unit: cron.service
 Slice: system.slice
   Boot ID: a57707f859fe4471ae781dd31d2b75f7
Machine ID: 230c8c9b6d3840749a45bcf6e73d8a82
  Hostname: syslog
   Storage: 
/var/lib/systemd/coredump/core.logrotate.0.a57707f859fe4471ae781dd31d2b75f7.754.1547979868.lz4
   Message: Process 754 (logrotate) of user 0 dumped core.

Stack trace of thread 754:
#0  0x55e3239db88a rotateLogSet (logrotate)
#1  0x55e3239d298d main (logrotate)
#2  0x7faf357fb2e1 __libc_start_main (libc.so.6)
#3  0x55e3239d312a _start (logrotate)



GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/logrotate...Reading symbols from 
/usr/lib/debug/.build-id/4b/a3d893d18935ef292da47c51a97214648caf82.debug...done.
done.
[New LWP 754]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/logrotate /etc/logrotate.conf'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x55e3239db88a in rotateLogSet (log=0x55e323ec4ca0, force=0) at 
logrotate.c:1880
1880logrotate.c: Aucun fichier ou dossier de ce type.


display/i $pc

1: x/i $pc
=> 0x55e3239db88a :callq  0x55e3239d6ec0 


info reg

 info reg
rax0x0  0
rbx0x55e323ec4ca0   94434048625824
rcx0x0  0
rdx0x55e323ec4650   94434048624208
rsi0x55e3239dd734   94434043483956
rdi0x2  2
rbp0x7fff984ad610   0x7fff984ad610
rsp0x7fff97c94a30   0x7fff97c94a30
r8 0x55e358a20040   94434932949056
r9 0x0  0
r100x0  0
r110x246582
r120x55e3239d3100   94434043441408
r130x0  0
r140x0  0
r150x55e323ec4ca0   94434048625824
rip0x55e3239db88a   0x55e3239db88a 
eflags 0x10246  [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0  0
es 0x0  0
fs 0x0  0
gs 0x0  0


disassemble $pc-0x50,$pc+0x50
Dump of assembler code from 0x55e3239db83a to 0x55e3239db8da:
   0x55e3239db83a:  test   %al,(%rax)
   0x55e3239db83c:  add%al,(%rax)
   0x55e3239db83e:  add%al,(%rax)
   0x55e3239db840 : push   %rbp
   0x55e3239db841 : mov%rsp,%rbp
   0x55e3239db844 : push   %r15
   0x55e3239db846 : push   %r14
   0x55e3239db848 : push   %r13
   0x55e3239db84a :push   %r12
   0x55e3239db84c :mov%esi,%r13d
   0x55e3239db84f :push   %rbx
   0x55e3239db850 :lea0x1edd(%rip),%rsi
# 0x55e3239dd734
   0x55e3239db857 :mov%rdi,%r15
   0x55e3239db85a :sub$0x58,%rsp
   0x55e3239db85e :mov(%rdi),%rdx
   0x55e3239db861 :mov%fs:0x28,%rax
   0x55e3239db86a :mov%rax,-0x38(%rbp)
   0x55e3239db86e :xor%eax,%eax
   0x55e3239db870 :movslq 0x10(%rdi),%rax
   0x55e3239db874 :mov$0x2,%edi
   0x55e3239db879 :lea0x12(,%rax,4),%rax
   0x55e3239db881 :and$0xfff0,%rax
   0x55e3239db885 :sub%rax,%rsp
   0x55e3239db888 :xor%eax,%eax
=> 0x55e3239db88a :callq  0x55e3239d6ec0 
   0x55e3239db88f :test   %r13d,%r13d
   0x55e3239db892 :mov%rsp,%r12
   0x55e3239db895 :jne0x55e3239dbb70 

   0x55e3239db89b :cmpl   $0x5,0x20(%r15)
   0x55e3239db8a0 :ja 0x55e3239db8e0 

   

Bug#919999: Fails to build from source in current stretch

[Adrian Bunk]

Control: severity -1 serious

On Mon, Jan 21, 2019 at 02:02:44PM +0100, Moritz Muehlenhoff wrote:
> Package: ruby2.3
> Version: 2.3.3-1+deb9u4
> Severity: important
> 
> Hi Ruby maintainers,
> I tried to rebuild ruby2.3 2.3.3-1+deb9u4 and it fails with the following 
> four test
> failures:
> 
> 
> 
>   1) Failure:
> IMAPTest#test_imaps_with_ca_file 
> [/build/ruby2.3-2.3.3/.ext/common/openssl/ssl.rb:404]:
> Exception raised:
> <# sslv3 alert certificate expired>>.
> 
>   2) Failure:
> IMAPTest#test_starttls [/build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:21]:
> exceptions on 1 threads:
> # dead>:
> /build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:589:in `accept': SSL_accept 
> returned=1 errno=0 state=unknown state: sslv3 alert certificate expired 
> (OpenSSL::SSL::SSLError)
> from /build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:589:in `block in 
> starttls_test'
>...
> Failure 1 and 2 are probably just an expired cert.

These look like #919516 in ruby2.5.

> We don't currently have any open/pending ruby2.3 security issues, but it 
> would be nice
> if those could be fixed in either the stretch branch in git or for the next 
> point release,
> so that this doesn't block a future sec update.

I'm marking it as RC, like any other FTBFS in stable.

This makes it visible for people looking through RC bugs in stable.

> Cheers,
> Moritz

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#920016: ITP: gst-plugins-rtp -- GStreamer libraries for handling RTP/RTCP streams on the network

[Marc Leeman]

Package: wnpp
Severity: wishlist
Owner: Marc Leeman 

* Package name: gst-plugins-rtp
  Version : 1.14.4.1
  Upstream Author : Marc Leeman 
* URL : https://github.com/mleeman/gst-plugins-rtp
* License : LGPL
  Programming Lang: C
  Description : GStreamer libraries for handling RTP/RTCP streams on the 
network

 GStreamer is a streaming media framework, based on graphs of filters
 which operate on media data.  Applications using this library can do
 anything from real-time sound processing to playing videos, and just
 about anything else media-related.  Its plugin-based architecture means
 that new data types or processing capabilities can be added simply by
 installing new plug-ins.
 .
 GStreamer RTP plugins provide elements that handle RTP streaming to
 and from the network and provide bindings to the rtp:// URI interface.
This message is subject to the following terms and conditions: MAIL 
DISCLAIMER

Bug#920015: Serious bug in armadillo

[Kumar Appaiah]

Package: armadillo
Version: 1:9.200.6+dfsg-1
Tags: patch

Per the author's report below.

Kumar
-- 
Kumar Appaiah
--- Begin Message ---
Hi Kumar,

I've discovered a serious bug in Armadillo 9.200.6, where the trace()
function can lead to incorrect results when applied to compound
expressions with complex matrices.

Attached is a small patch for Armadillo 9.200.6 which fixes the bug.
The patch changes only 1 line and does not introduce any new
functionality.  It is a pure bug fix patch.

Could you apply this patch to the Debian armadillo package ?  It would
be good to have this before upcoming freeze.

An alternative solution is to upgrade the Debian armadillo package to
version 9.200.7, which also contains the fix.

With regards,
Conrad


On Tue, 11 Dec 2018 at 15:39, Kumar Appaiah  wrote:
>
> Dear Conrad,
>
> On Tue, Dec 11, 2018 at 02:15:38PM +1000, Conrad Sand wrote:
> > Hi Kumar,
> >
> > I've released Armadillo 9.200, which contains bug fixes,
> > new functions, improvements and many speedups.
> >
> > I recommend upgrading the corresponding Debian and Ubuntu packages.
> >
> > http://sourceforge.net/projects/arma/files/armadillo-9.200.6.tar.xz
> >
> [snip]
> >
> > With regards,
> > Conrad
>
>
> Done. Thanks for contributing to Debian!
>
> Kumar
> --
> Kumar Appaiah
diff -r -u armadillo-9.200.6-a/include/armadillo_bits/fn_trace.hpp armadillo-9.200.6-b/include/armadillo_bits/fn_trace.hpp
--- armadillo-9.200.6-a/include/armadillo_bits/fn_trace.hpp	2016-06-17 02:19:16.0 +1000
+++ armadillo-9.200.6-b/include/armadillo_bits/fn_trace.hpp	2016-06-17 02:19:16.0 +1000
@@ -82,7 +82,7 @@
 template
 arma_warn_unused
 inline
-typename T1::elem_type
+typename enable_if2< is_cx::no, typename T1::elem_type>::result
 trace(const Glue& X)
   {
   arma_extra_debug_sigprint();
--- End Message ---

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[Stéphane Glondu]

Le 20/01/2019 à 23:14, Ian Jackson a écrit :
> In #919622 and the associated debian-devel thread,
>  "Conflict over /usr/bin/dune"
>   https://lists.debian.org/debian-devel/2019/01/msg00227.html
> the file conflict over /usr/bin/dune was discussed.
> 
> The rough consensus of the debian-devel thread was that /usr/bin/dune
> ought definitely not to be taken by the ocaml build system, and that
> the best claim on it was the C++ library which already provides a
> number of /usr/bin/dune?* binaries.

I do not agree there was such concensus.

You gave your opinion which seemed off-topic to me, Andy and Andreas
remotely agreed with you, Philipp had the same point of view as me.
Maintainers of whitedune did not object.

There is no conflict with the C++ library, I wonder why this was put on
the table.

> Instead, the maintainers of the ocaml package reassigned the bug
> against their `dune' package to the whitedune package, which
> previously provided /usr/bin/dune as a compat symlink.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622
> 
> They used the phrase
>   "As discussed on debian-devel"
> which is very misleading because it makes it sounds like there was a
> consensus for this course of action, whereas the opposite is true.

Sorry but from my point of view, I proposed something and there was no
(relevant) objection. I thought you were giving your opinion in passing,
and didn't understand you would be so vocal about it.

> Apparently as a result of this there was an NMU of `whitedune' to drop
> the symlink /usr/bin/dune.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#58
> 
> The maintainers of the ocaml `dune' have now uploaded `dune' (the
> ocaml package) with /usr/bin/dune and Breaks+Replaces to claim the
> file.
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919622#99

You seem to imply that transgressions have been made... but as far as I
can tell, procedures were followed and the relevant people (should) have
been notified.

> Meanwhile there seems to have been no contact with the maintainers of
> the C++ library which is the only hit on Wikipedia for
>   https://en.wikipedia.org/wiki/Dune_(software)
> (Amazingly, this is still true at the time of writing even though
> I referred to this fact in the debian-devel thread.)

I still fail to see how this is relevant.

> Note that this ocaml tool `dune' was previously known as `jbuilder'.
> It has nothing to do with Java AIUI.  No-one has suggested a plausible
> charitable explanation for why the ocaml upstream made such
> egregiously bad naming mistakes twice in succession.
> 
> Additionally the binary package name `dune' for the ocaml tool is bad,
> too.

Actually, I am not fond of the `dune' name either, but I think it's not
my job to judge and rename it. And I would feel ridiculous asking
upstream for a change (I am already ashamed of this situation).

> Please would the Technical Committee:
> 
>  * Declare that no-one is allowed the name /usr/bin/dune other than
>the C++ library dune-common or its friends.
> 
>  * Declare that no-one is allowed the binary package name
>/usr/bin/dune other than the C++ library dune-common
>or its friends.
> 
>  * Declare that the ocaml build system should choose a new source
>package name and use it henceforth.
> 
> I am about to file an RC bug against the `dune' package, blocked by
> this one.

The tone of your mail looks like harassment to me.


Cheers,

-- 
Stéphane

Bug#919957: Please check for binaries depending on unused libraries

[Adrian Bunk]

[ Josh: The BTS does not Cc submitter or commenters, so I didn't get 
your email. ]

On Mon, Jan 21, 2019 at 03:37:02PM +, Chris Lamb wrote:
> [Adding d...@debian.org to CC]
> 
> Josh Triplett wrote:
> 
> > > This does not sound like a good idea to me, since fixing such warnings 
> > > would result in many ugly (and sometimes not upstreamable) hacks.
> > 
> > In most cases, fixing such warnings would involve either adding
> > --as-needed or just removing a library from linking for a given program.
> 
> I believe Adrian's wider point was more that there would be no need to
> add --as-needed if it were made the default in Debian.

Correct, manually adding --as-needed on a per-package basis would be 
more work for less benefits.

> I believe doko (added to CC) was working on this (eg. #916831); is there
> a status, ETA, tracking bug, etc.?

These are FTBFS in Ubuntu, which switched to --as-needed
as default 8 years ago.

> Regards,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#920012: fwupd breaks xbox360 controller support

[Mario.Limonciello]

Moving to a newer release is problematic because newer releases need
libxmlb which isn't in Debian and doesn't yet have an ITP or team willing to 
adopt it yet even.

This commit has been backported to 1_1_X branch so when a 1.1.5 release is 
released it will be included.
Alternatively this commit can be cherry picked.
https://github.com/hughsie/fwupd/commit/76bdc8c3487f687009a51359d32a27a2a560d319

> -Original Message-
> From: Phil Armstrong 
> Sent: Monday, January 21, 2019 9:03 AM
> To: Debian Bug Tracking System
> Subject: Bug#920012: fwupd breaks xbox360 controller support
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.1.4-1
> Severity: normal
> 
> Dear Maintainer,
> 
> As outlined in https://github.com/hughsie/fwupd/pull/836 fwupd as
> currently in Debian testing breaks xbox 360 controller support.
> 
> Can we pull a more recent version of fwupd into buster?
> 
> cheers, Phil
> 
> -- System Information:
> Debian Release: buster/sid
>    APT prefers testing
>    APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libappstream-glib8 0.7.14-1
> ii  libarchive13   3.3.3-3
> ii  libc6  2.28-5
> ii  libefiboot1    37-1
> ii  libefivar1 37-1
> ii  libelf1    0.175-2
> ii  libfwupd2  1.1.4-1
> ii  libgcab-1.0-0  1.2-2
> ii  libglib2.0-0   2.58.2-3
> ii  libgnutls30    3.6.5-2
> ii  libgpg-error0  1.33-3
> ii  libgpgme11 1.12.0-4
> ii  libgudev-1.0-0 232-2
> ii  libgusb2   0.3.0-1
> ii  libjson-glib-1.0-0 1.4.4-2
> ii  libpolkit-gobject-1-0  0.105-25
> ii  libsmbios-c2   2.4.1-1
> ii  libsoup2.4-1   2.64.2-2
> ii  libsqlite3-0   3.26.0+fossilbc891ac6b-1
> ii  libuuid1   2.33.1-0.1
> 
> Versions of packages fwupd recommends:
> ii  bolt   0.7-2
> ii  fwupd-amd64-signed [fwupd-signed]  1.1.4+1
> ii  python3    3.7.1-3
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#920014: efitools: please consider packaging latest upstream version 1.9.2

[Luca Boccassi]

Source: efitools
Version: 1.8.1-1
Severity: wishlist
X-Debbugs-CC: debian-...@lists.debian.org

Dear Maintainer,

Please kindly consider updating efitools to the latest upstream version
before Buster ships. There have been a couple of important bug fixes
since last month that would be great to have in Buster.

For example, it fixes problems with signing variables for runtime
updates of KEK/DB/DBX, and with getting the hash of the kernel image in
some cases.

The latest upstream version is 1.9.2:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/

Thanks!

-- 
Kind regards,
Luca Boccassi

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

Bug#920013: sbsigntool: please consider packaging latest upstream version 0.9.2

[Luca Boccassi]

Source: sbsigntool
Version: 0.6-3.2
Severity: wishlist
X-Debbugs-CC: debian-...@lists.debian.org

Dear Maintainer,

Please kindly consider updating sbsigntool to the latest upstream
version before Buster ships. There have been a number of important
fixes and additions that would be good to have.

For example, the old version has sometimes issues parsing the kernel
signature. Also, the new version adds a convenient sbverify --list that
simply lists all signatures and is useful for a quick (and non
cryptographically secure!) check. Also, it fixes problems with signing
variables for runtime updates of KEK/DB/DBX.

The latest upstream version is 0.9.2:

https://git.kernel.org/pub/scm/linux/kernel/git/jejb/sbsigntools.git/

Thanks!

-- 
Kind regards,
Luca Boccassi

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

Bug#919977: security-tracker: https://security-tracker.debian.org/tracker/data/json returns stale data

[Julien Cristau]

+debian-admin

On Mon, Jan 21, 2019 at 02:26:16PM +0100, Julien Cristau wrote:
> On Mon, Jan 21, 2019 at 09:27:19AM +0100, Philipp Hahn wrote:
> > Package: security-tracker
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > the JSON stream of the Debian Security Bug Tracker seems to report stale
> > data since the beginning of January 2019:
> > 
> > $ curl -I https://security-tracker.debian.org/tracker/data/json
> > HTTP/2 200
> > date: Mon, 21 Jan 2019 08:10:06 GMT
> > ...
> > content-length: 19836218
> > last-modified: Wed, 02 Jan 2019 19:49:17 GMT
> > expires: Wed, 02 Jan 2019 20:57:34 GMT
> > 
> > This breaks our process to monitor the Debian Security updates by
> > processing the DSAs in a machine-readable format.
> > 
> Looks like at least one CDN node was returning stale data.  I purged
> /tracker/data/json and things are looking ok now.  Thanks for the
> report.
> 
For the record, in case this comes back: I wasn't able to reproduce, but
both Philipp and Ansgar were getting stale data with a "x-cache:
UPDATING" header, from 23.111.9.35.  For me from the same ip the data
was recent and "x-cache: HIT".

Cheers,
Julien

Bug#919849: [Pkg-salt-team] Bug#919849: salt-doc: broken symlinks: /usr/share/doc/salt/html/_static/*/bootstrap* -> ../../../../../twitter-bootstrap/files/*/bootstrap*

[Benjamin Drung]

Am Montag, den 21.01.2019, 16:34 +0100 schrieb Benjamin Drung:
> Am Sonntag, den 20.01.2019, 06:07 +0100 schrieb Andreas Beckmann:
> > Package: salt-doc
> > Version: 2018.3.3+dfsg1-2
> > Severity: normal
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > 
> > Hi,
> > 
> > during a test with piuparts I noticed your package ships (or
> > creates)
> > a broken symlink.
> > 
> > From the attached log (scroll to the bottom...):
> > 
> > 0m29.8s ERROR: FAIL: Broken symlinks:
> >   /usr/share/doc/salt/html/_static/js/vendor/bootstrap.min.js ->
> > ../../../../../../twitter-bootstrap/files/js/bootstrap.min.js
> > (salt-
> > doc)
> >   /usr/share/doc/salt/html/_static/js/vendor/bootstrap.js ->
> > ../../../../../../twitter-bootstrap/files/js/bootstrap.js (salt-
> > doc)
> >   /usr/share/doc/salt/html/_static/css/bootstrap.min.css ->
> > ../../../../../twitter-bootstrap/files/css/bootstrap.min.css (salt-
> > doc)
> >   /usr/share/doc/salt/html/_static/css/bootstrap-responsive.min.css
> > -> ../../../../../twitter-bootstrap/files/css/bootstrap-
> > responsive.min.css (salt-doc)
> > 
> > 
> > Is salt-doc missing a Depends/Recommends/Suggests: libjs-twitter-
> > bootstrap ?
> 
> salt-doc depends on libjs-bootstrap to provide these files. Sadly the
> path has changed between the version in stable and in unstable. I
> will fix the symlinks with the next upload.

I saw it wrong. The path in stable and unstable are the same. I
probably overlooked the changed path between src:twitter-bootstrap and
src:twitter-bootstrap3.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Bill Brelsford]

On Mon Jan 21 2019 at 08:36 AM +0100, Trek wrote:
> @Bill Brelsford: is the problem gone with the 240-4 version? if not,
> can you test udev with these patches applied? thanks!

Yes, 240-4 fixed the problem.  Thanks Trek, Michael and others who
helped resolve it!

Regards..  Bill

Bug#918106: logrotate: segfaults in rotateLogSet

[Bernhard Übelacker]

Control: retitle 918106 logrotate: segfaults in rotateLogSet


Hello Marc,
I am sorry, but my advice to use 'bt full' makes
following commands to show the state of frame #1.

Therefore can you repeat the "coredumpctl gdb 754"
without the "bt full"?

Kind regards,
Bernhard

Bug#919957: Please check for binaries depending on unused libraries

[Chris Lamb]

[Adding d...@debian.org to CC]

Josh Triplett wrote:

> > This does not sound like a good idea to me, since fixing such warnings 
> > would result in many ugly (and sometimes not upstreamable) hacks.
> 
> In most cases, fixing such warnings would involve either adding
> --as-needed or just removing a library from linking for a given program.

I believe Adrian's wider point was more that there would be no need to
add --as-needed if it were made the default in Debian.

I believe doko (added to CC) was working on this (eg. #916831); is there
a status, ETA, tracking bug, etc.?


Regards,

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

Bug#864082: [Fontconfig] Next steps for a reproducible Fontconfig?

[Alexander Larsson]

On Sun, Jan 13, 2019 at 7:21 PM Keith Packard  wrote:
>
> Alexander Larsson  writes:

> > Yeah, there will be two files. One static in the runtime
> > (/etc/fonts/conf.d/50-flatpak.xml), and one generated by flatpak
> > (/run/host/fontconf.xml).
>
> Sounds like we've got a plan for this part -- fix my mapping code to use
> config bits separate from the  elements, then add a 'salt'
> mechanism in the config bits that stirs in some random data when
> generating the cache keys for specific directory trees.

Whats the status of this. Can we come up with an agreed upon format
for doing the dir remapping (outside of the dir nodes) soon? I'm about
to do a flatpak 1.2 release and would like to preempt things by
generating the dir mapping dynamic snippet so we can use it when we
update fontconfig in the runtime. (Note: We need not yet finalize the
salt stuff, because that will not be in the dynamic flatpak-generated
part of this.)

Bug#919849: [Pkg-salt-team] Bug#919849: salt-doc: broken symlinks: /usr/share/doc/salt/html/_static/*/bootstrap* -> ../../../../../twitter-bootstrap/files/*/bootstrap*

[Benjamin Drung]

Am Sonntag, den 20.01.2019, 06:07 +0100 schrieb Andreas Beckmann:
> Package: salt-doc
> Version: 2018.3.3+dfsg1-2
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
> From the attached log (scroll to the bottom...):
> 
> 0m29.8s ERROR: FAIL: Broken symlinks:
>   /usr/share/doc/salt/html/_static/js/vendor/bootstrap.min.js ->
> ../../../../../../twitter-bootstrap/files/js/bootstrap.min.js (salt-
> doc)
>   /usr/share/doc/salt/html/_static/js/vendor/bootstrap.js ->
> ../../../../../../twitter-bootstrap/files/js/bootstrap.js (salt-doc)
>   /usr/share/doc/salt/html/_static/css/bootstrap.min.css ->
> ../../../../../twitter-bootstrap/files/css/bootstrap.min.css (salt-
> doc)
>   /usr/share/doc/salt/html/_static/css/bootstrap-responsive.min.css
> -> ../../../../../twitter-bootstrap/files/css/bootstrap-
> responsive.min.css (salt-doc)
> 
> 
> Is salt-doc missing a Depends/Recommends/Suggests: libjs-twitter-
> bootstrap ?

salt-doc depends on libjs-bootstrap to provide these files. Sadly the
path has changed between the version in stable and in unstable. I will
fix the symlinks with the next upload.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#920012: fwupd breaks xbox360 controller support

[Phil Armstrong]

Package: fwupd
Version: 1.1.4-1
Severity: normal

Dear Maintainer,

As outlined in https://github.com/hughsie/fwupd/pull/836 fwupd as 
currently in Debian testing breaks xbox 360 controller support.


Can we pull a more recent version of fwupd into buster?

cheers, Phil

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwupd depends on:
ii  libappstream-glib8 0.7.14-1
ii  libarchive13   3.3.3-3
ii  libc6  2.28-5
ii  libefiboot1    37-1
ii  libefivar1 37-1
ii  libelf1    0.175-2
ii  libfwupd2  1.1.4-1
ii  libgcab-1.0-0  1.2-2
ii  libglib2.0-0   2.58.2-3
ii  libgnutls30    3.6.5-2
ii  libgpg-error0  1.33-3
ii  libgpgme11 1.12.0-4
ii  libgudev-1.0-0 232-2
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-25
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.64.2-2
ii  libsqlite3-0   3.26.0+fossilbc891ac6b-1
ii  libuuid1   2.33.1-0.1

Versions of packages fwupd recommends:
ii  bolt   0.7-2
ii  fwupd-amd64-signed [fwupd-signed]  1.1.4+1
ii  python3    3.7.1-3

fwupd suggests no packages.

-- no debconf information

Bug#886777: Bug#907972 #886777: xsane crashes with Mustek Bearpaw 2448 TA Pro

[Bernhard Übelacker]

Control: forcemerge 886777 907972
Control: tags 886777 + upstream fixed-upstream


Dear Maintainer,
upstream applied a fix to this stack smashing.
If no new upstream version is released and enters buster,
this patch [1] might be a candidate for cherry-picking.

Kind regards,
Bernhard


[1] 
https://gitlab.com/sane-project/backends/commit/93340afddfbc4085a5297fe635b65dd7f7f3ef05.patch

Bug#912749: These warnings occur with annoying regularity

[sixerjman]

Even after performing the prescribed fix, after a few days or weeks the
warning are back.

Bug#920011: Recursive chmod

[Stefan Hornburg (Racke)]

package: sympa

W: sympa: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:207
N:
N:The maintainer script appears to call chmod or chown with a
N:--recursive/-R argument, or uses find(1) in a similar manner.
N:
N:This is vulnerable to hardlink attacks on mainline, non-Debian kernels
N:that do not have fs.protected_hardlinks=1,
N:
N:This arises through altering permissions or ownership within a directory
N:that may be owned by a non-privileged user - such a user can link to
N:files that they do not own such as /etc/shadow or files within
N:/var/lib/dpkg/. The promiscuous chown or chmod would convert the
N:ownership or permissions of these files so that they are manipulable by
N:the non-privileged user.
N:
N:Ways to avoid this problem include:
N:
N: - If your package uses a static uid, please perform the chown at
N:   package build time instead of installation time.
N: - Use a non-recursive call instead, ensuring that you do not change
N:   ownership of files that are in user-controlled directories.
N: - Use runuser(1) to perform any initialization work as the
N:   user you were previously chowning to.
N:
N:Refer to https://bugs.debian.org/889060, https://bugs.debian.org/889488,
N:and the runuser(1) manual page for details.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: scripts, Type: binary
N:
W: sympa: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:220
W: sympa: maintainer-script-should-not-use-recursive-chown-or-chmod postinst:226




-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

Bug#920010: Use maintscript files

[Stefan Hornburg (Racke)]

package: sympa
severity: minor

W: sympa: maintainer-script-should-not-use-dpkg-maintscript-helper postinst:56
N:
N:The maintainer script seems to make manual calls to the
N:dpkg-maintscript-helper(1) utility.
N:
N:Please use package.maintscript files instead; the dh_installdeb(1) tool
N:will do some basic validation of some of the commands listed in this
N:file to catch common mistakes.
N:
N:Refer to the dpkg-maintscript-helper(1) manual page and the
N:dh_installdeb(1) manual page for details.
N:
N:Severity: minor, Certainty: certain
N:
N:Check: scripts, Type: binary
N:
W: sympa: maintainer-script-should-not-use-dpkg-maintscript-helper postinst:58
W: sympa: maintainer-script-should-not-use-dpkg-maintscript-helper postinst:71


-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

Bug#920009: golang-google-cloud FTBFS with golang-google-genproto-dev 0.0~git20190111.db91494-1

[Adrian Bunk]

Source: golang-google-cloud
Version: 0.9.0-7
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-google-cloud.html

...
dh_auto_build
cd build && go install 
-gcflags=all=\"-trimpath=/build/1st/golang-google-cloud-0.9.0/build/src\" 
-asmflags=all=\"-trimpath=/build/1st/golang-google-cloud-0.9.0/build/src\" -v 
-p 16 cloud.google.com/go cloud.google.com/go/bigquery 
cloud.google.com/go/bigtable cloud.google.com/go/bigtable/bttest 
cloud.google.com/go/bigtable/cmd/cbt cloud.google.com/go/bigtable/cmd/emulator 
cloud.google.com/go/bigtable/cmd/loadtest 
cloud.google.com/go/bigtable/cmd/scantest 
cloud.google.com/go/bigtable/internal/cbtconfig 
cloud.google.com/go/bigtable/internal/gax 
cloud.google.com/go/bigtable/internal/option 
cloud.google.com/go/bigtable/internal/stat cloud.google.com/go/civil 
cloud.google.com/go/compute/metadata cloud.google.com/go/container 
cloud.google.com/go/datastore cloud.google.com/go/debugger/apiv2 
cloud.google.com/go/errorreporting/apiv1beta1 cloud.google.com/go/errors 
cloud.google.com/go/iam cloud.google.com/go/iam/admin/apiv1 
cloud.google.com/go/internal cloud.google.com/go/internal/atomiccache 
cloud.google.com/go/internal/fields cloud.google.com/go/internal/optional 
cloud.google.com/go/internal/pretty cloud.google.com/go/internal/readme 
cloud.google.com/go/internal/rpcreplay 
cloud.google.com/go/internal/rpcreplay/proto/intstore 
cloud.google.com/go/internal/rpcreplay/proto/rpcreplay 
cloud.google.com/go/internal/testutil cloud.google.com/go/internal/tracecontext 
cloud.google.com/go/internal/version cloud.google.com/go/language/apiv1 
cloud.google.com/go/language/apiv1beta2 cloud.google.com/go/logging 
cloud.google.com/go/logging/apiv2 cloud.google.com/go/logging/internal 
cloud.google.com/go/logging/internal/testing 
cloud.google.com/go/logging/logadmin cloud.google.com/go/longrunning 
cloud.google.com/go/longrunning/autogen cloud.google.com/go/monitoring/apiv3 
cloud.google.com/go/profiler cloud.google.com/go/profiler/mocks 
cloud.google.com/go/pubsub cloud.google.com/go/pubsub/apiv1 
cloud.google.com/go/pubsub/loadtest cloud.google.com/go/pubsub/loadtest/cmd 
cloud.google.com/go/pubsub/loadtest/pb cloud.google.com/go/spanner 
cloud.google.com/go/spanner/admin/database/apiv1 
cloud.google.com/go/spanner/admin/instance/apiv1 
cloud.google.com/go/spanner/internal/testutil cloud.google.com/go/speech/apiv1 
cloud.google.com/go/speech/apiv1beta1 cloud.google.com/go/storage 
cloud.google.com/go/trace cloud.google.com/go/trace/apiv1 
cloud.google.com/go/translate 
cloud.google.com/go/translate/internal/translate/v2 
cloud.google.com/go/videointelligence/apiv1beta1
src/cloud.google.com/go/speech/apiv1beta1/speech_client.go:29:2: cannot find 
package "google.golang.org/genproto/googleapis/cloud/speech/v1beta1" in any of:

/usr/lib/go-1.11/src/google.golang.org/genproto/googleapis/cloud/speech/v1beta1 
(from $GOROOT)

/build/1st/golang-google-cloud-0.9.0/build/src/google.golang.org/genproto/googleapis/cloud/speech/v1beta1
 (from $GOPATH)

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 15:31, Marc Haber wrote:
> On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:

>> I am downgrading this to important though, since I consider the
>> statistics writing an auxillary feature, and I suspect that the issue
>> will fix itself next midnight.
> 
> Can you check whether:
> mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
> atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
> will allow your atop to run again?

I can confirm: this works.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#920008: Manpage has errors

[Stefan Hornburg (Racke)]

package: sympa
severity: minor

W: sympa: manpage-has-errors-from-man usr/share/man/man5/sympa.conf.5.gz 222: 
warning [p 2, 2.2i]: can't break line
N:
N:This man page provokes warnings or errors from man.
N:
N:"cannot adjust" or "can't break" are trouble with paragraph filling,
N:usually related to long lines. Adjustment can be helped by left
N:justifying, breaks can be helped with hyphenation, see "Manipulating
N:Filling and Adjusting" and "Manipulating Hyphenation" in the groff
N:manual (see info groff).
N:
N:"can't find numbered character" usually means latin1 etc in the input,
N:and this warning indicates characters will be missing from the output.
N:You can change to escapes like \[:a] described on the groff_char man
N:page.
N:
N:Other warnings are often formatting typos, like missing quotes around a
N:string argument to .IP. These are likely to result in lost or malformed
N:output. See the groff_man (or groff_mdoc if using mdoc) man page for
N:information on macros.
N:
N:This test uses man's --warnings option to enable groff warnings that
N:catch common mistakes, such as putting . or ' characters at the start of
N:a line when they are intended as literal text rather than groff
N:commands. This can be fixed either by reformatting the paragraph so that
N:these characters are not at the start of a line, or by adding a
N:zero-width space (\&) immediately before them.
N:
N:At worst, warning messages can be disabled with the .warn directive, see
N:"Debugging" in the groff manual.
N:
N:Lintian also stricter in regards to declaring manpage preprocessors.
N:
N:To test this for yourself you can use the following command:
N: LC_ALL=en_US.UTF-8 MANROFFSEQ='' MANWIDTH=80 \
N:man --warnings -E UTF-8 -l -Tutf8 -Z  >/dev/null
N:
N:Refer to the groff_man(7) manual page and the groff_mdoc(7) manual page
N:for details.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: manpages, Type: binary

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

Bug#920007: squid: basic_ncsa_auth username case sensitivity

[Matsievskiy S.V.]

Package: squid
Version: 4.4-1
Severity: normal

Dear Maintainer,

I was configuring basic_ncsa_auth authentication in squid and could not get it 
to work.
Eventually I decided to check input of basic_ncsa_auth and replaced it with 
custom script:

#!/bin/bash
cat $@ > /tmp/args
cat > /tmp/stdin

After output examination, I learned that squid converts all characters to 
lowercase.
In my case, login had uppercase characters in it. So call to basic_ncsa_auth 
never succeeded.

In my opinion either squid should not convert characters to lowercase, or it 
should be clearly stated somewhere that uppercase characters are not allowed.

tldr: basic_ncsa_auth option does not support usernames with uppercase 
characters.

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

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

Versions of packages squid depends on:
ii  adduser  3.118
ii  libc62.28-5
ii  libcap2  1:2.25-1.2
ii  libcom-err2  1.44.5-1
ii  libdb5.3 5.3.28+dfsg1-0.2
ii  libdbi-perl  1.642-1+b1
ii  libecap3 1.0.1-3.2
ii  libexpat12.2.6-1
ii  libgcc1  1:8.2.0-14
ii  libgnutls30  3.6.5-2
ii  libgssapi-krb5-2 1.16.2-1
ii  libkrb5-31.16.2-1
ii  libldap-2.4-22.4.47+dfsg-2
ii  libltdl7 2.4.6-6
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnettle6   3.4.1~rc1-1
ii  libpam0g 1.1.8-4
ii  libsasl2-2   2.1.27~rc8-1
ii  libstdc++6   8.2.0-14
ii  libxml2  2.9.4+dfsg1-7+b3
ii  logrotate3.14.0-4
ii  lsb-base 10.2018112800
ii  netbase  5.5
ii  squid-common 4.4-1

Versions of packages squid recommends:
ii  ca-certificates  20180409
ii  libcap2-bin  1:2.25-1.2

Versions of packages squid suggests:
pn  resolvconf   
ii  smbclient2:4.9.4+dfsg-1
pn  squid-cgi
pn  squid-purge  
pn  squidclient  
ii  ufw  0.36-1
pn  winbindd 

-- Configuration Files:
/etc/squid/squid.conf changed:
acl localnet src 192.168.1.0/24 # RFC 1918 local private network (LAN)
acl SSL_ports port 443
acl Safe_ports port 80  # http
acl Safe_ports port 443 # https
acl CONNECT method CONNECT
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwords
auth_param basic children 10 startup=0 idle=1
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 6 hours
acl password proxy_auth REQUIRED
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
include /etc/squid/conf.d/*
http_access allow password
http_access deny all
http_port 3128
coredump_dir /var/spool/squid
refresh_pattern ^ftp:   144020% 10080
refresh_pattern ^gopher:14400%  1440
refresh_pattern -i (/cgi-bin/|\?) 0 0%  0
refresh_pattern .   0   20% 4320


-- no debconf information

Bug#920005: Embedded JavaScript Library

[Stefan Hornburg (Racke)]

package: sympa
version: 6.2.40~dfsg-1

W: sympa: embedded-javascript-library 
usr/share/sympa/static_content/js/html5shiv/html5shiv.js please use 
libjs-html5shiv
N:
N:This package contains an embedded copy of JavaScript libraries that are
N:now available in their own packages (for example, JQuery, Prototype,
N:Mochikit or "Cropper"). Please depend on the appropriate package and
N:symlink the library into the appropriate location.
N:
N:Refer to Debian Policy Manual section 4.13 (Convenience copies of code)
N:for details.
N:
N:Severity: normal, Certainty: possible
N:
N:Check: files, Type: binary, udeb

-- 
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration. Provisioning with Ansible.

Bug#920006: geeqie: Random crashes in directories with many images

[Rinat]

Package: geeqie
Version: 1:1.4+git20190106-1
Severity: important
Tags: upstream patch

Since version 1:1.4+git20190106-1, Geeqie crashes randomly. Most often it
does so in a directory with many images, about thousand of them. It turned
out, there was an uninitialized variable read, which caused random addresses
to be passed to free(). That code was called once per seen file. That's
why the more one uses Geeqie, the more probable the crash is.

Fix was applied upstream:
http://geeqie.org/cgi-bin/gitweb.cgi?p=geeqie.git;a=commitdiff;h=431adf320f4ce0ba31fb7a07ea53aca03c21fcbd

Please, consider updating the package to include changes.

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

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

Versions of packages geeqie depends on:
ii  geeqie-common1:1.4+git20190106-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-5
ii  libcairo21.16.0-2
ii  libexiv2-14  0.25-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-14
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.2-3
ii  libgtk2.0-0  2.24.32-3
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblirc-client0  0.10.1-5
ii  liblua5.1-0  5.1.5-8.1+b2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  libstdc++6   8.2.0-14
ii  libtiff5 4.0.10-3
ii  sensible-utils   0.0.12

Versions of packages geeqie recommends:
ii  cups-bsd [lpr]   2.2.10-3
ii  exiftran 2.10-2+b3
ii  exiv20.25-4
ii  imagemagick  8:6.9.10.23+dfsg-2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2
ii  librsvg2-common  2.44.10-1
ii  ufraw-batch  0.22-4
ii  zenity   3.30.0-2

Versions of packages geeqie suggests:
pn  geeqie-dbg 
ii  gimp   2.10.8-2
pn  libjpeg-progs  
pn  ufraw  
pn  xpaint 

-- no debconf information

Bug#920004: node-get-value: missing dependency on node-isobject

[Adrian Bunk]

Package: node-get-value
Version: 3.0.1-1
Severity: serious

> require('get-value')
{ Error: Cannot find module 'isobject'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)
at Function.Module._load (internal/modules/cjs/loader.js:507:25)
at Module.require (internal/modules/cjs/loader.js:637:17)
at require (internal/modules/cjs/helpers.js:22:18) code: 'MODULE_NOT_FOUND' 
}
>

Bug#920003: xfce4-pulseaudio-plugin: vlc : cannot control correctly play/pause feature in pulseaudio-plugin 0.4.1-1

[ewan.lbc]

Package: xfce4-pulseaudio-plugin
Version: 0.4.1-1
Severity: normal

Dear Maintainer,

I found this bug in debian testing, but I can reproduce it on debian stretch 
by adding pulseaudio-plugin 0.4.1-1.

Trying to use vlc through the pulseaudio-plugin seems to not work as expected 
(maybe it is a bug related to vlc and not pulseaudio-plugin) : 

1) open a media file from thunar  (sometimes it is happening on 
the second time, so reproduce this step more than one time).
2) click on the vlc pause button in pulseaudio plugin.
3) Try to click on the same button (now play button) to play the media file 
again.

Expected result : The vlc play button is clickable and the video starts again
Actual result : The vlc play button is greyed out and you cannot start the 
video from the  pulseaudio-plugin.


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

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

Versions of packages xfce4-pulseaudio-plugin depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.28-5
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdbus-glib-1-2 0.108-2
ii  libfribidi0  1.0.5-3.1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.58.2-3
ii  libgtk-3-0   3.24.2-3
ii  libkeybinder-3.0-0   0.3.1-1
ii  libnotify4   0.7.7-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpulse-mainloop-glib0  10.0-1+deb9u1
ii  libpulse010.0-1+deb9u1
ii  libxfce4panel-2.0-4  4.12.1-2
ii  libxfce4ui-2-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1

Versions of packages xfce4-pulseaudio-plugin recommends:
ii  pavucontrol  3.0-3.1
ii  pulseaudio   10.0-1+deb9u1

xfce4-pulseaudio-plugin suggests no packages.

-- no debconf information

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 15:43, Sven Hartge wrote:
> On 21.01.19 15:31, Marc Haber wrote:
>> On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:
> 
>>> I am downgrading this to important though, since I consider the
>>> statistics writing an auxillary feature, and I suspect that the issue
>>> will fix itself next midnight.
>>
>> Can you check whether:
>> mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
>> atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
>> will allow your atop to run again?
> 
> I don't have the old files any more unfortunately, sorry.

But I can temporarily downgrade to the version from testing and then do
the upgrade again.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#919966: akregator: symbol lookup error: /usr/lib/x86_64-linux-gnu/libKF5NewStuff.so.5: undefined symbol: _ZN7KNSCore6Engine15signalErrorCodeERKNS_9ErrorCodeERK7QStringRK8QVariant

[Bernhard Übelacker]

Hello Francois Marier,
this looks like a duplicate of bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919765

Kind regards,
Bernhard

Bug#913346: libsane1: Cannot update libsane1

[Jeremy Bicha]

On Mon, Jan 21, 2019 at 9:23 AM John Paul Adrian Glaubitz
 wrote:
> Well, I have a different opinion on that. I do not consider a temporary
> issue in unstable a bug affecting anything but developers.

3 months isn't temporary. While I think Testing is a better fit for
users than Unstable (maybe we agree there), there are huge numbers of
people and writings that argue that users should use Unstable instead
because "Testing has no security guarantees".

> I'm not sure why you are resorting to the Release Team here? What does the
> Release Team have to do with unstable which isn't even a release?

Because you're "appealing to authority" by asking me to prove that
there is a bug here. I think we all agree that the Debian Release Team
can decide what is an RC bug. But I guess you're going to nitpick and
argue that the Release Team has no authority over Unstable and we
shouldn't even consider their opinion then…

> Why is Ubuntu importing packages with RC bugs open? Shouldn't that
> be blocked?

I did block it: Ubuntu itself never had this bug because it was
blocked in the "devel-proposed" section which even developers aren't
supposed to be using.

Let me be more direct here: I don't understand why you are blocking
this bug fix. You don't even have to do the upload yourself: just
apply the patch that has been given and allow Gianfranco to do the
NMU. How does accepting this bugfix hurt anybody?

Thanks,
Jeremy Bicha

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Trek]

On Mon, 21 Jan 2019 08:36:51 +0100
Trek  wrote:

> and the one in the attach

missed, sorry
attached to this message--- udev.init.orig	2019-01-12 21:49:44.0 +0100
+++ udev.init	2019-01-21 01:54:51.047997585 +0100
@@ -178,7 +178,7 @@
 fi
 
 log_action_begin_msg "Synthesizing the initial hotplug events (subsystems)"
-if udevadm trigger --type=subsystems --action=add; then
+if udevadm trigger --type=subsystems --action=add --wait-daemon; then
 log_action_end_msg $?
 else
 log_action_end_msg $?

Bug#920002: mlton build depends on ruby-albino that was removed from unstable

[Adrian Bunk]

Source: mlton
Version: 20130715-3
Severity: serious
Tags: ftbfs buster sid
Control: close -1 20180207-1

mlton build depends on ruby-albino that was removed from unstable.

This bug is already fixed in the version in unstable.

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 15:31, Marc Haber wrote:
> On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:

>> I am downgrading this to important though, since I consider the
>> statistics writing an auxillary feature, and I suspect that the issue
>> will fix itself next midnight.
> 
> Can you check whether:
> mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
> atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
> will allow your atop to run again?

I don't have the old files any more unfortunately, sorry.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#918776: at-spi2-core: Warning "Couldn't register with accessibility bus:" when starting Emacs and other applications

[Peter Hull]

I can't reproduce this on a fresh install. Unless you know any different
this bug can be closed.

On Fri, 18 Jan 2019 at 13:16 Peter Hull  wrote:

> On Fri, Jan 18, 2019 at 12:25 PM Peter Hull  wrote:
> > I can try and
> > re-create a fresh install if that would help?
> I tried a fresh install (still under VirtualBox) and it didn't have
> this problem. So it may be nothing. I'll check my original one later
> when I get back to that machine.
>

Bug#872573: Stopping libvirtd.service does not properly stop all (dnsmasq) processes

[Tomas Janousek]

Hi,

On Mon, Sep 11, 2017 at 08:07:45AM +0200, Guido Günther wrote:
> On Fri, Aug 18, 2017 at 08:47:09PM +0200, Michael Biebl wrote:
> > [...]
> > See, how the dnsmasq processes are still running after stopping the
> > service.
> 
> This is itentional since the networks continue to run. Once you stop the
> network the dnsmasq instance goes away too. Otherwise daemon restarts
> would break VM connectivity.

If the networks continue to run, why are they started again? Is there perhaps
a way to detect that the network is already started and skip starting it
again?

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

Bug#920001: unblock: json-c/0.12.1+ds-2

[Boyuan Yang]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: k...@debian.org debian-b...@lists.debian.org

Dear Release Team and d-i Team,

As previously mentioned in [1], I made a new upload (QA upload) for json-c
library to clean up various issues. There's no change to the source code, only
updates in packaging instruction.

This package is currently blocked due to block-udeb request. I'm wondering if
we could unblock it so that the package may migrate into Testing soon (or at
least before full Buster freeze).

The new upload builds successfully on all architectures (except kfreebsd-*,
which is still under Needs-Build condition). There's no new regression
according to autopkgtest results. Piuparts test is also ok.

Regards,
Boyuan Yang

[1] https://lists.debian.org/debian-boot/2019/01/msg00146.html


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

Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]

[Adam Borowski]

On Mon, Jan 21, 2019 at 03:26:18PM +0100, أحمد المحمودي wrote:
> Re-uploaded elinks, with libmozjs60-dev | libmozjs-dev (removed obsolete 
> libmozjs185-dev)

Alas, it still FTBFSes:

Working on: /<>/doc/manual.xml
xmlto: /<>/doc/manual.xml does not validate (status 3)
xmlto: Fix document syntax or use --skip-validation option
/<>/doc/manual.xml:3993: element link: validity error : IDREF 
attribute linkend references an unknown ID "CONFIG-SCRIPTING-SPIDERMONKEY"
Document /<>/doc/manual.xml does not validate
make[2]: *** [Makefile:201: manual.html-chunked] Error 13


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:
> I am downgrading this to important though, since I consider the
> statistics writing an auxillary feature, and I suspect that the issue
> will fix itself next midnight.

Can you check whether:
mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
will allow your atop to run again?

Greetings
Marc

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

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 03:10:28PM +0100, Sven Hartge wrote:
> On 21.01.19 13:27, Marc Haber wrote:
> > On Mon, Jan 21, 2019 at 01:15:09PM +0100, Sven Hartge wrote:
> 
> >> I think you can just delete all old statistics files, since they are
> >> useless with the new atop. sysstat does this all the time (after a
> >> debconf prompt).
> > 
> > I'd rather go without debconf and gazillions of translations.
> 
> Easiest solution would be to run the rotate script on upgrades from
> <2.4.0 before starting the newly installed version. That way the old
> files are still there, if one needs them but the new daemon starts with
> a clean slate.

This is no direct rotate script, atop gets restarted at midnight with -w
"$LOGPATH"/atop_"$CURDAY", so just restarting the script won't work.

Take a look at /usr/share/atop/atop.daily.

Greetings
Marc

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

Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]

[أحمد المحمودي]

On Sat, Jan 19, 2019 at 01:41:58AM +0100, Adam Borowski wrote:
> On Sat, Jan 19, 2019 at 07:47:51AM +0800, Paul Wise wrote:
> > On Fri, Jan 18, 2019 at 11:51 PM Adam Borowski wrote:
> > The most ideal situation would be to leave it off by default but
> > have a command-line option to turn it on.
---end quoted text---

Elinks is only compiled with javascript, but it is disabled by default. 
ie. the user has to switch it on.

Re-uploaded elinks, with libmozjs60-dev | libmozjs-dev (removed obsolete 
libmozjs185-dev)

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


signature.asc
Description: PGP signature