Bug#812636: cross-gcc-4.9-ppc64el: FTBFS - build-depends gcc-4.9-source (= 4.9.3-5) when 4.9.3-11 is current

[Dima Kogan]

Michael Tautschnig  writes:

> Package: cross-gcc-4.9-ppc64el
> Version: 54
> Severity: serious
> Usertags: goto-cc
>
> During a rebuild of all Debian packages in a clean sid chroot (using 
> cowbuilder
> and pbuilder) the build failed with the following error.
>
> [...]
>  -> Considering build-dep gcc-4.9-source (= 4.9.3-5)
>   Tried versions: 4.9.3-11
>-> Does not satisfy version, not trying
> E: Could not satisfy build-dependency.

Hi. This is due to cross-gcc-dev being updated, but cross-gcc-4.9-xxx
not having been updated yet. I'll do that shortly.

Bug#812723: lintian: package-contains-broken-symlink should look at dependencies

[Sean Whitton]

Package: lintian
Version: 2.5.40.2
Severity: normal

Dear maintainers,

package-contains-broken-symlink gives a false positive when a package
contains a symlink to a file provided by another package, even when the
package with the warning depends on the package providing the target of
the symlink.

For an example, see the source package ublock-origin version
1.5.6+dfsg-1 in the Debian archive.

Thanks.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.3.0-1-686-pae (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 lintian depends on:
ii  binutils  2.25.90.20160101-2
ii  bzip2 1.0.6-8
ii  diffstat  1.60-1
ii  file  1:5.25-2
ii  gettext   0.19.7-2
ii  hardening-includes2.8+nmu2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.29+b5
ii  libarchive-zip-perl   1.56-2
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-1+b1
ii  libdpkg-perl  1.18.4
ii  libemail-valid-perl   1.198-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.413-1+b1
ii  libparse-debianchangelog-perl 1.2.0-8
ii  libperl5.22 [libdigest-sha-perl]  5.22.1-4
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  man-db2.7.5-1
ii  patchutils0.3.4-1
ii  perl  5.22.1-4
ii  t1utils   1.39-2
ii  xz-utils  5.1.1alpha+20120614-2.1

Versions of packages lintian recommends:
ii  dpkg 1.18.4
ii  libperlio-gzip-perl  0.19-1+b1
ii  perl 5.22.1-4
ii  perl-modules-5.22 [libautodie-perl]  5.22.1-4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.25.90.20160101-2
ii  dpkg-dev   1.18.4
ii  libhtml-parser-perl3.71-2+b1
ii  libtext-template-perl  1.46-1
ii  libyaml-perl   1.15-1

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#811460: [Debian-med-packaging] Bug#811460: ITP: fast5 -- library for reading Oxford Nanopore Fast5 files

[Afif Elghraoui]

Hi, Steffen,

على الإثنين 25 كانون الثاني 2016 ‫07:27، كتب Steffen Möller:
> Hi, I happily help with sponsoring 

That is much appreciated, but this package (together with nanopolish)
was already accepted :)

> and any feedback on how nice the
> nanopore is working for you would be appreciated :)

I myself have mostly just been working with Pacific Biosciences data,
but I thought Debian could get ahead and be prepared with software for
analysis of nanopore data.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#812724: gitlab: Failed to install. Should gitlab depend on nginx?

[Viktor Malyarchuk]

Package: gitlab
Version: 8.4.0+dfsg~rc2-2
Severity: important

Dear Maintainer,

gitlab fail to install with

/var/lib/dpkg/info/gitlab.postinst: 63: /var/lib/dpkg/info/gitlab.postinst: 
cannot create /etc/nginx/sites-available/localhost: Directory nonexistent
dpkg: error processing package gitlab (--configure):
 subprocess installed post-installation script returned error exit status 2

Nginx is not installed on the system. Should gitlab depend on it?

Best regards,
Viktor

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

Kernel: Linux 4.3.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 gitlab depends on:
ii  adduser3.113+nmu3
ii  asciidoctor1.5.3-1
ii  bc 1.06.95-9+b1
ii  debconf [debconf-2.0]  1.5.58
ii  gitlab-shell   2.6.10-1
ii  gitlab-workhorse   0.5.0-1
ii  libjs-chartjs  1.0.2-1
ii  libjs-clipboard1.4.2-1
ii  libjs-fuzzaldrin-plus  0.3.1-1
ii  libjs-graphael 0.5+dfsg-1
ii  libjs-jquery-cookie10-2
ii  libjs-jquery-history   10-2
ii  libjs-jquery-nicescroll3.6.6-1
ii  nodejs 5.5.0~dfsg-1
ii  postgresql 9.5+172
ii  postgresql-client-9.5 [postgresql-client]  9.5.0-2
ii  redis-server   2:3.2~rc1-3
ii  ruby   1:2.2.4
ii  ruby-ace-rails-ap  3.0.3-2
ii  ruby-activerecord-deprecated-finders   1.0.4-1
ii  ruby-activerecord-session-store0.1.1-2
ii  ruby-acts-as-taggable-on   3.5.0-2
ii  ruby-addressable   2.3.8-1
ii  ruby-after-commit-queue1.3.0-1
ii  ruby-allocations   1.0.3-1
ii  ruby-asana 0.4.0-1
ii  ruby-babosa1.0.2-1
ii  ruby-bootstrap-sass3.3.5.1-3
ii  ruby-browser   1.0.1-1
ii  ruby-cal-heatmap-rails 3.5.1+dfsg-1
ii  ruby-carrierwave   0.10.0+gh-1
ii  ruby-charlock-holmes   0.7.3+dfsg-2
ii  ruby-coffee-rails  4.1.0-2
ii  ruby-colored   1.2-2
ii  ruby-colorize  0.7.7-1
ii  ruby-creole0.5.0-2
ii  ruby-d3-rails  3.5.6+dfsg-1
ii  ruby-default-value-for 3.0.1-1
ii  ruby-devise3.5.2-3
ii  ruby-devise-async  0.9.0-1
ii  ruby-devise-two-factor 2.0.0-1
ii  ruby-diffy 3.0.6-1
ii  ruby-doorkeeper2.2.1-1
ii  ruby-dropzonejs-rails  0.7.1-1
ii  ruby-email-reply-parser0.5.8-1
ii  ruby-enumerize 1.0.0-1
ii  ruby-fog   1.34.0-2
ii  ruby-fogbugz   0.2.1-2
ii  ruby-font-awesome-rails4.3.0.0-1
ii  ruby-gemnasium-gitlab-service  0.2.6-1
ii  ruby-github-linguist   4.7.2-1
ii  ruby-github-markup 1.3.3+dfsg-1
ii  ruby-gitlab-emoji  0.2.1-1
ii  ruby-gitlab-flowdock-git-hook  1.0.1-1
ii  ruby-gitlab-git7.2.22-1
ii  ruby-gollum-lib4.1.0-3
ii  ruby-gon   6.0.1-1
ii  ruby-grack 2.0.2-1
ii  ruby-grape 0.13.0-1
ii  ruby-grape-entity  0.4.5-1
ii  ruby-haml-rails0.9.0-4
ii  ruby-hipchat   1.5.2-1
ii  ruby-html-pipeline 1.11.0-1
ii  ruby-httparty  0.13.5-1
ii  ruby-jquery-atwho-rails1.3.2-2
ii  ruby-jquery-rails  4.0.5-1
ii  ruby-jquery-scrollto-rails 1.4.3+dfsg-1
ii  ruby-jquery-turbolinks 2.1.0~dfsg-1
ii  ruby-jquery-ui-rails   5.0.5-3
ii  ruby-kaminari  0.16.3-1
ii  ruby-mail-room 0.6.1-1
ii  ruby-method-source 0.8.2-2
ii  

Bug#804281: Acknowledgement (python-setuptools: get_site_dirs in easy_install.py does not return the right path including dist-packages)

[Philipp Edelmann]

Control: found -1 18.8-1

The problem is still present in the current version of setuptools in sid
(18.8-1). I updated my patch to this version.

If I can do anything else to help fixing this in Debian, please let me
know.
diff -Nru python-setuptools-18.8/debian/changelog python-setuptools-18.8/debian/changelog
--- python-setuptools-18.8/debian/changelog	2015-12-13 22:51:45.0 +0900
+++ python-setuptools-18.8/debian/changelog	2016-01-26 13:43:21.0 +0900
@@ -1,3 +1,9 @@
+python-setuptools (18.8-1.1~tux1) unstable; urgency=medium
+
+  * Correct return value for get_site_dirs to use dist-packages.
+
+ -- Philipp Edelmann   Fri, 06 Nov 2015 21:06:34 +0100
+
 python-setuptools (18.8-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru python-setuptools-18.8/debian/patches/install-layout.diff python-setuptools-18.8/debian/patches/install-layout.diff
--- python-setuptools-18.8/debian/patches/install-layout.diff	2015-12-13 22:51:57.0 +0900
+++ python-setuptools-18.8/debian/patches/install-layout.diff	2016-01-26 13:48:16.0 +0900
@@ -1,5 +1,3 @@
-Index: b/setuptools/command/easy_install.py
-===
 --- a/setuptools/command/easy_install.py
 +++ b/setuptools/command/easy_install.py
 @@ -135,13 +135,15 @@ class easy_install(Command):
@@ -108,25 +106,26 @@
  for attr, val in scheme.items():
  if getattr(self, attr, None) is None:
  setattr(self, attr, val)
-@@ -1329,9 +1373,14 @@ def get_site_dirs():
-   "site-packages"),
-  os.path.join(prefix, "lib", "site-python")])
- else:
+@@ -1323,11 +1367,14 @@ def get_site_dirs():
+ if sys.platform in ('os2emx', 'riscos'):
+ sitedirs.append(os.path.join(prefix, "Lib", "site-packages"))
+ elif os.sep == '/':
+-sitedirs.extend([os.path.join(prefix,
+-  "lib",
+-  "python" + sys.version[:3],
+-  "site-packages"),
+- os.path.join(prefix, "lib", "site-python")])
 +if sys.version[:3] in ('2.3', '2.4', '2.5'):
 +sdir = "site-packages"
 +else:
 +sdir = "dist-packages"
- sitedirs.extend(
--[prefix, os.path.join(prefix, "lib", "site-packages")]
--)
++sitedirs.extend(
 +[os.path.join(prefix, "local/lib", "python" + sys.version[:3], sdir),
 + os.path.join(prefix, "lib", "python" + sys.version[:3], sdir)]
 +)
- if sys.platform == 'darwin':
- # for framework builds *only* we add the standard Apple
- # locations. Currently only per-user, but /Library and
-Index: b/setuptools/command/install_egg_info.py
-===
+ else:
+ sitedirs.extend(
+ [prefix, os.path.join(prefix, "lib", "site-packages")]
 --- a/setuptools/command/install_egg_info.py
 +++ b/setuptools/command/install_egg_info.py
 @@ -1,5 +1,5 @@


signature.asc
Description: PGP signature

Bug#812723: lintian: package-contains-broken-symlink should look at dependencies

[Adam D. Barratt]

On Mon, 2016-01-25 at 21:19 -0700, Sean Whitton wrote:
> package-contains-broken-symlink gives a false positive when a package
> contains a symlink to a file provided by another package, even when the
> package with the warning depends on the package providing the target of
> the symlink.
> 
> For an example, see the source package ublock-origin version
> 1.5.6+dfsg-1 in the Debian archive.

The tag description explicitly indicates that this is expected in the
situation you describe:

"The package contains a symlink but the destination for the link does
not exist in the package nor in its direct dependencies built from the
same source package."

xul-ext-ublock-origin and fonts-fonts-awesome are /not/ built from the
same source package.

Regards,

Adam

Bug#756316: iked failes to start

[Andreas Messer]

Hello,

the problem is caused by a bug in glibc package: 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810322

The problem can only reproduced on systems using TSX mutexes like Skylake 
or Broadwell CPUs. Workaround:

diff -r -u ike-orig/source/libith/libith.cpp ike/source/libith/libith.cpp
--- ike-orig/source/libith/libith.cpp   2012-02-10 08:05:36.0 +0100
+++ ike/source/libith/libith.cpp2016-01-08 11:42:32.0 +0100
@@ -94,7 +94,7 @@
 {
memset( obj_name, 0, 20 );
pthread_mutexattr_init(  );
-   pthread_mutexattr_settype( , PTHREAD_MUTEX_ERRORCHECK );
+   pthread_mutexattr_settype( , PTHREAD_MUTEX_NORMAL );
pthread_mutex_init( ,  );
 }

Works for me without problems so far.

Andreas

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

Bug#809923: New package proposal: nordlicht

[Peter Spiess-Knafl]

Hi Sebastian,

I modified the package including the following changes:

* New upstream release 0.4.4 (Fixes over-/underlinking, library
versioning, export symbol visibility)
* Add multiarch-support
* Add autopkgtest
* Fixed the symbols file


I pushed the changes to collab-maint [1].

I will send in an application to join debian-multimedia right now. If I
get accepted, I guess I also have to change the Maintainer-field in
d/control.

Thank you for your effort.

Greetings
Peter


[1]: http://anonscm.debian.org/cgit/collab-maint/nordlicht.git/

Bug#810299: debdiff

[Neil Roeth]

I have uploaded an NMU of sgml2x to the DELAYED/5 queue.  Please let me
know if I should delay longer or cancel.  Debdiff attached.

-- 
Neil Roeth

diff -u sgml2x-1.0.0/debian/changelog sgml2x-1.0.0/debian/changelog
--- sgml2x-1.0.0/debian/changelog
+++ sgml2x-1.0.0/debian/changelog
@@ -1,3 +1,11 @@
+sgml2x (1.0.0-11.4) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Removed dependencies on jade and openjade1.3 which are
+obsolete. (Closes: #810299).
+
+ -- Neil Roeth   Mon, 25 Jan 2016 20:30:28 -0500
+
 sgml2x (1.0.0-11.3) unstable; urgency=low
 
   * Non-maintainer upload.
diff -u sgml2x-1.0.0/debian/control sgml2x-1.0.0/debian/control
--- sgml2x-1.0.0/debian/control
+++ sgml2x-1.0.0/debian/control
@@ -3,12 +3,12 @@
 Priority: optional
 Maintainer: Yann Dirson 
 Build-Depends: debhelper (>> 5.0.0)
-Build-Depends-Indep: docbook-to-man, elinks, opensp, openjade1.3, openjade, 
docbook-dsssl
+Build-Depends-Indep: docbook-to-man, elinks, opensp, openjade, docbook-dsssl
 Standards-Version: 3.7.3
 
 Package: sgml2x
 Architecture: all
-Depends: opensp, openjade1.3 | openjade | jade, openjade, jadetex, 
${misc:Depends}
+Depends: opensp, openjade, jadetex, ${misc:Depends}
 Recommends: docbook-dsssl | docbook-stylesheets | alcovebook-sgml | 
sgmltools-lite | gtk-doc-tools (>= 1.1-1)
 Suggests: docbook-dsssl, sgmltools-lite, gtk-doc-tools, alcovebook-sgml
 Replaces: alcovebook-sgml (<< 0.0.999)
@@ -30,3 +29,0 @@
- .
- This package requires the DSSSL DTD from package openjade, although
- it can be used with any variant of jade.

Bug#812727: vmdebootstrap: better document SIZE setting

[Matt Taggart]

Package: vmdebootstrap
Version: 1.4-1
Severity: minor

The vmdebootstrap man page does not explain what units size is in or what 
unit suffixes are allowed. It appears it's just passing the setting to 
qemu-img directly, so maybe it should refer to that man page or just 
provide a summary (or both). Here is what qemu-img(1) says:

  size
   is the disk image size in bytes. Optional suffixes "k" or "K"
   (kilobyte, 1024) "M" (megabyte, 1024k) and "G" (gigabyte, 1024M)
   and T (terabyte, 1024G) are supported.  "b" is ignored.

So maybe it could say something like

 --size=SIZE
   create a disk image of size SIZE, in bytes (suffixes k,K,M,G,T
   are supported, see qemu-img(1) for more detail). (Default 1G)

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#812728: RFS: identity4c/1.0-1 [ITP] -- friendly greeter

[Richard Levenberg]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

  I am looking for a sponsor for my package "identity4c"

 * Package name: identity4c
   Version : 1.0-1
   Upstream Author : Richard Levenberg 
 * URL : https://github.com/ufpidentity/identity4c
 * License : GPL-2+
   Section : utils

  It builds those binary packages:

libufpidentity-dev - UFP Identity development library for C applications
 libufpidentity1 - UFP Identity library for C applications

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/identity4c


  Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/i/identity4c/identity4c_1.0-1.dsc

  More information about identity4c can be obtained from
https://github.com/ufpidentity/identity4c.

I need some additional help to make sure the binaries are installed
correctly with install-strip rather than install and I would appreciate
comments and criticism regarding the debian packaging.

This is precursor work to a PAM library that requires this library to
work. This library also works standalone for any C applications that
needs to integrate e.g. libnss, slapd plugins, etc.

  Regards,
   Richard Levenberg

Bug#693928: sbuild: Please support building without providing a version number

[Johannes Schauer]

Control: tag -1 + pending

Hi,

On Wed, 21 Nov 2012 20:56:50 + Roger Leigh  wrote:
> Mainly just notes so I don't forget:
> 
> Currently, sbuild uses a package_version syntax to specify the package and
> version to use when downloading the source package.  It would be useful in
> many cases to be able to just specify the package name only, and obtain the
> latest version in the specified distribution.

so today I realized how often I used the following pattern:

$ apt-get source --download-only foo
$ sbuild foo*.dsc

so I sat down and looked at how to implement this feature.

> Currently, Sbuild::Build copes with no version being provided.  It's just a
> matter of disabling the "invalid source" check.  But fetch_source_files
> currently has some requirements for knowing the version up-front, and will
> require some refactoring (or an alternative block for versionless source
> downloading) to handle this.  It will also need some logic adding to find the
> correct .dsc after the download is done; since we download into a temporary
> directory, only one ${package}*.dsc should match that glob; also need to
> check how multiple source versions are handled.
> 
> Not quite as simple as I initially thought, but it's pretty much contained
> within fetch_source_files.  So long as we reset $dsc and 'DSC File', that
> should be sufficient.

Turned out to be even harder than you initially thought because the version is
also required for log filtering (PKGBUILDDIR and BUILDDIR), for all kinds of
log status printing, for external command percentage escapes %d and %p, for
opening the build log at package_ver.build, making the build log symlink and
some more status printing...

Though I think I managed to implement it now. It is now in the sbuild git. Here
the commit message for details of how it was done:

Allow to build by only passing source package name without version (closes: 
#693928)

The packagename_version format was a handy way to fulfill the assumption
sbuild makes that the source package version is available right from the
start. Sbuild then uses the version for things like log filtering,
status output, external command percentage escapes or the build log file
name.

This patch makes it optional that the version is known from the start.
In case it is not known it will:

 - not print version information in the build log
 - not let external command percentage escapes be defined
 - use only the package name for the build log filename
 - set up log filtering much later when the version is definitely known

To not break existing setups, all the old behavior is kept if the
version is known from the start. To distinguish the version being known
from not being known, the user-supplied argument is checked for the
presence of an underscore. If an underscore exists, then either a dsc is
passed or the pkgname_version format was used and in both cases, the old
behavior can be executed. If no underscore can be found, then it is a
bare package name and the different behavior explained above will kick
in.

The man page has been adapted to document the new behavior.

While I was at it, I also rewrote the code downloading the source
package:

 - The old code triggered an "apt-get update" if the source package
   could not be found. This is not necessary because the source package
   is fetched after the chroot is updated. Furthermore it allows to
   "apt-get update" to be run without eventual failures be caught by the
   respective external command hooks. Lastly, this would ignore the
   --no-apt-update command line option.

 - "apt-cache showsrc" was run without --only-source

 - The "apt-cache showsrc" output was parsed using Perl regexes.
   Dpkg::Index is used now.

 - The Files field is now parsed using Dpkg::Checksums instead of using
   perl regexes.

 - the @fetched array was only filled but never used by anybody


Thanks!

cheers, josch


signature.asc
Description: signature

Bug#812672: mkdocs locale error building djangorestframework

[Vincent Bernat]

 ❦ 26 janvier 2016 11:57 +1100, Brian May  :

> I probably should change the line from:
>
> LANG=C.UTF-8 mkdocs build && mv site docs.debian/html
>
> To something like:
>
> LANG=C.UTF-8 LC_CTYPE= LC_ALL= mkdocs build && mv site docs.debian/html


This may not apply to your case, but there is a localehelper package for
this kind of situations.
-- 
Make input easy to prepare and output self-explanatory.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#812722: Boot-time scan should be quiet when "quiet" kernel parameter is used

[Ben Hutchings]

Package: btrfs-tools
Version: 4.3-1
Severity: normal
Tags: patch

Currently btrfs's boot script that runs in the initramfs always prints
messages, even if there are no btrfs filesystems present and no
errors.  This should not happen when the "quiet" kernel parameter is
used.  Please apply the attached patch.

Ben.

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 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 btrfs-tools depends on:
ii  e2fslibs1.42.13-1
ii  libblkid1   2.27.1-1
ii  libc6   2.21-6
ii  libcomerr2  1.42.13-1
ii  liblzo2-2   2.08-1.2
ii  libuuid12.27.1-1
ii  zlib1g  1:1.2.8.dfsg-2+b1

btrfs-tools recommends no packages.

btrfs-tools suggests no packages.

-- no debconf information
>From 2bc737c624c8307af7a9084b9e87ae2a3f912358 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Tue, 26 Jan 2016 03:51:30 +
Subject: [PATCH] Show only errors from boot-time "btrfs scan" if "quiet" is
 used

When the "quiet" kernel parameter is used, redirect stdout in the
initramfs boot script to /dev/null.  Stop redirecting stderr, as
any errors should still be shown.
---
 debian/local/btrfs.local-premount | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/local/btrfs.local-premount b/debian/local/btrfs.local-premount
index 7f7bf27..aea7128 100644
--- a/debian/local/btrfs.local-premount
+++ b/debian/local/btrfs.local-premount
@@ -19,5 +19,7 @@ esac
 if [ -x /bin/btrfs ]
 then
 	modprobe btrfs
-	/bin/btrfs device scan 2> /dev/null
+	# If asked to be quiet, show only errors
+	[ "${quiet}" = "y" ] && exec >/dev/null
+	/bin/btrfs device scan
 fi

Bug#812721: gbp could filter out Files-Excluded: entries when committing to the pristine-tar branch

[Sean Whitton]

Package: git-buildpackage
Version: 0.7.1
Severity: wishlist

Dear Maintainer,

When uscan is used to generate an upstream tarball, it filters out files
listed in the Files-Excluded: section of the debian/copyright file and
appends +dfsg to the tarball's version.  This can then be imported to
the packaging repository with gbp import-orig.

Nowadays, many upstreams do not ship tarballs.  When preparing the
Debian packaging for such a project, it is convenient to simply clone
upstream's git repository and add a branch to that for Debian
packaging.

Suppose that upstream tags a release 1.2.3 in the git repository.  The
Debian package maintainer must then manually delete the files listed in
Files-Excluded: and then tag a new version 1.2.3+dfsg.  gbp can then
create a tarball of this tag and commit it to the pristine-tar branch.

It would be great if gbp could produce the 1.2.3+dfsg tag itself by
reading debian/copyright and excluding the Files-Excluded: files.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#788005: libfreerdp-plugins-standard: urbdrc-client.so missing (USB redirection)

[Alex 'AdUser' Z]

Package: freerdp
Followup-For: Bug #788005

You may also want another patch, that fixes linkage urbdrc-client-libusb.so 
against udev.

If you see message like this right after login:

> undefined symbol 'udev_new'

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- a/channels/urbdrc/client/libusb/CMakeLists.txt	2016-01-26 15:25:32.979436442 +1000
+++ b/channels/urbdrc/client/libusb/CMakeLists.txt	2016-01-26 15:25:45.767436886 +1000
@@ -39,6 +39,7 @@
 set(${MODULE_PREFIX}_LIBS ${${MODULE_PREFIX}_LIBS}
 ${DBUS_GLIB_LIBRARIES}
 ${UUID_LIBRARIES}
+${UDEV_LIBRARIES}
 ${LIBUSB_1_LIBRARIES}
 )
 

Bug#810206: swfmill: Please update dependency on libpng-dev

[Tobias Frost]

Control: retitle -1 Please drop B-D on libpng12-dev
Control: severity normal
Contrpl: usertag -1 =


Yes, that will not block the transition.
However, it should still be removed as libpng12-dev will be retired.
(libpng-dev is also bpo save already)

--
tobi 

On Fri, 22 Jan 2016 11:59:48 +0100 Gianfranco Costamagna  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi, the package already have libpng-dev | libpng12-dev, so I don't
> think there is an issue right now.
> 
> cheers,
> 
> Gianfranco
> 
> On Thu, 07 Jan 2016 10:19:28 +0100 t...@debian.org wrote:
> > Package: swfmill Severity: important User:
> > lib...@packages.debian.org Usertags: libpng16-transition
> > 
> > Dear swfmill maintainers,
> > 
> > Currently we are preparing the transition of libpng1.2 to
> > libpng1.6. The transition bug is #650601.
> > 
> > A rebuild of all packages depending on libpng-dev and 
> > libpng(3,12,12-0)-dev has been done. The result with buildlogs can
> > be found here: https://libpng.sviech.de/
> > 
> > swfmill builds fine with libpng16, you can see the buildlog here: 
> > https://libpng.sviech.de/swfmill.build
> > 
> > Howver, swfmill (build-)depends an versioned development package 
> > libpng12-dev. Please update your (build-)depends to libpng-dev to 
> > help in the transition.
> > 
> > This bug will become RC as soon as the transition starts, as it is 
> > planned to remove libpng12.
> > 
> > Thanks! -- tobi
> > 
> > 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQIcBAEBCAAGBQJWogukAAoJEPNPCXROn13ZUVUP+wcusoIsLUJ0Z97UbTeHoEcJ
> kvRRXc/THdYiv4qsCdyjEdi56V5LD1WsvxYjfjUr9HfFzJi1/zGoG99FBFiyQUIg
> WDuVeu1Az5zetHz1ZXy+bUrw2Y0+RwOJKgEGbpFHSNQlBlXSBBIe9iWQmsb/O3wf
> +o+knJpWxcZz41AnqmcKkzgApABoVwT47h4cN9xNTPuGYsr/hIg8glin2sPKyVE2
> pkHYkzMqoa7J6cIGFEBhGo/YslXMc4PZuo69tVjBjRXOv6QTzWc5c/JUyZAmz4pB
> YfIVW0zTVNcnmFKjvCCi05xV9AbL8/FXULkaSvopfDirpVdmsQjlwEz+NWDA9wtD
> nJiWhc7UMA2AZLPxfQZkWEAlX2sTpOKbxLjaMirQpYTmBS+08aI+RK4EKs2Y+G7o
> RkK95KBtE5ztk60D/bXwJ5zf+m6KH8hJ1C5Dp1tZSdNulEVwFSNUaaqw2FjBuOdW
> YgzJaoWZU813Y2cJUzJ7g9d8mipr6XQqLi7lyeW+aw8xh8+ZSTdSBrMwJCHVq+qb
> YWwTyesfyxC+JVsKhy2JwD7KZfLdzaPUzaODRU6qng9ZJbdQ/WvhAIrgCrTRnqhh
> zraSbpt5LQ4WDdQ+dPwOODyWwsLKJxTgOSk6aSWOooaBrQOjhrT7YeHZg7tu1biM
> LmOmZSUe6V9XNJ8OAbYV
> =CHiG
> -END PGP SIGNATURE-
> 
> 

Bug#812726: [PATCH] Fix autopkgtest

[Martin Pitt]

Package: numexpr
Version: 2.4.3-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch xenial

Hello,

numexpr's autopkgtest fails [1] because the test tries to import
pkg_resources which is missing.

Trivial patch attached (which I uploaded to Ubuntu), I tested that
this makes all four tests pass.

Thanks for considering,

Martin

[1] https://ci.debian.net/packages/n/numexpr/unstable/amd64/
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Nru numexpr-2.4.3/debian/changelog numexpr-2.4.3/debian/changelog
--- numexpr-2.4.3/debian/changelog  2016-01-19 01:41:52.0 +0100
+++ numexpr-2.4.3/debian/changelog  2016-01-26 07:55:34.0 +0100
@@ -1,3 +1,9 @@
+numexpr (2.4.3-1ubuntu1) xenial; urgency=medium
+
+  * Add missing python[3]-pkg-resources test dependency.
+
+ -- Martin Pitt   Tue, 26 Jan 2016 07:55:19 +0100
+
 numexpr (2.4.3-1build1) xenial; urgency=medium
 
   * No-change rebuild to drop python3.4 support.
diff -Nru numexpr-2.4.3/debian/tests/control numexpr-2.4.3/debian/tests/control
--- numexpr-2.4.3/debian/tests/control  2015-08-16 13:32:00.0 +0200
+++ numexpr-2.4.3/debian/tests/control  2016-01-26 07:55:16.0 +0100
@@ -1,12 +1,12 @@
 Tests: python2
-Depends: python-numexpr, python-all
+Depends: python-numexpr, python-all, python-pkg-resources
 
 Tests: python2-dbg
-Depends: python-numexpr-dbg, python-all-dbg
+Depends: python-numexpr-dbg, python-all-dbg, python-pkg-resources
 
 Tests: python3
-Depends: python3-numexpr, python3-all
+Depends: python3-numexpr, python3-all, python3-pkg-resources
 
 Tests: python3-dbg
-Depends: python3-numexpr-dbg, python3-all-dbg
+Depends: python3-numexpr-dbg, python3-all-dbg, python3-pkg-resources
 

Bug#812725: make-dfsg has unsatisfiable cross build dependendencies in a bootstrap setting: libbsd-resource-perl

[Helmut Grohne]

Source: make-dfsg
Version: 4.1-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Manoj,

In your 4.1-5 upload, you added libbsd-resource-perl to Build-Depends.
Unfortunately, this package is not available during architecture
bootstrap for the host architecture when we need to build make-dfsg.
Looking closer one can see that libbsd-resource-perl is only used for
running tests. During cross building we generally inhibit running tests
via DEB_BUILD_OPTIONS=nocheck. This works well for make-dfsg as well
(thanks). So we actually do not need the libbsd-resource-perl dependency
there. I therefore suggest annotating it with the  profile and
attach a patch for your convenience.

Helmut
diff -u make-dfsg-4.1/debian/changelog make-dfsg-4.1/debian/changelog
--- make-dfsg-4.1/debian/changelog
+++ make-dfsg-4.1/debian/changelog
@@ -1,3 +1,11 @@
+make-dfsg (4.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Satsifiable cross build dependencies: libbsd-resource-perl is only needed
+for running tests (Closes: #-1).
+
+ -- Helmut Grohne   Tue, 26 Jan 2016 06:40:09 +0100
+
 make-dfsg (4.1-5) unstable; urgency=low
 
   * While increasing the timeout is a solution, it still did not work for
diff -u make-dfsg-4.1/debian/control make-dfsg-4.1/debian/control
--- make-dfsg-4.1/debian/control
+++ make-dfsg-4.1/debian/control
@@ -8,7 +8,7 @@
 Homepage: http://www.gnu.org/software/make/
 Build-Depends: gettext, po-debconf, debhelper (>= 9.0.0), dh-autoreconf,
autoconf, automake | automaken, autopoint, file, pkg-config,
-   guile-2.0-dev, procps, libbsd-resource-perl
+   guile-2.0-dev, procps, libbsd-resource-perl 
 
 Package: make
 Suggests: make-doc

Bug#662523: tracker: Please Build-Depends on libpng-dev, change from libpng12-dev

[Tobias Frost]

On Thu, 21 Jan 2016 17:58:47 +0100 Michael Biebl 
wrote:
> Hi Gianfranco
> 
> Am 21.01.2016 um 16:12 schrieb Gianfranco Costamagna:
> > 
> >> If you want to make a team-upload for this change, would be ok
with
> >> me as well.
> > 
> > I did the changes on collab-maint, and uploaded on delayed/7
> 
> Since I already acked the change, feel free to upload directly
without
> delay (you probably have to dcut the existing upload to DELAYED
first)
> 

Thanks for the head-up... 
Rescheduled to 0-day queue.

tobi@edoras:~$ dcut reschedule -d 0 -f tracker_1.6.1-2_amd64.changes
Uploading commands file to ftp.upload.debian.org (incoming: /pub/Upload
Queue/)

--
tobi

Bug#811464: vmdebootstrap: fails to download packages

[Matt Taggart]

I encounter the same error again and figured out what the problem was!

In my original problem report I specified "--size=1". Well that 
value is in _bytes_ so that is only 100M. So the image was filling up due 
to the kernel(large) and zlib(last alphabetically).

I filed a separate bug suggesting better documentation of the size option 
(#812727).

It would have been nice if vmdebootstrap detected this problem and gave a 
more specific error. If it's too complicated to detect the image full 
issue, a sanity check on reasonable values of SIZE would have caught it too.

Will change to wishlist.

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#812695: pygame-sdl2: FTBFS: format not a string literal and no format arguments

[Aaron M. Ucko]

Markus Koschany  writes:

> Thanks for the report. I believe this is some sort of regression in SDL2
> 2.0.4. Four days ago pygame-sdl2 built fine with SDL2 2.0.2.
> pygame_sdl2.error.c is auto-generated at build-time and the error
> message,(__pyx_t_3) is controlled by SDL_GetError(), so there is not
> much I can do here. I will disable this specific -format hardening check
> for now and re-enable it as soon as this issue is resolved in
> src:libsdl2 and related packages.

Ah, yes, I see that SDL_SetError hadn't previously been annotated as
printf-like.  It would be best if whatever generated pygame_sdl2.error.c
(cython?) respected this annotation itself.

At any rate, thanks for the quick response and workaround!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#812325: amavisd-new fails recognizing viruses on non-English systems if the AV scanner writes localized messages to stdout

[Mike Gabriel]

Hi Brian,

thanks for reacting on this so promptly.

On  Mo 25 Jan 2016 23:28:13 CET, Brian May wrote:


Mike Gabriel  writes:


Please consider applying this change (launch amavisd with LANG=C) to
amavisd-new in Debian testing/stretch and also possibly via
security.debian.org in older releases of Debian. (Feedback from the
security team is appreciated on this).


Out of the three init.d scripts, which one need this change?

/etc/init.d/amavis-mc
/etc/init.d/amavisd-snmp-subagent
/etc/init.d/amavis

Once I have a working tested patch, I will contact the release team
about a stable update. However first I need to be sure I understand
which files I should be updating.

...If I had to guess, I would say amavis-mc and amavis but not
amavisd-snmp-subagent.


At the site where the issue was discovered, I only use  
/etc/init.d/amavis. But from reading the docs of amavis-mc, that init  
script may also be affected. As amavisd-snmp-subagent does not launch  
AV scanner child processes, I'd say nothing is needed there.


Thus, I agree with your guess.

Greets,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/mailxchange/kronolith/fb.php?u=m.gabriel%40das-netzwerkteam.de


pgp1vcBLYtK_4.pgp
Description: Digitale PGP-Signatur

Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub

[Rick Thomas]

On Jan 25, 2016, at 8:07 AM, Kilian Krause  wrote:

> Package: u-boot
> Severity: wishlist
> Tags: d-i
> 
> Hi Vagrant,
> 
> as just discussed the d-i mimic of installing u-boot should also be
> available when updating u-boot packages in an installed system.
> 
> There may be cases, where automatic updates may not be desired or where
> defaults are just simply not matching, so there should probably be a
> /etc/defaults/u-boot with:
> - an option to ENABLE/DISABLE
> - dd parameters like offset
> - the u-boot flavor and image file (if one would want to override it)
> 
> When enabled the u-boot postinst should ensure the latest code is
> auto-activated just like at the end of d-i when installing the system.
> 
> Since duplicating d-i code is not what we want, this probably means also
> creating a udeb with the u-boot-tools (and especially this "installer")
> and moving the relevant installer heuristic over to u-boot and replacing
> it in d-i with a matching structure to call this new tool.
> 
> Best,
> Kilian

With all due respect...

Please don't do this!

Installing u-boot is not at all like installing grub.

If something goes wrong with installing grub, you can boot from a CD or via 
ethernet and recover or re-install.
If something goes wrong with installing u-boot, you have bricked your device.  
The only recourse is J-tag.  Not fun at all!

Installing u-boot is something that should only be undertaken very carefully if 
you know what you're doing and are prepared to recover from a mishap.  Doing it 
automatically every time there's an update is not wise.

Thanks for including me in the discussion!

Rick

Bug#812325: amavisd-new fails recognizing viruses on non-English systems if the AV scanner writes localized messages to stdout

[Brian May]

Mike Gabriel  writes:

> thanks for reacting on this so promptly.

I have been told just today that setting LC_ALL overrides LC_CTYPE and
LANG, so just setting LC_ALL should be sufficient.

Can you please test the following change to the init.d script and let me
know if it works for you?


diff --git a/debian/amavisd-new.amavis-mc.init 
b/debian/amavisd-new.amavis-mc.init
index 8de156e..eb7fb17 100644
--- a/debian/amavisd-new.amavis-mc.init
+++ b/debian/amavisd-new.amavis-mc.init
@@ -62,6 +62,7 @@ do_start()
rm -f $PIDFILE
fi
fi
+   export LC_ALL; LC_ALL=C
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
diff --git a/debian/amavisd-new.amavis.init b/debian/amavisd-new.amavis.init
index f36ed0b..7890ce7 100644
--- a/debian/amavisd-new.amavis.init
+++ b/debian/amavisd-new.amavis.init
@@ -90,6 +90,7 @@ case "$1" in
echo -n "Starting $DESC: "
fixdirs
check_noncompatible_upgrade
+   export LC_ALL; LC_ALL=C
if start-stop-daemon ${START} -- ${PARAMS} start >/dev/null ; then
echo "amavisd-new."
else

-- 
Brian May 

Bug#812685: mapserver: conflicting types of variable msyystring_icase

[Sebastiaan Couwenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 pending

Hi Michael,

On 25-01-16 22:14, Michael Tautschnig wrote:
> During a rebuild of all Debian packages in a clean sid chroot
> (using cowbuilder and pbuilder) the build failed with the following
> error. Please note that we use our research compiler tool-chain
> (using tools from the cbmc package), which permits extended
> reporting on type inconsistencies at link time.
> 
> mapfile.c line 65: error: conflicting types for variable
> `msyystring_icase' old definition in module `maplexer' file
> maplexer.l line 51 signed int new definition in module `mapfile'
> file mapfile.c line 65 char
> 
> Depending on endianness of the platform, the lexer may use the
> wrong byte of msyystring_icase. The attached patch fixes this
> problem.

Thanks for the patch, I've included it in the mapserver package and
forwarded it upstream: https://github.com/mapserver/mapserver/pull/5227

A new upload to unstable is being prepared.

Kind Regards,

Bas

- -- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJWpxQnAAoJEGdQ8QrojUrxJtQQAK1wBG0iu6RBpNRO3/0T4WSd
Y5wdOh4Z7tcUNe4wmZA/g0wShxPfXcIRYH8yyr9xF5qvR9OeoBf2ovzgmfSuEA5q
tX1p9MNsCFj3BNv3eDzv/RvYqZ5s0c0w7BfwnMn41wFuw7mxg82/pY+FcvwLoQ7O
M9m6GWtJnLMsG8T+tevt/p8VaB/HjU2in4njm7PuOAtaMtUyx8g77ub8JAIC2xyr
iw0orT/qgXz14YAnXuJo/3i45f6pGiscDOvObFOQzjIeG8cjOy9nNwF2pGOm96pL
mTNx62IBg8AbS+uEy3jUUqdrEHr0hojJDkNbNy6Zo3snqsEr8aH0f8BAxMpKHXQp
u2qqNmyFDB2jvlQOJloc/eQX4k2+tsJCIPxFfXnrahJGdX3YaiQtU10+ew0CffIB
VUxf8any7C+COtJb6DFyVl+7hS5o9agExXnqGw8K45Vo/zrQPrD/sbTlX3vcmUeu
kir0/VdvUYbxR6u9+kqJa5UzVR+nb9vRYprE+2yEZlNsr/WBw16nbF39EjllQWt4
WHj7ZP5DsnfOLG1q07Hw145rAZkDPecXKpWL8jHA++GjNbTNAzSlefqxobsKkR8H
uLWTw9CKsEeqp72WKyYQ0YdpLGtTDIxvbV9mVlK7aQPtj03hPj8yp/gVCzAE9ICs
ObN0fLoyS7O9bcVdz6gf
=OxXS
-END PGP SIGNATURE-

Bug#765639: Bug#802159: New OpenSSL upstream version

[Adam D. Barratt]

On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote:
> However 1.0.1q hasn't been in stable at all, which is presumably what
> you'd be proposing introducing to oldstable at this juncture. (and which
> we'd therefore need to introduce to stable first, if we were to agree to
> follow that path.)

Picking this up again (I hadn't realised the above was so many weeks
ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k
really needs a newer upstream version to be in Jessie first. We also
likely only have two opportunities to get a package in to "Wheezy
proper" before it moves to LTS status - likely a point release in March
and then a "mop up" after the EOL of the base suite.

> Admittedly, the description of the changes between 1.0.1k and 1.0.1q,
> according to NEWS/CHANGES don't immediately look crazy.

Comparing those against the package changelog and Security Tracker and
ignoring changes which are apparently only relevant if SSLv2 is enabled
leaves us with:

  *) dhparam: generate 2048-bit parameters by default.
 [Kurt Roeckx and Emilia Kasper]

  *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs.
 This changes the decoding behaviour for some invalid messages,
 though the change is mostly in the more lenient direction, and
 legacy behaviour is preserved as much as possible.
 [Emilia Käsper]

  *) In DSA_generate_parameters_ex, if the provided seed is too short,
 return an error
 [Rich Salz and Ismo Puustinen ]

  *) Build fixes for the Windows and OpenVMS platforms
 [Matt Caswell and Richard Levitte]

The last of those is obviously irrelevant. Have there been any reports
of issues related to the other fixes listed?

Regards,

Adam

Bug#812721: gbp could filter out Files-Excluded: entries when committing to the pristine-tar branch

[Guido Günther]

Hi,
On Mon, Jan 25, 2016 at 09:02:50PM -0700, Sean Whitton wrote:
> Package: git-buildpackage
> Version: 0.7.1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> When uscan is used to generate an upstream tarball, it filters out files
> listed in the Files-Excluded: section of the debian/copyright file and
> appends +dfsg to the tarball's version.  This can then be imported to
> the packaging repository with gbp import-orig.
> 
> Nowadays, many upstreams do not ship tarballs.  When preparing the
> Debian packaging for such a project, it is convenient to simply clone
> upstream's git repository and add a branch to that for Debian
> packaging.
> 
> Suppose that upstream tags a release 1.2.3 in the git repository.  The
> Debian package maintainer must then manually delete the files listed in
> Files-Excluded: and then tag a new version 1.2.3+dfsg.  gbp can then
> create a tarball of this tag and commit it to the pristine-tar branch.

I would rather do this with a dfsg-clean branch. You delete once and
then use git tools from there on.

> It would be great if gbp could produce the 1.2.3+dfsg tag itself by
> reading debian/copyright and excluding the Files-Excluded: files.

If somebody comes up with a clean patch I'm happy to merge that.

Cheers,
 -- Guido

Bug#812577: gummi: Gummi fails to locate pictures after ugrade to 0.6.5-3+deb8u1

[Daniel Stender]

Control: tags + confirmed

Yes, that's right. Please excuse that mistake.

I'm in contact with upstream and he's going to release a new upstream tarball
including a fix for CVE 2015-7758 which doesn't has that side effect in the next
days. I'm going to package it immediately and provide an update for Jessie, as
soon as it's possible.

DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#812605: RM: ruby-distribution/0.7.3+dfsg-1

[Christian Hofstaedtler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Hi,

ruby-distribution Build-Depends on ruby-gsl, which is not in testing.
(Also nobody seems to be working on fixing ruby-gsl for it to reenter
testing.)

Thanks,
Christian

Bug#812573: nmu: libaec_0.3.2-1

[Gilles Filippini]

On Mon, 25 Jan 2016 09:27:14 +0100 Gilles Filippini  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> Hi,
> 
> Despite successful buildlog [0], libaec binary packages are missing
> for arch x32. Please rebuild them.
> 
> [0] 
> https://buildd.debian.org/status/fetch.php?pkg=libaec=x32=0.3.2-1=1448449417
> 
> nmu libaec_0.3.2-1 . x32 . unstable . -m "rebuild for x32 because missing in 
> archive"

This is the case for archs ppc64 and sparc64 as well. Then this binnmu request 
becomes:

nmu libaec_0.3.2-1 . ppc64 sparc64 x32 . unstable . -m "rebuild for x32, ppc64, 
and sparc64 because missing in archive"

Thanks,
_g.

> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#812592: Requires systemd on Jessie for no particular reason

[Roman Mamedov]

Package: k3b
Version: 2.0.2-8

Hello,

I find that on Jessie the k3b package requires running a systemd-based OS.

  k3b depends on: udisks2
  udisks2 depends on: libpam-systemd
  libpam-systemd depends on: systemd

This is even more baffling when you consider that the Jessie version of k3b is
2.0.2-8, whereas the Wheezy version is 2.0.2-6. So there are probably no
actual systemd-using changes in the program to mandate its requirement.

Running non-systemd init systems such as 'sysvinit' and 'upstart' is also
a supported configuration in Debian Jessie. But their users can't currently
install k3b without breaking their systems.

Can you please reconsider to update the dependencies so that systemd is not
required to use k3b.

Thanks!

-- 
With respect,
Roman


signature.asc
Description: PGP signature

Bug#808140: [Pkg-privacy-maintainers] Bug#808140: Bug#808140: Bug#808140: torbrowser-launcher: AppArmor profile blocks browser self-upgrade

[Holger Levsen]

Hi intrigeri,

On Samstag, 16. Januar 2016, intrigeri wrote:
> > …however I'd be glad if you could just share the file as you are using
> > now…
> Sure:

sadly this doesn't apply - could you please just attach your file so I can 
create the needed patch myself? (I really don't want to manually edit the 
file, too errorprone…)

~/Projects/torbrowser-launcher/torbrowser-launcher$ git status
# On branch debian/sid
# Your branch is up-to-date with 'origin/debian/sid'.
#
nothing to commit, working directory clean
~/Projects/torbrowser-launcher/torbrowser-launcher$ git describe 
debian/0.2.2-2-3-g32f3f43
~/Projects/torbrowser-launcher/torbrowser-launcher$ quilt pop -a
No patch removed
~/Projects/torbrowser-launcher/torbrowser-launcher$ patch -p0 --dry-run < 
../808140.patch 
patching file apparmor/torbrowser.Browser.firefox
Hunk #1 FAILED at 36.
1 out of 2 hunks FAILED -- saving rejects to file 
apparmor/torbrowser.Browser.firefox.rej
~/Projects/torbrowser-launcher/torbrowser-launcher$ quilt push -a
Applying patch Include-local-overrides-file-in-AppArmor-profiles.-C.patch
patching file apparmor/torbrowser.Browser.firefox
patching file apparmor/torbrowser.Tor.tor
patching file apparmor/usr.bin.torbrowser-launcher

Applying patch Set-torbrowser.start-tor-browser-and-usr.bin.torbrow.patch
patching file apparmor/usr.bin.torbrowser-launcher

Now at patch Set-torbrowser.start-tor-browser-and-usr.bin.torbrow.patch
~/Projects/torbrowser-launcher/torbrowser-launcher$ patch -p0 --dry-run < 
../808140.patch 
patching file apparmor/torbrowser.Browser.firefox
Hunk #1 FAILED at 36.
Hunk #2 FAILED at 80.
2 out of 2 hunks FAILED -- saving rejects to file 
apparmor/torbrowser.Browser.firefox.rej
~/Projects/torbrowser-launcher/torbrowser-launcher$


cheers,
Holger


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

Bug#812595: ibgl1-nvidia-glx: can't install package

[Mattia Rizzolo]

control: reassign -1 libgl1-nvidia-glx 352.63-2
control: severity -1 serious


On Mon, Jan 25, 2016 at 01:53:41PM +0100, Thierry Florac wrote:
> Package: ibgl1-nvidia-glx

missing l on the package name.

> Version: 352.63-2
> Severity: critical
> Justification: breaks the whole system

it doesn't, it's not critical.  it's just a package failing to install
(still RC, though).

> Dear Maintainer,
> 
> Can't update package "libgl1-nvidia-glx" (release 352.63-2) because of an
> unpack error:
> 
> Preparing to unpack .../libgl1-nvidia-glx_352.63-2_amd64.deb ...
> dpkg: error processing archive /var/cache/apt/archives/libgl1-nvidia-
> glx_352.63-2_amd64.deb (--unpack):
>  subprocess new pre-installation script returned error exit status 128
> Processing triggers for libc-bin (2.21-7) ...
> Errors were encountered while processing:
>  /var/cache/apt/archives/libgl1-nvidia-glx_352.63-2_amd64.deb

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#812586: init-system-helpers: rebuilding the package with binary/clean/binary fails

[Michael Prokop]

* Martin Pitt [Mon Jan 25, 2016 at 12:54:46PM +0100]:
> Michael Prokop [2016-01-25 12:04 +0100]:

> > +override_dh_auto_clean:
> > +   dh_auto_clean
> > +   rm -f script/*.1p
> > +

> Thanks for the patch!

> However, the dh_auto_clean manpage suggests to not overwrite it.
> Should we rather let dh_clean take care of this

You're referring to:

| If it doesn't work, or tries to use the wrong clean target, you're
| encouraged to skip using dh_auto_clean at all, and just run make
| clean manually.

? If so, interesting, I didn't understand it that way. :)

> and add "script/*1.p" to debian/clean?

Ah sure, that would work too. :)

Choose whatever you prefer, I just noticed the behaviour while
working with the i-s-h package trying to fix #812337. :)

Thanks!

regards,
-mika-


signature.asc
Description: Digital signature

Bug#812600: ITP: designate-dashboard -- OpenStack DNS as a Service - dashboard plugin

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: designate-dashboard
  Version : 2.0.0~b2
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/designate-dashboard
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack DNS as a Service - dashboard plugin

 Designate provides DNSaaS services for OpenStack. It provides a multi-tenant
 REST API for domain & record management. It is Integrated with Keystone for
 authentication, and provides a framework in place to integrate with Nova and
 Neutron notifications (for auto-generated records). Designate supports
 PowerDNS and Bind9 out of the box.
 .
 This package contains the OpenStack dashboard plugin.

Bug#812595: ibgl1-nvidia-glx: can't install package

[Andreas Beckmann]

Control: tag -1 unreproducible
Control: forcemerge -1 812594

On Mon, 25 Jan 2016 13:53:41 +0100 Thierry Florac  wrote:
> Can't update package "libgl1-nvidia-glx" (release 352.63-2) because of an
> unpack error:

It worked fine in my tests (and in my piuparts).

Upgrading from which version?

What GPU do you have? (lspci -nn | grep 0300)

What CPU do you have?


Andreas

PS: you filed 2 bug reports, but they seem to describe the same problem,
therefore I merged them

Bug#812594: libgl1-nvidia-glx: can't install or upgrade package

[Thierry Florac]

Package: libgl1-nvidia-glx
Version: 352.63-2
Severity: normal

Dear Maintainer,

Can't update package "libgl1-nvidia-glx" (release 352.63-2) because of an
unpack error:

Preparing to unpack .../libgl1-nvidia-glx_352.63-2_amd64.deb ...
dpkg: error processing archive /var/cache/apt/archives/libgl1-nvidia-
glx_352.63-2_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 128
Processing triggers for libc-bin (2.21-7) ...
Errors were encountered while processing:
 /var/cache/apt/archives/libgl1-nvidia-glx_352.63-2_amd64.deb



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

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

Bug#702134: Processed: retitle 702134 to ITP: koha -- Koha Integrated Library System, owner 702134

[Dmitry Smirnov]

On Mon, 25 Jan 2016 01:09:04 PM Debian Bug Tracking System wrote:
> > retitle 702134 ITP: koha -- Koha Integrated Library System

It is really awesome that you are working on Koha, Jonas.

I wish I had time to give you a hand but likely I won't be able to do so 
anytime soon. I only want to aks you to consider using DH packaging layout 
instead of CDBS to make co-maintenance easier. Thank you.

-- 
Best wishes,
 Dmitry Smirnov.

---

Truth — Something somehow discreditable to someone.
-- H. L. Mencken, 1949


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

Bug#812597: libxi6: locale command in konsole comes up empty, utf-8 text problems after upgrade

[Arthur Marsh]

Package: libxi6
Followup-For: Bug #812597

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

After repeated upgrades and downgrades of libxi6, konsole came good on
the current version of libxi6:

$ locale
LANG=en_AU.UTF-8
LANGUAGE=en_GB
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=

$ dpkg -l|grep libxi6
ii  libxi6:amd64   2:1.7.6-1amd64X11 Input extension library

I'm mystified as to the cause.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.5.0-rc1 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libxi6 depends on:
ii  libc6 2.21-7
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1

libxi6 recommends no packages.

libxi6 suggests no packages.

-- debconf-show failed

Bug#812607: autopkg test failing

[Matthias Klose]

Package: src:ruby-redcarpet
Version: 3.3.3-2
Severity: important
Tags: patch

test dependency is missing, patch at
http://launchpadlibrarian.net/235168083/ruby-redcarpet_3.3.3-2build1_3.3.3-2ubuntu1.diff.gz

Bug#812591: liquidsoap: segfaults immediately

[Andrew Yong]

So I’d like to add,

I built liquidsoap-1.2.0-full.tar.bz2 from their Github tagged release
(compiled on the armhf/armmp box itself) and it works fine.

Was able to playback files.

On Mon, Jan 25, 2016 at 8:32 PM, Andrew Yong  wrote:

> Package: liquidsoap
> Version: 1.1.1-7.1
> Severity: important
>
> Dear Maintainer,
>
> I am running liquidsoap 1.1.1-7.1 on Debian Unstable 4.3.0-1-armmp. It
> immediately segfaults, even with --help switch only.
>
> I am now compiling from the Git trunk (
> https://github.com/savonet/liquidsoap-full.git) with instructions on
> http://liquidsoap.fm/download.html and will see if this resolves the
> segfault, that should help.
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: armhf (armv7l)
>
> Kernel: Linux 4.3.0-1-armmp (SMP w/4 CPU cores)
> Locale: LANG=en_SG.UTF-8, LC_CTYPE=en_SG.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages liquidsoap depends on:
> ii  adduser 3.113+nmu3
> ii  libc6   2.21-7
> ii  libcamomile-ocaml-data  0.8.4-4
> ii  libmagic1   1:5.25-2
> ii  libpcre32:8.38-1
> ii  perl5.22.1-4
> ii  sox 14.4.1-5
> ii  wget1.17.1-1+b1
>
> Versions of packages liquidsoap recommends:
> ii  liquidsoap-plugin-faad1.1.1-7.1
> ii  liquidsoap-plugin-flac1.1.1-7.1
> ii  liquidsoap-plugin-icecast 1.1.1-7.1
> ii  liquidsoap-plugin-lame1.1.1-7.1
> ii  liquidsoap-plugin-mad 1.1.1-7.1
> ii  liquidsoap-plugin-pulseaudio  1.1.1-7.1
> ii  liquidsoap-plugin-taglib  1.1.1-7.1
> ii  liquidsoap-plugin-voaacenc1.1.1-7.1
> ii  liquidsoap-plugin-vorbis  1.1.1-7.1
> ii  logrotate 3.8.7-2
> ii  mp3gain   1.5.2-r2-2+deb7u1
> ii  vorbis-tools  1.4.0-7
> ii  vorbisgain0.37-2
>
> Versions of packages liquidsoap suggests:
> pn  festival   
> ii  icecast2   2.4.2-1
> pn  liguidsoap 
> pn  liquidsoap-plugin-samplerate   
> pn  liquidsoap-plugin-xmlplaylist  
> pn  mplayer
>
> -- no debconf information
>

Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs

[Ben Hutchings]

On Thu, 12 Nov 2015 09:49:33 + Ian Campbell  wrote:
> On Wed, 2015-11-11 at 18:46 -0600, Vagrant Cascadian wrote:
[...]
> > Would definitely like to see this, with a recent install on a Wandboard
> > Dual with a USB2 sata disk for the rootfs. It installed fine with
> > jessie's debian-installer, but failed on initial boot.
> > 
> > I worked around it by adding to /etc/initramfs-tools/modules:
> > 
> >   ci_hdrc_imx
> >   phy_mxs_usb
> > 
> > I haven't yet verified if only adding "phy_mxs_usb" instead of both will
> > work.
> > 
> > Had a similar problem with an Odroid-XU4 install (which isn't yet
> > supported by debian-installer), and worked around it similarly, although
> > haven't narrowed down exactly which modules are needed, though I
> > suspect one or both of:
> > 
> >   phy_exynos_usb2
> >   phy_exynos5_usbdrd
> > 
> > 
> > Something that pulls in all the phy-* modules would likely fix the issue
> > in a generic way, rather than playing whack-a-mole with various phy
> > types.
> 
> I think Ben essentially did this in #762042[0], which ends up adding any
> phy-* which are currently loaded to the initramfs. That change appears to
> be in v0.119 while Jessie has v0.120 so perhaps something else is going on.
> 
> ci-* isn't covered by this logic, so that might be it in the first case.
> What is ci-*?

Thaose are the chipidea USB controller drivers, which should get found
through sysfs.

Please can you clear out /etc/initramfs-tools/modules (temporarily) and
run:

    sh -x /usr/sbin/mkinitramfs -o /dev/null 3.16.0-4-armmp >mkinitramfs.log 
2>&1

Then send the log so we can see how this is going wrong.

Ben.

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

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

Bug#790722: mkinitramfs fails with latest udev (>= 220-7) on some systems

[Ben Hutchings]

On Wed, 2015-12-09 at 22:09 +, Ben Hutchings wrote:
[...]
> > By the way, I am still hoping to get my parse_numeric patch, available at
> > http://users.wowway.com/~zlinuxman/kernel/parse_numeric.patch, included in
> > initramfs-tools.
> 
> It's not there any more...
> 
> > The current code cannot handle a kernel composite device number
> > greater than 0xf.  With the patch, it should be able to handle any valid
> > kernel composite device number.
> 
> ...but I sent you my patch for this.  It's also on that git branch.
> 
> Please can you test initramfs-tools built from that branch?  Note that
> this has the binary package split into initramfs-tools and initramfs-
> tools-core, and you'll need to install both.

These changes are now in unstable; please can you confirm whether the
bug is fixed?  If I don't hear from you I'll eventually just close
this.

Ben.

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

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

Bug#811129: Bug #811129: fails to boot on OpenRD

[Albert ARIBAUD]

Hello all,

I /think/ I've got the bug cornered (actually, I had a patch for it
already submitted...) but it is not the only problem with 2016.01 on
Open-RD.

One, major, other problem is that the 2016.01 Open-RD U-Boot does not
have the "sf" command. Once the boot issue is fixed, you can flash that
U-Boot on the NOR SPI... And then next time you want to flash a new
U-Boot, you're SOL because "sf probe" and "sf write" won't work. :/

I am working on reintegrating the "sf" command. Once this is done, I'll
be able to properly test the boot bug and /then/ the U-Boot package can
be updated.

Amicalement,
-- 
Albert.

Bug#811460: ITP: fast5 -- library for reading Oxford Nanopore Fast5 files

[Steffen Möller]

Hi, I happily help with sponsoring  and any feedback on how nice the
nanopore is working for you would be appreciated :)
Best,
Steffen

On 19/01/16 09:07, Afif Elghraoui wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Debian Med Packaging Team 
> 
> Control: block 811458 by -1
>
> * Package name: fast5
>   Version : 0~20150918
>   Upstream Author : Matei David
> * URL : https://github.com/mateidavid/fast5
> * License : MIT
>   Programming Lang: C++
>   Description : library for reading Oxford Nanopore Fast5 files
>
> Fast5 is a lightweight C++11 library to read raw signal data from Oxford
> Nanopore's FAST5 files.
>
> This package will be maintained by the Debian Med team. It is a requirement
> for nanopolish.
>

Bug#812591: liquidsoap: segfaults immediately

[Andrew Yong]

Package: liquidsoap
Version: 1.1.1-7.1
Severity: important

Dear Maintainer,

I am running liquidsoap 1.1.1-7.1 on Debian Unstable 4.3.0-1-armmp. It 
immediately segfaults, even with --help switch only.

I am now compiling from the Git trunk 
(https://github.com/savonet/liquidsoap-full.git) with instructions on 
http://liquidsoap.fm/download.html and will see if this resolves the segfault, 
that should help.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: armhf (armv7l)

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

Versions of packages liquidsoap depends on:
ii  adduser 3.113+nmu3
ii  libc6   2.21-7
ii  libcamomile-ocaml-data  0.8.4-4
ii  libmagic1   1:5.25-2
ii  libpcre32:8.38-1
ii  perl5.22.1-4
ii  sox 14.4.1-5
ii  wget1.17.1-1+b1

Versions of packages liquidsoap recommends:
ii  liquidsoap-plugin-faad1.1.1-7.1
ii  liquidsoap-plugin-flac1.1.1-7.1
ii  liquidsoap-plugin-icecast 1.1.1-7.1
ii  liquidsoap-plugin-lame1.1.1-7.1
ii  liquidsoap-plugin-mad 1.1.1-7.1
ii  liquidsoap-plugin-pulseaudio  1.1.1-7.1
ii  liquidsoap-plugin-taglib  1.1.1-7.1
ii  liquidsoap-plugin-voaacenc1.1.1-7.1
ii  liquidsoap-plugin-vorbis  1.1.1-7.1
ii  logrotate 3.8.7-2
ii  mp3gain   1.5.2-r2-2+deb7u1
ii  vorbis-tools  1.4.0-7
ii  vorbisgain0.37-2

Versions of packages liquidsoap suggests:
pn  festival   
ii  icecast2   2.4.2-1
pn  liguidsoap 
pn  liquidsoap-plugin-samplerate   
pn  liquidsoap-plugin-xmlplaylist  
pn  mplayer

-- no debconf information

Bug#812585: exim4: Exim crashing when comparing password created with "htpaswwd" without "-d" -- segmentation fault.

[Marc Haber]

This looks to me like a rather interesting upstream problem. Do you
feel comfortable with installing debug symbols and trying to obtain a
backtrace?

You might also want to report this to the upsteam bugzilla yourself to
make for shorter paths of communication.

Thanks for reporting this!

Greetings
Marc

On Mon, Jan 25, 2016 at 11:35:15AM +0100, Leszek Dubiel wrote:
> From: Leszek Dubiel 
> Subject: Bug#812585: exim4: Exim crashing when comparing password created
>  with "htpaswwd" without "-d" -- segmentation fault.
> To: Debian Bug Tracking System 
> Reply-To: Leszek Dubiel ,
>  812...@bugs.debian.org
> Date: Mon, 25 Jan 2016 11:35:15 +0100
> X-Debian-PR-Package: exim4
> X-Mailer: reportbug 6.6.3
> List-Id: Reach the exim4 maintainers
>  
> X-Spam-Score: (-) -1.9
> X-Spam-Report: torres.zugschlus.de  Content analysis details:   (-1.9
>  points, 5.0 required)   pts  rule name  description  
>  -- --- -0.0
>  RP_MATCHES_RCVDEnvelope sender domain matches handover relay
>  domain -1.9 BAYES_00   BODY: Bayes spam probability is 0 to 1%
>  [score: 0.]
> 
> Package: exim4
> Version: 4.84-8+deb8u2
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
> Here's the script to reproduce error: 
> 
>   #!/bin/bash 
> 
>   exec 2>&1
> 
>   printf '' >/tmp/mypassfile
>   echo "fooboo" | htpasswd -d -i /tmp/mypassfile john1 
>   echo "fooboo" | htpasswd-i /tmp/mypassfile john2
>   echo "xxxyyy" | htpasswd -d -i /tmp/mypassfile john3
>   echo "xxxyyy" | htpasswd-i /tmp/mypassfile john4
>   cat /tmp/mypassfile
>   printf "\n\n"
> 
>   for u in john1 john2 john3 john4; do 
>   for p in fooboo xxxyyy; do 
>   echo "user=$u, pass=$p"
>exim -be 
> '${lookup{'"$u"'}lsearch{/tmp/mypassfile}{$value}{*}}'
>   exim -be '${if 
> crypteq{'"$p"'}{${lookup{'"$u"'}lsearch{/tmp/mypassfile}{$value}{*}}}{ok and 
> suceed}{ok but failed}}'
>   echo
>   done
>   done 
> 
> and heres my output: 
> 
>   Adding password for user john1
>   Adding password for user john2
>   Adding password for user john3
>   Adding password for user john4
>   john1:Wob0SnzzkZiR6
>   john2:$apr1$4ONta6/3$ST0PLD7TaDxfYEnSbPpoy1
>   john3:Bvn4WIUEUqpK6
>   john4:$apr1$4hCz.Hp.$HhHC6yULqW1TEUGuC0bsS1
> 
> 
>   user=john1, pass=fooboo
>   Wob0SnzzkZiR6
>   ok and suceed
> 
>   user=john1, pass=xxxyyy
>   Wob0SnzzkZiR6
>   ok but failed
> 
>   user=john2, pass=fooboo
>   $apr1$4ONta6/3$ST0PLD7TaDxfYEnSbPpoy1
>   ./reproduce_exim_segmentation_fault_on_crypteq: line 14: 28257 
> Segmentation fault  exim -be '${if 
> crypteq{'"$p"'}{${lookup{'"$u"'}lsearch{/tmp/mypassfile}{$value}{*}}}{ok and 
> suceed}{ok but failed}}'
> 
>   user=john2, pass=xxxyyy
>   $apr1$4ONta6/3$ST0PLD7TaDxfYEnSbPpoy1
>   ./reproduce_exim_segmentation_fault_on_crypteq: line 14: 28261 
> Segmentation fault  exim -be '${if 
> crypteq{'"$p"'}{${lookup{'"$u"'}lsearch{/tmp/mypassfile}{$value}{*}}}{ok and 
> suceed}{ok but failed}}'
> 
>   user=john3, pass=fooboo
>   Bvn4WIUEUqpK6
>   ok but failed
> 
>   user=john3, pass=xxxyyy
>   Bvn4WIUEUqpK6
>   ok and suceed
> 
>   user=john4, pass=fooboo
>   $apr1$4hCz.Hp.$HhHC6yULqW1TEUGuC0bsS1
>   ./reproduce_exim_segmentation_fault_on_crypteq: line 14: 28273 
> Segmentation fault  exim -be '${if 
> crypteq{'"$p"'}{${lookup{'"$u"'}lsearch{/tmp/mypassfile}{$value}{*}}}{ok and 
> suceed}{ok but failed}}'
> 
>   user=john4, pass=xxxyyy
>   $apr1$4hCz.Hp.$HhHC6yULqW1TEUGuC0bsS1
>   ./reproduce_exim_segmentation_fault_on_crypteq: line 14: 28279 
> Segmentation fault  exim -be '${if 
> crypteq{'"$p"'}{${lookup{'"$u"'}lsearch{/tmp/mypassfile}{$value}{*}}}{ok and 
> suceed}{ok but failed}}'
> 
> 
> 
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- Package-specific info:
> Exim version 4.84 #3 built 15-Dec-2015 04:18:37
> Copyright (c) University of Cambridge, 1995 - 2014
> (c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2014
> Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
> Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM PRDR OCSP
> Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
> dbmnz dnsdb dsearch nis nis0 passwd
> Authenticators: cram_md5 plaintext
> Routers: accept dnslookup ipliteral manualroute queryprogram redirect
> Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
> Fixed never_users: 0
> Size of off_t: 8
> 

Bug#812593: linux-base: saa7134_alsa won't unload, reported in use by kernel

[John Smith]

Package: linux-base
Version: 3.5
Severity: normal
Tags: newcomer

Dear Maintainer,

Here is the summary:

   * What led up to the situation?
 I don't know when this problem first appeared as I was upgrading
regularly and did not need to remove the module. Recently I was forced to do a
fresh install and I needed to find out the card and tuner for the saa7134
module because the i2c system would not detect the correct card. To try
different settings I needed to unload and reload the saa7134 module multiple
times. But failed at the first attempt due to saa7134_alsa module being
reported as in use. Although lsmod says:
Module  Size  Used by
saa7134_alsa   17686  0

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
rmmod -f saa7134_alsa
modprobe -vfr saa7134_alsa

   * What was the outcome of this action?
modprobe reported this error:
modprobe: FATAL: Module saa7134_alsa is in use.
modprobe: ERROR: ../libkmod/libkmod-module.c:777
kmod_module_remove_module() could not remove 'saa7134_alsa': Device or resource
busy

   * What outcome did you expect instead?
removal of the module even without the "force" option, as was the case
in prior kernels.



-- System Information:
Debian Release: 8.2
  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/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 linux-base depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libuuid-perl   0.05-1+b1
ii  udev   215-17+deb8u2
ii  util-linux 2.25.2-6

linux-base recommends no packages.

linux-base suggests no packages.

-- debconf information:
  linux-base/disk-id-convert-plan-no-relabel: true
  linux-base/disk-id-manual-boot-loader:
  linux-base/disk-id-update-failed:
  linux-base/do-bootloader-default-changed:
  linux-base/disk-id-convert-auto: true

Bug#810499: usrmerge: Confuses dpkg-shlibdeps

[Matthias Klumpp]

2016-01-17 6:58 GMT+01:00 Marco d'Itri :
> On Jan 12, Guillem Jover  wrote:
>
>> Check your /etc/ld.so.conf.d/* for anything included libx32, and check
>> if «dpkg-query --search» knows about that pathname, and if it's the
>> canonical one or a symlinked one.
> I still do not fully understand how dpkg-shlibdeps determines the full
> library path from the NEEDED ELF entries, but how can it work if the
> libraries which are installed in /usr/lib/... now appear in /lib/...?

Here's the stuff I think that happens:
file /tmp/perf-read-vdsox32
/tmp/perf-read-vdsox32: ELF 32-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for
GNU/Linux 3.4.0,
BuildID[sha1]=08e989782c6b565fed78770acdb690f86123e6a1, stripped
file /tmp/perf-read-vdso32
/tmp/perf-read-vdso32: ELF 32-bit LSB executable, Intel 80386, version
1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for
GNU/Linux 2.6.32,
BuildID[sha1]=3c770afba2f8bdf603ed3372ee2695c4f565b0b0, stripped

The code seems to be compiled for different architectures, and
dpkg-shlibdeps knows that from analyzing the ELF binary, but then
searches the libc and other dependencies in the paths it finds on the
current system, resulting it not finding the right software (since the
dpkg database still lists these binaries in the non-usrmerge
directories).

On i386, it also searches in the wrong path, but in that case I am not
sure why this fails on this package but not on others:
```
dpkg-shlibdeps: error: no dependency information found for
/usr/lib/ld-linux.so.2 (used by
debian/liblockdep4.4/usr/lib/i386-linux-gnu/liblockdep.so.4.4)
```

Cheers,
Matthias

Bug#812603: RM: polarssl -- RoQA; rc-buggy, superseded by mbedtls

[James Cowgill]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: sti...@antcom.de

Hi,

Please remove polarssl from unstable and experimental.

PolarSSL has been rebranded upstream as "mbed TLS" and not too long ago
released version 2 which contains significant API changes. The new
version is packaged as "mbedtls" and I maintain it.

I think everything which was using polarssl has been ported to mbedtls
so the old package can now be removed. The final rdeps bzrtp and belle-
sip were recently uploaded so you might have to wait a bit until
they've been built everywhere.

I've emailed Roland Stigge (the polarssl maintainer, on copy) who said
it was ok for the package to be removed.

Thanks,
James

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

Bug#812602: don't recommend a specific python3.x version

[Mattia Rizzolo]

On Mon, Jan 25, 2016 at 03:00:45PM +0100, Matthias Klose wrote:
> btw, why the +dfsg+dfsg in the version?

It somehow slipped in when I imported the new upstream release, and then
I uploaded it without noticing.
Of course I realized something was off once it was too late for changing
it back...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://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#812602: don't recommend a specific python3.x version

[Matthias Klose]

ohh, and maybe drop the python2.7 recommends as well.

Bug#791247: #791247: pstoedit: library transition may be needed when GCC 5 is the default

[Roland Stigge]

Hi,

the libraries in pstoedit are currently only used package internally. I.e., 
there are no reverse dependencies and there will hardly ever be.

As package maintainer, I request that in this case, we don't do a transition in 
the package.

What do you think?

Thanks in advance, 

Roland. 
-- 

Bug#603944: Updated patch

[Ben Hutchings]

On Wed, 2015-12-09 at 20:35 +, Ben Hutchings wrote:
> Serge, I'm sorry this patch hasn't had any attention for so long.
> 
> On Thu, 9 Dec 2010 15:20:28 -0600 "Serge E. Hallyn"  wrote:
> > Here is a patch (against the ubuntu package, just as example)
> > which instead of doing a dumb retry loop, waits for udev.
> >  
> > === modified file 'debian/changelog'
> > --- debian/changelog2010-04-26 15:17:47 +
> > +++ debian/changelog2010-12-08 21:44:32 +
> > @@ -1,3 +1,15 @@
> > +initramfs-tools (0.92bubuntu79) natty; urgency=low
> > +
> > +  * When using multipath, it is possible that mountroot() will race
> > +with udev's renaming of /dev/disk/by-uuid/{rootfs-uuid} from
> > +/dev/sd?? to /dev/mapper/something.  After multipath has grabbed
> > +the /dev/sd?? and until udev completes the rename, mounting
> > +/dev/disk/by-uuid/{rootfs-uuid} will fail with -EBUSY.  In that
> > +case, call 'udevsettle' to wait until udev has finished all its
> > +related actions. (Closes LP: #686832)
> > +
> > + -- Serge Hallyn   Fri, 19 Nov 2010 12:19:43 -0600
> 
> (Bear in mind that I have no experience of using multipath.)
> 
> If one path shows up quickly and the other rather later, can't we still
> end up mounting the single-path device rather than the multipath
> device?  How do we tell when multipath discovery is complete?
> 
> Does it even make sense to specify a multipath device by UUID rather
> than by its device-mapper name?  This certainly isn't supported for
> LVM.

You need to answer these questions, otherwise I'm just going to close
this bug.

Ben.

> >   initramfs-tools (0.92bubuntu78) lucid; urgency=low
> >   
> > * hooks/compcache: Escape $-expansions inside <
> >  
> > === modified file 'scripts/local'
> > --- scripts/local   2009-12-21 23:06:53 +
> > +++ scripts/local   2010-11-20 01:03:26 +
> > @@ -69,10 +69,19 @@
> >     # FIXME This has no error checking
> >     [ -n "${FSTYPE}" ] && modprobe ${FSTYPE}
> >   
> > -   # FIXME This has no error checking
> >     # Mount root
> > -   mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
> > -   mountroot_status="$?"
> > +   tries=0
> > +   ret=1
> > +   while [ $tries -lt 2 -a $ret -ne 0 ]; do
> > +   mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} 
> > ${rootmnt}
> > +   ret=$?
> > +   if [ $ret -ne 0 ]; then
> > +   echo "failed attempt $tries to mount $ROOT as root"
> > +   udevadm settle
> > +   tries=$((tries+1))
> > +   fi
> > +   done
> > +   mountroot_status=$ret
> >     if [ "$LOOP" ]; then
> >     if [ "$mountroot_status" != 0 ]; then
> >     if [ ${FSTYPE} = ntfs ] || [ ${FSTYPE} = vfat ]; then
> >  
> >  
> >  
> >  
-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.

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

Bug#812595: ibgl1-nvidia-glx: can't install package

[Thierry Florac]

Package: ibgl1-nvidia-glx
Version: 352.63-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Can't update package "libgl1-nvidia-glx" (release 352.63-2) because of an
unpack error:

Preparing to unpack .../libgl1-nvidia-glx_352.63-2_amd64.deb ...
dpkg: error processing archive /var/cache/apt/archives/libgl1-nvidia-
glx_352.63-2_amd64.deb (--unpack):
 subprocess new pre-installation script returned error exit status 128
Processing triggers for libc-bin (2.21-7) ...
Errors were encountered while processing:
 /var/cache/apt/archives/libgl1-nvidia-glx_352.63-2_amd64.deb



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

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

Bug#809497: debian-cd: Please include espeakup on cd1, not speakup, and alsa-utils

[Samuel Thibault]

Steve McIntyre, on Mon 25 Jan 2016 12:03:10 +, wrote:
> If you consider it important enough, I can respin the images as
> 8.3.1. What do you think?

This is a problem only when installing with CD1 without network mirror.
The issue was raised only a few weeks ago, so it doesn't seem to bad.

Samuel

Bug#784688: Thousands of "xen:balloon: Cannot add additional memory (-17) messages" despite dom0 ballooning disabled

[Ian Campbell]

On Fri, 2016-01-22 at 21:38 +0200, KSB wrote:
> Seen this behavior on earlier kernels (i.e. 3.14-2-amd64 pkg 3.14.15-2.) 
> and seems to be gone at least in 4.3

That's useful info thanks, I've been unable to pinpoint a culprit for this
for ages now.

Do you have a package version which you know to be good? How confident are
you that it is ok (sometimes the problem is intermittent)?

Lastly, is there any chance you upgraded the Xen packages at the same time?
I'm starting to wonder if maybe this is not a kernel issue.

Ian.

Bug#763542: chrony: logrotate config file triggers an "Unrecognized command" error

[Vincent Blut]

On Sun, Jan 24, 2016 at 06:38:00PM +0100, Kurt Roeckx wrote:

On Mon, Jul 13, 2015 at 01:11:41PM +1000, Den Ivanov wrote:

Hi,
Confirm this bug, Jessie 8.1


Would it be possible to get this bug fixed in jessie too?


Hello Kurt,

Sure, in fact I already thought about applying this in jessie, but I was 
unsure that would be something the release team would approve. Anyway, I 
added this on my TODO list for 8.4 and see what they think about it. ;-)


Cheers,
Vincent


Kurt


signature.asc
Description: PGP signature

Bug#812604: nut-server: usbhid-ups segfaults due to missing USB strings

[Michael Kuron]

Package: nut-server
Version: 2.7.2-4
Severity: important
Tags: upstream patch

Dear Maintainer,

I am using an APC Back-UPS Pro with the usbhid-ups driver in NUT.
After upgrading from Debian 6 to Debian 8, the driver would not start anymore
and segfaulted before delivering any data.

There is an upstream bug report at
https://github.com/networkupstools/nut/issues/258
that deals with this problem. It is due to incorrect handling of a missing
USB product identifier string. Apparently the issue only occurs when running
on VMware ESXi, where the USB string is probably lost due to some issue with
the hypervisor, the kernel, or libusb.

A patch is available upstream at
https://github.com/networkupstools/nut/commit/f679a28
and I have confirmed that it fixes the bug for version 2.7.2 in Debian too.

Thanks,
Michael Kuron

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nut-server depends on:
ii  adduser  3.113+nmu3
ii  init-system-helpers  1.22
ii  libc62.19-18+deb8u2
ii  libnspr4 2:4.10.7-1+deb8u1
ii  libnss3  2:3.17.2-1.1+deb8u2
ii  libupsclient42.7.2-4
ii  libusb-0.1-4 2:0.1.12-25
ii  libwrap0 7.6.q-25
ii  lsb-base 4.1+Debian13+nmu1
ii  nut-client   2.7.2-4
ii  udev 215-17+deb8u3

nut-server recommends no packages.

Versions of packages nut-server suggests:
pn  nut-cgi   
pn  nut-ipmi  
pn  nut-snmp  
pn  nut-xml   

-- Configuration Files:
/etc/nut/ups.conf [Errno 13] Permission denied: u'/etc/nut/ups.conf'
/etc/nut/upsd.conf [Errno 13] Permission denied: u'/etc/nut/upsd.conf'
/etc/nut/upsd.users [Errno 13] Permission denied: u'/etc/nut/upsd.users'

-- no debconf information
diff --git a/drivers/apc-hid.c b/drivers/apc-hid.c
index 1d85621..1393d50 100644
--- a/drivers/apc-hid.c
+++ b/drivers/apc-hid.c
@@ -62,6 +62,11 @@ static void *general_apc_check(USBDevice_t *device)
 {
 	int i = 0;
 
+	if (!device->Product) {
+		upslogx(LOG_WARNING, "device->Product is NULL so it is not possible to determine whether to activate max_report_size workaround");
+		return NULL;
+	}
+
 	/* Some models of Back-UPS overflow on some ReportID.
 	 * This results in some data not being exposed and IO errors on
 	 * WIN32, causing endless reconnection or driver's failure */

Bug#747554: python-vobject: python3 branch

[Petter Reinholdtsen]

I just tried porting calypso to python3 (do not seem very hard), but
one of the blockers is the lack of python3-vobject.  Any news on a
new upstream for vobject?

Perhaps someone would be willing to take over the development of
the project?  It is used by several Debian packages:

% apt-cache rdepends python-vobject
python-vobject
Reverse Depends:
  calypso
  urlwatch
  tryton-modules-party-vcarddav
  tryton-modules-calendar-todo
  tryton-modules-calendar-classification
  tryton-modules-calendar
  translate-toolkit
  qreator
  python-caldav
  python-pycarddav
  gnumed-client
  gcalcl
%

-- 
Happy hacking
Petter Reinholdtsen

Bug#794300: buildbot: FTBFS on unstable and needs rebuild for sqlalchemy transition

[Francois Gouget]

Any news on this?
Buildbot is still causing conflicts every time I do a package update...


-- 
Francois Gouget   http://fgouget.free.fr/
 Linux: the choice of a GNU generation

Bug#805848: Please update taglib in Debian to version 1.10

[Jérémy Bobbio]

Control: block 810498 by 805848

Hi!

The latest release of Clementine requires taglib 1.10. It would be great
if you could update the Debian package.

Thanks,
-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#811116: lxc-ls raises error messages

[Sven Haardiek]

Hej,

installing cgmanager solved it for me.

Regards, 

Sven

On Fri, 15 Jan 2016 21:24:10 +0100 Patrice Pillot
 wrote:
> Package: lxc
> Version: 1:1.0.8-1
> Severity: normal
> 
> Dear Maintainer,
> 
> When I run commands as lxc-ls, lxc-info, lxc-start, ... on my desktop
> the following error message is printed in host terminal :
> 
> lxc: cgmanager.c: lxc_list_controllers: 817 Error connecting to cgroup
> manager
> 
> Apart from this message, everything seems to run fine :
> - creating containers (privileged, at least),
> - starting containers
> - stopping containers
> - using lxc-info or lxc-ls (except from the garbling effect of this
>   message)
> 
> This is the output of lxc-checkconfig:
> 
> 8<
> Kernel configuration not found at /proc/config.gz; searching...
> Kernel configuration found at /boot/config-4.3.0-1-amd64
> --- Namespaces ---
> Namespaces: enabled
> Utsname namespace: enabled
> Ipc namespace: enabled
> Pid namespace: enabled
> User namespace: enabled
> Network namespace: enabled
> Multiple /dev/pts instances: enabled
> 
> --- Control groups ---
> Cgroup: enabled
> Cgroup clone_children flag: enabled
> Cgroup device: enabled
> Cgroup sched: enabled
> Cgroup cpu account: enabled
> Cgroup memory controller: enabled
> Cgroup cpuset: enabled
> 
> --- Misc ---
> Veth pair device: enabled
> Macvlan: enabled
> Vlan: enabled
> Bridges: enabled
> Advanced netfilter: enabled
> CONFIG_NF_NAT_IPV4: enabled
> CONFIG_NF_NAT_IPV6: enabled
> CONFIG_IP_NF_TARGET_MASQUERADE: enabled
> CONFIG_IP6_NF_TARGET_MASQUERADE: enabled
> CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled
> 
> --- Checkpoint/Restore ---
> checkpoint restore: enabled
> CONFIG_FHANDLE: enabled
> CONFIG_EVENTFD: enabled
> CONFIG_EPOLL: enabled
> CONFIG_UNIX_DIAG: enabled



pgpqNvmC74I91.pgp
Description: OpenPGP digital signature

Bug#808802: #808802 synaptic: Can't drop privileges for downloading as file '/var/lib/apt/lists/partial/ftp.fr.debian.org_debian_dists_testing_InRelease'

[Tsu Jan]

On Mon, 25 Jan 2016 12:17:45 +0100 Michael Vogt  wrote:
> This is a bug indeed, the question is how it got triggered, that dir
> should be owend by the _apt user.
>
> What is the output of:
> $ ls -dl /var/cache/apt/archives/partial/
>
> Thanks,
> Michael

That directory has been owned by root from time immemorial. I've never 
had an "_apt" user/group and no update created such a user/group. In 
other words, this is a *new* problem that started after a recent update 
(of apt?).


The output of "ls -dl":

drwxr-xr-x 2 root root 4096 Jan 25 13:20 /var/cache/apt/archives/partial/

Thanks!

Bug#782828: libimobiledevice: diff for NMU version 1.2.0+dfsg-2.1

[Mattia Rizzolo]

Control: tags 782828 + pending

Dear maintainer,

I've prepared an NMU for libimobiledevice (versioned as 1.2.0+dfsg-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Allegedly the maintainer is ignoring this bug, but since this is now one
blocker for the gnutls28 transition, and it's preventing other packages
from entering testing, I'm NMUing it.

It's the very same patch Andreas Metzler uploaded earlier, but got
reverted (I'm tempted to say accidentally, not sure if anybody noticed
the NMU).

Regards.

-- 
regards,
Mattia Rizzolo

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

 changelog |   11 +++
 patches/10_Updated-cert-callback-to-gnutls3-API.patch |   59 ++
 patches/series|1 
 3 files changed, 71 insertions(+)

diff -Nru libimobiledevice-1.2.0+dfsg/debian/changelog libimobiledevice-1.2.0+dfsg/debian/changelog
--- libimobiledevice-1.2.0+dfsg/debian/changelog	2016-01-04 15:27:11.0 +
+++ libimobiledevice-1.2.0+dfsg/debian/changelog	2016-01-25 15:01:46.0 +
@@ -1,3 +1,14 @@
+libimobiledevice (1.2.0+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Andreas Metzler ]
+  * Apply 0001-Updated-cert-callback-to-gnutls3-API.patch from
+https://github.com/kalev/libimobiledevice/  to fix FTBFS against
+gnutls >= 3.4. Closes: #782828
+
+ -- Mattia Rizzolo   Mon, 25 Jan 2016 15:01:41 +
+
 libimobiledevice (1.2.0+dfsg-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru libimobiledevice-1.2.0+dfsg/debian/patches/10_Updated-cert-callback-to-gnutls3-API.patch libimobiledevice-1.2.0+dfsg/debian/patches/10_Updated-cert-callback-to-gnutls3-API.patch
--- libimobiledevice-1.2.0+dfsg/debian/patches/10_Updated-cert-callback-to-gnutls3-API.patch	1970-01-01 00:00:00.0 +
+++ libimobiledevice-1.2.0+dfsg/debian/patches/10_Updated-cert-callback-to-gnutls3-API.patch	2016-01-25 15:00:53.0 +
@@ -0,0 +1,59 @@
+From ecba0d673186d17f87fdd75d5d3b9dd9c42c2f0a Mon Sep 17 00:00:00 2001
+From: Nikos Mavrogiannopoulos 
+Date: Wed, 26 Aug 2015 13:43:15 +0200
+Subject: [PATCH] Updated cert callback to gnutls3 API
+
+Fixes #225
+---
+ configure.ac  | 2 +-
+ src/idevice.c | 7 ---
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index 43da458..6c598f3 100644
+--- a/configure.ac
 b/configure.ac
+@@ -146,7 +146,7 @@ if test "x$enable_openssl" = "xyes"; then
+   ssl_requires="$pkg_req_openssl"
+   AC_SUBST(ssl_requires)
+ else
+-  pkg_req_gnutls="gnutls >= 2.2.0"
++  pkg_req_gnutls="gnutls >= 3.0"
+   pkg_req_libtasn1="libtasn1 >= 1.1"
+   PKG_CHECK_MODULES(libgnutls, $pkg_req_gnutls)
+   AC_CHECK_LIB(gcrypt, gcry_control, [AC_SUBST(libgcrypt_LIBS,[-lgcrypt])], [AC_MSG_ERROR([libgcrypt is required to build libimobiledevice with GnuTLS])])
+diff --git a/src/idevice.c b/src/idevice.c
+index ce27495..0cf6641 100644
+--- a/src/idevice.c
 b/src/idevice.c
+@@ -626,7 +626,7 @@ static const char *ssl_error_to_string(int e)
+ /**
+  * Internally used gnutls callback function that gets called during handshake.
+  */
+-static int internal_cert_callback(gnutls_session_t session, const gnutls_datum_t * req_ca_rdn, int nreqs, const gnutls_pk_algorithm_t * sign_algos, int sign_algos_length, gnutls_retr_st * st)
++static int internal_cert_callback(gnutls_session_t session, const gnutls_datum_t * req_ca_rdn, int nreqs, const gnutls_pk_algorithm_t * sign_algos, int sign_algos_length, gnutls_retr2_st * st)
+ {
+ 	int res = -1;
+ 	gnutls_certificate_type_t type = gnutls_certificate_type_get(session);
+@@ -634,7 +634,8 @@ static int internal_cert_callback(gnutls_session_t session, const gnutls_datum_t
+ 		ssl_data_t ssl_data = (ssl_data_t)gnutls_session_get_ptr(session);
+ 		if (ssl_data && ssl_data->host_privkey && ssl_data->host_cert) {
+ 			debug_info("Passing certificate");
+-			st->type = type;
++			st->cert_type = type;
++			st->key_type = GNUTLS_PRIVKEY_X509;
+ 			st->ncerts = 1;
+ 			st->cert.x509 = _data->host_cert;
+ 			st->key.x509 = ssl_data->host_privkey;
+@@ -743,7 +744,7 @@ LIBIMOBILEDEVICE_API idevice_error_t idevice_connection_enable_ssl(idevice_conne
+ 	debug_info("enabling SSL mode");
+ 	errno = 0;
+ 	gnutls_certificate_allocate_credentials(_data_loc->certificate);
+-	gnutls_certificate_client_set_retrieve_function(ssl_data_loc->certificate, internal_cert_callback);
++	gnutls_certificate_set_retrieve_function(ssl_data_loc->certificate, internal_cert_callback);
+ 	gnutls_init(_data_loc->session, 

Bug#811106: Crash in this case is likely to be caused by ExternalInterface

[Nutchanon Wetchasit]

Control: tags -1 + upstream

Hello,

There're multiple issues with Gnash's ExternalInterface implementation.
(ExternalInterface is a module responsible for JavaScript-Flash
procedure call) Few of them were fixed in very recent Gnash's revision.

I have attempted to hook current development version of Gnash to Youtube, and
found the same problem; the video preview image is briefly shown, then
XUL plugin container crashed.

Communication log between libgnashplugin (ran under XUL plugin-container)
and gtk-gnash (which ran as a separate process) before the crash, shown that
this is very likely triggered by an attempt to pass an Object variable from
Flash to JavaScript as a return value from procedure call.

Procedure call sent from libgnashplugin to gtk-gnash:



Return value sent from gtk-gnash to libgnashplugin:

playVideoByIdgetAvailableModulesdisableModuleenableModuledestroysetAccessTokengetApiInterfacesetListIdgetAvailableQualityLevelssetPlaybackQualitygetPlaybackQualitygetVideoEmbedCodegetVideoUrlgetVolumesetVolumeisMutedunMutemuteaddEventListenersetSizegetPlayerStategetDurationseekTogetVideoStartBytesgetVideoBytesTotalgetVideoBytesLoadedgetVideoLoadedFractiongetCurrentTimeclearVideostopVideopauseVideoplayVideocueVideoByUrlloadVideoByUrlloadNonYouTubeVideocueVideoByIdloadVideoById


Object-typed return value is known to cause libgnashplugin to crash after
few seconds (gtk-gnash itself is not crashed). See upstream bug 32411
for details:



The reason that this is surfaced only in recent version of Gnash is
older Gnash have a bug that prevented gtk-gnash side from responding to
JavaScript call entirely (bug 37223 ).
The bug is recently fixed, so this crash issue surfaced.

Regards,
Nutchanon Wetchasit

Gnash: 0.8.11dev (git 62cfdfe 16-Jan-2016) NPAPI
Iceweasel: 10.0.12esr-1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

P.S. Full communication logs are also attached as a reference. YouTube URL
visited when I captured these log was



CONNECTION_ISSUEytPlayerCONNECTION_ISSUEplayer_uid_187039013_1
loadVideoById
cueVideoById
loadNonYouTubeVideo
loadVideoByUrl
cueVideoByUrl
playVideo
pauseVideo
stopVideo
clearVideo
getCurrentTime
getVideoLoadedFraction
getVideoBytesLoaded
getVideoBytesTotal
getVideoStartBytes
seekTo
getDuration
getPlayerState
setSize
addEventListener
mute
unMute
isMuted
setVolume
getVolume
getVideoUrl
getVideoEmbedCode
getPlaybackQuality
setPlaybackQuality
getAvailableQualityLevels
setListId
getApiInterface
setAccessToken
destroy
enableModule
disableModule
getAvailableModules
playVideoById
playVideoByIdgetAvailableModulesdisableModuleenableModuledestroysetAccessTokengetApiInterfacesetListIdgetAvailableQualityLevelssetPlaybackQualitygetPlaybackQualitygetVideoEmbedCodegetVideoUrlgetVolumesetVolumeisMutedunMutemuteaddEventListenersetSizegetPlayerStategetDurationseekTogetVideoStartBytesgetVideoBytesTotalgetVideoBytesLoadedgetVideoLoadedFractiongetCurrentTimeclearVideostopVideopauseVideoplayVideocueVideoByUrlloadVideoByUrlloadNonYouTubeVideocueVideoByIdloadVideoById
onYouTubePlayerReadyplayer%5Fuid%5F187039013%5F1

Bug#809497: debian-cd: Please include espeakup on cd1, not speakup, and alsa-utils

[Steve McIntyre]

On Mon, Jan 25, 2016 at 02:03:22PM +0100, Samuel Thibault wrote:
>Steve McIntyre, on Mon 25 Jan 2016 12:03:10 +, wrote:
>> If you consider it important enough, I can respin the images as
>> 8.3.1. What do you think?
>
>This is a problem only when installing with CD1 without network mirror.
>The issue was raised only a few weeks ago, so it doesn't seem to bad.

OK, fair enough. I've just fixed up the git setup now anyway, so I can
definitely promise things will be in 8.4

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.

Bug#811024: jessie-pu: package imagemagick/8:6.8.9.9-5

[Vincent Fourmond]

  Hello,

On Mon, Jan 18, 2016 at 9:39 PM, Vincent Fourmond 
wrote:

> On Thu, Jan 14, 2016 at 10:49 PM, Vincent Fourmond 
> wrote:
>
>> On Thu, Jan 14, 2016 at 10:44 PM, Adam D. Barratt <
>> a...@adam-barratt.org.uk> wrote:
>>
>>> Control: tags -1 + moreinfo
>>>
>>> On Thu, 2016-01-14 at 22:33 +0100, Vincent Fourmond wrote:
>>> >   The imagemagick maintainers (mostly Bastien) have prepared a new
>>> > version of imagemagick for stable that fixes a series of minor
>>> > security issues that the security team did not deem worthy of an
>>> > upload to stable-security. Can we upload the following package ? Here
>>> > is the changelog:
>>>
>>> While I've not checked each fix individually (mostly due to the lack of
>>> Debian bugs referenced), at least these changes:
>>>
>>> > - Fix an integer overflow that can lead to a buffer overrun
>>> >   in the icon parsing code (LP: #1459747, closes: #806441)
>>> > - Fix an integer overflow that can lead to a double free in
>>> >   pict parsing (LP: #1448803, closes: #806441).
>>>
>>> claim not to be fixed in unstable according to the BTS metadata, which
>>> is a pre-requisite for fixing them in stable. Please could you clarify
>>> the status of those and the other fixes.
>>>
>>
>>   You are unfortunately correct. We have uploaded a fix to experimental,
>> but it may not make its way before a while to unstable, so probably the
>> wisest course is to backport the changes to unstable, and then, I'll get
>> back to you.
>>
>
>   I have uploaded a -7 version to unstable that fixes the security
> problems mentioned above (some of those had been fixed before). I also have
> updated the changelog to make the changes more easy to track. Essentially,
> the upload I'm proposing (debdiff to stable attached) makes stable and
> unstable identical, since there were only security fixes involved (the bulk
> of the work is happening in experimental, but there are transitions
> involved, so it's not very fast...). Is that OK for an upload to jpu ?
>

  Can I upload to jpu, then ? Or should the fix move to testing first ?

  Cheers,

  Vincent

Bug#776188: qbzr: autopkgtest fails since 2015-01-01

[Dmitry Shachnev]

On Sun, 25 Jan 2015 10:59:25 +0300, Dmitry Shachnev wrote:
> qbzr autopkgtest fails on both ci.debian.net [1] and jenkins.qa.ubuntu.com [2]
> since recently.
>
> [...]
>
> On both servers, it is clear that the test succeeded in 2014, but started
> failing in 2015 (maybe due to some dependency package update).

According to https://ci.debian.net/packages/q/qbzr/unstable/amd64/, the tests
fail on months containing J, that is Januarys, Junes and Julys.

And it's because the code searches for "j" here:

  File 
"/usr/lib/python2.7/dist-packages/bzrlib/plugins/qbzr/lib/tests/test_guidebar.py",
 line 225, in test_find
self.assert_find("j", panels[0].bar, panels[0].edit, 1)

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Bug#812596: override: khmer:science/optional

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal

As per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811245
The section “python” is for packages that install the Python
programming language or libraries. Its packages are primarily of
interest only to Python programmers.

The package ‘khmer’ installs primarily an application of interest
regardless of the programming language. It should not be in the
“python” section.

By the section descriptions, this package belongs in section
“science”.

Bug#812597: libxi6: locale command in konsole comes up empty, utf-8 text problems after upgrade

[Arthur Marsh]

Package: libxi6
Version: 2:1.7.6-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Upgrading libxi6, after restarting the machine, konsole (but not other 
terminal programs) under KDE5 plasma fails to display utf-8 characters.

$ $ locale
LANG=en_AU.UTF-8
LANGUAGE=en_GB
LC_CTYPE=
LC_NUMERIC=
LC_TIME=
LC_COLLATE=
LC_MONETARY=
LC_MESSAGES=
LC_PAPER=
LC_NAME=
LC_ADDRESS=
LC_TELEPHONE=
LC_MEASUREMENT=
LC_IDENTIFICATION=
LC_ALL=


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

downgrading libxi6 solved the problem.

   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.5.0-rc1 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages libxi6 depends on:
ii  libc6 2.21-7
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1

libxi6 recommends no packages.

libxi6 suggests no packages.

-- debconf-show failed

Bug#812599: samba: %G is not expanded

[Pascal]

Package: samba
Version: 2:4.1.17+dfsg-2+deb8u1
Severity: important

Dear Maintainer,

I've got a problem with samba about logon script, when logon script = %G, then 
%G is not expanded and logon script (in netlogon share) are not launched.
More information can be found here : 
https://bugzilla.samba.org/show_bug.cgi?id=10286
Comment 20 : https://bugzilla.samba.org/show_bug.cgi?id=10286#c20

Thanks by advance for help.


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

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

Versions of packages samba depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.17.26
ii  libasn1-8-heimdal1.6~rc2+dfsg-9
ii  libbsd0  0.7.0-2
ii  libc62.19-18+deb8u2
ii  libcomerr2   1.42.12-1.1
ii  libhdb9-heimdal [heimdal-hdb-api-8]  1.6~rc2+dfsg-9
ii  libkdc2-heimdal  1.6~rc2+dfsg-9
ii  libkrb5-26-heimdal   1.6~rc2+dfsg-9
ii  libldb1  2:1.1.17-2+deb8u1
ii  libpam-modules   1.1.8-3.1+deb8u1
ii  libpam-runtime   1.1.8-3.1+deb8u1
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.9-2
ii  libroken18-heimdal   1.6~rc2+dfsg-9
ii  libtalloc2   2.1.1-2
ii  libtdb1  1.3.1-1
ii  libtevent0   0.9.21-1
ii  lsb-base 4.1+Debian13+nmu1
ii  multiarch-support2.19-18+deb8u2
ii  procps   2:3.3.9-9
ii  python   2.7.9-1
ii  python-dnspython 1.12.0-1
ii  python-ntdb  1.0-5
ii  python-samba 2:4.1.17+dfsg-2+deb8u1
pn  python2.7:any
ii  samba-common 2:4.1.17+dfsg-2+deb8u1
ii  samba-common-bin 2:4.1.17+dfsg-2+deb8u1
ii  samba-dsdb-modules   2:4.1.17+dfsg-2+deb8u1
ii  samba-libs   2:4.1.17+dfsg-2+deb8u1
ii  tdb-tools1.3.1-1
ii  update-inetd 4.43

Versions of packages samba recommends:
ii  attr   1:2.4.47-2
ii  logrotate  3.8.7-1+b1
ii  samba-vfs-modules  2:4.1.17+dfsg-2+deb8u1

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
pn  ldb-tools  
pn  ntp
pn  smbldap-tools  
ii  winbind2:4.1.17+dfsg-2+deb8u1

-- no debconf information

Bug#812602: don't recommend a specific python3.x version

[Matthias Klose]

Package: src:sigil
Version: 0.9.2+dfsg+dfsg-2

please don't recommend a specific python3.x version, just python3, and even that 
doesn't seem to be necessary.


btw, why the +dfsg+dfsg in the version?

Bug#812601: nmu: cdo_1.7.0+dfsg.1-2~bpo8+1

[Alastair McKinstry]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hi,
Due to a broken pbuild environment, the following backports were built
against sid rather than jessie, and need to be rebuilt:

nmu cdo_1.7.0+dfsg.1-2~bpo8+1 . ALL . -m "Rebuild against jessie-backports"
nmu libaec_0.3.2-1~bpo8+1 . ALL -m "Rebuild against jessie-backports"
nmu ncl_6.3.0-4~bpo8+1 . ALL-m "Rebuild against jessie-backports"
thanks


-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_IE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#662273: autotrace: diff for NMU version 0.31.1-16+nmu1.1

[Frost, Tobias]

Gianfranco, can you please cancel it?
It needs also a patch...

Thanks!

On Fri, 22 Jan 2016 10:32:10 + (UTC) Gianfranco Costamagna 
 wrote:
> Control: tags 662273 + patch
> Control: tags 662273 + pending
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for autotrace (versioned as 0.31.1-16+nmu1.1) and
> uploaded it to DELAYED/6. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> diff -Nru autotrace-0.31.1/debian/changelog autotrace-0.31.1/debian/changelog
> --- autotrace-0.31.1/debian/changelog   2014-12-16 23:24:46.0 +0100
> +++ autotrace-0.31.1/debian/changelog   2016-01-22 11:31:28.0 +0100
> @@ -1,3 +1,11 @@
> +autotrace (0.31.1-16+nmu1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Change libpng12-dev build-dependency to libpng-dev, to ease libpng
> +transition. (Closes: #662273)
> +
> + -- Gianfranco Costamagna   Fri, 22 Jan 2016 
> 11:31:14 +0100
> +
> autotrace (0.31.1-16+nmu1) unstable; urgency=low
> 
> * Non-maintainer upload.
> diff -Nru autotrace-0.31.1/debian/control autotrace-0.31.1/debian/control
> --- autotrace-0.31.1/debian/control 2011-08-08 02:40:01.0 +0200

Bug#742560: freeimage: diff for NMU version 3.17.0+ds1-1.1

[Anton Gladky]

Thanks, Tobias, for the patch and NMU.
I have pushed your changes to ou git.

Ghis, if you have a fixed reproducibility, please push it
to git and I will upload a new version with both changes.

Regards

Anton

2016-01-25 14:57 GMT+01:00 Ghislain Vaillant :

> I was about to submit an update for the reproducibility problem. I can
> prepare a proper update with your patch in it.
>
> How does that sound?
>
> Ghis
>
>
>
> On Fri, 22 Jan 2016 06:33:52 +0100 Tobias Frost  wrote:
>
>> Control: tags 742560 + patch
>> Control: tags 742560 + pending
>>
>> Dear maintainer,
>>
>> I've prepared an NMU for freeimage (versioned as 3.17.0+ds1-1.1) and
>> uploaded it to DELAYED/7. Please feel free to tell me if I
>> should delay it longer.
>>
>> Regards.
>> diff -Nru freeimage-3.17.0+ds1/debian/changelog
>> freeimage-3.17.0+ds1/debian/changelog
>> --- freeimage-3.17.0+ds1/debian/changelog   2016-01-18
>> 08:33:50.0 +0100
>> +++ freeimage-3.17.0+ds1/debian/changelog   2016-01-22
>> 06:12:59.0 +0100
>> @@ -1,3 +1,10 @@
>> +freeimage (3.17.0+ds1-1.1) UNRELEASED; urgency=medium
>> +
>> +  * Non-maintainer upload.
>> +  * Fix FTBFS with libpng16 to help preparing the libpng16 transition.
>> +
>> + -- Tobias Frost   Fri, 22 Jan 2016 06:12:17 +0100
>> +
>>  freeimage (3.17.0+ds1-1) unstable; urgency=medium
>>
>>* Move from experimental to unstable.
>> diff -Nru freeimage-3.17.0+ds1/debian/patches/libpng16.patch
>> freeimage-3.17.0+ds1/debian/patches/libpng16.patch
>> --- freeimage-3.17.0+ds1/debian/patches/libpng16.patch  1970-01-01
>> 01:00:00.0 +0100
>> +++ freeimage-3.17.0+ds1/debian/patches/libpng16.patch  2016-01-22
>> 06:10:39.0 +0100
>> @@ -0,0 +1,34 @@
>> +--- a/Source/FreeImage/PluginPNG.cpp
>>  b/Source/FreeImage/PluginPNG.cpp
>> +@@ -713,11 +713,19 @@
>> +
>> +   if (png_get_valid(png_ptr, info_ptr,
>> PNG_INFO_iCCP)) {
>> +   png_charp profile_name = NULL;
>> ++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
>> ++  png_bytepp profile_data = NULL;
>> ++#else
>> +   png_charp profile_data = NULL;
>> ++#endif
>> +   png_uint_32 profile_length = 0;
>> +   int  compression_type;
>> +
>> ++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
>> ++  png_get_iCCP(png_ptr, info_ptr,
>> _name, _type, profile_data, _length);
>> ++#else
>> +   png_get_iCCP(png_ptr, info_ptr,
>> _name, _type, _data, _length);
>> ++#endif
>> +
>> +   // copy ICC profile data (must be done
>> after FreeImage_AllocateHeader)
>> +
>> +@@ -1000,7 +1008,11 @@
>> +
>> +   FIICCPROFILE *iccProfile =
>> FreeImage_GetICCProfile(dib);
>> +   if (iccProfile->size && iccProfile->data) {
>> ++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
>> ++  //png_set_iCCP(png_ptr, info_ptr,
>> "Embedded Profile", 0, (png_const_bytep)iccProfile->data, iccProfile->size);
>> ++#else
>> +   png_set_iCCP(png_ptr, info_ptr, "Embedded
>> Profile", 0, (png_charp)iccProfile->data, iccProfile->size);
>> ++#endif
>> +   }
>>
>
> --
> debian-science-maintainers mailing list
> debian-science-maintain...@lists.alioth.debian.org
>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
>

Bug#812606: RM: ruby-integration/0.1.0-1

[Christian Hofstaedtler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm

Hi,

ruby-integration Build-Depends on ruby-gsl, which is not in testing.
(Also nobody seems to be working on fixing ruby-gsl for it to reenter
testing.)

Thanks,
Christian

Bug#812567: qtcreator: Crash editor

[Adam Majer]

On Mon, Jan 25, 2016 at 08:05:41AM +0300, ioann sys wrote:
> 
> Hello! After some time, my QtCreator has been crashed whith info:
> [ 3959.336949] Thread (pooled)[2408]: segfault at 7f4ea8002ff8 ip
> 7f4eb7d1cdcf sp 7f4ea8002ff0 error 6 in
> libCPlusPlus.so.1.0.0[7f4eb7b8e000+22a000]
> [ 7942.967980] TextEditor::Int[4078]: segfault at 7fd2f5530fb0 ip
> 7fd329f184dc sp 7fd2f5530fa0 error 6 in
> libc-2.21.so[7fd329ea+19a000]
> 
> And autocomlectation code very slow.


Can you get a proper backtrace? Install qtcreator-gdb for that.

Also, can you get a repliable way of reproducing this crash?

What is autocomlectation? Autocompletion?


-- 
Adam Majer
ad...@zombino.com

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[Michal Suchanek]

On 25 January 2016 at 03:05, adrian15  wrote:
> El 24/01/16 a las 16:51, Michal Suchanek escribió:

> What you are describing here is what it's actually implemented in my patch
> (Well, actually the first patch version because the current one enforces
> bootloader roles).

Actually, no.

Nowhere in the description is any bootloader designated primary or
secondary or first or second. On purpose.

> So what about primary and secondary terms? Or first or
> second terms?

Both are broken and confusing.

>
> These terms are used in two places:
> * Internal variables and functions to handle bootloaders
> * Information shown to the final user
>
> I'm most convinced to use the first and non-first notation. So that the old
> code that referred to LB_BOOTLOADER can just refer to: LB_FIRST_BOOTLOADER.

For what piece of code we have does it make sense to reference
LB_FIRST_BOOTLOADER when not also referencing LB_SECOND_BOOTLOADER?
Will that be extended to LB_THIRD_BOOTLOADER once x86 grows support
for coreboot or l-b grows support for some other platform with many
firmware variants?

If you set bootloaders like

LB_BOOTLOADERS="syslinux grub-efi"

then you can just do

for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo

after you check that you have at most two bootloaders and if you have
more than one then only the latter one ends with -efi.

Thanks

Michal

Bug#662273: autotrace: diff for NMU version 0.31.1-16+nmu1.1

[Tobias Frost]

Dear maintainer,

I've prepared an NMU for autotrace (versioned as 0.31.1-16+nmu1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru autotrace-0.31.1/debian/changelog autotrace-0.31.1/debian/changelog
--- autotrace-0.31.1/debian/changelog   2014-12-16 23:24:46.0 +0100
+++ autotrace-0.31.1/debian/changelog   2016-01-25 12:33:31.0 +0100
@@ -1,3 +1,12 @@
+autotrace (0.31.1-16+nmu1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixes for the libpng 1.6 library transition: (Closes: #662273)
+  - Build-Depends on libpng-dev, instead of libpng12-dev
+  - Add patch from Fedora for the library's API
+
+ -- Tobias Frost   Mon, 25 Jan 2016 12:32:10 +0100
+
 autotrace (0.31.1-16+nmu1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru autotrace-0.31.1/debian/control autotrace-0.31.1/debian/control
--- autotrace-0.31.1/debian/control 2011-08-08 02:40:01.0 +0200
+++ autotrace-0.31.1/debian/control 2016-01-25 13:19:13.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Edgar Antonio Palma de la Cruz 
 Build-Depends: debhelper (>= 8), autotools-dev, pkg-config,
-   libpng12-dev, libpstoedit-dev (>= 3.42-1.1), 
+   libpng-dev, libpstoedit-dev (>= 3.42-1.1),
libmagickcore-dev, dh-autoreconf
 Standards-Version: 3.9.2
 Homepage: http://autotrace.sourceforge.net/
@@ -25,7 +25,7 @@
 Description: bitmap to vector graphics converter, shared library files
  Runtime shared library files needed by programs that link with the
  AutoTrace bitmap-to-vector graphics converter.
- About the usage of the library 
+ About the usage of the library
  see http://autotrace.sourceforge.net/frontline
 
 
diff -Nru autotrace-0.31.1/debian/patches/libpng16.patch 
autotrace-0.31.1/debian/patches/libpng16.patch
--- autotrace-0.31.1/debian/patches/libpng16.patch  1970-01-01 
01:00:00.0 +0100
+++ autotrace-0.31.1/debian/patches/libpng16.patch  2016-01-25 
12:43:34.0 +0100
@@ -0,0 +1,61 @@
+Description: Fix for libpng 1.6
+ libpng1.6 hides some implementation details, getters/setters are now to be 
uded.
+Origin: 
http://pkgs.fedoraproject.org/cgit/rpms/autotrace.git/plain/autotrace-0.31.1-libpng15.patch?id=0fbea0205eddba3b39fcf17ac91984dd2aa5ab1e
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662273
+Last-Update: 2016-01-25 by t...@debian.org
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/input-png.c
 b/input-png.c
+@@ -42,7 +42,7 @@
+ 
+ static void handle_warning(png_structp png, const at_string message) {
+ LOG1("PNG warning: %s", message);
+-  at_exception_warning((at_exception_type *)png->error_ptr,
++  at_exception_warning((at_exception_type *)png_get_error_ptr(png),
+message);
+   /* at_exception_fatal((at_exception_type *)at_png->error_ptr,
+  "PNG warning"); */
+@@ -50,7 +50,7 @@
+ 
+ static void handle_error(png_structp png, const at_string message) {
+   LOG1("PNG error: %s", message);
+-  at_exception_fatal((at_exception_type *)png->error_ptr,
++  at_exception_fatal((at_exception_type *)png_get_error_ptr(png),
+  message);
+   /* at_exception_fatal((at_exception_type *)at_png->error_ptr,
+  "PNG error"); */
+@@ -157,8 +157,8 @@
+ 
+   png_set_strip_16(png_ptr);
+   png_set_packing(png_ptr);
+-  if ((png_ptr->bit_depth < 8) ||
+-  (png_ptr->color_type == PNG_COLOR_TYPE_PALETTE) ||
++  if ((png_get_bit_depth(png_ptr, info_ptr) < 8) ||
++  (png_get_color_type(png_ptr, info_ptr) == PNG_COLOR_TYPE_PALETTE) ||
+   (png_get_valid(png_ptr, info_ptr, PNG_INFO_tRNS)))
+   png_set_expand(png_ptr);
+ 
+@@ -181,20 +181,10 @@
+  PNG_BACKGROUND_GAMMA_FILE, 1, 1.0);
+   } else
+   png_set_strip_alpha(png_ptr);
++  png_set_interlace_handling(png_ptr);
+   png_read_update_info(png_ptr, info_ptr);
+ 
+-
+-  info_ptr->row_pointers = (png_bytepp)png_malloc(png_ptr,
+-  info_ptr->height * 
sizeof(png_bytep));
+-#ifdef PNG_FREE_ME_SUPPORTED
+-  info_ptr->free_me |= PNG_FREE_ROWS;
+-#endif
+-  for (row = 0; row < (int)info_ptr->height; row++)
+-  info_ptr->row_pointers[row] = (png_bytep)png_malloc(png_ptr,
+-  
png_get_rowbytes(png_ptr, info_ptr));
+-  
+-  png_read_image(png_ptr, info_ptr->row_pointers);
+-  info_ptr->valid |= PNG_INFO_IDAT;
++  png_read_png(png_ptr, info_ptr, PNG_TRANSFORM_IDENTITY, NULL);
+   png_read_end(png_ptr, info_ptr);
+   return png_get_rows(png_ptr, info_ptr);
+ }
diff -Nru autotrace-0.31.1/debian/patches/series 
autotrace-0.31.1/debian/patches/series
--- 

Bug#742560: freeimage: diff for NMU version 3.17.0+ds1-1.1

[Ghislain Vaillant]

I was about to submit an update for the reproducibility problem. I can 
prepare a proper update with your patch in it.


How does that sound?

Ghis


On Fri, 22 Jan 2016 06:33:52 +0100 Tobias Frost  wrote:

Control: tags 742560 + patch
Control: tags 742560 + pending

Dear maintainer,

I've prepared an NMU for freeimage (versioned as 3.17.0+ds1-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru freeimage-3.17.0+ds1/debian/changelog 
freeimage-3.17.0+ds1/debian/changelog
--- freeimage-3.17.0+ds1/debian/changelog   2016-01-18 08:33:50.0 
+0100
+++ freeimage-3.17.0+ds1/debian/changelog   2016-01-22 06:12:59.0 
+0100
@@ -1,3 +1,10 @@
+freeimage (3.17.0+ds1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with libpng16 to help preparing the libpng16 transition.
+
+ -- Tobias Frost   Fri, 22 Jan 2016 06:12:17 +0100
+
 freeimage (3.17.0+ds1-1) unstable; urgency=medium

   * Move from experimental to unstable.
diff -Nru freeimage-3.17.0+ds1/debian/patches/libpng16.patch 
freeimage-3.17.0+ds1/debian/patches/libpng16.patch
--- freeimage-3.17.0+ds1/debian/patches/libpng16.patch  1970-01-01 
01:00:00.0 +0100
+++ freeimage-3.17.0+ds1/debian/patches/libpng16.patch  2016-01-22 
06:10:39.0 +0100
@@ -0,0 +1,34 @@
+--- a/Source/FreeImage/PluginPNG.cpp
 b/Source/FreeImage/PluginPNG.cpp
+@@ -713,11 +713,19 @@
+
+   if (png_get_valid(png_ptr, info_ptr, PNG_INFO_iCCP)) {
+   png_charp profile_name = NULL;
++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
++  png_bytepp profile_data = NULL;
++#else
+   png_charp profile_data = NULL;
++#endif
+   png_uint_32 profile_length = 0;
+   int  compression_type;
+
++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
++  png_get_iCCP(png_ptr, info_ptr, _name, 
_type, profile_data, _length);
++#else
+   png_get_iCCP(png_ptr, info_ptr, _name, 
_type, _data, _length);
++#endif
+
+   // copy ICC profile data (must be done after 
FreeImage_AllocateHeader)
+
+@@ -1000,7 +1008,11 @@
+
+   FIICCPROFILE *iccProfile = FreeImage_GetICCProfile(dib);
+   if (iccProfile->size && iccProfile->data) {
++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
++  //png_set_iCCP(png_ptr, info_ptr, "Embedded Profile", 
0, (png_const_bytep)iccProfile->data, iccProfile->size);
++#else
+   png_set_iCCP(png_ptr, info_ptr, "Embedded Profile", 
0, (png_charp)iccProfile->data, iccProfile->size);
++#endif
+   }

Bug#812633: [Pkg-utopia-maintainers] Bug#812633: network-manager-openvpn: Failure to add server pushed route

[Jamie McClelland]

> > This appears to be fixed upstream:
> > 
> > http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=11aa07ed939193e85516c287a57dee1837242972
> 
> It's supposed to be a bug in network-manager, not network-manager-openvpn.
> 
> Please test again with network-manager 1.0.10-2.

Thank you! This can be closed. Upgrading to network-manager 1.0.10-2 fixes the 
problem.

jamie





signature.asc
Description: PGP signature

Bug#812653: bpython: FTBFS - UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4811: ordinal not in range(128)

[Sebastian Ramacher]

Control: tags -1 + moreinfo unreproducible

On 2016-01-25 18:23:59, Michael Tautschnig wrote:
> Package: bpython
> Version: 0.15-1
> Severity: serious
> Usertags: goto-cc
> 
> During a rebuild of all Debian packages in a clean sid chroot (using 
> cowbuilder
> and pbuilder) the build failed with the following error.
> 
> [...]
> running compile_catalog
> Traceback (most recent call last):
>   File "setup.py", line 292, in 
> test_suite='bpython.test'
>   File "/usr/lib/python3.4/distutils/core.py", line 148, in setup
> dist.run_commands()
>   File "/usr/lib/python3.4/distutils/dist.py", line 955, in run_commands
> self.run_command(cmd)
>   File "/usr/lib/python3.4/distutils/dist.py", line 974, in run_command
> cmd_obj.run()
>   File "/usr/lib/python3.4/distutils/command/build.py", line 126, in run
> self.run_command(cmd_name)
>   File "/usr/lib/python3.4/distutils/cmd.py", line 313, in run_command
> self.distribution.run_command(command)
>   File "/usr/lib/python3.4/distutils/dist.py", line 974, in run_command
> cmd_obj.run()
>   File "/usr/lib/python3/dist-packages/babel/messages/frontend.py", line 134, 
> in run
> catalog = read_po(infile, locale)
>   File "/usr/lib/python3/dist-packages/babel/messages/pofile.py", line 205, 
> in read_po
> for lineno, line in enumerate(fileobj.readlines()):
>   File "/usr/lib/python3.4/encodings/ascii.py", line 26, in decode
> return codecs.ascii_decode(input, self.errors)[0]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 4811: 
> ordinal not in range(128)
> E: pybuild pybuild:274: build: plugin distutils failed with: exit code=1: 
> /usr/bin/python3.4 setup.py build
> dh_auto_build: pybuild --build -i python{version} -p 3.4 3.5 --dir . returned 
> exit code 13
> debian/rules:8: recipe for target 'build' failed
> make: *** [build] Error 25
> 
> 
> The full build log is attached; please do let me know if the problem is
> unreproducible, in which case I shall try to investigate further.

I cannot reproduce the issue with sbuild. But I suspect there might be something
different with respect to the locales setup. Could you test if the build success
if LANG is set to en_US.utf8?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#812488: libsms-send-perl: After upgrade: Can't send SMS: 500 Can't connect to api.twilio.com:443 (certificate verify failed)

[Niko Tyni]

On Mon, Jan 25, 2016 at 08:12:03PM +0100, gregor herrmann wrote:
> On Sun, 24 Jan 2016 19:29:14 -0600, Michael Shuler wrote:

> > $ openssl s_client -CApath /etc/ssl/certs -connect api.twillio.com:443

The report is about api.twilio.com, not api.twillio.com.
It's perfectly reproducible for me, with both libwww-perl and curl.

 % curl https://api.twilio.com/
 curl: (60) SSL certificate problem: self signed certificate in certificate 
chain
 More details here: http://curl.haxx.se/docs/sslcerts.html

The certificate chain returned by the site is

 0 s:/C=US/ST=California/L=San Francisco/O=Twilio, Inc./OU=api/CN=*.twilio.com
   i:/C=US/O=thawte, Inc./CN=thawte SSL CA - G2

 1 s:/C=US/O=thawte, Inc./CN=thawte SSL CA - G2
   i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 
thawte, Inc. - For authorized use only/CN=thawte Primary Root CA

 2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 
thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification 
Services Division/CN=Thawte Premium Server 
CA/emailAddress=premium-ser...@thawte.com

 3 s:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification 
Services Division/CN=Thawte Premium Server 
CA/emailAddress=premium-ser...@thawte.com
   i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification 
Services Division/CN=Thawte Premium Server 
CA/emailAddress=premium-ser...@thawte.com

and the last one ("Thawte Premium Server CA") was apparently removed
in the ca-certificates update. However, a self signed version of the
previous certificate in the chain, "thawte Primary Root CA", is still
present AFAICS.

What I don't quite understand is why this works on unstable
(ca-certificates 20160104) but not stable, with no differences in the
relevant certificates that I can see. Perhaps openssl is behaving
differently?

Hope this helps a bit,
-- 
Niko Tyni   nt...@debian.org

Bug#650601: libpng is ready for transtion

[Tobias Frost]

Dear release-team,

Now that all NMUs are in DELAYED for all fixables.
I think we are ready to throw the switch. 

Please let us know and assign us the transition slot :)

Please assign a slot.

Here's the actual summary [1]
Built: 474
Failed: 34
OK: 440

The failed ones split up as follow:

NMUs: 12  
Patches: 2  
RC Buggy: 13  
RC as B-D: 4 
RM: 2
(my package: 1)

- The NMUs are uploaded, waiting to enter the archives.
- Also Gianfranco uploaded tons of packages to update the B-D to
libpng-dev. 
- The two patches are submitted to the BTS with a review request. A NMU
will follow...
- The RC Buggy packages are not building in sid as well, no way to
check them without fixing them.
- 4 Packages B-D on libvigraimpex, which is one of the RC packages.
- 2 packages are to be removed
- 1 package is mine, fix in prepration (rbdoom3bfg)


Details:

NMU in DELAYED - 12
==
antigrav
autotrace
ctsim
exult
freeimage
pngnq
literki
libtwin
nagios3
openlayer
scorched3d
xaos

Patch available (review requested):  2

netpbm-free
ghostscript


RC-Buggy in sid: - 13

blender
calligra
caret
criticalmass
fw4spl
libvigraimpex
odin
openvrml
libtk-img
root-system
wine-development
xemacs21
yt


reverse B-Ds libvigraimpex: - 4


===
3depict
enblend-enfuse
gamera
hugin

RM or RM requested: - 2
===
exrtools
celestia


the remaining:
===
rbdoom3bfg
is my package, a patch is almost ready.

[1] http://libpng.sviech.de/!summary.txt
The file in the link will be updated as I rebuild package when uploads
have been done; (manual process)


-- tobi

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

Bug#812666: RM: lynx-cur -- ROM; renamed to and replaced by "lynx"

[Axel Beckert]

Package: ftp.debian.org
Severity: normal

Hi,

we renamed the "lynx-cur" source package back to "lynx" while building
the same binary packages (and some more).

So please remove the now obsolete "lynx-cur" source package from
Debian Unstable.

TIA!

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

Bug#811146: [pkg-gnupg-maint] Bug#811146: gnupg2: gpg2.1 failing to handle hkps keyservers

[Daniel Kahn Gillmor]

Hi Phil--

On Fri 2016-01-15 23:07:53 -0500, Phil Dibowitz wrote:
> Sometime recently gpg2.1 stopped handling HKPS keyservers. dirmngr can
> still do it if I ask directly, but gpg2.1 won't. All of the debug info I
> can think of is below.
>
> Relevant ~/.gnupg/gpg.conf lines:
>
>   keyserver hkps://hkps.pool.sks-keyservers.net
>   keyserver-options auto-key-retrieve no-honor-keyserver-url include-revoked
>
> Relevant ~/.gnupg/dirmngr.conf lines:
>
>   hkp-cacert /usr/local/share/ca-certificates/sks-keyservers.netCA.pem
>
> When I try through gpg (first without debug for clarity) I get:
>
>   $ gpg --search-key 58E11BB1E414D9AD
>   gpg: error searching keyserver: General error
>   gpg: keyserver search failed: General error


this looks like gpg, since the 2.1 series is currently provided as
/usr/bin/gpg2.

what does gpg --version tell you?

gpg 2.1 never talks to the network itself at all; it relies entirely on
dirmngr to do that work.

--dkg

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

El 25/01/16 a las 16:12, Michal Suchanek escribió:

On 25 January 2016 at 03:05, adrian15  wrote:

El 24/01/16 a las 16:51, Michal Suchanek escribió:



What you are describing here is what it's actually implemented in my patch
(Well, actually the first patch version because the current one enforces
bootloader roles).


Actually, no.

Nowhere in the description is any bootloader designated primary or
secondary or first or second. On purpose.
Neither it is on my patch (initial implementation). Yes, the term 
PRIMARY_BOOTLOADER is used there for reusing old code. But using:


--bootloaders=syslinux,grub-efi

did not enforce syslinux to be in the first place or grub-efi to be in 
the second place.


That's the specific part I meant.




So what about primary and secondary terms? Or first or
second terms?


Both are broken and confusing.

Ok...


These terms are used in two places:
* Internal variables and functions to handle bootloaders
* Information shown to the final user

I'm most convinced to use the first and non-first notation. So that the old
code that referred to LB_BOOTLOADER can just refer to: LB_FIRST_BOOTLOADER.


For what piece of code we have does it make sense to reference
LB_FIRST_BOOTLOADER when not also referencing LB_SECOND_BOOTLOADER?
Will that be extended to LB_THIRD_BOOTLOADER once x86 grows support
for coreboot or l-b grows support for some other platform with many
firmware variants?

If you set bootloaders like

LB_BOOTLOADERS="syslinux grub-efi"

then you can just do

for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo

Mostly what current path does but with commas instead.


after you check that you have at most two bootloaders and if you have
more than one then only the latter one ends with -efi.


This is not a good approach. You are requesting the bootloaders to end 
in "-efi". The current approach is to name them based on the Debian 
package name. These packages do not need to end in "-efi".


My use case is the following one. The final user requests:

--bootloaders=grub-efi,syslinux

so I show him:

"Warning. You are using: syslinux as a non first bootloader. This might 
work but it is not advised."


How do I know that I have to output this message?

Because I compare the internal variable:

LB_FIRST_BOOTLOADER="grub-efi"

with the bootloader name "syslinux" and I see they are not the same one.

So, as you see I need to use:

"non first bootloader" term
and
LB_FIRST_BOOTLOADER variable.

So...

1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER 
to another terminology which makes more technical sense.
2) I prefer this approach over yours (Michal) because it's the own 
bootloader which decides if it is more suited for "first bootloader" or 
not. Let's not repeat the current binary_iso design which has many 
references to the different available binary_bootloaders available.




Thanks

Michal


adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#812589: fsck -M has stopped working

[sacrificial-spam-address]

>> The "802" is the root= argument passed to the kernel by the boot loader.
>> Major device 8, minor 2.  What I don't understand is why libmount thinks
>> it's a file name (in $PWD, no less).

> The boot loader should be passing "/dev/sda2", not "802".  Are you using
> an ancient boot loader ( like the dos linload.com ) or something?

Package: lilo
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 649
Maintainer: Joachim Wiedorn 
Architecture: i386
Version: 1:24.2-1

And regardless of the boot loader, if the kernel is documented as accepting
a root= format, code that parses /proc/cmdlike should handle it gracefully.

At an *absolute* minimum provide a specific error message that a
particular format is not supported, as opposed to implementing RFC 748
and losing randomly.

Bug#812654: libreoffice-writer: if center a portion of text, all text its centered in rest of document!!!!

[Rene Engelhard]

notfound 812654 1:5.0.4~rc2-2~bpo8+1
close 812654
thanks

Hi,

On Mon, Jan 25, 2016 at 01:55:08PM -0430, PICCORO McKAY Lenz wrote:
> Package: libreoffice-writer
> Version: 1:5.0.4~rc2-2~bpo8+1

No. This BTS is NOT for bpo-specific bugs. It doesn't know that versions and
the version tracking gets confused. The package should redirect reports
to debian-backpo...@lists.debian.org where they belong. Unless there is
a bug there in that version.

> Severity: grave
> Justification: causes non-serious data loss

This makes no sense. Even if this was a bug, it doesn't cause data loss. Just
loss of (bogus) formatting.

> The writter (and i noted all of LO, if a portion of text selected or
> where cursor are)
> its toggle to aling centered, all the rest of the text in rest of the document
> event its not selected are centered too

No.

>* What led up to the situation?
> writing i want to center a piece of text and the rest its also centered
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> writing i want to center a piece of text and the rest its also centered
> the text selected was using the "default" style, as rest of text not selected.

And probably the same paragraph, too...

>* What was the outcome of this action?
> text not selected are centered too
> 
>* What outcome did you expect instead?
> only center the line where the text was selected or cursor are positioned

That's not how it works. Center in writer affects the _paragraph_. Anything else
("center a random part of a sentence" inside a block doesn't make sense. Where
to center if it's inside a surrounding text?)

If you used hard formatting (like Shift-Return) without proper paragraphs your
scenario happens because it then "officially" is ONE paragraph.

Use proper formatting and paragraphs and maybe learn word processor basics

Closing this.

Regards,

Rene

Bug#812674: RM: qdox/experimental -- ROM; qdox 2.0 is packaged in src:qdox2

[Markus Koschany]

Package: ftp.debian.org
Severity: normal

Hello,

QDox 2 is now available in a separate package src:qdox2. We
don't intend to package new releases of QDox in src:qdox because they
are incompatible with older versions. Therefore please remove version
2.0-M3-1 in experimental.

Regards,

Markus

Bug#743404: #743404 RFP: eslint -- tool for static analysis of ECMAScript (JavaScript™) code

[Daniel Kahn Gillmor]

Hi debian javascript maintainers--

in https://bugs.debian.org/743404, Ben Finney  
wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: eslint
>   Version : 0.4.5
>   Upstream Author : Nicholas C. Zakas 
> * URL : http://eslint.org/
> * License : Expat (MIT)
>   Programming Lang: ECMAScript
>   Description : tool for static analysis of ECMAScript (JavaScript™) code
>
> ESLint is a tool for identifying and reporting on patterns found in
> ECMAScript (JavaScript™) code. It performs static code analysis to find
> common and likely mistakes.
> .
> In many ways, it is similar to JSLint and JSHint with a few exceptions:
> .
> * ESLint uses Esprima for JavaScript parsing.
> * ESLint uses an AST to evaluate patterns in code.
> * ESLint is completely pluggable, every single rule is a plugin and you
>   can add more at runtime.
>
> One reason this package is attractive for ECMAScript developers is because
> it is a DFSG-free licensed linter; the two most popular linters, JSLint and
> JSHint, both have non-free licenses that prevent their inclusion in Debian.


Is anyone in the javascript team up for packaging this?  It appears to
available in npm, fwiw.

Enigmail is now using eslint upstream as part of the test suite (they've
switched to it from jshint to avoid the crappy jshint license), and i'd
love to be able to run the full test suite from within debian during
enigmail package builds.

 --dkg

Bug#812665: git-buildpackage: after building with --git-pbuilder, gbp fails to call debsign

[Sean Whitton]

Package: git-buildpackage
Version: 0.7.1
Severity: normal

Dear Maintainer,

When building a package with the --git-pbuilder option, gbp fails to
invoke debsign to sign the .changes and .dsc files.  By contrast, when
building without --git-pbuilder, debsign is invoked automatically.

In one case gbp signed the .dsc file but not the .changes file, though
I haven't been able to reproduce this.

Full output attached.

Thanks.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: i386 (i686)

Kernel: Linux 4.3.0-1-686-pae (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 git-buildpackage depends on:
ii  devscripts2.15.10
ii  git   1:2.7.0~rc3-1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
ii  python-pkg-resources  18.8-1
ii  python-six1.10.0-1
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.78
ii  pbuilder 0.222
ii  pristine-tar 1.33
ii  python-requests  2.9.1-1

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  sudo   1.8.15-1.1
ii  unzip  6.0-20

-- no debconf information

-- 
Sean Whitton
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: /bin/true [] []
gbp:debug: ['git', 'status', '--porcelain']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'HEAD']
gbp:debug: ['git', 'ls-tree', 'HEAD']
gbp:debug: ['git', 'show', '--pretty=medium', 'HEAD:debian/changelog']
gbp:debug: ['git', 'show', '--pretty=medium', 
'HEAD:debian/source/format']
gbp:info: Exporting 'HEAD' to '/home/swhitton/local/debuild/flx-tmp'
gbp:debug: ['git', 'show', '--pretty=medium', 
'HEAD:debian/source/format']
gbp:info: Moving '/home/swhitton/local/debuild/flx-tmp' to 
'/home/swhitton/local/debuild/flx-0.6.1'
gbp:debug: ['git', 'show', '--pretty=medium', 
'HEAD:debian/source/format']
gbp:debug: ['git', 'show', '--pretty=medium', 
'HEAD:debian/source/format']
gbp:info: Building with (cowbuilder) for sid
gbp:debug: git-pbuilder [] []
Building with cowbuilder for distribution sid
W: The configuration option DEBEMAIL is deprecated.  Please pass the required 
options to DEBBUILDOPTS (--debbuildopts command line flag) instead.
W: DEBEMAIL='spwhit...@spwhitton.name' is ignored!
W: The configuration option DEBEMAIL is deprecated.  Please pass the required 
options to DEBBUILDOPTS (--debbuildopts command line flag) instead.
W: DEBEMAIL='spwhit...@spwhitton.name' is ignored!
W: /home/swhitton/.pbuilderrc does not exist
W: The configuration option DEBEMAIL is deprecated.  Please pass the required 
options to DEBBUILDOPTS (--debbuildopts command line flag) instead.
W: DEBEMAIL='spwhit...@spwhitton.name' is ignored!
I: using cowbuilder as pbuilder
dpkg-checkbuilddeps: error: Unmet build dependencies: elpa-async (>= 1.4)
W: Unmet build-dependency in source
dpkg-buildpackage: source package flx
dpkg-buildpackage: source version 0.6.1-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Sean Whitton 
 dpkg-source --before-build flx-0.6.1
dpkg-source: info: using options from flx-0.6.1/debian/source/local-options: 
--single-debian-patch --unapply-patches
dpkg-source: info: applying 0001-patch-README.patch
dpkg-source: info: applying 0002-fix-tests.patch
dpkg-source: info: applying 0003-dummy-upstream-changelog.patch
 fakeroot debian/rules clean
dh clean --parallel --with elpa
   dh_testdir
   dh_auto_clean
make -j1 clean
make[1]: Entering directory '/home/swhitton/local/debuild/flx-0.6.1'
rm -f flx.elc flx-ido.elc 
make[1]: Leaving directory '/home/swhitton/local/debuild/flx-0.6.1'
   dh_clean
 dpkg-source -b flx-0.6.1
dpkg-source: info: using options from flx-0.6.1/debian/source/local-options: 
--single-debian-patch --unapply-patches
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building flx using existing ./flx_0.6.1.orig.tar.xz
dpkg-source: info: building flx in flx_0.6.1-1.debian.tar.xz
dpkg-source: info: building flx in flx_0.6.1-1.dsc
 dpkg-genchanges -S >../flx_0.6.1-1_source.changes
dpkg-genchanges: including full source code in upload
 dpkg-source --after-build flx-0.6.1
dpkg-source: info: using options from flx-0.6.1/debian/source/local-options: 
--single-debian-patch --unapply-patches
dpkg-source: info: unapplying 0003-dummy-upstream-changelog.patch
dpkg-source: info: unapplying 0002-fix-tests.patch
dpkg-source: info: unapplying 0001-patch-README.patch
dpkg-buildpackage: full upload 

Bug#807669: dh-strip-nondeterminism: Breaks some jar file

[Raphael Hertzog]

Control: severity -1 important

On Mon, 14 Dec 2015, Raphael Hertzog wrote:
> Your analysis is correct but dh_strip_nondeterminisn should detect the
> signature and avoid messing up with the file in that case.
> 
> That's what this bug is about.

And we got another case where dh_strip_nondeterminism actually broke a
working package... https://bugs.kali.org/view.php?id=3019

Is there anything we can do to ensure that this bug gets a timely fix?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#812668: mailfilter: FTBFS - error: no match for 'operator='

[Michael Tautschnig]

Package: mailfilter
Version: 0.8.3-1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
Making all in src
make[3]: Entering directory 
'/srv/jenkins-slave/workspace/sid-goto-cc-mailfilter/mailfilter-0.8.3/src'
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include -I. -I../include -I.. 
-DLOCALEDIR=\"/usr/share/locale\" -I../intl -I.. -I../include -I.  -Wdate-time  
-g -O0 -fstack-protector-strong -Wformat -Werror=format-security -c -o md5c.o 
md5c.c
bison -y -p rc -d -v -oy.tab.c rcfile.yy;   \
   mv -f y.tab.c rcparser.cc; \
   mv -f y.tab.h rcparser.hh; \
   g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include -I. -I../include -I.. 
-DLOCALEDIR=\"/usr/share/locale\" -I../intl -I.. -I../include -I.  -Wdate-time 
-Wall -g -O0 -fstack-protector-strong -Wformat -Werror=format-security -c 
rcparser.cc;  \
   touch y.tab.c
flex -+ -i -Prc -orcfile.cc rcfile.ll
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include -I. -I../include -I.. 
-DLOCALEDIR=\"/usr/share/locale\" -I../intl -I.. -I../include -I.  -Wdate-time 
-Wall -g -O0 -fstack-protector-strong -Wformat -Werror=format-security -c -o 
rcfile.o rcfile.cc
rcfile.ll: In member function 'virtual int rcFlexLexer::yylex()':
rcfile.ll:150:14: error: no match for 'operator=' (operand types are 
'std::istream {aka std::basic_istream}' and 'std::ifstream* {aka 
std::basic_ifstream*}')
 yyin = new ifstream (sub_file.c_str ());
  ^
In file included from /usr/include/c++/5/iostream:40:0,
 from rcfile.cc:96:
/usr/include/c++/5/istream:58:11: note: candidate: std::basic_istream& 
std::basic_istream::operator=(const std::basic_istream&)
 class basic_istream : virtual public basic_ios<_CharT, _Traits>
   ^
/usr/include/c++/5/istream:58:11: note:   no known conversion for argument 1 
from 'std::ifstream* {aka std::basic_ifstream*}' to 'const 
std::basic_istream&'
rcfile.ll:152:27: error: invalid cast from type 'std::istream {aka 
std::basic_istream}' to type 'std::ifstream* {aka 
std::basic_ifstream*}'
 if (!((ifstream*) yyin)->is_open ())
   ^
Makefile:459: recipe for target 'rcfile.o' failed
make[3]: *** [rcfile.o] Error 1


The full build log is attached; please do let me know if the problem is
unreproducible, in which case I shall try to investigate further.

Best,
Michael


mailfilter-build-log.txt.gz
Description: application/gunzip


signature.asc
Description: PGP signature

Bug#812672: djangorestframework: FTBFS - TypeError: a bytes-like object is required, not 'str'

[Michael Tautschnig]

Package: djangorestframework
Version: 3.3.2-1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
# Build the HTML documentation.
mkdir 
/srv/jenkins-slave/workspace/sid-goto-cc-djangorestframework/djangorestframework-3.3.2/docs.debian
LANG=C.UTF-8 mkdocs build && mv site docs.debian/html
Traceback (most recent call last):
  File "/usr/bin/mkdocs", line 9, in 
load_entry_point('mkdocs==0.14.0', 'console_scripts', 'mkdocs')()
  File "/usr/lib/python3/dist-packages/click/core.py", line 716, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 675, in main
_verify_python3_env()
  File "/usr/lib/python3/dist-packages/click/_unicodefun.py", line 69, in 
_verify_python3_env
if locale.lower().endswith(('.utf-8', '.utf8')):
TypeError: a bytes-like object is required, not 'str'
debian/rules:12: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 1


The full build log is attached; please do let me know if the problem is
unreproducible, in which case I shall try to investigate further.

Best,
Michael


djangorestframework-build-log.txt.gz
Description: application/gunzip


signature.asc
Description: PGP signature

Bug#812671: doc-base: FTBFS - nsgmls: not found

[Michael Tautschnig]

Package: doc-base
Version: 0.10.6
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
make[2]: Entering directory 
'/srv/jenkins-slave/workspace/sid-goto-cc-doc-base/doc-base-0.10.6'
*** Making ./_build ...
*** Making ./_build/install-docs ...
*** Making ./_build/man/man8/install-docs.8 ...
*** Making ./_build/install-docs.html ...
 Making ./doc/_build ...
 Making ./doc/_build/doc-base.sgml ...
 Making ./doc/_build/version.ent ...
 Making ./doc/_build/check-stamp ...
/bin/sh: 1: nsgmls: not found
Makefile:26: recipe for target '_build/check-stamp' failed
make[3]: *** [_build/check-stamp] Error 127
common.mk:178: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory 
'/srv/jenkins-slave/workspace/sid-goto-cc-doc-base/doc-base-0.10.6'
dh_auto_build: make -j1 returned exit code 2


The full build log is attached; please do let me know if the problem is
unreproducible, in which case I shall try to investigate further.

Best,
Michael


doc-base-build-log.txt.gz
Description: application/gunzip


signature.asc
Description: PGP signature

Bug#812619: libtm-perl: FTBFS - Failed test 'assertions applying to identical topics are found'

[Michael Tautschnig]

Package: libtm-perl
Version: 1.56-7
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]

#   Failed test 'assertions applying to identical topics are found'
#   at t/043diff.t line 408.
# Comparing hash keys of $data->{"modified"}
# Extra: 'tm:/told'
# Looks like you failed 1 test of 52.
t/043diff.t  
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/52 subtests 
[...]

Test Summary Report
---
t/043diff.t  (Wstat: 256 Tests: 52 Failed: 1)
  Failed test:  52
  Non-zero exit status: 1
t/102mapsphere.t (Wstat: 0 Tests: 41 Failed: 0)
  TODO passed:   25
Files=41, Tests=11410, 54 wallclock secs ( 2.24 usr  0.17 sys + 52.04 cusr  
1.21 csys = 55.66 CPU)
Result: FAIL
Failed 1/41 test programs. 1/11410 subtests failed.
Makefile:1259: recipe for target 'test_dynamic' failed


The full build log is attached; please do let me know if the problem is
unreproducible, in which case I shall try to investigate further.

Best,
Michael


libtm-perl-build-log.txt.gz
Description: application/gunzip


signature.asc
Description: PGP signature

Bug#812541: More information

[Stanimir Stoyanov]

Okay, I removed the usb-autosuspend.conf file and checked out the 
runtime-pm. Well, this is not a bug but a perfectly working program with 
bad configuration...


LM/NOLM_SUSPEND_RUNTIME is set by default to 1 with a timeout of 2 
seconds! This is really wrong and annoying in my opinion for default 
configuration.