Bug#837394: Better fix for the angband PIE FTBFS

[Adrian Bunk]

A fix for the angband PIE FTBFS that does not disable PIE is attached.

cu
Adrian

-- 

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

Description: Fix the build with PIE as default
 Use -r instead of -Wl,-r so that gcc no longer always
 passes -r to ld.
 .
 -r and -pie cannot be used together in the linker,
 and position independent is already relocatable.
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/837394

--- angband-3.5.1.orig/src/Makefile
+++ angband-3.5.1/src/Makefile
@@ -32,7 +32,7 @@ win/angband.res: win/angband.rc
 	$(RC) $< -O coff -o $@
 
 angband.o: $(OBJECTS)
-	$(LD) -nostdlib -Wl,-r -o $@ $(OBJECTS)
+	$(LD) -nostdlib -r -o $@ $(OBJECTS)
 	@printf "%10s %-20s\n" LINK $@
 
 tests: angband.o

Bug#843852: amanda-common: Cannot run amdump - and report about missing ssl symbols

[Kamil Jonca]

Package: amanda-common
Version: 1:3.3.9-2
Severity: grave
Justification: renders package unusable

amdump ends prematurely with report:
an't load '/usr/lib/x86_64-linux-gnu/amanda/perl/auto/Amanda/Debug/libDebug.so' 
for module Amanda::Debug: /usr/lib/x86_64-linux-gnu/amanda/libamanda-3.3.9.so: 
undefined symbol: SSL_library_init at 
/usr/lib/x86_64-linux-gnu/perl/5.24/DynaLoader.pm line 187.
 at /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Debug.pm line 11.
Compilation failed in require at 
/usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Config/FoldingHash.pm line 5.
BEGIN failed--compilation aborted at 
/usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Config/FoldingHash.pm line 5.
Compilation failed in require at 
/usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Config.pm line 753.
BEGIN failed--compilation aborted at 
/usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Config.pm line 753.
Compilation failed in require at /usr/sbin/amdump line 29.
BEGIN failed--compilation aborted at /usr/sbin/amdump line 29.


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

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

Versions of packages amanda-common depends on:
ii  adduser   3.115
ii  bsd-mailx [mailx] 8.1.2-0.20160123cvs-3
ii  debconf [debconf-2.0] 1.5.59
ii  libc6 2.24-5
ii  libcurl3  7.51.0-1
ii  libglib2.0-0  2.50.2-1
ii  libssl1.0.2   1.0.2j-4
ii  openbsd-inetd [inet-superserver]  0.20140418-2
pn  perl:any  
ii  update-inetd  4.43

amanda-common recommends no packages.

Versions of packages amanda-common suggests:
ii  amanda-client  1:3.3.9-2
ii  amanda-server  1:3.3.9-2

-- Configuration Files:
/etc/amandahosts [Errno 13] Permission denied: u'/etc/amandahosts'

-- debconf information:
  amanda-common/merge_amandates:

Bug#843853: Uninstallabel due to dependency on libgstreamer-plugins-bad1.0-0 (< 1.8.4)

[Vincent Bernat]

Package: gstreamer1.0-vaapi
Version: 1.8.3-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

gstreamer-vaapi is currently uninstallable (in unstable only) due to
its dependency on libgstreamer-plugins-bad1.0-0.

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

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

-BEGIN PGP SIGNATURE-

iQIvBAEBCAAZBQJYJDS4EhxiZXJuYXRAZGViaWFuLm9yZwAKCRCVpC/oNTUl+aWB
D/wI7YyskAtgE9TT4hz/nQv1n86qCfZDhWehl0nz+mMTfOGG9vi01hmkYBL1eTz7
o5ElIiJaVPZgUFoUyiOPM3+inytAplePM94Mj/VD1ps1CP/l9kM/cLhC8Nskcsah
d0uQhRIpS0NHOpxyYo9fMGeGTCjAxWkZVm5JPG23VKTXIsdmfX3qiC6KzAUr6p+t
lNhcO5WvEpFCIdHZbspmIBXuj1s3B6m51PrUpxI6WHQKIJUgDIBhDfpMX/WfROOM
bUutKd+ap+xmfZHwigTe7EKKZxWU6m8Q8/4zwzqN7Xc3/JVjsft1tO71AY2WEp7q
9ONzZJWCXVditU5tCAmLxt+U0OEMhRy9BvuzXck7D1F/ChqA17cgPuX0uxxTMTO9
lxED53tAgraHnBqlK6myLxG/wAwF/ddEIvctHrxKF6uPX8lSaB7oD3G8yc9tF/iR
PfPcRaoFIiBKn4jup6ggv/nabPvVF3eioKtBq/LE+ViOMbFpQyvRmRiVfvEDxchA
GWKiuY7e1K0RU6/GuE8HV6qq5cIhqlaVG66wG2UdBGMOsFwzH+e4Srmx3yB5XDQ6
P6Dgy7os4/ID2bCdjS9TP1JsmMDGevh9KsUV/0L7Yxg1bJYjmCgyL7PkGl/B1scI
JgNExSQ8pXLR/qp58TtojtWH7kjsBTOFf8BDm0ERFlwR0A==
=M1yr
-END PGP SIGNATURE-

Processed: Re: Bug#843169: xbmc-eventclients-j2me: uninstallable in unstable

[Debian Bug Tracking System]

Processing control commands:

> tags -1 pending confirmed
Bug #843169 [xbmc-eventclients-j2me] xbmc-eventclients-j2me: uninstallable in 
unstable
Added tag(s) confirmed and pending.

-- 
843169: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843169
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#843169: xbmc-eventclients-j2me: uninstallable in unstable

[Bálint Réczey]

Control: tags -1 pending confirmed


2016-11-10 9:34 GMT+01:00 Andreas Beckmann :
> On Fri, 4 Nov 2016 14:34:09 + James Cowgill  wrote:
>> The xbmc-eventclients-j2me cannot be installed in unstable.
>> The kodi-eventclients-j2me package does not exist.
>
> since kodi-eventclients-j2me has been dropped, the transitional
> xbmc-eventclients-j2me package needs to be removed as well

Hi Andreas,

The fix is ready in git and will be uploaded soon.

Cheers,
Balint

Bug#826042: Microsoft Outlook Inc. Copyright © 2016

[Camus, Blandine]

MICROSOFT OUTLOOK NOTIFICATION

Your email box account needs to be 
verify now or will be block for 
irregularities found in your email box account


Microsoft Outlook Inc. Copyright © 2016




























































































































































?

?

Bug#843169: xbmc-eventclients-j2me: uninstallable in unstable

[Andreas Beckmann]

On Fri, 4 Nov 2016 14:34:09 + James Cowgill  wrote:
> The xbmc-eventclients-j2me cannot be installed in unstable.
> The kodi-eventclients-j2me package does not exist.

since kodi-eventclients-j2me has been dropped, the transitional
xbmc-eventclients-j2me package needs to be removed as well


Andreas

Bug#843644: 843644 fixed

[SkyzoThreaD]

That bug is indeed fixed. Thank you so much. Great job ;)

Bug#843838: [pkg-bacula-devel] Bug#843838: Fail to access config file

[Sven Hartge]

On 10.11.2016 08:05, Jörg Frings-Fürst wrote:

> # ls -l /etc/bacula/
> insgesamt 104
> -rw-r- 1 root   dirmngr 9343 Feb 20  2016 bacula-dir.conf
> -rw-r- 1 root   bacula  9156 Aug 18 14:12 bacula-dir.conf.dist
> -rw-r- 1 root   dirmngr 1024 Sep 29  2013 bacula-fd.conf

This looks highly suspicious and reminds me of something that happened
to me in the past:

Was the system in question at some time in the past cloned/copied via
rsync (without using --numeric-ids) or any other method while having
been bootet from a rescue medium like GRML or Knoppix?

It seems the numerical UID in the rootfs got messed up.

Could you also please provide the output of

ls -ln /etc/bacula
getent group dirmngr
getent group bacula

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Andreas Tille]

Hi Ole,

On Thu, Nov 10, 2016 at 09:06:52AM +0100, Ole Streicher wrote:
> > 
> >> it's indeed to late in the stretch dev cycle in my opinion.
> > 
> > That would mean to lower the severity of #840094.  Ole, are you OK with
> > this?
> 
> No, I am not. The tool gives wrong results, and it does so silently. If
> I would not have discovered this by chance, the Debian Astro tasks
> packages were still wrong and would have stayed so in Stretch. I don't
> know about other blends, whether they ever checked the metapackages --
> others still may have missing tasks as well, just because their
> maintainers read the docs and trust the debian-blends package. And you
> can't just change the specs in the last minute.
> 
> And, if the package is in Stretch, people will start their new blend
> with exactly this package, again running into this trouble.

I see your point but I have mixed feelings.

> I would really propose to fix that before Stretch. It just can't be that
> difficult. Nobody knows a Perl specialist who can have a look?

Petter, could you please have a look at the patch provided by Ole[1]?
 
> (Oh, and can we have Python for the Next Generation blends-dev? This is
> at least what I understand, and there is already a parser for rfc822)

Did you ever checked out[2]?  Its Python and it solves another major
problem.  It is able to create Architecture=any metapackages verifying
the availability of a dependency on the said architecture.  It also
creates automatic changelog about differences to previous releases and
adds some statistical data in json format.  The price you need to pay is
that you need to access UDD - but given that there is some public UDD
mirror this could be turned to a non issue.  And it needs testing ...
since 3 years. :-(

If you have a local UDD mirror you can just build the package and use it
to create the metapackage source as a drop in replacement - which I'm
actually doing for Debian Med to get the json data and changelog which
I'm copying over.  As I said: Sorry for not managing to push this into
production earlier ...

Kind regards

   Andreas.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840094#25 
[2] https://anonscm.debian.org/git/blends/blends-gsoc.git

-- 
http://fam-tille.de

Bug#843848: ifupdown2: diversion handling broken

[Andreas Beckmann]

Package: ifupdown2
Version: 1.0~git20161101-1
Severity: serious

Hi,

ifupdown doesn't use the diversions correctly

1. diverting conffiles does not work well, so just use Breaks against
the bash-completion versions shipping the ifup etc. completion in /etc
Do not forget to clean up the now obsolete diversions in /etc in the
preinst or postinst!

2. unconditionally install the diversions, installing bash-completion
after ifupdown2 breaks right now with a file overwrite error since the
diversions are not in place (this is how I noticed the problems)
(also upgrading ifupdown2 will suddenly install more diversions since
it finds more of the files that could be diverted - because the
installed ifupdown2 version shipped them)

3. unconditionally install/remove the diversions without checking
whether they exist, running dpkg-divert multiple times is idempotent


Andreas

Bug#843457: mysql-workbench: Dependency gdal-abi-2-1-1 no longer in repo

[Alessio Gaeta]

Package: mysql-workbench
Version: 6.3.4+dfsg-3+b5
Followup-For: Bug #843457

Any news on that one?

mysql-workbench is stuck in unstable since more than a year now, and it is not
in testing anymore since September. The freeze is approaching: do we will not
have mysql-workbench in Stretch?

Is this package abandoned?

Thanks



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

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

Versions of packages mysql-workbench depends on:
ii  libatkmm-1.6-1v52.24.2-2
ii  libc6   2.24-5
ii  libcairo2   1.14.6-1+b1
ii  libcairomm-1.0-1v5  1.12.0-1+b1
ii  libctemplate3   2.3-3
ii  libgcc1 1:6.2.0-10
ii  libgdal20 [gdal-abi-2-1-1]  2.1.1+dfsg-5
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libgl1-mesa-glx [libgl1]12.0.3-3
ii  libglib2.0-02.50.1-1
ii  libglibmm-2.4-1v5   2.50.0-1
ii  libgnome-keyring0   3.12.0-1+b1
ii  libgtk2.0-0 2.24.31-1
ii  libgtkmm-2.4-1v51:2.24.5-1
ii  libmysqlclient185.6.30-1
ii  libmysqlcppconn7v5  1.1.4+really1.1.3-1
ii  libodbc12.3.1-5+b1
ii  libpango-1.0-0  1.40.3-2
ii  libpangocairo-1.0-0 1.40.3-2
ii  libpangomm-1.4-1v5  2.40.1-3
ii  libpcre32:8.39-2
ii  libpcrecpp0v5   2:8.39-2
ii  libpython2.72.7.12-3+b1
ii  libsigc++-2.0-0v5   2.10.0-1
ii  libstdc++6  6.2.0-10
ii  libtinyxml2.6.2v5   2.6.2-4
ii  libuuid12.28.2-1
ii  libvsqlitepp3v5 0.3.13-3.1
ii  libx11-62:1.6.3-1
ii  libxml2 2.9.4+dfsg1-2.1
ii  libzip4 1.1.2-1.1
ii  mysql-workbench-data6.3.4+dfsg-3
ii  python-mysql.connector  2.1.3-1
ii  python-paramiko 2.0.0-1
ii  python-pexpect  4.2.0-1
ii  python-pyodbc   3.0.10-2
ii  python-pysqlite22.7.0-1
ii  python2.7   2.7.12-3+b1
pn  python:any  

Versions of packages mysql-workbench recommends:
ii  mysql-client 5.6.30-1
ii  mysql-client-5.6 [virtual-mysql-client]  5.6.30-1
ii  mysql-utilities  1.6.3-1
ii  ttf-bitstream-vera   1.10-8

Versions of packages mysql-workbench suggests:
ii  gnome-keyring  3.20.0-3

-- no debconf information

Bug#843838: [pkg-bacula-devel] Bug#843838: Fail to access config file

[Carsten Leonhardt]

Hi,

thanks for your report.

As a quick fix "chgrp bacula /etc/bacula/bacula-dir.conf" should help.

To further understand your problem though, could you please also send us
the output of:

groups bacula

cat /etc/defaults/bacula-dir.conf

and if you use systemd, any local modifications of the startup
procedure?

Thanks,

 - Carsten

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas and Bas,

On 10.11.2016 08:45, Andreas Tille wrote:
> On Wed, Nov 09, 2016 at 06:27:13PM +0100, Sebastiaan Couwenberg wrote:
>> On 11/09/2016 03:35 PM, Andreas Tille wrote:
>>> If you (and Bas and other readers here) think we should fix the issue
>>> right now I'm fine if you apply the patch below and we should seriously
>>> test the metapackage creation of each Blend *before* 2016-12-05.
>>>
>>> What do you think?
>>
>> I think supporting the deb822 format should be a Blends release goal for
>> buster,
> 
> I fully agree.  I admit I did way less for blends-dev than I intended to
> do but other tasks that felt more urgent occupied all my Debian time.
> 
>> it's indeed to late in the stretch dev cycle in my opinion.
> 
> That would mean to lower the severity of #840094.  Ole, are you OK with
> this?

No, I am not. The tool gives wrong results, and it does so silently. If
I would not have discovered this by chance, the Debian Astro tasks
packages were still wrong and would have stayed so in Stretch. I don't
know about other blends, whether they ever checked the metapackages --
others still may have missing tasks as well, just because their
maintainers read the docs and trust the debian-blends package. And you
can't just change the specs in the last minute.

And, if the package is in Stretch, people will start their new blend
with exactly this package, again running into this trouble.

I would really propose to fix that before Stretch. It just can't be that
difficult. Nobody has a Perl specialist who can have a look?

(Oh, and can we have Python for the Next Generation blends-dev? This is
at least what I understand, and there is already a parser for rfc822)

Best regards

Ole

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Ole Streicher]

Hi Andreas and Bas,

On 10.11.2016 08:45, Andreas Tille wrote:
> On Wed, Nov 09, 2016 at 06:27:13PM +0100, Sebastiaan Couwenberg wrote:
>> On 11/09/2016 03:35 PM, Andreas Tille wrote:
>>> If you (and Bas and other readers here) think we should fix the issue
>>> right now I'm fine if you apply the patch below and we should seriously
>>> test the metapackage creation of each Blend *before* 2016-12-05.
>>>
>>> What do you think?
>>
>> I think supporting the deb822 format should be a Blends release goal for
>> buster,
> 
> I fully agree.  I admit I did way less for blends-dev than I intended to
> do but other tasks that felt more urgent occupied all my Debian time.
> 
>> it's indeed to late in the stretch dev cycle in my opinion.
> 
> That would mean to lower the severity of #840094.  Ole, are you OK with
> this?

No, I am not. The tool gives wrong results, and it does so silently. If
I would not have discovered this by chance, the Debian Astro tasks
packages were still wrong and would have stayed so in Stretch. I don't
know about other blends, whether they ever checked the metapackages --
others still may have missing tasks as well, just because their
maintainers read the docs and trust the debian-blends package. And you
can't just change the specs in the last minute.

And, if the package is in Stretch, people will start their new blend
with exactly this package, again running into this trouble.

I would really propose to fix that before Stretch. It just can't be that
difficult. Nobody knows a Perl specialist who can have a look?

(Oh, and can we have Python for the Next Generation blends-dev? This is
at least what I understand, and there is already a parser for rfc822)

Best regards

Ole