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

[Ole Streicher]

Hi Andreas & all,

On 09.11.2016 15:35, Andreas Tille wrote:
>> We have a clear definition of how these files should look like, namely
>> RFC822, and this also defines continuation lines.
> 
> Unfortunately in this specific feature tasks files are not RFC822
> compliant, which sucks, yes.  Its even not documented (I just checked
> since I intended to document it at some point in time but can't find it
> :-( )

If one of our main tools is not compliant with our documented
specifications, and this may cause incomplete metapackages (which are
one central part of the blend), then I would still rate this as an RC
bug, independently of whether it is easy to fix or not.

>> I would think that there is also a quick fix for it -- the tool already
>> handles continuation lines for the tasks description, so one could
>> probably just take that. I have no glue of all the Perl $@^!~ special
>> chars, but wouldn't do it something like the attached patch (after
>> removing the obvious errors from it)?
>>
>> Or something else just adopted from lines 556-562 of blends-gen-control?
> 
> While I fully agree that we should fix this I'm not fully convinced how
> to sensibly proceed here.  The problematic thing is that we are quite
> short before a release and if we might break metapackage creation in
> some way we might get in trouble.  I'm no Perl programmer myself (even
> if I think your patch looks sensible) and so IMHO staying conservative
> and add some line ending escapes could be the less invasive change.

I checked my patch, and it does *not* work correctly, it will produce
syntax errors in the debian/control file, if RFC822 continuation lines
are used. For tasks that have all in one line, or that have
metapackages, everything seems to be OK, however.

> 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 am ready to test and also to fix; however my know-how ends here. I
don't know what is wrong with the fix.

Just wondering, and starting to really get worried: None of the
debian-blends maintainers has enough Perl knowledge to fix this? If we
all do not know Perl, why do we use that language in one of our central
tools? That sounds to me even more RC than the bug itself...

Cheers

Ole

Bug#774415: From srebuild sbuild-wrapper to debrebuild

[Johannes Schauer]

Hi all,

On Tue, 02 Aug 2016 22:49:00 +0200 Johannes Schauer  wrote:
> I was thinking about this issue again and thought that instead of creating a
> wrapper for sbuild which then uses a chroot-setup hook to install the
> dependencies, what I should instead do is to let sbuild itself accept
> .buildinfo files and then do the right thing like:
> 
>  - use snapshot.d.o to retrieve the right timestamps needed to gather all
>packages
>  - mangle the build dependencies such that the source package now depends on
>the exact right package versions and let the resolver figure out the rest
>(thanks Benjamin for that idea)
>  - check whether the generated binaries produce the same checksum as given in
>the supplied buildinfo file
> 
> But then on IRC, HW42 suggested to approach this problem differently. Instead
> of integrating the functionality of figuring out the right repositories to
> reproduce the contents of a buildinfo file into sbuild, write a tool that can
> drive any package builder (like pbuilder).
> 
> I now wrote such a script.

now that libdpkg-perl comes with support for .buildinfo files, I improved the
script (new version attached) with the following changes:

 - don't use DateTime::Format::Strptime but Time::Piece instead (which is a
   perl core module)
 - don't use CTRL_INDEX_SRC but CTRL_FILE_BUILDINFO now that dpkg supports
   .buildinfo files
 - Dpkg::Compression::FileHandle as it is not needed
 - the .dsc file name is no longer part of the .buildinfo file, so assemble the
   .dsc file name from the package name and version using Dpkg::Source::Package
 - use the information from the Environment field
 - instead of splitting Installed-Build-Depends manually, use
   Dpkg::Deps::deps_parse
 - instead of using [trusted=yes], retrieve the gpg key of the reproducible
   builds repository and verify its fingerprint
 - set Binary::apt-get::Acquire::AllowInsecureRepositories to false so that
   apt-get fails to update repositories it cannot authenticate
 - use Dpkg::Vendor to retrieve the keyring filenames

Thanks to Guillem Jover for the code review!

cheers, josch
#!/usr/bin/perl
#
# Copyright 2016 Johannes Schauer
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.

use strict;
use warnings;

use Dpkg::Control;
use Dpkg::Index;
use Dpkg::Deps;
use Dpkg::Source::Package;
use File::Temp qw(tempdir);
use File::Path qw(make_path);
use JSON::PP;
use Time::Piece;
use File::Basename;

eval {
require LWP::Simple;
require LWP::UserAgent;
no warnings;
$LWP::Simple::ua = LWP::UserAgent->new(agent => 'LWP::UserAgent/srebuild');
$LWP::Simple::ua->env_proxy();
};
if ($@) {
if ($@ =~ m/Can\'t locate LWP/) {
	die "Unable to run: the libwww-perl package is not installed";
} else {
	die "Unable to run: Couldn't load LWP::Simple: $@";
}
}

my $buildinfo = shift @ARGV;
if (not defined($buildinfo)) {
die "need buildinfo filename";
}

# buildinfo support in libdpkg-perl (>= 1.18.11)
my $cdata = Dpkg::Control->new(type => CTRL_FILE_BUILDINFO);

if (not $cdata->load($buildinfo)) {
die "cannot load $buildinfo";
}

my $build_arch = $cdata->{"Build-Architecture"};
if (not defined($build_arch)) {
die "need Build-Architecture field";
}
my $inst_build_deps = $cdata->{"Installed-Build-Depends"};
if (not defined($inst_build_deps)) {
die "need Installed-Build-Depends field";
}

my $srcpkg = Dpkg::Source::Package->new();
$srcpkg->{fields}{'Source'} = $cdata->{"Source"};
$srcpkg->{fields}{'Version'} = $cdata->{"Version"};
my $dsc_fname = $srcpkg->get_basename(1) . ".dsc";

my $environment = $cdata->{"Environment"};
if (not defined($environment)) {
die "need Environment field";
}
$environment =~ s/\n/ /g; # remove newlines
$environment =~ s/^ //; # remove leading whitespace

my $checksums = Dpkg::Checksums->new();
$checksums->add_from_control($cdata);
my @files = $checksums->get_files();

# gather all installed build-depends and figure out the version of base-files
# and dpkg
my $base_files_version;
my $dpkg_version;
my @inst_build_deps = ();
$inst_build_deps = deps_parse($inst_build_deps, reduce_arch => 0, build_dep => 0);
if (! defined $inst_build_deps) {
die "deps_parse failed\n";
}

foreach my $pkg ($inst_build_deps->get_deps()) {
if (! $pkg->isa('Dpkg::Deps::Simple')) {
	die "dependency disjunctions are not allowed\n";
}
if (not defined($pkg->{package})) {
	die "name undefined";
}
if 

Bug#822792: (no subject)

[Michael Lustfield]

Sorry for the noise... should quiet down now. :(

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

[Andreas Tille]

Hi Bas,

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?

In addition we might mention this in the docs and publish it on the web
page at least.

Kind regards

  Andreas. 

-- 
http://fam-tille.de

Bug#843845: libgtk-3-0: Eclipse IDE (Oracle JDK8) crashes with libgtk-3.so.0

[Aleksandar Nikolov]

Package: libgtk-3-0
Version: 3.22.2-1
Severity: normal

Dear Maintainer,

After last upgrade at November 2, 2016, when I start Eclipse IDE, which uses
Oracle JDK 1.8.0, and start use it, after several operations (like open 
files

or start a server) the IDE crashes.
Actually crashes JDK using libgtk-3.so.0 - version 3.22.2-1. I have no such
crashes with previous versions of libgtk-3.so.0.
Here is a piece of the log (the whole log is 250k):

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7f761fcbfd56, pid=9969, tid=0x7f769ce98700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_111-b14) (build
1.8.0_111-b14)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.111-b14 mixed mode 
linux-amd64

compressed oops)
# Problematic frame:
# C  [libgtk-3.so.0+0x173d56]
#
# Failed to write core dump. Core dumps have been disabled. To enable core
dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---  T H R E A D  ---

Current thread (0x7f769400b000):  JavaThread "main" [_thread_in_native,
id=9970, stack(0x7f769cd98000,0x7f769ce99000)]

siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr:
0x3000

Registers:
RAX=0x7f769445b550, RBX=0x7f7695c36290, RCX=0x,
RDX=0x3000
RSP=0x7f769ce95ae0, RBP=0x7f7696d19890, RSI=0x7f7694346f70,
RDI=0x7f7695c36290
R8 =0x017d, R9 =0x0006, R10=0x,
R11=0x
R12=0x7f7697726640, R13=0x7f7695c36290, R14=0x,
R15=0x7f769ce95b00
RIP=0x7f761fcbfd56, EFLAGS=0x00010206, 
CSGSFS=0x002b0033,

ERR=0x0004
  TRAPNO=0x000e

Top of Stack: (sp=0x7f769ce95ae0)
0x7f769ce95ae0:   7f7697726470 7f761fddd4f6
0x7f769ce95af0:   00300018 9ce95bd0
0x7f769ce95b00:    017f0008
0x7f769ce95b10:   00020002 017b0004
0x7f769ce95b20:    017f0008
0x7f769ce95b30:    36805df85b98de00
0x7f769ce95b40:   7f769ce95bf0 7f7697726640
0x7f769ce95b50:   7f7697726470 7f7694357ce0
0x7f769ce95b60:   7f7697726601 7f7697726640
0x7f769ce95b70:   7f7694357fa0 7f761fddf2e2
0x7f769ce95b80:   0002 
0x7f769ce95b90:    36805df85b98de00
0x7f769ce95ba0:   0018 7f7697c223f0
0x7f769ce95bb0:   7f769ce95d70 7f761fd7b651
0x7f769ce95bc0:   7f76943621b0 7f761f934568
0x7f769ce95bd0:   00300020 7f769ce95f20
0x7f769ce95be0:   7f769ce95e60 36805df85b98de00
0x7f769ce95bf0:    7f7694357ce0
0x7f769ce95c00:    7f769ce95d70
0x7f769ce95c10:   7f7697726640 7f769ce95e40
0x7f769ce95c20:   7f7694357fa0 7f76462ca1a4
0x7f769ce95c30:   7f7694357fa0 7f76462ca070
0x7f769ce95c40:   7f7697c22600 0001
0x7f769ce95c50:   7f760002 7f7645fdf119
0x7f769ce95c60:   7f764002 7f7645fdf119
0x7f769ce95c70:   7f769436b910 7f7697726640
0x7f769ce95c80:   7f769430cc70 7f7694358030
0x7f769ce95c90:   7f769ce95e30 7f769ce95d40
0x7f769ce95ca0:    7f7694357ce0
0x7f769ce95cb0:   7f7694357fc0 7f76462e4391
0x7f769ce95cc0:   7f769ce95df0 64a0
0x7f769ce95cd0:   7f7697c22600 7f769ce95d70

Instructions: (pc=0x7f761fcbfd56)
0x7f761fcbfd36:   26 05 21 00 66 0f 1f 44 00 00 53 48 89 fb e8 d7
0x7f761fcbfd46:   f3 ff ff 48 85 db 74 1c 48 8b 13 48 85 d2 74 05
0x7f761fcbfd56:   48 3b 02 74 2d 48 89 c6 48 89 df e8 3a 2b f1 ff
0x7f761fcbfd66:   85 c0 75 1e 5b 48 8d 15 a6 f3 27 00 48 8d 35 97

.


I upgraded JDK 1.8.0 from version 101 to 111, but there was no effect - 
the IDE

still crashes.

But it seems that downgrading libgtk-3 from version 3.22.2-1 to
libgtk-3-0_3.22.1-1_amd64.deb and libgtk-3-bin_3.22.1-1_amd64.deb fixes the
crash.

I am using Debian Stretch, kernel 4.7.0-1-amd64, last upgrade at November 2,
2016.




-- 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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme  3.22.0-1
ii  hicolor-icon-theme  0.15-1
ii  

Bug#842505: closed by Scott Kitterman <deb...@kitterman.com> (already not in unstable)

[Otto Kekäläinen]

Hello!

2016-11-09 23:58 GMT+02:00 Mattia Rizzolo :
> |trying: -mariadb-client-lgpl
> |skipped: -mariadb-client-lgpl (6, 13, 19)
> |got: 47+0: a-7:i-24:a-4:a-0:a-0:m-0:m-11:m-0:p-0:s-1
> |* arm64: haxe, mercurial-buildpackage, neko, r-cran-rmysql
>
>
> Fix that, then mariadb-client-lgpl will be removed from testing too, and
> then mariadb-connector-c will migrate.

Thanks for the dak command example and explaining this. I now filed
Bug#843841 and Bug#843842 against neko and rmysql to get their
dependencies updated.

- Otto

Bug#840468: mame: FTBFS[arm64]: immediate value out of range 0 to 63

[Graham Inggs]

This should be fixed in gcc-6 6.2.0-13 now.

Bug#843844: Potentially missing files from mariadb-10.0 packages

[Otto Kekäläinen]

Package: mariadb-10.0
Severity: wishlist

I ran the mariadb-10.0 build with option 'dh --list-missing' and got
the output below. Are any of the non-installed files perhaps files we
should install? If so, in which package?

My notes:
- example configs are outdated anyway, probably no point including them at all
- server doc files should maybe be included in mariadb-server-core-10.0?
- the man pages are (at least most of them) already included, but
maybe the syntax in *.manpages is wrong or something when dh_install
does not detect this fact
- usr/bin/tokuft_logprint should maybe go into the mariadb-plugin-tokudb package
- usr/bin/mysqlbug should NOT be included, as it is a tool to submit
bugs to Oracle
- mytop maybe?
- sqlbench config files should NOT be included, they are only useful
if the sql-bench-runner and other stuff from
http://bazaar.launchpad.net/~maria-captains/mariadb-tools/trunk/files
are installed

What do others think?

dh_install: etc/mysql/conf.d/dialog.cnf exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/mysql/magic exists in debian/tmp but is not
installed to anywhere
dh_install: usr/share/mysql/my-innodb-heavy-4G.cnf exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/mysql/my-medium.cnf exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/mysql/my-huge.cnf exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/mysql/mysql-log-rotate exists in debian/tmp but
is not installed to anywhere
dh_install: usr/share/mysql/binary-configure exists in debian/tmp but
is not installed to anywhere
dh_install: usr/share/mysql/my-large.cnf exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/mysql/mysql.server exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/mysql/mysqld_multi.server exists in debian/tmp
but is not installed to anywhere
dh_install: usr/share/mysql/my-small.cnf exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/mysql/mysql-test/mysql-test-run exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/mysql/mysql-test/unstable-tests exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/mysql/mysql-test/mtr exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/mysql/SELinux/RHEL4/mysql.te exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/mysql/SELinux/RHEL4/mysql.fc exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/EXCEPTIONS-CLIENT exists
in debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/PATENTS exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/COPYING.GPLv2 exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/COPYING.AGPLv3 exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/README exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/COPYING exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/CREDITS exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/INSTALL-BINARY exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/doc/mariadb-server-10.0/COPYING.LESSER exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/man/man1/mysqltest_embedded.1 exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/man/man1/mysql_tzinfo_to_sql.1 exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/man/man1/mysqladmin.1 exists in debian/tmp but
is not installed to anywhere
dh_install: usr/share/man/man1/mysqltest.1 exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/man/man1/aria_chk.1 exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/man/man1/mysql_waitpid.1 exists in debian/tmp
but is not installed to anywhere
dh_install: usr/share/man/man1/mysql_zap.1 exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/man/man1/mysql_find_rows.1 exists in debian/tmp
but is not installed to anywhere
dh_install: usr/share/man/man1/myisampack.1 exists in debian/tmp but
is not installed to anywhere
dh_install: usr/share/man/man1/mysqld_safe.1 exists in debian/tmp but
is not installed to anywhere
dh_install: usr/share/man/man1/resolve_stack_dump.1 exists in
debian/tmp but is not installed to anywhere
dh_install: usr/share/man/man1/perror.1 exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/man/man1/mysql_config.1 exists in debian/tmp but
is not installed to anywhere
dh_install: usr/share/man/man1/aria_pack.1 exists in debian/tmp but is
not installed to anywhere
dh_install: usr/share/man/man1/myisamchk.1 exists in 

Bug#843809: check that executables don't link to libraries in /usr is broken wrt libsystemd-shared

[Martin Pitt]

Martin Pitt [2016-11-09 22:55 +0100]:
> +1 on dropping the check again.

Done so in git, FTR.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#843843: linux-kernel: Transcend USB 3.0 PCIE card reports ERROR Transfer event

[Adrian Immanuel Kiess]

Package: linux-kernel
Version: linux-image
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 Transfering large data sets to USB 3.0 hard drive connected to Transcend
USB 3.0 adapter
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Running storebackup
   * What was the outcome of this action?
 Kernel (syslog) reports ERROR Transfer event for disabled endpoint or
incorrect stream ring
   * What outcome did you expect instead?
 No message in syslog

when running my daily backup with storebackup.pl to an USB 3.0 Seagate drive
connected over an Transcend USB 3.0 controller syslog repeatedly reports the
following error:

Nov  9 22:30:35 g6 kernel: [1612362.282588] xhci_hcd :10:00.0: ERROR
Transfer event for disabled endpoint or incorrect stream ring
Nov  9 22:30:35 g6 kernel: [1612362.282595] xhci_hcd :10:00.0:
@000428ec1dc0   1b00 07038000
Nov  9 22:31:40 g6 kernel: [1612427.289774] xhci_hcd :10:00.0: ERROR
Transfer event for disabled endpoint or incorrect stream ring
Nov  9 22:31:40 g6 kernel: [1612427.289780] xhci_hcd :10:00.0:
@000428ec12a0   1b00 07038000
Nov  9 22:32:45 g6 kernel: [1612492.285646] xhci_hcd :10:00.0: ERROR
Transfer event for disabled endpoint or incorrect stream ring
Nov  9 22:32:45 g6 kernel: [1612492.285656] xhci_hcd :10:00.0:
@000428ec1780   1b00 07038001
Nov  9 22:33:50 g6 kernel: [1612557.313806] xhci_hcd :10:00.0: ERROR
Transfer event for disabled endpoint or incorrect stream ring
Nov  9 22:33:50 g6 kernel: [1612557.313812] xhci_hcd :10:00.0:
@000428ec1c60   1b00 07038000
Nov  9 22:34:55 g6 kernel: [1612622.273893] xhci_hcd :10:00.0: ERROR
Transfer event for disabled endpoint or incorrect stream ring
Nov  9 22:34:55 g6 kernel: [1612622.273899] xhci_hcd :10:00.0:
@000428ec1130   1b00 07038000

Thank you very much for your efforts.

Sincerely,

Adrian Immanuel Kiess
http://www.immanuelK.net



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

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

Bug#843842: Update build dependency to libmariadb-dev in rmysql

[Otto Kekäläinen]

Package: rmysql
Severity: important

The package RMySQL currently has this build dependency:
   libmariadb-client-lgpl-dev

The MariaDB Connector C package has been renamed about 4 months ago.
Please update the dependency to
   libmariadb-dev

The dependency on the old package from stops the mariadb-connector-c
from migrating to testing
(https://tracker.debian.org/pkg/mariadb-connector-c) thus I marked
this 'important'.

Thanks!

(And sorry for the inconvenience we caused by renaming the package.)

Bug#843841: Update build dependency to libmariadb-dev-compat in neko

[Otto Kekäläinen]

Package: neko
Severity: important

The package Neko currently has this build dependency:
  libmariadb-client-lgpl-dev-compat | libmysqlclient-dev

The MariaDB Connector C package has been renamed about 4 months ago.
Please update the dependency to
   libmariadb-dev-compat | default-libmysqlclient-dev

The dependency on the old package from Neko stops the
mariadb-connector-c from migrating to testing
(https://tracker.debian.org/pkg/mariadb-connector-c) thus I marked
this 'important'.

The package haxe depends on neko and the package
mercurial-buildpackage depends on haxo, so this change in neko will
cascade in fixing all of those packages.

Thanks!

(And sorry for the inconvenience we caused by renaming the package.)

Bug#645895: ftp.debian.org: epoch should be part of the .deb file name

[Johannes Schauer]

Hi,

On Fri, 24 Feb 2012 01:10:45 +0100 Ansgar Burchardt  wrote:
> Tollef Fog Heen  writes:
> > It's a bit confusing that the file names of .debs don't contain the
> > epoch.  I think we should change that.
> >
> > I would suggest %-encoding it, so foo-1:1 becomes foo_1%251_all.deb.
> > The reason to not include a : verbatim is it won't work correctly on all
> > file systems (: gets translated to / in the UI on Mac OS X and is
> > disallowed for at least FAT, I'm not sure about NTFS).  Also, : is
> > traditionally how you reference remote files and devices with tar and
> > scp (and probably more tools), so avoiding : in files names seem
> > prudent.
> 
> This will break some existing tools and I don't see what we gain from
> this, esp. when we still need to encode the : in some other way.  I'm
> therefore tagging this bug as wontfix.

being the author of such a tool (debrebuild, see #774415), I'm using the
following code snippet to go from source package name, version tuple to .dsc
filename:

my $srcpkg = Dpkg::Source::Package->new();
$srcpkg->{fields}{'Source'} = $srcpkgname;
$srcpkg->{fields}{'Version'} = $version;
my $dsc_fname = $srcpkg->get_basename(1) . ".dsc";

Should the encoding ever get changed, using above snippet will (hopefully)
prevent any breakage in my tool because I rely on libdpkg-perl doing the job
for me. Other tools relying on this mapping should consider doing the same
instead of re-implementing this.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#843838: Fail to access config file

[Jörg Frings-Fürst]

Hi,

the directory listing /etc/bacula:


# 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
-rw-r- 1 root   root1127 Aug 18 14:12 bacula-fd.conf.dist
-rw-r- 1 bacula dirmngr 3338 Sep 12  2014 bacula-sd.conf
-rw-r- 1 bacula bacula  8070 Aug 18 14:12 bacula-sd.conf.dist
-rw-r- 1 root   dirmngr  175 Feb 24  2014 bat.conf
-rw-r- 1 root   bacula   180 Aug 18 14:12 bat.conf.dist
-rw-r- 1 root   dirmngr  172 Sep 29  2013 bconsole.conf
-rw-r- 1 root   bacula   266 Aug 18 14:12 bconsole.conf.dist
-rw--- 1 root   root 442 Feb 24  2014 common_default_passwords
-rw--- 1 root   dirmngr  442 Dez 12  2013 common_default_passwords.dist
-rw-r- 1 root   dirmngr  926 Okt 20  2014 filesets.conf
drwxr-xr-x 2 root   root4096 Nov  9 06:13 scripts
-rw-r- 1 root   dirmngr 3396 Sep 12  2014 server-ixion.conf
-rw-r- 1 root   dirmngr 3433 Mai  1  2014 server-neptun.conf
-rw-r- 1 root   dirmngr  583 Apr 18  2014 tray-monitor.conf
-rw-r- 1 root   dirmngr  583 Dez 12  2013 tray-monitor.conf.dist
-rw-r- 1 root   dirmngr 3590 Feb 20  2016 ws-merkur.conf
-rw-r- 1 root   dirmngr 3436 Mai  2  2014 ws-triton.conf
-rw-r- 1 root   dirmngr 3127 Mai  1  2014 ws-zaubermaus.conf

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#839029: [Pkg-libvirt-maintainers] Bug#839029: virt-manager shows no menu and context menu only underline

[Guido Günther]

control: -1 blockedy-by 843810

On Wed, Nov 09, 2016 at 08:13:04PM +0100, Guido Günther wrote:
> Hi,
> On Wed, Nov 09, 2016 at 02:59:03PM +0100, Marc-Christian Petersen wrote:
> > Hi,
> > 
> > I have the same problem. It does not affect virt-manager alone, also
> > Firefox does not show any menu.
> > 
> > I've downgraded gtk3 down to 3.20.9-1, that made it work again. All
> > versions above have the problem that virt-manager, Firefox and maybe
> > also others do not show the menu.
> > 
> > Please tell me how to help/debug that so we can fix that issue.
> 
> If it happens with several programs and a gtk+ downgrade fixes it then
> it would be great if you could take this up with the GTK+
> maintainers. Maybe they have an idea whats broken. Please keep the
> bugreport (and me) in cc:

The corresponding GTK+ bug is 843810. Thanks!

Bug#843840: DEP14: Support dot escaping via '#'

[Guido Günther]

Package: git-buildpackage
Version: 0.8.6
Severity: minor

See the recent dep14 extension proposal.

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

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

Versions of packages git-buildpackage depends on:
ii  devscripts2.16.8
ii  git   1:2.10.2-1
ii  man-db2.7.5-1
ii  python-dateutil   2.5.3-2
ii  python-pkg-resources  28.0.0-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.81
ii  pbuilder 0.226.1
ii  pristine-tar 1.37
ii  python-requests  2.11.1-1
ii  sbuild   0.72.0-2

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  sudo   1.8.17p1-2
ii  unzip  6.0-20

-- no debconf information

Bug#843839: RFP: pcb-rnd -- modular, interactive printed circuit board designer, compatible with gEDA/PCB and kicad and various other import/export formats.

[debbug]

Package: wnpp
Severity: wishlist

* Package name: pcb-rnd
  Version : 1.1.3
  Upstream Author : Tibor Palinkas (deb...@igor2.repo.hu)
* URL : http://repo.hu/projects/pcb-rnd
* License : GPLv2+
  Programming Lang: C
  Description : modular, interactive printed circuit board designer, 
compatible with gEDA/PCB and kicad and various other import/export formats.

pcb-rnd is an interactive printed circuit board editor for the X11 window 
system. pcb-rnd includes a rats nest feature, design rule checking, and can 
provide industry standard RS-274-X (Gerber), NC drill, and centroid data 
(X-Y data) output for use in the board fabrication and assembly process.


pcb-rnd is load/save compatible with gEDA/PCB and kicad and offers various
auxiliary import/export formats.

Originally forked from gEDA/PCB.

Why is this package useful/relevant: pcb-rnd is an actively developed 
alternative
to already packaged pcb. It offers a lot more features, including compatibility
with kicad.

Is it a dependency for another package: no.

Do you use it: yes. I am also the lead developer.

If there are other packages providing similar functionality: yes; pcb and kicad

How does it compare: vs pcb: pcb-rnd is much more modular and offers
more features. An almost complete summary of the extra features can
be found at: http://repo.hu/projects/pcb-rnd/features . Kicad: pcb-rnd
is much smaller with fewer dependencies; more suitable for scripted/automated
processing.

How do you plan to maintain it: I am currently maintaining a set of
home-grown debian packages, part of the upstream repository.

Are you looking for co-maintainers/sponsor: yes.

Bug#843838: Fail to access config file

[Jörg Frings-Fürst]

Package: bacula-director
Version: 7.4.4+dfsg-3
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

after upgrade baculu bacule-director don't start anymore.

Nov 10 07:39:29 merkur systemd[1]: Starting Bacula Director Daemon service...
Nov 10 07:39:29 merkur bacula-dir[24610]: bacula-dir: ERROR TERMINATION at
parse_conf.c:919
Nov 10 07:39:29 merkur bacula-dir[24610]: Config error: Cannot open config file
"/etc/bacula/bacula-dir.conf": Keine Berechtigung
Nov 10 07:39:29 merkur bacula-dir[24610]: 10-Nov 07:39 bacula-dir: ERROR
TERMINATION at parse_conf.c:919
Nov 10 07:39:29 merkur bacula-dir[24610]: Config error: Cannot open config file
"/etc/bacula/bacula-dir.conf": Keine Berechtigung
Nov 10 07:39:29 merkur systemd[1]: bacula-director.service: Control process
exited, code=exited status=1
Nov 10 07:39:29 merkur systemd[1]: Failed to start Bacula Director Daemon
service.
Nov 10 07:39:29 merkur systemd[1]: bacula-director.service: Unit entered failed
state.
Nov 10 07:39:29 merkur systemd[1]: bacula-director.service: Failed with result
'exit-code'.





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

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

Versions of packages bacula-director depends on:
ii  bacula-common  7.4.4+dfsg-3
ii  bacula-director-mysql  7.4.4+dfsg-3
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-3
ii  init-system-helpers1.45
ii  libc6  2.24-5
ii  libcap21:2.25-1
ii  libgcc11:6.2.0-10
ii  libssl1.0.21.0.2j-1
ii  libstdc++6 6.2.0-10
ii  libwrap0   7.6.q-25
ii  lsb-base   9.20161101
ii  ucf3.0036
ii  zlib1g 1:1.2.8.dfsg-2+b3

bacula-director recommends no packages.

Versions of packages bacula-director suggests:
pn  bacula-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYJBd7AAoJEAn4nzyModJdEP4QAI9Sud21FefTt6l0SXzBmBsq
Fqu7EAF+0xgHUE0S+1JaVLV8DyjGtGNiQi06vKWC6AdExJG21MeoVmeQrs42pqYS
7kRfGNlUsvg/hYKQa+tO1pJcUW7Qw7uw9jbzUUA7s1jBecIBFi28V+s9W9ai0rtR
Og46QbQ81j/x6P4OnZ86MM6L4/RbRxWq+C9QRo0NjGju52JSvtCFTjKdEGguBYSZ
Wc0yCrI+L2Ncbh6WJqdp0xMA8B8vKQw12BrJxYur0E++ZBeXbNMGbAgnrfz3HvRJ
qWxOmqO0R2Zh+ZdgHvdd50+Zm/IqiZVORd8lEoNd9T5KHYWrxBSei3yyNN+b0oGK
nFgPm0YRpf3x6dKKkIuCov8Qg458rkbOWx45BJeU40BBkVovcBc7+wEvREfGLKgs
CtamdWJUQtmu3tPUYh/4rloZdnq3rvY89tShGa6tUIWFblw85gl9zeVssrZo5OSC
JorkJdn9HJ9KFunmqR4I0i+uaCdZOnLZD8YKBt1sK1GNxBP4XbIaEb7JnfZM2vrq
ap7dH84sdXPHoLkX9vG6UcNYzFASR/0X0EbXeNWdEYBsZBG8VDdizam3oOu+zV9w
7nki7PHvQxinkLX8QIMVr5ZKCTIPUTv3pl9netMAy75/FhL89wgYrjBmL6aBhWLx
RyqFIztZEZgYA344ldDc
=hKUx
-END PGP SIGNATURE-

Bug#801080: Red and black dots in the splash screen graphics

[Miroslav Urbanek]

On Sun, Nov 15, 2015 at 03:14:36PM +0100, Laurent Bigonville wrote:
> To be honest, if the bug is really in gcc I don't think that it
> should be worked around at the package level.

Bug #799953 was resolved as "non-bug". It was suggested to use GCC
option "-fexcess-precision=standard". I tested plymouth on i386 with
this option and it really fixes the issue.

MU

Bug#843837: libxft-dev: Xft/Xft.h header incorrectly includes ft2build.h

[Oleksiy]

Package: libxft-dev
Version: 2.3.2-1
Severity: normal
Tags: upstream

Dear Maintainer,

   * What led up to the situation?
  Tried to build Motif from sources.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
  Take Motif sources and run configure && make

   * What was the outcome of this action?
  Compilation error:
make[3]: Entering directory '/home/alex/heap/motif.sf.git/lib/Xm'
/bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../include -I.. -I./.. -DXMBINDDIR_FALLBACK=\"/usr/lib/X11/bindings\"
-DINCDIR=\"/usr/include/X11\" -DLIBDIR=\"/usr/lib/X11\" -O0 -g3 -Wall -g
-fno-strict-aliasing -Wno-unused -Wno-comment -fno-tree-ter  -MT Label.lo -MD
-MP -MF .deps/Label.Tpo -c -o Label.lo Label.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I.. -I./..
-DXMBINDDIR_FALLBACK=\"/usr/lib/X11/bindings\" -DINCDIR=\"/usr/include/X11\"
-DLIBDIR=\"/usr/lib/X11\" -O0 -g3 -Wall -g -fno-strict-aliasing -Wno-unused
-Wno-comment -fno-tree-ter -MT Label.lo -MD -MP -MF .deps/Label.Tpo -c Label.c
-fPIC -DPIC -o .libs/Label.o
In file included from XmRenderTI.h:33:0,
 from Label.c:77:
/usr/include/X11/Xft/Xft.h:39:22: fatal error: ft2build.h: No such file or
directory
 #include 
  ^
compilation terminated.
Makefile:1048: recipe for target 'Label.lo' failed
make[3]: *** [Label.lo] Error 1
make[3]: Leaving directory '/home/alex/heap/motif.sf.git/lib/Xm'

   * What outcome did you expect instead?
  Motif should compile without errors.


/usr/include/X11/Xft/Xft.h from the package libxft-dev. This header has include
string:


#include 


on line 39.

This is incorrect. Since ft2build.h is installed in
  /usr/include/freetype2
dir, the include macro must be the following:

  #include 




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

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

Versions of packages libxft-dev depends on:
ii  libc6-dev [libc-dev]   2.19-18+deb8u6
ii  libfontconfig1-dev 2.11.0-6.3+deb8u1
ii  libfreetype6-dev   2.5.2-3+deb8u1
ii  libx11-dev 2:1.6.2-3
ii  libxft22.3.2-1
ii  libxrender-dev 1:0.9.8-1+b1
ii  zlib1g-dev [libz-dev]  1:1.2.8.dfsg-2+b1

libxft-dev recommends no packages.

libxft-dev suggests no packages.

-- no debconf information

Bug#843836: /usr/bin/gnome-disks: HDD spin-down with standby timeout/APM disabled

[Fulano Diego Perez]

Package: gnome-disk-utility
Version: 3.22.0-1
Severity: normal
File: /usr/bin/gnome-disks


standby = never

APM level = 254 spin down not permitted

write cache = enabled

---

a non-SSD HDD spins down when on battery power discharging after approx.
5 mins

why would this spin-down occur ?

i dont believe it occurs when on AC



-- 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/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-disk-utility depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo-gobject21.14.6-1+b1
ii  libcairo21.14.6-1+b1
pn  libcanberra-gtk3-0   
pn  libcanberra0 
ii  libdvdread4  5.0.3-2
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.1-1
ii  libgtk-3-0   3.22.2-1
ii  liblzma5 5.2.2-1.2
ii  libnotify4   0.7.7-1
ii  libpango-1.0-0   1.40.3-2
ii  libpangocairo-1.0-0  1.40.3-2
pn  libpwquality1
pn  libsecret-1-0
ii  libsystemd0  231-9
ii  libudisks2-0 2.1.7-3
ii  libx11-6 2:1.6.3-1
ii  udisks2  2.1.7-3

gnome-disk-utility recommends no packages.

gnome-disk-utility suggests no packages.

-- no debconf information

Bug#843835: UDD: expose an API for upstream versions to rmadison

[Paul Wise]

Package: qa.debian.org
User: qa.debian@packages.debian.org
Usertags: udd madison watch
Severity: wishlist
Control: affects -1 devscripts

It would be nice if the UDD watch file scanning service had a madison
frontend that could be added to rmadison so that one could get the
upstream version of a package from the command-line.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#843773: sbuild should use build date as binnmu changelog date

[Johannes Schauer]

Hi Ian and reproducible-builds folks,

On Wed, 9 Nov 2016 12:03:48 + Ian Jackson  
wrote:
> Currently, when adding a changelog stanza for a binnmu (or when appending to
> the version number is requested for another reason), sbuild uses the existing
> source changelog timestamp when inventing the changelog entry for the binnmu
> itself:
> 
> http://sources.debian.net/src/sbuild/0.72.0-2/lib/Sbuild/Build.pm/#L2005
> 
> This causes problems because it means that (in the usual case) the
> rebuilt package has files with the same timestamps as the previous
> build, but different contents.  So on the end system, the timestamps
> cani be misleading, causing malfunction of backup programs etc.  (Eg
> an upgrade to a binnmu would be captured only partially in a backup,
> leading to lossage.)
> 
> AIUI there were two reasons why this particular timestamp was (might
> have been) chosen:
> 
> Firstly, part of an early attempt to assist multiarch by making all
> the changelogs identical on different architectures.  But in fact, the
> changelog is not identical in any case (because different
> architectures may have differently version-numbered binnmus).  So the
> binnmu changelog entry is nowadays put in a separate file, and need
> not be the same on different architectures.
> 
> Secondly, an attempt to assist reproducible builds.  But the
> reproducible build output necessarily includes the complete binnmu
> changelog entry; therefore the complete binnmu changelog entry is an
> input to a repro-build attempt.  It is indeed contained in the
> Binary-Only-Changes field of the .buildinfo.
> 
> Subsequent binnmu builds of the same package should generate packages
> containing increasing timestamps.  The best timestamp to use is the
> timestamp of the build attempt.
> 
> So, sbuild should use `date -R`[1] instead of the date from the last
> changelog entry in the source package, when generating the binnmu
> changelog entry.
> 
> [1] Actually, sbuild seems to have a tweakable parameter
> "Pkg Start Time" which looks like it would be appropriate, so
> something like this:
>my $date = strftime_c "%FT%TZ", gmtime($self->get('Pkg Start Time'));

thanks for putting all the relevant information from the original thread on
debian-devel into this bug report in an organized manner!

While "Pkg Start Time" might be a good default, I guess for to be able to
reproduce a binNMU it would be necessary to also allow the user to pass a
custom timestamp.

I propose to add the command line option --binNMU-date and use that or, if the
command line option is not given, the value from the environment variable
SOURCE_DATE_EPOCH.

The --binNMU-date option can then also be used by debrebuild.pl (see #774415).

Does that sound like an acceptable fix?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#843791: ghc: builds fail on hurd-i386: /usr/bin/ld: -r and -pie may not be used together

[Guillem Jover]

Hi!

On Thu, 2016-11-10 at 01:21:11 +0100, Samuel Thibault wrote:
> Clint Adams, on Wed 09 Nov 2016 17:08:23 +, wrote:
> > On Wed, Nov 09, 2016 at 05:47:13PM +0100, Samuel Thibault wrote:
> > > It seems the latest ghc has troubles building packages on hurd-i386:
> > > 
> > > [ 1 of 18] Compiling Data.Streaming.Zlib.Lowlevel ( 
> > > Data/Streaming/Zlib/Lowlevel.hs, 
> > > dist-ghc/build/Data/Streaming/Zlib/Lowlevel.o )
> > > ...
> > > [18 of 18] Compiling Data.Streaming.Text ( Data/Streaming/Text.hs, 
> > > dist-ghc/build/Data/Streaming/Text.o )
> > > [ 1 of 18] Compiling Data.Streaming.Zlib.Lowlevel ( 
> > > Data/Streaming/Zlib/Lowlevel.hs, 
> > > dist-ghc/build/Data/Streaming/Zlib/Lowlevel.p_o )
> > > /usr/bin/ld: -r and -pie may not be used together
> > 
> > That's confusing.
> 
> This seems to be triggered by the newer dpkg, which apparently emits
> -pie itself on hurd-i386: on my not-so-up-to-date box I hadn't the
> issue, and after upgrading dpkg I got the issue on my box too.
> 
> dpkg maintainers: ghc does emi -no-pie, but it seems dpkg's -pie
> overrides it.

Ok, could you try the following patch for the specs files? That's be
appreciated. I've tested those standalone on the Hurd with a synthetic
test file, but not as part of GHC build or similar.

> I'm however surprised that dpkg adds -pie on hurd-i386 too: AIUI hurd's
> gcc does have pie enabled by default too.

Very unfortunately nope, supposedly only architectures for which
porters requested it to be enabled, which means we have a mess of
arches that do PIE by default and others that do not. :(

  

If you request it to be enabled on Hurd (which I think would be way
ideal), please let me know and I'll mark it as such in dpkg-dev. :)

Thanks,
Guillem
diff --git i/data/no-pie-compile.specs w/data/no-pie-compile.specs
index f85b394..2277b97 100644
--- i/data/no-pie-compile.specs
+++ w/data/no-pie-compile.specs
@@ -1,2 +1,2 @@
-*cc1_options:
+*self_spec:
 + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fno-PIE}}
diff --git i/data/no-pie-link.specs w/data/no-pie-link.specs
index 15243a0..54db649 100644
--- i/data/no-pie-link.specs
+++ w/data/no-pie-link.specs
@@ -1,2 +1,2 @@
 *self_spec:
-+ %{!shared:%{!r:-fno-PIE -no-pie}}
++ %{!shared:%{!r:%{!fPIE:%{!pie:-fno-PIE -no-pie
diff --git i/data/pie-compile.specs w/data/pie-compile.specs
index fc54bcb..74d8215 100644
--- i/data/pie-compile.specs
+++ w/data/pie-compile.specs
@@ -1,2 +1,2 @@
-*cc1_options:
-+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
+*self_spec:
++ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:%{!fno-PIE:%{!no-pie:-fPIE
diff --git i/data/pie-link.specs w/data/pie-link.specs
index a5e0fe4..35d26e1 100644
--- i/data/pie-link.specs
+++ w/data/pie-link.specs
@@ -1,2 +1,2 @@
 *self_spec:
-+ %{!shared:%{!r:-fPIE -pie}}
++ %{!shared:%{!r:%{!fno-PIE:%{!no-pie:-fPIE -pie

Bug#842454: [debian-mysql] Bug#842454: Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

[Helmut Grohne]

On Wed, Nov 09, 2016 at 11:33:07PM +0200, Otto Kekäläinen wrote:
> Or if we move the plugins to a separate package, called maybe
> mariadb-plugin-clientauth that would contain these two files? Then the
> libmariadbclient18 package would stay "clean". I would however need to
> depend on the mariadb-plugin-clientauth package however..

I note that this way resolves the policy issue if and only if those
plugins are ABI-compatible across multiple ABI-incompatible mariadb
releases. The purpose of having no unversioned files in the shared
library package is to have them coinstallable (e.g. libmariadbclient18
and libmariadbclient19). If they depend on a mariadb-plugin-clientauth,
then libmariadbclient18 must work with at least the next version of
those plugins after an ABI bump. Is that a reasonable assumption?

If instead you were to depend on mariadb-plugin-clientauth-$VER and
would have those mariadb-plugin-client-auth-$VER packages conflict with
each other, then policy would still be violated in spirit, because you
cannot install libmariadbclient18 and libmariadbclient19 due to
conflicting dependencies.

Solving this now will make the next ABI bump much less painful.

> And it was still unclear to me if the libmariadbclient18 and
> libmariadbd packages should have "Multi-Arch: same" or what? That is
> what we strive for with the above changes, right?

The plugin location issues are kinda orthogonal. Moving the plugins is
required by the policy to better support ABI bumps, not to support
multiarch. It just happens that multiarch benefits from that. In
general, trying to make lib* packages Multi-Arch: same is a good idea.

In terms of multiarch, having mariadb-plugin-clientauth is probably not
useful. You can mark libmariadbclient18 Multi-Arch: same after moving
those plugins, but since libmariadbclient18 will depend on
mariadb-plugin-clientauth, it can only be coinstalled for multiple
architectures if mariadb-plugin-clientauth can. The latter doesn't use
multiarch paths, so it cannot become Multi-Arch: same. Thus this split
is not useful to multiarch and still might resolve the policy issue.

Really, the only way to make libmariadbclient18 client useful with
multiarch is to move these plugins to architecture-specific locations.
If that cannot be done, its multiarch capability will be severely
limited. It's not entirely clear how much multiarch we actually need
though. Only after switching default-libmysqlclient-dev to Arch:any will
we see how many source packages will need libmariadbclient18 to be
Multi-Arch: same for cross compiling (and the answer usually is "few").
You shall find the detailed answer on
http://bootstrap.debian.net/cross_all.html (<- huge) approximately one
week after uploading default-libmysqlclient-dev.

Helmut

Bug#843826: PIE specs file leads to segfaults on sparc64

[Guillem Jover]

Hi!

On Wed, 2016-11-09 at 23:46:42 +, James Clarke wrote:
> Package: dpkg-dev
> Version: 1.18.13
> Severity: important
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> X-Debbugs-Cc: debian-sp...@lists.debian.org

> Unfortunately, your new specs files lead to segfaults on sparc64:
> 
> > $ cat exit.c
> > #include 
> >
> > int main(int argc, char **argv) {
> > exit(1);
> > return 2;
> > }
> > $ gcc -specs=/usr/share/dpkg/pie-compile.specs -c exit.c -o exit.o
> > $ gcc -specs=/usr/share/dpkg/pie-link.specs exit.o -o exit
> > $ ./exit
> > Segmentation fault
> 
> This is because, while cc1 is given -fPIE, as is not given anything. For
> most architectures, this is actually fine, but on SPARC, as *must* be
> given -K PIC. When looking at strace, this is the only difference
> between gcc -specs=... and gcc -fPIE for compiling. Otherwise, what
> happens is the assembler does not emit a PLT call, instead leaving the
> call address as an immediate to be filled in by a 30-bit relocation,
> which doesn't fit at runtime (with this particular example, libc was
> loaded such that exit was at 0xfff80001001624e0) and gets truncated.
> Note that the linker invocation itself is fine; it was just given bad
> input (although perhaps this is something it could have caught and given
> an error message?).
> 
> As far as I can tell, changing the cc1_options to self_spec in
> (no-)pie-compile.specs should work fine. It certainly fixes the problem
> here, and off the top of my head, I can't think of any issues this would
> cause.

Thanks for the analysis! I've done several changes to the specs, I've
tried on a powerpc schroot I had already lying around due to another
report, if you could test on sparc64 that would be appreciated!

Attached the changes.

Thanks,
Guillem
diff --git i/data/no-pie-compile.specs w/data/no-pie-compile.specs
index f85b394..2277b97 100644
--- i/data/no-pie-compile.specs
+++ w/data/no-pie-compile.specs
@@ -1,2 +1,2 @@
-*cc1_options:
+*self_spec:
 + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fno-PIE}}
diff --git i/data/no-pie-link.specs w/data/no-pie-link.specs
index 15243a0..54db649 100644
--- i/data/no-pie-link.specs
+++ w/data/no-pie-link.specs
@@ -1,2 +1,2 @@
 *self_spec:
-+ %{!shared:%{!r:-fno-PIE -no-pie}}
++ %{!shared:%{!r:%{!fPIE:%{!pie:-fno-PIE -no-pie
diff --git i/data/pie-compile.specs w/data/pie-compile.specs
index fc54bcb..74d8215 100644
--- i/data/pie-compile.specs
+++ w/data/pie-compile.specs
@@ -1,2 +1,2 @@
-*cc1_options:
-+ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
+*self_spec:
++ %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:%{!fno-PIE:%{!no-pie:-fPIE
diff --git i/data/pie-link.specs w/data/pie-link.specs
index a5e0fe4..35d26e1 100644
--- i/data/pie-link.specs
+++ w/data/pie-link.specs
@@ -1,2 +1,2 @@
 *self_spec:
-+ %{!shared:%{!r:-fPIE -pie}}
++ %{!shared:%{!r:%{!fno-PIE:%{!no-pie:-fPIE -pie

Bug#519867: [Buildd-tools-devel] Bug#519867: sbuild: run edos-debcheck in case of build failure due to dependency installation

[Johannes Schauer]

Control: forcemerge 839566 -1

Hi,

On Tue, 07 Jun 2016 22:25:32 +0200 Johannes Schauer  wrote:
> Hi,
> 
> On Fri, 25 Dec 2015 19:44:09 +0100 Johannes Schauer  wrote:
> > In summary, the following should work:
> > 
> > apt-cache dumpavail | dose-debcheck -v -f -e 
> > sbuild-build-depends-yourpackage-dummy

turns out, that "apt-cache dumpavail" is inadequate because that is subject to
apt pinning and we want dose to not be restricted by apt limitations.

> > Together with --build-deps-failed-commands you can create a hook which does
> > exactly what this bug requests. Would this be sufficient to fix this bug?
> 
> thinking about this a bit more, the above should work but requires
> dose-debcheck and its dependencies to be installed inside the chroot. But
> installing additional packages might influence the result and should thus not
> be done.
> 
> Instead, the output of "apt-cache dumpavail" inside the chroot should be piped
> to dose-debcheck installed outside the chroot. Unfortunately, the
> --build-deps-failed-commands are run inside the chroot and do not offer 
> running
> anything outside the chroot.
> 
> So as originally suggested, it might be necessary to add the functionality to
> sbuild itself. Maybe by sbuild opportunistically running dose-debcheck after
> dependency installation failed and sbuild sees the dose-debcheck binary on
> the host?

it turns out, having forgotten about this bug, I reported #839566 and closed
that one with the last upload, forgetting about this bug.

dose3 is now by default automatically installed and run inside the chroot in
case the build dependencies cannot be satisfied.

To switch this off, you can use --bd-uninstallable-explainer= (giving no
argument).

Besides dose3, another explainer of bd-uninstallability is available: apt.
Dose3 is the default because its output should be more readable than the apt
diagnostics. The apt explainer is available to those who find that one more
readable or to give to apt developers for diagnostics.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#843714: dpkg: /usr/share/dpkg/pie-link.specs breaks statically linked binaries on some architectures

[Guillem Jover]

Hi!

On Wed, 2016-11-09 at 00:34:30 +0100, Hilko Bengen wrote:
> Package: dpkg
> Version: 1.18.13
> Severity: important

> recent rebuilds of supermin on a few architectures (at least powerpc,
> ppc64, sh4, sparc64) failed gcc no longer produces static binaries.
> 
> It looks as if this breakage was introduced when
> "-specs=/usr/share/dpkg/pie-link.specs" became part of the command line
> via LDFLAGS. A quick test on powerpc showed that removing this parameter
> leads to a valid static binary.

I think this is a problem at least in supermin itself. The new dpkg
options enable PIE by default everywhere, but supermin build system is
using file(1) to determine whether the resulting init object has been
statically linked or not. PIE makes binaries look like shared
libraries so I'm assuming file(1) on several of those architecture
might be confused here?

It also seems gcc produces different results depending on whether PIE
is enabled by default. Something like this:

  ,---
  $ cat test.c
  #include 
  int main(int argc, char **argv) {
 printf("test %s %d\n", "foo", 100);
 return 0;
  }
  $ gcc -static -o test test.c
  $ readelf -h test | grep Type
  $ gcc -static -fPIE -pie -o test test.c
  $ readelf -h test | grep Type
  `---

Produces for the readelf calls, EXEC, EXEC for builtin PIE, or
EXEC, DYN for non-builtin PIE. I'd assume this is possibly a problem
in gcc, so I'll file a bug there. In the mean time you might perhaps
want to removed the file check in src/Makefile.am for the
ext2init-bin.S target. So I think I'll reassign this to supermin.

Thanks,
Guillem

Bug#842281: sbuild: --extra-repository cannot be used with --no-apt-update

[Johannes Schauer]

Control: tag -1 + moreinfo

Hi,

On Thu, 27 Oct 2016 19:02:22 +0300 Ilias Tsitsimpis  
wrote:
> Since commit 0e71b40, `--extra-repository' cannot be used with
> `--no-apt-update' (i.e., the extra repositories are not being used).

I would say that this is a feature instead of a bug. Imagine it were the other
way round and sbuild would run "apt-get update" even if --no-apt-update was
specified, then I would get another bug report "sbuild runs apt-get update even
though --no-apt-update was given".

With what justification would you still run "apt-get update" even if
--no-apt-update was passed? I would've said that a user who uses
--extra-repositories just must not use --no-apt-update. Maybe sbuild should
even print a warning if they attempt to do so.

Notice for example, that there also exists the --chroot-update-failed-commands
hook which will only get executed if "apt-get update" failed. A user might not
expect the code given by --chroot-update-failed-commands to be run if
--no-apt-update is in effect. They might experience unexpected side-effects if
that code is still run even though --no-apt-update is passed.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#830509: current status?

[Kamaraju Kusumanchi]

Hi Ben,
What is the current status of this? Could you please package and
upload the latest version of python-gtkspellcheck?

Currently, zim recommeds python-gtkspell. But since that is longer
available, zim should probably recommend python-gtkspellcheck.
However, it seems[1] zim crashes with the 3.0-1.1 version of
python-gtkspellcheck. So, it would be nice if we can upgrade this to
the latest version.

[1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834405

Bug#843834: apt-cacher-ng: SocketPath option is quite broken

[Paul Wise]

Package: apt-cacher-ng
Version: 1-2
Severity: important
Usertags: cron

After the recent upgrade of acng to 1-2 I get this from the cron job:

/etc/cron.daily/apt-cacher-ng:
Error: cannot fetch 
http://chianamo:3142/acng-report.html?doExpire=Start+Expiration=aOe,
 

The page works fine in my web browser.

If I run `acngtool maint` from the cron job as root it fails.
If I run `acngtool maint` from the cron job as pabs it seems to work.

Based on strace it looks like the difference is that as root it tries
to use the socket and that fails while as a user it gets permission
denied and then connects to the TCP port instead.

acngtool is printing the wrong location in the error message, since it
is connecting to the SocketPath instead of the TCP port.

If I drop the SocketPath argument from the `acngtool maint` call then
it works as both root and pabs.

It looks like the issue is that the socket is disabled by default.

# Socket file for accessing through local UNIX socket instead of TCP/IP. Can be
# used with inetd bridge or cron client.
# Default: not set, UNIX socket bridge is disabled.
#
# SocketPath:/var/run/apt-cacher-ng/socket

While SocketPath is disabled by default in the configuration,
SocketPath is enabled by the systemd service:

$ systemctl status apt-cacher-ng.service  | tail -n1
   └─20687 /usr/sbin/apt-cacher-ng SocketPath=/run/apt-cacher-ng/socket 
-c /etc/apt-cacher-ng ForeGround=1

Even when I enable SocketPath in the configuration, acngtool still doesn't work.

-- System Information:
Debian Release: stretch/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 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt-cacher-ng depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.10
ii  init-system-helpers1.45
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.24-5
ii  libgcc11:6.2.0-10
ii  liblzma5   5.2.2-1.2
ii  libssl1.0.21.0.2j-1
ii  libstdc++6 6.2.0-10
ii  libsystemd0231-9
ii  libwrap0   7.6.q-25
ii  lsb-base   9.20161101
ii  zlib1g 1:1.2.8.dfsg-2+b3

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.6.32-1
pn  doc-base  
ii  libfuse2  2.9.7-1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#843833: Could use shlibs bump after introducing symbol versioning

[Dato Simó]

Package: liblua5.1-0
Version: 5.1.5-8.1

A binary built against 5.1.5-8 can run against previous versions
of the library (e.g. jessie's), but it will print a warning:

pandoc: /usr/lib/x86_64-linux-gnu/liblua5.1.so.0: no version information 
available (required by pandoc)

It would be convenient to bump shlibs to avoid this.

-d

Bug#842040: Please add https support

[Martin Michlmayr]

* Roger Shimizu  [2016-10-26 00:59]:
> > So, approximately 780k extra for the initrd image (3.5% increase)
> 
> I'm not sure whether any libs already is included in the d-i image, if
> not, adding 780k extra would definitely affect armel/orion5x qnap d-i
> initrd image.
> 
> So I append Martin, the porter of armel/orion5x qnap, to CC list.

Thanks for the CC.  I just added wget-udeb and it adds 345 KB,
which breaks the orion5x-qnap image.  However, this image is really
quite a special case and I don't want to block https support because
of it.  I can always exclude wget-udeb from this particular image.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#842515: github-backup: FTBFS with newer directory

[James McCoy]

On Sat, Oct 29, 2016 at 10:46:24PM +, Clint Adams wrote:
> Because we've updated GHC to 8.0, the version of the directory library
> has also been updated, and you'll need something like
> https://github.com/joeyh/github-backup/commit/848f6b64f75f4d267ba364405fb2a7b284969020

That's already included in the latest release ... I'm finally able to
install all the build-deps again, so I'll see where else things are
breaking.

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

Bug#843832: needrestart: detect need for a systemctl daemon-reload

[Paul Wise]

Package: needrestart
Severity: wishlist

When systemd service configuration files are modified, there is often a
need to ask the systemd daemons to reload their configuration files:

systemctl daemon-reload
sudo -u uid systemctl --user daemon-reload

The need to reload systemd service configuration files can be detected
using these commands, passing the names of all loaded units.

systemctl --property NeedDaemonReload show name.service other.service
sudo -u uid systemctl --user --property NeedDaemonReload show name.service 
other.service

The list of loaded units can be found using these commands:

systemctl --all list-units
sudo -u uid systemctl --user systemctl --all list-units

Unfortunately it doesn't appear to be machine-parsable.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#843614: Fixed in python-openssl 16.2.0-1?

[Matt Kraai]

Hi,

I was able to use torbrowser-launcher again after upgrading
python-openssl to 16.2.0-1.  The new version ensures that SSL_ST_INIT
is defined before referencing it.  I don't know if that's considered a
fix for this issue, though.

-- 
Matt   https://ftbfs.org/~kraai/

Bug#703216: iputils-ping: ping preload doesn't appear to work as advertised in the man page, works fine when strace'ing it

[michael chesterton]

On 09/11/16 01:11, Noah Meyerhans wrote:

Confirmed that this bug is still present in newer versions.
If behavior is correct when running under strace, that suggests a timing
related issue. I'd guess that what's happening is that if ping receives
and processes a response before it has finished sending the preload
packets then the preload routine is interrupted and it immediately falls
back to standard behavior. But I haven't investigated.

On the other hand, I don't see ping sending more than 12 preload packets
at all, under strace or not. Tried against nearby hosts and remote hosts
on the other end of VPN tunnels (thus with larger RTTs).

noah


this is a blast from the past, I forgot all about it.
atm, I only have debian on a vps, where as when I reported this bug
debian was running on my laptop, and it's now working fine on the vps.
Version: 3:20121221-5+b2

I tested with my new laptop which is running ubuntu
(same ping version as debian i think Version: 3:20121221-5ubuntu2)
and it has the same behaviour as you noted

ie it now preloads 12 before dropping to 1 a second interval,
but I still found it worked OK under strace, which is different
to what you're seeing.

I tested my pi running raspbian, it worked ok
I tested a few random ubuntu boxes, a 14.04 worked ok and a 16.04 had 
the issue.


I think it's related to the network interface, all vps's I tried worked ok
my laptop with wifi didn't work
ubuntu running directly on the hardware didn't work
the pi worked though

Bug#842878: Asterisk crashes with pjproject 2.5.5

[Gedalya]

OK, confirmed.
The patch (r5401) works, we're back with the previous behavior:

[Nov  9 20:43:33] ERROR[14871]: res_pjsip.c:2883 ast_sip_create_dialog_uac: 
Could not create dialog to endpoint '' as URI '' is not valid
[Nov  9 20:43:33] ERROR[14871]: chan_pjsip.c:1947 request: Failed to create 
outgoing session to endpoint ''
[Nov  9 20:43:33] WARNING[14935][C-0001]: app_dial.c:2524 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 3 - No route to destination)
[Nov  9 20:43:33] ERROR[14871]: res_pjsip.c:2883 ast_sip_create_dialog_uac: 
Could not create dialog to endpoint '' as URI '' is not valid
[Nov  9 20:43:33] ERROR[14871]: chan_pjsip.c:1947 request: Failed to create 
outgoing session to endpoint ''
[Nov  9 20:43:33] WARNING[14935][C-0001]: app_dial.c:2524 dial_exec_full: 
Unable to create channel of type 'PJSIP' (cause 3 - No route to destination)

And the call goes through just fine.

I guess the problem you had when reproducing the issue was another problem. 
Probably including some more of the upstream patches would be a good measure 
indeed.

Bug#822749: heimdal ftbfs on all 32bit architectures

[Nishanth Aravamudan]

Package: heimdal
Version: 1.7~git20160703+dfsg-1
Followup-For: Bug #822749
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu zesty ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/use_off_t_for_constants.patch: Use off_t in for
constants used in iprop log seeks.  Thanks to Nicolas Williams
.  Closes: #822749, LP: #1629055.


Thanks for considering the patch.

diff -Nru heimdal-1.7~git20160703+dfsg/debian/patches/series 
heimdal-1.7~git20160703+dfsg/debian/patches/series
--- heimdal-1.7~git20160703+dfsg/debian/patches/series  2016-07-03 
07:28:39.0 -0700
+++ heimdal-1.7~git20160703+dfsg/debian/patches/series  2016-11-09 
17:02:46.0 -0800
@@ -16,3 +16,4 @@
 061_disable_test_plugin
 062_disable_test_iprop
 parallel-build
+use_off_t_for_constants.patch
diff -Nru 
heimdal-1.7~git20160703+dfsg/debian/patches/use_off_t_for_constants.patch 
heimdal-1.7~git20160703+dfsg/debian/patches/use_off_t_for_constants.patch
--- heimdal-1.7~git20160703+dfsg/debian/patches/use_off_t_for_constants.patch   
1969-12-31 16:00:00.0 -0800
+++ heimdal-1.7~git20160703+dfsg/debian/patches/use_off_t_for_constants.patch   
2016-11-09 17:05:47.0 -0800
@@ -0,0 +1,35 @@
+Description: Use off_t in for constants used in iprop log seeks
+ On 32-bit architectures with _FILE_OFFSET_BITS=64,
+  sizeof(off_t) > sizeof(size_t) .
+ .
+ LOG_HEADER_SZ was #define'd as an expression of type size_t, so in
+ order to get the sign extension right we need -(off_t)LOG_HEADER_SZ
+ instead of (off_t)(-LOG_HEADER_SZ).  However, we can just define the
+ *_SZ macros to cast to off_t, then we don't need to worry about
+ negation.
+Author: Nicolas Williams 
+Origin: upstream, 
https://github.com/heimdal/heimdal/commit/7c8b66d76b562912c09c0955a53da2f26afbc8f7
+Bug: https://github.com/heimdal/heimdal/issues/175
+Bug-Debian: https://bugs.debian.org/822749
+Bug-Ubuntu: https://launchpad.net/bugs/1629055
+Last-Update: 2016-11-10
+
+--- heimdal-1.7~git20160703+dfsg.orig/lib/kadm5/log.c
 heimdal-1.7~git20160703+dfsg/lib/kadm5/log.c
+@@ -174,11 +174,11 @@ RCSID("$Id$");
+  * will deadlock with ipropd-slave -- don't do that.
+  */
+ 
+-#define LOG_HEADER_SZ   (sizeof(uint32_t) * 4)
+-#define LOG_TRAILER_SZ  (sizeof(uint32_t) * 2)
+-#define LOG_WRAPPER_SZ  (LOG_HEADER_SZ + LOG_TRAILER_SZ)
+-#define LOG_UBER_LEN(sizeof(uint64_t) + sizeof(uint32_t) * 2)
+-#define LOG_UBER_SZ (LOG_WRAPPER_SZ + LOG_UBER_LEN)
++#define LOG_HEADER_SZ   ((off_t)(sizeof(uint32_t) * 4))
++#define LOG_TRAILER_SZ  ((off_t)(sizeof(uint32_t) * 2))
++#define LOG_WRAPPER_SZ  ((off_t)(LOG_HEADER_SZ + LOG_TRAILER_SZ))
++#define LOG_UBER_LEN((off_t)(sizeof(uint64_t) + sizeof(uint32_t) * 2))
++#define LOG_UBER_SZ ((off_t)(LOG_WRAPPER_SZ + LOG_UBER_LEN))
+ 
+ #define LOG_NOPEEK 0
+ #define LOG_DOPEEK 1


-- System Information:
Debian Release: stretch/sid
  APT prefers yakkety-updates
  APT policy: (500, 'yakkety-updates'), (500, 'yakkety-security'), (500, 
'yakkety'), (400, 'yakkety-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#843830: ITP: golang-github-raintank-met -- an opinionated wrapper around metric client libraries

[Jordi Mallach]

El dj 10 de 11 de 2016 a les 01:33 +0100, en/na Jordi Mallach va
escriure:
> Package: wnpp
> Severity: wishlist
> Owner: Jordi Mallach 
> 
> * Package name: golang-github-raintank-met
>   Version : 0.0~git20161103.0.05a94bb-1
>   Upstream Author : raintank
> * URL : https://github.com/raintank/met
> * License : TODO
  
This was meant to read AGPL-3.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer http://www.debian.org/
jo...@sindominio.net jo...@debian.org http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/

Bug#842878: Asterisk crashes with pjproject 2.5.5

[Gedalya]

r5401 seems to be the fix:

https://trac.pjsip.org/repos/ticket/1946

However I'm having trouble adding a patch with this source package :-(

Bug#843215: fwupd: Please announce supported hardware using appstream

[Paul Wise]

On Wed, 2016-11-09 at 20:35 +, Mario Limonciello wrote:

> This is turning into a bit of a philosophical question, but why package
> flashable FW in Debian in the first place?

You may as well ask "why package anything for Debian?".

> Runtime loadable FW I entirely agree should be packaged so it can be
> loaded when appropriate.  Flashable however I fail to understand why
> the tools shouldn't be directly consuming binaries (.CAB files) and 
> processing them as they're needed.

For proprietary blobs, sure there is little advantage to being in
Debian. For anything that is Free Software, there are numerous
advantages, which are all the same as software that runs on the CPU.

> Yes, understand, but the type of thing that it would be better to have a
> ore proper frontend of fwupd integrated in the different (non-Gnome) 
> GUI's.
> 
> Fwupd runs as a daemon on the system and needs to be pulling updated
> metadata and always checking against the devices plugged in at the time.

Yeah, like apt. I expect the right integration level here is PackageKit.
Beyond that I'm not really sure how the upper layers work.

> Isenkram is more oriented around apps for devices than for FW.

It is simply mapping between software (packages, not apps) and devices.
fwupd provides a mechanism for doing that mapping, which isenkram
should use as an additional mapping mechanism when available.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#751993: another instance

[Vincent McIntyre]

On Wed, Nov 09, 2016 at 04:27:40PM +0530, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Wed, 2016-11-09 at 09:15 +1100, Vincent McIntyre wrote:
> > This is a problem because I need to blacklist DELL,
> > multipath -l -v 3 gives me the listing below.
> > Note that at this point I have no fibre channel links plugged in,
> > I don't trust this package that far yet.
> > 
> > Farther below, backtrace for the segfaulting configuration.
> > I also tried blacklisting the 'product' (PERC 6/i) instead of
> > 'vendor', that segfaulted too.
> > It would appear the segfault only occurs on a blacklist match.
> > 
> > Please consider upgrading the severity of this again.
> 
> Hello Vincent, 
> 
> Are you in a position to build debian packages by yourself ?
> If so, can you cherry-pick this [1] commit and try it on top of the Jessie
> version of multipath-tools ?
> 
> [1] 
> https://anonscm.debian.org/cgit/pkg-lvm/multipath-tools.git/commit/?id=5195a
> bd56cdfbc12c32c0ad3127a32643d11db4b

Thanks for the fast response. 

First, try the existing package with a product as well:

# grep -v ^# /etc/multipath.conf
blacklist {
devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
devnode "^hd[a-z][[0-9]*]"
devnode "^cciss!c[0-9]d[0-9]*[p[0-9]*]"

device {
vendor DELL
product "PERC H800"
}
}

# multipath -l -v 3
Nov 10 10:22:08 | libdevmapper version 1.02.90 (2014-09-01)
Nov 10 10:22:08 | DM multipath kernel driver v1.11.0
Nov 10 10:22:08 | loading /lib/multipath/libcheckdirectio.so checker
Nov 10 10:22:08 | loading /lib/multipath/libprioconst.so prioritizer
Nov 10 10:22:08 | sda: blacklisted, udev property missing
Nov 10 10:22:08 | sdb: udev property ID_WWN whitelisted
Nov 10 10:22:08 | sdb: not found in pathvec
Nov 10 10:22:08 | sdb: mask = 0x21
Nov 10 10:22:08 | sdb: dev_t = 8:16
Nov 10 10:22:08 | sdb: size = 11717836800
Nov 10 10:22:08 | sdb: vendor = DELL
Nov 10 10:22:08 | sdb: product = PERC 6/i
Nov 10 10:22:08 | sdb: rev = 1.22
Nov 10 10:22:08 | sdb: h:b:t:l = 0:2:1:0
Nov 10 10:22:08 | sdb: path state = running
Nov 10 10:22:08 | sdc: udev property ID_WWN whitelisted
Nov 10 10:22:08 | sdc: not found in pathvec
Nov 10 10:22:08 | sdc: mask = 0x21
Nov 10 10:22:08 | sdc: dev_t = 8:32
Nov 10 10:22:08 | sdc: size = 39059456000
Nov 10 10:22:08 | sdc: vendor = DELL
Nov 10 10:22:08 | sdc: product = PERC H800
Nov 10 10:22:08 | sdc: rev = 2.10
Nov 10 10:22:08 | sdc: h:b:t:l = 2:2:0:0
Nov 10 10:22:08 | (null): (DELL:PERC H800) vendor/product blacklisted
Nov 10 10:22:08 | sr0: blacklisted, udev property missing
Nov 10 10:22:08 | loop0: blacklisted, udev property missing
Nov 10 10:22:08 | loop1: blacklisted, udev property missing
Nov 10 10:22:08 | loop2: blacklisted, udev property missing
Nov 10 10:22:08 | loop3: blacklisted, udev property missing
Nov 10 10:22:08 | loop4: blacklisted, udev property missing
Nov 10 10:22:08 | loop5: blacklisted, udev property missing
Nov 10 10:22:08 | loop6: blacklisted, udev property missing
Nov 10 10:22:08 | loop7: blacklisted, udev property missing
Nov 10 10:22:08 | dm-0: blacklisted, udev property missing
Nov 10 10:22:08 | dm-1: blacklisted, udev property missing
Nov 10 10:22:08 | dm-10: blacklisted, udev property missing
Nov 10 10:22:08 | dm-11: blacklisted, udev property missing
Nov 10 10:22:08 | dm-12: blacklisted, udev property missing
Nov 10 10:22:08 | dm-13: blacklisted, udev property missing
Nov 10 10:22:08 | dm-2: blacklisted, udev property missing
Nov 10 10:22:08 | dm-3: blacklisted, udev property missing
Nov 10 10:22:08 | dm-4: blacklisted, udev property missing
Nov 10 10:22:08 | dm-5: blacklisted, udev property missing
Nov 10 10:22:08 | dm-6: blacklisted, udev property missing
Nov 10 10:22:08 | dm-7: blacklisted, udev property missing
Nov 10 10:22:08 | dm-8: blacklisted, udev property missing
Nov 10 10:22:08 | dm-9: blacklisted, udev property missing
= paths list =
uuid hcildev dev_t pri dm_st chk_st vend/prod/rev dev_st 
 0:2:1:0 sdb 8:16  -1  undef undef  DELL,PERC 6/i running
Nov 10 10:22:08 | params = 0 0 1 1 service-time 0 1 2 8:16 1 1 
Nov 10 10:22:08 | status = 2 0 0 0 1 1 A 0 1 2 8:16 A 0 0 1 
Nov 10 10:22:08 | 36782bcb0091105001b7d74a00b7be1cb: disassemble map [0 0 1 1 
service-time 0 1 2 8:16 1 1 ]
Nov 10 10:22:08 | 36782bcb0091105001b7d74a00b7be1cb: disassemble status [2 0 0 
0 1 1 A 0 1 2 8:16 A 0 0 1 ]
36782bcb0091105001b7d74a00b7be1cb dm-2 DELL,PERC 6/i
size=5.5T features='0' hwhandler='0' wp=rw
`-+- policy='service-time 0' prio=0 status=active
  `- 0:2:1:0 sdb 8:16 active undef running
Nov 10 10:22:08 | params = 0 0 1 1 service-time 0 1 2 8:32 1 1 
Nov 10 10:22:08 | status = 2 0 0 0 1 1 A 0 1 2 8:32 A 0 0 1 
Nov 10 10:22:08 | 36c81f660d4620f001b7c65f99ab4cfb8: disassemble map [0 0 1 1 
service-time 0 1 2 8:32 1 1 ]
Nov 10 10:22:08 | 8:32: not found in pathvec
Nov 10 10:22:08 | 36c81f660d4620f001b7c65f99ab4cfb8: disassemble status [2 0 0 
0 1 1 A 0 1 2 

Bug#843773: misleading timestamps in binnmus

[Cyril Brulebois]

Ian Jackson  (2016-11-09):
> What version of sbuild do buildds run ?  Ie, supposing that this is
> fixed in sbuild in stretch, will this be fixed on the buildds ?  Or do
> we need to update jessie, or what ?

sbuild on buildds uses a specific version of sbuild, for reasons I'm not
going to summarize. The base version is close to what's in jessie (see the
first lines of any build log which has “sbuild (Debian sbuild) 0.65.2”).

dsa-puppet.git has:
,---[ modules/debian-org/files/apt.preferences ]---
| …
| Package: sbuild
| Pin: release o=buildd.debian.org
| Pin-Priority: 500
| 
| Package: buildd
| Pin: release o=buildd.debian.org
| Pin-Priority: 500
| 
| Package: libsbuild-perl
| Pin: release o=buildd.debian.org
| Pin-Priority: 500
`---

Repository seems to live under:
  https://apt.buildd.debian.org/


KiBi.


signature.asc
Description: Digital signature

Bug#843831: Couldn't connect to accessibility bus: Failed to connect to socket

[積丹尼 Dan Jacobson]

Package: midori
Version: 0.5.12~wk2-exp1

Always lots of
** (WebKitWebProcess:7137): WARNING **: Couldn't connect to accessibility bus: 
Failed to connect to socket /tmp/dbus-vtwsCP7zpi: Connection refused

** (WebKitWebProcess:7163): WARNING **: Couldn't connect to accessibility bus: 
Failed to connect to socket /tmp/dbus-vtwsCP7zpi: Connection refused

-- System Information:
Debian Release: stretch/sid
  APT prefers experimental
  APT policy: (990, 'experimental'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.8.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages midori depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libcairo-gobject21.14.6-1.1
ii  libcairo21.14.6-1.1
ii  libgck-1-0   3.20.0-3
ii  libgcr-base-3-1  3.20.0-3
ii  libgcr-ui-3-13.20.0-3
ii  libgdk-pixbuf2.0-0   2.36.0-1
ii  libglib2.0-0 2.50.2-1
ii  libgtk-3-0   3.22.3-1
ii  libjavascriptcoregtk-4.0-18  2.15.1-1
ii  libp11-kit0  0.23.2-5
ii  libpango-1.0-0   1.40.3-3
ii  libpangocairo-1.0-0  1.40.3-3
ii  libsoup2.4-1 2.56.0-1
ii  libsqlite3-0 3.15.1-1
ii  libwebkit2gtk-4.0-37 2.15.1-1
ii  libx11-6 2:1.6.3-1
ii  libxml2  2.9.4+dfsg1-2.1
ii  libxss1  1:1.2.2-1
ii  libzeitgeist-2.0-0   0.9.16-0.2

Versions of packages midori recommends:
ii  gnome-icon-theme  3.12.0-2
ii  gnome-keyring 3.20.0-3

Bug#822792: (no subject)

[Michael Lustfield]

tags 822792 - pending
thanks

We had to pop this off because of other changes that needed to be released.

I've moved these specific changes into their own branch and plan to work on
the change there until we have something ready with other upstream packages so
that we can provide magical installations of web applications.


> 1. After looking at conf/sites-available/default I noticed a
>commented block handling .php files in there.
> 
>Would a config file in apps.d be allowed to do exactly
>that?  Like apps.d/pkg_php-fpm.conf handling *.php
>files?

Nope! In fact, that's why I'm trying to be very strict with the format of these
files. I don't want packages stepping on each other's toes.

However... I've already covered this use case with conf.d.

https://wiki.debian.org/Nginx/DirectoryStructure#appincludes

"Example: /etc/nginx/conf.d/pkg_drupal8.conf"

In this case, I'd say go ahead and provide /etc/nginx/conf.d/pkg_php-fpm.conf
which would include "upstream _provider_php { ... }". This shouldn't be a
problem unless someone tries to install multiple "php providers."

I'd like to get something like _provider_php available via php-fpm as well as
uwsgi-plugin-php.


Doing it this way would reduce security, but I'm thinking it's to a very
negligible degree and not very concerned.


> 2. Do we have recommended naming for files added by the
>local admin to apps.d?

We could suggest custom_.conf.

-- 
Michael Lustfield

Bug#842878: Asterisk crashes with pjproject 2.5.5

[Gedalya]

On 11/09/2016 06:26 PM, Gedalya wrote:
> asterisk: ../src/pjsip/sip_auth_client.c:507: pjsip_auth_clt_deinit: 
> Assertion `sess && sess->endpt' failed.
> Aborted
>
> This is me calling myself via my outbound trunk and coming back in via my 
> inbound trunk.
> The problem comes up only on the inbound calls, at the point where I dial 
> them to the phones and other devices.
> If I just call e.g. my mobile phone it works fine, I can complete the call 
> and asterisk continues fine.

Per [0] + google translate and testing and confirming locally, the problem is 
isolated to missing (not currently registered) SIP peers.

Making sure the Dial() app is only dialing registered and available peers makes 
the problem go away.

Next step would be to see if there is a patch upstream addressing this.

[0] https://forum.asterisk.ru/viewtopic.php?f=5=7772=10

Bug#843830: ITP: golang-github-raintank-met -- an opinionated wrapper around metric client libraries

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: golang-github-raintank-met
  Version : 0.0~git20161103.0.05a94bb-1
  Upstream Author : raintank
* URL : https://github.com/raintank/met
* License : TODO
  Programming Lang: Go
  Description : a wrapper around metric client libraries for Go

 This library provides an opinionated wrapper around metric client
 libraries for Go. It supports statsd (recommended) and dogstatsd.

This is a dependency of goiardi, a chef server written in Go that
I am packaging.

Bug#843803: Please catch illegal use of $F[0..1] as syntax error

[積丹尼 Dan Jacobson]

Gasp. Yes please warn.

Bug#843829: dpkg-parsechangelog incorrectly claims May is only a 'full' month on date parse failure

[Nishanth Aravamudan]

Package: dpkg
Version: 1.18.10ubuntu1
Severity: important
Tags: patch

Dear Maintainer,

Running dpkg-parsechangelog on changelogs that produce date parsing
problems, e.g.:

Tue, 17 May 2008 10:93:55 -0500

(don't ask me how it got there, but it happened in one Ubuntu publish).

ends up with an error like, "uses full instead of abbreviated month name
'May'", which is obviously not the actual problem. I think there is
actually a bug in dpkg (introduced in:
https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/scripts/Dpkg/Changelog/Entry/Debian.pm?id=21f5898d846a1cd69bdc6849e2097168cde02fdf),
in that if a full month is found to be used, it's not checked that the
full month is *also* an abbreviated month (only true for May, though).

I tested a fix with below patch on my local system. It feels like it
might be cleaner to special-case May as the only affected month, but I
think the logic was simply incorrect before either way -- it only makes
sense to check if a full month was used if an abbreviated month wasn't.

Thanks,
Nish

--- /usr/share/perl5/Dpkg/Changelog/Entry/Debian.pm.bak 2016-11-02 
17:07:08.195115132 -0700
+++ /usr/share/perl5/Dpkg/Changelog/Entry/Debian.pm 2016-11-02 
17:08:14.020173675 -0700
@@ -226,11 +226,13 @@ sub parse_trailer {
# Validate the month. Date::Parse used to accept both abbreviated
# and full months, but Time::Piece strptime() implementation only
# matches the abbreviated one with %b, which is what we want anyway.
-   if (exists $month_name{$8}) {
-   push @errors, sprintf(g_('uses full instead of abbreviated 
month name \'%s\''),
- $8, $month_name{$8});
-   } elsif (not exists $month_abbrev{$8}) {
-   push @errors, sprintf(g_('invalid abbreviated month name 
\'%s\''), $8);
+   if (not exists $month_abbrev{$8}) {
+if (exists $month_name{$8}) {
+   push @errors, sprintf(g_('uses full instead of abbreviated 
month name \'%s\''),
+ $8, $month_name{$8});
+} else {
+   push @errors, sprintf(g_('invalid abbreviated month name 
\'%s\''), $8);
+}
}
push @errors, sprintf(g_("cannot parse non-comformant date '%s'"), 
$7);
};


-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#816446: (no subject)

[Michael Lustfield]

nicoo: I'll apologize up front for my immediate response. I'd not looked at
this closely enough and made an incorrect assumption. I've finally found the
time to look at this a bit more closely.


> From: Moritz Muehlenhoff 
> systemd is the default init system since jessie and we cannot limit
> features used in init scripts to the least common denominator. In fact
> we already have a lot of feature disparaties with sysvinit not 
> providing many features present in systemd.

I don't care if it's the default. It's not the only init system supported by
Debian and breaking things for everyone else is unacceptable. Additionally,
there are a very large number of users with non-systemD servers and many
organizations I've worked with have expressed interest in avoiding it as long
as possible. They've quoted this type of action as one of the primary
motivators for that decision.

Yes, we can add confinement features. No, we will *NOT* break support for other
init systems.


Now...


Looking at this more closely, PrivateTmp and PrivateDevices shouldn't cause
issues.


> # Prevents access to /home, /root and /run/user
> ProtectHome=true

I actually like this idea, but... we have a *LOT* of "administrators" out there
that assume placing applications in /home// is the standard way of doing
things. Once this update reaches them, their applications will stop working
correctly. Even setting /home to read-only is going to generate an enormous
amount of breaking.

I agree that nobody should ever put web applications in /home, but it's a
common practice. Are we ready to break their setup? Are we ready to deal with
the continual fallout?

I'm wondering if ProtectHome=false would be better with a comment above it
explaining the benefits of =true/read-only.


> # Makes /usr, /boot and /etc read-only
> ProtectSystem=full

This has the potential to have the same problem as above. I know some web
applications like drupal install configuration data to /etc, but these are
typically symlinks for convenience. I'm not sure how applications will behave
and would hedge toward =true for this setting.

It's also worth noting that, when configuration management tools are used, web
applications are typically dropped into /srv or /opt. These will also need to
remain accessible, as will /usr/share and possibly others.


Anyway, this is all for continued discussion.


As for roll-out, I would prefer include this with #822792. If this is going to
break anything, keeping the roll-out schedule to that bug should help make sure
I break everything that can be broken before releasing for public
consumption. ;)

If anyone is interested in helping expedite that, I'm not gonna argue!

-- 
Michael Lustfield

Bug#843694: sbuild: No way to pre-install extra-packages before build

[Johannes Schauer]

Hi,

On Tue, 8 Nov 2016 16:44:53 -0300 Felipe Sateler  wrote:
> On 8 November 2016 at 16:39, Felipe Sateler  wrote:
> > Package: sbuild
> > Version: 0.72.0-2
> > Severity: wishlist
> >
> > Hi,
> >
> > I have been trying to run some builds with a modified dpkg, but this
> > currently isn't working. sbuild appears to copy the debs to the chroot
> > after the initial apt-get update/upgrade, so it will not be
> > automatically upgraded.
> >
> > --chroot-setup-commands= doesn't help because it is also run before
> > setting up the apt repository, and --starting-build-commands= is run as
> > non-root.
> >
> > Upon further reading of the manpage, it is explicitly stated that
> > --extra-packages is only available for build-dependency resolution, and
> > that there is no --$something-command that will run as root but after
> > all chroot setup. It would be great to have such a command.
> 
> I forgot to add that it is currently possible to --add-depends to
> achieve installation, but in the general case where one needs a root command
> after injecting the debs (eg, to run some command from the package) this
> would not be possible.

now I'm confused. What's the bug here? As you already pointed out,
--add-depends allows you to force installation of your custom .deb. What is
missing? Why do you still need root after packages are installed?

Your bug report might also have similarities to #792037.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#843791: ghc: builds fail on hurd-i386: /usr/bin/ld: -r and -pie may not be used together

[Samuel Thibault]

Hello,

Clint Adams, on Wed 09 Nov 2016 17:08:23 +, wrote:
> On Wed, Nov 09, 2016 at 05:47:13PM +0100, Samuel Thibault wrote:
> > It seems the latest ghc has troubles building packages on hurd-i386:
> > 
> > [ 1 of 18] Compiling Data.Streaming.Zlib.Lowlevel ( 
> > Data/Streaming/Zlib/Lowlevel.hs, 
> > dist-ghc/build/Data/Streaming/Zlib/Lowlevel.o )
> > ...
> > [18 of 18] Compiling Data.Streaming.Text ( Data/Streaming/Text.hs, 
> > dist-ghc/build/Data/Streaming/Text.o )
> > [ 1 of 18] Compiling Data.Streaming.Zlib.Lowlevel ( 
> > Data/Streaming/Zlib/Lowlevel.hs, 
> > dist-ghc/build/Data/Streaming/Zlib/Lowlevel.p_o )
> > /usr/bin/ld: -r and -pie may not be used together
> 
> That's confusing.

This seems to be triggered by the newer dpkg, which apparently emits
-pie itself on hurd-i386: on my not-so-up-to-date box I hadn't the
issue, and after upgrading dpkg I got the issue on my box too.

dpkg maintainers: ghc does emi -no-pie, but it seems dpkg's -pie
overrides it.

I'm however surprised that dpkg adds -pie on hurd-i386 too: AIUI hurd's
gcc does have pie enabled by default too.

Samuel

Bug#843828: default output, --lines 1, --limit, etc.

[積丹尼 Dan Jacobson]

Package: procps
Version: 2:3.3.12-2
Severity: wishlist
File: /usr/share/man/man1/ps.1.gz

Man page says

AIX FORMAT DESCRIPTORS
   This ps supports AIX format descriptors, which work somewhat like the
   formatting codes of printf(1) and printf(3).  For example, the normal
   default output can be produced with this: ps -eo "%p %y %x %c".  The
   NORMAL codes are described in the next section.

$ ps -o "%p %y %x %c"
  PID TTY  TIME COMMAND
 1580 pts/200:00:00 bash
 1817 pts/200:00:00 ps
$ ps
  PID TTY  TIME CMD
 1580 pts/200:00:00 bash
 1818 pts/200:00:00 ps

So they actually differ by COMMAND vs. CMD. So that paragraph is wrong.

Also don't use -e, as the default is many lines less than with -e.

Also mention one can mix % and non % items, but must use separate -o stanzas:

$ ps -o pid -o %c
  PID COMMAND
 1212 bash
 1920 ps

Also please mention, quite near the top of the page, what the default
output in fact is.

OK I found it is
$ ps -o "%p %y %x" -o ucmd

By the way, also

   CODE   NORMAL   HEADER...
   %y tty  TTY

is wrong.
   %y tty  TTY
should be
   %y tnameTTY
as tty will produce TT.

$ ps -o %y -o tty -o tname|sed 2q
TTY  TT   TTY
pts/0pts/0pts/0

(Perhaps also add a --limit option, so one doesn't need sed when testing
as above.)

Also at
   Print only the process IDs of syslogd:
  ps -C syslogd -o pid=
mention how to get rid of blanks. Mention that the only way is
to apparently alas rely on external programs:
# ps -C rsyslogd -o pid= | tr -d ' '
424

Also as I above do, use rsyslogd instead of syslogd so people can test
without editing, as rsyslogd is what more people perhaps use these days.

By the way, this is busted for n=1,
$ for n in `seq 5`;do echo -n $n:; ps -e --lines $n --rows $n --headers|wc -l; 
done
1:116
2:230
3:173
4:154
5:144

Also be very careful, sometime on the man page you say "screen",
sometimes you say "page", when apparently talking about the same thing.
In fact there is a second meaning of "page" also there too... (memory page).

Maybe they should all be "page" as we are talking more of a printer like
output than top(1) output...

Bug#843827: ITP: golang-github-ctdk-go-trie -- Trie implementation based on a minimal automaton for Go

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: golang-github-ctdk-go-trie
  Version : 0.0~git20161027.0.6443fbc-1
  Upstream Author : Jeremy Bingham
* URL : https://github.com/ctdk/go-trie
* License : MIT
  Programming Lang: Go
  Description : Trie implementation based on a minimal automaton for Go

 This library implements tries, also known as prefix trees, using
 minimal acyclic finite-state automata for the Go programming language.

This is a dependency of my upcoming ITP goiardi, a chef server written in Go.

Bug#843826: PIE specs file leads to segfaults on sparc64

[James Clarke]

Package: dpkg-dev
Version: 1.18.13
Severity: important
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hi Guillem,
Unfortunately, your new specs files lead to segfaults on sparc64:

> $ cat exit.c
> #include 
>
> int main(int argc, char **argv) {
> exit(1);
> return 2;
> }
> $ gcc -specs=/usr/share/dpkg/pie-compile.specs -c exit.c -o exit.o
> $ gcc -specs=/usr/share/dpkg/pie-link.specs exit.o -o exit
> $ ./exit
> Segmentation fault

This is because, while cc1 is given -fPIE, as is not given anything. For
most architectures, this is actually fine, but on SPARC, as *must* be
given -K PIC. When looking at strace, this is the only difference
between gcc -specs=... and gcc -fPIE for compiling. Otherwise, what
happens is the assembler does not emit a PLT call, instead leaving the
call address as an immediate to be filled in by a 30-bit relocation,
which doesn't fit at runtime (with this particular example, libc was
loaded such that exit was at 0xfff80001001624e0) and gets truncated.
Note that the linker invocation itself is fine; it was just given bad
input (although perhaps this is something it could have caught and given
an error message?).

As far as I can tell, changing the cc1_options to self_spec in
(no-)pie-compile.specs should work fine. It certainly fixes the problem
here, and off the top of my head, I can't think of any issues this would
cause.

James

Bug#841257: sendmail: Privilege escalation from group smmsp to (user) root

[paul . szabo]

Dear Andreas,

> I have a completely untested patch sitting in GIT - do you have a
> possibility to test packages built from that?

I could replace files, or DEB packages, on some test machines. Do not
know whether that testing would be exhaustive: do not know how many
features of the sendmail package I use. Or if the changes are "small"
then could just inspect.

Cheers, Paul

Bug#842878: Asterisk crashes with pjproject 2.5.5

[Gedalya]

On 11/09/2016 04:51 AM, Bernhard Schmidt wrote:

> I have now uploaded Asterisk 13.12.1~dfsg-1 into sid, should be built
> and available within a few hours. This works well for me with pjproject
> from sid. Maybe it really just needed a recompile, but you had already
> tested that in the beginning. Would it be possible that something went
> wrong there?
I don't see what or how. I definitely rebuilt against the new pjproject.
I'm getting the same problems now, with the new packages in the debian archive.

Note that I can make outbound calls just fine. The problem is perhaps triggered 
by something specific in my inward dialing plan.

This is with the new packages:

-- Executing *desk-out:1] Goto("PJSIP/*-", 
"desk-out,*,1") in new stack
-- Goto (desk-out,*,1)
-- Executing [*@desk-out:1] Set("PJSIP/*-", 
"CALLERID(num)=*") in new stack
-- Executing [*@desk-out:2] Goto("PJSIP/*-", 
"out-vitel,*,1") in new stack
-- Goto (out-vitel,*,1)
-- Executing [*@out-vitel:1] MixMonitor("PJSIP/*-", 
"/var/local/callrec/2016-11/1478733136.0.wav") in new stack
  == Begin MixMonitor Recording PJSIP/*-
-- Executing [*@out-vitel:2] Set("PJSIP/*-", 
"CDR(peername)=*") in new stack
-- Executing [*@out-vitel:3] Dial("PJSIP/*-", 
"PJSIP/*@trunk-didlogic") in new stack
-- Called PJSIP/*@trunk-didlogic
-- Executing [*@from-external:1] 
Goto("PJSIP/trunk-vitelity-in-0002", "internal,gedalya-all,1")
-- Goto (internal,gedalya-all,1)
-- Executing [gedalya-all@internal:1] 
Set("PJSIP/trunk-vitelity-in-0002", "CDR(peername)=trunk-vitelity-in") in 
new stack
-- Executing [gedalya-all@internal:2] 
MixMonitor("PJSIP/trunk-vitelity-in-0002", 
"/var/local/callrec/2016-11/1478733137.2.wav") in new stack
  == Begin MixMonitor Recording PJSIP/trunk-vitelity-in-0002
-- Executing [gedalya-all@internal:3] 
Dial("PJSIP/trunk-vitelity-in-0002", 
"PJSIP/*/*/*/*/*,30") in new stack
asterisk: ../src/pjsip/sip_auth_client.c:507: pjsip_auth_clt_deinit: Assertion 
`sess && sess->endpt' failed.
Aborted

This is me calling myself via my outbound trunk and coming back in via my 
inbound trunk.
The problem comes up only on the inbound calls, at the point where I dial them 
to the phones and other devices.
If I just call e.g. my mobile phone it works fine, I can complete the call and 
asterisk continues fine.

I'll try patching pjproject now and see how that goes.

Bug#843825: ITP: golang-github-ctdk-chefcrypto -- Go cryptographic routines to interact with chef servers

[Jordi Mallach]

Package: wnpp
Severity: wishlist
Owner: Jordi Mallach 

* Package name: golang-github-ctdk-chefcrypto
  Version : 0.0~git20161109.0.dea96d7-1
  Upstream Author : Jeremy Bingham
* URL : https://github.com/ctdk/chefcrypto
* License : Apache-2.0
  Programming Lang: Go
  Description : Go cryptographic routines to interact with chef servers

This library includes various cryptographic routines for communicating with
chef servers for golang programs and libraries. Originally part of goiardi,
it's been split out for packaging purposes.

It is being packaged as a dependency of go-chef, in turn a dependency of
goiardi, a chef server written in Go.

Bug#843711: biber: FTBFS (failing tests)

[Niko Tyni]

On Thu, Nov 10, 2016 at 12:41:39AM +0900, Norbert Preining wrote:
> > But that'd be just bandaid IMO and a real fix would either revert the
> > relevant Unicode::Collate change if it's a bug, or adapt biber to work
> 
> If one could find out what the relevant change is. It is rather unfortunate
> that the two version of the same things don't produce the same :-(

% perl -MUnicode::Collate -le 'print $Unicode::Collate::VERSION, " ", 
Unicode::Collate->new->viewSortKey("Foo")'

gives this output with the versions available on jessie and sid:

1.04 [1680 176D 176D | 0020 0020 0020 | 0008 0002 0002 |    |]

1.07 [1680 176D 176D | 0020 0020 0020 | 0008 0002 0002 |    |]

1.14 [19A9 1AA1 1AA1 | 0020 0020 0020 | 0008 0002 0002 |    |]

1.17 [1C60 1D58 1D58 | 0020 0020 0020 | 0008 0002 0002 |    |]

So the U::C sort key generation has changed (again), and the biber test
suite hardcodes md5sums of the old sort keys.

Given 
https://github.com/plk/biber/commit/9bebd3ef0cb57b5ca4f15885d0cbfecc4939a835
I suspect biber just needs to adapt again.
-- 
Niko Tyni   nt...@debian.org

Bug#836595: ruby-celluloid-io: FTBFS randomly (failing tests)

[Santiago Vila]

retitle 836595 ruby-celluloid-io: FTBFS randomly (failing tests)
thanks

(I never liked the "too much often" wording)

Bug#842939: Handling of "malware" in Debian

[Jonathan Wiltshire]

On 2016-11-09 18:44, Holger Levsen wrote:

On Wed, Nov 09, 2016 at 07:14:45PM +0100, W. Martin Borgert wrote:

If users of testing or unstable have the malware installed now and
the package gets removed from the archive, users are left with the
malware, right?


yes


That's why I thought about uploading an empty package to unstable,


yes, of course.


Whilst that's in progress, let's at least limit damage through new 
installations:


jmw@respighi:~$ head -n 3 hints/jmw
# 20161109
# #842939 damage limitation
remove wot/20151208-2

A 'fixed' package can still migrate later.



it should be released with stretch, but can be safely removed later.


i'm not sure about the releasing with stretch part. Maybe it would be
better to have the updated, empty package in stretch in 5plusX days and
then remove it before the release, say on January 1st.


Let's not actually release it, but a leaf package like this is trivially 
removed again.


(Strictly speaking use of Stretch is still 'at own risk' and 
unsupported, so this is overkill, but it's small effort to be nice.)


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

Bug#828236: Processed: tagging 828236

[Stefan Fritsch]

Hi Kurt,

On Sunday, 25 September 2016 19:51:08 CET Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > tags 828236 + patch
> 
> Bug #828236 [src:apache2] apache2: FTBFS with openssl 1.1.0
> Added tag(s) patch.

I am sorry, but I don't feel qualified to review that patch (or the upstream 
branch 2.4.x-openssl-1.1.0-compat which has a different implementation). In 
apache, there is lots of subtle interaction between TLS-renegotiation and 
access control. Therefore I want to have the patch reviewed by someone who 
knows mod_ssl well before I include it in Debian. Also, having openssl 1.1 
support only in testing/unstable won't give apache enough exposure to ensure 
that nothing is broken in complex configurations. 

Currently there is no movement upstream to finish the openssl 1.1 support any 
time soon. This means that it is very unlikely that apache2 will get fixed in 
time for stretch.

Cheers,
Stefan

Bug#843824: kdenlive: Screen Grab has hard coded display setting

[Daniel Keast]

Package: kdenlive
Version: 0.9.10-2
Severity: normal

Dear Maintainer,

The screen grab feature has the DISPLAY location hard coded. When I attempt to
record my desktop I get a notification with the message "x11grab Could not open
X display. :0.0: Input/output error".

This patch fixes the issue for me:

diff --git a/kdenlive-0.9.10/src/monitor/recmonitor.cpp 
b/kdenlive-0.9.10/src/monitor/recmonitor.cpp
index f465d82..57b5536 100644
--- a/kdenlive-0.9.10/src/monitor/recmonitor.cpp
+++ b/kdenlive-0.9.10/src/monitor/recmonitor.cpp
@@ -29,6 +29,8 @@
 #include "videosurface.h"
 #include 
 
+#include 
+
 #include 
 #include 
 #include 
@@ -731,7 +733,8 @@ void RecMonitor::slotRecord()
m_captureArgs << "-f" << "x11grab";
if (KdenliveSettings::grab_follow_mouse()) m_captureArgs << 
"-follow_mouse" << "centered";
if (!KdenliveSettings::grab_hide_frame()) m_captureArgs << 
"-show_region" << "1";
-   captureSize = ":0.0";
+   captureSize = std::genenv("DISPLAY");
+   if (captureSize == NULL) captureSize = ":0.0";
 if (KdenliveSettings::grab_capture_type() == 0) {
 // Full screen capture
m_captureArgs << "-s" << QString::number(screenSize.width()) + 
'x' + QString::number(screenSize.height());


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

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

Versions of packages kdenlive depends on:
ii  kde-runtime   4:4.14.2-2
ii  kdenlive-data 0.9.10-2
ii  libav-tools   6:11.8-1~deb8u1
ii  libc6 2.19-18+deb8u6
ii  libgcc1   1:4.9.2-10
ii  libgl1-mesa-glx [libgl1]  10.3.2-1+deb8u1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libkdecore5   4:4.14.2-5+deb8u1
ii  libkdeui5 4:4.14.2-5+deb8u1
ii  libkio5   4:4.14.2-5+deb8u1
ii  libknewstuff3-4   4:4.14.2-5+deb8u1
ii  libknotifyconfig4 4:4.14.2-5+deb8u1
ii  libkrossui4   4:4.14.2-5+deb8u1
ii  libmlt++3 0.9.2-2
ii  libmlt6   0.9.2-2
ii  libnepomuk4   4:4.14.2-5+deb8u1
ii  libqjson0 0.8.1-3
ii  libqt4-dbus   4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-network4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-script 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-svg4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libsolid4 4:4.14.2-5+deb8u1
ii  libsoprano4   2.9.4+dfsg-1.1
ii  libstdc++64.9.2-10
ii  libv4l-0  1.6.0-2
ii  libx11-6  2:1.6.2-3
ii  libxau6   1:1.0.8-1
ii  libxdmcp6 1:1.1.1-1+b1
ii  libxext6  2:1.3.3-1
ii  melt  0.9.2-2

Versions of packages kdenlive recommends:
ii  dvdauthor0.7.0-1.3
ii  dvgrab   3.5-2+b2
ii  frei0r-plugins   1.4-3
ii  genisoimage  9:1.1.11-3
ii  recordmydesktop  0.3.8.1+svn602-1+b1
ii  swh-plugins  0.4.15+1-7

Versions of packages kdenlive suggests:
pn  khelpcenter4  

-- no debconf information

Bug#843823: vlc-plugin-base: It depends on liblirc-client0 but it doesn't exists

[Julian Yezid Castellanos Pinzon]

Package: vlc-plugin-base
Version: 1:2.2.4-dmo7
Severity: grave
Justification: renders package unusable

Dear Maintainer,

vlc became uninstallable (or upgradable) because vlc-plugin-base depends on
liblirc-client0 but the package in the system is liblircclient0 (without -).



-- 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/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#842505: closed by Scott Kitterman <deb...@kitterman.com> (already not in unstable)

[Mattia Rizzolo]

On Wed, Nov 09, 2016 at 11:36:45PM +0200, Otto Kekäläinen wrote:
> Hello!
> 
> There is no actual explanation why this issue was closed. "Not in
> unstable" isn't satisfactory.

The package was already removed by https://bugs.debian.org/834082

> The mentioned packages are still in both testing and unstable:
> https://packages.debian.org/search?keywords=libmariadb-client-lgpl-dev=names=all=all

according to that page (note also that that one shows binaries, you
requested a source removal) in sid is only available through debports
for arm64 only.

It's not getting removed from testing because removing it would break
stuff, as you can see by a `dak rm -Rn -s testing mariadb-client-lgpl`


|Checking reverse dependencies...
|# Broken Depends:
|neko: neko
|rmysql: r-cran-rmysql
|
|# Broken Build-Depends:
|rmysql: libmariadb-client-lgpl-dev


and in update_output.txt by britney:

|trying: -mariadb-client-lgpl
|skipped: -mariadb-client-lgpl (6, 13, 19)
|got: 47+0: a-7:i-24:a-4:a-0:a-0:m-0:m-11:m-0:p-0:s-1
|* arm64: haxe, mercurial-buildpackage, neko, r-cran-rmysql


Fix that, then mariadb-client-lgpl will be removed from testing too, and
then mariadb-connector-c will migrate.

That "automatic transition" you see there is exactly what needs to be
addressed, those packages (build-)depends on those binaries you want to
remove.


In the past I saw library packages moving between sources and britney
nicely coping with it, if this needs some prod to get in you are better
contacting the release team than a ftp.debian.org bug anyway.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#842505: closed by Scott Kitterman <deb...@kitterman.com> (already not in unstable)

[Scott Kitterman]

It's only in unstable in the Debian Ports archive, which is not maintained by 
the FTP team.  There is nothing we can do about it:

2.0.0-1 [debports]: arm64 

You need to contact the ports maintainers.

Scott K

On Wednesday, November 09, 2016 11:36:45 PM Otto Kekäläinen wrote:
> Hello!
> 
> There is no actual explanation why this issue was closed. "Not in
> unstable" isn't satisfactory.
> 
> The mentioned packages are still in both testing and unstable:
> https://packages.debian.org/search?keywords=libmariadb-client-lgpl-dev
> hon=names=all=all
> 2016-11-05 6:32 GMT+02:00 Debian Bug Tracking System 
:
> > This is an automatic notification regarding your Bug report
> > which was filed against the ftp.debian.org package:
> > 
> > #842505: RM: mariadb-client-lgpl -- ROM; obsoleted by mariadb-connector-c
> > 
> > It has been closed by Scott Kitterman .
> > 
> > Their explanation is attached below along with your original report.
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Scott Kitterman
> >  by replying to this email.
> > 
> > 
> > --
> > 842505: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842505
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> > 
> > 
> > -- Edelleenlähetetty viesti --
> > From: Scott Kitterman 
> > To: 842505-d...@bugs.debian.org
> > Cc:
> > Date: Sat, 05 Nov 2016 00:31:11 -0400
> > Subject: already not in unstable
> > 
> > 
> > -- Edelleenlähetetty viesti --
> > From: "Otto Kekäläinen" 
> > To: Debian Bug Tracking System 
> > Cc: schep...@debian.org
> > Date: Sat, 29 Oct 2016 22:41:10 +0300
> > Subject: RM: mariadb-client-lgpl -- ROM; obsoleted by mariadb-connector-c
> > Package: ftp.debian.org
> > Severity: normal
> > 
> > The source package mariadb-client-lgpl was renamed to
> > mariadb-connector-c. At the same time some binary packages were also
> > renamed.
> > 
> > To finalize this change, please remove from testing and unstable the
> > following binary packages that have become obsolete:
> > 
> > * libmariadb-client-lgpl-dev
> > * libmariadb-client-lgpl-dev-compat
> > 
> > Please do not remove libmariadb2 or any other packages that are produced
> > from the new mariadb-connector-c source package.
> > 
> > While you are at it, please advice me if the automatic transition
> > visible at
> > https://release.debian.org/transitions/html/auto-mariadb-client-lgpl-rm.ht
> > ml needs any further action than this.
> > 
> > Thanks!

Bug#843809: check that executables don't link to libraries in /usr is broken wrt libsystemd-shared

[Martin Pitt]

Hello Michael,

Michael Biebl [2016-11-09 22:23 +0100]:
> >> Dunno, maybe we should just drop the check again. Thoughts?

+1 on dropping the check again. It has always been an approximation
anyway, and the last time this got broken through a libaudit library
update [1], not a systemd upload, so that we couldn't catch it anyway.

But enabling merged /usr was the final nail in the coffin -- let's
drop the check.

> We should clearly communicate this then, but I have no good idea how.
> Ideally we'd have a preinst check which tests if /usr is separate and
> there is no initramfs. But a check for that sounds brittle.

Right, and again it wouldn't help with the libaudit scenario we had
last time.

> The second best would be, to document it officially.
> So next time a user comes around like in [1] or [2], we can simply point
> him/her there and close it wontfix

We can add a paragraph to README.Debian? Something like

Separate /usr partition
===
If you have /usr on a separate partition, you *must* use an initrd
which mounts /usr. Otherwise your system will most likely fail to
boot.

?

Martin

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828991

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: PGP signature

Bug#843803: Please catch illegal use of $F[0..1] as syntax error

[Niko Tyni]

On Thu, Nov 10, 2016 at 02:43:28AM +0800, 積丹尼 Dan Jacobson wrote:
> Package: perl
> Version: 5.24.1~rc3-3
> Severity: wishlist
> 
> Please catch illegal use of $F[0..1] as syntax error.
> 
> Else it gets interference from "$."!

It's not illegal: the index is evaluated in scalar context and the
$. "interference" you mention is documented behaviour. See perlop,
"Range Operators".

In scalar context, '..' acts as a "flip-flop" operator, and constant
operands are compared to the current line number ("$."). This enables
things like "perl -ne 'print if 2..5' /etc/passwd".

See also http://www.perlmonks.org/?node_id=525392

> use strict;
> use warnings FATAL => q(all);
> $_=`ps -axo pid=`;
> my $c;
> for(split){
> last if ++$c > 5;
> open N, "/proc/$_/stat" or next;
> my @F = split " ", ;
> close N;
> print  "@F[0..$c]\n=>$F[0..1]\n\n";
> }

Here $. is always 0, so the left operand of 0..1 is true and the
resulting index increments on every evaluation.

> my @A=(7..99);
> print $A[0..1],"\n";
> print $A[0..2],"\n";
> print $A[1..2],"\n";

$. is still 0 so we get 1 for the first two indices and the empty string
(false) for the last one.

> Tell the user
> die "Did you mean @F[0..1]?"

No, it's perfectly legal. At most warn.
-- 
Niko Tyni   nt...@debian.org

Bug#843727: fix inside

[Aurélien COUDERC]

control: tags -1 pending

Le mercredi 9 novembre 2016, 22:45:32 CET Eric Valette a écrit :
> the wrong code is calling "which update-initramfs" outside of if
> because then the set -e catch an error and there is no way the
> test on $? can work
> 
> correct code is:
> 
>  if which update-initramfs > /dev/null; then
>  update-initramfs -u
>  fi

Yes, was preparing that already after reading your last mail. :-)

It’s now committed to SVN and will be in the next upload.


Cheers,
--Aurélien

Bug#840673: dput missing a dependency on python setuptools library [and 1 more messages]

[Ian Jackson]

Matthias Klose writes ("Re: Bug#840673: dput missing a dependency on python 
setuptools library [and 1 more messages]"):
> On 09.11.2016 21:44, Goirand Thomas (aka zigo) wrote:
> > What's happening here is probably dput having a Python dep
> > on setuptools but it's not expressed in the Debian package's
> > runtime Depends:. The way to fix it would be patching the
> > dput Python requires (probably, that's in setup.py), or add the
> > Depends: python-setuptools in the dput package. But I haven't
> > looked at the issue so I can't tell which one of actions to do.

I don't think this is right.

See Ben Finney's message here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836710#10

> it's surprising that dput would need a dependency on the setuptools
> egg instead of the pkg_resources egg.  A dependency on the
> setuptools egg just sounds plain wrong.
> 
> Do you have a test case why a dependency on the setuptools egg is needed?

Is this likely to be relevant ?

(build)root@zealot:/home/ian# egrep . 
/usr/share/dput/dput-0.10.3.egg-info/requires.txt
setuptools
python-debian
(build)root@zealot:/home/ian#

Also, I don't understand how python module loading stuff works, but
the behaviour I see below makes things quite hard to test:

(build)root@zealot:/home/ian# dput
Traceback (most recent call last):
  File "/usr/bin/dput", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2994, 
in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2980, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3007, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 658, 
in _build_master
ws.require(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 966, 
in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 852, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'setuptools' distribution was not found 
and is required by dput
(build)root@zealot:/home/ian# cp /usr/bin/dput .
(build)root@zealot:/home/ian# python ./dput
Traceback (most recent call last):
  File "./dput", line 6, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2994, 
in 
@_call_aside
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2980, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3007, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 658, 
in _build_master
ws.require(__requires__)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 966, 
in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 852, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'dput==0.10.3' distribution was not 
found and is required by the application
(build)root@zealot:/home/ian# 


-- 
Ian Jackson    These 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#843822: KDE binaries (ksplashqml) *silently* fail if they cannot allocate memory, causing a hang at startup

[Alain Knaff]

Package: kde-workspace-bin
Version: 4:4.11.13-2

When attempting to start kde with a too low ulimit -d applied, kde just 
hangs, without displaying its splash screen, nor popping up any error 
dialog, nor printing any error message to stderr (.xsession-errors)

This makes diagnosing such situations needlessly difficult.

strace shows the following sequence:

6907  execve("/usr/bin/ksplashqml", ["ksplashqml", "lines", "--pid"], [/* 59 
vars */]) = 0
...
6907  clone(child_stack=0, 
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, 
child_tidptr=0x7f8ada54aa50) = 6908
...
6907  exit_group(0) = ?
6907  +++ exited with 0 +++
...
6908  mmap(NULL, 2147483648, PROT_READ|PROT_WRITE|PROT_EXEC, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0 
6908  <... mmap resumed> )  = -1 ENOMEM (Cannot allocate memory)
6908  --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xbbadbeef} 
---
6908  +++ killed by SIGSEGV +++

This shows several problems:
1. No attempt is made by the victim process (ksplashqml) to write an 
error message to stderr
2. Apparently the victim process tries to use the pointer returned by 
mmap without first checking it for MAP_FAILED, which results in a 
segfault.
3. The process is started with a double-fork making it impossible for 
the parent process to react to the SEGV either. Double fork is a weird 
way of starting a child process that is meant to be shortlived (such as 
the splash screen)

This situation may seem cosmetical (it's the splash screen, after 
all...) but unfortunately it occurs similarly for 
/usr/bin/kbuildsycoca4 --incremental --checkstamps and 
/usr/bin/kdeinit4 --oom-pipe +kcminit_startup

Occasionally the following message is indeed printed to stderr:

QThread::start: Thread creation error: Resource temporarily unavailable

This is still misleading, as it doesn't tell *which* resource. Indeed, 
the error from the kernel is ENOMEM, and not EAGAIN.

This makes it needlessly difficult to debug such a situation. A memory 
issue is really not expected on a hang (rather than on a crash...)

Thanks for fixing this.

Alain

Bug#843727: fix inside

[Eric Valette]

the wrong code is calling "which update-initramfs" outside of if
because then the set -e catch an error and there is no way the
test on $? can work

correct code is:

if which update-initramfs > /dev/null; then
update-initramfs -u
fi

-- eric

Bug#843727: requested infos

[Eric Valette]

apt-get -f install

Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Le paquet suivant a été installé automatiquement et n'est plus nécessaire :
  libkodiplatform16
Veuillez utiliser « apt autoremove » pour le supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 2 non mis à jour.
1 partiellement installés ou enlevés.
Après cette opération, 0 o d'espace disque supplémentaires seront utilisés.
Paramétrage de desktop-base (9.0.0~exp1) ...
+ dpkg-maintscript-helper rm_conffile /etc/default/kdm.d/10_desktop-base 
9.0.0~ desktop-base -- configure 8.0.2

+ [[ configure = \c\o\n\f\i\g\u\r\e ]]
+ read theme priority
+ update-alternatives --install /usr/share/desktop-base/active-theme 
desktop-theme /usr/share/desktop-base/softwaves-theme 50

+ read theme priority
+ update-alternatives --install /usr/share/desktop-base/active-theme 
desktop-theme /usr/share/desktop-base/lines-theme 40

+ read theme priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/active-theme/wallpaper/contents/images/1920x1080.svg 
70

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/softwaves-theme/wallpaper/contents/images/1280x720.svg 
65

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/softwaves-theme/wallpaper/contents/images/1280x800.svg 
65

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/softwaves-theme/wallpaper/contents/images/1920x1080.svg 
65

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/softwaves-theme/wallpaper/contents/images/1920x1200.svg 
65

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/softwaves-theme/wallpaper/contents/images/2560x1440.svg 
65

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/softwaves-theme/wallpaper/contents/images/2560x1600.svg 
65

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/lines-theme/wallpaper/contents/images/1280x1024.svg 
60

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/lines-theme/wallpaper/contents/images/1600x1200.svg 
60

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/lines-theme/wallpaper/contents/images/1920x1080.svg 
60

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/lines-theme/wallpaper/contents/images/1920x1200.svg 
60

+ read theme filename priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/desktop-base/lines-theme/wallpaper/contents/images/2560x1080.svg 
60

+ read theme filename priority
+ read background priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/images/desktop-base/joy-wallpaper_1600x1200.svg 50

+ read background priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/images/desktop-base/joy-wallpaper_1280x1024.svg 50

+ read background priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/images/desktop-base/joy-wallpaper_1920x1080.svg 50

+ read background priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/images/desktop-base/joy-wallpaper_1920x1200.svg 50

+ read background priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/images/desktop-base/joy-inksplat-wallpaper_1920x1080.svg 50

+ read background priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/images/desktop-base/spacefun-wallpaper.svg 50

+ read background priority
+ update-alternatives --install 
/usr/share/images/desktop-base/desktop-background desktop-background 
/usr/share/images/desktop-base/spacefun-wallpaper-widescreen.svg 50

+ read background priority
+ 

Bug#842505: closed by Scott Kitterman <deb...@kitterman.com> (already not in unstable)

[Otto Kekäläinen]

Hello!

There is no actual explanation why this issue was closed. "Not in
unstable" isn't satisfactory.

The mentioned packages are still in both testing and unstable:
https://packages.debian.org/search?keywords=libmariadb-client-lgpl-dev=names=all=all



2016-11-05 6:32 GMT+02:00 Debian Bug Tracking System :
> This is an automatic notification regarding your Bug report
> which was filed against the ftp.debian.org package:
>
> #842505: RM: mariadb-client-lgpl -- ROM; obsoleted by mariadb-connector-c
>
> It has been closed by Scott Kitterman .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Scott Kitterman 
>  by
> replying to this email.
>
>
> --
> 842505: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842505
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Edelleenlähetetty viesti --
> From: Scott Kitterman 
> To: 842505-d...@bugs.debian.org
> Cc:
> Date: Sat, 05 Nov 2016 00:31:11 -0400
> Subject: already not in unstable
>
>
> -- Edelleenlähetetty viesti --
> From: "Otto Kekäläinen" 
> To: Debian Bug Tracking System 
> Cc: schep...@debian.org
> Date: Sat, 29 Oct 2016 22:41:10 +0300
> Subject: RM: mariadb-client-lgpl -- ROM; obsoleted by mariadb-connector-c
> Package: ftp.debian.org
> Severity: normal
>
> The source package mariadb-client-lgpl was renamed to
> mariadb-connector-c. At the same time some binary packages were also
> renamed.
>
> To finalize this change, please remove from testing and unstable the
> following binary packages that have become obsolete:
>
> * libmariadb-client-lgpl-dev
> * libmariadb-client-lgpl-dev-compat
>
> Please do not remove libmariadb2 or any other packages that are produced
> from the new mariadb-connector-c source package.
>
> While you are at it, please advice me if the automatic transition
> visible at
> https://release.debian.org/transitions/html/auto-mariadb-client-lgpl-rm.html 
> needs any further action than this.
>
> Thanks!
>



-- 
Otto Kekäläinen
https://keybase.io/ottok
Seravo Oy and MariaDB Foundation

Bug#843810: libgtk-3-0: gtk3 >= 3.21.4-1 does not show a menu in Firefox, virt-manager and probably many others

[D. B.]

What Jason said. It's fine for me, on 3.22.2, and more info is needed in
any case.

Also, I suspect it's quite likely this is a duplicate of Bug#843418

Bug#843821: RM: anon-proxy -- RoQA; orphaned, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Hi,
please remove anon-proxy. It's orphaned for 2.5 years without an
adopter and dead upstream.

Cheers,
   Moritz

Bug#840673: dput missing a dependency on python setuptools library [and 1 more messages]

[Matthias Klose]

On 09.11.2016 21:44, Goirand Thomas (aka zigo) wrote:
> 
> On Nov 9, 2016 5:56 PM, Ian Jackson  wrote:
>>
>> Ian Jackson writes ("dput missing a dependency on python setuptools 
>> library"): 
>>>   (build)root@zealot:~# dput 
>> ... 
>>>   raise DistributionNotFound(req, requirers) 
>>>   pkg_resources.DistributionNotFound: The 'setuptools' distribution was not 
>>> found and is required by dput 
>>
>> Are there any plans to fix this in python ?  (I'm not really familiar 
>> enough with the python module and loading system to do so myself.) 
> 
> Every python module is installed with an "egg-info" folder
> containing a "require.txt" file that contains Python module deps.
> 
> What's happening here is probably dput having a Python dep
> on setuptools but it's not expressed in the Debian package's
> runtime Depends:. The way to fix it would be patching the
> dput Python requires (probably, that's in setup.py), or add the
> Depends: python-setuptools in the dput package. But I haven't
> looked at the issue so I can't tell which one of actions to do.

it's surprising that dput would need a dependency on the setuptools egg instead
of the pkg_resources egg.  A dependency on the setuptools egg just sounds plain
wrong.

Do you have a test case why a dependency on the setuptools egg is needed?

Matthias

Bug#842454: [debian-mysql] Bug#842454: Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

[Otto Kekäläinen]

2016-10-30 1:45 GMT+03:00 Kristian Nielsen :
> Clearly, these libmariadb plugins need to have an arch-dependent path. I
> suppose they also need a path that includes the major .so version number of
> the libmariadbclient.
>
> Maybe something like this is needed on the cmake command?
>
>   -DINSTALL_PLUGINDIR=/usr/lib/x86_64-linux-gnu/mysql/lib18/plugin
>
> That build option seems to be what determines where the client library will
> look for its plugin.
>
> (This build option seems to be shared between the server plugins and the
> client plugins, which seems a bit of a mess, and might require a separate
> build for the server package and the client library package - but maybe that
> is already the case anyway?)

I tried this avenue but indeed the PLUGINDIR parameter then also
changes where all the server plugins (TokuDB, Spider etc) are
installed, so that is not an option.

Can you Kristian help us introduce in the makefiles a new parameter
CLIENTPLUGINDIR?

Or what if we keep the PLUGINDIR=lib/mysql/plugin but then in a later
stage in the rules file move the two client plugins?
  mv lib/mysql/plugin/dialog.so  lib/$(DEB_HOST_MULTIARCH)/mariadb-lib18/plugin
  mv lib/mysql/plugin/mysql_clear_password.so
lib/$(DEB_HOST_MULTIARCH)/mariadb-lib18/plugin

Or if we move the plugins to a separate package, called maybe
mariadb-plugin-clientauth that would contain these two files? Then the
libmariadbclient18 package would stay "clean". I would however need to
depend on the mariadb-plugin-clientauth package however..


And it was still unclear to me if the libmariadbclient18 and
libmariadbd packages should have "Multi-Arch: same" or what? That is
what we strive for with the above changes, right?


(For reference, in mariadb-connector-c shared libs are built with
'dh_makeshlibs -X/mariadb/plugin/' and installed to
usr/lib/*/mariadb/plugin/*.so, and it has 'Multi-Arch: same' - see
https://anonscm.debian.org/cgit/pkg-mysql/mariadb-client-lgpl.git/tree/debian)

Bug#843815: O: libnmap-parser-perl -- parse nmap scan data with perl

[Axel Beckert]

Control: retitle -1 ITA: libnmap-parser-perl -- parse nmap scan data with perl

Hi,

Tobias Frost wrote:
> The current maintainer of libnmap-parser-perl, Joshua D. Abraham 
> ,
> has orphaned this package.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

I'll take it over under the umbrella of the Debian Perl Team.

Funnily I did not know about its existence and could have used that
module earlier today. Well, the next nmap parsing script will surely
come and this will make my life easier. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://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#843809: check that executables don't link to libraries in /usr is broken wrt libsystemd-shared

[Michael Biebl]

Am 09.11.2016 um 22:11 schrieb Ansgar Burchardt:
> Michael Biebl writes:
>> But now we have a different issue, ldd thinks, that liblz4 is in /lib.:
> [...]
>> This is because of merged-usr. This more or less renders the whole check
>> useless once we build in a chroot which has been created with
>> debootstrap --merged-usr
>>
>> Dunno, maybe we should just drop the check again. Thoughts?
> 
> I suppose one could ask dpkg where it thinks the library belongs to.

That's non-trivial, afaics.

> But as far as I understand, we require /usr is available early, that is
> /usr must already be mounted by the initramfs if it is a separate
> partition.  Making sure nothing in the root partition links against
> libraries from /usr seems a moot exercise when /usr should already be
> available even on non-merged-/usr systems.

We should clearly communicate this then, but I have no good idea how.
Ideally we'd have a preinst check which tests if /usr is separate and
there is no initramfs. But a check for that sounds brittle.

The second best would be, to document it officially.
So next time a user comes around like in [1] or [2], we can simply point
him/her there and close it wontfix

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771652
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788913


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#843820: O: zpb-ttf -- TTF parser

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of zpb-ttf, Pierre THIERRY 
,
is apparently not active anymore.  Therefore, I orphan this package now.

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

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

Some information about this package:

Package: zpb-ttf
Binary: cl-zpb-ttf
Version: 0.7-2
Maintainer: Pierre THIERRY 
Build-Depends: cdbs, debhelper (>= 5)
Build-Depends-Indep: dh-lisp
Architecture: all
Standards-Version: 3.7.2
Format: 1.0
Files:
 dfd25e1f750bd2b8d632435bb207a940 600 zpb-ttf_0.7-2.dsc
 6eea38e0207eb56b688725f03b726c7e 47022 zpb-ttf_0.7.orig.tar.gz
 e21dddcd22dd5ef9e1c2b7e2eb544423 1811 zpb-ttf_0.7-2.diff.gz
Checksums-Sha256:
 fde5024d0325c4b9a212e7c90d253e24c8d6bd16598c61b401fbb8d1645a65c7 600 
zpb-ttf_0.7-2.dsc
 df8cda6bfd9cf17a3f1dc70a9ba64c1f2cb2ff71d4d4db12d7f5c3357d43161a 1811 
zpb-ttf_0.7-2.diff.gz
 fb70eea4d7270d2860edb96438dfb72b1563a8c2652a0360f219f68ef23b22fb 47022 
zpb-ttf_0.7.orig.tar.gz
Directory: pool/main/z/zpb-ttf
Priority: source
Section: libs

Package: cl-zpb-ttf
Source: zpb-ttf
Version: 0.7-2
Installed-Size: 244
Maintainer: Pierre THIERRY 
Architecture: all
Depends: common-lisp-controller (>= 5.11)
Description-en: TTF parser
 ZPB-TTF is a TrueType file parser that provides an interface for reading
 typographic metrics, glyph outlines, and other information from a TTF file.
Description-md5: 420dde4695cbce63147a971261d0d6b4
Section: lisp
Priority: optional
Filename: pool/main/z/zpb-ttf/cl-zpb-ttf_0.7-2_all.deb
Size: 48862
MD5sum: 9eadf919016120b7b0e4abd1c5dde2ac
SHA256: f02e4c8cfc8456ace2d7ebfbbb90bf0500d94be0e3414d1a0bb2fc29b2a17760



signature.asc
Description: PGP signature

Bug#843810: libgtk-3-0: gtk3 >= 3.21.4-1 does not show a menu in Firefox, virt-manager and probably many others

[Jason Crain]

On Wed, Nov 09, 2016 at 09:26:34PM +0100, Marc-Christian Petersen wrote:
> there seems to be a problem with gtk3 >= 3.21.4-1. Please see #839029 also.
> When using gtk3 3.21.4-1 or above, virt-manager, Firefox and maybe also others
> are not able to show a menu (when pressing Alt-F for example). Downgrading 
> gtk3
> to 3.20.9-1 fixes it, so Firefox and virt-manager are usable again.

Alt-F in firefox and virt-manager works fine for me.  What version of
firefox are you using and where did you get it from?  What desktop
environment are you using?  Are you using any themes or the default
Adwaita theme?  Does it work differently if you try in wayland vs xorg?

Bug#813940: forked-daapd: Fails to scrobble plays to lastfm

[Bálint Réczey]

Control: forwarded -1
https://github.com/ejurgensen/forked-daapd/commit/d66a130064f4c9f7f4b02f586a67d4e1f3a470de
Control: tags -1 upstream fixed-upstream confirmed

Hi Chris,

2016-02-06 22:47 GMT+01:00 Chris Carr :
> Package: forked-daapd
> Version: 22.0-2
> Severity: normal
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> I played some songs and checked my lastfm profile
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> I followed the instructions to put my lastfm credentials into a temporary file
> which would enable forked-daapd to obtain a lastfm session key when it started
> up.
>
>* What was the outcome of this action?
>
> The log file (attached) shows that forked-daapd obtained a lastfm session key,
> but none of my plays have been scrobbled.
>
>* What outcome did you expect instead?
>
> I expected each played track to be scrobbled, either as it finished, or every
> hour, or something.

Upstream fixed the issue.
The fix will be in Stretch as part of the next upstream release of as
a cherry-picked patch.

Cheers,
Balint

Bug#843819: gnome-terminal: Parenthesis in the directory name leads to crash

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 09.11.2016 um 22:04 schrieb Pr0metheus:
> Package: gnome-terminal
> Version: 3.22.1-1
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> I have folders with greek characters. I can change directory to any of
> them without problem.
> Inside one of these folders i create a directory with english
> characters using gnome nautilus, e.g. LLC (3350)
> I open a terminal and try to change directory to the new folder, after
> i type the command: cd LLC (3350) and hit enter terminal closes without 
> notice.
> 


I can't reproduce this. This sounds more like an issue with your shell.
I simply get:
$ cd LLC (3350)
bash: syntax error near unexpected token `('


Which shell do you use?
Can you get a backtrace of the crash?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#843808: libgdal20: Depends on unwanted packages

[Leandro Guimaraes Faria Corcete DUTRA]

Le mercredi 09 novembre 2016 à 21:57 +0100, Sebastiaan Couwenberg a
écrit :
> 
> Then you need to build gdal yourself, on Gentoo perhaps.

Sorry if I irritated you.  It is not such a huge issue.


> > Several other packages have can interface with many data sources
> > without needing to have an arbitrary one installed.
> 
> When linking to a library, a dependency on the respective library
> package is required. Unless dlopen is used, which is not the case for
> most GDAL drivers.

OK, now you gave me a pointer I could possibly follow with my limited
knowledge: https://trac.osgeo.org/gdal/ticket/3212#comment:3


> But other people are still not convinced, and are using MySQL/MariaDB
> instead of PostgreSQL. You'll need to get those people to switch to
> PostgreSQL before we can consider dropping support for MySQL/MariaDB
> in GDAL.

Am not such a crusader.


> You clearly don't understand.

I clearly do not intend to supersede MySQL, only to clean my system. 
And yes, I clearly do not understand the technicalities.


> As long as people are using MySQL/MariaDB
> instead of PostgreSQL there is demand for support of those databases
> in GDAL, and hence for that support to be enabled in the gdal package
> in Debian.

You just told me dlOpen could make this issue moot.  I will follow that
track for now, thanks.


> If you want to patch that away because you don't have the need for
> that support, please do so in your fork of the package which only has
> to support your needs. The gdal package in Debian needs to service
> the needs of many more people than you. I have no need for the
> MySQL/MariaDB support either, but I've re-instated the support after
> the MariaDB packages were fixed on mips4el, because other users of
> the package do have that need.

It seems to me like you are upset because of other discussions with
other issues and is just venting on me.


> And in Debian one of our priorities are our users, which
> are many more people than just you and me.

I fully appreciate that.  It just do not seem the issue, rather a gDal
limitation.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm

Bug#843809: check that executables don't link to libraries in /usr is broken wrt libsystemd-shared

[Ansgar Burchardt]

Michael Biebl writes:
> But now we have a different issue, ldd thinks, that liblz4 is in /lib.:
[...]
> This is because of merged-usr. This more or less renders the whole check
> useless once we build in a chroot which has been created with
> debootstrap --merged-usr
>
> Dunno, maybe we should just drop the check again. Thoughts?

I suppose one could ask dpkg where it thinks the library belongs to.

But as far as I understand, we require /usr is available early, that is
/usr must already be mounted by the initramfs if it is a separate
partition.  Making sure nothing in the root partition links against
libraries from /usr seems a moot exercise when /usr should already be
available even on non-merged-/usr systems.

Ansgar

Bug#806940: [pkg-gnupg-maint] Bug#806940: gpgv-static possible?

[Hans-Christoph Steiner]

For the use cases I've outlined, gpgv-static definitely does not need
LDAP/PAM/NFS/whatever, and would probably be totally fine without all
kinds of tilde expansion.

Daniel Kahn Gillmor:
> Tilde expansion isn't super important -- it certainly shouldn't be used
> in debootstrap.  And if the result was a crash i'd really want to find a
> workaround here.  Out of curiosity, how is HAVE_PWD_H set (or unset) in
> the config.h for your static build against bionic libc?

The Android toolchain (aka NDK) does not set HAVE_PWD_H, but in my
Android builds of gnupg 2.1, it is set:

  #define HAVE_PWD_H 1

And Android does indeed have that header at, for example:
/opt/android-ndk/platforms/android-21/arch-x86/usr/include/pwd.h


Daniel Kahn Gillmor:
> given that the statically-built binary appears to fail gracefully in the
> absence of libnss inside a chroot, though, i'm inclined to not bother
> with either of these approaches.

I'm fine with trying it as is.  Otherwise, just remove NSS/LDAP/etc and
tilde expansion entirely and be done with it.



Here's my stab at the description:

 GnuPG is GNU's tool for secure communication and data storage.
 It can be used to encrypt data and to create digital signatures.
 It includes an advanced key management facility and is compliant
 with the proposed OpenPGP Internet standard as described in RFC 4880.
 .
 This is GnuPG's signature verification tool, gpgv, built statically
 so that it can be directly used on any platform that is running on
 the Linux kernel.  Android and ChromeOS are two well known examples,
 but there are many other platforms that this will work for, like
 embedded Linux OSes.  This gpgv in combination with debootstrap
 and Debian keyrings allows the secure creation of chroot installs on
 these platforms by using the full Debian signature verification that
 is present in all official Debian mirrors.

.hc

Bug#843819: gnome-terminal: Parenthesis in the directory name leads to crash

[Pr0metheus]

Package: gnome-terminal
Version: 3.22.1-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

I have folders with greek characters. I can change directory to any of
them without problem.
Inside one of these folders i create a directory with english
characters using gnome nautilus, e.g. LLC (3350)
I open a terminal and try to change directory to the new folder, after
i type the command: cd LLC (3350) and hit enter terminal closes without notice.

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

I renamed the directory and removed the parenthesis and change
directory worked but this is not a solution

   * What was the outcome of this action?

Crash

   * What outcome did you expect instead?

Enter the directory containing the parenthesis in its name and continue
my work



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

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

Versions of packages gnome-terminal depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gconf-service3.2.6-4
ii  gnome-terminal-data  3.22.1-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-5
ii  libdconf10.26.0-2
ii  libgconf-2-4 3.2.6-4
ii  libglib2.0-0 2.50.2-1
ii  libgtk-3-0   3.22.3-1
ii  libnautilus-extension1a  3.22.1-2
ii  libpango-1.0-0   1.40.3-3
ii  libuuid1 2.29-1
ii  libvte-2.91-00.46.1-1
ii  libx11-6 2:1.6.3-1

Versions of packages gnome-terminal recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.12-1
ii  dbus-x11 [dbus-session-bus]   1.10.12-1
ii  gvfs  1.30.2-2
ii  yelp  3.22.0-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#843818: fails to start with AttributeError: 'module' object has no attribute 'SSL_ST_INIT'

[Michael Biebl]

Package: virt-manager
Version: 1:1.4.0-3
Severity: grave

Trying to run virt-manager, I get

$ virt-manager 
Traceback (most recent call last):
  File "/usr/share/virt-manager/virt-manager", line 33, in 
from virtinst import util as util
  File "/usr/share/virt-manager/virtinst/__init__.py", line 89, in 
from virtinst.distroinstaller import DistroInstaller
  File "/usr/share/virt-manager/virtinst/distroinstaller.py", line 23, in 

from . import urlfetcher
  File "/usr/share/virt-manager/virtinst/urlfetcher.py", line 34, in 
import requests
  File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line 52, in 

from .packages.urllib3.contrib import pyopenssl
  File "/usr/lib/python2.7/dist-packages/requests/packages/__init__.py", line 
58, in 
vendored('urllib3.contrib.pyopenssl')
  File "/usr/lib/python2.7/dist-packages/requests/packages/__init__.py", line 
32, in vendored
__import__(vendored_name, globals(), locals(), level=0)
  File "/usr/lib/python2.7/dist-packages/urllib3/contrib/pyopenssl.py", line 
54, in 
import OpenSSL.SSL
  File "/usr/lib/python2.7/dist-packages/OpenSSL/__init__.py", line 8, in 

from OpenSSL import rand, crypto, SSL
  File "/usr/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 112, in 
SSL_ST_INIT = _lib.SSL_ST_INIT
AttributeError: 'module' object has no attribute 'SSL_ST_INIT'




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

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

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gconf2   3.2.6-4
ii  gir1.2-gtk-3.0   3.22.3-1
ii  gir1.2-gtk-vnc-2.0   0.6.0-1
ii  gir1.2-libosinfo-1.0 1.0.0-2
ii  gir1.2-libvirt-glib-1.0  0.2.3-2
ii  gir1.2-vte-2.91  0.46.1-1
ii  librsvg2-common  2.40.16-1
ii  python-dbus  1.2.4-1
ii  python-gi3.22.0-1
ii  python-gi-cairo  3.22.0-1
ii  python-libvirt   2.4.0-1
ii  python-requests  2.11.1-1
pn  python2.7:any
pn  python:any   
ii  virtinst 1:1.4.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-spice-client-gtk-3.0  0.33-3
pn  gnome-icon-theme 
ii  libvirt-daemon-system2.4.0-1+b1

Versions of packages virt-manager suggests:
ii  gnome-keyring  3.20.0-3
ii  ksshaskpass [ssh-askpass]  4:5.8.2-1
pn  python-gnomekeyring
pn  python-guestfs 
ii  ssh-askpass1:1.2.4.1-9
ii  virt-viewer4.0-1

-- no debconf information

Bug#813658: virglrenderer support before the freeze?

[Andreas Cadhalpun]

Hi intrigeri,

On 09.11.2016 17:43, intrigeri wrote:
> Michael Tokarev:
>> I looked at this matter a bit more.  I switched from sdl1 to gtk3
>> and enabled gl and virglrenderer.  It works.
> 
> Thanks a lot for looking into it! I'm interested in this because
> a number of people run Tails in virtual machines, and virt-manager +
> QEMU is our best supported platform so far.

If you want to use virgl with virt-manager you don't need to enable
gtk3 or sdl2, only virglrenderer and opengl.
However, you also need a newer libspice-server-dev (0.13.2).
With qemu built that way virgl works fine for virt-manager and
even gnome-boxes.

Best regards,
Andreas

Bug#843808: libgdal20: Depends on unwanted packages

[Sebastiaan Couwenberg]

On 11/09/2016 09:41 PM, Guimarães Faria Corcete DUTRA, Leandro wrote:
> 2016-11-09 18:30 GMT-02:00 Sebastiaan Couwenberg :
>> On 11/09/2016 09:02 PM, Leandro Guimaraes Faria Corcete DUTRA wrote:
>>>   Please make all DB drivers, or at least the Maria ones, only
>>> recommendations, not hard dependencies.
>>
>> I'm sorry to hear you don't like MariaDB packages.
> 
> Actually it is more that I do not see the need for it, even if it is
> true that I do not like Maria DB.  And I would like to keep my systems
> as lean as possible.

Then you need to build gdal yourself, on Gentoo perhaps. Because Debian
packages tend to enable as much features as possible, unlike Gentoo
where USE flags help to limit the features to just those you need.

>> GDAL is built with
>> MySQL/MariaDB support because ogr2ogr is one of the few viable options
>> to get spatial data into those databases. Hence the dependency on
>> libmariadbclient18 is required to not cause segfaults when using libgdal20.
> 
> I do not follow, why ogr2ogr would need MySQL or Maria DB, when all I
> want to use is PostGIS?

Because you are not the only user the gdal packages. See the recent
discussion about the MySQL/MariaDB support on the debian-gis list.

>> Having the libmariadbclient18 package installed does not hinder your use
>> of PostgreSQL for which libgdal20 depends on libpq5. GDAL interfaces
>> with many data sources, that includes several most people won't use.
>> It's just the nature of the library.
> 
> Several other packages have can interface with many data sources
> without needing to have an arbitrary one installed.

When linking to a library, a dependency on the respective library
package is required. Unless dlopen is used, which is not the case for
most GDAL drivers.

>> If don't want packages depending on MySQL/MariaDB packages, help make
>> PostgreSQL such an awesome database that people will not be able to
>> justify using something else.
> 
> It is already as far as I am concerned.

But other people are still not convinced, and are using MySQL/MariaDB
instead of PostgreSQL. You'll need to get those people to switch to
PostgreSQL before we can consider dropping support for MySQL/MariaDB in
GDAL.

>> That work includes patching many projects
>> to support PostgreSQL as a first class database backend to not have them
>> require MySQL/MariaDB as the only option.
> 
> You mean it is an arbitrary decision by the gDal developers that could
> simply be patched away?

You clearly don't understand. As long as people are using MySQL/MariaDB
instead of PostgreSQL there is demand for support of those databases in
GDAL, and hence for that support to be enabled in the gdal package in
Debian.

If you want to patch that away because you don't have the need for that
support, please do so in your fork of the package which only has to
support your needs. The gdal package in Debian needs to service the
needs of many more people than you. I have no need for the MySQL/MariaDB
support either, but I've re-instated the support after the MariaDB
packages were fixed on mips4el, because other users of the package do
have that need. And in Debian one of our priorities are our users, which
are many more people than just you and me.

Kind Regards,

Bas

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

Bug#843817: jmtpfs: stat returns wrong file size

[John Kozak]

Package: jmtpfs
Version: 0.5-2
Severity: normal

Dear Maintainer,

My mobile phone (OnePlus One) when mounted via jmtpfs, misreports the size
of jpg files (via stat or ls), giving them as five bytes too small.  The
files can be copied over to a local disk and appear to be well-formed.
Running wc against the jmtpfs-mounted device gives the correct byte count.

This breaks the de-duplication in git annex.

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

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

Versions of packages jmtpfs depends on:
ii  fuse  2.9.3-15+deb8u2
ii  libc6 2.19-18+deb8u6
ii  libfuse2  2.9.3-15+deb8u2
ii  libgcc1   1:4.9.2-10
ii  libmagic1 1:5.22+15-2+deb8u2
ii  libmtp9   1.1.8-1+b1
ii  libstdc++64.9.2-10
ii  libusb-1.0-0  2:1.0.19-1

jmtpfs recommends no packages.

jmtpfs suggests no packages.

-- no debconf information

--
John

Bug#843809: check that executables don't link to libraries in /usr is broken wrt libsystemd-shared

[Michael Biebl]

Am 09.11.2016 um 21:18 schrieb Michael Biebl:
> In a chroot, systemd and libsytemd-shared are not installed.
> We probably need to override LD_LIBRARY_PATH and point it to
> debian/systemd/lib/systemd/

This patch works to find libsystemd-shared:

> --- a/debian/rules
> +++ b/debian/rules
> @@ -326,7 +326,7 @@ ifeq (, $(filter nocheck, $(DEB_BUILD_OPTIONS)))
>   debian/systemd/lib/systemd/system-generators/* \
>   debian/udev/lib/systemd/systemd*; do \
> echo " $$e"; \
> -   OUT=`env -u LD_PRELOAD ldd $$e` || continue; if echo "$$OUT" | 
> grep -q /usr; then \
> +   OUT=`env -u LD_PRELOAD 
> LD_LIBRARY_PATH=debian/systemd/lib/systemd/ ldd $$e` || continue; if echo 
> "$$OUT" | grep -q /usr; then \
> echo "ERROR: $$e links to /usr"; echo "$$OUT"; exit 1; \
> fi; \
> done

But now we have a different issue, ldd thinks, that liblz4 is in /lib.:

> + echo  debian/systemd/lib/systemd/systemd
>  debian/systemd/lib/systemd/systemd
> + env -u LD_PRELOAD LD_LIBRARY_PATH=debian/systemd/lib/systemd/ ldd 
> debian/systemd/lib/systemd/systemd
> + OUT=linux-vdso.so.1 (0x7ffeb311)
>   libsystemd-shared-232.so => 
> debian/systemd/lib/systemd/libsystemd-shared-232.so (0x7f886a9a3000)
...
>   liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f8868c82000)

This is because of merged-usr. This more or less renders the whole check
useless once we build in a chroot which has been created with
debootstrap --merged-usr

Dunno, maybe we should just drop the check again. Thoughts?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#843816: O: gdevilspie -- User friendly interface for devilspie

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of gdevilspie, Chris Silva ,
is apparently not active anymore.  Therefore, I orphan this package now.

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

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

Some information about this package:

Package: gdevilspie
Binary: gdevilspie
Version: 1:0.5-3.2
Maintainer: Chris Silva 
Build-Depends: debhelper (>= 8.0.0), python, dh-python
Architecture: all
Standards-Version: 3.9.3
Format: 3.0 (quilt)
Files:
 ec745898f5ccb08fddfc592a224d1c94 1727 gdevilspie_0.5-3.2.dsc
 0efd0803433176bf0bdaa0dcef63671f 31520 gdevilspie_0.5.orig.tar.gz
 1136cedfa3c4a778290dfee41ab51dc0 3828 gdevilspie_0.5-3.2.debian.tar.xz
Checksums-Sha256:
 069d22d4d6444b34428927692f42348540f0e448c7d0c94a3e3dda4547c88c35 1727 
gdevilspie_0.5-3.2.dsc
 5387b1ee090fad14beb99b11dab81a8755009b37620849bd72abd79d4829131a 31520 
gdevilspie_0.5.orig.tar.gz
 21b3e8fab971b3c4180d49e5f48b6ede1a8dacf916192d1e63a2091d77d9f9f9 3828 
gdevilspie_0.5-3.2.debian.tar.xz
Homepage: http://code.google.com/p/gdevilspie/
Package-List: 
 gdevilspie deb gnome extra arch=all
Directory: pool/main/g/gdevilspie
Priority: source
Section: gnome

Package: gdevilspie
Version: 1:0.5-3.2
Installed-Size: 114
Maintainer: Chris Silva 
Architecture: all
Depends: python, python:any (<< 2.8), python:any (>= 2.7.5-5~), python-wnck, 
python-glade2
Recommends: python-xdg, devilspie
Description-en: User friendly interface for devilspie
 gDevilspie is a graphical front-end for editing the Devilspie configuration
 file which allows you to run a particular application within a particular
 workspace in the GNOME panner in a particular manner.
 .
 gDevilspie also allows you to start and stop the Devilspie daemon.
Description-md5: 6a05f6cf36fb261ac0a7097307094ebb
Homepage: http://code.google.com/p/gdevilspie/
Tag: interface::graphical, interface::x11, role::program, uitoolkit::gtk,
 x11::application
Section: gnome
Priority: extra
Filename: pool/main/g/gdevilspie/gdevilspie_0.5-3.2_all.deb
Size: 19946
MD5sum: ad165cb835b44a7a3cbfdacb4d544c0f
SHA256: f32b90ea97a254eaf35186d35e1aecb9b489e940fd35b1c1d601d71e2beab864



signature.asc
Description: PGP signature

Bug#843640: bluez: Unable to transfer files over bluetooth - no file transfer settings shown

[Michal Zimen]

Hi,

try to run this:

  systemctl --user start obex

  systemctl enable --user obex.service

and then you should see the  process /usr/lib/bluetooth/obexd running*
*


Michal+


On 11/08/2016 03:00 PM, Julian Gilbey wrote:

On Tue, Nov 08, 2016 at 01:54:44PM +, Julian Gilbey wrote:

Package: bluez
Version: 5.43-1
Severity: important

The settings window (shown in attached screenshots) says "Applet's
transfer service plug-in is disabled".  I have no idea how to enable
it, though.  I do have bluez-obexd installed, if that is of any help.

I wonder whether it is a permissions issue, as when I run
blueman-services as root, it shows the transfer dialog fine.

Julian



--
~Epitheton s.r.o./AMDG

Bug#843210: binutils-multiarch: ar and ranlib generates undeterministic symbol table ar entries

[Ximin Luo]

On Sat, 5 Nov 2016 13:37:08 +0100 Guillem Jover  wrote:
> Control: reassign -1 binutils-multiarch
> Control: retitle -1 binutils-multiarch: ar and ranlib generates 
> undeterministic symbol table ar entries
> 
> Hi!
> 
> It seems the culprit is binutils-multiarch, binutils works just fine.
> 

I can confirm this. Minimal test case:

$ touch lol && ar cruv lol.a lol && xxd lol.a | head -n4
ar: `u' modifier ignored since `D' is the default (see `U')
r - lol
: 213c 6172 6368 3e0a 2f53 594d 3634 2f20  !./SYM64/ 
0010: 2020 2020 2020 2020 3134 3738 3732 3431  14787241
0020: 3239 2020 3020 2020 2020 3020 2020 2020  29  0 0 
0030: 3020 2020 2020 2020 3732 2020 2020 2020  0   72  

Watch the timestamp increase as you run this repeatedly. It doesn't happen with 
ar from binutils, only binutils-multiarch.

However, it looks like it might be an upstream issue - notice the explicit 
notice saying that `D' is supposedly the default, yet there's a timestamp 
there. So the Debian package is passing in the correct configure flag 
(--enable-deterministic-archives) but it's not being respected for some reason.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#843815: O: libnmap-parser-perl -- parse nmap scan data with perl

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of libnmap-parser-perl, Joshua D. Abraham 
,
has orphaned this package.

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

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

Some information about this package:

Package: libnmap-parser-perl
Binary: libnmap-parser-perl
Version: 1.05-2
Maintainer: Joshua D. Abraham 
Build-Depends: debhelper (>= 5)
Build-Depends-Indep: perl (>= 5.8.0-7), libxml-twig-perl
Architecture: all
Standards-Version: 3.7.2
Format: 1.0
Files:
 0fd4f21c8f8a95a2f2096952bacac938 667 libnmap-parser-perl_1.05-2.dsc
 5d5f113a9d166b07e041a5dc52f9c3ee 34451 libnmap-parser-perl_1.05.orig.tar.gz
 e2dc4439e0f35308ab140331031ea1e4 2134 libnmap-parser-perl_1.05-2.diff.gz
Checksums-Sha1:
 4c9c2b099838e1b960f69bdc821ce0e229e148a3 667 libnmap-parser-perl_1.05-2.dsc
 ec7be36308d126cc37392ad4a3608ed1f82728e6 2134 
libnmap-parser-perl_1.05-2.diff.gz
 e7c66709e6b0c8b40ea6f54ec6c6569d101f3f5c 34451 
libnmap-parser-perl_1.05.orig.tar.gz
Checksums-Sha256:
 e2a1fbec5a7e43f3f68649a61d13de16b45c15f6de56f72d9fd93d29be48847d 667 
libnmap-parser-perl_1.05-2.dsc
 a539534c6d3bf2d74685dcf92b1c507e1077ed4ec6c23e03e69975e02b66ae61 2134 
libnmap-parser-perl_1.05-2.diff.gz
 5979fa59078376ce752e9bd46fdc2b34b9a18199780412f5a3f257c82a31a759 34451 
libnmap-parser-perl_1.05.orig.tar.gz
Directory: pool/main/libn/libnmap-parser-perl
Priority: source
Section: perl

Package: libnmap-parser-perl
Binary: libnmap-parser-perl
Version: 1.05-2.1
Maintainer: Joshua D. Abraham 
Build-Depends: debhelper (>= 5)
Build-Depends-Indep: perl (>= 5.8.0-7), libxml-twig-perl
Architecture: all
Standards-Version: 3.7.2
Format: 1.0
Files:
 0dfd703f06efab2bbd9b4600e8bb754d 1909 libnmap-parser-perl_1.05-2.1.dsc
 5d5f113a9d166b07e041a5dc52f9c3ee 34451 libnmap-parser-perl_1.05.orig.tar.gz
 87852c7606d53966052ec823624ab2d5 2272 libnmap-parser-perl_1.05-2.1.diff.gz
Checksums-Sha256:
 5813c7852736c1a57cfb53f347b3bf64357f8b83acdbf649fb9ae14381f52934 1909 
libnmap-parser-perl_1.05-2.1.dsc
 5979fa59078376ce752e9bd46fdc2b34b9a18199780412f5a3f257c82a31a759 34451 
libnmap-parser-perl_1.05.orig.tar.gz
 3c7ad85ffd60803573845dc476770b356dd0ddd6fac2213536416ac511b414c7 2272 
libnmap-parser-perl_1.05-2.1.diff.gz
Package-List: 
 libnmap-parser-perl deb perl optional arch=all
Directory: pool/main/libn/libnmap-parser-perl
Priority: source
Section: perl

Package: libnmap-parser-perl
Binary: libnmap-parser-perl
Version: 1.05-2.1
Maintainer: Joshua D. Abraham 
Build-Depends: debhelper (>= 5)
Build-Depends-Indep: perl (>= 5.8.0-7), libxml-twig-perl
Architecture: all
Standards-Version: 3.7.2
Format: 1.0
Files:
 0dfd703f06efab2bbd9b4600e8bb754d 1909 libnmap-parser-perl_1.05-2.1.dsc
 5d5f113a9d166b07e041a5dc52f9c3ee 34451 libnmap-parser-perl_1.05.orig.tar.gz
 87852c7606d53966052ec823624ab2d5 2272 libnmap-parser-perl_1.05-2.1.diff.gz
Checksums-Sha1:
 a2682f829dc22f07645ff21386e04939f1f04bbc 1909 libnmap-parser-perl_1.05-2.1.dsc
 e7c66709e6b0c8b40ea6f54ec6c6569d101f3f5c 34451 
libnmap-parser-perl_1.05.orig.tar.gz
 c3a402cc53905ecd08e72903c23896cff61d0c64 2272 
libnmap-parser-perl_1.05-2.1.diff.gz
Checksums-Sha256:
 5813c7852736c1a57cfb53f347b3bf64357f8b83acdbf649fb9ae14381f52934 1909 
libnmap-parser-perl_1.05-2.1.dsc
 5979fa59078376ce752e9bd46fdc2b34b9a18199780412f5a3f257c82a31a759 34451 
libnmap-parser-perl_1.05.orig.tar.gz
 3c7ad85ffd60803573845dc476770b356dd0ddd6fac2213536416ac511b414c7 2272 
libnmap-parser-perl_1.05-2.1.diff.gz
Package-List: 
 libnmap-parser-perl deb perl optional arch=all
Directory: pool/main/libn/libnmap-parser-perl
Priority: source
Section: perl

Package: libnmap-parser-perl
Version: 1.05-2.1
Installed-Size: 80
Maintainer: Joshua D. Abraham 
Architecture: all
Depends: perl, libxml-twig-perl
Recommends: nmap
Description-en: parse nmap scan data with perl
 It is implemented by parsing the xml scan data that is generated by nmap. This
 will enable anyone who utilizes nmap to quickly create fast and robust
 security scripts that utilize the powerful port scanning abilities of nmap.
Description-md5: 160ba80fa26b1a2ac37a1208a8bbdd61
Tag: devel::lang:perl, implemented-in::perl
Section: perl
Priority: optional
Filename: 
pool/main/libn/libnmap-parser-perl/libnmap-parser-perl_1.05-2.1_all.deb
Size: 34768
MD5sum: 3ed485a30223de0c93a7cad1d19d443c
SHA256: d43c695e395526a5b6bdb35e376ad9fcea077c380eb81a0e272b991e9b813636

Package: libnmap-parser-perl
Version: 1.05-2
Installed-Size: 136
Maintainer: Joshua D. Abraham 
Architecture: all
Depends: perl (>= 5.6.0-16), libxml-twig-perl
Recommends: nmap
Description-en: parse nmap scan data with perl
 It is implemented by parsing the xml scan data that is generated by 

Bug#843814: O: pbnj -- a suite of tools to monitor changes on a network

[Tobias Frost]

Package: wnpp
Severity: normal

The current maintainer of pbnj, Joshua D. Abraham ,
has orphaned this package.

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

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

Some information about this package:

Package: pbnj
Binary: pbnj
Version: 2.04-4
Maintainer: Joshua D. Abraham 
Build-Depends: debhelper (>= 5)
Build-Depends-Indep: perl (>= 5.8.0-7), libxml-twig-perl (>= 3.22), 
libnmap-parser-perl (>= 1.01), libdbd-sqlite3-perl (>= 1.11), 
libfile-which-perl (>= 0.05), libtext-csv-perl (>= 0.23), libfile-homedir-perl 
(>= 0.06), libyaml-perl (>= 0.39)
Architecture: all
Standards-Version: 3.7.2
Format: 1.0
Files:
 7deb623eb7e15451c4b55497b5c09ed8 793 pbnj_2.04-4.dsc
 f0a5b4dfa9456c21154a289e1e45b1d5 86080 pbnj_2.04.orig.tar.gz
 63a0257a07b42865f3603d9148c92cb5 2724 pbnj_2.04-4.diff.gz
Checksums-Sha1:
 cd2f12a1a3a2dfbc3a58c561760f43e9038d017e 793 pbnj_2.04-4.dsc
 8c6b2e1e822757b7cfa4de2cb3835fbcec8c836f 2724 pbnj_2.04-4.diff.gz
 dc15bdf07abb70525867ce1f643f5acc5687155a 86080 pbnj_2.04.orig.tar.gz
Checksums-Sha256:
 4f4dac2825f0fa4a58580b4c23d6327a1e11519a2a1c97b501761d2d14018dd0 793 
pbnj_2.04-4.dsc
 a6e4de5338c6baf11f686864d72f48c0378a346f1b30644563a6b911b9db1595 2724 
pbnj_2.04-4.diff.gz
 3df88ea306bd47401766d69f32e5cd1fdc1f015e6a06c66a7fa7aba7dfd0f3b9 86080 
pbnj_2.04.orig.tar.gz
Directory: pool/main/p/pbnj
Priority: source
Section: net

Package: pbnj
Binary: pbnj
Version: 2.04-4.1
Maintainer: Joshua D. Abraham 
Build-Depends: debhelper (>= 5)
Build-Depends-Indep: perl (>= 5.8.0-7), libxml-twig-perl (>= 3.22), 
libnmap-parser-perl (>= 1.01), libdbd-sqlite3-perl (>= 1.11), 
libfile-which-perl (>= 0.05), libtext-csv-perl (>= 0.23), libfile-homedir-perl 
(>= 0.06), libyaml-perl (>= 0.39)
Architecture: all
Standards-Version: 3.7.2
Format: 1.0
Files:
 3563b6f8fab4f91601346ce046338bcb 1959 pbnj_2.04-4.1.dsc
 f0a5b4dfa9456c21154a289e1e45b1d5 86080 pbnj_2.04.orig.tar.gz
 6b6fd5e1386e11c477ffa7647c632485 2841 pbnj_2.04-4.1.diff.gz
Checksums-Sha256:
 717239508ec532f3f59e5f520efb511aa9e756680c358ca22237cdba294ab572 1959 
pbnj_2.04-4.1.dsc
 3df88ea306bd47401766d69f32e5cd1fdc1f015e6a06c66a7fa7aba7dfd0f3b9 86080 
pbnj_2.04.orig.tar.gz
 16f0653da19de1b6e2819ebd67a59fb047196320927b4674af612ce8d1594821 2841 
pbnj_2.04-4.1.diff.gz
Package-List: 
 pbnj deb net optional arch=all
Directory: pool/main/p/pbnj
Priority: source
Section: net

Package: pbnj
Version: 2.04-4.1
Installed-Size: 143
Maintainer: Joshua D. Abraham 
Architecture: all
Depends: perl, nmap, libxml-twig-perl (>= 3.22), libnmap-parser-perl (>= 1.01), 
libdbd-sqlite3-perl (>= 1.11), libfile-which-perl (>= 0.05), libtext-csv-perl 
(>= 0.23), libfile-homedir-perl (>= 0.06), libyaml-perl (>= 0.39)
Recommends: sqlite3
Suggests: libdbd-mysql-perl | libdbd-pg-perl
Description-en: a suite of tools to monitor changes on a network
 PBNJ is a network suite to monitor changes that occur on a network
 over time. It does this by checking for changes on the target
 machine(s), which includes the details about the services running on
 them as well as the service state. PBNJ parses the data from a scan
 and stores it in a database. PBNJ uses Nmap to perform scans.
Description-md5: 37d10dd2fd4ed4f5479d5d44dc2e30e3
Tag: admin::monitoring, role::program, use::monitor
Section: net
Priority: optional
Filename: pool/main/p/pbnj/pbnj_2.04-4.1_all.deb
Size: 40738
MD5sum: 62994e40ece519120e4c6ef9b56f6619
SHA256: d6fee9307ceae640ce9e57af8e2041a29036f2f8357bc9f67709b79b7a4d82d3

Package: pbnj
Version: 2.04-4
Installed-Size: 224
Maintainer: Joshua D. Abraham 
Architecture: all
Depends: perl, nmap, libxml-twig-perl (>= 3.22), libnmap-parser-perl (>= 1.01), 
libdbd-sqlite3-perl (>= 1.11), libfile-which-perl (>= 0.05), libtext-csv-perl 
(>= 0.23), libfile-homedir-perl (>= 0.06), libyaml-perl (>= 0.39)
Recommends: sqlite3
Suggests: libdbd-mysql-perl | libdbd-pg-perl
Description-en: a suite of tools to monitor changes on a network
 PBNJ is a network suite to monitor changes that occur on a network
 over time. It does this by checking for changes on the target
 machine(s), which includes the details about the services running on
 them as well as the service state. PBNJ parses the data from a scan
 and stores it in a database. PBNJ uses Nmap to perform scans.
Description-md5: 37d10dd2fd4ed4f5479d5d44dc2e30e3
Tag: admin::monitoring, role::program, use::monitor
Section: net
Priority: optional
Filename: pool/main/p/pbnj/pbnj_2.04-4_all.deb
Size: 45912
MD5sum: a786ec034c4877512b2a48b5a144dcee
SHA1: b19ce5ebc1b0f7807779b67e6200ad0877e1e690
SHA256: aed194d9bab70266d03573580ef4d2d74f3d733e6a5a4ca1e262053321cc0e20

Package: pbnj
Version: 2.04-4.1
Installed-Size: 143

Bug#843243: gazebo: diff for NMU version 7.3.1+dfsg-1.1

[Gianfranco Costamagna]

control: tags -1 pending

On deferred/5

(patch attached)

G.
On Sat, 5 Nov 2016 12:11:51 + (UTC) Gianfranco Costamagna 
 wrote:
> Package: gazebo
> Version: 7.3.1+dfsg-1
> Severity: serious
> Justification: FTBFS with ongoing boost1.62 transition
> 
> Tags: patch
> 
> Dear maintainer,
> 
> I've prepared an NMU for gazebo (versioned as 7.3.1+dfsg-1.1) and
> not uploaded it :)
> 
> it is a cherry-pick of an upstream build fix (even if I found it after 
> uploading
> the fix in Ubuntu).
> Can you please apply and upload? this is fixing a build failure with the 
> current
> sid package.
> 
> Regards.
> 
> The NMU needs to sed UNRELEASED/unstable and to close this bug :)
> 
> 
> G.
diff -Nru gazebo-7.3.1+dfsg/debian/changelog gazebo-7.3.1+dfsg/debian/changelog
--- gazebo-7.3.1+dfsg/debian/changelog  2016-09-16 00:09:49.0 +0200
+++ gazebo-7.3.1+dfsg/debian/changelog  2016-11-09 21:36:30.0 +0100
@@ -1,3 +1,11 @@
+gazebo (7.3.1+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/fix-boost1.62.patch: cherry-pick upstream commit to fix
+a boost1.62 build failure due to a missing include (Closes: #843243).
+
+ -- Gianfranco Costamagna   Sat, 05 Nov 2016 
13:06:20 +0100
+
 gazebo (7.3.1+dfsg-1) unstable; urgency=medium
 
   * Imported Upstream version 7.3.1
diff -Nru gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch 
gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch
--- gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch1970-01-01 
01:00:00.0 +0100
+++ gazebo-7.3.1+dfsg/debian/patches/fix-boost1.62.patch2016-11-09 
21:36:30.0 +0100
@@ -0,0 +1,14 @@
+Description: fix a build failure with boost1.62
+Author: Carlos Agüero
+Origin: 
https://bitbucket.org/osrf/gazebo/commits/5a7cfea81159d5287a561bc8be035f89f0dc303d
+
+--- gazebo-7.3.1+dfsg.orig/gazebo/rendering/Camera.cc
 gazebo-7.3.1+dfsg/gazebo/rendering/Camera.cc
+@@ -25,6 +25,7 @@
+ 
+ #include 
+ #include 
++#include 
+ #include 
+ 
+ #ifndef _WIN32
diff -Nru gazebo-7.3.1+dfsg/debian/patches/series 
gazebo-7.3.1+dfsg/debian/patches/series
--- gazebo-7.3.1+dfsg/debian/patches/series 2016-09-15 23:57:55.0 
+0200
+++ gazebo-7.3.1+dfsg/debian/patches/series 2016-11-09 21:36:30.0 
+0100
@@ -4,3 +4,4 @@
 0009-fix-gcc6-linking.patch
 0001-fix_tinyxml_constant.patch
 0004-fix-status-double-declaration.patch
+fix-boost1.62.patch


signature.asc
Description: OpenPGP digital signature