Bug#837980: ITP: libdist-zilla-plugin-repository-perl -- Dist::Zilla plugin to discovery repository URL from svn/svk/Git checkout

2016-09-16 Thread Joenio Costa

Package: wnpp
Severity: wishlist
Owner: Joenio Costa 

* Package name: libdist-zilla-plugin-repository-perl
  Version : 0.20
  Upstream Author : Fayland Lam , Ricardo SIGNES 
, Moritz Onken , Christopher J. Madsen 


* URL : https://metacpan.org/pod/Dist::Zilla::Plugin::Repository
* License : Perl
  Programming Lang: Perl
  Description : Dist::Zilla plugin to discovery repository URL from 
svn/svk/Git checkout


Dist::Zilla::Plugin::Repository is a Dist::Zilla plugin to automatically
figure out repository URL and set it on the distribution metadata that 
will be stored in META.yml or META.json.




Bug#837951: tcpdump FTCBFS: fails to pass --host to configure

2016-09-16 Thread Romain Francoise
Hello,

On Thu, Sep 15, 2016 at 10:17:28PM +0200, Helmut Grohne wrote:
> tcpdump fails to cross build from source, because it configures the
> build for the build architecture. To support cross builds, it needs to
> pass --host. The attached patch implements that by replacing the
> explicit ./configure invocation with dh_auto_configure, which happens to
> know what to pass. Please consider applying the patch.

Indeed, thank you for the patch, I will include it in the next upload.

Cheers,
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/



Bug#837983: open-vm-tools: Please announce supported hardware using AppStream

2016-09-16 Thread Petter Reinholdtsen

Package: open-vm-tools
Version: 2:10.0.7-3227872-4
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The open-vm-tools package is one of the packages in the Debian archive that
should be proposed for installation when a given hardware dongle is
inserted or available.  Thanks to the appstream system, this can now be
announced in a way other tools can use and act on.  I've written the
isenkram system to ask the current user if hardware specific packages
should be installed when a new dongle is installed or already present on
a machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
open-vm-tools package, with content similar to this:

  
  
   [...]
   
dmi:*:svnVMWare*:*

  

If there are other USB ids also supposed by the package, please add
those too. :)

-- 
Happy hacking
Petter Reinholdtsen



Bug#837981: gtkpod: Please announce supported hardware using AppStream

2016-09-16 Thread Petter Reinholdtsen

Package: gtkpod
Version: 2.1.5-3
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The gtkpod package is one of the packages in the Debian archive that
should be proposed for installation when a given hardware dongle is
inserted or available.  Thanks to the appstream system, this can now be
announced in a way other tools can use and act on.  I've written the
isenkram system to ask the current user if hardware specific packages
should be installed when a new dongle is installed or already present on
a machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
gtkpod package, with content similar to this:

  
  
   [...]
   
usb:v05ACp1300d*

  

If there are other USB ids also supposed by the package, please add
those too. :)

-- 
Happy hacking
Petter Reinholdtsen



Bug#837890: libqt5sql5-sqlite: /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5Sql_QSQLiteDriverPlugin.cmake is missing

2016-09-16 Thread Paul Labedan
Hi Lisandro Damián Nicanor,

In fact, locating the plugin to ship it on a bundled app is my point: I
build a Qt5 application and I would like to make it available for Wheezy
without backports (some of the machines I'm targeting have limited internet
access and won't have access to backports easily), for this purpose I have
to ship Qt5 libs and plugins within the app.

Regards,
Paul

2016-09-16 2:44 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com>:

> tag 837890 moreinfo
> thanks
>
> Hi Paul!
>
> On jueves, 15 de septiembre de 2016 10:23:31 A. M. ART Paul Labedan wrote:
> [snip]
> > The /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5Sql_
> QSQLiteDriverPlugin.cmake
> > file is missing (it's loaded by
> > /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5SqlConfig.cmake) to populate
> > Qt5::QSQLiteDriverPlugin (which then could be used to locate the plugin
> > withing cmake). I found the issue on debian 8 and 7 with backports, both
> on
> > x86 and amd64.
>
> We are actually proactively removing them for every plugin. The rationale
> is
> that so far we could not find a reason to ship them, as the only use we
> could
> hear of so far is to locate the plugin to be able to ship it on a bundled
> app.
>
> Of course if you have a good reason to ship this CMake files please do not
> heasitate in telling us, so we can reconsider this.
>
> Thanks for your bug report!
>
>
>
> --
> Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>


Bug#837982: mutt: sort order different in sidebar

2016-09-16 Thread Ph. Marek
Package: mutt
Version: 1.7.0-5
Severity: normal

The IMAP folders in the sidebar are ordered differently than those in the 
mbox list on the right (sorted alphanumerically, of course); in the 
sidebar, a "_" is before all alphabetical characters, but in the right
window it is ignored.

Eg., create IMAP folders "_a", "_b", "_c", "a", "b", "c", and the lists 
won't line up.


Thank you!


-- Package-specific info:
NeoMutt 20160910 (1.7.0)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.6.0-1-amd64 (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.0-3' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib 
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo 
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home 
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.0 20160901 (Debian 6.2.0-3) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-eJ8cNY/mutt-1.7.0=. -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-fPIE -pie 
-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-eJ8cNY/mutt-1.7.0=. -fPIE 
-fstack-protector-strong -Wformat -Werror=format-security

Compile options:
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME 
+DEBUG +DL_STANDALONE +ENABLE_NLS -EXACT_ADDRESS -HOMESPOOL -LOCALES_HACK 
-SUN_ATTACHMENT +HAVE_BKGDSET +HAVE_COLOR +HAVE_CURS_SET +HAVE_GETADDRINFO 
+HAVE_GETSID +HAVE_ICONV +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR 
+HAVE_LIBIDN +HAVE_META +HAVE_REGCOMP +HAVE_RESIZETERM +HAVE_START_COLOR 
+HAVE_TYPEAHEAD +HAVE_WC_FUNCS +ICONV_NONTRANS +USE_COMPRESSED +USE_DOTLOCK 
+USE_FCNTL -USE_FLOCK -USE_FMEMOPEN -USE_GNU_REGEX +USE_GSS +USE_HCACHE 
+USE_IMAP +USE_NOTMUCH +USE_NNTP +USE_POP +USE_SASL +USE_SETGID +USE_SIDEBAR 
+USE_SMTP +USE_SSL_GNUTLS -USE_SSL_OPENSSL 
-DOMAIN
MIXMASTER="mixmaster"
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"

patch-attach-headers-color-neomutt
patch-compress-neomutt
patch-cond-date-neomutt
patch-encrypt-to-self-neomutt
patch-fmemopen-neomutt
patch-forgotten-attachments-neomutt
patch-ifdef-neomutt
patch-index-color-neomutt
patch-initials-neomutt
patch-keywords-neomutt
patch-limit-current-thread-neomutt
patch-lmdb-neomutt
patch-multiple-fcc-neomutt
patch-nested-if-neomutt
patch-new-mail-neomutt
patch-nntp-neomutt
patch-notmuch-neomutt
patch-progress-neomutt
patch-quasi-delete-neomutt
patch-reply-with-xorig-neomutt
patch-sensible-browser-neomutt
patch-sidebar-neomutt
patch-skip-quoted-neomutt
patch-smime-encrypt-self-neomutt
patch-status-color-neomutt
patch-timeout-neomutt
patch-tls-sni-neomutt

To learn more about NeoMutt, visit: http://www.neomutt.org/
If you find a bug in NeoMutt, please r

Bug#837629: u-boot 2016.09 in Debian

2016-09-16 Thread Rick Thomas

On Sep 15, 2016, at 10:43 PM, Vagrant Cascadian  wrote:

> Control: severity 837629 serious
> 
> On 2016-09-14, Rick Thomas wrote:
>> On Sep 14, 2016, at 5:31 PM, Vagrant Cascadian  wrote:
>> 
>>> Worst case, we have to remove it from stretch again if it really is that
>>> bad...
>> 
>> I’ll certainly do the test.  If it still doesn’t work on the OpenRD, I
>> would not remove it from stretch just yet.  Frankly, there just aren’t
>> that many OpenRD machines out there, and it works on everything else
>> we’ve tested it on — including my non-ESATA SheevaPlug.  If we can’t
>> fix it for OpenRD, we’ll have to put a warning in NEWS.Debian, but
>> IMHO that’s not a reason for denying its benefits to all the other
>> machine types.
> 
> No, a warning in NEWS.Debian is not good enough; I meant removing the
> targets that "brick" devices. There's no point in shipping something
> known to be broken in ways that cause boot failures.

That would work, too.

> At one point I disabled the OpenRD* targets as it was failing to
> build... now we're in a similar situation, only they fail to boot at all
> even though they build, which is considerably more dangerous...
> 
> Upgrading the severity to prevent migration to stretch, until we have
> a better handle on the situation…

OK.  I’ll do the test ASAP (probably Friday or Saturday).  Please let me know 
if there’s anything else I can do to help get this debugged.  I’ll also try it 
on my OpenRD “Client” machine, incase the problem is specific to that one 
device.

> live well,
>  vagrant



Bug#837984: mysql-server-5.5: mysqld_safe only checks i386/amd64 library path

2016-09-16 Thread NOKUBI Takatsugu
Package: mysql-server-5.5
Version: 5.5.50-0+deb8u1
Severity: important

Dear Maintainer,

mysqld_safe script is not check multiarch library path except i386 and amd64.
This release includes some code checking log filename ended with ".ini" or
".cnf", so I think it is not so serious problem, but it would be better
to fix.

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

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

Versions of packages mysql-server-5.5 depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.56
ii  initscripts2.88dsf-59
ii  libc6  2.19-18+deb8u4
ii  libdbi-perl1.631-3+b1
ii  libgcc11:4.9.2-10
ii  libstdc++6 4.9.2-10
ii  lsb-base   4.1+Debian13+nmu1
ii  mysql-client-5.5   5.5.50-0+deb8u1
ii  mysql-common   5.5.50-0+deb8u1
ii  mysql-server-core-5.5  5.5.50-0+deb8u1
ii  passwd 1:4.2-3+deb8u1
ii  perl   5.20.2-3+deb8u6
ii  psmisc 22.21-2
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages mysql-server-5.5 recommends:
ii  libhtml-template-perl  2.95-1

Versions of packages mysql-server-5.5 suggests:
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-2
pn  tinyca 

-- debconf information excluded



Bug#837985: argyll: Please announce supported hardware using AppStream

2016-09-16 Thread Petter Reinholdtsen

Package: argyll
Version: 1.8.3+repack-2
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The argyll package is one of the packages in the Debian archive that
should be proposed for installation when a given hardware dongle is
inserted or available.  Thanks to the appstream system, this can now be
announced in a way other tools can use and act on.  I've written the
isenkram system to ask the current user if hardware specific packages
should be installed when a new dongle is installed or already present on
a machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
argyll package, with content similar to this:

  
  
   [...]
   
usb:v0403pF208d*
usb:v0670p0001d*
usb:v0765pD020d*
usb:v0765pD092d*
usb:v0765pD094d*
usb:v085Cp0200d*
usb:v085Cp0300d*
usb:v0971p2000d*
usb:v0971p2001d*
usb:v0971p2003d*
usb:v0971p2005d*
usb:v0971p2007d*
usb:v04DBp005Bd*
   
  

If there are other USB ids also supposed by the package, please add
those too. :)

-- 
Happy hacking
Petter Reinholdtsen



Bug#837890: libqt5sql5-sqlite: /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5Sql_QSQLiteDriverPlugin.cmake is missing

2016-09-16 Thread Paul Labedan
tag 837890 moreinfo
thanks

Hi Lisandro Damián Nicanor,

In fact, locating the plugin to ship it on a bundled app is my point: I
build a Qt5 application and I would like to make it available for Wheezy
without backports (some of the machines I'm targeting have limited internet
access and won't have access to backports easily), for this purpose I have
to ship Qt5 libs and plugins within the app.

Regards,
Paul

2016-09-16 2:44 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com>:

> tag 837890 moreinfo
> thanks
>
> Hi Paul!
>
> On jueves, 15 de septiembre de 2016 10:23:31 A. M. ART Paul Labedan wrote:
> [snip]
> > The /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5Sql_
> QSQLiteDriverPlugin.cmake
> > file is missing (it's loaded by
> > /usr/lib/x86_64-linux-gnu/cmake/Qt5Sql/Qt5SqlConfig.cmake) to populate
> > Qt5::QSQLiteDriverPlugin (which then could be used to locate the plugin
> > withing cmake). I found the issue on debian 8 and 7 with backports, both
> on
> > x86 and amd64.
>
> We are actually proactively removing them for every plugin. The rationale
> is
> that so far we could not find a reason to ship them, as the only use we
> could
> hear of so far is to locate the plugin to be able to ship it on a bundled
> app.
>
> Of course if you have a good reason to ship this CMake files please do not
> heasitate in telling us, so we can reconsider this.
>
> Thanks for your bug report!
>
>
>
> --
> Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/
>


Bug#827097: [PATCH] new_security_install: fix ACCEPT file name for binNMUs

2016-09-16 Thread Julien Cristau
Bug#827097

Signed-off-by: Julien Cristau 
---
 dak/new_security_install.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/dak/new_security_install.py b/dak/new_security_install.py
index 7d4603d..d37127d 100755
--- a/dak/new_security_install.py
+++ b/dak/new_security_install.py
@@ -174,7 +174,9 @@ def main():
 # strip epoch from version
 version=dbchange.version
 version=version[(version.find(':')+1):]
-acceptfilename="%s/COMMENTS/ACCEPT.%s_%s" % 
(os.path.dirname(os.path.abspath(changes[0])), dbchange.source, version)
+# strip possible version from source (binNMUs)
+source = dbchange.source.split(None, 1)[0]
+acceptfilename="%s/COMMENTS/ACCEPT.%s_%s" % 
(os.path.dirname(os.path.abspath(changes[0])), source, version)
 acceptfiles[acceptfilename]=1
 
 print "Would create %s now and then go on to accept this package, if you 
allow me to." % (acceptfiles.keys())
-- 
2.9.3



Bug#837986: tpb: Please announce supported hardware using AppStream

2016-09-16 Thread Petter Reinholdtsen

Package: tpb
Version: 0.6.4-8
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The tpb package is one of the packages in the Debian archive that should
be proposed for installation when a given hardware dongle is inserted or
available.  Thanks to the appstream system, this can now be announced in
a way other tools can use and act on.  I've written the isenkram system
to ask the current user if hardware specific packages should be
installed when a new dongle is installed or already present on a
machine, and isenkram now uses appstream as one source for hardware to
package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
tpb package, with content similar to this:

  
  
   [...]
   
dmi:*:pn*:pvrThinkPad*:rvn*

  

If there are other modalias matches also supposed by the package, please
add those too. :)

-- 
Happy hacking
Petter Reinholdtsen



Bug#837970: Apt simulation improvements

2016-09-16 Thread David Kalnischkies
On Thu, Sep 15, 2016 at 10:06:55PM -0400, Kevin Mills wrote:
> It should be possible to continue a simulation through several invocations
> of apt. As it is, you can only do a simulation of one thing; you can't
> simulate, for example, installing package X and removing package Y, only
> one or the other.

You can install & remove packages at the same time. All "apt install" or
"apt remove" does is set a default for unqualified package names. If you
want to install a package append a '+' to its name, if you want it
removed append a '-'.

e.g.: apt install -s awesome apt-doc+ dpkg-dev-

This installs (or upgrades) 'awesome' and 'apt-doc' and removes
'dpkg-dev'.


Is that what you are asking for?


Best regards

David Kalnischkies


signature.asc
Description: PGP signature


Bug#837987: printer-driver-splix: Please announce supported hardware using AppStream

2016-09-16 Thread Petter Reinholdtsen

Package: printer-driver-splix
Version: 2.0.0+svn315-5
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The printer-driver-splix package is one of the packages in the Debian
archive that should be proposed for installation when a given hardware
dongle is inserted or available.  Thanks to the appstream system, this
can now be announced in a way other tools can use and act on.  I've
written the isenkram system to ask the current user if hardware specific
packages should be installed when a new dongle is installed or already
present on a machine, and isenkram now uses appstream as one source for
hardware to package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
printer-driver-splix package, with content similar to this:

  
  
   [...]
   
usb:v04E8p323Ad*
usb:v04E8p323Bd*
usb:v04E8p323Dd*
usb:v04E8p3242d*
usb:v04E8p324Cd*
usb:v04E8p324Dd*
usb:v04E8p325Bd*
usb:v04E8p325Fd*
usb:v04E8p3260d*
usb:v04E8p3268d*
usb:v04E8p3276d*
usb:v04E8p341Bd*
usb:v04E8p3426d*

  

If there are other USB ids also supposed by the package, please add
those too. :)

-- 
Happy hacking
Petter Reinholdtsen



Bug#837988: gnome-screenshot: Screenshotting an area results in incorrect are being captured

2016-09-16 Thread Petr Vanek
Package: gnome-screenshot
Version: 3.20.1-1
Severity: important
Tags: upstream

After selecting an area, correct size is being captured but probably
from wrong starting coordinates.

Previous working scenario: results in the selected area are being saved into 
file

Current non working scenario: saved file contains transparency and then
only a small portion of the selected area. Like of the selection was
calculated from wrong resolution...


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

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

Versions of packages gnome-screenshot depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  libc62.24-2
ii  libcairo21.14.6-1+b1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libgdk-pixbuf2.0-0   2.35.5-1
ii  libglib2.0-0 2.49.7-1
ii  libgtk-3-0   3.21.6-1
ii  libx11-6 2:1.6.3-1
ii  libxext6 2:1.3.3-1

gnome-screenshot recommends no packages.

gnome-screenshot suggests no packages.

-- debconf-show failed



Bug#837975: Contents also miss pdiff

2016-09-16 Thread Pirate Praveen
Get:21 http://debian.sil.at/debian sid/main amd64 Contents (deb) [34.1
MB]
0% [21 Contents-amd64 18.6 MB/34.1 MB 54%]



signature.asc
Description: OpenPGP digital signature


Bug#833634: jessie-pu: package apache2/2.4.10-10+deb8u6

2016-09-16 Thread Adam D. Barratt

On 2016-09-15 22:02, Julien Cristau wrote:

diff -Nru apache2-2.4.10/debian/apache2.install
apache2-2.4.10/debian/apache2.install
--- apache2-2.4.10/debian/apache2.install	2016-08-07 12:56:37.0 
+0200
+++ apache2-2.4.10/debian/apache2.install	2016-09-15 22:41:39.0 
+0200

@@ -5,4 +5,4 @@
 debian/a2query /usr/sbin
 debian/ask-for-passphrase  /usr/share/apache2/
 debian/debhelper/apache2-maintscript-helper/usr/share/apache2/
-debian/forking.conf
/lib/systemd/system/apache2.service.d/forking.conf
+debian/forking.conf
/lib/systemd/system/apache2.service.d
diff -Nru apache2-2.4.10/debian/changelog 
apache2-2.4.10/debian/changelog

--- apache2-2.4.10/debian/changelog 2016-08-07 13:02:55.0 +0200
+++ apache2-2.4.10/debian/changelog 2016-09-15 22:42:20.0 +0200
@@ -1,3 +1,9 @@
+apache2 (2.4.10-10+deb8u7) jessie; urgency=medium
+
+  * Fix installation of 
/lib/systemd/system/apache2.service.d/forking.conf.

+
+ -- Julien Cristau   Thu, 15 Sep 2016 22:42:19 
+0200

+
 apache2 (2.4.10-10+deb8u6) jessie; urgency=medium

   * Fix race condition and logical error in init script. Thanks to 
Thomas


Flagged for acceptance, thanks.

Regards,

Adam



Bug#837973: licensecheck should check license of font files

2016-09-16 Thread Jonas Smedegaard
Hi Praveen,

Quoting Pirate Praveen (2016-09-16 06:34:29)
> Many times ftp master reject a package because copyright of embedded 
> fonts are missing. It wuld be nice if licensecheck can find it before 
> the upload itself.

Thanks for reporting this!

This is already on my mental TODO-list (therefore thanks for making it 
visible by this bugreport!): One of the reasons for my adopting and 
refactoring licensecheck was to incorporate the extensions developed as 
part of CDBS - including the /usr/lib/cdbs/license-miner which extracts 
metadata from binary files like fonts and graphics files.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#815760: dpdk debian packaging

2016-09-16 Thread santiag...@riseup.net
El 15/09/16 a las 09:04, Christian Ehrhardt escribió:
> 
> On Wed, Sep 14, 2016 at 6:28 PM, Luca Boccassi  
> wrote:
> 
> Christian has sent patches upstream a couple weeks back:
> 
> http://dpdk.org/dev/patchwork/patch/15553/

Great!

> And we carry the former version of that submission as a patch for now to fix
> packaging as-is for now.
> Once accepted upstream that delta will be rebased for 16.07 topic branch to
> match the accepted version.
> For 16.11 I expect them to be upstream so on that topic branch we can drop the
> delta then.

So would you like to include it in debian/patches for now?


Attached you can find other three patches to fix minor issues, and make
lintian happier.
What else would be needed to upload to debian?

Cheers, and thanks a lot for your work!

Santiago
From 1108622aa88d56abf0e635e14768ef75eff55306 Mon Sep 17 00:00:00 2001
From: Santiago 
Date: Thu, 15 Sep 2016 09:28:44 +0200
Subject: [PATCH 1/4] debian/changelog: fix minor typos

Gbp-Dch: Ignore
---
 debian/changelog | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index fc040d5..007a8eb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -14,7 +14,7 @@ dpdk (16.07-0~git1) UNRELEASED; urgency=medium
   * d/p/dpdk-dev-doc-fix-old-dpdk-nic-bind.py-references.patch to fix the
 docs in regard to 16.07 changes renaming dpdk_nic_bind
   * d/p/make-load-devel-config-not-to-appear-as-executable.patch to avoid
-accidentially executing as script and to fix unusual-interpreter lintian
+accidentally executing as script and to fix unusual-interpreter lintian
 warning.
   * fix d/t/test-initscripts on more recent systemd environments
   * enable dpdk for ppc64el
@@ -46,7 +46,7 @@ dpdk (16.07-0~git1) UNRELEASED; urgency=medium
   * Add lintian-overrides for: "W: dpdk-doc: embedded-javascript-library"
   * Add optional binary kernel modules package, disabled by default (build with
 DEB_BUILD_OPTIONS=kernel_modules to enable). If enabled will build kernel
-modules agains the local, current kernel version (override by adding
+modules against the local, current kernel version (override by adding
 ksrc= to DEB_BUILD_OPTIONS) into a
 dpdk-modules- package
   * Set HOST_/EXTRA/CPP/C/LDFLAGS in d/rules so that all built objects pick up
-- 
2.1.4

From 4a728b804fe002a8447d7c3118dd1afbd12598c2 Mon Sep 17 00:00:00 2001
From: Santiago 
Date: Thu, 15 Sep 2016 18:22:29 +0200
Subject: [PATCH 3/4] debian/copyright: fix some wrong file entries

Gbp-Dch: Ignore
---
 debian/copyright | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index 49358f7..a0babbe 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -40,9 +40,9 @@ Copyright: 2007-2014, Intel Corporation.
 License: BSD-3-clause or LGPL-2.1
 
 Files: lib/librte_compat/rte_compat.h
- script
  drivers/net/vmxnet3/base/upt1_defs.h
- drivers/net/vmxnet3/base/vmxnet3_defs.hs/validate-abi.sh
+ drivers/net/vmxnet3/base/vmxnet3_defs.h
+ scripts/validate-abi.sh
 Copyright: 2015, Neil Horman 
2007, VMware, Inc.
 License: BSD-2-clause
-- 
2.1.4

From 10638d6224623f5c5ec978b06eefcf545e0e6b22 Mon Sep 17 00:00:00 2001
From: Santiago 
Date: Thu, 15 Sep 2016 18:25:23 +0200
Subject: [PATCH 4/4] debian/control: remove duplicate Homepage: and Section:
 fields

Gbp-Dch: Ignore
---
 debian/control | 46 --
 1 file changed, 46 deletions(-)

diff --git a/debian/control b/debian/control
index b2a38e4..7205167 100644
--- a/debian/control
+++ b/debian/control
@@ -26,7 +26,6 @@ Vcs-Browser: https://gerrit.fd.io/r/gitweb?p=deb_dpdk.git
 Package: dpdk
 Section: admin
 Architecture: amd64 arm64 i386 ppc64el
-Homepage: http://www.dpdk.org
 Depends: libdpdk-dev (= ${binary:Version}),
  lsb-base (>= 3.2-14),
  pciutils,
@@ -42,7 +41,6 @@ Description: Data Plane Development Kit (runtime)
 Package: dpdk-dev
 Section: devel
 Architecture: amd64 arm64 i386 ppc64el
-Homepage: http://www.dpdk.org
 Depends: libdpdk-dev (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
 Description: Data Plane Development Kit (development files)
  DPDK is a set of libraries for fast packet processing. Applications run
@@ -148,7 +146,6 @@ Description: Data Plane Development Kit (basic development files)
 
 Package: libethdev4
 Architecture: amd64 arm64 i386 ppc64el
-Section: libs
 Multi-Arch: same
 Homepage: http://dpdk.org/doc/api/rte__ethdev_8h.html
 Pre-Depends: ${misc:Pre-Depends}
@@ -161,7 +158,6 @@ Description: Data Plane Development Kit (libethdev runtime library)
 
 Package: librte-acl2
 Architecture: amd64 arm64 i386
-Section: libs
 Multi-Arch: same
 Homepage: http://dpdk.org/doc/api/rte__ethdev_8h.html
 Pre-Depends: ${misc:Pre-Depends}
@@ -174,7 +170,6 @@ Description: Data Plane Development Kit (librte-acl runtime library)
 
 Package: librte-cfgfile2
 Architecture: amd64 arm64 i386 ppc64el
-Section: libs
 Mul

Bug#837989: openocd: can no longer use SheevaPlug JTAGKey FT2232D (regression)

2016-09-16 Thread David Madore
Package: openocd
Version: 0.8.0-4

(I am reporting this against openocd version 0.8.0-4 because that is
what is found in Debian jessie, currently stable, but I also tried
0.9.0-1+b1, the version currently in sid.)

A SheevaPlug JTAGKey FT2232D (USB identifiers 9e88:9e8f) being
connected, version 0.5.0-1 (as found in Debian wheezy) of openocd
worked fine with it:

vega david ~ $ /tmp/openocd-0.5.0/src/openocd -f 
/tmp/openocd-0.5.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.5.0 (2016-09-16-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
2000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: feroceon.cpu: IR capture error; saw 0x00 not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 0
Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit
Error: unexpected Feroceon EICE version signature
^C

but openocd 0.8.0 fails as follows:

vega david ~ $ /tmp/openocd-0.8.0/src/openocd -f 
/tmp/openocd-0.8.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, it is based on code in ft2232.c.
Please report your experience with this file to openocd-devel mailing list,
so it could be marked as working or fixed.
Info : only one transport option; autoselect 'jtag'
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain 
connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Error: no device found
Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 
'SheevaPlug JTAGKey FT2232D' and serial '*'
in procedure 'init'

The error message is almost identical with openocd 0.9.0:

vega david ~ $ /tmp/openocd-0.9.0/src/openocd -f 
/tmp/openocd-0.9.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.9.0 (2016-09-16-09:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
WARNING!
This file was not tested with real interface, it is based on code in ft2232.c.
Please report your experience with this file to openocd-devel mailing list,
so it could be marked as working or fixed.
Info : auto-selecting first available session transport "jtag". To override use 
'transport select '.
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain 
connect_deassert_srst
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
adapter speed: 2000 kHz
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Error: no device found
Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 
'SheevaPlug JTAGKey FT2232D' and serial '*'

I also tried to get openocd 0.9.0 working with the openocd 0.5.0
scripts, with a different error message, but with no more success:

vega david ~ $ /tmp/openocd-0.9.0/src/openocd -f 
/tmp/openocd-0.5.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.9.0 (2016-09-16-09:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Error: The specified debug interface was not found (ft2232)
The following debug interfaces are available:
1: parport
2: dummy
3: ftdi
4: usb_blaster
5: amt_jtagaccel
6: gw16012
7: usbprog
8: jlink
9: vsllink
10: rlink
11: ulink
12: arm-jtag-ew
13: buspirate
14: remote_bitbang
15: hla
16: osbdm
17: opendous
18: aice
19: cmsis-dap


-- 
 David A. Madore
   ( http://www.madore.org/~david/ )



Bug#830863: Nothing?

2016-09-16 Thread Stanimir Stoyanov
Its a shame that no action has been made either with this report or with 
#826165


I was forced to downgrade opensc && opensc-pkcs11 from 0.16.0-1 to 
0.14.0-2 in order to be able to do my job.




Bug#837990: ITP: elpa-monokai-theme -- fruity color theme for Emacs

2016-09-16 Thread Lev Lamberov
Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: elpa-monokai-theme
  Version : 2.2.1
  Upstream Author : Kelvin Smith 
* URL : https://github.com/oneKelvinSmith/monokai-emacs
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : fruity color theme for Emacs

Monokai for Emacs is a port of the popular TextMate theme Monokai by Wimer
Hazenberg, built on top of the new built-in theme support in Emacs 24. The
inspiration for the theme came from Bozhidar Batsov and his Zenburn port and
Sublime Text 2 which defaults to this color scheme.



Bug#837929: npm: Should suggest nodejs-legacy

2016-09-16 Thread Matijs van Zuijlen
I read through bug 614907, and I think the very best solution would be
for npm to ensure the correct node executable is referenced in each
package's executable. I don't know how feasible that would be.

Regards,
Matijs

On 15/09/16 19:22, Jonas Smedegaard wrote:
> Quoting Jérémy Lal (2016-09-15 17:21:30)
>> 2016-09-15 17:12 GMT+02:00 Matijs van Zuijlen :
>>
>>> Package: npm
>>> Version: 1.4.21+ds-2
>>> Severity: wishlist
>>>
>>> Executables installed with npm need the /usr/bin/node executable, which
>>> is provided in the nodejs-legacy package. This information is currently
>>> only in the README.Debian file. I think it would be really helpful to
>>> add nodejs-legacy to the npm package's Suggests:, or even Recommends:.
>>>
>>>
>> Well, re-reading
>> https://lists.debian.org/debian-devel-announce/2012/07/msg2.html
>> paragraph 2 says
>>
>>> No package in the archive may depend on or recommend
>>> the nodejs-legacy package, which is provided solely for upstream
>> compatibility.
>>
>> Taken literally, it doesn't forbid Suggest. Does it ?
> 
> I agree we are not forbidden from suggesting: Seems to me the choice of 
> words by the Technical Committee was deliberate, as that matches how 
> packages outside of Debian (i.e. non-free stuff) is allowed to be 
> suggested only.
> 
> 
>  - Jonas
> 



signature.asc
Description: OpenPGP digital signature


Bug#837929: [Pkg-javascript-devel] Bug#837929: npm: Should suggest nodejs-legacy

2016-09-16 Thread Sebastiaan Couwenberg
On 09/16/2016 09:57 AM, Matijs van Zuijlen wrote:
> I read through bug 614907, and I think the very best solution would be
> for npm to ensure the correct node executable is referenced in each
> package's executable. I don't know how feasible that would be.

That's unfeasible in my opinion. The best you can get expect is for npm
to suggest nodejs-legacy to help remind you that you need that package
for /usr/bin/node. All Node.js users on Debian should already be
familiar which that situation and install nodejs-legacy when they need it.

Kind Regards,

Bas

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



signature.asc
Description: OpenPGP digital signature


Bug#837929: npm: Should suggest nodejs-legacy

2016-09-16 Thread Jérémy Lal
(reordered your reply to the bottom)

On 15/09/16 19:22, Jonas Smedegaard wrote:
> > Quoting Jérémy Lal (2016-09-15 17:21:30)
> >> 2016-09-15 17:12 GMT+02:00 Matijs van Zuijlen :
> >>
> >>> Package: npm
> >>> Version: 1.4.21+ds-2
> >>> Severity: wishlist
> >>>
> >>> Executables installed with npm need the /usr/bin/node executable, which
> >>> is provided in the nodejs-legacy package. This information is currently
> >>> only in the README.Debian file. I think it would be really helpful to
> >>> add nodejs-legacy to the npm package's Suggests:, or even Recommends:.
> >>>
> >>>
> >> Well, re-reading
> >> https://lists.debian.org/debian-devel-announce/2012/07/msg2.html
> >> paragraph 2 says
> >>
> >>> No package in the archive may depend on or recommend
> >>> the nodejs-legacy package, which is provided solely for upstream
> >> compatibility.
> >>
> >> Taken literally, it doesn't forbid Suggest. Does it ?
> >
> > I agree we are not forbidden from suggesting: Seems to me the choice of
> > words by the Technical Committee was deliberate, as that matches how
> > packages outside of Debian (i.e. non-free stuff) is allowed to be
> > suggested only.
>

2016-09-16 9:57 GMT+02:00 Matijs van Zuijlen :

> I read through bug 614907, and I think the very best solution would be
> for npm to ensure the correct node executable is referenced in each
> package's executable. I don't know how feasible that would be.
>

While it looks pleasant, the executable name is referenced in js code, in
makefiles,
bash files, json files, and possibly in very hidden ways.
It wouldn't be the best solution, it would be the riskiest one.

Jérémy


Bug#837989: openocd: can no longer use SheevaPlug JTAGKey FT2232D (regression)

2016-09-16 Thread Paul Fertser
Hello,

On Fri, Sep 16, 2016 at 09:55:21AM +0200, David Madore wrote:
> A SheevaPlug JTAGKey FT2232D (USB identifiers 9e88:9e8f) being

Please also provide lsusb -vvv data for this device.

> worked fine with it:
...
> Error: JTAG scan chain interrogation failed: all zeroes

No, this doesn't look fine to me.

> Open On-Chip Debugger 0.8.0 (2016-09-16-09:45)
...
> Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 
> 'SheevaPlug JTAGKey FT2232D' and serial '*'

You might want to try to comment out ftdi_device_desc command from
interface/ftdi/sheevaplug.cfg to workaround this issue.

> The error message is almost identical with openocd 0.9.0:
...
> Error: unable to open ftdi device with vid 9e88, pid 9e8f,
> description 'SheevaPlug JTAGKey FT2232D' and serial '*'

The error you report seems to be fixed post-0.8.0, but before 0.9.0,
in v0.8.0-142-geab9af1 . So it looks as if you're trying to use 0.9.0
with scripts from 0.8.0.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com



Bug#837992: cloud.debian.org: vagrant libvirt box NFS mount failure on vagrant up

2016-09-16 Thread Emmanuel Kasper
Package: cloud.debian.org
Severity: normal

The libvirt box has problem with the default shared mode (NFS)

A fresh vagrant up from the atlas box brings:

mount -o vers=3,udp
192.168.121.1:/home/manu/Projects/vagrenvs/jatlavirtdef /vagrant
if command -v /sbin/init && /sbin/init --version | grep upstart; then
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/vagrant
fi
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified

this seens to relate to this bug in Jessie:  #775542
NFS exports fail due to rpcbind not starting before nfs-common and
nfs-kernel-server

 
 the rpc.statd startup depends on portmapper
 portmapper is started by the rpcbind service
 and the rpcbind service is not started early enough if started at all
 

I see three possibility fo fix this:
 A) switch to NFSv4 by default via a Vagrant configuration option
NFSv4 does not requires the rpc.statd service to run before mounting a
NFS share
 B) force the rpcbind server to start earlier by patching stuff in /etc
 C) switch to rsync as the default file sharing mecanismus ( or maybe
p9fs) for libvirt boxes. Rsync has also the advantage of not requiring
the root password for each vagrant up.


I would propose to work this bug around in order of preferences via C) or A)

and check if #775542 is fixed in stretch


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

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



Bug#837929: npm: Should suggest nodejs-legacy

2016-09-16 Thread Jonas Smedegaard
Quoting Matijs van Zuijlen (2016-09-16 09:57:52)
> I read through bug 614907, and I think the very best solution would be 
> for npm to ensure the correct node executable is referenced in each 
> package's executable. I don't know how feasible that would be.

Arguably the "very best" would be to drop npm from Debian ;-)

More to the point, however: Do npm work at all without nodejs-legacy?
If not, then npm itself should be moved to contrib!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#837991: [python-mode] [jessie] >>Error occurred processing python-mode.el: Cannot open load file: rx

2016-09-16 Thread LACROIX Jean Marc

Package: python-mode
Version: 1:6.1.3-2
Severity: normal

Dear maintainers,
I am trying to install python on a Jessie system (X86/amd64) in order to 
use it with xemacs21 editor.


ansible@solo:~$ cat /etc/debian_version
8.5
ansible@solo:~$ uname -a
Linux solo 4.6.0-0.bpo.1-amd64 #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11) 
x86_64 GNU/Linux



ansible@solo:~$ dpkg -l |grep python
ii  dh-python 2.20160818~bpo8+1 
  all  Debian helper tools for packaging Python libraries 
and applications
ii  libpython-stdlib:amd642.7.9-1 
  amd64interactive high-level object-oriented language 
(default python version)
ii  libpython2.7:amd642.7.9-2 
  amd64Shared Python runtime library (version 2.7)
ii  libpython2.7-minimal:amd642.7.9-2 
  amd64Minimal subset of the Python language (version 2.7)
ii  libpython2.7-stdlib:amd64 2.7.9-2 
  amd64Interactive high-level object-oriented language 
(standard library, version 2.7)
ii  libpython3-stdlib:amd64   3.4.2-2 
  amd64interactive high-level object-oriented language 
(default python3 version)
ii  libpython3.4:amd643.4.2-1 
  amd64Shared Python runtime library (version 3.4)
ii  libpython3.4-minimal:amd643.4.2-1 
  amd64Minimal subset of the Python language (version 3.4)
ii  libpython3.4-stdlib:amd64 3.4.2-1 
  amd64Interactive high-level object-oriented language 
(standard library, version 3.4)
ii  python2.7.9-1 
  amd64interactive high-level object-oriented language 
(default version)
ii  python-appindicator   0.4.92-3.1 
  amd64Python bindings for libappindicator
ii  python-apt0.9.3.12 
  amd64Python interface to libapt-pkg
ii  python-apt-common 0.9.3.12 
  all  Python interface to libapt-pkg (locales)
ii  python-beautifulsoup  3.2.1-1 
  all  error-tolerant HTML parser for Python
ii  python-brlapi 5.3.1-1~bpo8+1 
  amd64Braille display access via BRLTTY - Python bindings
ii  python-cairo  1.8.8-1+b2 
  amd64Python bindings for the Cairo vector graphics library
ii  python-central0.6.17 
  all  register and build utility for Python packages
ii  python-chardet2.3.0-1 
  all  universal character encoding detector for Python2
ii  python-crypto 2.6.1-5+b2 
  amd64cryptographic algorithms and protocols for Python
ii  python-dbus   1.2.0-2+b3 
  amd64simple interprocess messaging system (Python interface)
ii  python-dbus-dev   1.2.0-2 
  all  main loop integration development files for python-dbus
ii  python-debian 0.1.27 
  all  Python modules to work with Debian-related data formats
ii  python-debianbts  2.6.0~bpo8+1 
  all  Python interface to Debian's Bug Tracking System
ii  python-defusedxml 0.4.1-2 
  all  XML bomb protection for Python stdlib modules (for 
Python 2)
ii  python-docutils   0.12+dfsg-1 
  all  text processing system for reStructuredText 
(implemented in Python 2)
ii  python-ecdsa  0.11-1 
  all  ECDSA cryptographic signature library (Python 2)
ii  python-enum34 1.0.3-1 
  all  backport of Python 3.4's enum package
ii  python-feedparser 5.1.3-3 
  all  Universal Feed Parser for Python
ii  python-fpconst0.7.2-5 
  all  Utilities for handling IEEE 754 floating point 
special values
ii  python-gconf  2.28.1+dfsg-1.1 
  amd64Python bindings for the GConf configuration database 
system
ii  python-gi 3.14.0-1 
  amd64Python 2.x bindings for gobject-introspection libraries
ii  python-gi-cairo   3.14.0-1 
  amd64Python Cairo bindings for the GObject library
ii  python-glade2 2.24.0-4 
  amd64GTK+ bindings: Glade support
ii  python-gnome2 2.28.1+dfsg-1.1 
  amd64Python bindings for the GNOME desktop environment
ii  python-gobject3.14.0-1 
  all  Python 2.x bindings for GObject - transitional package
ii  python-gobject-2  2.28.6-12+b1 
  amd64deprecated static Python bindings for the GObject lib
ii  python-gpgme  0.3-1+b1 
  amd64python wrapper for the GPGME library
ii  p

Bug#837992: (no subject)

2016-09-16 Thread Emmanuel Kasper
inital bug discussion happpened via email, but we prefer to have this in
the BTS, so move the relevant part of the discussions here


> I see three possibility fo fix this:
>  A) switch to NFSv4 by default via a Vagrant configuration option
> NFSv4 does not requires the rpc.statd service to run before mounting a
> NFS share
>  B) force the rpcbind server to start earlier by patching stuff in /etc
>  C) switch to rsync as the default file sharing mecanismus ( or maybe
> p9fs) for libvirt boxes. Rsync has also the advantage of not requiring
> the root password for each vagrant up.
>
>
> I would propose to work this bug around in order of preferences via C)
or A)

A) seems cleaner.

wrt C):

- I have tried p9fs before and it is not so easy to make it work
  correctly, because you cannot get the uid mapping between host and vm
  correct all the time; it's "easy" to get it working if the share is
  read-only from the PoV of the VM, but not so easy otherwise.

- rsync seems like a terrible regression on how vagrant is supposed to
  work. you expect to change something from the host and it being
  immediately reflected on the VM, but when sharing via rsync you need
  to re-provision the VM to have your changes reflected, which sucks



Bug#837929: npm: Should suggest nodejs-legacy

2016-09-16 Thread Jérémy Lal
2016-09-16 10:22 GMT+02:00 Jonas Smedegaard :

> Quoting Matijs van Zuijlen (2016-09-16 09:57:52)
> > I read through bug 614907, and I think the very best solution would be
> > for npm to ensure the correct node executable is referenced in each
> > package's executable. I don't know how feasible that would be.
>
> Arguably the "very best" would be to drop npm from Debian ;-)
>
> More to the point, however: Do npm work at all without nodejs-legacy?
> If not, then npm itself should be moved to contrib!


Actually i believe most modules just work without nodejs-legacy, and npm
itself
has some uses without installing it either.

Jérémy.


Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

2016-09-16 Thread Cristian Ionescu-Idbohrn
Muammar,

On Fri, 16 Sep 2016, Muammar El Khatib wrote:
>
> I hope you are still interested in this.

Of course.

> After reading a lot here and
> there, I am writing this mail casting ti the chromecast using ALSA
> instead of pulseaudio :). It works pretty well so far.  I decided to
> uninstall pulseaudio and I gave it a try.
>
> I have prepared a page in the wiki that you can check:
>
> https://github.com/muammar/mkchromecast/wiki/ALSA
>
> I would be glad if you could test it. Note that you have to checkout
> the `alsa` branch.

I would also be glad to do so, if I could figure out how ~/.asoundrc
must look like.  Currently, the minimal conf to get sound out the
audio card I prefer is:

,[ ~/.asoundrc ]
| pcm.!default {
| type plug
| slave.pcm spdif
| }
`

Here are some more details on the sound cards on my system:

,[ cat /proc/asound/cards ]
|  0 [Live   ]: EMU10K1 - SB Live! 5.1 [SB0060]
|   SB Live! 5.1 [SB0060] (rev.7, serial:0x80611102) at 
0xd000, irq 17
|  1 [PCH]: HDA-Intel - HDA Intel PCH
|   HDA Intel PCH at 0xf723 irq 29
|  2 [NVidia ]: HDA-Intel - HDA NVidia
|   HDA NVidia at 0xf708 irq 17
|  3 [Controller ]: USB-Audio - USB Audio Controller
|   USB Audio Controller at usb-:00:1d.0-1.5, full speed
|  4 [Loopback   ]: Loopback - Loopback
|   Loopback 1
`

,[ aplay -l ]
|  List of PLAYBACK Hardware Devices 
| card 0: Live [SB Live! 5.1 [SB0060]], device 0: emu10k1 [ADC Capture/Standard 
PCM Playback]
|   Subdevices: 32/32
|   Subdevice #0: subdevice #0
|   Subdevice #1: subdevice #1
|   Subdevice #2: subdevice #2
|   Subdevice #3: subdevice #3
|   Subdevice #4: subdevice #4
|   Subdevice #5: subdevice #5
|   Subdevice #6: subdevice #6
|   Subdevice #7: subdevice #7
|   Subdevice #8: subdevice #8
|   Subdevice #9: subdevice #9
|   Subdevice #10: subdevice #10
|   Subdevice #11: subdevice #11
|   Subdevice #12: subdevice #12
|   Subdevice #13: subdevice #13
|   Subdevice #14: subdevice #14
|   Subdevice #15: subdevice #15
|   Subdevice #16: subdevice #16
|   Subdevice #17: subdevice #17
|   Subdevice #18: subdevice #18
|   Subdevice #19: subdevice #19
|   Subdevice #20: subdevice #20
|   Subdevice #21: subdevice #21
|   Subdevice #22: subdevice #22
|   Subdevice #23: subdevice #23
|   Subdevice #24: subdevice #24
|   Subdevice #25: subdevice #25
|   Subdevice #26: subdevice #26
|   Subdevice #27: subdevice #27
|   Subdevice #28: subdevice #28
|   Subdevice #29: subdevice #29
|   Subdevice #30: subdevice #30
|   Subdevice #31: subdevice #31
| card 0: Live [SB Live! 5.1 [SB0060]], device 2: emu10k1 efx [Multichannel 
Capture/PT Playback]
|   Subdevices: 8/8
|   Subdevice #0: subdevice #0
|   Subdevice #1: subdevice #1
|   Subdevice #2: subdevice #2
|   Subdevice #3: subdevice #3
|   Subdevice #4: subdevice #4
|   Subdevice #5: subdevice #5
|   Subdevice #6: subdevice #6
|   Subdevice #7: subdevice #7
| card 0: Live [SB Live! 5.1 [SB0060]], device 3: emu10k1 [Multichannel 
Playback]
|   Subdevices: 1/1
|   Subdevice #0: subdevice #0
| card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
|   Subdevices: 1/1
|   Subdevice #0: subdevice #0
| card 1: PCH [HDA Intel PCH], device 1: ALC892 Digital [ALC892 Digital]
|   Subdevices: 1/1
|   Subdevice #0: subdevice #0
| card 2: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
|   Subdevices: 1/1
|   Subdevice #0: subdevice #0
| card 2: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
|   Subdevices: 1/1
|   Subdevice #0: subdevice #0
| card 2: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
|   Subdevices: 1/1
|   Subdevice #0: subdevice #0
| card 3: Controller [USB Audio Controller], device 0: USB Audio [USB Audio]
|   Subdevices: 1/1
|   Subdevice #0: subdevice #0
| card 4: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
|   Subdevices: 8/8
|   Subdevice #0: subdevice #0
|   Subdevice #1: subdevice #1
|   Subdevice #2: subdevice #2
|   Subdevice #3: subdevice #3
|   Subdevice #4: subdevice #4
|   Subdevice #5: subdevice #5
|   Subdevice #6: subdevice #6
|   Subdevice #7: subdevice #7
| card 4: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
|   Subdevices: 8/8
|   Subdevice #0: subdevice #0
|   Subdevice #1: subdevice #1
|   Subdevice #2: subdevice #2
|   Subdevice #3: subdevice #3
|   Subdevice #4: subdevice #4
|   Subdevice #5: subdevice #5
|   Subdevice #6: subdevice #6
|   Subdevice #7: subdevice #7
`

Cards 0 and 1 connected to speakers.

> Regarding the two interfaces in your machine, was the chromecast
> detected? If yes, I think I can provide a flag where you can specify
> the ip of the host.

Yeah, that may be needed.  Not being able to figure out the alsa
configuration, I tried this:

,
| $ python ./mkchromecast.py --debug --discover
| None
| This option is not implemented yet.
`

But the device is there.  Nmap rep

Bug#837993: libboost-all-dev: Package libboost-type-erasure-dev is not a dependency

2016-09-16 Thread Massimiliano Leoni
Package: libboost-all-dev
Version: 1.61.0.2
Severity: normal

Dear Maintainer,

On debian testing, package libboost-type-erasure-dev is not a dependency
of this package, whereas I would say it should be. Please add the
dependency or explain why it is not one.

Thanks,
Massimiliano


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

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

Versions of packages libboost-all-dev depends on:
ii  libboost-atomic-dev   1.61.0.2
ii  libboost-chrono-dev   1.61.0.2
ii  libboost-context-dev  1.61.0.2
ii  libboost-coroutine-dev1.61.0.2
ii  libboost-date-time-dev1.61.0.2
ii  libboost-dev  1.61.0.2
ii  libboost-exception-dev1.61.0.2
ii  libboost-filesystem-dev   1.61.0.2
ii  libboost-graph-dev1.61.0.2
ii  libboost-graph-parallel-dev   1.61.0.2
ii  libboost-iostreams-dev1.61.0.2
ii  libboost-locale-dev   1.61.0.2
ii  libboost-log-dev  1.61.0.2
ii  libboost-math-dev 1.61.0.2
ii  libboost-mpi-dev  1.61.0.2
ii  libboost-mpi-python-dev   1.61.0.2
ii  libboost-program-options-dev  1.61.0.2
ii  libboost-python-dev   1.61.0.2
ii  libboost-random-dev   1.61.0.2
ii  libboost-regex-dev1.61.0.2
ii  libboost-serialization-dev1.61.0.2
ii  libboost-signals-dev  1.61.0.2
ii  libboost-system-dev   1.61.0.2
ii  libboost-test-dev 1.61.0.2
ii  libboost-thread-dev   1.61.0.2
ii  libboost-timer-dev1.61.0.2
ii  libboost-tools-dev1.61.0.2
ii  libboost-wave-dev 1.61.0.2

libboost-all-dev recommends no packages.

libboost-all-dev suggests no packages.

-- no debconf information



Bug#837994: mysql-5.5: FTBFS on armhf

2016-09-16 Thread Salvatore Bonaccorso
Source: mysql-5.5
Version: 5.5.52-0+deb8u1
Severity: serious
Justification: FTBFS

Hi

On armhf the latest security-update for mysql-5.5 5.5.52-0+deb8u1
fails to build. Attached is a build log for it.

Regards,
Salvatore


mysql-5.5_5.5.52-0+deb8u1_armhf-20160915-0647.gz
Description: application/gzip


Bug#827061: transition: openssl

2016-09-16 Thread Christoph Berg
Re: Kurt Roeckx 2016-09-16 <20160916054549.2wjl4xzb2eyg6...@roeckx.be>
> > do you expect the transition to be done for stretch?
> 
> I really would like to have it in stretch.  I don't want to have
> the same situtation like we had with 1.0.2 that didn't make it it
> to jessie.

Nod, thanks for confirming.

> > I'm asking because the PostgreSQL people want to know if they need to
> > add support for OpenSSL 1.1 in the older release branches (9.2 ..
> > 9.4), or if patching 9.5 .. 10 is enough for now.
> 
> I guess they want to provide binaries for all their releases on
> apt.postgresql.org?

That's exactly the reason, yes. (And "they" is me ;)

Christoph


signature.asc
Description: PGP signature


Bug#837929: npm: Should suggest nodejs-legacy

2016-09-16 Thread Matijs van Zuijlen
On 16/09/16 10:24, Jérémy Lal wrote:
> 
> 
> 2016-09-16 10:22 GMT+02:00 Jonas Smedegaard  >:
> 
> Quoting Matijs van Zuijlen (2016-09-16 09:57:52)
> > I read through bug 614907, and I think the very best solution would be
> > for npm to ensure the correct node executable is referenced in each
> > package's executable. I don't know how feasible that would be.
> 
> Arguably the "very best" would be to drop npm from Debian ;-)
> 
> More to the point, however: Do npm work at all without nodejs-legacy?
> If not, then npm itself should be moved to contrib!
> 
> 
> Actually i believe most modules just work without nodejs-legacy, and npm
> itself
> has some uses without installing it either.

Yes, it seems it's mainly the modules that provide an executable script
that need nodejs-legacy (In my case, coffeelint).

Regards,
Matijs



signature.asc
Description: OpenPGP digital signature


Bug#837995: libvirt: please run tests on arm architectures

2016-09-16 Thread Riku Voipio
Source: libvirt
Version: 2.2.0-1
Severity: wishlist
Tags: patch

In my tests, libvirt tests pass fine on armhf/arm64. I take we
have newer kernel than debian builders, so it could fail in Debian.
To play safe, I suggest running tests but not failing them on arm/arm64.
This what the patch below does, being minimum impact.

The more ambitious way would be to enable tests on all platforms,
upload to experimental, and then set FAIL_CHECK for all architectures
that pass.

diff --git a/debian/rules b/debian/rules
index cf50336..0885cd6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,11 +7,12 @@ DEB_BUILDUSER=$(shell dpkg-parsechangelog -SMaintainer)
 ifneq (,$(findstring $(DEB_HOST_ARCH_OS), linux))
   ifneq (,$(findstring $(DEB_HOST_ARCH), i386 amd64))
 WITH_VBOX = --with-vbox
-MAKE_CHECK= 1
+FAIL_CHECK= 1
   else
 WITH_VBOX = --without-vbox
   endif
   ifneq (,$(findstring $(DEB_HOST_ARCH), i386 amd64 armhf arm64))
+MAKE_CHECK= 1
 WITH_XEN  = --with-xen
 WITH_LIBXL= --with-libxl
 XEN_ENABLED   = 1
@@ -154,7 +155,7 @@ override_dh_auto_test:
if ! dh_auto_test -O--builddirectory=$(DEB_BUILDDIR); then \
cat ./debian/build/gnulib/tests/test-suite.log \
./debian/build/tests/test-suite.log; \
-   exit 1; \
+   [ -n "$(FAIL_CHECK)" ] || exit 1; \
fi
 
 override_dh_install-arch:

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

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



Bug#837996: ftp.debian.org: Please enable auto building of seqan

2016-09-16 Thread Andreas Tille
Package: ftp.debian.org
Severity: normal

Hi ftpmasters,

as per this hint on Debian Mentors list[1] I hereby ask you for help to
let the seqan package be auto-build.  The fact that the seqan-app
package was dropped from the binary packages might have caused this
issue which might have been hidden by my source only upload.

Thanks for your ftpmaster work

 Andreas.


[1] https://lists.debian.org/debian-mentors/2016/09/msg00274.html



Bug#777320: dhcping: please make the build reproducible

2016-09-16 Thread Chris Lamb
Dear Maintainer,

> Source: dhcping
> Version: 1.2-4.1
> Tags: patch

There hasn't seem to be any update on this bug in 32 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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



Bug#777398: ssmtp: please make the build reproducible

2016-09-16 Thread Chris Lamb
Dear Maintainer,

> Source: ssmtp
> Version: 2.64-4
> Tags: patch

There hasn't seem to be any update on this bug in 32 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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



Bug#837997: novnc: launch.sh missing

2016-09-16 Thread Tim Connors
Package: novnc
Version: 1:0.4+dfsg+1+20131010+gitf68af8af3d-4
Severity: important

utils/launch.sh isn't included in the debian package.

Justification for important tag: /usr/share/doc/novnc/README.md.gz
refers to launch.sh.  All documentation on the web refers to
launch.sh.  Without it, I don't seem to be able to find a way to
launch the server, and thus the package seems unusable.

Similar ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/novnc/+bug/1492351


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

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

Versions of packages novnc depends on:
ii  adduser  3.113+nmu3
ii  dpkg 1.18.3
ii  libjs-swfobject  2.2+dfsg-1
ii  python   2.7.9-1
ii  python-novnc 1:0.4+dfsg+1+20131010+gitf68af8af3d-4
ii  python-numpy 1:1.11.0-1
ii  websockify   0.6.0+dfsg1-1

Versions of packages novnc recommends:
pn  python-nova  

novnc suggests no packages.

-- no debconf information



Bug#776622: dahdi-linux: please make the build reproducible

2016-09-16 Thread Chris Lamb
Dear Maintainer,

> Source: dahdi-linux
> Version: 1:2.3.0.1+dfsg-2
> Tags: patch

There hasn't seem to be any update on this bug in 32 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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



Bug#776760: dot-forward: please make the build reproducible

2016-09-16 Thread Chris Lamb
Dear Maintainer,

> Source: dot-forward
> Version: 1:0.71-2
> Tags: patch

There hasn't seem to be any update on this bug in 32 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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



Bug#778229: xfonts-terminus: please make the build reproducible

2016-09-16 Thread Chris Lamb
Dear Maintainer,

> Source: xfonts-terminus
> Version: 4.30-2
> Tags: patch

There hasn't seem to be any update on this bug in 32 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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



Bug#837992: (no subject)

2016-09-16 Thread Marcin Kulisz
I personally am not a big vagrant user but I'd opt for the solution A
-- 

|_|0|_|  |
|_|_|0|  "Panta rei" |
|0|0|0|  kuLa    |

gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3
3DF1  A4DF  C732  4688  38BC  F121  6869  30DD  58C3  38B3


signature.asc
Description: PGP signature


Bug#834773: gkrellm: please make the build reproducible

2016-09-16 Thread Chris Lamb
Dear Maintainer,

> Source: gkrellm
> Version: 2.3.5-3
> Tags: patch

There hasn't seem to be any update on this bug in 28 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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



Bug#778431: tkrat: please make the build reproducible

2016-09-16 Thread Chris Lamb
Dear Maintainer,

> Source: tkrat
> Version: 1:2.2cvs20100105-true-dfsg-6ubuntu1
> Tags: patch

There hasn't seem to be any update on this bug in 32 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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



Bug#834773: gkrellm: please make the build reproducible

2016-09-16 Thread Sandro Tosi
> Would you consider applying this patch and uploading?

yeah i'll do soon, when i'll upload the new upstream release

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi



Bug#837996: ftp.debian.org: Please enable auto building of seqan

2016-09-16 Thread Gianfranco Costamagna
control: retitle -1 RM: seqan-apps --  RoM; NBS

> as per this hint on Debian Mentors list[1] I hereby ask you for help to
> let the seqan package be auto-build.  The fact that the seqan-app
> package was dropped from the binary packages might have caused this
> issue which might have been hidden by my source only upload.
> 

the hint was:
you don't build seqan-apps anymore, so you need to ask to decuft, remove that 
binary
because not built from source anymore.

G.



signature.asc
Description: OpenPGP digital signature


Bug#837998: fuse-umfuse-fat: fix month in timestamps

2016-09-16 Thread Alessandro Larcher

Package: fuse-umfuse-fat
Version: 0.1a-1.1
Severity: normal
Tags: patch

We use fusefat to create FAT images to write to SD cards, but the 
month in timestamp is/was wrong:


~ mkdir test.fat
~ date
gio 15 set 2016, 18.05.05, CEST
~ su
# fusefat -o rw+ /dev/sde2 test.fat
# touch test.fat/empty
# ls -l test.fat/empty
-rwx-- 1 root root 0 set 15 17:05 test.fat/empty
# #note that the hour is wrong - maybe something TZ-related?
# fusermount -u test.fat
# mount /dev/sde2 test.fat
# ls -l test.fat/empty
-rwxr-xr-x 1 root root 0 ago 15 18:05 test.fat/empty
# #note that the hour is right, but the month is wrong

The reason is that tm.tm_mon range is 0-11, while FAT range is 1-12.

The attached patch fixes the month issue. 

fix-month.diff
Description: Binary data


Bug#838000: ctdb.service names wrong PIDFILE in ctdb_4.4.5+dfsg-3

2016-09-16 Thread KoJac
Package: ctdb
Version: 2:4.4.5+dfsg-3
Severity: important
Tags: newcomer



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

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

Versions of packages ctdb depends on:
ii  init-system-helpers  1.42
ii  iproute2 4.3.0-1+b1
ii  libbsd0  0.8.3-1
ii  libc62.23-5
ii  libpopt0 1.16-10
ii  libtalloc2   2.1.7-1
ii  libtdb1  1.3.9-1
ii  libtevent0   0.9.28-1
ii  lsb-base 9.20160629
ii  psmisc   22.21-2.1+b1
ii  samba-libs   2:4.4.5+dfsg-3
ii  sudo 1.8.17p1-2
ii  tdb-tools1.3.9-1
ii  time 1.7-25.1

Versions of packages ctdb recommends:
ii  ethtool  1:4.6-1

Versions of packages ctdb suggests:
ii  logrotate  3.8.7-2
ii  lsof   4.89+dfsg-0.1

-- Configuration Files:
/etc/default/ctdb changed:
CTDB_RECOVERY_LOCK=/mnt/gv_main/samba/ctdb.lock 
CTDB_NODES=/etc/ctdb/nodes
CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses
CTDB_MANAGES_SAMBA=yes
CTDB_MANAGES_WINBIND=yes


-- no debconf information

as of ctdb package version 4.4.5+dfsg-3 there seems to be a bug in the 
ctdb.service script.
With a configuration tested with the previous version "service ctdb start" 
fails after service start timeout. While starting and waiting for the timeout, 
ctdb service is usable but the startup scripts kill the processes if no pid 
file can be found.
journalctl message:
systemd[1]: ctdb.service: PID file /var/run/sambe/ctdb/ctdbd.pid not readable 
(yet?) after start: No such file or directory

replacing the pidfile inside /lib/systemd/system/ctdb.service fixed the problem 
for me:

sed -i 
's/^PIDFile=\/var\/run\/samba\/ctdb\/ctdbd.pid$/PIDFile=\/run\/ctdb\/ctdbd.pid/'
 /lib/systemd/system/ctdb.service
systemctl daemon-reload



PS:
offtopic (probably known issue):
the following statement inside /etc/default/ctdb
CTDB_MANAGES_SAMBA=yes

can be made working with:
cd /lib/systemd/system/
rm samba.service ; ln -s smbd.service samba.service



Bug#836531: Bug#837356: libreoffice-gtk3: Impress is unusably slow on GNOME 3 with libreoffice-gtk3 installed

2016-09-16 Thread Rene Engelhard
tag 837356 + upstream
forwarded 837356 caol...@redhat.com
retitle 836531 LibreOffice unusably slow on GNOME 3 with libreoffice-gtk3 
installed with Gtk 3.21
thanks

Hi,

On Thu, Sep 15, 2016 at 12:46:17PM -0300, Daniel Serpell wrote:
> > .. I'd actually believe this is a Gtk3 and/or GNOME bug?
> >
> > What happens if you downgrade Gtk3 to 3.20.9-1 or so?
> > (http://snapshot.debian.org/package/gtk%2B3.0/3.20.9-1/#libgtk-3-0_3.20.9-1)
> >
>
> Downgrading Gtk3 to 3.20.9-1 fixes the bug!!

Does that also help for the "-gtk3 makes it slow in xfce" bug (#836531)?
Then those indeed are the same one and should be merged.

> So, it is probably a bug in Gtk3 or in the way that LO uses Gtk (because no
> other Gtk app seems affected).

Upstream says:

10:51 <@caolan> might be the same thing as
https://bugzilla.redhat.com/show_bug.cgi?id=1373933 which I'm
looking at right now
10:52 < IZBot> bug 1373933: Fedora-['libreoffice'] unspecified/unspecified NEW
   object selection and edit freezes libreoffice for several seconds
10:52 < _rene_> 17:57 < _rene_> caolan: remember on how I asked about Gtk
3.21.x?  http://bugs.debian.org/837356...
10:52 <@caolan> I'd say its the same thing, especially cause of "Downgrading
Gtk3 to 3.20.9-1 fix it"
10:52 <@caolan> I'm bisecting gtk itself at the moment
10:53 < _rene_> yeah, sounds like it afte reading the rhbz bug

Regards,

Rene



Bug#838001: cryptsetup does not support ZFS

2016-09-16 Thread Richard Laager
Package: cryptsetup

I use Ubuntu, not Debian, and filed this bug:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1612906

It was suggested there that I look at Debian bug #820888, titled
cryptsetup: initramfs cryptroot zfs support:
https://bugs.debian.org/820888

I think that's a separate issue, but I'm not 100% sure. Either way, it'd
be nice to upstream the patch below into Debian's cryptsetup, if the
patch is in fact suitable for Debian.

On to the actual issue...

This happens on Ubuntu 16.04:
$ sudo update-initramfs -c -k all
update-initramfs: Generating /boot/initrd.img-4.4.0-34-generic
cryptsetup: WARNING: could not determine root device from /etc/fstab
update-initramfs: Generating /boot/initrd.img-4.4.0-31-generic
cryptsetup: WARNING: could not determine root device from /etc/fstab

The attached patch adds ZFS support to cryptsetup.

-- 
Richard
diff -Nru cryptsetup-1.7.2/debian/changelog cryptsetup-1.7.2/debian/changelog
--- cryptsetup-1.7.2/debian/changelog   2016-07-01 03:57:14.0 -0500
+++ cryptsetup-1.7.2/debian/changelog   2016-08-03 11:35:40.0 -0500
@@ -1,3 +1,9 @@
+cryptsetup (2:1.7.2-0ubuntu2~rlaager1) yakkety; urgency=medium
+
+  * Support ZFS in the cryptroot initramfs-tools hook.
+
+ -- Richard Laager   Wed, 03 Aug 2016 11:30:29 -0500
+
 cryptsetup (2:1.7.2-0ubuntu1) yakkety; urgency=medium
 
   * New upstream release, merge from Debian unstable (LP: #1548137). Remaining
diff -Nru cryptsetup-1.7.2/debian/initramfs/cryptroot-hook 
cryptsetup-1.7.2/debian/initramfs/cryptroot-hook
--- cryptsetup-1.7.2/debian/initramfs/cryptroot-hook2016-04-29 
01:18:05.0 -0500
+++ cryptsetup-1.7.2/debian/initramfs/cryptroot-hook2016-08-03 
11:35:57.0 -0500
@@ -20,11 +20,7 @@
local device mount type options dump pass
local wantmount="$1"
 
-   if [ ! -r /etc/fstab ]; then
-   return 1
-   fi
-
-   grep -s '^[^#]' /etc/fstab | \
+   grep -s '^[^#]' /etc/fstab 2>/dev/null | \
while read device mount type options dump pass; do
if [ "$mount" = "$wantmount" ]; then
local devices
@@ -39,6 +35,21 @@
return
fi
done
+
+   zfs list -H -o name,canmount,mountpoint 2>/dev/null | \
+   while read name canmount mountpoint; do
+   [ "$canmount" = off ] && continue
+   if [ "$mountpoint" = "$wantmount" ]; then
+   local devices
+   for dev in $(zpool status -P "${name%%/*}" 2>/dev/null 
| awk '($1 ~ /\//) {print $1}'); do
+   devices="$devices $(canonical_device "$dev")"
+   done
+   echo "$devices"
+   return
+   fi
+   done
+
+   return 1
 }
 
 get_resume_devices() {


Bug#838002: Libreoffice-writer formatting dialogs take too long to open

2016-09-16 Thread Leon Meier

Package: libreoffice-writer
Version: 1:5.2.1-1

Opening the dialog Format->Character from the menu took around 1 min 41 
sec. I tried:

- removing the .config/libreoffice directory
- increasing usable memory in the extras->options
- # fc-cache -f -v
After the last action, the delay went down to 1 minute. Still way to long.
The bug is consistently repeatable.
My distribution is an up-to-date sid.

Any help?



Bug#837929: npm: Should suggest nodejs-legacy

2016-09-16 Thread Jonas Smedegaard
[drop old archived bug from cc]

Quoting Matijs van Zuijlen (2016-09-16 10:39:05)
> On 16/09/16 10:24, Jérémy Lal wrote:
> > 2016-09-16 10:22 GMT+02:00 Jonas Smedegaard  > >:
> > Quoting Matijs van Zuijlen (2016-09-16 09:57:52)
> > > I read through bug 614907, and I think the very best solution 
> > > would be for npm to ensure the correct node executable is 
> > > referenced in each package's executable. I don't know how feasible 
> > > that would be.
> >
> > Arguably the "very best" would be to drop npm from Debian ;-)
> >
> > More to the point, however: Do npm work at all without 
> > nodejs-legacy? If not, then npm itself should be moved to contrib!
> > 
> > Actually i believe most modules just work without nodejs-legacy, and 
> > npm itself has some uses without installing it either.
> 
> Yes, it seems it's mainly the modules that provide an executable 
> script that need nodejs-legacy (In my case, coffeelint).

Agreed.

I mentioned it only for completeness.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature


Bug#837994: [debian-mysql] Bug#837994: mysql-5.5: FTBFS on armhf

2016-09-16 Thread Lars Tangvald

build-stamp fails, but there's no error message that I can see

...

[  6%] Building CXX object 
extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/dh.cpp.o
cd /«PKGBUILDDIR»/builddir-pic/extra/yassl/taocrypt && 
/usr/bin/arm-linux-gnueabihf-g++   -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 
-O3 -DBIG_JOINS=1 -felide-constructors -fno-exceptions -fno-rtti -fPIC 
-fno-strict-aliasing   -fPIC -fno-exceptions -fno-rtti -O2 -g -DNDEBUG 
-DDBUG_OFF -I/«PKGBUILDDIR»/builddir-pic/include 
-I/«PKGBUILDDIR»/extra/yassl/taocrypt/mySTL 
-I/«PKGBUILDDIR»/extra/yassl/taocrypt/include 
-I/«PKGBUILDDIR»/include-DHAVE_YASSL -DYASSL_PURE_C -DYASSL_PREFIX 
-DHAVE_OPENSSL -DMULTI_THREADED -fvisibility=hidden -o 
CMakeFiles/taocrypt.dir/src/dh.cpp.o -c 
/«PKGBUILDDIR»/extra/yassl/taocrypt/src/dh.cpp
/usr/bin/cmake -E cmake_progress_report 
/«PKGBUILDDIR»/builddir-pic/CMakeFiles
[  6%] Building CXX object 
extra/yassl/taocrypt/CMakeFiles/taocrypt.dir/src/dsa.cpp.o
cd /«PKGBUILDDIR»/builddir-pic/extra/yassl/taocrypt && 
/usr/bin/arm-linux-gnueabihf-g++   -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 
-O3 -DBIG_JOINS=1 -felide-constructors -fno-exceptions -fno-rtti -fPIC 
-fno-strict-aliasing   -fPIC -fno-exceptions -fno-rtti -O2 -g -DNDEBUG 
-DDBUG_OFF -I/«PKGBUILDDIR»/builddir-pic/include 
-I/«PKGBUILDDIR»/extra/yassl/taocrypt/mySTL 
-I/«PKGBUILDDIR»/extra/yassl/taocrypt/include 
-I/«PKGBUILDDIR»/include-DHAVE_YASSL -DYASSL_PURE_C -DYASSL_PREFIX 
-DHAVE_OPENSSL -DMULTI_THREADED -fvisibility=hidden -o 
CMakeFiles/taocrypt.dir/src/dsa.cpp.o -c 
/«PKGBUILDDIR»/extra/yassl/taocrypt/src/dsa.cpp

debian/rules:142: recipe for target 'build-stamp' failed
make[1]: *** [build-stamp] Error 1
make[1]: *** Waiting for unfinished jobs

...

--

Lars


On 09/16/2016 10:39 AM, Salvatore Bonaccorso wrote:

Source: mysql-5.5
Version: 5.5.52-0+deb8u1
Severity: serious
Justification: FTBFS

Hi

On armhf the latest security-update for mysql-5.5 5.5.52-0+deb8u1
fails to build. Attached is a build log for it.

Regards,
Salvatore


___
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint




Bug#838003: /usr/bin/openssl: unable to write 'random state'

2016-09-16 Thread Ph. Marek
Package: openssl
Version: 1.1.0-1
Severity: normal
File: /usr/bin/openssl

$ openssl rand -base64 3
WTIu
unable to write 'random state'

$ openssl rand 0
unable to write 'random state'

$ strace openssl rand 0
...
close(3)= 0
getuid()= 1044
getuid()= 1044
geteuid()   = 1044
getgid()= 1044
getegid()   = 1044
stat("", 0x7ffe46f65ae0)= -1 ENOENT (No such file or 
directory)
open("", O_WRONLY|O_CREAT, 0600)= -1 ENOENT (No such file or 
directory)
open("", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 ENOENT (No such file or 
directory)
write(2, "unable to write 'random state'\n", 31unable to write 'random 
state'
) = 31
exit_group(1)   = ?
+++ exited with 1 +++



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

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

Versions of packages openssl depends on:
ii  libc6  2.23-5
ii  libssl1.1  1.1.0-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20160104

-- no debconf information



Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

2016-09-16 Thread Niko Tyni
On Tue, Sep 13, 2016 at 10:48:42PM -0500, Bob Friesenhahn wrote:

> It may be necessary to prove where the problem is occuring by manually
> overwriting updated files in the magick directory with those from the
> previous working version until the problem goes away (assuming that it
> does).

I've bisected it to 

 
https://sourceforge.net/p/graphicsmagick/code/ci/4ee2a87a67e064f3a094ee30b40a7a9bba1eb727/

 Use clock_gettime() to obtain elapsed time.

Further observations:

- it also happens with GCC 5
- it goes away if ElapsedTime() or StartTimer() in magick/timer.c are
  optimized with -O0 (bisected with GCC #pragmas)
- it also goes away if LockSemaphoreInfo() in magick/semaphore.c is
  optimized with -O0, which seems weird
- it also goes away if I modify ElapsedTime() in magick/timer.c to
  print out the return value before returning it

I haven't found the exact optimization that's triggering it yet,
and I haven't looked at the code GCC generates.
-- 
Niko Tyni   nt...@debian.org



Bug#837992: nfs problem might be related to rpcbind installation in chroot

2016-09-16 Thread Emmanuel Kasper
Le 16/09/2016 à 10:17, Emmanuel Kasper a écrit :
> Package: cloud.debian.org
> Severity: normal
>
> The libvirt box has problem with the default shared mode (NFS)
>
> A fresh vagrant up from the atlas box brings:
>
> mount -o vers=3,udp
> 192.168.121.1:/home/manu/Projects/vagrenvs/jatlavirtdef /vagrant
> if command -v /sbin/init && /sbin/init --version | grep upstart; then
>   /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/vagrant
> fi
> mount.nfs: rpc.statd is not running but is required for remote locking.
> mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
> mount.nfs: an incorrect mount option was specified
>
> this seens to relate to this bug in Jessie:  #775542
> NFS exports fail due to rpcbind not starting before nfs-common and
> nfs-kernel-server

further debugging showed me that the problem is not related to #775542
but to rpcbind itself

vagrant base boxes include all packages with standard|important
https://anonscm.debian.org/cgit/cloud/debian-vm-templates.git/tree/helpers/vagrant-setup#n35

this pulls rpcbind which is needed for NFSv3 mounts

now this package installation happens within a chroot with
automatic service startup disabled with
printf '#!/bin/sh\nexit 101\n' > $fs/usr/sbin/policy-rc.d

I don't know how much this plays a role, but the rpcbind service
afterwards _never_ starts on boot in the resulting image
even if you try to reenable it manually via

   systemctl enable rpcbind in the created image

I am now wondering if the problem comes from our script or inoperant
startup sequence from rpcbind

@marcin: since you're a bootstrap-vz expert here, do you know if a
debian image created with boostrap-vz exhibits the same behaviour ?
ie when adding rpc package in a boostrap-vz manifest, is  the service
started on boot (systemctl status rpcbind)



Bug#838004: RFS: rear/1.18-1 ITP: rear -- Bare metal disaster recovery and system migration framework

2016-09-16 Thread Frederic Bonnard


Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 Package name: rear
 Version : 1.18-1
 Upstream Author : Schlomo Schapiro, Gratien D'haese, Stefan Semmelroggen, Peer 
Heinlein, Dag Wieers, Jeroen Hoekx
 URL : https://github.com/rear/rear/
 License : GPL-3+, LGPL-2.1+, GPL-2+, CC-BY-ND-3.0
 Section : admin

It builds those binary packages:

  rear  - Bare metal disaster recovery and system migration framework
  rear-doc   - Bare metal disaster recovery and system migration framework 
(documentation)

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

https://mentors.debian.net/package/rear


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

  dget -x https://mentors.debian.net/debian/pool/main/r/rear/rear_1.18-1.dsc

More information about rear can be obtained from http://relax-and-recover.org/

Note:
  There is a load of Info lintians but this is due to the fact that rear embeds
  skeleton files/dirs that won't be use by the system installing rear, but
  those files will be used by the rear OS created to be booted later.


Regards,
 Frederic Bonnard



Bug#838005: RFS: python-arrayfire/3.3.20160624-1

2016-09-16 Thread Ghislain Vaillant

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-arrayfire"

* Package name: python-arrayfire
  Version : 3.3.20160624-1
  Upstream Author : ArrayFire
* URL : https://github.com/arrayfire/arrayfire-python
* License : BSD
  Section : python

It builds those binary packages:

  python-arrayfire - Python wrappers for the ArrayFire library (Python 2)
  python-arrayfire-doc - examples for the ArrayFire Python wrappers
  python3-arrayfire - Python wrappers for the ArrayFire library (Python 3)

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


  https://mentors.debian.net/package/python-arrayfire

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-arrayfire/python-arrayfire_3.3.20160624-1.dsc


Successful builds on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/python-arrayfire/3.3.20160624-1/buildlog

http://debomatic-i386.debian.net/distribution#unstable/python-arrayfire/3.3.20160624-1/buildlog

Changes since the last upload:

  * New upstream release.
  * Patch buggy standalone tests module.
  * Update test override.
  * Simplify packaging testsuite.
  * d/control: add missing Testsuite: autopkgtest.
  * d/control: mark -doc package Multi-Arch: foreign.

Regards,
Ghislain Vaillant



Bug#837940: gnome-twitch-player-backend-mpv-opengl: immediate segmentation fault

2016-09-16 Thread Tim Dengel
On Thu, 15 Sep 2016 19:58:39 +0200 Jonas Smedegaard  wrote:
> Package: gnome-twitch-player-backend-mpv-opengl
> Version: 0.3.0-1
> Severity: grave
> Justification: renders package unusable
> 
> Selecting mpv backend immediately causes segmentation fault.

Hi Jonas,

I can not reproduce this. Can you provide one (or more) of the following
things?

1. Log messages (i.e. run gnome-twitch in a terminal, maybe with a lower
logging level by giving it "--log-level=debug" or something as an argument)

2. A backtrace (install the dbgsym packages for gnome-twitch and
gnome-twitch-player-backend-mpv-opengl and run gnome-twitch in gdb, then
get a full backtrace with the "bt full" command.

3. A core dump (I would rather prefer the first two, if they are meaningful)

It would also be interesting to know what kind of graphics hardware you
have (Intel, NVIDIA, AMD...) and if you have tried other backends (and
whether they work). From your report it seems that the segfault happens
directly on selecting the backend, not on playback, is that correct?
Were you selecting it from the settings dialog[1] outside of a stream,
or when you were prompted to select one when trying to watch a stream?
Does the same happen when you try the other one of the two methods?

Sincerely,
Tim Dengel


[1] You can reach that dialog by clicking on the "gnome-twitch" item in
gnome's "task bar" and then selecting "settings"



Bug#836130: trilinos: FTBFS without __sync_val_compare_and_swap_8

2016-09-16 Thread Graham Inggs
severity 836130 wishlist
retitle 836130 trilinos: FTBFS without __sync_val_compare_and_swap_8
thanks


Hi Aaron

On 30 August 2016 at 20:18, Aaron M. Ucko  wrote:
> Source: trilinos
> Version: 12.6.4-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)

I'm dropping this bug's severity to wishlist as Trilinos last built on
32-bit architectures in 2010 [1], before the Kokkos package was
introduced.  These binaries are not in testing and therefore should
not prevent Trilinos from migrating.

> Thanks for looking into #835406!  trilinos now successfully builds on
> i386 and x32, and the builds for other 32-bit architectures don't fail
> as quickly as they used to, but they nevertheless remain broken (at
> least on mips, mipsel, and powerpc -- builds for other architectures
> are still in progress):

The build was also successful on armhf, but still fails on
architectures without '__sync_val_compare_and_swap_8'.  There's a GCC
bug [2] requesting an implementation, however it has been closed
WONTFIX.  Before you reassign this bug to gcc in Debian, there seems
to be a workaround mentioned in that bug which I intend investigating
when I have some time to spend on a porterbox, probably after the
openmpi transition.

We have opened a PR [3] with upstream, in the hopes that we can work
together on a solution.

Regards
Graham

PS: If you are happy with the outcome of #815725, please close it.


[1] https://buildd.debian.org/status/logs.php?pkg=trilinos&arch=powerpc
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368
[3] https://github.com/kokkos/kokkos/pull/410



Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

2016-09-16 Thread Muammar El Khatib
Hi Cristian,

On Fri, Sep 16, 2016 at 10:27:57AM +0200, Cristian Ionescu-Idbohrn wrote:
> Muammar,
>
> On Fri, 16 Sep 2016, Muammar El Khatib wrote:
> >
> > I hope you are still interested in this.
>
> Of course.
>

Nice!.

> > I have prepared a page in the wiki that you can check:
> >
> > https://github.com/muammar/mkchromecast/wiki/ALSA
> >
> > I would be glad if you could test it. Note that you have to checkout
> > the `alsa` branch.
>
> I would also be glad to do so, if I could figure out how ~/.asoundrc
> must look like.  Currently, the minimal conf to get sound out the
> audio card I prefer is:
>
> ,[ ~/.asoundrc ]
> | pcm.!default {
> | type plug
> | slave.pcm spdif
> | }
> `
>
> Here are some more details on the sound cards on my system:
>

I have prepared two .asoundrc files (asoundrc1 and asoundrc2). You may want to
download them and try them as your .asoundrc file.

> ,[ cat /proc/asound/cards ]
> |  0 [Live   ]: EMU10K1 - SB Live! 5.1 [SB0060]
> |   SB Live! 5.1 [SB0060] (rev.7, serial:0x80611102) at 
> 0xd000, irq 17

asoundrc1 for the case where this is the right card: hw:0,0 is the device.

> |  1 [PCH]: HDA-Intel - HDA Intel PCH
> |   HDA Intel PCH at 0xf723 irq 29

asoundrc1 for the case where this is the right card: hw:1,0 is the device.

>
> ,[ aplay -l ]
> |  List of PLAYBACK Hardware Devices 
> | card 0: Live [SB Live! 5.1 [SB0060]], device 0: emu10k1 [ADC 
> Capture/Standard PCM Playback]
> |   Subdevices: 32/32
> |   Subdevice #0: subdevice #0
> |   Subdevice #1: subdevice #1
> |   Subdevice #2: subdevice #2
> |   Subdevice #3: subdevice #3
> |   Subdevice #4: subdevice #4
> |   Subdevice #5: subdevice #5
> |   Subdevice #6: subdevice #6
> |   Subdevice #7: subdevice #7
> |   Subdevice #8: subdevice #8
> |   Subdevice #9: subdevice #9
> |   Subdevice #10: subdevice #10
> |   Subdevice #11: subdevice #11
> |   Subdevice #12: subdevice #12
> |   Subdevice #13: subdevice #13
> |   Subdevice #14: subdevice #14
> |   Subdevice #15: subdevice #15
> |   Subdevice #16: subdevice #16
> |   Subdevice #17: subdevice #17
> |   Subdevice #18: subdevice #18
> |   Subdevice #19: subdevice #19
> |   Subdevice #20: subdevice #20
> |   Subdevice #21: subdevice #21
> |   Subdevice #22: subdevice #22
> |   Subdevice #23: subdevice #23
> |   Subdevice #24: subdevice #24
> |   Subdevice #25: subdevice #25
> |   Subdevice #26: subdevice #26
> |   Subdevice #27: subdevice #27
> |   Subdevice #28: subdevice #28
> |   Subdevice #29: subdevice #29
> |   Subdevice #30: subdevice #30
> |   Subdevice #31: subdevice #31
> | card 0: Live [SB Live! 5.1 [SB0060]], device 2: emu10k1 efx [Multichannel 
> Capture/PT Playback]
> |   Subdevices: 8/8
> |   Subdevice #0: subdevice #0
> |   Subdevice #1: subdevice #1
> |   Subdevice #2: subdevice #2
> |   Subdevice #3: subdevice #3
> |   Subdevice #4: subdevice #4
> |   Subdevice #5: subdevice #5
> |   Subdevice #6: subdevice #6
> |   Subdevice #7: subdevice #7
> | card 0: Live [SB Live! 5.1 [SB0060]], device 3: emu10k1 [Multichannel 
> Playback]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 1: PCH [HDA Intel PCH], device 0: ALC892 Analog [ALC892 Analog]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 1: PCH [HDA Intel PCH], device 1: ALC892 Digital [ALC892 Digital]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 2: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 2: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 2: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 3: Controller [USB Audio Controller], device 0: USB Audio [USB Audio]
> |   Subdevices: 1/1
> |   Subdevice #0: subdevice #0
> | card 4: Loopback [Loopback], device 0: Loopback PCM [Loopback PCM]
> |   Subdevices: 8/8
> |   Subdevice #0: subdevice #0
> |   Subdevice #1: subdevice #1
> |   Subdevice #2: subdevice #2
> |   Subdevice #3: subdevice #3
> |   Subdevice #4: subdevice #4
> |   Subdevice #5: subdevice #5
> |   Subdevice #6: subdevice #6
> |   Subdevice #7: subdevice #7
> | card 4: Loopback [Loopback], device 1: Loopback PCM [Loopback PCM]
> |   Subdevices: 8/8
> |   Subdevice #0: subdevice #0
> |   Subdevice #1: subdevice #1
> |   Subdevice #2: subdevice #2
> |   Subdevice #3: subdevice #3
> |   Subdevice #4: subdevice #4
> |   Subdevice #5: subdevice #5
> |   Subdevice #6: subdevice #6
> |   Subdevice #7: subdevice #7
> `
>
> Cards 0 and 1 connected to speakers.
>

Now, your Loopback's index is 4, and mkchromecast command should be:

python mkchromecast.py --encoder-backend ffmpeg --alsa-device hw:4,1 -c ogg
--volume

Did it work?.

> > Regarding the two interfaces in your machine, was the chromecast
> > detected? If yes, I think I can provide a flag where you can sp

Bug#815760: dpdk debian packaging

2016-09-16 Thread Luca Boccassi
On Sep 16, 2016 08:53, "santiag...@riseup.net" 
wrote:
>
> El 15/09/16 a las 09:04, Christian Ehrhardt escribió:
> >
> > On Wed, Sep 14, 2016 at 6:28 PM, Luca Boccassi 
wrote:
> >
> > Christian has sent patches upstream a couple weeks back:
> >
> > http://dpdk.org/dev/patchwork/patch/15553/
>
> Great!
>
> > And we carry the former version of that submission as a patch for now
to fix
> > packaging as-is for now.
> > Once accepted upstream that delta will be rebased for 16.07 topic
branch to
> > match the accepted version.
> > For 16.11 I expect them to be upstream so on that topic branch we can
drop the
> > delta then.
>
> So would you like to include it in debian/patches for now?
>
>
> Attached you can find other three patches to fix minor issues, and make
> lintian happier.
> What else would be needed to upload to debian?
>
> Cheers, and thanks a lot for your work!
>
> Santiago

Hi,

Thanks again, but could you please add the signoff to your patches? We
cannot apply them as-is otherwise.

Thanks!

Kind regards,
Luca Boccassi


Bug#838002: Libreoffice-writer formatting dialogs take too long to open

2016-09-16 Thread Rene Engelhard
tag 838002 + moreinfo
thanks

Hi,

On Fri, Sep 16, 2016 at 11:37:04AM +0200, Leon Meier wrote:
> Opening the dialog Format->Character from the menu took around 1 min 41 sec.
> I tried:
> - removing the .config/libreoffice directory
> - increasing usable memory in the extras->options
> - # fc-cache -f -v
> After the last action, the delay went down to 1 minute. Still way to long.
> The bug is consistently repeatable.
> My distribution is an up-to-date sid.

Then you probably got affected by #837356, too?

> Any help?

Yes, see above. (And this is per se not "something for help" but a bug tracking
system ;))

Regards,

Rene
> 



Bug#837989: openocd: can no longer use SheevaPlug JTAGKey FT2232D (regression)

2016-09-16 Thread David Madore
On Fri, Sep 16, 2016 at 11:13:53AM +0300, Paul Fertser wrote:
> On Fri, Sep 16, 2016 at 09:55:21AM +0200, David Madore wrote:
> > A SheevaPlug JTAGKey FT2232D (USB identifiers 9e88:9e8f) being
> 
> Please also provide lsusb -vvv data for this device.

Bus 003 Device 002: ID 9e88:9e8f  
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x9e88 
  idProduct  0x9e8f 
  bcdDevice5.00
  iManufacturer   1 FTDI
  iProduct2 SheevaPlug JTAGKey FT2232D B
  iSerial 3 FTU85Z4Y
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   55
bNumInterfaces  2
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  2 SheevaPlug JTAGKey FT2232D B
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  2 SheevaPlug JTAGKey FT2232D B
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04  EP 4 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Device Status: 0x
  (Bus Powered)

> > worked fine with it:
> ...
> > Error: JTAG scan chain interrogation failed: all zeroes
> 
> No, this doesn't look fine to me.

Indeed, the JTAG connector was badly connected at the other end.
Here's what the output of openocd 0.5.0-1 looks like when it's
correctly connected (to a GuruPlug):

vega david ~ $ /tmp/openocd-0.5.0/src/openocd -s /tmp/openocd-0.5.0/tcl -f 
/tmp/openocd-0.5.0/tcl/board/sheevaplug.cfg
Open On-Chip Debugger 0.5.0 (2016-09-16-09:33)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
2000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
dcc downloads are enabled
Warn : use 'feroceon.cpu' as target identifier, not '0'
sheevaplug_load_uboot
Info : clock speed 2000 kHz
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 
0x0a02, ver: 0x2)
Info : Embedded ICE version 0
Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit

- and in case that's of any use, here's the additional stuff it says
when I run "reset ; init ; sheevaplug_load_uboot" from the telnet
interface:

Info : accepting 'telnet' connection from 
Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 
0x0a02, ver: 0x2)
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x00d3 pc: 0x
MMU: disabled, D-Cache: disabled, I-Cache: disabled
230196 bytes written at addre

Bug#815760: dpdk debian packaging

2016-09-16 Thread Christian Ehrhardt
Hi,
I reviewed, split and posted your changes to the project for further review
and acceptance along with my man page changes.
Thanks for your contribution.

With all those applied and the recent work of luca lintian is happy with us
now.

But we should no more hijack that bug.
Please for any further discussion comments use mailing list and gerrit of
https://wiki.fd.io/view/Deb_dpdk


On Fri, Sep 16, 2016 at 9:52 AM, santiag...@riseup.net <
santiag...@riseup.net> wrote:

> El 15/09/16 a las 09:04, Christian Ehrhardt escribió:
> >
> > On Wed, Sep 14, 2016 at 6:28 PM, Luca Boccassi 
> wrote:
> >
> > Christian has sent patches upstream a couple weeks back:
> >
> > http://dpdk.org/dev/patchwork/patch/15553/
>
> Great!
>
> > And we carry the former version of that submission as a patch for now to
> fix
> > packaging as-is for now.
> > Once accepted upstream that delta will be rebased for 16.07 topic branch
> to
> > match the accepted version.
> > For 16.11 I expect them to be upstream so on that topic branch we can
> drop the
> > delta then.
>
> So would you like to include it in debian/patches for now?
>
>
> Attached you can find other three patches to fix minor issues, and make
> lintian happier.
> What else would be needed to upload to debian?
>
> Cheers, and thanks a lot for your work!
>
> Santiago
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd


Bug#838002: Libreoffice-writer formatting dialogs take too long to open

2016-09-16 Thread Leon Meier

tag 838002 - moreinfo
thanks

On 16.09.2016 12:13, Rene Engelhard wrote:

tag 838002 + moreinfo
thanks

Hi,

On Fri, Sep 16, 2016 at 11:37:04AM +0200, Leon Meier wrote:

Opening the dialog Format->Character from the menu took around 1 min 41 sec.
I tried:
- removing the .config/libreoffice directory
- increasing usable memory in the extras->options
- # fc-cache -f -v
After the last action, the delay went down to 1 minute. Still way to long.
The bug is consistently repeatable.
My distribution is an up-to-date sid.


Then you probably got affected by #837356, too?


Yes.


Any help?


Yes, see above. (And this is per se not "something for help" but a bug tracking
system ;))

Thank you.
Downgrading libgtk-3 from to libgtk-3-0_3.20.9-1 fixes the bug.
Please feel free to merge.



Regards,

Rene






Bug#831065: python-kinterbasdb: please make the build reproducible

2016-09-16 Thread Santiago Vila
On Thu, 15 Sep 2016, Chris Lamb wrote:

> Dear Maintainer,
> 
> > Source: python-kinterbasdb
> > Version: 3.3.0-2
> > Tags: patch
> 
> There hasn't seem to be any update on this bug in 63 days, in which
> time the Reproducible Builds effort has come on a long way. :)
> 
> Would you consider applying this patch and uploading?

Hello Chris.

This package is orphaned and it's in collab-maint, so I just went
ahead, pushed your patch to git (with some additional metadata), and
made a QA upload.

While doing so I found this error:

remote: Migrating settings from hooks.* to multimailhook.*
remote: [...]
remote: git_multimail.ConfigurationException: The list of recipients
for refchangelist is not configured.
remote: Please set one of the following:
remote: "multimailhook.refchangelist"
remote: "multimailhook.mailinglist"

If you want to fix this, or explain briefly what's the proper way I
could fix it, I'll apreciate it.

But maybe for another project, because later I realized this one seems
to be obsolete:

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

Thanks.



Bug#838002: Libreoffice-writer formatting dialogs take too long to open

2016-09-16 Thread Rene Engelhard
reassign 838002 libreoffice-gtk3
forcemerge 837356 838002
thanks

Hi,

On Fri, Sep 16, 2016 at 12:45:46PM +0200, Leon Meier wrote:
> tag 838002 - moreinfo
> thanks
> 
> On 16.09.2016 12:13, Rene Engelhard wrote:
> >tag 838002 + moreinfo
> >thanks
> >
> >Hi,
> >
> >On Fri, Sep 16, 2016 at 11:37:04AM +0200, Leon Meier wrote:
> >>Opening the dialog Format->Character from the menu took around 1 min 41 sec.
> >>I tried:
> >>- removing the .config/libreoffice directory
> >>- increasing usable memory in the extras->options
> >>- # fc-cache -f -v
> >>After the last action, the delay went down to 1 minute. Still way to long.
> >>The bug is consistently repeatable.
> >>My distribution is an up-to-date sid.
> >
> >Then you probably got affected by #837356, too?
> >
> Yes.
[...]
> Please feel free to merge.

Doing, thanks

Regards,

Rene
> 



Bug#837712: xemacs21: FTBFS with bindnow and PIE enabled

2016-09-16 Thread Mark Brown
On Tue, Sep 13, 2016 at 09:25:13PM +0200, Balint Reczey wrote:

> For more information about the changes to sid's dpkg and GCC please
> visit:
>  https://wiki.debian.org/Hardening/PIEByDefaultTransition

You've not provided any instructions for reproducing this problem :(


signature.asc
Description: PGP signature


Bug#831065: python-kinterbasdb: please make the build reproducible

2016-09-16 Thread Chris Lamb
> While doing so I found this error:
> 
> remote: Migrating settings from hooks.* to multimailhook.*

This looks like something wrong in the collab-maint git repo; I have no
insight there, alas :)


Regards,

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



Bug#837225: xemacs21: FTBFS: Can't locate var_file.pl in @INC

2016-09-16 Thread Mark Brown
On Sat, Sep 10, 2016 at 09:30:31AM +0200, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build on
> amd64.

FFS, why did this suddenly break and if it's due to the perl include
transition why did it not get reported in the mass bug filing for this?


signature.asc
Description: PGP signature


Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

2016-09-16 Thread Cristian Ionescu-Idbohrn
On Fri, 16 Sep 2016, Muammar El Khatib wrote:
> On Fri, Sep 16, 2016 at 10:27:57AM +0200, Cristian Ionescu-Idbohrn wrote:
>
> I have prepared two .asoundrc files (asoundrc1 and asoundrc2).

Thanks.

> You may want to download them and try them as your .asoundrc file.
>
> > ,[ cat /proc/asound/cards ]
> > |  0 [Live   ]: EMU10K1 - SB Live! 5.1 [SB0060]
> > |   SB Live! 5.1 [SB0060] (rev.7, serial:0x80611102) at 
> > 0xd000, irq 17
>
> asoundrc1 for the case where this is the right card: hw:0,0 is the device.

I tested both.  But let's discuss asoundrc1.  Problem is that this
block:

,
| pcm.!default {
|   type asym
|   playback.pcm "LoopAndReal"
|   #capture.pcm "looprec"
|   capture.pcm "hw:0,0"
| }
`

overwrites this one:

,
| pcm.!default {
| type plug
| slave.pcm spdif
| }
`

which I _must_ have in order to get sound out to the speakers through
card 0.

> Now, your Loopback's index is 4,

Right.

> and mkchromecast command should be:
> python mkchromecast.py --encoder-backend ffmpeg --alsa-device hw:4,1 -c ogg 
> --volume
>
> Did it work?.

,
| hw:4,1
| hw:4,1
| mkchromecast v0.3.6
| Starting local streaming server
| [Done]
| Traceback (most recent call last):
|   File "./mkchromecast.py", line 50, in 
| import mkchromecast.audio
|   File ".../mkchromecast/audio.py", line 21, in 
| from flask import Flask, Response, request
| ImportError: No module named flask
`

Looks like I'm missing some 'python-flask' package.


Cheers,

-- 
Cristian



Bug#838006: r-cran-shiny: adequate says broken symlink in r-cran-shiny

2016-09-16 Thread shirish शिरीष
Package: r-cran-shiny
Version: 0.13.2+dfsg-2
Severity: normal
Usertags: broken-symlink adequate
User: debian...@lists.debian.org

Dear Maintainer,
While installing r-cran-shiny, got the following -

r-cran-shiny: broken-symlink
/usr/lib/R/site-library/shiny/www/shared/datepicker/js/bootstrap-datepicker.min.js
->
../../../../../../../../share/twitter-bootstrap/files/js/bootstrap-datepicker.min.js

and going down through the road, found that the share directory is not
in the path that is given -

┌─[shirish@debian] -
[/usr/lib/R/site-library/shiny/www/shared/datepicker] - [10329]
└─[$] ls

css  js  less

only three directories and none of them are named share.

Please fix the bug.

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 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 r-cran-shiny depends on:
ii  fonts-font-awesome  4.6.3~dfsg-1
ii  libjs-bootstrap 3.3.6+dfsg-1
ii  libjs-es5-shim  4.5.9-1
ii  libjs-highlight.js  8.2+ds-4
ii  libjs-jquery1.12.4-1
ii  libjs-jquery-datatables 1.10.12+dfsg-1
ii  libjs-jquery-ui 1.10.1+dfsg-1
ii  libjs-json  0~20160510-1
ii  libjs-twitter-bootstrap 2.0.2+dfsg-9
ii  libjs-twitter-bootstrap-datepicker  1.3.1+dfsg1-1
ii  r-base-core [r-api-3]   3.3.1-1+b1
ii  r-cran-digest   0.6.10-1
ii  r-cran-ggplot2  2.1.0-3
ii  r-cran-htmltools0.3.5-2
ii  r-cran-httpuv   1.3.3-3
ii  r-cran-jsonlite 1.0-1
ii  r-cran-mime 0.4-2
ii  r-cran-r6   2.1.3-1
ii  r-cran-rcpp 0.12.7-1
ii  r-cran-xtable   1:1.8-2-1

r-cran-shiny recommends no packages.

r-cran-shiny suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8



Bug#838005: RFS: python-arrayfire/3.3.20160624-1

2016-09-16 Thread Ghislain Vaillant
On Fri, 2016-09-16 at 11:07 +, Gianfranco Costamagna wrote:
> Hi,
> 
> > 
> > I am looking for a sponsor for my package "python-arrayfire"
> 
> 
> I see upstream changes wrt sphinx documentation.
> 
> Please consider trying to build the sphinx documentation in the -doc
> package for a future release (if possible and not already done, I
> didn't
> check)
> 
> thanks
> 
> G.

You are correct, I forgot to include the sphinx docs.

I will correct this in a subsequent release.

Thanks for sponsoring.

Ghis




Bug#838007: trigger-rally-data: Adequate reports broken symlink at changelog.gz

2016-09-16 Thread shirish शिरीष
Package: trigger-rally-data
Version: 0.6.4+dfsg-1
Severity: normal
Usertags: broken-symlink adequate
User: debian...@lists.debian.org

Dear Maintainer,
Adequate reported the following broken symlink -

trigger-rally-data: broken-symlink
/usr/share/doc/trigger-rally-data/changelog.gz -> README.txt.gz

I looked and found out there is not README.txt.gz in
/usr/share/doc/trigger-rally-data -

┌─[shirish@debian] - [/usr/share/doc/trigger-rally-data] - [10337]
└─[$] ls

changelog.Debian.gz  changelog.gz  copyright

Please fix the above.

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 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)

trigger-rally-data depends on no packages.

Versions of packages trigger-rally-data recommends:
ii  trigger-rally  0.6.4+dfsg-1

trigger-rally-data suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8



Bug#831240: google-perftools: FTBFS: Running death test 0 hangs

2016-09-16 Thread Lucas Nussbaum
Hi,

On 15/09/16 at 19:39 +0200, Santiago Vila wrote:
> Hello.
> 
> This package is still a headache for my autobuilder.
> 
> On Tue, 19 Jul 2016, Lucas Nussbaum wrote:
> 
> > Indeed it was the equivalent of dpkg-buildpackage -A that
> > triggered it.
> 
> Do you mean you could always reproduce with "dpkg-buildpackage -A"
> and never with "dpkg-buildpackage"?
> 
> Later you said:
> 
> > [ sysctl tunings ]
> > It seems that one of those caused that failure, because, now that I have
> > them disabled, it does not fail anymore.
> 
> Are you sure that removing those settings is the real reason it stopped
> failing for you? (Would you try a few more times?)
> 
> It still fails for me, randomly, and I'm not using EC2 but KVM on my
> own server and KVM on a commercial provider, so my alternate theory is
> that it was random before you dropped the settings, and it continues
> to be random after dropping the settings.
> 
> This is my historic data:
> 
> Status: failed  google-perftools_2.2.1-0.2_amd64-20151025T1748Z
> Status: failed  google-perftools_2.2.1-0.2_amd64-20151201T1848Z
> Status: failed  google-perftools_2.2.1-0.2_amd64-20151220T1430Z
> Status: failed  google-perftools_2.2.1-0.2_amd64-20160101T2221Z
> Status: failed  google-perftools_2.2.1-0.2_amd64-20160507T1523Z
> Status: failed  google-perftools_2.2.1-0.2_amd64-20160507T1649Z
> Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T055103Z
> Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T150752Z
> Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T151026Z
> Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T151114Z
> Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T161241Z
> Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T151357Z
> Status: successful  google-perftools_2.2.1-0.3_amd64-20160914T161322Z
> Status: successful  google-perftools_2.2.1-0.3_amd64-20160914T161612Z
> Status: successful  google-perftools_2.2.1-0.3_amd64-20160914T161656Z
> Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T161654Z
> Status: failed  google-perftools_2.2.1-0.3_amd64-20160914T161043Z
> 
> 
> Version 2.2.1-0.3 is the first one that does not *always* fail for me.
> This is a great achievement indeed.
> 
> Now it builds sometimes, but 3/11 is not a very good ratio.

I'm not sure, no. It's indeed possible that it's still failing randomly.

Lucas



Bug#838008: trigger-rally-data: adequate reports obsolete conffile

2016-09-16 Thread shirish शिरीष
Package: trigger-rally-data
Version: 0.6.4+dfsg-1
Severity: normal
Usertags: obsolete-conffile adequate
User: debian...@lists.debian.org

Dear Maintainer,
Adequate reports obsolete-conffile for trigger-rally-data -

┌─[shirish@debian] - [~] - [10342]
└─[$] adequate trigger-rally-data

trigger-rally-data: broken-symlink
/usr/share/doc/trigger-rally-data/changelog.gz -> README.txt.gz
trigger-rally-data: obsolete-conffile /etc/trigger.config.defs

I have already filed a bug for the broken symlink, please fix the
obsolete-conffile issue too.

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/2 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)

trigger-rally-data depends on no packages.

Versions of packages trigger-rally-data recommends:
ii  trigger-rally  0.6.4+dfsg-1

trigger-rally-data suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8



Bug#836531: Bug#837356: libreoffice-gtk3: Impress is unusably slow on GNOME 3 with libreoffice-gtk3 installed

2016-09-16 Thread Rene Engelhard
tag 837356 + upstream
tag 837356 + fixed-upstream
tag 837356 + patch
thanks

Hi,

On Thu, Sep 15, 2016 at 10:59:52AM +0200, Rene Engelhard wrote:
> Cc'ing #836531 and -gtk-gnome.

For -gtk-gnomes sake:

commit 0f116135f4a5033ce4e9dfa19f10624701fa615c
Author: Matthias Clasen 
Date:   Fri May 6 10:12:14 2016 -0400

Avoid emitting ::style-set by name

GtkStyle is deprecated, but we still emit ::style-set quite
a bit, so lets at least not be slow while doing it.

in Gtk caused it, but it's fixed in LOs master
(https://cgit.freedesktop.org/libreoffice/core/commit/?id=ef7abe81df10cb8a8c04afbb1fbe700f94e73f04)

Will backport.

Regards,

Rene



Bug#838010: uftp: French debconf templates translation

2016-09-16 Thread Steve Petruzzello
Package: uftp
Version: 4.9.2-1
Severity: wishlist
Tags: patch l10n

Hi,

Please find attached the french debconf templates translation, proofread by the
debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Best,
Steve
# Translation of uftp debconf template to French
# Copyright (C) 2016 Debian French l10n Team 
# This file is distributed under the same license as the uftp package.
# Steve Petruzzello 
#
msgid ""
msgstr ""
"Project-Id-Version: uftp_4.9.2-1\n"
"Report-Msgid-Bugs-To: u...@packages.debian.org\n"
"POT-Creation-Date: 2016-08-25 19:08+0200\n"
"PO-Revision-Date: 2016-09-16 13:30+0200\n"
"Last-Translator: Steve Petruzzello \n"
"Language-Team: LANGUAGE \n"
"Language: \n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: string
#. Description
#: ../uftp.templates:1001
msgid "Destination directories for received files:"
msgstr "Répertoire de destination des fichiers reçus :"

#. Type: string
#. Description
#: ../uftp.templates:1001
msgid ""
"When an incoming file specifies an absolute path, it must match one of the "
"destination directories, otherwise the file will be rejected. Incoming files "
"that don't specify an absolute path will be received into the first "
"destination directory in the list."
msgstr ""
"Quand un fichier entrant indique un chemin absolu, celui-ci doit "
"correspondre à l'un des répertoires de destination sinon le fichier sera "
"rejeté. Les fichiers entrants qui n'indiquent pas de chemin absolu seront "
"placés dans le premier répertoire de destination de la liste."

#. Type: string
#. Description
#: ../uftp.templates:1001
msgid "Default is '/tmp'."
msgstr "Le répertoire par défaut est « /tmp »."

#. Type: string
#. Description
#: ../uftp.templates:2001
msgid "Extra arguments passed to uftpd:"
msgstr "Arguments additionnels passés à uftpd :"

#. Type: string
#. Description
#: ../uftp.templates:2001
msgid "Commonly used arguments:"
msgstr "Arguments couramment utilisés :"

#. Type: string
#. Description
#: ../uftp.templates:2001
msgid ""
" '-t' for writing the received data into the destination directory.\n"
" '-k ' can be used to specify key-files for encrypted transfers.\n"
" '-I ' can be used to specify the network interface to listen on."
msgstr ""
" '-t' pour enregistrer le nouveau fichier dans le répertoire de "
"destination.\n"
" '-k ' pour indiquer des fichiers de clé pour les transfert "
"chiffrés.\n"
" '-I ' pour indiquer l'interface réseau sur laquelle écouter."

#. Type: string
#. Description
#: ../uftp.templates:2001
msgid "See 'man 1 uftpd' for details."
msgstr "Consulter « man 1 uftpd » pour les détails."


Bug#838009: modsecurity-crs: Apache2 dont start after activate modsecurity rule modsecurity_crs_16_session_hijacking.conf

2016-09-16 Thread Karsten Schoeke
Package: modsecurity-crs
Version: 2.2.9-1
Severity: important

Dear Maintainer,

apache2 dont start after activate modsecurity rule
modsecurity_crs_16_session_hijacking.conf

:~> sudo apache2ctl configtest
AH00526: Syntax error on line 51 of
/etc/modsecurity/modsecurity_crs_16_session_hijacking.conf:
ModSecurity: Disruptive actions can only be specified by chain starter
rules.
Action 'configtest' failed.
The Apache error log may have more information.

Pls see this commit:
https://github.com/SpiderLabs/owasp-modsecurity-crs/commit/e2fbef4ce89fed0c4dd338002b9a090dd2f6491d
This fix the prblem, pls insert the fix in Debian package.

Regard
Karsten

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

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

Versions of packages modsecurity-crs depends on:
ii  libapache2-mod-security2  2.8.0-3

modsecurity-crs recommends no packages.

Versions of packages modsecurity-crs suggests:
pn  geoip-database-contrib  
pn  lua 
ii  ruby1:2.1.5+deb8u2

-- no debconf information



Bug#837982: mutt: sort order different in sidebar

2016-09-16 Thread Richard Russon
Hi Philipp,

> The IMAP folders in the sidebar are ordered differently than those in the 
> browser (sorted alphanumerically, of course)

Ah, good.  A nice easy, entertaining bug :-)

I've changed the Sidebar to "collate" the strings, rather than just
"sort" them.   This is what the browser does.

This is fixed in NeoMutt commit: 5e146b1

Rich / FlatCap
NeoMutt maintainer



signature.asc
Description: PGP signature


Bug#837996: ftp.debian.org: Please enable auto building of seqan

2016-09-16 Thread Andreas Tille
Hi again,

Gianfranco Costamagna had the hint that in addition I should mention
exolicitly that the binary package seqan-apps (which has an rdepends to
gasic) was removed from the seqan source package but will be created
now by the seqan2 source package which is in new.  So if this relation
might stop you from triggering the autobuild it should be solved once
seqan2 is accepted.

Kind regards

  Andreas.

On Fri, Sep 16, 2016 at 10:48:34AM +0200, Andreas Tille wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Hi ftpmasters,
> 
> as per this hint on Debian Mentors list[1] I hereby ask you for help to
> let the seqan package be auto-build.  The fact that the seqan-app
> package was dropped from the binary packages might have caused this
> issue which might have been hidden by my source only upload.
> 
> Thanks for your ftpmaster work
> 
>  Andreas.
> 
> 
> [1] https://lists.debian.org/debian-mentors/2016/09/msg00274.html
> 

-- 
http://fam-tille.de



Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades

2016-09-16 Thread Axel Beckert
Hi Keshav,

Keshav Kini wrote:
> When upgrading packages, aptitude users might like to know whether each
> upgrade represents a newer upstream version of the package, or is merely
> a Debian-specific change.  This can be determined by comparing the
> current and candidate versions in the rightmost two columns of the
> package listing, but I thought it might be easier to see at a glance if
> these two kinds of upgrades were colored differently in the UI.
> 
> The attached patch (directly importable into git) makes upgrades that
> represent a newer upstream version appear in bold, while upgrades that
> represent a Debian revision bump appear as before.

Interesting ideas (both, separating upstream from packaging changes as
well as using the bold attribute for highlighting).

Will probably have to try it so see how it feels, but in general I
like the idea. So thanks for having already included a patch!

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



Bug#838011: gitlab-ci-multi-runner - No gitlab-runner-prebuilt.tar.xz

2016-09-16 Thread Bastian Blank
Package: gitlab-ci-multi-runner
Version: 1.5.2+dfsg-1
Severity: important

A clean installation using docker.io fails every build with a missing
gitlab-runner-prebuilt.tar.xz.  Please fail during startup so this
condition is properly logged in system log and not build log sent to the
user.

Bastian

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

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



Bug#838012: gitlab-ci-multi-runner - Missing gitlab-runner-helper in prebuilt

2016-09-16 Thread Bastian Blank
Package: gitlab-ci-multi-runner
Version: 1.5.2+dfsg-1
Severity: important

gitlab-runner-helper is not installed in the prebuilt image.  This makes
the use of caching between builds impossible.

Bastian

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

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



Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

2016-09-16 Thread Cristian Ionescu-Idbohrn
On Fri, 16 Sep 2016, Cristian Ionescu-Idbohrn wrote:
>
> ,
> | hw:4,1
> | hw:4,1
> | mkchromecast v0.3.6
> | Starting local streaming server
> | [Done]
> | Traceback (most recent call last):
> |   File "./mkchromecast.py", line 50, in 
> | import mkchromecast.audio
> |   File ".../mkchromecast/audio.py", line 21, in 
> | from flask import Flask, Response, request
> | ImportError: No module named flask
> `
>
> Looks like I'm missing some 'python-flask' package.

Alright, found that myself and installed package 'python-flask'.
Having done that, progress ;)

Cast media controller status

CastStatus(is_active_input=False, ..., status_text=u'Ready To Cast')


Controls:
=

Volume up: u
Volume down: d
Quit the application: q or Ctrl-C

192.168.x.y - - [16/Sep/2016 13:40:45] "GET /stream HTTP/1.1" 200 -

and sound out the TV speakers.  Fun :)


Cheers,

-- 
Cristian



Bug#820984: proftpd-basic: cannot preseed / ignores local config changes

2016-09-16 Thread Hilmar Preuße

tags 820984 + help
stop

On 14.04.2016 12:25, Florian Ernst wrote:

Hi,


please consider the following (abridged) transcript of trying to run
proftpd-basic from inetd, but ending up having it running
standalone:

Im played a little bit on that bug, w/o success. Initially there was the 
following code in the ...config file:



#!/bin/sh

set -e

# Source debconf library.
. /usr/share/debconf/confmodule

action=$1
version=$2

db_title ProFTPD configuration
db_input high shared/proftpd/inetd_or_standalone || true
db_go


and here is the relevant part of the template file:


Template: shared/proftpd/inetd_or_standalone
Type: select
__Choices: from inetd, standalone
Default: standalone


However I'm failing to understand, what is wrong on that code as it is 
nearly a copy of the template examples delivered w/ debconf. Of course 
the fix for debbug#707689 was wrong:


+db_set shared/proftpd/inetd_or_standalone standalone
 db_input high shared/proftpd/inetd_or_standalone || true
-db_go
+db_go || true

At first I suspected the  in the possible values "from inetd" 
could be a problem, I replaced it by "_" w/o solving the problem.


Could anybody have a look at the problem and give an advise? Tagging it 
"help" for now.


Hilmar
--
http://www.hilmar-preusse.de.vu/   #206401 http://counter.li.org



Bug#699149: bacula-fd: should not run as 'root' by default

2016-09-16 Thread Carsten Leonhardt
Control: tag -1 - wontfix
Control: tag -1 + confirmed
Control: retitle -1 Make running bacula-fd as non-root easier

While the default will not be to run as non-root, it will likely become
a debconf question, and so could be preseeded.

And to correct my earlier statement - it is possible to backup the
entire system, but the restore will not work as expected if the bacula-fd
isn't running as root.



Bug#838013: RM: trigger-rally-data -- ROM; obsolete; taken over by trigger-rally

2016-09-16 Thread James Cowgill
Package: ftp.debian.org
Severity: normal

Hi,

The trigger-rally-data package is now built from the main trigger-rally
source, so the old trigger-rally-data source is no longer needed.

Just to be clear, these should be removed:
 trigger-rally-data | 0.6.1-2   | unstable| source, all

but not this one:
 trigger-rally-data | 0.6.4+dfsg-1  | unstable| all

Thanks,
James



signature.asc
Description: OpenPGP digital signature


Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

2016-09-16 Thread Niko Tyni
On Fri, Sep 16, 2016 at 12:56:37PM +0300, Niko Tyni wrote:

> I haven't found the exact optimization that's triggering it yet,

At -O1 it goes away with -fno-inline-functions-called-once .

> and I haven't looked at the code GCC generates.

Diffstat for timer.s between -O1 and "-O1 -fno-inline-functions-called-once" is

 1 file changed, 605 insertions(+), 492 deletions(-)

Not sure how helpful that is.
-- 
Niko



Bug#837970: Apt simulation improvements

2016-09-16 Thread Kevin Mills
My request is more general than that. The idea is that you could chain
*any* apt commands together as a single simulation. Such as, for example, a
sequence consisting of:

add-apt-repository -y ppa:footeam/foo
apt -y update
apt -y upgrade
apt -y install foo bar

However, install with "+" or "-" does solve my immediate problem, so thank
you for that, but I still think allowing arbitrarily complex simulations
would be a good idea, assuming it's not prohibitively difficult to
implement.

On Fri, Sep 16, 2016 at 3:21 AM, David Kalnischkies 
wrote:

> On Thu, Sep 15, 2016 at 10:06:55PM -0400, Kevin Mills wrote:
> > It should be possible to continue a simulation through several
> invocations
> > of apt. As it is, you can only do a simulation of one thing; you can't
> > simulate, for example, installing package X and removing package Y, only
> > one or the other.
>
> You can install & remove packages at the same time. All "apt install" or
> "apt remove" does is set a default for unqualified package names. If you
> want to install a package append a '+' to its name, if you want it
> removed append a '-'.
>
> e.g.: apt install -s awesome apt-doc+ dpkg-dev-
>
> This installs (or upgrades) 'awesome' and 'apt-doc' and removes
> 'dpkg-dev'.
>
>
> Is that what you are asking for?
>
>
> Best regards
>
> David Kalnischkies
>


Bug#835608: mkchromecast: fails to Open pavucontrol and select the mkchromecast sink.

2016-09-16 Thread Cristian Ionescu-Idbohrn
On Fri, 16 Sep 2016, Cristian Ionescu-Idbohrn wrote:
>
> and sound out the TV speakers.  Fun :)

One thing I noticed is that if I _first_ start mkchromecast and play
some sound file _after_, the player (in this case mpg123) will bail
out with:

,
| [format.c:295] error: Unable to set up output format! Constraints: 44100, 
22050 or 11025Hz.
| [mpg123.c:695] error: ...in decoding next frame: Unable to set up output 
format! (code 1)
`

If I now kill (^C) mkchromecast, I get this trace:

,
| 192.168.x.y - - [16/Sep/2016 14:01:07] "GET /stream HTTP/1.1" 200 -
| Process Process-1:
| Traceback (most recent call last):
|   File "/usr/lib/python2.7/multiprocessing/process.py", line 258, in 
_bootstrap
| self.run()
|   File "/usr/lib/python2.7/multiprocessing/process.py", line 114, in run
| self._target(*self._args, **self._kwargs)
|   File ".../mkchromecast/audio.py", line 523, in start_app
| app.run(host= '0.0.0.0')
|   File "/usr/lib/python2.7/dist-packages/flask/app.py", line 843, in run
| run_simple(host, port, self, **options)
|   File "/usr/lib/python2.7/dist-packages/werkzeug/serving.py", line 694, in 
run_simple
| inner()
|   File "/usr/lib/python2.7/dist-packages/werkzeug/serving.py", line 659, in 
inner
| srv.serve_forever()
|   File "/usr/lib/python2.7/dist-packages/werkzeug/serving.py", line 499, in 
serve_forever
| HTTPServer.serve_forever(self)
|   File "/usr/lib/python2.7/SocketServer.py", line 233, in serve_forever
| self._handle_request_noblock()
|   File "/usr/lib/python2.7/SocketServer.py", line 292, in 
_handle_request_noblock
| self.handle_error(request, client_address)
|   File "/usr/lib/python2.7/SocketServer.py", line 290, in 
_handle_request_noblock
| self.process_request(request, client_address)
|   File "/usr/lib/python2.7/SocketServer.py", line 318, in process_request
| self.finish_request(request, client_address)
|   File "/usr/lib/python2.7/SocketServer.py", line 331, in finish_request
| self.RequestHandlerClass(request, client_address, self)
|   File "/usr/lib/python2.7/SocketServer.py", line 654, in __init__
| self.finish()
|   File "/usr/lib/python2.7/SocketServer.py", line 713, in finish
| self.wfile.close()
|   File "/usr/lib/python2.7/socket.py", line 283, in close
| self.flush()
|   File "/usr/lib/python2.7/socket.py", line 307, in flush
| self._sock.sendall(view[write_offset:write_offset+buffer_size])
| error: [Errno 32] Broken pipe
`

The terminal gets messed up and needs to be `reset'.

If I first start the player and mkchromecast after, it works fine.
I can stop and start the player as I please, no apparent troubles.


Cheers,

-- 
Cristian



Bug#838014: RFS: imagemagick

2016-09-16 Thread Bastien ROUCARIES
Package: sponsorship-requests
Severity: important
X-Debbugs-CC: Mattia Rizzolo 
X-Debbugs-CC: Salvatore Bonaccorso 


  Dear mentors,

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

 * Package name: imagemagick
   Version : 8:6.9.5.9+dfsg-1
   Section : graphics

  It builds those binary packages:

imagemagick - image manipulation programs -- binaries
 imagemagick-6-common - image manipulation programs -- infrastructure
 imagemagick-6-doc - document files of ImageMagick
 imagemagick-6.q16 - image manipulation programs -- quantum depth Q16
 imagemagick-common - image manipulation programs -- infrastructure
dummy package
 imagemagick-doc - document files of ImageMagick -- dummy package
 libimage-magick-perl - Perl interface to the ImageMagick graphics routines
 libimage-magick-q16-perl - Perl interface to the ImageMagick graphics
routines -- Q16 versio
 libmagick++-6-headers - object-oriented C++ interface to ImageMagick
- header files
 libmagick++-6.q16-6v6 - object-oriented C++ interface to ImageMagick
 libmagick++-6.q16-dev - object-oriented C++ interface to ImageMagick
- development files
 libmagick++-dev - object-oriented C++ interface to ImageMagick -- dummy package
 libmagickcore-6-arch-config - low-level image manipulation library -
architecture header files
 libmagickcore-6-headers - low-level image manipulation library - header files
 libmagickcore-6.q16-2 - low-level image manipulation library --
quantum depth Q16
 libmagickcore-6.q16-2-extra - low-level image manipulation library -
extra codecs (Q16)
 libmagickcore-6.q16-dev - low-level image manipulation library -
development files (Q16)
 libmagickcore-dev - low-level image manipulation library -- dummy package
 libmagickwand-6-headers - image manipulation library - headers files
 libmagickwand-6.q16-2 - image manipulation library
 libmagickwand-6.q16-dev - image manipulation library - development files
 libmagickwand-dev - image manipulation library -- dummy package
 perlmagick - Perl interface to ImageMagick -- dummy package

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

  https://mentors.debian.net/package/imagemagick


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

dget -x 
https://mentors.debian.net/debian/pool/main/i/imagemagick/imagemagick_6.9.5.9+dfsg-1.dsc

  More information about hello can be obtained from https://www.example.com.



  Regards,
   bastien roucaries



Bug#837946: [Aptitude-devel] Bug#837946: aptitude: actions causing »aptitude received signal SIGABRT, Aborted.«

2016-09-16 Thread Axel Beckert
Control: tag -1 + moreinfo

Hi Marcel,

Marcel Partap wrote:
> Package: aptitude
> Version: 0.8.2-1+b1

This version is no more available in Debian anymore for like a month.
Can you please try to upgrade aptitude 0.8.3-1 from Unstable/Testing
and see if you still run into the same issue?

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



Bug#836942: transition: glew

2016-09-16 Thread Matteo F. Vescovi
Hi!

On 2016-09-16 at 08:14 (CEST), Paul Wise wrote:

[...]

> Since you declined I've now uploaded a glewmx source package to NEW.

Thanks.

Cheers.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature


Bug#837225: xemacs21: FTBFS: Can't locate var_file.pl in @INC

2016-09-16 Thread Niko Tyni
On Fri, Sep 16, 2016 at 12:03:54PM +0100, Mark Brown wrote:
> On Sat, Sep 10, 2016 at 09:30:31AM +0200, Lucas Nussbaum wrote:
> 
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> 
> FFS, why did this suddenly break and if it's due to the perl include
> transition why did it not get reported in the mass bug filing for this?

My best guess is that we missed it because xemacs21 doesn't build-depend
on perl and we only tested those packages that do.

As perl is transitively build-essential via dpkg-dev -> libdpkg-perl,
packages can get away without an explicit build dependency. Also, some
packages (looks like this includes xemacs21) only need perl-base, which
is Essential:yes so no build dependency is fine.

Apologies for the inconvenience,
-- 
Niko Tyni   nt...@debian.org



Bug#837996: ftp.debian.org: Please enable auto building of seqan

2016-09-16 Thread Gianfranco Costamagna
control: tags  -1 moreinfo

> Gianfranco Costamagna had the hint that in addition I should mention
> exolicitly that the binary package seqan-apps (which has an rdepends to
> gasic) was removed from the seqan source package but will be created
> now by the seqan2 source package which is in new.  So if this relation
> might stop you from triggering the autobuild it should be solved once
> seqan2 is accepted.

so there is no need to act on this bug probably, except for accepting saqan2 
from
new queue...

G.



signature.asc
Description: OpenPGP digital signature


  1   2   3   >