Bug#940630: xchm: Newer upstream releases

2019-09-17 Thread Olly Betts
Source: xchm
Version: 2:1.23-3
Severity: normal

Visiting the current "Homepage:" URL I get "Unable to connect", but if I
change https to http, i.e. http://xchm.sourceforge.net/ I get a page
that redirects me to https://github.com/rzvncj/xCHM which seems to be
the new upstream home.

And that has several newer releases than what's currently packaged for
Debian - the latest is 1.30, released 2019-06-20.

It looks like 1.30 fixes a number of bugs over 1.23:

https://github.com/rzvncj/xCHM/blob/66a953f04bb79c609cc52f74be2f9514f8b6d22d/ChangeLog

Updating to it would also allow wx3.0-compat.patch to be dropped.

Cheers,
Olly



Bug#939757: gnome-sound-recorder 3.28.2-2~deb10u1 flagged for acceptance

2019-09-17 Thread Adam D Barratt
package release.debian.org
tags 939757 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: gnome-sound-recorder
Version: 3.28.2-2~deb10u1

Explanation: fix crash when selecting a recording



Bug#940587: cloud.debian.org: additional Vagrant boxes with puppet/ansible pre-installed?

2019-09-17 Thread Geert Stappers
On Tue, Sep 17, 2019 at 10:52:54AM -0400, Gabriel Filion wrote:
> I was wondering if folks maintaining the vagrant boxes would be willing to
> publish additional images that would have puppet/ansible pre-installed with
> the debian packages from each release's package repository?

I also don't understand how cloudinit works.

There is https://cloudinit.readthedocs.io/en/latest/
But it lacks what it makes it tick.

Nowhere is documented
* how it starts (what triggers the start)
* how "client" finds "server"
* why "client" trusts "server"


Groeten
Geert Stappers
-- 
Leven en laten leven



Bug#870579: aren't CALLIT replies still going to come from a random port?

2019-09-17 Thread Martin Dorey
I've looked at the changes in 1.2.5-8 and I don't see how they'll make
rpcbind reply from port 111 like portmap used to.  If I'm right, then this
bug isn't fixed yet.  I just happened across a change that looks more
hopeful to me:

https://github.com/mendersoftware/poky/blob/master/meta/recipes-extended/rpcbind/rpcbind/rpcbind_add_option_to_fix_port_number.patch

I haven't tried it but it looks like it might let me set the port used to
111.


Bug#939768: Bug resolved

2019-09-17 Thread Charlie Hagedorn
Chiming in to confirm that a debian-testing update just now pulled
in libgegl-0.4-0:amd64 (0.4.14-2). GIMP starts up as expected with the
first jpeg I tried. My system was never apt-pinned.

Back to image editing!

Thank you, everyone who makes Debian possible!

Charlie


Bug#939901: Upstream has released 1.3.0

2019-09-17 Thread Chris Knadle
Michael Evans:
> Package: mumble
> Version: 1.3.0~git20190125.440b173+dfsg-2
> 
> Upstream has released 1.3.0
> https://www.mumble.info/blog/mumble-1.3.0-release-announcement/

Ignore my last message to you, it was due to user error -- I was verifying an
old 2017 tarball in place of the new 1.3.0 tarball accidentally.

I'm working to upgrade the package when possible.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



Bug#940629: fatrace: add support for detecting rename events

2019-09-17 Thread Paul Wise
Package: fatrace
Version: 0.13-2
Severity: wishlist

Linux fanotify now supports detecting file renames, it would be nice to
have support for those (AFAICT there is no support for them yet) and for any 
other fanotify events that have been added in recent years.

https://lwn.net/Articles/717060/

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages fatrace depends on:
ii  libc6  2.29-1

Versions of packages fatrace recommends:
ii  powertop  2.10-1+b1
ii  python3   3.7.3-1

fatrace suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#939768: Gimp crashes on opening any jpeg

2019-09-17 Thread jazzmans
Debian bullseye updated 2019 09 17
```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6)

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```
/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7fe599c81f98]
gimp-2.10(+0xd1590)[0x55b1adb26590]
gimp-2.10(+0xd19b8)[0x55b1adb269b8]
gimp-2.10(+0xd2029)[0x55b1adb27029]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13510)[0x7fe599173510]
gimp-2.10(gimp_gegl_mask_is_empty+0x91)[0x55b1adf11411]
gimp-2.10(+0x3b7810)[0x55b1ade0c810]
gimp-2.10(+0x42ec18)[0x55b1ade83c18]
gimp-2.10(+0x3d5b50)[0x55b1ade2ab50]
gimp-2.10(+0x42f2aa)[0x55b1ade842aa]
gimp-2.10(gimp_drawable_set_buffer_full+0x1cb)[0x55b1ade299bb]
gimp-2.10(gimp_drawable_set_buffer+0x11d)[0x55b1ade29f9d]
gimp-2.10(gimp_drawable_new+0x106)[0x55b1ade2a296]
gimp-2.10(gimp_layer_new+0x90)[0x55b1ade874d0]
gimp-2.10(+0x3319cc)[0x55b1add869cc]
gimp-2.10(gimp_procedure_execute+0x237)[0x55b1addbf577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x55b1addb8a39]
gimp-2.10(gimp_plug_in_handle_message+0x216)[0x55b1addc3626]
gimp-2.10(+0x36cf91)[0x55b1addc1f91]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7fe599326898]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ec88)[0x7fe599326c88]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7fe599326f82]
gimp-2.10(gimp_plug_in_manager_call_run+0x5fc)[0x55b1addd335c]
gimp-2.10(+0x376dbe)[0x55b1addcbdbe]
gimp-2.10(gimp_procedure_execute+0x237)[0x55b1addbf577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x55b1addb8a39]
gimp-2.10(gimp_plug_in_handle_message+0x216)[0x55b1addc3626]
gimp-2.10(+0x36cf91)[0x55b1addc1f91]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7fe599326898]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ec88)[0x7fe599326c88]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7fe599326f82]
gimp-2.10(gimp_plug_in_manager_call_run+0x5fc)[0x55b1addd335c]
gimp-2.10(+0x376dbe)[0x55b1addcbdbe]
gimp-2.10(gimp_procedure_execute+0x237)[0x55b1addbf577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x55b1addb8a39]
gimp-2.10(gimp_pdb_execute_procedure_by_name+0x3cd)[0x55b1addb8efd]
gimp-2.10(file_open_image+0x33d)[0x55b1adeb96fd]
gimp-2.10(gimp_imagefile_create_thumbnail+0x402)[0x55b1ade74d52]
gimp-2.10(gimp_imagefile_create_thumbnail_weak+0xb5)[0x55b1ade74e65]
gimp-2.10(+0x2b6037)[0x55b1add0b037]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7fe599326898]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ec88)[0x7fe599326c88]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7fe599326f82]
gimp-2.10(app_run+0x36e)[0x55b1adb25d7e]
gimp-2.10(main+0x36e)[0x55b1adb2564e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7fe598fc6bbb]
gimp-2.10(_start+0x2a)[0x55b1adb257da]

```
-- 

Life is what happens to you while you are busy  making other plans.


Bug#939446: buster-pu: package emacs/1:26.1+1-3.2

2019-09-17 Thread Rob Browning
Andreas Beckmann  writes:

> You probably want to include the fixes for #929567 in case that affects
> stable, too.

I'd be happy to if the release managers are amenable -- I was just
trying to make the minimum change in order to get the key updated
without potentially raising other questions.

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



Bug#940270: mumble-server: Server fails to start with valid SSL Certs enabled.

2019-09-17 Thread Chris Knadle
Andrew Lawrence DeMarsh:
> Package: mumble-server
> Version: 1.3.0~git20190125.440b173+dfsg-2
> Severity: important
> 
> Dear Maintainer,
> 
> When adding SSL Certs from LetsEncrypt to the mumble server that was
> operating with self signed certs it was found that the Server would
> fail to start up with the following error:
> 
> root@mumble:/# murmurd -ini /etc/mumble-server.ini -v
> 2019-09-14 23:40:58.428 SSL: OpenSSL version is 'OpenSSL 1.1.1c  28 May 
> 2019'
> 2019-09-14 23:40:58.428 Initializing settings from 
> /etc/mumble-ff-server.ini (basepath /etc) 
>  
> 2019-09-14 23:40:58.430 MetaParams: Failed to find certificate matching 
> private key.
> 2019-09-14 23:40:58.430 MetaParams: Failed to load SSL settings. See 
> previous errors.
> 
> This is not a permissions issue as the certificates are in roots home folder 
> and it is running as root.
> These are standard SSL Cert from letsencrypt recieved using acme.sh.

It's unusual to run mumble-server/murmur as root, and also unusual to have SSL
certificates in the root user home folder.  Mumble is typically started as root
but then the user switched to the user listed in the configuration file in
/etc/mumble-server.ini.  The default setting is: "uname=mumble-server".
Have you set the 'uname' setting to "root"?

The Mumble wiki has some LetsEncrypt instructions here:
   https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate

note that the instructions above discuss the folders in the path needing
"directory execute permissions" for the server to be able to read the 
certificates.

Other users have had issues getting mumble-server with LetsEncrypt certificates
but eventually got it working after discussing it in the #mumble IRC channel on
irc.freenode.net.  If you get the chance to ask there I think they can help
debug the issue further.

  -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us



Bug#936399: diodon: Python2 removal in sid/bullseye

2019-09-17 Thread Scott Kitterman
This turns out to be more complicated than I had expected.  Internally waf 
uses /usr/bin/env python (which still, of course, is /usr/bin/python vice 
python3), so it fails with python3 even though the upstream code appears to at 
least in part consider python3.

This I could fix with sed, something like:

find -name "*.py" | xargs sed -i "s:\/usr\/bin\/env\ python:\/usr/bin\/
python3:g"
sed -i "s:\/usr\/bin\/env\ python:\/usr/bin\/python3:g" waf
sed -i "s:\/usr\/bin\/env\ python:\/usr/bin\/python3:g" wscript

Not pretty, but works.  But then waf exploads on me:

./waf distclean --nocache --prefix=/usr
Traceback (most recent call last):
  File "./diodon-1.8.0/waflib/Node.py", line 491, in ant_iter
raise StopIteration
StopIteration

The above exception was the direct cause of the following exception:

Traceback (./diodon-1.8.0/waflib/Scripting.py", line 138, in waf_entry_point
run_commands()
  File "./diodon-1.8.0/waflib/Scripting.py", line 225, in run_commands
parse_options()
  File "./diodon-1.8.0/waflib/Scripting.py", line 186, in parse_options
Context.create_context('options').execute()
  File "./diodon-1.8.0/waflib/Options.py", line 250, in execute
super(OptionsContext, self).execute()
  File "./diodon-1.8.0/waflib/Context.py", line 216, in execute
self.recurse([os.path.dirname(g_module.root_path)])
  File "./diodon-1.8.0/waflib/Context.py", line 294, in recurse
user_function(self)
  File "./diodon-1.8.0/wscript", line 39, in options
opt.tool_options('compiler_c')
  File "./diodon-1.8.0/waflib/Context.py", line 209, in load
fun(self)
  File "./diodon-1.8.0/waflib/Tools/compiler_c.py", line 87, in options
opt.load_special_tools('c_*.py', ban=['c_dumbpreproc.py'])
  File "./diodon-1.8.0/waflib/Context.py", line 515, in load_special_tools
lst = self.root.find_node(waf_dir).find_node('waflib/extras').ant_glob(var)
  File "./diodon-1.8.0/waflib/Node.py", line 579, in ant_glob
ret = [x for x in self.ant_iter(accept=accept, pats=[to_pat(incl), 
to_pat(excl)], maxdepth=25, dir=dir, src=src, remove=kw.get('remove', True))]
  File "./diodon-1.8.0/waflib/Node.py", line 579, in 
ret = [x for x in self.ant_iter(accept=accept, pats=[to_pat(incl), 
to_pat(excl)], maxdepth=25, dir=dir, src=src, remove=kw.get('remove', True))]
RuntimeError: generator raised StopIteration
make[1]: *** [debian/rules:18: override_dh_auto_clean] Error 2
make[1]: Leaving directory './diodon-1.8.0'
make: *** [debian/rules:10: clean] Error 2
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit 
status 2

I don't know anything about waf, so that's not something I can troubleshoot.  
Not going to NMU.

Scott K

On Tuesday, September 17, 2019 1:46:07 PM EDT Oliver Sauder wrote:
> I currently do not have a lot of time at hand. So if you could follow up
> releasing your NMU debdiff that would be great (diff looks good to me).
> 
> Oliver
> 
> On 01.09.19 09:18, Scott Kitterman wrote:
> > On Fri, 30 Aug 2019 07:15:05 + Matthias Klose  wrote:
> >> Package: src:diodon
> >> Version: 1.8.0-1
> >> Severity: normal
> >> Tags: sid bullseye
> >> User: debian-pyt...@lists.debian.org
> >> Usertags: py2removal
> >> 
> >> Python2 becomes end-of-live upstream, and Debian aims to remove
> >> Python2 from the distribution, as discussed in
> >> https://lists.debian.org/debian-python/2019/07/msg00080.html
> >> 
> >> Your package either build-depends, depends on Python2, or uses Python2
> >> in the autopkg tests.  Please stop using Python2, and fix this issue
> >> by one of the following actions.
> > 
> > I've attached a fix in the form of an NMU debdiff.  I don't currently plan
> > to NMU, but may later if this remains open.  Please fix.
> > 
> > Scott K



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


Bug#940220: 940...@bugs.debian.org

2019-09-17 Thread Eiichiro ITANI
Dear maintainer,

When /usr/lib/postgresql Directory contains directory which name
does not look like version number(aka, /usr/lib/posgresql/lib),
pg_ctlcluster do always enter infinite loop.

Please apply patch below, it will fix this problem.

Regards.
  ITANI Eiichiro


--- /usr/share/perl5/PgCommon.pm.orig   2019-09-12 22:22:22.0 +0900
+++ /usr/share/perl5/PgCommon.pm2019-09-18 09:21:20.312233557 +0900
@@ -694,7 +694,7 @@
 my $pfx = '';
 #redhat# $pfx = "pgsql-";
 ($entry) = $entry =~ /^$pfx(\d+\.?\d+)$/; # untaint
-push @versions, $entry if get_program_path ('psql', $entry);
+push @versions, $entry if $entry and get_program_path ('psql', 
$entry);
 }
 closedir D;
 }



Bug#940626: uxterm: please lessen dependency on locales

2019-09-17 Thread Thomas Dickey
On Wed, Sep 18, 2019 at 12:35:32AM +0200, Thorsten Glaser wrote:
> Package: xterm
> Version: 348-2
> Severity: normal
> Tags: patch
> 
> Please apply the following patch (which is _not_ suitable for
> upstream as the C.UTF-8 locale is my invention and not shipped

really?

(I forget exactly, but my first sighting of this was from the Cygwin crowd -
there was a long thread on austin-review a few years later).

> in all operating systems):

still, a bad idea regarding interoperability (in case one uses ssh,
passing the locale settings from one machine to another).

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


signature.asc
Description: PGP signature


Bug#928520: Provide systemd unit for unclutter

2019-09-17 Thread Axel Beckert
Control: tag -1 + moreinfo

Hi Jörg,

Jörg Sommer wrote:
> maybe, could you ship this unit file as 
> /usr/lib/systemd/user/unclutter.service?
> This runs unclutter independent of the window manager

Well, /etc/X11/Xsession.d/90unclutter is also independent of the
window manager...

So I assume that -- if we include your file --
/etc/X11/Xsession.d/90unclutter will need to check if its running
under systemd and if it discovers that it is running under systemd,
then do nothing? (BTW: What's the best way to do such a check?)

I'm though not sure if we don't loose some cases where it now would
start and later would not start.

> and it aggregates all log messages via journal.

So far that's the only advantage I see of that .service file.

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



Bug#940238: Acknowledgement (ZFS on Linux fails to install under Buster (dependency problems))

2019-09-17 Thread Matt Weller
I had luck following the version-pinning instructions on zfsonlinux's Github 
page with Debian instructions.

Original link here: https://github.com/zfsonlinux/zfs/wiki/Debian

And in case that changes or disappears:
# vi /etc/apt/sources.list.d/buster-backports.list
deb http://deb.debian.org/debian buster-backports main contrib
deb-src http://deb.debian.org/debian buster-backports main contrib

# vi /etc/apt/preferences.d/90_zfs
Package: libnvpair1linux libuutil1linux libzfs2linux libzpool2linux spl-dkms 
zfs-dkms zfs-test zfsutils-linux zfsutils-linux-dev zfs-zed
Pin: release n=buster-backports
Pin-Priority: 990

apt update && apt install -yes dpkg-dev linux-headers-$(uname -r) 
linux-image-amd64 && apt-get install zfs-dkms zfsutils-linux



And finally, during the install, it will still bomb out trying to process 
zfs-zed and zfsutils-linux. You can get around this bymodprobe zfs, then 
apt install -f.




Network Administrator
Northern Valley Indian Health, Inc.
2561 California Park Drive, Suite 200
Chico, CA 95928
 530-433-2607
 530-921-2080
 matthew.wel...@nvih.org
 https://nvih.org
 https://facebook.com/northernvalleyindianhealth
CONFIDENTIALITY NOTICE: The text and documents accompanying this electronic 
transmission may contain confidential information, which is legally privileged. 
 The information is intended only for the use of the individual or individuals 
named above.  If you are not the intended recipient, you are hereby notified 
that any disclosure, copying, distribution or use of any of the information 
contained in this transmission is strictly PROHIBITED.  If you have received 
this transmission in error, please immediately notify sender above by 
telephone.  Thank you.   EXCLAIMER-1X2S9KJ
On Sun, 15 Sep 2019 13:56:30 +1000 TarotApprentice  
wrote:
> I also tried a clean install of Stretch with the version in Stretch and 4.9 
> kernel. I tried the Stretch-backports version with the 4.19 kernel. They both 
> fail with the same errors regarding dependencies.

>
> I tried the clean install of Buster as logged as well as the version from 
> Buster-backports and also the version in experimental. I tried with the 4.19 
> kernel and the 5.2 kernel (from backports). None seem able to be installed on 
> a clean system.

>
>
>
>


Bug#940628: grub-efi-{non-i386/amd64}-bin: Missing multiboot.mod

2019-09-17 Thread Elliott Mitchell
Package: src:grub2
Version: 2.02+dfsg1-20
Severity: important

In particular grub-efi-arm-bin should have
/usr/lib/grub/arm-efi/multiboot.mod and grub-efi-arm64-bin should have
/usr/lib/grub/arm64-efi/multiboot.mod

This makes it impossible for GRUB to load Xen on any platform that is not
either i386 or amd64.  Xen has support for running on ARM platforms, but
with no bootloader...

For example there is known to be working UEFI third-stage firmware for
the Raspberry PI:
https://github.com/tianocore/edk2-platforms/tree/master/Platform/RaspberryPi/RPi3

The absence of /usr/lib/grub/arm64-efi/multiboot.mod means entries
generated by /etc/grub.d/20_linux_xen cannot work.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



Bug#932336: xen-utils-common: vif-nat exits with code 1 even if successful

2019-09-17 Thread Stephan Beyer
I stumbled over exactly the same issue today, tried to narrow it down by
adding debug messages to the script, and suddenly it worked.

I think the bad guy is

[ "$dhcp" != 'no' ] && dhcp_up

which returns 1 in case no dhcp is used. Maybe using "if" here is better...

Also handle_iptable (in vif-common.sh) only does a "return" which again
returns 1. Maybe using "return 0" here is better...

The question (for me) is why this leads to an exit. Even if "set -e" is
used in some scripts, why does it exit at handle_iptable() and not
already after the false [ "$dhcp" != 'no' ]?

Stephan



Bug#940615: grub-efi-amd64: On upgrade to buster apt fails to install shim-signed-common and shim-signed due to grub-install fail

2019-09-17 Thread Steve McIntyre
On Tue, Sep 17, 2019 at 08:09:02PM +0100, Tony wrote:
>Package: grub-efi-amd64
>Version: 2.02+dfsg1-20
>Severity: important
>
>Dear Maintainer,
>
>I have just upgraded to buster.  apt full-upgrade failed.  Subsequently
>further use of apt fails so I don't seem able to make further changes
>with apt,  such as purge removed packages.  It appears that the problem
>is in install-grub which is failing.
>
>I suspect this is a problem I have had on earlier releases where
>grub-install failed because I have the efi partition on raid 0.  However
>on previous versions although grub-install did not complete it did not
>return an error so software calling it continued.  This meant that apt
>could continue.

So you're running in a known-unsupported configuration. In the past,
Grub was buggy and would ignore errors. In that situation, you could
get to the point where you'd think that an upgrade had worked but your
system would not boot. At least now you get to see the errors.

Please fix your configuration. There is no bug here IMHO.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess



Bug#940627: ffmpegthumbnailer Rotation metadata ignored

2019-09-17 Thread Joe Dupuis
Package: ffmpegthumbnailer
Version: 2.1.1-0.1+b3
Severity: normal

Hi,
The version of ffmpegthumbnailer on debian ignore rotation metadata.
This is problematic when dealing with video filmed on a smartphone.
A fix for it have been pushed upstream in version 2.1.2 (debian is at 2.1.1).

Thank you,

Joe

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

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

Versions of packages ffmpegthumbnailer depends on:
ii  libc62.24-11+deb9u4
ii  libffmpegthumbnailer4v5  2.1.1-0.1+b3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libstdc++6   6.3.0-18+deb9u1

ffmpegthumbnailer recommends no packages.

Versions of packages ffmpegthumbnailer suggests:
ii  libglib2.0-0  2.50.3-2

-- no debconf information



Bug#875184: Help needed for medical imaging framework sofa (Was: Bug#875184: [sofa-framework] Future Qt4 removal from Buster)

2019-09-17 Thread Lisandro Damián Nicanor Pérez Meyer
Hi!

El mar., 17 sep. 2019 17:17, Andreas Tille  escribió:

> On Tue, Sep 17, 2019 at 01:26:17PM -0300, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> >
> > Is the embedded stuff all in extlibs/? or is there some other 3rdparty
> code?
>
> A lot is excluded in advance from the packaging Git:
>
> Files-Excluded: */libQGLViewer*
> */csparse
> */gtest
> */qwt*
> */eigen-3*
> */newmat
> */extlibs/json
> */tinyxml
> */*.dll
> */*.lib
> */SuiteSparse
>
> Some of these previously resided in SofaKernel/extlibs before
> the removal.
>
> Hope this helps



It does. I can't assure you I'll be able to do it, but will do my best try.


Bug#801614: xserver-xorg-legacy: ask for needs_root_rights in Xwrapper.config

2019-09-17 Thread Thorsten Glaser
Package: xserver-xorg-legacy
Version: 2:1.20.4-1
Followup-For: Bug #801614

Yes please, I need this preseedable so I can set this to yes in the
debconf database in an installer for a specific platform which needs
this for the X server to work, so that, when the user later installs
the X server, the settings will be already correct (we do not install
X by default but wish to prepare for it).

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 xserver-xorg-legacy depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  libaudit1  1:2.8.5-2
ii  libbsd00.10.0-1
ii  libc6  2.29-1
ii  xserver-common 2:1.20.4-1

xserver-xorg-legacy recommends no packages.

xserver-xorg-legacy suggests no packages.

-- debconf information:
  xserver-xorg-legacy/xwrapper/actual_allowed_users: anybody
  xserver-xorg-legacy/xwrapper/allowed_users: Anybody



Bug#940626: uxterm: please lessen dependency on locales

2019-09-17 Thread Thorsten Glaser
Package: xterm
Version: 348-2
Severity: normal
Tags: patch

Please apply the following patch (which is _not_ suitable for
upstream as the C.UTF-8 locale is my invention and not shipped
in all operating systems):

--- usr/bin/uxterm
+++ uxterm
@@ -71,7 +71,7 @@ do
C|POSIX)
# Yes, I know this is not the same - but why are you
# here then?
-   value=en_US
+   value=C
;;
esac
break
@@ -87,7 +87,7 @@ if test $found != yes ; then
value=`echo ${value} |sed -e 's/[.@].*//'`.UTF-8
else
name="LC_CTYPE"
-   value="en_US.UTF-8"
+   value="C.UTF-8"
fi
eval save=\$${name}
eval ${name}=${value}


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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 xterm depends on:
ii  libc6   2.29-1
ii  libfontconfig1  2.13.1-2+b1
ii  libfreetype62.9.1-4
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20190803-1
ii  libutempter01.1.6-3
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information



Bug#940613: ITP: GNU poke -- An interactive, extensible editor for binary data

2019-09-17 Thread Sergio Durigan Junior
[ Forwarding.  ]

<#secure method=pgpmime mode=sign>
On Tuesday, September 17 2019, I wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Sergio Durigan Junior 
>
> * Package name: poke
>   Version : 0.1-beta
>   Upstream Author : Jose E. Marchesi
> * URL : http://www.jemarch.net/poke.html
> * License : GPL-3+
>   Programming Lang: C
>   Description : GNU poke -- An interactive, extensible editor for binary 
> data
>
>  GNU poke is an interactive, extensible editor for binary data. Not
>  limited to editing basic entities such as bits and bytes, it provides a
>  full-fledged procedural, interactive programming language designed to
>  describe data structures and to operate on them.
>
> -- 
> Sergio
> GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> Please send encrypted e-mail if possible
> http://sergiodj.net/
>

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/



Bug#940625: ITP: diskcache -- Python module for Disk and file backed persistent cache

2019-09-17 Thread Yaroslav Halchenko
Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: diskcache
  Version : 4.0.0
  Upstream Author : Grant Jenks 
* URL : http://www.grantjenks.com/docs/diskcache/
* License : Apache-2.0
  Programming Lang: Python
  Description : Python module for Disk and file backed persistent cache

 DiskCache is an Apache2 licensed disk and file backed cache library, written
 in pure-Python. Its features include
 .
 - Django compatible API
 - Thread-safe and process-safe
 - Supports multiple eviction policies (LRU and LFU included)
 - Keys support “tag” metadata and eviction

 This package is needed for another ITP, girder-client


Bug#875195: [stretchplayer] Future Qt4 removal from Buster

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

This seems dead upstream, the upstream repo vanished along with
gitorious.org, does anyone intend to port it themselves? Otherwise
we should remove it as Qt4 removal is going forward now.

Cheers,
Moritz



Bug#935343: eficas: Qt4 removal from Bullseye

2019-09-17 Thread Moritz Mühlenhoff
On Wed, Aug 21, 2019 at 11:00:10PM +0300, Dmitry Shachnev wrote:
> Source: eficas
> Version: 6.4.0-1-2
> Severity: important
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> Hi!
> 
> As you might know, we the Qt/KDE team are going to remove Qt 4 in Bullseye
> cycle, as announced in [1].
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get removed
> from the Debian repositories.
> 
> Your package still uses Qt 4, via the Python bindings (PyQt4).
> 
> Therefore, please take the time and:
> 
> - contact your upstream (if existing) and ask about the state of a Qt 5 /
>   PyQt5 port of your application;
> - if there are no activities regarding porting, investigate whether there are
>   suitable alternatives for your users;
> - if there is a Qt 5 port that is not yet packaged, consider packaging it;
> - if both the Qt 4 and the Qt 5 versions already coexist in the Debian
>   archives, consider removing the Qt 4 version.

Per https://www.code-aster.org/forum2/viewtopic.php?id=22738 is obsolete
and won't get ported.

Is this accurate? Does anyone of the maintainers intend to port it themselves?
Otherwise let's remove it as we're moving forward with the Qt4 removal now.

Cheers,
Moritz 



Bug#940624: Errors in the translatable messages

2019-09-17 Thread Maarten

Package: dbconfig-common
Version: 2.0.12
Severity: minor



Dear Maintainer


On 1 September 2019 I delivered an updated Dutch translation for
dbconfig-common. This is my report on the errors that I found in the
English source text.

This report uses 'the English source text' as an abstraction that
refers to the strings that have been made translatable in the source
code of dbconfig-common. It also uses 'paragraph' to refer to one of
those strings.

I will use the error types that are listed in the following table.
If you use a monospaced font, the table will be displayed neatly.

===
linguistic level error types
===
word level   spelling error
 word choice error
---
sentence level   grammatical error
 phrasing error
---
paragraph level  coherence error
 clarity error
---
text level   text level error
===


SOURCE TEXT
Alternatively the passwords can be permanently remembered in the
debconf database (which is protected by Unix file permissions),
though this is less secure and thus not the default setting.
ERRORS
- Word choice error: 'permanently remembered' ('stored').

SOURCE TEXT
The ${pkg} package must have a database installed and configured
before it can be used. This can be optionally handled with
dbconfig-common.
ERRORS
- Phrasing error: 'This can be optionally handled with
dbconfig-common.' (This can be done with dbconfig-common when
desired.).

SOURCE TEXT
If you are an advanced database administrator and know that you want
to perform this configuration manually, or if your database has
already been installed and configured, you should refuse this option.
Details on what needs to be done should most likely be provided in
/usr/share/doc/${pkg}.
ERRORS
- Phrasing error: 'know that you want' ('want').
- Phrasing error: 'should most likely be provided in' ('is likely
provided in').

SOURCE TEXT
If you wish to reinstall the database for ${pkg}, you should select
this option. If you do not wish to do so (if you are reconfiguring
the package for unrelated reasons), you should not select this option.
ERRORS
- Clarity error: 'for unrelated reasons'.

SOURCE TEXT
Warning: if you change the name of the database, the old database
will not be removed. If you change the name of the user that connects
to the database, the privileges of the original user will not be
revoked.
ERRORS
- Word choice error: 'Warning' ('Warnings').
- Grammatical error: 'if' (If).
- Coherence error: 'If' (And if).

SOURCE TEXT
Perform upgrade on database for ${pkg} with dbconfig-common?
ERRORS
- Phrasing error: 'Perform upgrade on' (Upgrade).

SOURCE TEXT
According to the maintainer for this package, database upgrade
operations need to be performed on ${pkg}. Typically, this is due to
changes in how a new upstream version of the package needs to store
its data.
ERRORS
- Word choice error: 'for this package' (of this package).
- Phrasing error: 'database upgrade operations need to be performed
on ${pkg}' (the ${pkg} database needs to be updated).
- Phrasing error: 'needs to store' (stores).
- Coherence error: 'its data' (the database).

SOURCE TEXT
If you want to handle this process manually, you should refuse this
option. Otherwise, you should choose this option. During the upgrade,
a backup of the database will be made in
/var/cache/dbconfig-common/backups, from which the database can be
restored in the case of problems.
ERRORS
- Phrasing error: 'handle this process' (do this) {verbosity}.
- Word choice error: 'from which' (with which).
- Phrasing error: 'in the case of' (in case of) {not idiomatic}.

SOURCE TEXT
If other database types are supported by ${pkg} but not shown here,
the reason for their omission is that the corresponding
dbconfig- packages are not installed. If you know that
you want the package to use another supported database type, your
best option is to back out of the dbconfig-common questions and opt
out of dbconfig-common assistance for this package for now. Install
your preferred dbconfig- option from the list in the
package dependencies, and then "dpkg-reconfigure ${pkg}" to select it.
ERRORS
- Phrasing error: 'know that you want' (want).
- Phrasing error: 'back out of the dbconfig-common questions' (back
out of your answers to the dbconfig-common questions).
- Phrasing error: 'Install your preferred dbconfig-
option' (Install your preferred dbconfig-).

SOURCE TEXT
If you no longer have need of the data being stored by ${pkg}, you
should choose this option. If you want to keep this data, or if you
would rather handle this process 

Bug#875029: closed by Yves-Alexis Perez (Bug#875029: fixed in lightdm 1.26.0-6)

2019-09-17 Thread Lisandro Damián Nicanor Pérez Meyer
**Thanks**


Bug#940623: ITP: r-cran-lisreltor -- import output from LISREL into GNU R

2019-09-17 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-lisreltor -- import output from LISREL into GNU R
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-lisreltor
  Version : 0.1.4
  Upstream Author : Sacha Epskamp
* URL : https://cran.r-project.org/package=lisrelToR
* License : GPL-2
  Programming Lang: GNU R
  Description : import output from LISREL into GNU R
 This is an unofficial package aimed at automating the
 import of LISREL output in R.  This package or its maintainer
 is not in any way affiliated with the creators of LISREL and
 SSI, Inc.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-lisreltor



Bug#940611: fails to start because no wrapper missing

2019-09-17 Thread Andreas Tille
Control: tag -1 pending

Hi Daniel,

On Tue, Sep 17, 2019 at 09:31:13PM +0200, Daniel Baumann wrote:
> tag 940611 + patch
> thanks
> 
> here's a patch:
> https://git.progress-linux.org/distributions/engywuck/packages/beagle/commit/?id=dfd229f18e861f5107091be55b82770e961dd7dd

Thanks for your bug report including the patch.  I've pushed it the the
packaging Git leaving the package for final inspection by Dylan.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Bug#940618: mark libmapbox-variant-dev Multi-Arch: foreign

2019-09-17 Thread Sebastiaan Couwenberg
Control: tags -1 pending

Hi Helmut,

Thanks for the patch, it's applied in git and will be included in the
next upload.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#940622: ITP: girder-client -- Python libraries and a command-line tool to interact with a Girder server

2019-09-17 Thread Yaroslav Halchenko
Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: girder-client
  Version : 3.0.3
  Upstream Author : Girder Team
* URL : https://girder.readthedocs.io/en/latest/python-client.html
* License : Apache-2.0
  Programming Lang: Python
  Description : Python libraries and a command-line tool to interact with a 
Girder server

Girder comes with a Python client library and a CLI to allow for
programmatic interaction with a Girder server, and also to workaround
limitations of the web client. For example, the python CLI makes it much easier
to upload a large, nested hierarchy of data from a local directory to Girder,
and also makes it much easier to download a large, nested hierarchy of data
from Girder to a local directory.



Bug#940564: racon: FTBFS against libspoa3

2019-09-17 Thread Andreas Tille
Hi again,

On Tue, Sep 17, 2019 at 02:15:51PM +0200, Andreas Tille wrote:
> Latest upstream needs liblogger[1] which needs to be packaged new.
> I'm working on this (Python3 migration drained to many resources,
> sorry)
> 
> [1]  https://salsa.debian.org/med-team/liblogger

That's solved now but there is another incompatibility with spoa:

   https://github.com/lbcb-sci/racon/issues/6

Kind regards

  Andreas.

-- 
http://fam-tille.de



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

2019-09-17 Thread Thomas Dreibholz
Hi,

I can confirm that the issue gets fixed by installing libgegl-0.4-0
0.4.14-2 from "unstable" over 0.4.12-2 from "testing".

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 Simula@OsloMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature


Bug#490000: [PATCH] Search in all available description translations

2019-09-17 Thread Алексей Шилин
Hi,

With the attached patch, APT searches in all available translations of
package descriptions, which fixes the issue:

$ apt-cache search служба протокола системы | grep rsyslog
rsyslog -
гибкая служба ведения протокола работы системы и ядра
$ apt-cache search system logging daemon | grep rsyslog
rsyslog - гибкая служба ведения протокола работы системы и ядра
$ 
From b827d6845f547ac123e3cbef58b86f57a5037373 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=90=D0=BB=D0=B5=D0=BA=D1=81=D0=B5=D0=B9=20=D0=A8=D0=B8?=
 =?UTF-8?q?=D0=BB=D0=B8=D0=BD?= 
Date: Tue, 17 Sep 2019 22:11:30 +0300
Subject: [PATCH] Search in all available description translations

When multiple translations of package descriptions are available,
perform search in all of them. It allows using search patterns in
any of the configured languages.

Previously, only the first available translation was searched. As
the result, patterns in e.g. English never matched packages which
had their descriptions translated into local language.

Closes: #49
---
 apt-private/private-search.cc | 73 ++-
 1 file changed, 46 insertions(+), 27 deletions(-)

diff --git a/apt-private/private-search.cc b/apt-private/private-search.cc
index de1b19758..7f7d2b343 100644
--- a/apt-private/private-search.cc
+++ b/apt-private/private-search.cc
@@ -94,27 +94,39 @@ static bool FullTextSearch(CommandLine )/*{{{*/
   if (PkgsDone[P->ID] == true)
 	 continue;
 
-  char const * const PkgName = P.Name();
-  pkgCache::DescIterator Desc = V.TranslatedDescription();
-  std::string LongDesc = "";
-  if (Desc.end() == false)
+  std::vector PkgDescriptions;
+  if (NamesOnly == false)
   {
-	 pkgRecords::Parser  = records.Lookup(Desc.FileList());
-	 LongDesc = parser.LongDesc();
+ for (auto Desc = V.TranslatedDescription(); Desc.end() == false; ++Desc)
+ {
+pkgRecords::Parser  = records.Lookup(Desc.FileList());
+PkgDescriptions.push_back(parser.LongDesc());
+ }
   }
 
-  bool all_found = true;
-  for (std::vector::const_iterator pattern = Patterns.begin();
-	pattern != Patterns.end(); ++pattern)
+  bool all_found = false;
+
+  char const * const PkgName = P.Name();
+  for (std::string const : PkgDescriptions)
   {
-	 if (regexec(&(*pattern), PkgName, 0, 0, 0) == 0)
-	continue;
-	 else if (NamesOnly == false && regexec(&(*pattern), LongDesc.c_str(), 0, 0, 0) == 0)
-	continue;
-	 // search patterns are AND, so one failing fails all
-	 all_found = false;
-	 break;
+ all_found = true;
+
+ for (std::vector::const_iterator pattern = Patterns.begin();
+  pattern != Patterns.end(); ++pattern)
+ {
+if (regexec(&(*pattern), PkgName, 0, 0, 0) == 0)
+   continue;
+else if (NamesOnly == false && regexec(&(*pattern), PkgDesc.c_str(), 0, 0, 0) == 0)
+   continue;
+// search patterns are AND, so one failing fails all
+all_found = false;
+break;
+ }
+
+ if (all_found == true)
+break;
   }
+
   if (all_found == true)
   {
 	 PkgsDone[P->ID] = true;
@@ -172,6 +184,7 @@ static void LocalitySort(pkgCache::DescFile ** const begin, unsigned long long c
 struct ExDescFile
 {
pkgCache::DescFile *Df;
+   pkgCache::DescIterator D;
pkgCache::VerIterator V;
map_id_t ID;
ExDescFile() : Df(nullptr), ID(0) {}
@@ -254,6 +267,7 @@ static bool Search(CommandLine )
 	 if (D.end() == true)
 	continue;
 	 DFList[G->ID].Df = D.FileList();
+	 DFList[G->ID].D = D;
 	 DFList[G->ID].V = V;
 	 DFList[G->ID].ID = G->ID;
   }
@@ -274,6 +288,7 @@ static bool Search(CommandLine )
 	 if (D.end() == true)
 	continue;
 	 DFList[id].Df = D.FileList();
+	 DFList[id].D = D;
 	 DFList[id].V = V;
 	 DFList[id].ID = id;
 
@@ -290,19 +305,20 @@ static bool Search(CommandLine )
// Iterate over all the version records and check them
for (ExDescFile *J = DFList; J->Df != 0; ++J)
{
-  pkgRecords::Parser  = Recs.Lookup(pkgCache::DescFileIterator(*Cache,J->Df));
   size_t const PatternOffset = J->ID * NumPatterns;
-
   if (NamesOnly == false)
   {
-	 std::string const LongDesc = P.LongDesc();
-	 for (unsigned I = 0; I < NumPatterns; ++I)
-	 {
-	if (PatternMatch[PatternOffset + I] == true)
-	   continue;
-	else if (regexec([I],LongDesc.c_str(),0,0,0) == 0)
-	   PatternMatch[PatternOffset + I] = true;
-	 }
+ for (auto Desc = J->D; Desc.end() == false; ++Desc)
+ {
+std::string const LongDesc = Recs.Lookup(Desc.FileList()).LongDesc();
+for (unsigned I = 0; I < NumPatterns; ++I)
+{
+   if (PatternMatch[PatternOffset + I] == true)
+  continue;
+   else if (regexec([I], LongDesc.c_str(), 0, 0, 0) == 0)
+  PatternMatch[PatternOffset + I] = true;
+}
+   

Bug#940618: mark libmapbox-variant-dev Multi-Arch: foreign

2019-09-17 Thread Helmut Grohne
Package: libmapbox-variant-dev
Version: 1.1.6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:node-mapnik src:python-mapnik src:mapnik src:viking

The affected packages fail to satisfy their cross Build-Depends, because
their (transitive) dependency on libmapbox-variant-dev is unsatisfiably.
In general, Architecture: all packages can never satisfy cross build
dependencies unless marked Multi-Arch: foreign or annotated :native. In
this case, the foreign marking is appropriate, because
libmapbox-variant-dev is a header-only library that entirely lacks
dependencies and maintainer scripts. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru mapbox-variant-1.1.6/debian/changelog 
mapbox-variant-1.1.6/debian/changelog
--- mapbox-variant-1.1.6/debian/changelog   2019-07-07 08:35:09.0 
+0200
+++ mapbox-variant-1.1.6/debian/changelog   2019-09-17 22:16:36.0 
+0200
@@ -1,3 +1,10 @@
+mapbox-variant (1.1.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark libmapbox-variant-dev Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 17 Sep 2019 22:16:36 +0200
+
 mapbox-variant (1.1.6-1) unstable; urgency=medium
 
   * Update gbp.conf to use --source-only-changes by default.
diff --minimal -Nru mapbox-variant-1.1.6/debian/control 
mapbox-variant-1.1.6/debian/control
--- mapbox-variant-1.1.6/debian/control 2018-12-25 22:33:55.0 +0100
+++ mapbox-variant-1.1.6/debian/control 2019-09-17 22:16:34.0 +0200
@@ -15,6 +15,7 @@
 
 Package: libmapbox-variant-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Description: Alternative to boost::variant for C++11
  Mapbox variant has the same speedy performance of boost::variant but is


Bug#940619: brotli should be buildable without python

2019-09-17 Thread Helmut Grohne
Source: brotli
Version: 1.0.7-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:curl

curl recently gained a build dependency on libbrotli-dev. This means,
that brotli is now required for architecture bootstrap. We'll need to be
able to build brotli without having python available. This is typically
implemented using the nopython build profile. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru brotli-1.0.7/debian/changelog brotli-1.0.7/debian/changelog
--- brotli-1.0.7/debian/changelog   2019-01-07 23:11:10.0 +0100
+++ brotli-1.0.7/debian/changelog   2019-09-17 22:15:21.0 +0200
@@ -1,3 +1,10 @@
+brotli (1.0.7-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Support the nopython build profile. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 17 Sep 2019 22:15:21 +0200
+
 brotli (1.0.7-2) unstable; urgency=medium
 
   * Refresh packaging (std-ver, compat=12)
diff --minimal -Nru brotli-1.0.7/debian/control brotli-1.0.7/debian/control
--- brotli-1.0.7/debian/control 2019-01-07 23:11:10.0 +0100
+++ brotli-1.0.7/debian/control 2019-09-17 22:12:40.0 +0200
@@ -6,13 +6,13 @@
 Build-Depends: cmake,
debhelper (>= 12),
debhelper-compat (= 12),
-   dh-python,
-   python,
-   python-dev,
-   python-setuptools,
-   python3,
-   python3-all-dev,
-   python3-setuptools
+   dh-python ,
+   python ,
+   python-dev ,
+   python-setuptools ,
+   python3 ,
+   python3-all-dev ,
+   python3-setuptools ,
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/debian/brotli
 Vcs-Git: https://salsa.debian.org/debian/brotli.git
@@ -20,6 +20,7 @@
 
 Package: python-brotli
 Architecture: any
+Build-Profiles: 
 Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
 Description: lossless compression algorithm and format (Python 2 version)
  Brotli is a generic-purpose lossless compression algorithm
@@ -33,6 +34,7 @@
 
 Package: python3-brotli
 Architecture: any
+Build-Profiles: 
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Description: lossless compression algorithm and format (Python 3 version)
  Brotli is a generic-purpose lossless compression algorithm
diff --minimal -Nru brotli-1.0.7/debian/rules brotli-1.0.7/debian/rules
--- brotli-1.0.7/debian/rules   2018-02-03 08:56:52.0 +0100
+++ brotli-1.0.7/debian/rules   2019-09-17 22:15:19.0 +0200
@@ -6,6 +6,7 @@
 
 export PYBUILD_NAME = brotli
 
+ifeq (,$(filter nopython,$(DEB_BUILD_PROFILES)))
 %:
dh $@ --buildsystem=pybuild --with=python2,python3
 
@@ -28,6 +29,10 @@
 override_dh_auto_test:
dh_auto_test
dh_auto_test --buildsystem=cmake
+else
+%:
+   dh $@ --buildsystem=cmake
+endif
 
 override_dh_install:
find debian/tmp -name '*.a' -print -delete


Bug#940620: brotli FTCBFS: python-ish Build-Depends not installable

2019-09-17 Thread Helmut Grohne
Source: brotli
Version: 1.0.7-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

brotli fails to cross build from source, because its python-ish
Build-Depends are not installable. It requests the host architecture
python, which fails postinst. What it really needs is a runnable python
interpreter and host architecture python libraries. This usally amounts
to replacing python-something with libpython-something plus
python-something:any. Indeed, doing so makes brotli cross buildable.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru brotli-1.0.7/debian/changelog brotli-1.0.7/debian/changelog
--- brotli-1.0.7/debian/changelog   2019-01-07 23:11:10.0 +0100
+++ brotli-1.0.7/debian/changelog   2019-09-17 22:06:18.0 +0200
@@ -1,3 +1,10 @@
+brotli (1.0.7-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Multiarchify python Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 17 Sep 2019 22:06:18 +0200
+
 brotli (1.0.7-2) unstable; urgency=medium
 
   * Refresh packaging (std-ver, compat=12)
diff --minimal -Nru brotli-1.0.7/debian/control brotli-1.0.7/debian/control
--- brotli-1.0.7/debian/control 2019-01-07 23:11:10.0 +0100
+++ brotli-1.0.7/debian/control 2019-09-17 22:06:16.0 +0200
@@ -7,11 +7,13 @@
debhelper (>= 12),
debhelper-compat (= 12),
dh-python,
-   python,
-   python-dev,
+   python:any,
+   libpython-dev,
+   python-dev:any,
python-setuptools,
-   python3,
-   python3-all-dev,
+   python3:any,
+   libpython3-all-dev,
+   python3-all-dev:any,
python3-setuptools
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/debian/brotli


Bug#940606: new upstream (2.6.3)

2019-09-17 Thread Andreas Tille
Control: tags -1 help

On Tue, Sep 17, 2019 at 08:01:53PM +0200, Daniel Baumann wrote:
> it would be nice if you could upgrade to current igv version 2.6.3. the
> current version in unstable is (apart from the other issues) so old,
> it's hardly usable.

I agree and its work in progress

   https://lists.debian.org/debian-med/2019/09/msg00087.html

If you have any idea how to fix the build in Git[1] this would
be more than welcome.

Thanks for your interest in the package anyway

Andreas.

[1] https://salsa.debian.org/med-team/igv

-- 
http://fam-tille.de



Bug#875184: Help needed for medical imaging framework sofa (Was: Bug#875184: [sofa-framework] Future Qt4 removal from Buster)

2019-09-17 Thread Andreas Tille
On Tue, Sep 17, 2019 at 01:26:17PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> 
> Is the embedded stuff all in extlibs/? or is there some other 3rdparty code?

A lot is excluded in advance from the packaging Git:

Files-Excluded: */libQGLViewer*
*/csparse
*/gtest
*/qwt*
*/eigen-3*
*/newmat
*/extlibs/json
*/tinyxml
*/*.dll
*/*.lib
*/SuiteSparse

Some of these previously resided in SofaKernel/extlibs before
the removal.

Hope this helps

  Andreas.

-- 
http://fam-tille.de



Bug#940617: ITP: r-cran-qgraph -- GNU R graph plotting methods and psychometric data visualization

2019-09-17 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-qgraph -- GNU R graph plotting methods and psychometric 
data visualization
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-qgraph
  Version : 1.6.3
  Upstream Author : Sacha Epskamp,
* URL : https://cran.r-project.org/package=qgraph
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R graph plotting methods and psychometric data 
visualization
 This GNU R package provides graph plotting methods, psychometric data
 visualization and graphical model estimation functions based on
 weighted network visualization and analysis, as well as Gaussian graphical
 model computation. See Epskamp et al. (2012) .

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-qgraph



Bug#940615: Logs

2019-09-17 Thread Tony Middleton
Here is the end of the log from grub-install

grub-install: info: Registering with EFI: distributor = `debian', path =
`\EFI\debian\shimx64.efi', ESP at mduuid/a6fcec628151c509d2bd0ab56b8e5c15.
grub-install: info: executing modprobe efivars 2>/dev/null.
grub-install: warning: efivarfs_get_variable:
open(/sys/firmware/efi/efivars/blk0-47c7b225-c42a-11d2-8e57-00a0c969723b):
No such file or directory.
grub-install: warning: efi_get_variable: ops->get_variable failed: No
such file or directory.
grub-install: warning: efi_va_generate_file_device_path_from_esp: could
not open device for ESP: Bad address.
grub-install: warning: efi_generate_file_device_path_from_esp: could not
generate File DP from ESP: Bad address.
grub-install: error: failed to register the EFI boot entry: Bad address.


And here the log from apt

root@thistle:~# apt full-upgrade
Reading package lists... Done
Building dependency tree  
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up shim-signed-common (1.33+15+1533136590.3beb971-7) ...
Installing for x86_64-efi platform.
grub-install: warning: efivarfs_get_variable:
open(/sys/firmware/efi/efivars/blk0-47c7b225-c42a-11d2-8e57-00a0c969723b):
No such file or directory.
grub-install: warning: efi_get_variable: ops->get_variable failed: No
such file or directory.
grub-install: warning: efi_va_generate_file_device_path_from_esp: could
not open device for ESP: Bad address.
grub-install: warning: efi_generate_file_device_path_from_esp: could not
generate File DP from ESP: Bad address.
grub-install: error: failed to register the EFI boot entry: Bad address.
dpkg: error processing package shim-signed-common (--configure):
 installed shim-signed-common package post-installation script
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of shim-signed:amd64:
 shim-signed:amd64 depends on shim-signed-common (=
1.33+15+1533136590.3beb971-7); however:
  Package shim-signed-common is not configured yet.

dpkg: error processing package shim-signed:amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 shim-signed-common
 shim-signed:amd64
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)



Bug#940611: fails to start because no wrapper missing

2019-09-17 Thread Daniel Baumann
tag 940611 + patch
thanks

here's a patch:
https://git.progress-linux.org/distributions/engywuck/packages/beagle/commit/?id=dfd229f18e861f5107091be55b82770e961dd7dd

Regards,
Daniel



Bug#940615: grub-efi-amd64: On upgrade to buster apt fails to install shim-signed-common and shim-signed due to grub-install fail

2019-09-17 Thread Tony
Package: grub-efi-amd64
Version: 2.02+dfsg1-20
Severity: important

Dear Maintainer,

I have just upgraded to buster.  apt full-upgrade failed.  Subsequently
further use of apt fails so I don't seem able to make further changes
with apt,  such as purge removed packages.  It appears that the problem
is in install-grub which is failing.

I suspect this is a problem I have had on earlier releases where
grub-install failed because I have the efi partition on raid 0.  However
on previous versions although grub-install did not complete it did not
return an error so software calling it continued.  This meant that apt
could continue.

Will post logs of apt and grub-install separately.

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/md3 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/md1 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
/dev/mapper/VGT-africa /vol/africa ext4 rw,relatime 0 0
/dev/mapper/VGT-offsite /vol/offsite ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/6ba89e9a1c2d0b18aa28937c8156ea9f'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='mduuid/6ba89e9a1c2d0b18aa28937c8156ea9f'  
daf603fa-df99-4e6a-bc67-02cac7ca2fde
else
  search --no-floppy --fs-uuid --set=root daf603fa-df99-4e6a-bc67-02cac7ca2fde
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_GB
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-daf603fa-df99-4e6a-bc67-02cac7ca2fde' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/6ba89e9a1c2d0b18aa28937c8156ea9f'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='mduuid/6ba89e9a1c2d0b18aa28937c8156ea9f'  
daf603fa-df99-4e6a-bc67-02cac7ca2fde
else
  search --no-floppy --fs-uuid --set=root 
daf603fa-df99-4e6a-bc67-02cac7ca2fde
fi
echo'Loading Linux 4.19.0-6-amd64 ...'
linux   /boot/vmlinuz-4.19.0-6-amd64 
root=UUID=daf603fa-df99-4e6a-bc67-02cac7ca2fde ro  quiet
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-4.19.0-6-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-daf603fa-df99-4e6a-bc67-02cac7ca2fde' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-6-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.19.0-6-amd64-advanced-daf603fa-df99-4e6a-bc67-02cac7ca2fde' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi

Bug#940614: gdm3: GDM doesn't start (I see flickering on the console a few times until it decides it has failed)

2019-09-17 Thread Stefan Monnier
Package: gdm3
Version: 3.30.2-3
Severity: important

Dear Maintainer,

After the upgrade to Buster, I'm unable to get GDM3 working on this system (a 
thinkpad X201s).
It fails at start.  I tried to change /etc/gdm3/daemon.conf to prevent use of 
Wayland,
but it made no noticeable difference.

I can start `xinit` from a root console login and it successfully launches the 
X xserver and the xterm.
I haven't found anything in the logs which gave me any hint at the origin of 
the problem (e.g.
the Xorg log in /var/lib/gdm3 doesn't have any EE lines, AFAICT).


Stefan


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.45-2
ii  adduser   3.118
ii  ctwm [x-window-manager]   3.7-4+b1
ii  dconf-cli 0.30.1-2
ii  dconf-gsettings-backend   0.30.1-2
ii  debconf [debconf-2.0] 1.5.71
ii  gir1.2-gdm-1.03.30.2-3
ii  gnome-session [x-session-manager] 3.30.1-2
ii  gnome-session-bin 3.30.1-2
ii  gnome-settings-daemon 3.30.2-3
ii  gnome-shell   3.30.2-9
ii  gnome-terminal [x-terminal-emulator]  3.30.2-2
ii  gsettings-desktop-schemas 3.28.1-1
ii  libaccountsservice0   0.6.45-2
ii  libaudit1 1:2.8.4-3
ii  libc6 2.28-10
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libgdm1   3.30.2-3
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libglib2.0-bin2.58.3-2+deb10u1
ii  libgtk-3-03.24.5-1
ii  libkeyutils1  1.6-6
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd241-7~deb10u1
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.44.10-2.1
ii  libselinux1   2.8-1+b1
ii  libsystemd0   241-7~deb10u1
ii  libwrap0  7.6.q-28
ii  libx11-6  2:1.6.7-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.13.1-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  10.2019051400
ii  metacity [x-window-manager]   1:3.30.1-2
ii  mutter [x-window-manager] 3.30.2-7
ii  policykit-1   0.105-25
ii  procps2:3.3.15-2
ii  ucf   3.0038+nmu1
ii  wmaker [x-window-manager] 0.95.8-3
ii  x11-common1:7.7+19
ii  x11-xserver-utils 7.7+8
ii  xfce4-session [x-session-manager] 4.12.1-6
ii  xfce4-terminal [x-terminal-emulator]  0.8.7.4-2
ii  xfwm4 [x-window-manager]  4.12.5-1
ii  xterm [x-terminal-emulator]   344-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.30.0-7
ii  desktop-base10.0.2
ii  x11-xkb-utils   7.7+4
ii  xserver-xephyr  2:1.20.4-1
ii  xserver-xorg1:7.7+19
ii  zenity  3.30.0-2

Versions of packages gdm3 suggests:
ii  gnome-orca3.30.1-1
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.28.2-5

-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: gdm3



Bug#939015: buster-pu: package akonadi/4:18.08.3-5

2019-09-17 Thread Sandro Knauß
Fixed version number to make version smaller than the version in sid:
akonadi/4:18.08.3-7~deb10u1

hefeediff -Nru akonadi-18.08.3/debian/changelog akonadi-18.08.3/debian/changelog
--- akonadi-18.08.3/debian/changelog	2019-04-29 16:24:10.0 +0200
+++ akonadi-18.08.3/debian/changelog	2019-08-30 22:11:22.0 +0200
@@ -1,3 +1,34 @@
+akonadi (4:18.08.3-7~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster.
+
+ -- Sandro Knauß   Fri, 30 Aug 2019 22:11:22 +0200
+
+akonadi (4:18.08.3-7) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Sandro Knauß ]
+  * Add patch to fix: Akonadi components crash on logout. (Closes: #939013)
+  * Add patch to fix: Automatic recovery from Multiple Merge Candidates
+error (Closes: #939012)
+  * Add patch with files, that are needed for other patches.
+  * Update symbols from buildds for 4:18.08.3
+
+ -- Sandro Knauß   Fri, 30 Aug 2019 12:59:47 +0200
+
+akonadi (4:18.08.3-6) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Sandro Knauß ]
+  * Fix "Akonadi don't anwser any requests and ends in deadlock" (Closes: #935981)
+by adding upstream patches.
+- Akonadi-fix-dangling-transaction-after-itemsync-fail.patch
+- ItemSync-skip-handling-remote-items-if-local-changes.patch
+
+ -- Sandro Knauß   Wed, 28 Aug 2019 19:31:31 +0200
+
 akonadi (4:18.08.3-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru akonadi-18.08.3/debian/libkf5akonadiagentbase5.symbols akonadi-18.08.3/debian/libkf5akonadiagentbase5.symbols
--- akonadi-18.08.3/debian/libkf5akonadiagentbase5.symbols	2019-02-08 23:19:51.0 +0100
+++ akonadi-18.08.3/debian/libkf5akonadiagentbase5.symbols	2019-08-30 12:58:59.0 +0200
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 4:18.07.90 amd64
+# SymbolsHelper-Confirmed: 4:18.08.3 alpha amd64 arm64 armel armhf hppa hurd-i386 i386 m68k mips64el mipsel ppc64 ppc64el riscv64 s390x x32
 libKF5AkonadiAgentBase.so.5 libkf5akonadiagentbase5 #MINVER#
 * Build-Depends-Package: libkf5akonadi-dev
  _ZN7Akonadi12ResourceBase10cancelTaskERK7QString@Base 4:15.07.90
@@ -197,7 +197,6 @@
  _ZNK7Akonadi9AgentBase8isOnlineEv@Base 4:15.07.90
  _ZNK7Akonadi9AgentBase8progressEv@Base 4:15.07.90
  _ZNK7Akonadi9AgentBase9agentNameEv@Base 4:15.07.90
- (optional=templinst)_ZSt4swapIN7Akonadi10CollectionEENSt9enable_ifIXsrSt6__and_IJSt6__not_ISt15__is_tuple_likeIT_EESt21is_move_constructibleIS6_ESt18is_move_assignableIS6_EEE5valueEvE4typeERS6_SG_@Base 4:18.07.90
  _ZTI12QDBusContext@Base 4:15.07.90
  _ZTIN7Akonadi12ResourceBaseE@Base 4:15.07.90
  _ZTIN7Akonadi16PreprocessorBaseE@Base 4:15.07.90
diff -Nru akonadi-18.08.3/debian/libkf5akonadicore5abi2.symbols akonadi-18.08.3/debian/libkf5akonadicore5abi2.symbols
--- akonadi-18.08.3/debian/libkf5akonadicore5abi2.symbols	2019-02-13 19:42:05.0 +0100
+++ akonadi-18.08.3/debian/libkf5akonadicore5abi2.symbols	2019-08-30 12:58:21.0 +0200
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 4:18.08.3 alpha amd64 arm64 armel armhf hppa hurd-i386 i386 mips mips64el mipsel powerpc ppc64 ppc64el s390x
+# SymbolsHelper-Confirmed: 4:18.08.3 alpha amd64 arm64 armel armhf hppa hurd-i386 i386 m68k mips mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x x32
 libKF5AkonadiCore.so.5abi2 libkf5akonadicore5abi2 #MINVER#
 * Build-Depends-Package: libkf5akonadi-dev
  ABI_5_2@ABI_5_2 4:18.07.90
@@ -27,7 +27,8 @@
  _ZN7Akonadi10Collection7fromUrlERK4QUrl@ABI_5_2 4:18.07.90
  _ZN7Akonadi10Collection7setNameERK7QString@ABI_5_2 4:18.07.90
  _ZN7Akonadi10Collection8mimeTypeEv@ABI_5_2 4:18.07.90
- (optional=templinst|arch=hurd-i386 i386 m68k)_ZN7Akonadi10Collection9attributeINS_25PersistentSearchAttributeEEEPT_NS0_12CreateOptionE@ABI_5_2 4:18.07.90
+ (optional=templinst|arch=!mips !powerpc)_ZN7Akonadi10Collection9attributeINS_22EntityDisplayAttributeEEEPT_NS0_12CreateOptionE@ABI_5_2 4:18.08.3
+ (optional=templinst|arch=alpha amd64 arm64 armel armhf hppa hurd-i386 i386 m68k mips64el mipsel ppc64 ppc64el riscv64 s390x x32)_ZN7Akonadi10Collection9attributeINS_25PersistentSearchAttributeEEEPT_NS0_12CreateOptionE@ABI_5_2 4:18.07.90
  _ZN7Akonadi10Collection9setRightsE6QFlagsINS0_5RightEE@ABI_5_2 4:18.07.90
  _ZN7Akonadi10CollectionC1ERKS0_@ABI_5_2 4:18.07.90
  _ZN7Akonadi10CollectionC1Ev@ABI_5_2 4:18.07.90
@@ -1597,7 +1598,7 @@
  _ZN7Akonadi9UnlinkJobD2Ev@ABI_5_2 4:18.07.90
  _ZN9QHashData9hasShrunkEv@ABI_5_2 4:18.07.90
  (optional=templinst)_ZNK12KConfigGroup9readEntryIxEE5QListIT_EPKcRKS3_@ABI_5_2 4:18.07.90
- (optional=templinst|arch=alpha hppa mips64el ppc64 ppc64el s390x)_ZNK12KConfigGroup9readEntryIxEET_PKcRKS1_@ABI_5_2 4:18.07.90
+ (optional=templinst|arch=alpha hppa mips64el ppc64 ppc64el riscv64 s390x)_ZNK12KConfigGroup9readEntryIxEET_PKcRKS1_@ABI_5_2 4:18.07.90
  _ZNK7Akonadi10Collection10attributesEv@ABI_5_2 4:18.07.90
  _ZNK7Akonadi10Collection10referencedEv@ABI_5_2 4:18.07.90
  _ZNK7Akonadi10Collection10shouldListENS0_11ListPurposeE@ABI_5_2 4:18.07.90
@@ -1620,7 +1621,9 @@
  _ZNK7Akonadi10Collection8remoteIdEv@ABI_5_2 

Bug#940613: ITP: GNU poke -- An interactive, extensible editor for binary data

2019-09-17 Thread Sergio Durigan Junior
Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: poke
  Version : 0.1-beta
  Upstream Author : Jose E. Marchesi
* URL : http://www.jemarch.net/poke.html
* License : GPL-3+
  Programming Lang: C
  Description : GNU poke -- An interactive, extensible editor for binary 
data

 GNU poke is an interactive, extensible editor for binary data. Not
 limited to editing basic entities such as bits and bytes, it provides a
 full-fledged procedural, interactive programming language designed to
 describe data structures and to operate on them.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature


Bug#940612: gnome-shell: JS ERROR: TypeError: Clutter.Animates is undefined

2019-09-17 Thread Harshula
Package: gnome-shell
Version: 3.34.0-1
Severity: important

Gnome-shell can hang when the Activities Overview is triggered.

Upstream bug: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1616

Upstream fix:
https://gitlab.gnome.org/fmuellner/gnome-shell/commit/817aec5466eeccf9d00fc1e69b4b77f1aebf44fd

cya,
#



Bug#940611: fails to start because no wrapper missing

2019-09-17 Thread Daniel Baumann
Package: beagle
Version: 5.0-180928+dfsg-1
Severity: serious

Hi,

beagle is written in java and shipped as /usr/share/beagle/beagle.jar
with 0644 permissions.

/usr/bin/beagle is a symlink to above jar. Starting it fails, as the jar
is not executable.

However, even if it would be executable, it woudln't work as jars are
not binaries to be executed directly in the first place. Something like
this should be used as /usr/bin/beagle instead of the symlink:

---snip---
#!/bin/sh

set -e

java -jar /usr/share/beagle/beagle.jar ${@}
---snap---

Regards,
Daniel



Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure

2019-09-17 Thread Jan Kowalsky
Hi again,

Am 17.09.19 um 18:02 schrieb Mike Gabriel:
> Hi,
> completing the story...
> 
> During package upgades, I see upgrade failures:
> 
> ```
> root@jessie:~# apt-get install 389-ds-base --reinstall
> Paketlisten werden gelesen... Fertig
> Abhängigkeitsbaum wird aufgebaut.
> Statusinformationen werden eingelesen Fertig
> 0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen
> und 0 nicht aktualisiert.
> Es müssen noch 0 B von 1.459 kB an Archiven heruntergeladen werden.
> Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
> (Lese Datenbank ... 137483 Dateien und Verzeichnisse sind derzeit
> installiert.)
> Vorbereitung zum Entpacken von
> .../389-ds-base_1.3.3.5-4+deb8u6_amd64.deb ...
> Entpacken von 389-ds-base (1.3.3.5-4+deb8u6) über (1.3.3.5-4+deb8u6) ...
> Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
> Trigger für systemd (215-17+deb8u13) werden verarbeitet ...
> 389-ds-base (1.3.3.5-4+deb8u6) wird eingerichtet ...
> dpkg: Fehler beim Bearbeiten des Paketes 389-ds-base (--configure):
>  Unterprozess installiertes post-installation-Skript gab den Fehlerwert
> 1 zurück
> Fehler traten auf beim Bearbeiten von:
>  389-ds-base
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> ```

I've reported this bug in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905184

But unfortunately it doesn't seemed to be backported to lts. In stretch
it is fixed.

Great that you did now also for jessie.

Kind regards
Jan



Bug#940578: printer-driver-cups-pdf: cups pdf printer cannot create pdf file

2019-09-17 Thread Martin-Éric Racine
This very much seems like an issue caused by AppArmor. Reassigned.

Martin-Éric


ti 17. syysk. 2019 klo 16.45 Rudolf Polzer (rudolf.pol...@i-r-p.de) kirjoitti:
>
> Package: printer-driver-cups-pdf
> Version: 3.0.1-5
> Severity: normal
>
>
>
> -- System Information:
> Debian Release: 10.0
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages printer-driver-cups-pdf depends on:
> ii  cups2.2.10-6
> ii  cups-client 2.2.10-6
> ii  ghostscript 9.27~dfsg-2
> ii  libc6   2.28-10
> ii  libcups22.2.10-6
> ii  libpaper-utils  1.1.28
>
> printer-driver-cups-pdf recommends no packages.
>
> Versions of packages printer-driver-cups-pdf suggests:
> pn  system-config-printer  
>
> -- Configuration Files:
> /etc/cups/cups-pdf.conf changed:
> Out ${HOME}/Transport
> Grp lpadmin
> DecodeHexStrings 1
>
>
> -- no debconf information
>
>
> -- audit error message:
> audit[11578]: AVC apparmor="DENIED" operation="mknod" 
> profile="/usr/lib/cups/backend/cups-pdf" 
> name="/home/rudi/Transport/home_rudi_Transport.pdf" pid=11578 comm="gs" 
> requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
>



Bug#940317: Re : Bug#940317: hplip: No more printing

2019-09-17 Thread Brian Potkin
tags 940317 - moreinfo
reassign 940317 printer-driver-hpcups
merge 940317 932246
thanks



On Mon 16 Sep 2019 at 21:05:45 +0200, nicolas.patr...@gmail.com wrote:

> In fact I have four ppd files (three for the 5534, one for the 4780).
> HP_ENVY_5530_series_AFD037_.ppd in 5830_1_* files.
> HP_ENVY_5530_series_AFD037_.ppd.O in 5830_2_* files.
> HP-ENVY-5530-series.ppd in 5830_3_* files.
> HP-Photosmart-C4700-series.ppd in 4700_* files.

Thanks for the logs. Two of them show

  *** stack smashing detected ***:  terminated
  ERROR: hpcups (PID 25874) crashed on signal 6

The message appears to be from gcc (it is in its source code), but I
haven't any idea where to go with this. You should be able to get the
5534 printing using driverless printing. See the wiki.

Cheers,

Brian.



Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure

2019-09-17 Thread Jan Kowalsky
Hi Mike,


Am 17.09.19 um 17:38 schrieb Mike Gabriel:
> What I did:
>
> 1. Setup a fresh 389-ds instance using jessie's original version
> (see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/)
>
> 2. Upgrade to +deb8u4, test login, LDAP queries, etc.
>
> -> worked
>
> 3. Upgrade to +deb8u5, test login, LDAP queries, etc.
>
> -> worked
>
> 4. Upgrade to +deb8u6, test login, LDAP queries, etc.
>
> -> worked
>
> Can you be any chance provide more info about this issue? What exactly
> are the LDAP queries, that Nextcloud does on your 389-ds server?

unfortunately not. It was an setup we don't have any more, we updated
nextcloud and moved to an newer ldap version. And in fact at that time I
couldn't figure out the exact problem since the queries worked when I
provided them via ldapsearch command line.

My notes about the error where:

nextcloud-log:

root@nextcloud:/etc# tail -f /srv/ncdata/nextcloud-demo/nextcloud.log
{"reqId":"U7vRHqej7uRmeA2JsBIf","level":3,"time":"2018-10-26T16:26:40+00:00","remoteAddr":"88.198.xx.xxx","user":"--","app":"PHP","method":"POST","url":"\/login?redirect_url=\/apps\/files\/%3Fdir%3D\/%26fileid%3D955=demo%40example.org","message":"ldap_control_paged_result_response():
Result is: Protocol error (2) at
\/opt\/nextcloud-demo\/apps\/user_ldap\/lib\/LDAP.php#74","userAgent":"Mozilla\/5.0
(X11; Linux x86_64; rv:52.0) Gecko\/20100101
Firefox\/52.0","version":"14.0.3.0"}

Note the: "Protocol error (2)"

When we encountered the bug we had an replication of multiple ldap
servers with slightly different versions:

Access log of the ldap server with 389-ds version 1.3.3.5-4+deb8u3:

[26/Oct/2018:16:32:41.929490646 +] conn=5364586 op=0 BIND
dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=org" method=128
version=3
[26/Oct/2018:16:32:41.929803839 +] conn=5364586 op=0 RESULT err=0
tag=97 nentries=0 etime=0 dn="uid=owncloud-bind,ou=special
users,dc=example,dc=org"
[26/Oct/2018:16:32:41.987048655 +] conn=5364586 op=1 SRCH
base="dc=example,dc=org" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))"
attrs="entryuuid nsUniqueId objectguid guid ipauniqueid
distinguishedName uid samaccountname memberOf   mail displayName
jpegPhoto thumbnailphoto"
[26/Oct/2018:16:32:41.987905862 +] conn=5364586 op=1 RESULT err=0
tag=101 nentries=1 etime=0 notes=P pr_idx=0 pr_cookie=-1
[26/Oct/2018:16:32:42.459561451 +] conn=5364586 op=2 UNBIND
[26/Oct/2018:16:32:42.459584128 +] conn=5364586 op=2 fd=825 closed - U1

Access log at the other one with 389-ds version 1.3.5.17-2:

[26/Oct/2018:18:29:19 +0200] conn=66 op=0 BIND
dn="uid=owncloud-bind,ou=Special Users,dc=example,dc=org" method=128
version=3
[26/Oct/2018:18:29:19 +0200] conn=66 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn="uid=owncloud-bind,ou=special users,dc=example,dc=org"
[26/Oct/2018:18:29:19 +0200] conn=66 op=1 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=d...@example.org)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=1 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:19 +0200] conn=66 op=2 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=2 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:19 +0200] conn=66 op=3 SRCH base="(null)" scope=2
filter="(&(|(objectClass=inetorgperson))(|(mail=1d0b3c01-fd3f11e4-a213ad4c-cdc1d3d2)))",
invalid attribute request
[26/Oct/2018:18:29:19 +0200] conn=66 op=3 RESULT err=2 tag=101
nentries=0 etime=0
[26/Oct/2018:18:29:32 +0200] conn=66 op=4 UNBIND
[26/Oct/2018:18:29:32 +0200] conn=66 op=4 fd=279 closed - U1

there ist an search base with "null" in access log. But this seems to
happen on the server side. Providing the same query on command line worked.

> Can anyone else give feedback about 389-ds in jessie LTS? Any observed
> problems that look similar to #912224 [1]?

Maybe we've been the only who where affected.

Kind regards
Jan



Bug#932883: RFS: dmagnetic/0.16-1 [put in ITP, ITA, RC, NMU if applicable]

2019-09-17 Thread Thomas Dettbarn


 
 
  
   Heloo Adam!
  
  
   Thank you sooo much for answering my call.
  
  
   To answer the biggest question: The game data is not freely licensable. I asked the original developers. 
  
  
   
  
  
   As for your question regarding the graphics: guild and pawn should run without the need to type in GRAPHICS to see some output. Could you send me the complete commandline you used?
  
  
   
  
  
   Please also try running 'dMagnetic -mag guild.mag -gfx guild.gfx -vmode monochrome' If that does not work, there might be a bug. I usually change the .ini file to get the games running. 
  
  
   
  
  
   The debhelper thingie is something i will fix once i have access to a computer.. currently i only have a cellphone to write this. Sorry. 
  
  
   
  
  
   Would you be my sponsor?
  
  
   
  
  
   
Adam Borowski <
kilob...@angband.pl> hat am 15. September 2019 um 20:46 geschrieben:
   
   

   
   

   
   
On Wed, Jul 24, 2019 at 08:30:49AM +0200, Thomas Dettbarn wrote:
   
   

 * Package name : dmagnetic


 Version : 0.16-1


 Upstream Author : Thomas Dettbarn <
 det...@dettus.net>


 * URL : 
 http://www.dettus.net/dMagnetic


 * License : BSD-2clause


 Section : games

   
   

 It builds those binary packages:


 dmagnetic - A Magnetic Scrolls Interpreter

   
   
Hi!
   
   
First, the big question: is there are freely licensed data for this
   
   
interpreter? If not, the package will have to go into contrib rather than
   
   
main: it's a section for free stuff that requires non-free to function.
   
   

   
   
The package lacks build-depends on debhelper 12: you use compat 12 yet have
   
   
"Build-Depends: debhelper (>=9)". Also, nowadays there's a better way to
   
   
express that: "Build-Depends: debhelper-compat (=12)".
   
   

   
   
The package installs LICENSE.txt (redundant with copyright) and README.txt
   
   
(redundant with the long desc of the package).
   
   

   
   
After having downloaded game data, I get no graphics. The command
   
   
"graphics" switches between text only and text + a line with lightgray
   
   
background + a lot of empty space. I've tried two games: "pawn" and
   
   
"guild", passing -gfx and -mag each time.
   
   

   
   
The .menu file is obsolete, most desktop environments don't support it
   
   
anymore, and those which do are hardly maintained.
   
   

   
   

   
   
Meow!
   
   
--
   
   
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
   
   
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
   
   
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
   
   
⠈⠳⣄ etc), let the drink age at least 3-6 months.
   
   
 




Bug#940610: gimp: segmentation fault

2019-09-17 Thread Marcelo Luiz de Laia
Package: gimp
Version: 2.10.8-2+b1
Severity: normal

GIMP crashed with a fatal error: segmentation fault


GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-
languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-
gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-
libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror --with-
arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-
driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-
gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20190827 (Debian 9.2.1-6)

using GEGL version 0.4.12 (compiled against version 0.4.14)
using GLib version 2.60.6 (compiled against version 2.60.6)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.1)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Falha de segmentação

Stack trace:
```
/usr/lib/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x398)[0x7f6b62950f98]
gimp-2.10(+0xd1590)[0x556060d95590]
gimp-2.10(+0xd19b8)[0x556060d959b8]
gimp-2.10(+0xd2029)[0x556060d96029]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13510)[0x7f6b61c8a510]
gimp-2.10(gimp_gegl_mask_is_empty+0x91)[0x556061180411]
gimp-2.10(+0x3b7810)[0x55606107b810]
gimp-2.10(+0x42ec18)[0x5560610f2c18]
gimp-2.10(+0x3d5b50)[0x556061099b50]
gimp-2.10(+0x42f2aa)[0x5560610f32aa]
gimp-2.10(gimp_drawable_set_buffer_full+0x1cb)[0x5560610989bb]
gimp-2.10(gimp_drawable_set_buffer+0x11d)[0x556061098f9d]
gimp-2.10(gimp_drawable_new+0x106)[0x556061099296]
gimp-2.10(gimp_layer_new+0x90)[0x5560610f64d0]
gimp-2.10(+0x3319cc)[0x556060ff59cc]
gimp-2.10(gimp_procedure_execute+0x237)[0x55606102e577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x556061027a39]
gimp-2.10(gimp_plug_in_handle_message+0x216)[0x556061032626]
gimp-2.10(+0x36cf91)[0x556061030f91]
/usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0(g_main_context_dispatch+0x158)[0x7f6b61e30898]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4ec88)[0x7f6b61e30c88]
/usr/lib/x86_64-linux-
gnu/libglib-2.0.so.0(g_main_loop_run+0xb2)[0x7f6b61e30f82]
gimp-2.10(gimp_plug_in_manager_call_run+0x5fc)[0x55606104235c]
gimp-2.10(+0x376dbe)[0x55606103adbe]
gimp-2.10(gimp_procedure_execute+0x237)[0x55606102e577]
gimp-2.10(gimp_pdb_execute_procedure_by_name_args+0x1e9)[0x556061027a39]
gimp-2.10(gimp_pdb_execute_procedure_by_name+0x3cd)[0x556061027efd]
gimp-2.10(file_open_image+0x33d)[0x5560611286fd]
gimp-2.10(file_open_with_proc_and_display+0x29d)[0x55606112964d]
gimp-2.10(file_open_from_command_line+0x1b4)[0x556061129eb4]
gimp-2.10(app_run+0x304)[0x556060d94d14]
gimp-2.10(main+0x36e)[0x556060d9464e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb)[0x7f6b61ad]
gimp-2.10(_start+0x2a)[0x556060d947da]

```



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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.8-2
ii  libaa1   1.4p5-46+b1
ii  libbabl-0.1-00.1.62-1
ii  libbz2-1.0   1.0.8-2
ii  libc62.29-1
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-8
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgegl-0.4-00.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2+b1
ii  libglib2.0-0 2.60.6-2
ii  libgs9   9.27~dfsg-3.1
ii  libgtk2.0-0  2.24.32-3
ii  

Bug#876178: two years minus two days

2019-09-17 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2019-09-17 at 14:13 +0200, Geert Stappers wrote:
> bugreport is now open for almost two years, in two days exactly two years.
> 
> a patch is one year old.
> 
> 
> What will happen with this issue?

Hi,

sorry noone replied sooner (I seem to remember a different issue where this
was discussed, but can't remember which one right now). I'm a bit reluctant to
add the recommends because last time I checked gvfs-backends brought a lot of
dependencies and it's not really useful for browsing local filesystems.

Having it installed by default and forcing bizarre backends on all users
systems is not nice,

Also, gvfs by itself only Suggests it, which look like the right thing to do.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2BJzoACgkQ3rYcyPpX
RFv5Kwf/WosaZN2yLueydzBNg7t2a+ZjNMwsriIhzwl/i0ffLamRBL7pS/2+zwn/
GFKzLACA9Fp/ghtaJVzeShXHZKai/oECWD5iH4HEhq2O+3Q0j/GMX9kQAv0WHWOZ
+MrK470Rk9Q740yNTw68oztiKmLeSAhNrQRZTjteOXSRd9LWB7vCl6S0ZEgSmL8v
GLdRda+wUTgNN9Ecj50gm5WLO77MMGXqETXSg+m9/MV+DzRBju9AQ4AACvjPsHk5
7Bc5jsbI7U06bomVJ2xOWqNYgufB4C02HiJnHkfItJkPrY7cqRi+lrdIYxn/uOPs
1juJf81e7WJxo6rAIMR5ju5v9l4mKg==
=m1D0
-END PGP SIGNATURE-



Bug#939824: [Pkg-clamav-devel] Bug#939824: add meta package

2019-09-17 Thread Sebastian Andrzej Siewior
On 2019-09-11 09:23:24 [+0200], Matus UHLAR - fantomas wrote:
> > On September 9, 2019 10:03:13 AM UTC, Matus UHLAR - fantomas 
> >  wrote:
> > > Please, add meta package pointing to current libclamunrar.
> 
> On 10.09.19 16:02, Sebastian Andrzej Siewior wrote:
> > Do you have an example how that should look like? I can't add package to 
> > main which has a recommends or depends on a package in contrib or non-free, 
> > see:
> >  
> > https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_debian_is_100_free_software
> 
> I believe that the dependency from libclamav could stay at Suggests: level,
> adding new metapackage:
> 
> Suggests: libclamunrar9, libclamunrar
> 
> while libclamunrar would have hard Depends: libclamunrar
> 
> Depends: libclamunrar9

Sounds good, this would work.

Sebastian



Bug#875029: Ping!

2019-09-17 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2019-09-17 at 13:29 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> I'm terribly sorry if we are being pushy here, it is indeed with no
> bad faith and we definitely don't want to annoy anyone. And yes, we
> are targeting at removing qt4 from testing as soon as possible. Don't
> worry, we will leave this package until it's the only blocker left.
> 
> Again, sorry if it annoyed you, no bad faith here :-)

There's no big deal, but I already replied to Moritz and on this bug
*yesterday* that I'll take a look at it.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl2BJPEACgkQ3rYcyPpX
RFsgnggAlK2hzacRyd//Zpfv8cnEfjax3tt2PFCXa3AnzOEzRmWrvCphhW5uc5GQ
gayj0XGAxDOY2Ve/Cr11Ius9K75KTTe44gb7tNt1M4IsFwxHiJ2wOlnhA46J16wK
xSAkuvnpyZcobPnecV00cjsIieZBBnHDvVdvOM6a8wJRQ31pTw+G1G4pc6zPlgat
cmAia+egrletB1lpYUKfIZRlI4pGvPk55HU6gHMijAzbjSxk6o55Ww0ROe1vsYVp
513LAo1IaQbW7MgmmrCAYYwGji9Xrx9LPEBG0L+B4p/hkN1zy/WpbwdtrbP9DkOy
ZDu12/pzUIzSOqSHLLvSRN6Z3vGyYQ==
=546A
-END PGP SIGNATURE-



Bug#940229: uses killall in logrotate snippet

2019-09-17 Thread Roger Light
Thank you. The more recent systemd unit files already include the HUP
command. I have changed the logrotate command to use invoke-rc.d as
per your suggestion. I have done this for the new 1.6.6 upload I've
just sent to mentors. In terms of updating stable, I haven't had much
luck with that in the past. I'm neither a DD nor DM and have in the
past been advised that only security updates are appropriate for
stable, so am a bit stuck there.

On Sat, 14 Sep 2019 at 10:21, Peter Palfrader  wrote:
>
> Package: mosquitto
> Version: 1.5.7-1
> Severity: important
>
> Regarding severity, see [1].
>
> | root@raven:~# systemctl --failed
>   | UNIT  LOAD   ACTIVE SUBDESCRIPTION
> | ● logrotate.service loaded failed failed Rotate log files
>
> | root@raven:~# journalctl -u logrotate.service
> | -- Logs begin at Fri 2019-09-13 13:14:46 CEST, end at Sat 2019-09-14 
> 10:46:55 CEST. --
> | Sep 14 00:00:01 raven systemd[1]: Starting Rotate log files...
> | Sep 14 00:00:02 raven logrotate[17281]: logrotate_script: 2: 
> logrotate_script: /usr/bin/killall: not found
> | Sep 14 00:00:02 raven logrotate[17281]: error: error running non-shared 
> postrotate script for /var/log/mosquitto/mosquitto.log of 
> '/var/log/mosquitto/mosquitto.log '
> | Sep 14 00:00:02 raven systemd[1]: logrotate.service: Main process exited, 
> code=exited, status=1/FAILURE
> | Sep 14 00:00:02 raven systemd[1]: logrotate.service: Failed with result 
> 'exit-code'.
>
> So, there's a few things wrong with this logrotate setup:
>
> | root@raven:~# grep -A1 postro /etc/logrotate.d/mosquitto
> | postrotate
> | /usr/bin/killall -HUP mosquitto
>
> First, you should never use killall (or pkill) to send signals to
> processes by name out of system scripts.  You may only send things to
> your processes, and you don't control which other things on the system
> might be called mosquitto.
>
> Second, *if* you use killall, you need to ensure it's actually
> installed.  killall is shipped by the psmisc package, which is not
> Essential, yet the mosquitto packages doesn't depend on it.  Further,
> the postrotate snippet probably should NOT supply the full path to the
> script[2].
>
> However, what the script probably should do is reload its service using
> something like apache2 does:
> |   postrotate
> |   if invoke-rc.d apache2 status > /dev/null 2>&1; then \
> |   invoke-rc.d apache2 reload > /dev/null 2>&1; \
> |   fi;
> |   endscript
>
> This will call the service's reload thing.  Your sysV init script
> already correctly sends a HUP only to the service process.  It seems
> the systemd service file doesn't.  I don't know if this is the proper
> way to deal with this issue but the following should work:
>
> @@ -8,6 +8,7 @@
>  Type=notify
>  NotifyAccess=main
>  ExecStart=/usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
> +ExecReload=/bin/kill -HUP ${MAINPID}
>  Restart=on-failure
>
>  [Install]
>
>
> Cheers,
>
> PS: please consider updating the version in stable.
>
> Cheers,
> 1: This could be serious, since "Packages must include a "Depends:" line
>listing any other packages they require for operation", but then it's
>"just" logrotation.  Either way, please fix :)
> 2: | Programs called from maintainer scripts should not normally have a
>| path prepended to them.  [...] These considerations really apply to
>| all shell scripts.
>
>
> --
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/



Bug#940609: ITP: r-cran-bdgraph -- GNU R bayesian structure learning in graphical models

2019-09-17 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-bdgraph -- GNU R bayesian structure learning in graphical 
models
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-bdgraph
  Version : 2.61
  Upstream Author : Reza Mohammadi,
* URL : https://cran.r-project.org/package=BDgraph
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R bayesian structure learning in graphical models
 Statistical tools for Bayesian structure learning in undirected
 graphical models for continuous, discrete, and mixed data. The package
 is implemented the recent improvements in the Bayesian graphical models
 literature, including Mohammadi and Wit (2015) ,
 Mohammadi and Wit (2019) .

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-bdgraph



Bug#940608: freeradius: Init script does not stop service when using sysvinit

2019-09-17 Thread Roel van Meer
Package: freeradius
Version: 3.0.17+dfsg-1.1
Severity: normal
Tags: patch

Dear Maintainer,

when using sysvinit instead of systemd, calling the init script with
argument 'stop' does not stop the service. It seems in the invocation of
killproc the program name is missing.

Attached you should find a patch that fixes this problem.

Thanks for your work,

Roel
diff -pru a/debian/freeradius.init b/debian/freeradius.init
--- a/debian/freeradius.init2019-04-22 23:23:36.0 +0200
+++ b/debian/freeradius.init2019-09-17 19:54:37.926055502 +0200
@@ -62,7 +62,7 @@ case "$1" in
 stop)
 log_daemon_msg "Stopping $DESCR" "$PROG"
 
-killproc -p "$PIDFILE" || ret=$?
+killproc -p "$PIDFILE" "$PROG" || ret=$?
 log_end_msg $ret
 ;;
 


Bug#940607: ldap2dns FTCBFS: many reasons

2019-09-17 Thread Helmut Grohne
Source: ldap2dns
Version: 0.3.1-3.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ldap2dns fails to cross build from source for multiple reasons. For
starters, debian/rules fails to pass cross tools to make. Then the
upstream Makefile stuffs flags into the CC variable which get lost when
dh_auto_build substitutes it. Further down, it has a copy of CC called
LD, which doesn't get substituted. It lists -l flags as Makefile
dependencies. Doing so works fine during native compilation, because
make has an architecture-dependent search path. This is why make is not
marked Multi-Arch: foreign. Such dependencies do break cross building
and need to be avoided. Close to the end it strips with the build
architecture strip during make install. Beyond breaking cross
compilation, this breaks generation of -dbgsym packages as well as
DEB_BUILD_OPTIONS=nostrip (aka #437301). The attached patch fixes all of
that (including #437301).

Helmut
diff -u ldap2dns-0.3.1/Makefile ldap2dns-0.3.1/Makefile
--- ldap2dns-0.3.1/Makefile
+++ ldap2dns-0.3.1/Makefile
@@ -1,12 +1,14 @@
 # $Id: Makefile,v 1.29 2002/08/02 15:19:36 jrief Exp $ 
 VERSION=0.3.1
 RELEASE=1
-CC=gcc -O2
-CCDEBUG=gcc -g
+CC=gcc
+CCRELEASE=$(CC) -O2
+CCDEBUG=$(CC) -g
 CFLAGS=$(INC) -DVERSION='"$(VERSION)"'
 LIBS=-lldap -llber
-LD=gcc 
+LD=$(CC)
 LDFLAGS=
+INSTALL ?= install
 INSTALL_PREFIX=
 PREFIXDIR=$(INSTALL_PREFIX)/usr
 LDAPCONFDIR=$(INSTALL_PREFIX)/etc/ldap
@@ -15,17 +17,17 @@
 
 all: ldap2dns ldap2dnsd ldap2dns-dbg
 
-ldap2dns: ldap2dns.o $(LIBS) 
-   $(LD) $(LDFLAGS) -o $@ $+
+ldap2dns: ldap2dns.o $(filter-out -l%,$(LIBS))
+   $(LD) $(LDFLAGS) -o $@ $+ $(filter -l%,$(LIBS))
 
 ldap2dnsd: ldap2dns
ln -sf ldap2dns ldap2dnsd
 
-ldap2dns-dbg: ldap2dns.o-dbg $(LIBS) 
-   $(LD) $(LDFLAGS) -o $@ $+
+ldap2dns-dbg: ldap2dns.o-dbg $(filter-out -l%,$(LIBS))
+   $(LD) $(LDFLAGS) -o $@ $+ $(filter -l%,$(LIBS))
 
 ldap2dns.o: ldap2dns.c
-   $(CC) $(CFLAGS) -c $< -o $@
+   $(CCRELEASE) $(CFLAGS) -c $< -o $@
 
 ldap2dns.o-dbg: ldap2dns.c
$(CCDEBUG) $(CFLAGS) -c $< -o $@
@@ -33,16 +35,16 @@
 install: all
mkdir -p $(PREFIXDIR)/bin
mkdir -p $(LDAPCONFDIR)
-   install -s -o root -g root -m 755 ldap2dns $(PREFIXDIR)/bin/
+   $(INSTALL) -s -o root -g root -m 755 ldap2dns $(PREFIXDIR)/bin/
#ln -sf $(PREFIXDIR)/bin/ldap2dns $(PREFIXDIR)/bin/ldap2dnsd
-   install -o root -g root -m 755 ldap2tinydns-conf $(PREFIXDIR)/bin/
+   $(INSTALL) -o root -g root -m 755 ldap2tinydns-conf $(PREFIXDIR)/bin/

# OpenLDAP2
-   install -o root -g root -m 644 dns.schema $(LDAPCONFDIR)/schema/
+   $(INSTALL) -o root -g root -m 644 dns.schema $(LDAPCONFDIR)/schema/

# OpenLDAP1
-   #install -o root -g root -m 644 dns.at.conf $(LDAPCONFDIR)/
-   #install -o root -g root -m 644 dns.oc.conf $(LDAPCONFDIR)/
+   #$(INSTALL) -o root -g root -m 644 dns.at.conf $(LDAPCONFDIR)/
+   #$(INSTALL) -o root -g root -m 644 dns.oc.conf $(LDAPCONFDIR)/

# README.txt
links -dump README.html > README.txt
diff -u ldap2dns-0.3.1/debian/changelog ldap2dns-0.3.1/debian/changelog
--- ldap2dns-0.3.1/debian/changelog
+++ ldap2dns-0.3.1/debian/changelog
@@ -1,3 +1,10 @@
+ldap2dns (0.3.1-3.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix cross building. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 16 Sep 2019 17:42:12 +0200
+
 ldap2dns (0.3.1-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u ldap2dns-0.3.1/debian/rules ldap2dns-0.3.1/debian/rules
--- ldap2dns-0.3.1/debian/rules
+++ ldap2dns-0.3.1/debian/rules
@@ -14,7 +14,7 @@
 build: configure-stamp build-stamp
 build-stamp:
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch build-stamp
 
 clean:
@@ -29,7 +29,7 @@
dh_testroot
dh_clean -k
dh_installdirs
-   $(MAKE) install INSTALL_PREFIX=$(CURDIR)/debian/ldap2dns
+   $(MAKE) install INSTALL_PREFIX=$(CURDIR)/debian/ldap2dns 
INSTALL='install --strip-program=true'
 
 # Build architecture-independent files here.
 binary-indep: build install


Bug#782952: python-pyramid-zcml: diff for NMU version 1.0.0-1.1

2019-09-17 Thread Andrey Rahmatullin
Control: tags 782952 + patch
Control: tags 782952 + pending

Dear maintainer,

I've prepared an NMU for python-pyramid-zcml (versioned as 1.0.0-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
WBR, wRAR
diff -Nru python-pyramid-zcml-1.0.0/debian/changelog python-pyramid-zcml-1.0.0/debian/changelog
--- python-pyramid-zcml-1.0.0/debian/changelog	2013-06-06 15:06:42.0 +0600
+++ python-pyramid-zcml-1.0.0/debian/changelog	2019-09-17 22:37:08.0 +0500
@@ -1,3 +1,14 @@
+python-pyramid-zcml (1.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from Python 2 to Python 3 (Closes: #782952).
+  * Add support for Python 3.7.
+  * Add support for Pyramid 1.8 and other modern libs.
+  * Disable tests using mako as pyramid_mako is not packaged.
+  * Update the priority from extra to optional.
+
+ -- Andrey Rahmatullin   Tue, 17 Sep 2019 22:37:08 +0500
+
 python-pyramid-zcml (1.0.0-1) unstable; urgency=low
 
   * New upstream release
diff -Nru python-pyramid-zcml-1.0.0/debian/control python-pyramid-zcml-1.0.0/debian/control
--- python-pyramid-zcml-1.0.0/debian/control	2012-05-03 19:35:31.0 +0600
+++ python-pyramid-zcml-1.0.0/debian/control	2019-09-17 22:36:13.0 +0500
@@ -1,14 +1,18 @@
 Source: python-pyramid-zcml
 Section: python
-Priority: extra
+Priority: optional
 Maintainer: Free Ekanayaka 
-Build-Depends: debhelper (>= 7.0.50~), python-setuptools, python-all (>= 2.6.6-3)
+Build-Depends: debhelper (>= 7.0.50~), dh-python, python3-all,
+  python3-setuptools,
+  python3-pyramid,
+  python3-webtest,
+  python3-zope.configuration,
 Standards-Version: 3.9.3
 Homepage: http://pypi.python.org/pypi/pyramid_zcml
 
-Package: python-pyramid-zcml
+Package: python3-pyramid-zcml
 Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${python3:Depends}, ${misc:Depends}
 Description: Declarative configuration for the Pyramid web framework
  The pyramid_zcml package provides ZCML (Zope Configuration Markup Language)
  directives for all "configurator" methods available in the Pyramid web
diff -Nru python-pyramid-zcml-1.0.0/debian/patches/fix-authkit.patch python-pyramid-zcml-1.0.0/debian/patches/fix-authkit.patch
--- python-pyramid-zcml-1.0.0/debian/patches/fix-authkit.patch	1970-01-01 05:00:00.0 +0500
+++ python-pyramid-zcml-1.0.0/debian/patches/fix-authkit.patch	2019-09-17 22:01:00.0 +0500
@@ -0,0 +1,24 @@
+From d041694f77215dcb692b65d33ab0ad64b07135f0 Mon Sep 17 00:00:00 2001
+From: Tres Seaver 
+Date: Wed, 4 Feb 2015 12:25:02 -0500
+Subject: [PATCH] Accomodate updated AuthTkt.
+
+---
+ pyramid_zcml/tests/test_units.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/pyramid_zcml/tests/test_units.py b/pyramid_zcml/tests/test_units.py
+index a53d398..24b8941 100644
+--- a/pyramid_zcml/tests/test_units.py
 b/pyramid_zcml/tests/test_units.py
+@@ -372,8 +372,8 @@ def callback(identity, request):
+ reg.registerUtility(object(), IAuthorizationPolicy)
+ _execute_actions(actions)
+ policy = reg.getUtility(IAuthenticationPolicy)
+-self.assertEqual(policy.cookie.path, '/sub/')
+-self.assertEqual(policy.cookie.http_only, True)
++self.assertEqual(policy.cookie.cookie_profile.path, '/sub/')
++self.assertEqual(policy.cookie.cookie_profile.httponly, True)
+ self.assertEqual(policy.cookie.secret, 'sosecret')
+ self.assertEqual(policy.callback, callback)
+ 
diff -Nru python-pyramid-zcml-1.0.0/debian/patches/fix-path.patch python-pyramid-zcml-1.0.0/debian/patches/fix-path.patch
--- python-pyramid-zcml-1.0.0/debian/patches/fix-path.patch	1970-01-01 05:00:00.0 +0500
+++ python-pyramid-zcml-1.0.0/debian/patches/fix-path.patch	2019-09-17 22:35:35.0 +0500
@@ -0,0 +1,23 @@
+From c32e7ee71c631a68206989055d027cee91a5021f Mon Sep 17 00:00:00 2001
+From: Tres Seaver 
+Date: Tue, 8 Jan 2019 14:14:08 -0500
+Subject: [PATCH] Module's '__path__' is supposed to be a list ot strings, or
+ None.
+
+---
+ pyramid_zcml/tests/test_units.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pyramid_zcml/tests/test_units.py b/pyramid_zcml/tests/test_units.py
+index 2048aa1..7f1e438 100644
+--- a/pyramid_zcml/tests/test_units.py
 b/pyramid_zcml/tests/test_units.py
+@@ -1227,7 +1227,7 @@ def __call__(self):
+ """ """
+ 
+ class DummyModule:
+-__path__ = "foo"
++__path__ = ["foo"]
+ __name__ = "dummy"
+ __file__ = ''
+ scanned = False
diff -Nru python-pyramid-zcml-1.0.0/debian/patches/fix-pyramid-1.8-2.patch python-pyramid-zcml-1.0.0/debian/patches/fix-pyramid-1.8-2.patch
--- python-pyramid-zcml-1.0.0/debian/patches/fix-pyramid-1.8-2.patch	1970-01-01 05:00:00.0 +0500
+++ python-pyramid-zcml-1.0.0/debian/patches/fix-pyramid-1.8-2.patch	2019-09-17 22:05:24.0 +0500
@@ -0,0 +1,86 @@
+From 7357d01b7d5815d2451b44ff3d03ef251d652e92 Mon Sep 17 

Bug#940606: new upstream (2.6.3)

2019-09-17 Thread Daniel Baumann
Package: igv

Hi,

it would be nice if you could upgrade to current igv version 2.6.3. the
current version in unstable is (apart from the other issues) so old,
it's hardly usable.

Regards,
Daniel



Bug#936399: diodon: Python2 removal in sid/bullseye

2019-09-17 Thread Oliver Sauder
I currently do not have a lot of time at hand. So if you could follow up 
releasing your NMU debdiff that would be great (diff looks good to me).


Oliver

On 01.09.19 09:18, Scott Kitterman wrote:

On Fri, 30 Aug 2019 07:15:05 + Matthias Klose  wrote:

Package: src:diodon
Version: 1.8.0-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.


I've attached a fix in the form of an NMU debdiff.  I don't currently plan to
NMU, but may later if this remains open.  Please fix.

Scott K





Bug#940603: upstream bug report

2019-09-17 Thread cage
FWIW I have found this bug report upstream:

https://dev.gajim.org/gajim/gajim/issues/9790

Bye!
C.



Bug#940605: libjbig2dec0: breaks mupdf with message "undefined symbol: jbig2_ctx_new"

2019-09-17 Thread Jörg-Volker Peetz
Package: libjbig2dec0
Version: 0.16+20190905-2
Severity: normal

Dear Maintainer,

this version and the previous version 0.16+20190905-1 break mupdf which
crashes with message "undefined symbol: jbig2_ctx_new".

Regards,
Jörg.


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

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

Versions of packages libjbig2dec0 depends on:
ii  libc6  2.29-1

libjbig2dec0 recommends no packages.

libjbig2dec0 suggests no packages.

-- no debconf information



Bug#940604: dhcpig depends on cruft package.

2019-09-17 Thread peter green

Package: dhcpig
Version: 1.5-2
Severity: serious
Tags: bullseye, sid

dhcpig depends on python-scapy which is no longer built by the scapy source 
package.

If you want your package to remain around you probably need to migrate to 
python 3.



Bug#940333: RFH: python-click

2019-09-17 Thread Alexandre Viau
On 2019-09-16 8:20 p.m., Sandro Tosi wrote:
> Hey Alexandre,
>
> On Sun, 15 Sep 2019 17:01:07 -0400 Alexandre Viau  wrote:
>> Package: wnpp
>> Severity: normal
>>
>> Hello,
>>
>> I haven't had a lot of time to put into python-click lately.
>>
>> I am thinking that moving it to the python packaging team could be a
>> good idea. I am not familiar with the python team's processes, so that
>> would be without my help.
> id be happy to move it under the DPMT umbrella
>
>> If you want to take over python-click, as part of a team or not, you are
>>  welcome!
> want me to keep you as uploaders or you're ok with me taking over? i
> dont mind either way :)


I am okay with you taking over!

Thanks for offering to help!

Cheers,


-- 
Aleaxandre Viau
av...@debian.org




signature.asc
Description: OpenPGP digital signature


Bug#940603: gajim-omemo: Gajim on testing fails to start, reporting problem with omemo plugin

2019-09-17 Thread cage
Package: gajim-omemo
Version: 2.6.27-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Starting gajim fails with the stacktrace listed below, gajim freezes and became 
unusable.

---8<8<---8<

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gajim/application.py", line 221, in 
_activate
self.interface.run(self)
  File "/usr/lib/python3/dist-packages/gajim/gui_interface.py", line 2551, in 
run
app.plugin_manager.init_plugins()
  File "/usr/lib/python3/dist-packages/gajim/plugins/helpers.py", line 114, in 
wrapper
result = f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gajim/plugins/pluginmanager.py", line 
176, in init_plugins
self._activate_all_plugins_from_global_config()
  File "/usr/lib/python3/dist-packages/gajim/plugins/pluginmanager.py", line 
544, in _activate_all_plugins_from_global_config
self.activate_plugin(plugin)
  File "/usr/lib/python3/dist-packages/gajim/plugins/helpers.py", line 114, in 
wrapper
result = f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/gajim/plugins/pluginmanager.py", line 
453, in activate_plugin
plugin.activate()
  File 
"/usr/lib/python3/dist-packages/gajim/./data/plugins/omemo/omemoplugin.py", 
line 176, in activate
self.connections[account] = OMEMOConnection(account, self)
  File 
"/usr/lib/python3/dist-packages/gajim/./data/plugins/omemo/omemo_connection.py",
 line 48, in __init__
self.omemo = self.__get_omemo()
  File 
"/usr/lib/python3/dist-packages/gajim/./data/plugins/omemo/omemo_connection.py",
 line 97, in __get_omemo
return OmemoState(self.own_jid, conn, self.account, self)
  File 
"/usr/lib/python3/dist-packages/gajim/./data/plugins/omemo/omemo/state.py", 
line 65, in __init__
self.store = LiteAxolotlStore(db_con)
  File 
"/usr/lib/python3/dist-packages/gajim/./data/plugins/omemo/omemo/liteaxolotlstore.py",
 line 57, in __init__
self._generate_axolotl_keys()
  File 
"/usr/lib/python3/dist-packages/gajim/./data/plugins/omemo/omemo/liteaxolotlstore.py",
 line 62, in _generate_axolotl_keys
preKeys = KeyHelper.generatePreKeys(KeyHelper.getRandomSequence(),
TypeError: getRandomSequence() missing 1 required positional argument: 'max'

---8<8<---8<

Thank you!

Bye!
c.

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

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

Versions of packages gajim-omemo depends on:
ii  gajim  1.1.3-2
ii  python3-axolotl0.2.3-3
ii  python3-cryptography   2.6.1-3
ii  python3-pkg-resources  41.2.0-1

Versions of packages gajim-omemo recommends:
ii  python3-qrcode  6.1-1

gajim-omemo suggests no packages.

-- no debconf information



Bug#940467: Bug #940467 is a duplicate of #940204 - SORRY!

2019-09-17 Thread Andreas Beckmann
Control: close -1
Control: merge 940204 -1

On Mon, 16 Sep 2019 06:54:35 +0200 "news [at] Schiermeier-IT"
 wrote:
> I'm sorry to tell you that I did a mistake: I filed again the
> bug #940204 by accident!

No problem, closing and merging.


Andreas



Bug#939687: Help needed

2019-09-17 Thread Lisandro Damián Nicanor Pérez Meyer
tag 939687 + help
thanks

Hi! I'm afraid I'll need help with this one. -latomic is being passed, but it is
still failing to build when it previously did. The only change was clang itself
(and I wonder why clang is not automatically passing -latomic, as the arch seems
to need it).

Any help will be aprecciated.

Thanks!



Bug#940602: mate-desktop: multi-monitor has icons misplaced and not on the screen with the panels

2019-09-17 Thread Erich Minderlein
Package: mate-desktop
Version: 1.20.4-2
Severity: important

Dear Maintainer,

   * What led up to the situation?
   I have a secondary monitor left of the main monitor.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 panels are on the (right) main monitor , icons are on the left monitor
 run this script : 
#!/bin/bash
# $0 moves Icons to the other screen

wmctrl -r ${WINDOW_SHORT} -b remove,maximize_vert,maximize_horz
wmctrl -r ${WINDOW_SHORT} -e 400,1440,30,1024,770
wmctrl -r ${WINDOW_SHORT} -b add,maximize_vert,maximize_horz
   * What was the outcome of this action?
   Icons are on the (right) main panel
   however ; script must be run manually and not automatically
   * What outcome did you expect instead?
   have the Icons automatically in the correct place


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

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

Versions of packages mate-desktop depends on:
ii  hicolor-icon-theme0.17-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2+deb10u1
ii  libgtk-3-03.24.5-1
ii  libmate-desktop-2-17  1.20.4-2
ii  libpango-1.0-01.42.4-7~deb10u1
ii  libpangocairo-1.0-0   1.42.4-7~deb10u1
ii  libstartup-notification0  0.12-6
ii  libxrandr22:1.5.1-1
ii  mate-desktop-common   1.20.4-2

Versions of packages mate-desktop recommends:
ii  mate-user-guide  1.20.2-1

Versions of packages mate-desktop suggests:
ii  mate-desktop-environment  1.20.0+5

-- debconf-show failed



Bug#782951: python-pyramid-tm: diff for NMU version 0.5-1.1

2019-09-17 Thread Andrey Rahmatullin
Control: tags 782951 + patch
Control: tags 782951 + pending

Dear maintainer,

I've prepared an NMU for python-pyramid-tm (versioned as 0.5-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
WBR, wRAR
diff -Nru python-pyramid-tm-0.5/debian/changelog python-pyramid-tm-0.5/debian/changelog
--- python-pyramid-tm-0.5/debian/changelog	2012-09-03 01:50:39.0 +0600
+++ python-pyramid-tm-0.5/debian/changelog	2019-09-17 21:22:59.0 +0500
@@ -1,3 +1,11 @@
+python-pyramid-tm (0.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch from Python 2 to Python 3 (Closes: #782951).
+  * Update the priority from extra to optional.
+
+ -- Andrey Rahmatullin   Tue, 17 Sep 2019 21:22:59 +0500
+
 python-pyramid-tm (0.5-1) unstable; urgency=low
 
   * New upstream release
diff -Nru python-pyramid-tm-0.5/debian/control python-pyramid-tm-0.5/debian/control
--- python-pyramid-tm-0.5/debian/control	2012-05-20 13:37:22.0 +0600
+++ python-pyramid-tm-0.5/debian/control	2019-09-17 21:12:12.0 +0500
@@ -1,14 +1,17 @@
 Source: python-pyramid-tm
 Section: python
-Priority: extra
+Priority: optional
 Maintainer: Free Ekanayaka 
-Build-Depends: debhelper (>= 7.0.50~), python-setuptools, python-all (>= 2.6.6-3)
+Build-Depends: debhelper (>= 7.0.50~), dh-python, python3-all,
+  python3-setuptools,
+  python3-pyramid,
+  python3-transaction,
 Standards-Version: 3.9.3
 Homepage: http://pypi.python.org/pypi/pyramid_tm
 
-Package: python-pyramid-tm
+Package: python3-pyramid-tm
 Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
+Depends: ${python3:Depends}, ${misc:Depends}
 Description: Transaction management for the Pyramid web framework
  The pyramid_tm package allows Pyramid requests to join the active
  transaction as provided by the transaction package.
diff -Nru python-pyramid-tm-0.5/debian/rules python-pyramid-tm-0.5/debian/rules
--- python-pyramid-tm-0.5/debian/rules	2012-04-12 18:16:52.0 +0600
+++ python-pyramid-tm-0.5/debian/rules	2019-09-17 21:08:37.0 +0500
@@ -1,4 +1,4 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with python2
+	dh $@ --with python3 --buildsystem=pybuild


signature.asc
Description: PGP signature


Bug#940547: [Pkg-openssl-devel] Bug#940547: python-cryptography: Testsuite fails with OpenSSL 1.1.1d

2019-09-17 Thread Kurt Roeckx
On Tue, Sep 17, 2019 at 08:32:28AM +0200, Sebastian Andrzej Siewior wrote:
> Package: python-cryptography
> Version: 2.6.1-3
> Severity: serious
> 
> The upload of latest openssl 1.1.1d triggert three testsuite failures in
> python-cryptography [0]
> 
> - _ test_buffer_protocol_alternate_modes[mode5] 
> __
> 
> |mode =  0x7f0c8ceaba50>
> |backend =  0x7f0c95a29cd0>
> |
> |@pytest.mark.parametrize(
> |"mode",
> |[
> |modes.CBC(bytearray(b"\x00" * 16)),
> |modes.CTR(bytearray(b"\x00" * 16)),
> |modes.OFB(bytearray(b"\x00" * 16)),
> |modes.CFB(bytearray(b"\x00" * 16)),
> |modes.CFB8(bytearray(b"\x00" * 16)),
> |modes.XTS(bytearray(b"\x00" * 16)),
> |]
> |)
> |@pytest.mark.requires_backend_interface(interface=CipherBackend)
> |def test_buffer_protocol_alternate_modes(mode, backend):
> |data = bytearray(b"sixteen_byte_msg")
> |cipher = base.Cipher(
> |algorithms.AES(bytearray(b"\x00" * 32)), mode, backend
> |)
> |>   enc = cipher.encryptor()
> |
> |tests/hazmat/primitives/test_aes.py:495: 
> |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ _ 
> |/usr/lib/python2.7/dist-packages/cryptography/hazmat/primitives/ciphers/base.py:121:
>  in encryptor
> |self.algorithm, self.mode
> |/usr/lib/python2.7/dist-packages/cryptography/hazmat/backends/openssl/backend.py:295:
>  in create_symmetric_encryption_ctx
> |return _CipherContext(self, cipher, mode, _CipherContext._ENCRYPT)
> |/usr/lib/python2.7/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py:116:
>  in __init__
> |self._backend.openssl_assert(res != 0)
> |/usr/lib/python2.7/dist-packages/cryptography/hazmat/backends/openssl/backend.py:125:
>  in openssl_assert
> |return binding._openssl_assert(self._lib, ok)
> 
> This is due to commit 2a5f63c9a61be ("Allow AES XTS decryption using duplicate
> keys.").
> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2a5f63c9a61be

I'm guessing the commit message is a little bit misleading. I
think it now rejects it for encryption, but still allows it for
decryption. I think in the master branch we started with rejecting
both, and then allowed decryption again.

> 
> - _ TestDH.test_dh_parameters_supported 
> __
> 
> |self = 
> |backend =  0x7f0c95a29cd0>
> |
> |def test_dh_parameters_supported(self, backend):
> |assert backend.dh_parameters_supported(23, 5)
> |>   assert not backend.dh_parameters_supported(23, 18)
> |E   assert not True
> |E+  where True =   0x7f0c95a29cd0>>(23, 18)
> |E+where   0x7f0c95a29cd0>> =  object at 0x7f0c95a29cd0>.dh_parameters_supported
> |
> |tests/hazmat/primitives/test_dh.py:161: AssertionError
> 
> This is due to commit ddd16c2fe988e ("Change DH parameters to generate the
> order q subgroup instead of 2q").
> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=ddd16c2fe988e
> 
> - _ TestECDSACertificate.test_load_ecdsa_no_named_curve 
> __
> 
> |self = 
> |backend =  0x7f0c95a29cd0>
> |
> |def test_load_ecdsa_no_named_curve(self, backend):
> |_skip_curve_unsupported(backend, ec.SECP256R1())
> |cert = _load_cert(
> |os.path.join("x509", "custom", "ec_no_named_curve.pem"),
> |x509.load_pem_x509_certificate,
> |backend
> |)
> |with pytest.raises(NotImplementedError):
> |>   cert.public_key()
> |E   Failed: DID NOT RAISE 
> |
> |tests/x509/test_x509.py:3722: Failed
> 
> This is due to commit 9a43a733801bd ("[ec] Match built-in curves on
> EC_GROUP_new_from_ecparameters").
> https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a43a733801bd

So the no named curve test fails now because OpenSSL now compares
it to built-in curves, and uses the built-in curves instead if it
has the parameters of a known curve.

The commit has a very long message about why this is done. so I'll
just duplicate it here:

[ec] Match built-in curves on EC_GROUP_new_from_ecparameters

Description
---

Upon `EC_GROUP_new_from_ecparameters()` check if the parameters match any
of the built-in curves. If that is the case, return a new
`EC_GROUP_new_by_curve_name()` object instead of the explicit parameters
`EC_GROUP`.

This affects all users of `EC_GROUP_new_from_ecparameters()`:
- direct calls to `EC_GROUP_new_from_ecparameters()`
- direct calls to `EC_GROUP_new_from_ecpkparameters()` with an explicit
  parameters argument
- ASN.1 parsing of explicit parameters keys (as it eventually
  ends up calling `EC_GROUP_new_from_ecpkparameters()`)

A parsed explicit parameter key will still be marked with the
`OPENSSL_EC_EXPLICIT_CURVE` ASN.1 flag on load, so, unless
programmatically forced otherwise, if the key 

Bug#940601: logwatch depends on a mail agent, not always necessary

2019-09-17 Thread Erich Minderlein
Package: logwatch
Version: 7.5.3
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   installed logwatch
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 aptitude install logwatch
   * What was the outcome of this action?
   mail agent as nullmailer or exim gets pulled in

   * What outcome did you expect instead?
   do not need mail agent, as I operate locally, 



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

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

Versions of packages logwatch depends on:
pn  default-mta | mail-transport-agent  
ii  perl5.28.1-6

Versions of packages logwatch recommends:
pn  libdate-manip-perl   
pn  libsys-cpu-perl  
pn  libsys-meminfo-perl  

Versions of packages logwatch suggests:
pn  fortune-mod  



Bug#940599: ITP: r-cran-d3network -- GNU R tools for creating D3 JavaScript network, tree, dendrogram etc.

2019-09-17 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-d3network -- GNU R tools for creating D3 JavaScript 
network, tree, dendrogram etc.
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-d3network
  Version : 0.5.2.1
  Upstream Author : Christopher Gandrud
* URL : https://cran.r-project.org/package=d3Network
* License : GPL-3+
  Programming Lang: GNU R
  Description : GNU R tools for creating D3 JavaScript network, tree, 
dendrogram etc.
 This GNU R package contains tools for creating D3 JavaScript network,
 tree, dendrogram, and Sankey graphs.
 This package is intended to make it easy to create D3 JavaScript
 network, tree, dendrogram, and Sankey graphs from R using data frames.
 .
 NOTE: Active development has moved to the networkD3 package and was only
 packaged for the purpose to fulfill reverse dependencies of other R
 packages.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-d3network



Bug#940600: gcc-9: Please disable gm2 on hurd-i386 too

2019-09-17 Thread Samuel Thibault
Package: gcc-9
Version: 9.2.1-4
Severity: important
Tags: patch

Hello,

mc hangs on hurd-i386, could you disable m2 there as the attached patch
does?

Samuel

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

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

Versions of packages gcc-9 depends on:
ii  binutils  2.32.51.20190821-2
ii  cpp-9 9.2.1-4
ii  gcc-9-base9.2.1-4
ii  libc6 2.29-1
ii  libcc1-0  9.2.1-4
ii  libgcc-9-dev  9.2.1-4
ii  libgcc1   1:9.2.1-4
ii  libgmp10  2:6.1.2+dfsg-4
ii  libisl19  0.20-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++69.2.1-4
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages gcc-9 recommends:
ii  libc6-dev  2.29-1

Versions of packages gcc-9 suggests:
ii  gcc-9-doc 9.2.0-1
pn  gcc-9-locales 
ii  gcc-9-multilib9.2.1-4
pn  libasan5-dbg  
pn  libatomic1-dbg
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan1-dbg 

-- no debconf information

-- 
Samuel
 ça gaze ?
 prout
 -+- #ens-mim - ouvrez les fenêtres ! -+-
commit 5aabd4e720ac112f080aaca1e22e7de7887894d8
Author: Samuel Thibault 
Date:   Thu Sep 12 08:53:23 2019 +0200

Disable gm2 on hurd-i386, mc hangs there

diff --git a/debian/changelog b/debian/changelog
index 3e4df82..7700fdb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,13 @@
 gcc-9 (9.2.1-9) UNRELEASED; urgency=medium
 
+  [ Matthias Klose ]
   * Update to SVN 20190917 (r275806) from the gcc-9-branch.
 - Fix PR libstdc++/91748, PR rtl-optimization/89795, PR c++/91705,
   PR fortran/91557, PR fortran/91553, PR fortran/91566, PR fortran/91642.
 
+  [ Samuel Thibault ]
+  * Disable gm2 on hurd-i386, mc hangs there.
+
  -- Matthias Klose   Tue, 17 Sep 2019 17:10:04 +0200
 
 gcc-9 (9.2.1-8) unstable; urgency=medium
diff --git a/debian/rules.defs b/debian/rules.defs
index 54bad2a..dca283d 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -1195,7 +1195,7 @@ ifneq ($(with_base_only),yes)
 with_m2 := yes
   endif
 endif
-m2_no_archs = powerpc ppc64 sh4 x32 kfreebsd-amd64 kfreebsd-i386
+m2_no_archs = powerpc ppc64 sh4 x32 kfreebsd-amd64 kfreebsd-i386 hurd-i386
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(m2_no_archs)))
 with_m2 := disabled for cpu $(DEB_TARGET_ARCH)
 endif


Bug#875029: Ping!

2019-09-17 Thread Lisandro Damián Nicanor Pérez Meyer
Hi again!

On Tue, 17 Sep 2019 at 13:23, Yves-Alexis Perez  wrote:
>
> Yes I mind. I’m sorry my schedule doesn’t align with yours, but I honestly 
> don’t see the urgency here. I’m not asking you to wait for months, I’m just 
> trying to find some time to properly review and integrate Moritz patch. And 
> the way you push is a bit annoying right now. I’m sure it’s not intended, but 
> could you please slow down a bit?

I'm terribly sorry if we are being pushy here, it is indeed with no
bad faith and we definitely don't want to annoy anyone. And yes, we
are targeting at removing qt4 from testing as soon as possible. Don't
worry, we will leave this package until it's the only blocker left.

Again, sorry if it annoyed you, no bad faith here :-)

Thanks!



Bug#875184: Help needed for medical imaging framework sofa (Was: Bug#875184: [sofa-framework] Future Qt4 removal from Buster)

2019-09-17 Thread Lisandro Damián Nicanor Pérez Meyer
Hi!

On 19/09/12 09:40, Andreas Tille wrote:
> Control: tags -1 help
> 
> On Sun, Sep 08, 2019 at 11:00:34PM +0200, Moritz Mühlenhoff wrote:
> > On Sun, Sep 08, 2019 at 08:41:40AM +0200, Andreas Tille wrote:
> > > On Sat, Sep 07, 2019 at 10:43:53PM +0200, Moritz Mühlenhoff wrote:
> > > > 
> > > > The current releases on https://github.com/sofa-framework claim to be 
> > > > Qt5
> > > > compatible. Is anyone working on updating the package or should it be 
> > > > removed?
> > > > 
> > > > sofa-framework is one of the three remaining reverse dependencies of
> > > > libqwt5-qt4-dev at this point.
> > > 
> > > I tried to upgrade sofa-framework but had severe issues with new cmake
> > > configuration.  I'll have a look next week.
> > 
> > If you're stuck, feel free to ping #debian-qt-kde.
> 
> I need to admit I'm totally stuck with this package.  Yes, there is a
> new upstream version since a long time and I tried several times to
> update it in Git[1].  However, its basically a new packaging of a large
> package with the need for excluding several code copies of libraries.
> I took over the maintenance from a former uploader which left the team
> but I need to admit my time resources and interest in this package are
> quite sparse.
> 
> To have a chance to keep sofa-framework we need an expert in cmake who
> has some experience how to replace Debian packaged libraries.  I'd
> happily add any volunteer to the Debian Med team to give full commit
> permissions.  If nobody volunteers I do not see a realistic chance to
> keep that package.
> 
> Kind regards,
> 
> Andreas.

Is the embedded stuff all in extlibs/? or is there some other 3rdparty code?



Bug#875029: Ping!

2019-09-17 Thread Yves-Alexis Perez
Yes I mind. I’m sorry my schedule doesn’t align with yours, but I honestly 
don’t see the urgency here. I’m not asking you to wait for months, I’m just 
trying to find some time to properly review and integrate Moritz patch. And the 
way you push is a bit annoying right now. I’m sure it’s not intended, but could 
you please slow down a bit?

—
Yves-Alexis

> On 17 Sep 2019, at 18:05, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
> Hi!
> 
>> On Tue, 17 Sep 2019 at 12:49, Yves-Alexis Perez  wrote:
>> 
>> Please don’t, I already told Moritz I’ll handle it when I have time.
> 
> That's just great! Do you mind if, once we get out of testing the two
> other blockers, we ask the RT to remove lightdm from testing? It will
> still re enter testing as soons as you do your next upload+normal
> time.
> 
> Thanks!!



Bug#940598: ITP: r-cran-ggm -- GNU R functions for graphical Markov models

2019-09-17 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-ggm -- GNU R functions for graphical Markov models
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-ggm
  Version : 2.3
  Upstream Author : Giovanni M. Marchetti, Mathias Drton, Kayvan Sadeghi
* URL : https://cran.r-project.org/package=ggm
* License : GPL-2+
  Programming Lang: GNU R
  Description : GNU R functions for graphical Markov models
 Functions and datasets for maximum likelihood fitting of some classes of
 graphical Markov models.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-ggm



Bug#940081: opendmarc: signature bypass with multiple From addresses

2019-09-17 Thread Salvatore Bonaccorso
Control: retitle -1 opendmarc: CVE-2019-16378: signature bypass with multiple 
From addresses

CVE-2019-16378 was assigned for this issue.

Regards,
Salvatore



Bug#875029: Ping!

2019-09-17 Thread Lisandro Damián Nicanor Pérez Meyer
Hi!

On Tue, 17 Sep 2019 at 12:49, Yves-Alexis Perez  wrote:
>
> Please don’t, I already told Moritz I’ll handle it when I have time.

That's just great! Do you mind if, once we get out of testing the two
other blockers, we ask the RT to remove lightdm from testing? It will
still re enter testing as soons as you do your next upload+normal
time.

Thanks!!



Bug#939663: freefem++: B-D on cruft packages

2019-09-17 Thread Drew Parsons
Package: freefem++
Followup-For: Bug #939663

Is there a reason why freefem++ has the versioned

  Build-Depends: libpetsc-real3.10-dev, libpetsc-complex3.10-dev

instead of the non-specific
  
  Build-Depends: libpetsc-real-dev, libpetsc-complex-dev

?



Bug#940597: ITP: r-cran-huge -- GNU R high-dimensional undirected graph estimation

2019-09-17 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-huge -- GNU R high-dimensional undirected graph estimation
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-huge
  Version : 1.3.3
  Upstream Author : Haoming Jiang, Xinyu Fei, Han Liu, Kathryn Roeder, John 
Lafferty, Larry
* URL : https://cran.r-project.org/package=huge
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R high-dimensional undirected graph estimation
 Provides a general framework for high-dimensional undirected graph
 estimation. It integrates data preprocessing, neighborhood screening,
 graph estimation, and model selection techniques into a pipeline. In
 preprocessing stage, the nonparanormal(npn) transformation is applied to
 help relax the normality assumption. In the graph estimation stage, the
 graph structure is estimated by Meinshausen-Buhlmann graph estimation or
 the graphical lasso, and both methods can be further accelerated by the
 lossy screening rule preselecting the neighborhood of each variable by
 correlation thresholding.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-huge



Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure

2019-09-17 Thread Mike Gabriel

Hi,

On  Di 17 Sep 2019 17:38:03 CEST, Mike Gabriel wrote:


What I did:

1. Setup a fresh 389-ds instance using jessie's original version
(see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/)

2. Upgrade to +deb8u4, test login, LDAP queries, etc.

-> worked

3. Upgrade to +deb8u5, test login, LDAP queries, etc.

-> worked

4. Upgrade to +deb8u6, test login, LDAP queries, etc.

-> worked

Can you be any chance provide more info about this issue? What  
exactly are the LDAP queries, that Nextcloud does on your 389-ds  
server?


Can anyone else give feedback about 389-ds in jessie LTS? Any  
observed problems that look similar to #912224 [1]?


Thanks+Greets,
Mike

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


completing the story...

During package upgades, I see upgrade failures:

```
root@jessie:~# apt-get install 389-ds-base --reinstall
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu  
entfernen und 0 nicht aktualisiert.

Es müssen noch 0 B von 1.459 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
(Lese Datenbank ... 137483 Dateien und Verzeichnisse sind derzeit  
installiert.)

Vorbereitung zum Entpacken von .../389-ds-base_1.3.3.5-4+deb8u6_amd64.deb ...
Entpacken von 389-ds-base (1.3.3.5-4+deb8u6) über (1.3.3.5-4+deb8u6) ...
Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
Trigger für systemd (215-17+deb8u13) werden verarbeitet ...
389-ds-base (1.3.3.5-4+deb8u6) wird eingerichtet ...
dpkg: Fehler beim Bearbeiten des Paketes 389-ds-base (--configure):
 Unterprozess installiertes post-installation-Skript gab den  
Fehlerwert 1 zurück

Fehler traten auf beim Bearbeiten von:
 389-ds-base
E: Sub-process /usr/bin/dpkg returned an error code (1)
```

The underlying reason of this is this:

```
root@jessie:~# setup-ds -u -s General.UpdateMode=offline
Use of literal control characters in variable names is deprecated at  
/usr/lib/x86_64-linux-gnu/dirsrv/perl/DSCreate.pm line 867.
Could not rename config file  
'/etc/dirsrv/slapd-jessie/slapd-collations.conf' to  
'/var/lib/dirsrv/slapd-jessie/bak.bak/slapd-collations.conf'.  Error:  
Ungültiger Link über Gerätegrenzen hinweg

Error: could not update the directory server.
Exiting . . .
Log file is '/tmp/setupKkbY5z.log'
```

The fix for it (that one has to apply to  
/usr/share/dirsrv/updates/60upgradeconfigfiles.pl and then run  
"apt-get install -f") is this:


```
--- updates.orig/60upgradeconfigfiles.pl2018-09-03 09:58:45.911804203 
+0200
+++ updates/60upgradeconfigfiles.pl 2018-09-03 09:59:36.420699451 +0200
@@ -31,7 +31,7 @@
 next if (! -f $oldname); # does not exist - skip - already
(re)moved
 my $newname = "$bakdir/$file";
 $! = 0; # clear
-rename $oldname, $newname;
+move $oldname, $newname;
 if ($!) {
 push @errs, ["error_renaming_config", $oldname, $newname, $!];
 }
@@ -57,7 +57,7 @@
 next if (! -f $oldname); # does not exist - not backed up
 my $newname = $inf->{slapd}->{config_dir} . "/" . $file;
 next if (-f $newname); # not removed
-rename $oldname, $newname;
+move $oldname, $newname;
 }
 return @errs;
 }
```

So, an improvement, we could offer is fixing the upgrade of  
389-ds-base (which had been broken since jessie got released, in fact).


Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp3XhUlSWWzS.pgp
Description: Digitale PGP-Signatur


Bug#894663: transition: wxwidgets3.0

2019-09-17 Thread Olly Betts
On Tue, Sep 17, 2019 at 05:26:00PM +0200, Gunter Königsmann wrote:
> Making separate bug reports for that, too, and bisecting them costs more
> time than I currently have at hand. Which is why I asked if we
> absolutely need to switch to GTK3.

There's no *absolute* need, but it's unlikely wxmaxima would be in
bullseye if you insisted on sticking with GTK2.

But as Scott already said, there's time before bullseye to work through
remaining problems - that's why we started the transition early and
why we're trying to push it along now.  Please put your time and energy
into resolving any blockers rather than into questioning the transition.

The only potential fly in the ointment is that upstream are making
noises about 3.2.0 again - *if* a release actually happens and in time
for us to seriously consider it for bullseye then we'd really want to
get this transition done first.

Either way, the key thing is to provide upstream with clear bug reports
(and all the information in one place, not split over an upstream bug
report, a debian bug report, and a thread on an upstream mailing list
without even any links between any of them) and ideally their preferred
form of reproducer.

Cheers,
Olly



Bug#940581: Unrecognized country Kosovo

2019-09-17 Thread Pat Suwalski

On 2019-09-17 11:00 a.m., Patrick Matthäi wrote:

Could you test the patch below? It should restore the behaviour for
those IPs. then they are (again) listed as "serbia":


That patch did not help. I looked into it further, and the error is 
triggered on the other "Unrecognized country code" circa line 1100.


This very similar patch makes it work:

--- geoip-csv-to-dat.cpp.orig   2019-09-17 07:31:42.0 -0400
+++ geoip-csv-to-dat.cpp2019-09-17 11:34:59.180224941 -0400
@@ -1103,6 +1109,9 @@
if (csv_fields[CSV_FIELD_COUNTRY_CODE] == "AN") {
csv_fields[CSV_FIELD_COUNTRY_CODE] = "CW";
}
+   else if (csv_fields[CSV_FIELD_COUNTRY_CODE] == "XK") {
+   csv_fields[CSV_FIELD_COUNTRY_CODE] = "RS";
+   }

 	const int countryid = 
GeoIP_id_by_code(csv_fields[CSV_FIELD_COUNTRY_CODE].c_str());

if (countryid == 0) {


Note, the other patch circa line 873 is not needed. So, perhaps there is 
some nicer solution to fix this method, but the special case does work.


--Pat



Bug#875029: Ping!

2019-09-17 Thread Yves-Alexis Perez
Please don’t, I already told Moritz I’ll handle it when I have time.

—
Yves-Alexis

> On 17 Sep 2019, at 16:46, Lisandro Damián Nicanor Pérez Meyer 
>  wrote:
> 
> Hi Yves-Alexis!
> 
> lightdm is now one of the three packages holding qt4 in testing. Would
> it be possible for you to  apply the patch Moritz sent? If you can't
> I'll be happy to NMU it.
> 
> Cheers, Lisandro.
> 
> -- 
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/



Bug#940596: upgrading libjbig2dec0 broke mupdf

2019-09-17 Thread Marco d'Itri
Package: mupdf
Version: 1.15.0+ds1-1+b1
Severity: grave

After upgrading libjbig2dec0 from 0.16-1 to 0.16+20190905-2 it does not 
start anymore:

md@bongo:~$ mupdf
/usr/lib/mupdf/mupdf-x11: symbol lookup error: /usr/lib/mupdf/mupdf-x11: 
undefined symbol: jbig2_ctx_new
[Exit 127]
md@bongo:~$ nm -D /usr/lib/x86_64-linux-gnu/libjbig2dec.so.0 | grep 
jbig2_ctx_new
3a40 T jbig2_ctx_new_imp
md@bongo:~$

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

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

Versions of packages mupdf depends on:
ii  libc62.29-1
ii  libfreetype6 2.9.1-4
ii  libharfbuzz0b2.6.1-3
ii  libjbig2dec0 0.16+20190905-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopenjp2-7 2.3.0-2
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-1+b1

mupdf recommends no packages.

Versions of packages mupdf suggests:
pn  mupdf-tools  

-- no debconf information

-- 
ciao,
Marco


signature.asc
Description: PGP signature


Bug#912224: since update 1.3.3.5-4+deb8u5 php ldap authentification failure

2019-09-17 Thread Mike Gabriel

Hi Jan,

On Thu, 12 Sep 2019 09:38:13 +0200 Jan Kowalsky 
 wrote:

> Hi Mike,
> hi Hugo,
>
>
> Am 11.09.19 um 14:04 schrieb Mike Gabriel:
> > Hi Hugo,
> >
> > sorry for the late reply on this urgent matter.
> >
> > On  So 08 Sep 2019 10:46:26 CEST, Hugo Lefeuvre wrote:
> >
> >> Sorry for the very late answer. For some reason, it looks like the LTS
> >> team
> >> was not aware of this bug...
> >>
> >> I am the one who provided these updates. This issue must have slipped
> >> through my LDAP tests. I will investigate this as soon as possible and
> >> provide a fix consequently.
> >>
> >> Mike, you did the latest 389-ds-base update. Did you notice anything
> >> wrong
> >> during your tests?
> >
> > For uploading 1.3.3.5-4+deb8u6, I unfortunately did not do much smoke
> > testing regarding the LDAP query stuff (the patch was about indefinite
> > SSL connection hangs).
> >
> > Let me know, if you need help looking into this (due to e.g. time
> > constraints or what not on your side).
>
> as with version 1.3.5.17-2 everything worked fine, we didn't investiagte
> further...
>
> So I can only report that we didn't encounter any errors with all the
> versions shipped in debian 9.
>
> Regards
> Jan

I looked into this issue much deeper today and I cannot confirm the 
observation this bug was originally about.


What I did:

1. Setup a fresh 389-ds instance using jessie's original version
(see http://snapshot.debian.org/package/389-ds-base/1.3.3.5-4/)

2. Upgrade to +deb8u4, test login, LDAP queries, etc.

-> worked

3. Upgrade to +deb8u5, test login, LDAP queries, etc.

-> worked

4. Upgrade to +deb8u6, test login, LDAP queries, etc.

-> worked

Can you be any chance provide more info about this issue? What exactly 
are the LDAP queries, that Nextcloud does on your 389-ds server?


Can anyone else give feedback about 389-ds in jessie LTS? Any observed 
problems that look similar to #912224 [1]?


Thanks+Greets,
Mike

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



Bug#940595: transition: hypre

2019-09-17 Thread Drew Parsons
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to proceed with the hypre transition to 2.17.0.

I've tested that petsc and sundials build successfully with the new
hypre.

Ben file:

title = "hypre";
is_affected = .depends ~ "libhypre-2.16.0" | .depends ~ "libhypre-2.17.0";
is_good = .depends ~ "libhypre-2.17.0";
is_bad = .depends ~ "libhypre-2.16.0";


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

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



Bug#940589: git-debpush: undeclared perl dependency

2019-09-17 Thread Ian Jackson
Control: user d...@packages.debian.org
Control: usertags -1 rsn

Andrej Shadura writes ("Bug#940589: git-debpush: undeclared perl dependency"):
...
> When I attempt to run git-debpush, I see this error:
> 
> Can't locate Git/Wrapper.pm in @INC (you may need to install the 
> Git::Wrapper module) (@INC contains: /etc/perl 
> /usr/local/lib/x86_64-linux-gnu/perl/5.28.1 /usr/local/share/perl/5.28.1 
> /usr/lib/x86_64-linux-gnu/perl5/5.28 /usr/share/perl5 
> /usr/lib/x86_64-linux-gnu/perl/5.28 /usr/share/perl/5.28 
> /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at 
> /usr/bin/git-deborig line 93.

This is odd.  I wonder why the tests don't catch it.
Anyway thanks for the report.

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#940588: git-debpush: pipefail in get_file_from_ref

2019-09-17 Thread Ian Jackson
Control: user d...@packages.debian.org
Control: usertags -1 rsn

Andrej Shadura writes ("Bug#940588: git-debpush: pipefail in 
get_file_from_ref"):
> Package: git-debpush
> Version: 9.9
> Severity: important
...
> In line 61, grep -Eq may cause a pipefail if grep exits before git
> ls-tree concludes. With a debug print for $? I can see this:
> 
> ++ get_file_from_ref debian/source/format
> ++ local path=debian/source/format
> ++ git ls-tree --name-only -r refs/heads/debian/buster-security
> ++ grep -Eq '^debian/source/format$'
> ++ echo  141
> 
> It helped when I replaced it with a redirect:
> 
> if git ls-tree --name-only -r "$branch" \
> | grep -E "^$path$" >/dev/null; then
> git cat-file blob $branch:$path
> fi
> 
> ++ local path=debian/source/format
> ++ git ls-tree --name-only -r refs/heads/debian/buster-security
> ++ grep -E '^debian/source/format$'
> ++ echo  0

I agree with the suggestion to redirect to >/dev/null

Background from irc:

11:37  The thing with pipefail and SIGPIPE is very annoying.
11:37  IMO this is a bug in set -o pipefail
11:38  if ( git ls-tree --name-only -r "$branch" || test $? = 141 ) | 
   ...
11:38  What even weirder this is all in an if
11:39  I’d just >/dev/null tbh
11:39  http://paste.debian.net/1101208/#

ie:

mariner:~> bash -xec 'set -o pipefail; if yes | head -1 ; then id; fi'
+ set -o pipefail
+ yes
+ head -1
y
mariner:~> 

11:39  that’s more readable to me at least
11:40  I guess the performance is not really a consideration since it's 
   O(n) either way
11:40  (both because the worst case is O(n) and because the rest of it 
   is O(n))


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#940594: Tests fail when applying new upstream commit

2019-09-17 Thread Gunnar Hjalmarsson

Package: src:ibus

Hello!

We are about to upgrade ibus for Ubuntu 19.10 based on ibus 
1.5.21-1~exp2. We added the upstream commit 
 since it's a security 
thing and has also been added to our stable releases.


https://launchpad.net/ubuntu/+source/ibus/1.5.21-1~exp2ubuntu1

So far, so good. But then I'd like to also add the upstream commit "bus: 
Use XDG_RUNTIME_DIR for Unix socket directory":


https://github.com/ibus/ibus/commit/a141a141

However, doing so makes a bunch of tests fail when building.

I noticed that two of the Debian patches probably conflict with that new 
way to deal with the abstract socket file:


* 0003-dconf-Use-dbus-run-session-to-set-up-dconf-overrides.patch
* dconf-Create-a-temporary-XDG_RUNTIME_DIR.patch

so I tried to disable those, but it didn't help.

You can see what it looks like in this PPA:

https://launchpad.net/~gunnarhj/+archive/ubuntu/ibus-test/+packages

This is an example buildlog:

https://launchpadlibrarian.net/443014842/buildlog_ubuntu-eoan-amd64.ibus_1.5.21-1~exp2ubuntu1+test_BUILDING.txt.gz

I have reported the issue upstream as well:

https://github.com/ibus/ibus/issues/2135

But since Takao Fujiwara didn't instantly confirm the problem, I thought 
I'd better call your attention to it.


--
Cheers,

Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj



Bug#940591: python-mlt: mlt.py and _mlt.so installed in wrong location(/usr/lib/dist-packages/)

2019-09-17 Thread j
On 17/09/2019 10:14, Patrick Matthäi wrote:
> The fail was, that the packaging didn't died...
> I replaced pyversions with py3versions

with py3versions you get usr/lib/python3.7/dist-packages
but in python3 everything is installed in usr/lib/python3/dist-packages



Bug#940590: git-debpush: error message unclear

2019-09-17 Thread Ian Jackson
Andrej Shadura writes ("Bug#940590: git-debpush: error message unclear"):
> Package: git-debpush
> Version: 9.9
> Severity: minor
...
> Sometimes git-debpush complains about things, and it’s not clear what
> exactly it complains about.

11:33  I think it might be worth disabling those git
 warnings
11:33  Yes.

11:33  And maybe changing the wording of the check.
11:33  Eg it could say   git-debpush: check failed: blah blah
11:34  and then when it says "some check(s) failed" you'd be cued to 
   recognise the two messages as going together, even in the 
   presence of other noise

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#894663: transition: wxwidgets3.0

2019-09-17 Thread Gunter Königsmann


On 16.09.19 22:50, Scott Talbert wrote:
> On Mon, 16 Sep 2019, Gunter Königsmann wrote:
>
>> I can try to bisect wxWidgets. But as building wxWidgets drains my
>> battery in minutes I will be able to do at maximum one step per week.
>
> You can only charge your battery once a week?

Not once a week, but as I have other projects, as well, I am very
limited on time on unlimited power.

>
> If you're really strapped for compile resources, you can probably use
> some of the debian porter boxes?
>
Wow... ...will look into that possibility. Before that I will have to
find a way to ship around other bugs of the combination wxWidgets/GTK3,
though, that make it hard to see if the  "scroll" sample, if it would
work, would flicker (see
https://www.peterpall.de/wxMaxima/debian/FlickerScreenshot1.png).

Making separate bug reports for that, too, and bisecting them costs more
time than I currently have at hand. Which is why I asked if we
absolutely need to switch to GTK3.

Kind regards,

   Gunter.



Bug#940521: buster-pu: package mariadb-10.3 10.3.18-0+deb10u1

2019-09-17 Thread Otto Kekäläinen
> Some poking around on Github suggests that the fix is
> https://github.com/MariaDB/server/commit/47f8a18fec604983e47fdf7c822d94b26d85cade
>
> If this is actively breaking systems, couldn't we simply apply that
> patch to the current versions in stretch and buster, as a least-change
> option?

We could in theory extend the gitlab-ci.yml pipeline to include a test
that sets up a replication master and a slave, and runs some updates
and replicates them. With that pipeline we could validate that earlier
versions worked and with this patch it works again. And such an
addition to the CI pipeline would also discover if replication ever
breaks again. This is however too much work for me right now, so
instead I would just wait until upstream releases and trust that
upstream knows what they are doing in terms of making the fix
correctly without breaking anything more somewhere else.



  1   2   3   >